Hi, > Maybe I can't attend next webex meeting tomorrow.
That is too bad, because I will be briefing the AERO BGP routing system at the meeting tomorrow. > So let me try to make clear what I am thinking. Please correct me if I'm > wrong to understand the notion > of the next DMM charter. > 1. Forwarding path and signaling > In fact, my proposal, stateless-uplan for vEPC (aka vEPC), to dmm is that > wherever mobility management > located, existing user-plane control protocol works fine for forwarding path > > management with some > already proposed extensions. The important thing is, BGP itself is not > mobility management protocol in > the vEPC. The reason for this is because it enables stable operation, > maintained continuously for many > advanced use cases, and most scalable since it supports global Internet > routing. But I think that BGP does > not suitable for mobility management. I understand that other people may have > their own choice, of course. I read your proposal, but have not received any indication if you have read my AERO proposal yet. AERO uses BGP in a way that was first specified by RFC6179 in 2011 and carried forward into draft-templin-ironbis and draft-templin-aerolink. In AERO, BGP allows AERO Relays to keep track of which AERO Client Prefixes (ACPs) are associated with which AERO servers. But, only the Servers are exposed to localized ACP mobility events; the BGP is only updated when an ACP moves to a new Server. This means that there will be very little churn in the BGP routing system itself. So, the BGP is not directly exposed to localized mobility events. > 2. Enhanced mobility anchoring > As you may know the vEPC has anycast discovery for EPC-E. It is not a >discovery mechanism actually. As the > anycast address is assumed to be informed from control-plane, which address > should be chosen is a matter > of anchor selection policy or algorithm in the mobility management. So I know > that more intelligent anchor > selection in the mobility management should be considered to optimize the > path. Anycast would be an > operational choice whether the informed address is assigned to single or > multiple routers. Anycast has been widely used in other router discovery solutions. Two cases are 6rd [RFC5969] and 6to4 [RFC3068]. But, anycast has known operational problems in real networks, and in fact has caused major headaches for 6to4 - even to the point that its deprecation is currently being called for: http://www.ietf.org/mail-archive/web/ipv6/current/msg21248.html http://www.ietf.org/mail-archive/web/ipv6/current/msg21268.html AERO Clients use DNS discovery to discover the address(es) of nearby Server(s) as the default means. Other solutions such as manual configuration, DHCP option, etc. are also possible. > 3. Mobility state exposure > Some people asked me to what entity discloses mobility info mapped into > routes. Yes, vEPC need > that entity to achieve the architecture model. Now that the draft has stated > that it is a further study > item. We have to study common way to disclose mobility information regardless > the type of mobility > management, which are MIP/PMIP or GTP-C whatever. It may need mobility state > exposure for not > only mobile node, but also network node that the charter has already > mentioned. It would be nice if you were to review the AERO architecture and explain to me the way in which this requirement is or is not addressed already there. Thanks - Fred fred.l.temp...@boeing.com From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima Sent: Sunday, October 05, 2014 9:20 PM To: sarik...@ieee.org Cc: Dapeng Liu; dmm@ietf.org Subject: Re: [DMM] Going forward with the DMM work items Behcet, and all, Maybe I can't attend next webex meeting tomorrow. So let me try to make clear what I am thinking. Please correct me if I'm wrong to understand the notion of the next DMM charter. 1. Forwarding path and signaling In fact, my proposal, stateless-uplan for vEPC (aka vEPC), to dmm is that wherever mobility management located, existing user-plane control protocol works fine for forwarding path management with some already proposed extensions. The important thing is, BGP itself is not mobility management protocol in the vEPC. The reason for this is because it enables stable operation, maintained continuously for many advanced use cases, and most scalable since it supports global Internet routing. But I think that BGP does not suitable for mobility management. I understand that other people may have their own choice, of course. 2. Enhanced mobility anchoring As you may know the vEPC has anycast discovery for EPC-E. It is not a discovery mechanism actually. As the anycast address is assumed to be informed from control-plane, which address should be chosen is a matter of anchor selection policy or algorithm in the mobility management. So I know that more intelligent anchor selection in the mobility management should be considered to optimize the path. Anycast would be an operational choice whether the informed address is assigned to single or multiple routers. 3. Mobility state exposure Some people asked me to what entity discloses mobility info mapped into routes. Yes, vEPC need that entity to achieve the architecture model. Now that the draft has stated that it is a further study item. We have to study common way to disclose mobility information regardless the type of mobility management, which are MIP/PMIP or GTP-C whatever. It may need mobility state exposure for not only mobile node, but also network node that the charter has already mentioned. I support these work items to moving forward. I've found some solutions in the forwarding path and signaling. But AFAIK, couldn't see the solutions to apply other two items, but it might be already there. I would like to see solutions which are clarified into three work items and fill them. I would be happy to contribute to make things progress. Cheers, --satoru On Sat, Sep 27, 2014 at 12:14 AM, Behcet Sarikaya <sarikaya2...@gmail.com> wrote: Hi Jouni, I don't see anything in the charter regarding the design teams or "working teams". I also mentioned this in the list and there was no objection. On what basis you are forming the working teams? We currently have many solution drafts and I can not see any of them dividing the solution as exposing mobility state, enhanced mobility anchoring or forwarding path and signaling. These three items were mentioned by certain people which I believe do not constitute the consensus in DMM. Yes the charter had those but my interpretation was it was for the purpose of abstracting the solution into some pieces. I have never interpreted them to be the requirements to divide the final DMM protocol like this. My question is we do that three four solution drafts and some of them implemented. What do we do with them? My advice to those colleagues wishing to lead the design teams is to please come up with your own solution and get into the race with others. How come they can get the hat of DT lead and produce something and get priority over others who worked so hard? Regards, Behcet On Fri, Sep 26, 2014 at 12:51 AM, Jouni Korhonen <jouni.nos...@gmail.com> wrote: > Folks, > > In the interim call #2 we agreed to form "working teams". We got three > volunteers to run up those: > > o Alper will take care of coordinating "exposing mobility state.." > o Anthony will take care of coordinating "enhanced mobility anchoring.." > o Marco will take care of coordinating "forwarding path and signaling.." > > The above gentlement will arrange calls for brainstorming that are open for > everyone to participate. The process is open - about equivalent to a design > team, you just don't need to signup for one. Just keep in mind that it is > good to concentrate on a limited amount of work items. > > The working teams, if they so manage, will produce the solution I-D(s). > These documents will be equivalent to any individual produced I-D, though. > > - Jouni & Dapeng > > _______________________________________________ > 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 _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
