Hi Marco, Might be difficult to converge over email on this topic. But, I will try.
> Then: If we think about the case 2b below, that implies that the initially > selected DPA (is it the home DPA in your model?) binds a HoA which is topologically not correct from the very beginning. Here, traffic steering may be required from the first registration already. I am just wondering if there is a reasonable use case behind this. PI address binding? The entity (CP and/or DP) where the subscriber's control plane state got created is always "Home CPA" and the entity where the subscriber home address (lets say EID :) ) is topologically anchored is always the "home DPA". There is no reason for the home CPA to allocate a DPA and a prefix that have not topological relation. IMO, the CPA should ensure it allocates a topologically correct address, by selecting a DPA and the allocated address pool associated with that anchor. Any incorrect allocation may happen for supporting session chaining in roaming scenarios, but truly the home CPA in such scenario is outside the admin domain. If our goal is for realizing optimized routing, we rather ensure there is no traffic steering requirement after the first registration. But again, there are two scenarios here. The a.) very flat model with a controller and a bunch of DPA's that Pete was interested in (Pete's model), and the b) model of splitting CP and DP in access and home domains. For the former case, the DPA (Home+Access) will always be a floating anchor, but for the later case, its only the access DPA which is a floating anchor. IMO, in both the cases, the aspect of CPA migration is rare and for very specific use-cases that we need to qualify. Moving a mobile’s mobility state (binding a HoA to a locator) from a previous DPA to a new DPA is gateway relocation. Well, relocation of the data plane anchor. The control plane anchor will/may stay the same. HoA to COA binding change (EID to Locator mapping) should not be looked at as gateway relocation. Unless we move the address across anchors by updating the routing infrastructure, there is never a DPA migration. The moment we talk about Locator, it implies we have access DPA and home DPA, and change of access DPA is not relocation, its only a state change on the home DPA. The DPA relocation is mainly for the very flat, pete's model. But, again, that model will be bounded in size, given the # of routes. Agree, the CPA relocation is rare, specially in the controller-based architectures. We have some use cases for Geo-Redundancy where CPA migration will be needed, but again we need to qualify that use-cases as that comes at some cost. Regards Sri From: Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>> Date: Monday, July 14, 2014 5:50 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [DMM] demand for DMM traffic steering Hi Sri, Thanks for your prompt response. please see inline. From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Freitag, 11. Juli 2014 19:46 To: Marco Liebsch; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] demand for DMM traffic steering Hi Marco, I think we may have to qualify the term "anchor". In our conf calls we used the terms, Control Plane Anchor (CPA), Data Plane Anchor (DPA) with Home/Access prefix tags. I thought that gets clear from my description, but you are right. This thread focuses on the data/user plane anchor. At the start of a session, the selected anchor assigns a topologically correct address. I guess you’re referring to the mobility session, not the data session. Yes, that’s today’s procedure: Select (data-plane) anchor first, then assign an IP address which fits to the anchor’s network. The HoA/HNP for a mobile node's session is always topologically anchored on that node. That anchor is the Home CPA/DPA (Integrated case) and for the controller scenario, those functions are split across two nodes. However, once the MN changes its point of attachment, then the selected anchor for that attachment can be the Acces-CPA/Access-DPA in relation to the home CPA/DPA. The session is still anchored on the home CPA/DPA, but the access CPA/DPA is providing the CoA (pardon me, its your locator per the LISP terminology, or our classic CoA) and the routing state. However, this access CPN/DPN is also a Home CPN/DPN as the MN can create a new session and may obtain a new HoA/MNP. I think it can be even the same CPA that controls multiple DPAs, whether it’s the home or the access. About the terms: I like the identifier/locator terms as they apply to any mobility solution without taking a particular one (e.g. PMIP) as base line for a discussion. This is not LISP-specific. See, MIP maps an identifier (HoA) to a locator (CoA). Northbound to the HA, the HoA serves as both, identifier and locator assuming a topologically correct HoA at that anchor. Same for PMIP; or even Cellular IP, where the locator is an output port, or BGP, where the locator is a hext hop :) So I think this is suitable terminology to discuss DMM, in particular if we still differentiate the northbound and the southbound operation from a distributed data plane anchor viewpoint. Questions to answer are then how are packet routed to selected DPA in particular if the assigned HoA is topologically incorrect at the used DPA. The protocol southbound to the DPA may use any mobility specific transport, e.g. tunnel (to the locator :)) . The aspect of session relocation is relevant for the initial session and at that point your case#2 comes into picture. Yes, that was the rationale behind. At this point, we have a choice to keep both Access CPN/DPN and Home CPN/DPN and apply traditional schemes for forwarding traffic, or relocate the session to the new Access CPA/DPA and make that as the Home CPA/DPN for the initial session. But, the access CPA/DPA is always a local gateway (typically first-hop router) and so not sure how the gateway selection can be relevant in this context. Moving a mobile’s mobility state (binding a HoA to a locator) from a previous DPA to a new DPA is gateway relocation. Well, relocation of the data plane anchor. The control plane anchor will/may stay the same. Gateway selection is relevant in a two node architecture with access and home anchors, and selection being about the home anchor. Selection is an orthogonal problem. Of course an initial DPA and a target DPA must be selected during DPA relocation. But the mechanism to transfer binding context and to steer traffic to the new anchor is a different technology compared to selection. Then: If we think about the case 2b below, that implies that the initially selected DPA (is it the home DPA in your model?) binds a HoA which is topologically not correct from the very beginning. Here, traffic steering may be required from the first registration already. I am just wondering if there is a reasonable use case behind this. PI address binding? marco Regards Sri From: Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>> Date: Friday, July 11, 2014 8:59 AM To: "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: [DMM] demand for DMM traffic steering Folks, I would like to discuss the demand for DMM traffic steering as preparation for Toronto. DMM enables smart deployment and selection of network components serving as User-Plane anchor to the mobile node. The MN’s IP address or prefix (HNP/HoA) is assigned to the selected anchor and bound to the MN’s locator (CoA, pCoA, ..) Now, there are two cases: (1) Selected anchor is in the network of the MN’s HoA/HNP (topologically correct address) (2) Selected anchor is not in the network of the MN’s HoA/HNP (topologically incorrect address) Case (1) is what IP mobility assumed so far. Default routes in the transport network deliver the packet into the network which hosts the MN’s assigned anchor. Case (2) can happen in 2 cases: (a) MN gets assigned a new anchor mid-session but wants to keep its HoA/HNP. That’s what has been called so far anchor re-location (b) MN has a stable IP address (e.g. profile-bound) but the network wants to select an anchor according to the requested service, i.e. anchor should be close to a local server or CDN cache. In that case the MN’s IP address will be topologically incorrect from the very beginning of its attachment. All cases (a) and (b) may require steering the MN’s traffic according to a host policy, as the route deviates from the default. First questions we may rise: I) Are we on the same page regarding the above cases? II) What comes first in DMM: IP address configuration or anchor selection? Hope we can discuss some opinions ahead of the meeting. marco
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
