Hi Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] > Sent: Tuesday, June 09, 2015 7:58 AM > To: Templin, Fred L; Satoru Matsushima > Cc: dmm > Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s > > Fred, > > Le 08/06/2015 19:08, Templin, Fred L a écrit : > [...] > > >>>> 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. > > Well it looks like a good idea. It is a bit new compared to IPv4 in > cellular networks (there is no concept of premium service delivery of > several IPv4 addresses per single device, and there is no StdsTrack PD > for DHCPv4). Do you think cellular operators may create such new > payment schemes for classes of service in IPv6? Or rather migrate the > existing IPv4 payment schemes from IPv4 - a one to one mapping between > concepts, modulo the address length being bigger?
I don't know much about the cellular operator business. I am confident AERO would be a good fit for that environment, but I have been more focused on enterprise networks, aviation networks, unmanned air system networks, etc. Taking aviation for example, I believe that airplanes will have many onboard addressable devices and networks. So, a /56 (or possibly even more) might be a natural prefix delegation unit for each airplane. > > 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. > > I agree - the mechanism is there. OK. > Why the cellular operators dont respond to DHCPv6 Prefix Delegation > requests from the User Equipments? I don't know why - it is really easy to set up, and a natural way to get an arbitrary-length prefix delegation to the UE. 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 > >>>>>> > >>>>>>> > >>>>>>> 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
