Re: vepc draft Rev. 04 - /62s to UE, not /64s
Alexandru Petrescu <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <[email protected]> |
Le 11/06/2015 18:02, Jouni Korhonen a écrit : > > > 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. I would like to discuss these use cases. Use cases of grouping devices under a unique cellular connection are very numerous: IPv6 automobiles, IPv6 tethering smartphones, IPv6 Things on Personal Area Networks. All these devices need the cellular operator to deliver shorter-than-64 prefixes to a SIM connection. Alex > > - 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