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. 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
