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

Hi Alex,

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email protected]]
> Sent: Thursday, June 04, 2015 7:09 AM
> To: Templin, Fred L; Satoru Matsushima
> Cc: dmm
> Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
> 
> Le 04/06/2015 05:42, Templin, Fred L a écrit :
> > 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.
> 
> I agree DHCP-PD provides the necessary tool.  But unfortunately the
> cellular operators have not deployed DHCPv6-PD (although yes there is
> some DHCP-non-PD in some IPv6/4G deployments).

That is a pity, because DHCPv6 PD (along with IPv6 ND and BGP) are all
that are necessary for distributed mobility management.

> The common thinking at operators and advisers is still that a /64 should
> be given to an User Equipment.
> 
> This must change: the 3GPP specs and operator deployments must give /62
> to UEs, and not /64.

Why not a /N instead of just a /62 or /64? N could be anything (62, 60, 56,
48, etc.) as long as it is a proper subset of the prefix space the operator has
available for delegation.

Thanks - Fred
[email protected]

> Alex
> 
> >
> > 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