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> 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> > 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 https://www.ietf.org/mailman/listinfo/dmm
