Hi Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] > Sent: Monday, June 08, 2015 9:43 AM > To: Templin, Fred L; Satoru Matsushima > Cc: dmm > Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s > > Hi Fred, > > Le 04/06/2015 17:10, Templin, Fred L a écrit : > > Hi Alex, > > > >> -----Original Message----- From: Alexandru Petrescu > >> [mailto:alexandru.petre...@gmail.com] 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:alexandru.petre...@gmail.com] 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:dmm-boun...@ietf.org] 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. > > I agree. A dynamic routing protocol like BGP was demonstrated to > feature distributed mobility management on a wide geographical scale. > > >> 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. > > I agree that in general it's good to be more generic with the prefix length. > > But in this particular case we are too generic if we just say '/N'. The > readers will assume '/64' to be a good example of N, and that is not so. > > We can't say 'non-/64' either, because it means too much. > > We could say N between /48 and /63 in one bit steps. But to be clear > that /64 is forbidden. > > (I can imagine the pressure that may put on the operatos, but we may > also think there are enough of these addresses and that the pressure is > simply a misunderstanding.)
What I was thinking was that users could pay for different classes of service. Basic service could be a /64 (or /63 or /62). Premium service could be a /60. Super-premium could be a /56, etc. Point being that the mechanism should support any prefix delegation size that the user has contracted with the service provider for; not just a fixed one-size-fits-all size for all users. Thanks - Fred fred.l.temp...@boeing.com > > Alex > > > > > > > > Thanks - Fred fred.l.temp...@boeing.com > > > >> Alex > >> > >>> > >>> Thanks - Fred fred.l.temp...@boeing.com > >>> > >>>> > >>>> Alex > >>>> > >>>>> > >>>>> Thanks - Fred fred.l.temp...@boeing.com > >>>>> > >>>>> > >>>>>> > >>>>>> Alex > >>>>>> > >>>>>>> > >>>>>>> But yes, I agree with you. > >>>>>>> > >>>>>>> cheers, --satoru > >>>>>>> > >>>>>>> On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu > >>>>>>> <alexandru.petre...@gmail.com > >>>>>>> <mailto:alexandru.petre...@gmail.com>> 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 > >>>>>>> <satoru.matsush...@gmail.com > >>>>>>> <mailto:satoru.matsush...@gmail.com>> 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 > >>>>>>> <sarikaya2...@gmail.com <mailto:sarikaya2...@gmail.com>> > >>>>>>> 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 dmm@ietf.org <mailto:dmm@ietf.org> > >>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ dmm > >>>>>>> mailing list dmm@ietf.org <mailto:dmm@ietf.org> > >>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ dmm > >>>>>> mailing list dmm@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>> > >>> > >> > > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
