[DMM] WG adoption (was Re: DMM solution space)
Folks, Let's change gears. We'd like to propose draft-yegin-dmm-ondemand-mobility-02 for WG adoption. This draft falls under the following deliverable: Exposing mobility state to mobile nodes and network nodes: define solutions that allow, for example, mobile nodes to select either a care-of address or a home address depending on an application' mobility needs. In order to enable this functionality, the network side control functions and other networking nodes must also be able to exchange appropriate control information, as well as to the mobile nodes and their applications. Comments welcome. Alper Behcet/Fred: I've updated the list with your input. - Per-flow IP address configuration according to mobility needs Apps indicating their mobility needs to the IP stack on the MN, and associated IP configuration signaling between the MN and the network. draft-bhandari-dhc-class-based-prefix-03 draft-korhonen-dmm-prefix-properties-00.txt draft-yegin-dmm-ondemand-mobility-02 - Mobility solution selection MN determining the type of mobility solution(s) it'd apply to a given flow. draft-yegin-ip-mobility-orchestrator-00 - IP anchor selection MN selecting the IP anchor node after it decides to use IP anchoring (whether in the access network or the core network). draft-aliahmad-dmm-anchor-selection-00.txt - Access network anchoring Anchoring IP address within the access network using IP-in-IP tunneling. draft-bernardos-dmm-cmip-01 draft-bernardos-dmm-pmip-03 draft-bernardos-dmm-distributed-anchoring-04 draft-chan-dmm-enhanced-mobility-anchoring-00 draft-sarikaya-dmm-for-wifi-00.txt draft-seite-dmm-dma-07.txt draft-xuan-dmm-nemo-dmm-02.txt - Corresponding node/network anchoring Anchoring IP address on the Corresponding Node or Corresponding Network. Mobile IPv6 route optimization draft-yegin-dmm-cnet-homing-02 draft-xiong-dmm-ip-reachability-01 draft-templin-aerolink-29 - Host-route based intra-domain solutions Non-tunneling solutions. draft-chan-dmm-enhanced-mobility-anchoring-00 draft-matsushima-stateless-uplane-vepc-02 draft-mccann-dmm-flatarch-00 draft-sarikaya-dmm-for-wifi-00.txt___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
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 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.eumailto:marco.lieb...@neclab.eu Date: Wednesday, July 16, 2014 2:31 PM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com, Hirschman, Brent B [CTO] brent.hirsch...@sprint.commailto:brent.hirsch...@sprint.com, Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Cc: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto: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.orgmailto: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
Re: [DMM] DMM solution space
Since you are collecting the list, there is one PMIPv6 extension that deals with access network short lived addresses (where MAG would be the access DPA): draft-korhonen-dmm-local-prefix-01 I think it belongs to Anchoring IP address within the access network using IP-in-IP tunneling in your categorization. - Jouni 7/12/2014 2:13 PM, Alper Yegin kirjoitti: Folks, I went over the solutions and categorized them. I haven't covered all of the solutions (due to lack of time). For any I-D that is missing, please state the name and where you think it belongs to. When we agree with the categorization and the candidates for each, then we can proceed to discussing how we can converge. Note: Multiple I-Ds under each category may be complementary, competing, or orthogonal (e.g., due to different applicability). It's case by case. Cheers, *- Per-flow IP address configuration according to mobility needs* Apps indicating their mobility needs to the IP stack on the MN, and associated IP configuration signaling between the MN and the network. draft-bhandari-dhc-class-based-prefix-03 draft-korhonen-dmm-prefix-properties-00.txt draft-yegin-dmm-ondemand-mobility-02 *- Mobility solution selection * MN determining the type of mobility solution(s) it'd apply to a given flow. draft-yegin-ip-mobility-orchestrator-00 *- IP anchor selection* MN selecting the IP anchor node after it decides to use IP anchoring (whether in the access network or the core network). draft-aliahmad-dmm-anchor-selection-00.txt *- Access network anchoring* Anchoring IP address within the access network using IP-in-IP tunneling. draft-bernardos-dmm-cmip-01 draft-bernardos-dmm-pmip-03 draft-bernardos-dmm-distributed-anchoring-04 draft-chan-dmm-enhanced-mobility-anchoring-00 draft-sarikaya-dmm-for-wifi-00.txt draft-seite-dmm-dma-07.txt draft-xuan-dmm-nemo-dmm-02.txt *- Corresponding node/network anchoring* Anchoring IP address on the Corresponding Node or Corresponding Network. Mobile IPv6 route optimization draft-yegin-dmm-cnet-homing-02 draft-xiong-dmm-ip-reachability-01 *- Host-route based intra-domain solutions* Non-tunneling solutions. draft-chan-dmm-enhanced-mobility-anchoring-00 draft-matsushima-stateless-uplane-vepc-02 draft-mccann-dmm-flatarch-00 ___ 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
Re: [DMM] Fwd: IETF 90 Preliminary Agenda
Folks, The agenda has been updated.. no more requests allowed (running out of time). The allocated times for slots are still subject to change, mainly to take minutes away from those who have plenty to those who have less.. http://www.ietf.org/proceedings/90/agenda/agenda-90-dmm The agenda is packed so make sure you stay within your allocated time slot with your powerpoint marathon and actually have some time left for the QA. - Jouni Dapeng 6/24/2014 12:22 AM, Behcet Sarikaya kirjoitti: Friday (after)noon session :) On Mon, Jun 23, 2014 at 4:01 PM, Alper Yegin alper.ye...@yegin.org wrote: Oops, I missed the second one :-) Sorry for the false alarm. On Jun 23, 2014, at 11:15 PM, h chan wrote: I see 2 sessions in the agenda. H Anthony Chan From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Monday, June 23, 2014 2:26 PM To: dmm@ietf.org Subject: [DMM] Fwd: IETF 90 Preliminary Agenda How are we going to make progress on solution discussions when all we have is a single 2-hr session for the whole DMM WG? Begin forwarded message: From: IETF Agenda age...@ietf.org Subject: IETF 90 Preliminary Agenda Date: June 23, 2014 10:16:20 PM GMT+03:00 To: IETF Announcement List ietf-annou...@ietf.org Cc: i...@ietf.org Reply-To: i...@ietf.org, IETF Agenda age...@ietf.org The IETF 90 Preliminary Agenda has been posted. The final agenda will be published on Friday, June 27th, 2014. Currently Registration and Breaks are not displaying. This will be remedied on the final agenda. https://datatracker.ietf.org/meeting/90/agenda.html https://datatracker.ietf.org/meeting/90/agenda.txt More information regarding IETF 90 in Toronto, ON, Canada is located here:https://www.ietf.org/meeting/90/index.html Thank you! IETF Secretariat ___ 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
Re: [DMM] WG adoption (was Re: DMM solution space)
Hi Jouni, We cannot have an official approval of the documents, but what we can do is: - check the WG to see if they are willing to accept a document, based on the assumption that the new charter would be approved - if the WG is OK, then when the charter is approved, we can double check on the mailing list and make WG adoption official. We should progress… Alper On Jul 17, 2014, at 7:03 PM, Jouni Korhonen wrote: Alper, The charter text you cite is not approved yet. I-D adoption requests at this point are premature. - Jouni 7/17/2014 9:19 AM, Alper Yegin kirjoitti: * * Folks, Let's change gears. We'd like to propose draft-yegin-dmm-ondemand-mobility-02 for WG adoption. This draft falls under the following deliverable: Exposing mobility state to mobile nodes and network nodes: _define solutions that allow, for example, mobile nodes to select_ _either a care-of address or a home address depending on an_ _application' mobility needs_. In order to enable this functionality, the network side control functions and other networking nodes must also be able to exchange appropriate control information, as well as to the mobile nodes and their applications. Comments welcome. Alper Behcet/Fred: I've updated the list with your input. * * * * *- Per-flow IP address configuration according to mobility needs* Apps indicating their mobility needs to the IP stack on the MN, and associated IP configuration signaling between the MN and the network. draft-bhandari-dhc-class-based-prefix-03 draft-korhonen-dmm-prefix-properties-00.txt draft-yegin-dmm-ondemand-mobility-02 *- Mobility solution selection * MN determining the type of mobility solution(s) it'd apply to a given flow. draft-yegin-ip-mobility-orchestrator-00 *- IP anchor selection* MN selecting the IP anchor node after it decides to use IP anchoring (whether in the access network or the core network). draft-aliahmad-dmm-anchor-selection-00.txt *- Access network anchoring* Anchoring IP address within the access network using IP-in-IP tunneling. draft-bernardos-dmm-cmip-01 draft-bernardos-dmm-pmip-03 draft-bernardos-dmm-distributed-anchoring-04 draft-chan-dmm-enhanced-mobility-anchoring-00 draft-sarikaya-dmm-for-wifi-00.txt draft-seite-dmm-dma-07.txt draft-xuan-dmm-nemo-dmm-02.txt *- Corresponding node/network anchoring* Anchoring IP address on the Corresponding Node or Corresponding Network. Mobile IPv6 route optimization draft-yegin-dmm-cnet-homing-02 draft-xiong-dmm-ip-reachability-01 draft-templin-aerolink-29 *- Host-route based intra-domain solutions* Non-tunneling solutions. draft-chan-dmm-enhanced-mobility-anchoring-00 draft-matsushima-stateless-uplane-vepc-02 draft-mccann-dmm-flatarch-00 draft-sarikaya-dmm-for-wifi-00.txt ___ 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
Re: [DMM] IETF 90 Preliminary Agenda
16:05 - 16:15 New proposal, Alper (10 minutes) The new proposal here is: https://datatracker.ietf.org/doc/draft-yegin-ip-mobility-orchestrator/ (Jouni, I'd appreciate if you can fix the online agenda as well). Alper On Jul 17, 2014, at 7:36 PM, Jouni Korhonen wrote: Folks, The agenda has been updated.. no more requests allowed (running out of time). The allocated times for slots are still subject to change, mainly to take minutes away from those who have plenty to those who have less.. http://www.ietf.org/proceedings/90/agenda/agenda-90-dmm The agenda is packed so make sure you stay within your allocated time slot with your powerpoint marathon and actually have some time left for the QA. - Jouni Dapeng 6/24/2014 12:22 AM, Behcet Sarikaya kirjoitti: Friday (after)noon session :) On Mon, Jun 23, 2014 at 4:01 PM, Alper Yegin alper.ye...@yegin.org wrote: Oops, I missed the second one :-) Sorry for the false alarm. On Jun 23, 2014, at 11:15 PM, h chan wrote: I see 2 sessions in the agenda. H Anthony Chan From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Monday, June 23, 2014 2:26 PM To: dmm@ietf.org Subject: [DMM] Fwd: IETF 90 Preliminary Agenda How are we going to make progress on solution discussions when all we have is a single 2-hr session for the whole DMM WG? Begin forwarded message: From: IETF Agenda age...@ietf.org Subject: IETF 90 Preliminary Agenda Date: June 23, 2014 10:16:20 PM GMT+03:00 To: IETF Announcement List ietf-annou...@ietf.org Cc: i...@ietf.org Reply-To: i...@ietf.org, IETF Agenda age...@ietf.org The IETF 90 Preliminary Agenda has been posted. The final agenda will be published on Friday, June 27th, 2014. Currently Registration and Breaks are not displaying. This will be remedied on the final agenda. https://datatracker.ietf.org/meeting/90/agenda.html https://datatracker.ietf.org/meeting/90/agenda.txt More information regarding IETF 90 in Toronto, ON, Canada is located here:https://www.ietf.org/meeting/90/index.html Thank you! IETF Secretariat ___ 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] WG adoption (was Re: DMM solution space)
Lets get the charter approved first. - jouni 7/17/2014 7:42 PM, Alper Yegin kirjoitti: Hi Jouni, We cannot have an official approval of the documents, but what we can do is: - check the WG to see if they are willing to accept a document, based on the assumption that the new charter would be approved - if the WG is OK, then when the charter is approved, we can double check on the mailing list and make WG adoption official. We should progress… Alper On Jul 17, 2014, at 7:03 PM, Jouni Korhonen wrote: Alper, The charter text you cite is not approved yet. I-D adoption requests at this point are premature. - Jouni 7/17/2014 9:19 AM, Alper Yegin kirjoitti: * * Folks, Let's change gears. We'd like to propose draft-yegin-dmm-ondemand-mobility-02 for WG adoption. This draft falls under the following deliverable: Exposing mobility state to mobile nodes and network nodes: _define solutions that allow, for example, mobile nodes to select_ _either a care-of address or a home address depending on an_ _application' mobility needs_. In order to enable this functionality, the network side control functions and other networking nodes must also be able to exchange appropriate control information, as well as to the mobile nodes and their applications. Comments welcome. Alper Behcet/Fred: I've updated the list with your input. * * * * *- Per-flow IP address configuration according to mobility needs* Apps indicating their mobility needs to the IP stack on the MN, and associated IP configuration signaling between the MN and the network. draft-bhandari-dhc-class-based-prefix-03 draft-korhonen-dmm-prefix-properties-00.txt draft-yegin-dmm-ondemand-mobility-02 *- Mobility solution selection * MN determining the type of mobility solution(s) it'd apply to a given flow. draft-yegin-ip-mobility-orchestrator-00 *- IP anchor selection* MN selecting the IP anchor node after it decides to use IP anchoring (whether in the access network or the core network). draft-aliahmad-dmm-anchor-selection-00.txt *- Access network anchoring* Anchoring IP address within the access network using IP-in-IP tunneling. draft-bernardos-dmm-cmip-01 draft-bernardos-dmm-pmip-03 draft-bernardos-dmm-distributed-anchoring-04 draft-chan-dmm-enhanced-mobility-anchoring-00 draft-sarikaya-dmm-for-wifi-00.txt draft-seite-dmm-dma-07.txt draft-xuan-dmm-nemo-dmm-02.txt *- Corresponding node/network anchoring* Anchoring IP address on the Corresponding Node or Corresponding Network. Mobile IPv6 route optimization draft-yegin-dmm-cnet-homing-02 draft-xiong-dmm-ip-reachability-01 draft-templin-aerolink-29 *- Host-route based intra-domain solutions* Non-tunneling solutions. draft-chan-dmm-enhanced-mobility-anchoring-00 draft-matsushima-stateless-uplane-vepc-02 draft-mccann-dmm-flatarch-00 draft-sarikaya-dmm-for-wifi-00.txt ___ 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
Re: [DMM] demand for DMM traffic steering
Intense reading… :-) Lot of abstractions, which I can only follow by relating to specific solutions. In my understanding, what Sri is describing is about how to apply UP/CP separation to various DMM solutions. In the examples I see a number of DMM solutions defined with UP/CP separation using Sri's terminology (e.g., per-flow mobility, access network anchoring, host-specific route based solutions, etc). So, it's not a solution by itself, but it's an approach that can be applied to various solution techniques to SDNize them. And that indeed has value. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] WG adoption (was Re: DMM solution space)
I'm in favor of this approach. This was my suggestion as well in the past (when we presented prefix coloring spec) to move forward some documents. But, those should be documents which are considered common across multiple solution approaches. The issue seems to be charter approval. Sri On 7/17/14 11:04 AM, Alper Yegin alper.ye...@yegin.org wrote: Why? Why not make technical progress at every opportunity? This extreme serialization and every step overly stretchingŠ. am I the only one having issue with the slow progress? Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] demand for DMM traffic steering
Understood. If there is agreement on the functional roles, the terms can be worked out. Sri From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu Date: Thursday, July 17, 2014 8:30 AM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com, Hirschman, Brent B [CTO] brent.hirsch...@sprint.commailto:brent.hirsch...@sprint.com, Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Cc: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto: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.orgmailto: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.eumailto:marco.lieb...@neclab.eu Date: Wednesday, July 16, 2014 2:31 PM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com, Hirschman, Brent B [CTO] brent.hirsch...@sprint.commailto:brent.hirsch...@sprint.com, Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Cc: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto: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.orgmailto: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).
Re: [DMM] demand for DMM traffic steering
I do not know your definition of approach vs solution, but one can argue DMM itself is about a deployment model and an approach. I always insisted its less of a protocol work and more about a tying many aspects. So, what we have been discussing is a solution approach which has the essential properties of CP/DP separation, aspect of optimized/stateless data plane, application specific gateway allocations .. etc and that at the end is an approach for realizing DMM. Sri On 7/17/14 10:59 AM, Alper Yegin alper.ye...@yegin.org wrote: Intense readingŠ :-) Lot of abstractions, which I can only follow by relating to specific solutions. In my understanding, what Sri is describing is about how to apply UP/CP separation to various DMM solutions. In the examples I see a number of DMM solutions defined with UP/CP separation using Sri's terminology (e.g., per-flow mobility, access network anchoring, host-specific route based solutions, etc). So, it's not a solution by itself, but it's an approach that can be applied to various solution techniques to SDNize them. And that indeed has value. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] demand for DMM traffic steering
Hi Pierrick, Using the term Anchor in Access DPA is not a minor issue IMHO, because it implicitly assimilates anchoring and traffic redirection function. I'm fine with the removal of the Anchor term from the Access DPA. Access Gateway, Data Plane Redirection function ..(except Locator or any terms which ties the architecture to a specific protocol) is fine to me. Now, let’s consider the example above: the UE initiates a first IP flow , flow#1,using the address obtained from the DPA of its current access (DPA#1), i.e. using the local address… Here, no mobility support, no DPR coming into play… . Then the UE attaches to a new access, i.e. changes the first-hop router, and obtain an IP address from the DPA of the new access ( DPA#2). Flow#1 remains anchored to DPA#1 and dataplane is updated to the DPR of the new access. The DPR may, or may not, be supported by the first-hop router of the new access. The DPR may, or may not be collocated with the DPA function. Then the UE intiates a second flow, flow#2, with address obtained from DPA#2 as source address. The UE is thus served by two DPAs, each handling their own mobility sessions; mobility functions are DPA#1 and DPR for flow#1 and only DPA#2 for flow#2. What I want to stress here is 1) a UE can be served by more than one home DPA and 2) the DPR function comes into play only when mobility support is required, i.e. when the UE attaches to a new first-hop router. Sure. One conclusions: #1: Agree. A UE can be served by more than two home DPA's. I thought this is the same example I gave as well. This is where the gateway selection on Application basis comes into picture. #2. Agree. I said earlier, 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 ... Access DPS function is not needed when the access gateway where to MN is attached too serves as its Home DPA. But, while I agree with the conclusions I'm not following this comment. The DPR may, or may not, be supported by the first-hop router of the new access. The DPR may, or may not be collocated with the DPA function. We do need some function in the access gateway which can ensure the traffic for the first flow reaches its home. That interface could be Routing infra, Open Flow .. but some magic needs to happen there. Regards Sri From: pierrick.se...@orange.commailto:pierrick.se...@orange.com pierrick.se...@orange.commailto:pierrick.se...@orange.com Date: Thursday, July 17, 2014 2:48 AM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com, Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu, Hirschman, Brent B [CTO] brent.hirsch...@sprint.commailto:brent.hirsch...@sprint.com, Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Cc: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: RE: [DMM] demand for DMM traffic steering Hi, Just to be sure that we are on the same page…. De : dmm [mailto:dmm-boun...@ietf.org] De la part de Sri Gundavelli (sgundave) Envoyé : jeudi 17 juillet 2014 06:37 À : Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin Cc : dmm@ietf.orgmailto:dmm@ietf.org Objet : 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), [PS] Access DPA and Home DPA should be considered as different network functions and not be confused with network entities. Using the term Anchor in Access DPA is not a minor issue IMHO, because it implicitly assimilates anchoring and traffic redirection function. Actually, we should talk about DPA, i.e. the node where IP address are topologically correct and data plane
Re: [DMM] demand for DMM traffic steering
Sri, PMIP is a solution. You can apply SDN approach to it by splitting CP and DP. For example, a draft like draft-bernardos-dmm-pmip-03 talks about access network anchoring. And you can apply SDN to it (as you already mentioned jun your examples on this thread), or not. Alper On Jul 17, 2014, at 9:21 PM, Sri Gundavelli (sgundave) wrote: I do not know your definition of approach vs solution, but one can argue DMM itself is about a deployment model and an approach. I always insisted its less of a protocol work and more about a tying many aspects. So, what we have been discussing is a solution approach which has the essential properties of CP/DP separation, aspect of optimized/stateless data plane, application specific gateway allocations .. etc and that at the end is an approach for realizing DMM. Sri On 7/17/14 10:59 AM, Alper Yegin alper.ye...@yegin.org wrote: Intense readingŠ :-) Lot of abstractions, which I can only follow by relating to specific solutions. In my understanding, what Sri is describing is about how to apply UP/CP separation to various DMM solutions. In the examples I see a number of DMM solutions defined with UP/CP separation using Sri's terminology (e.g., per-flow mobility, access network anchoring, host-specific route based solutions, etc). So, it's not a solution by itself, but it's an approach that can be applied to various solution techniques to SDNize them. And that indeed has value. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] WG adoption (was Re: DMM solution space)
On Jul 17, 2014, at 9:11 PM, Sri Gundavelli (sgundave) wrote: I'm in favor of this approach. This was my suggestion as well in the past (when we presented prefix coloring spec) to move forward some documents. But, those should be documents which are considered common across multiple solution approaches. Obviously. And that's the case in this particular instance. Recapping the DMM solution space analysis below. Per-flow IP address configuration according to mobility needs Apps indicating their mobility needs to the IP stack on the MN, and associated IP configuration signaling between the MN and the network. draft-bhandari-dhc-class-based-prefix-03 draft-korhonen-dmm-prefix-properties-00.txt draft-yegin-dmm-ondemand-mobility-02 Mobility solution selection MN determining the type of mobility solution(s) it'd apply to a given flow. draft-yegin-ip-mobility-orchestrator-00 IP anchor selection MN selecting the IP anchor node after it decides to use IP anchoring (whether in the access network or the core network). draft-aliahmad-dmm-anchor-selection-00.txt Access network anchoring Anchoring IP address within the access network using IP-in-IP tunneling. draft-bernardos-dmm-cmip-01 draft-bernardos-dmm-pmip-03 draft-bernardos-dmm-distributed-anchoring-04 draft-chan-dmm-enhanced-mobility-anchoring-00 draft-sarikaya-dmm-for-wifi-00.txt draft-seite-dmm-dma-07.txt draft-xuan-dmm-nemo-dmm-02.txt Corresponding node/network anchoring Anchoring IP address on the Corresponding Node or Corresponding Network. Mobile IPv6 route optimization draft-yegin-dmm-cnet-homing-02 draft-xiong-dmm-ip-reachability-01 Host-route based intra-domain solutions Non-tunneling solutions. draft-chan-dmm-enhanced-mobility-anchoring-00 draft-matsushima-stateless-uplane-vepc-02 draft-mccann-dmm-flatarch-00 Alper The issue seems to be charter approval. Sri On 7/17/14 11:04 AM, Alper Yegin alper.ye...@yegin.org wrote: Why? Why not make technical progress at every opportunity? This extreme serialization and every step overly stretchingŠ. am I the only one having issue with the slow progress? Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] demand for DMM traffic steering
Sri, You SDNize a solution, then co-locate two entities, and voila the mobility protocol vanishes, and all that's left is OpenFlow. That's why there's no mobility protocol in that picture. It'd really be good if we see your solution documented, it's not easy to fully grasp it in a QA style. (I'm saying this to save us energy. If we read your I-D, we can all see how it meets the requirements. Otherwise, we are going to have to ask about them and have lengthy discussions to understand things). Alper On Jul 17, 2014, at 10:51 PM, Sri Gundavelli (sgundave) wrote: Alper, There is no mobility protocol here in this below deployment modek. Mobility protocol based on GTP/PMIP comes into the second case when we introduce the access and the home network based separation. In a flat model, its just a SDN interface between the CP and DP functions. But, the way we perform gateway selection, allocate application specific gateways, migrate a data plane session, allow UE the gateway indicators ..it meets every single DMM requirement that we have discussed in this group and with the side-affect of realizing CP/DP separation. CA18E534-121E-4582-90A4-14AA394AEDEE.png Sri From: Alper Yegin alper.ye...@yegin.org Date: Thursday, July 17, 2014 12:39 PM To: Sri Gundavelli sgund...@cisco.com Cc: Marco Liebsch marco.lieb...@neclab.eu, dmm@ietf.org dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Sri, PMIP is a solution. You can apply SDN approach to it by splitting CP and DP. For example, a draft like draft-bernardos-dmm-pmip-03 talks about access network anchoring. And you can apply SDN to it (as you already mentioned jun your examples on this thread), or not. Alper On Jul 17, 2014, at 9:21 PM, Sri Gundavelli (sgundave) wrote: I do not know your definition of approach vs solution, but one can argue DMM itself is about a deployment model and an approach. I always insisted its less of a protocol work and more about a tying many aspects. So, what we have been discussing is a solution approach which has the essential properties of CP/DP separation, aspect of optimized/stateless data plane, application specific gateway allocations .. etc and that at the end is an approach for realizing DMM. Sri On 7/17/14 10:59 AM, Alper Yegin alper.ye...@yegin.org wrote: Intense readingŠ :-) Lot of abstractions, which I can only follow by relating to specific solutions. In my understanding, what Sri is describing is about how to apply UP/CP separation to various DMM solutions. In the examples I see a number of DMM solutions defined with UP/CP separation using Sri's terminology (e.g., per-flow mobility, access network anchoring, host-specific route based solutions, etc). So, it's not a solution by itself, but it's an approach that can be applied to various solution techniques to SDNize them. And that indeed has value. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] WG adoption (was Re: DMM solution space)
Hi Alper, draft-sarikaya-dmm-for-wifi- 00.txt does not use anchoring, I don't know how many times I should tell? It simply extends vEPC, so it should be classified wherever vEPC is classified, and I don't care where. Regards, Behcet On Thu, Jul 17, 2014 at 2:45 PM, Alper Yegin alper.ye...@yegin.org wrote: On Jul 17, 2014, at 9:11 PM, Sri Gundavelli (sgundave) wrote: I'm in favor of this approach. This was my suggestion as well in the past (when we presented prefix coloring spec) to move forward some documents. But, those should be documents which are considered common across multiple solution approaches. Obviously. And that's the case in this particular instance. Recapping the DMM solution space analysis below. Per-flow IP address configuration according to mobility needs Apps indicating their mobility needs to the IP stack on the MN, and associated IP configuration signaling between the MN and the network. draft-bhandari-dhc-class-based-prefix-03 draft-korhonen-dmm-prefix-properties-00.txt draft-yegin-dmm-ondemand-mobility-02 Mobility solution selection MN determining the type of mobility solution(s) it'd apply to a given flow. draft-yegin-ip-mobility-orchestrator-00 IP anchor selection MN selecting the IP anchor node after it decides to use IP anchoring (whether in the access network or the core network). draft-aliahmad-dmm-anchor-selection-00.txt Access network anchoring Anchoring IP address within the access network using IP-in-IP tunneling. draft-bernardos-dmm-cmip-01 draft-bernardos-dmm-pmip-03 draft-bernardos-dmm-distributed-anchoring-04 draft-chan-dmm-enhanced-mobility-anchoring-00 draft-sarikaya-dmm-for-wifi-00.txt draft-seite-dmm-dma-07.txt draft-xuan-dmm-nemo-dmm-02.txt Corresponding node/network anchoring Anchoring IP address on the Corresponding Node or Corresponding Network. Mobile IPv6 route optimization draft-yegin-dmm-cnet-homing-02 draft-xiong-dmm-ip-reachability-01 Host-route based intra-domain solutions Non-tunneling solutions. draft-chan-dmm-enhanced-mobility-anchoring-00 draft-matsushima-stateless-uplane-vepc-02 draft-mccann-dmm-flatarch-00 Alper The issue seems to be charter approval. Sri On 7/17/14 11:04 AM, Alper Yegin alper.ye...@yegin.org wrote: Why? Why not make technical progress at every opportunity? This extreme serialization and every step overly stretchingŠ. am I the only one having issue with the slow progress? Alper ___ 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
Re: [DMM] demand for DMM traffic steering
Alper, What we broadly agreed in Nov/Mar IETF's (based on offline discussion) to go with a design group approach. Approach of Individual I-D's, comparing them, selecting the best will go no where, IMO. There are like dozen proposal on the table. With that goal in mind we have had several conf calls (with smaller group of folks) in Jan time frame. What we discussed there and in f2f meetings was summarized in IETF 89 WG slides. Off course, that does not give it a WG status, but the goal is to come to some agreement on the approach and then document the approach. Fair comment on lack of details and that its at a high-level. The discussion is purposely kept at a high-level and we need to work out the details. We should have more formal design meetings and if we converge, we should then write a I-D(s). Sri From: Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Date: Thursday, July 17, 2014 1:06 PM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com Cc: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu, dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Sri, You SDNize a solution, then co-locate two entities, and voila the mobility protocol vanishes, and all that's left is OpenFlow. That's why there's no mobility protocol in that picture. It'd really be good if we see your solution documented, it's not easy to fully grasp it in a QA style. (I'm saying this to save us energy. If we read your I-D, we can all see how it meets the requirements. Otherwise, we are going to have to ask about them and have lengthy discussions to understand things). Alper On Jul 17, 2014, at 10:51 PM, Sri Gundavelli (sgundave) wrote: Alper, There is no mobility protocol here in this below deployment modek. Mobility protocol based on GTP/PMIP comes into the second case when we introduce the access and the home network based separation. In a flat model, its just a SDN interface between the CP and DP functions. But, the way we perform gateway selection, allocate application specific gateways, migrate a data plane session, allow UE the gateway indicators ..it meets every single DMM requirement that we have discussed in this group and with the side-affect of realizing CP/DP separation. CA18E534-121E-4582-90A4-14AA394AEDEE.png Sri From: Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Date: Thursday, July 17, 2014 12:39 PM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com Cc: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu, dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Sri, PMIP is a solution. You can apply SDN approach to it by splitting CP and DP. For example, a draft like draft-bernardos-dmm-pmip-03 talks about access network anchoring. And you can apply SDN to it (as you already mentioned jun your examples on this thread), or not. Alper On Jul 17, 2014, at 9:21 PM, Sri Gundavelli (sgundave) wrote: I do not know your definition of approach vs solution, but one can argue DMM itself is about a deployment model and an approach. I always insisted its less of a protocol work and more about a tying many aspects. So, what we have been discussing is a solution approach which has the essential properties of CP/DP separation, aspect of optimized/stateless data plane, application specific gateway allocations .. etc and that at the end is an approach for realizing DMM. Sri On 7/17/14 10:59 AM, Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org wrote: Intense readingŠ :-) Lot of abstractions, which I can only follow by relating to specific solutions. In my understanding, what Sri is describing is about how to apply UP/CP separation to various DMM solutions. In the examples I see a number of DMM solutions defined with UP/CP separation using Sri's terminology (e.g., per-flow mobility, access network anchoring, host-specific route based solutions, etc). So, it's not a solution by itself, but it's an approach that can be applied to various solution techniques to SDNize them. And that indeed has value. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] WG adoption (was Re: DMM solution space)
The list is still missing draft-korhonen-dmm-local-prefix-01. - Jouni 7/17/2014 10:45 PM, Alper Yegin kirjoitti: On Jul 17, 2014, at 9:11 PM, Sri Gundavelli (sgundave) wrote: I'm in favor of this approach. This was my suggestion as well in the past (when we presented prefix coloring spec) to move forward some documents. But, those should be documents which are considered common across multiple solution approaches. Obviously. And that's the case in this particular instance. Recapping the DMM solution space analysis below. *Per-flow IP address configuration according to mobility needs* Apps indicating their mobility needs to the IP stack on the MN, and associated IP configuration signaling between the MN and the network. draft-bhandari-dhc-class-based-prefix-03 draft-korhonen-dmm-prefix-properties-00.txt draft-yegin-dmm-ondemand-mobility-02 *Mobility solution selection * MN determining the type of mobility solution(s) it'd apply to a given flow. draft-yegin-ip-mobility-orchestrator-00 *IP anchor selection* MN selecting the IP anchor node after it decides to use IP anchoring (whether in the access network or the core network). draft-aliahmad-dmm-anchor-selection-00.txt *Access network anchoring* Anchoring IP address within the access network using IP-in-IP tunneling. draft-bernardos-dmm-cmip-01 draft-bernardos-dmm-pmip-03 draft-bernardos-dmm-distributed-anchoring-04 draft-chan-dmm-enhanced-mobility-anchoring-00 draft-sarikaya-dmm-for-wifi-00.txt draft-seite-dmm-dma-07.txt draft-xuan-dmm-nemo-dmm-02.txt *Corresponding node/network anchoring* Anchoring IP address on the Corresponding Node or Corresponding Network. Mobile IPv6 route optimization draft-yegin-dmm-cnet-homing-02 draft-xiong-dmm-ip-reachability-01 *Host-route based intra-domain solutions* Non-tunneling solutions. draft-chan-dmm-enhanced-mobility-anchoring-00 draft-matsushima-stateless-uplane-vepc-02 draft-mccann-dmm-flatarch-00 Alper The issue seems to be charter approval. Sri On 7/17/14 11:04 AM, Alper Yegin alper.ye...@yegin.org mailto:alper.ye...@yegin.org wrote: Why? Why not make technical progress at every opportunity? This extreme serialization and every step overly stretchingŠ. am I the only one having issue with the slow progress? Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
