Re: vepc draft Rev. 04 - /62s to UE, not /64s
Jouni Korhonen <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <[email protected]> |
6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: > 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). > > 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. I think we are not in the position to force operators or 3GPP to do anything, unfortunately. The best we can do is to make sure the protocols we work here in IETF are not prohibiting better deployments (see e.g. RFC6603 effort). 3GPP specs are not the show stoppers here. I know this is frustrating. For example some operators I know offer IPv6 PD on their fixed side of business but have no plans for similar on the cellular side.. reasons are many. I assume that identofying a strong enough use case would be the key. - Jouni > > 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 _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm