Re: vepc draft Rev. 04 - /62s to UE, not /64s

Hi Alex,

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email protected]]
> Sent: Wednesday, June 03, 2015 8:36 AM
> To: Templin, Fred L; Satoru Matsushima
> Cc: dmm
> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
> 
> Le 29/05/2015 20:21, Templin, Fred L a écrit :
> > Hi Alex,
> >
> >> -----Original Message-----
> >> From: dmm [mailto:[email protected]] On Behalf Of Alexandru Petrescu
> >> Sent: Friday, May 29, 2015 10:59 AM
> >> To: Satoru Matsushima
> >> Cc: dmm
> >> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
> >>
> >> Le 29/05/2015 15:30, Satoru Matsushima a écrit :
> >>> Ah OK. thanks.
> >>> Slightly off-topic, I think that there is still chance for tethering
> >>> with single /64 if it is allocated as a off-link prefix.
> >>
> >> Yes, there is still such a chance.  But it can not tether more than one
> >> single subnet.  Connected vehicles need several subnets.
> >
> > How would it be if the vehicle received a single prefix, but it could be
> > shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting
> > be satisfied if it received a shorter prefix from which many /64s
> > could be allocated?
> 
> Certainly yes.
> 
> Each vehicle needs such a shorter-than-64 prefix allocated to it.
> 
> For example, an automobile connecting to LTE receives a /62 from the
> operator and makes four /64s out of it: one for its CAN-entertainment,
> one for its CAN-safety, one for its WiFi and one for its Bluetooth.
> 
> This is a MUST.
> 
> Allocating a single /64 to a vehicle can not accommodate all these
> unbridgeable subnets.

OK, that is good. Giving a mobile router something shorter than /64
should be no problem, at least up to practical limitations of the prefix
delegation authority's available prefix space. DHCPv6 PD provides all
that is needed to give out right-sized prefixes.

Thanks - Fred
[email protected]
 
> 
> Alex
> 
> >
> > Thanks - Fred
> > [email protected]
> >
> >
> >>
> >> Alex
> >>
> >>>
> >>> But yes, I agree with you.
> >>>
> >>> cheers,
> >>> --satoru
> >>>
> >>> On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu
> >>> <[email protected] <mailto:[email protected]>> wrote:
> >>>
> >>>      Hi,
> >>>
> >>>      In addition to what Behcet says.
> >>>
> >>>      I read the example below.  I think it is just an example, but just
> >>>      to make sure.
> >>>
> >>>      Please - do not allocate /64s to end users in a cellular network.
> >>>      Allocate at least /62s to end users.
> >>>
> >>>      This is to allow the smartphone to perform tethering (small network
> >>>      of wifi devices connecting through the smartphone to the Internet).
> >>>
> >>>      The assumption of /64 to end user is not good at all.
> >>>
> >>>      (and yes, I agree that these /62s may be aggregated into a larger
> >>>      prefix and advertised upstream as a single prefix instead of
> >>>      multiple host-based routes).
> >>>
> >>>      Yours,
> >>>
> >>>      Alex Petrescu
> >>>
> >>>      Le 26/05/2015 22:34, Behcet Sarikaya a écrit :
> >>>
> >>>          Hi Satoru,
> >>>
> >>>          Thanks for your reply.
> >>>
> >>>          Let me continue the discussion with your text in Section 3.2
> >>>          where you mention
> >>>          vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP)
> >>>          that defines FPCP Agent function and Client function.
> >>>
> >>>          I don't understand how you could justify defining a new forwarding
> >>>          policy configuration protocol to do this Agent/Client functionality?
> >>>          Why not use similar Agent/Client models that are being defined
> >>>          rather
> >>>          than defining a new protocol?
> >>>          I think this point requires much stronger justification which I
> >>>          could
> >>>          not see in Section 3.2.
> >>>
> >>>          Are you that we have to to reinvent the wheel, rather than reusing
> >>>          something that is already available? How are we going to
> >>>          reinvent that
> >>>          wheel also remains to be seen, I think.
> >>>
> >>>          Regards,
> >>>
> >>>          Behcet
> >>>
> >>>
> >>>
> >>>          On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima
> >>>          <[email protected]
> >>>          <mailto:[email protected]>> wrote:
> >>>
> >>>              Hi Bechet-san,
> >>>
> >>>              Thank you for your question.
> >>>              In step (15), I meant that EPC-E advertises prefix including
> >>>              UE assigned
> >>>              prefixes.
> >>>
> >>>              For example, in the case of /64 prefixes assigned to UEs
> >>>              from a /56 space,
> >>>              that /56
> >>>              is advertised by EPC-E to upstream routers. So the
> >>>              advertised route isn't
> >>>              host routes.
> >>>
> >>>              Depends on configuration policy, but one case is that the
> >>>              source of that
> >>>              advertised
> >>>              /56 route might be statically configured in EPC-E.
> >>>
> >>>              Regards,
> >>>              --satoru
> >>>
> >>>
> >>>
> >>>              On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya
> >>>              <[email protected] <mailto:[email protected]>>
> >>>              wrote:
> >>>
> >>>
> >>>                     Hi Matsushima-san,
> >>>
> >>>                  I have a question on your draft:
> >>>                  In Sec. 3.2, page 11, you say
> >>>                  In step (15), the EPC-E advertises routes to upstream
> >>>                  routers ...
> >>>
> >>>                  Are these routes static/host routes?
> >>>
> >>>                  Regards,
> >>>
> >>>                  Behcet
> >>>
> >>>
> >>>
> >>>
> >>>          _______________________________________________
> >>>          dmm mailing list
> >>>          [email protected] <mailto:[email protected]>
> >>>          https://www.ietf.org/mailman/listinfo/dmm
> >>>
> >>>
> >>>
> >>>
> >>>      _______________________________________________
> >>>      dmm mailing list
> >>>      [email protected] <mailto:[email protected]>
> >>>      https://www.ietf.org/mailman/listinfo/dmm
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> dmm mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/dmm
> 

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm