[DMM] Enhanced mobility anchoring
The bridge number for Wednesday May 27 9:30-10:30 Central Daylight Time: ATT Connect USA Toll-Free: 888-858-6182 USA Caller Paid: 646-746-3029 For Other Countries: Click Here to View Global Conference Access Numbershttps://www.teleconference.att.com/servlet/glbAccess?process=1accessCode=1136694accessNumber=6467463029#C2 Access Code: 3101535 Continue discussions on the enhanced mobility anchoring. H Anthony Chan From: h chan Sent: Tuesday, May 19, 2015 12:37 PM To: 'dmm@ietf.org' Subject: RE: Enhanced mobility anchoring Let us schedule 2 teleconferences (one hour each) to accommodate everyone in the doodle list: 1st teleconference: Friday May 22 at 9:30-10:30AM US Central Time 2nd teleconference: Wednesday May 27 at 9:30-10:30AM US Central Time Thanks. H Anthony Chan From: h chan Sent: Friday, May 15, 2015 11:08 AM To: dmm@ietf.orgmailto:dmm@ietf.org Subject: Enhanced mobility anchoring Please check your availability for a teleconference to discuss enhanced mobility anchoring. Thanks. http://doodle.com/fibfbwybwhws65gb H Anthony Chan ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] vepc draft Rev. 04
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
[DMM] WT#4 - Conf Call
Folks: I’m trying to schedule one or two calls to discuss the work items under WT#4. We did have few discussions including f2f meetings in the past, but now doing it more formally. Scope of WT#4 per chairs suggestion was to cover, architectural/deployment models and to tie the different work items under the overall DMM scope. If you have any topics to present in this call, send me a note and we can cover that. I will schedule these calls for the weeks of June 15 and June 27th. I will send out a poll. Regards Sri ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
