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