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
