Understood. If there is agreement on the functional roles, the terms can be worked out.
Sri From: Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>> Date: Thursday, July 17, 2014 8:30 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, "Hirschman, Brent B [CTO]" <brent.hirsch...@sprint.com<mailto:brent.hirsch...@sprint.com>>, Alper Yegin <alper.ye...@yegin.org<mailto:alper.ye...@yegin.org>> Cc: "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [DMM] demand for DMM traffic steering I am only about functions, not picky about terms. But with certain terms there is some expectation of the function behind. We need to be clear about the roles of both, access and home DPA for mobility management and assess their role in driving the different DMM scenarios. marco From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Donnerstag, 17. Juli 2014 06:37 To: Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin Cc: dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] demand for DMM traffic steering Hi Marco, If there should be the use of word, "Anchor" in "access DPA" term is a minor issue, IMO. We can always fix that and come up with a better term. The key point is the distinction in roles and functionalities of these two entities and which we seem to agree. Home DPA is clearly the routing anchor and access DPA is entity that is providing some mobility support and it is also the first-hop router. We also need to highlight that the functional role is always in the context of a mobility session. The Access DPA may assume the role of Home DPA for one specific MN's session, while it may offer the Access DPA function to another mobility session. > If we bring in offload at an Access DPA, the Access DPA provides a different > IP address to the MN and becomes the Home DPA for traffic using that IP. The > role of the original Home DPA may be solely to determine which traffic to > offload at the Access DPA. When we discuss offload at the Access DPA, we should qualify this and state that this offload is for certain IP flows for a session anchored on a remote Home DPA. While there may be another session anchored on the same Access DPA for that MN (with the access DPA acting as a Home DPA for that local session), but that session will have not relation to the Home DPA of the first session and so making sure your last sentence above did not suggest that. Its strictly the UE choice on address selection for local offload. On the aspect of session migration across Home DPA's you had a comment in one of your earlier emails. I see session migration as a tool used in very specific scenarios. When we migrate a session from Home-DPA-1 to Home-DPA-2, truly the session is completely migrated to the new Home DPA; even the routing infra is updated and that allows us to completely forget the previous Home-DPA where the session was previously hosted. For a mobility session, at a point of time, we have states in the Controller, Home DPA and Access DPA (optionally) and that's about it. Home DPA may have been changed, Access DPA may have been changed as well, but the state is always present in these three entities. Regards Sri From: Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>> Date: Wednesday, July 16, 2014 2:31 PM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, "Hirschman, Brent B [CTO]" <brent.hirsch...@sprint.com<mailto:brent.hirsch...@sprint.com>>, Alper Yegin <alper.ye...@yegin.org<mailto:alper.ye...@yegin.org>> Cc: "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [DMM] demand for DMM traffic steering Sri, please see inline. From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Mittwoch, 16. Juli 2014 15:32 To: Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin Cc: dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] demand for DMM traffic steering Marco, If the idea is DP anchor relocation after every L3 mobility event, you have a single-node DPA model. The MN attach point at every location will take the Home DPA Role after each Relocation trigger. Any time you cannot relocate a Home DPA, you end with a two node Access/Home DPA model, which IMO offers nice flexibility with respect to when to initiate DP relocation and when to go with a two-node DPA model. Yes, that’s close to the model I had in mind. Remain anchored at the DPA, which preforms mobility management. Then, at some point when it makes sense (not every L3 handover, but when e.g. the routing path can be optimized), relocate the DPA. The new DPA may provide a new, topologically correct IP to the MN, or may import and bind the previous IP if IP address continuity is required. In the latter case tailored routing rules for traffic steering are required. The role of the Access DPA in case the Home DPA performs mobility management I left aside so far, as it serves more as locator (access gateway). It’s not necessarily an anchor in terms of mobility management, unless we talk about a hierarchy of mobility anchors. If we bring in offload at an Access DPA, the Access DPA provides a different IP address to the MN and becomes the Home DPA for traffic using that IP. The role of the original Home DPA may be solely to determine which traffic to offload at the Access DPA. With all this (the Access DPA becoming a Home DPA..) I am wondering if the Access DPA deserves the term Anchor. Also according to your description we only have Home DPAs, which bind an MN’s IP and perform mobility management. The Access-thing is not an anchor until it performs offload, which makes a Home DPA out of it. Isn’t it more a Data Plane Access Gateway until it becomes a real anchor? marco
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
