[DMM] [FPSM] Friday's WebEx call
Please find below the WebEx info for tomorrow's FPSM call. I put the following items on the agenda: () Confirmation of IETF91 discussion and received advice () Synergies with other IETF activity () FPSM data model () Next steps () Chat about.. Expectation from concrete protocol implementations (if time permits) () Chat about.. Deployment models (if time permits) () Usual AoB for the year's end.. :) marco Topic: DMM Date: Friday, December 19, 2014 Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00) Meeting Number: 200 916 187 Password: dmm --- To join the meeting online(Now from mobile devices!) --- 1. Go to https://cisco.webex.com/ciscosales/j.php?MTID=mc842327a99d63e82b748e4dfebed a664 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: dmm 4. Click Join. 5. If the meeting includes a teleconference, follow the instructions that appear on your screen. --- To join the audio conference only --- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll number (US/Canada): +1-408-525-6800 Call-in toll-free number (US/Canada): +1-866-432-9903 Having trouble dialing in? Try these backup numbers: Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Access code:200 916 187 Global call-in numbers: https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MCED=29675 6737tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf CCP:+14085256800x200916187# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment
Hi Pierrick, thanks for the feedback. Agree that we can avoid the anchor term, since there is always some expectation on such node. DPE is good, or simply Data-Plane Node (DPN), as we where using it in the past discussion. No strong opinion here. The WG may still need to converge on a definition of the term 'anchor', though it depends solely on the policies being configured and enforced by a data-plane node. The work team on Advanced Anchor selection started to investigate on this. Point for the FPSM work is that it's the deployment and configuration which can make an anchor out of a data-plane node, not a specification and the architecture behind. marco From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com] Sent: Donnerstag, 18. Dezember 2014 15:10 To: dmm@ietf.org; Marco Liebsch Subject: Re: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment Hi Marco, I definitely agree that a DP node can play different role; quoting the PMIP example, a node can play either à MAG or LMA role, or even both rôles. A single name thus makes sense. However, the term anchor is à bit confusing since it refers implicitely to HA/ LMA. So, i suggest to use DPE node, standing for data plane enfoncement node. The DPE can support different functions: tunnel termination, encap, etc Pierrick Envoyé depuis mon Sony Xperia SP d'Orange Marco Liebsch a écrit Folks, at IETF91 we received the valid comment to converge on a definition of the term 'anchor'. In the FPSM discussion, we so far distinguished Data-Plane Anchor (DPA), traditionally a downlink encap function, Data-Plane Node (DPN), which is more located in the access to terminate tunnels, and regular transport nodes. Another comment was about a scenario where a single flow may traverse multiple DPAs on its way to the MN. I'd like to propose and discuss the following: In a decentralized data-plane and a control-/data-plane separated deployment, I consider it a reasonable assumption that each of the so far unambiguously named data-plane nodes can take the role of the other. So, we may solely refer to a single type of function, e.g. Data-Plane Anchor (DPA), which receives policies from the Control-Plane. For a certain deployment, it's the Control-Plane that determines the role and associated policies for each involved DPA. Data-Plane nodes are agnostic to the role they play in mobility management. Control-Plane determines the role of each DPA according to the preferred deployment and configures the policies accordingly. I think such assumption allows flexible deployment and eases description in our specifications. I am not good in drawing ASCII, but I gave it a try (for downlink operation only). Using PMIP6 terms, the middle-DPA in the figure below serves as kind of LMA, left DPA as MAG, right DPA (one or multiple) may enforce per-host rules for traffic steering. Would be happy to get your opinion on this proposal. marco +--+ | Control-Plane | +--+ | | | | | | | | | \ /V V V +--+ -o- +---+ +---+ +---+ +--+ |MN| |---|DPA||DPA||DPA|--|CN| +--+ | +---+ +---+ +---+ +--+ Rules: Rules: Rules: Decap, Encap, host-route Forward Forward, qos _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment
De : Marco Liebsch [mailto:marco.lieb...@neclab.eu] Envoyé : jeudi 18 décembre 2014 15:45 À : SEITE Pierrick IMT/OLN; dmm@ietf.org Objet : RE: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment Hi Pierrick, thanks for the feedback. Agree that we can avoid the anchor term, since there is always some expectation on such node. DPE is good, or simply Data-Plane Node (DPN), as we where using it in the past discussion. No strong opinion here. [PS] me too... no strong opinion ... I was just trying to reflect the fact that the DPN is the enforcement point of the control plane decision ... The WG may still need to converge on a definition of the term 'anchor', though it depends solely on the policies being configured and enforced by a data-plane node. The work team on Advanced Anchor selection started to investigate on this. Point for the FPSM work is that it's the deployment and configuration which can make an anchor out of a data-plane node, not a specification and the architecture behind. marco From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com] Sent: Donnerstag, 18. Dezember 2014 15:10 To: dmm@ietf.org; Marco Liebsch Subject: Re: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment Hi Marco, I definitely agree that a DP node can play different role; quoting the PMIP example, a node can play either à MAG or LMA role, or even both rôles. A single name thus makes sense. However, the term anchor is à bit confusing since it refers implicitely to HA/ LMA. So, i suggest to use DPE node, standing for data plane enfoncement node. The DPE can support different functions: tunnel termination, encap, etc Pierrick Envoyé depuis mon Sony Xperia SP d'Orange Marco Liebsch a écrit Folks, at IETF91 we received the valid comment to converge on a definition of the term 'anchor'. In the FPSM discussion, we so far distinguished Data-Plane Anchor (DPA), traditionally a downlink encap function, Data-Plane Node (DPN), which is more located in the access to terminate tunnels, and regular transport nodes. Another comment was about a scenario where a single flow may traverse multiple DPAs on its way to the MN. I'd like to propose and discuss the following: In a decentralized data-plane and a control-/data-plane separated deployment, I consider it a reasonable assumption that each of the so far unambiguously named data-plane nodes can take the role of the other. So, we may solely refer to a single type of function, e.g. Data-Plane Anchor (DPA), which receives policies from the Control-Plane. For a certain deployment, it's the Control-Plane that determines the role and associated policies for each involved DPA. Data-Plane nodes are agnostic to the role they play in mobility management. Control-Plane determines the role of each DPA according to the preferred deployment and configures the policies accordingly. I think such assumption allows flexible deployment and eases description in our specifications. I am not good in drawing ASCII, but I gave it a try (for downlink operation only). Using PMIP6 terms, the middle-DPA in the figure below serves as kind of LMA, left DPA as MAG, right DPA (one or multiple) may enforce per-host rules for traffic steering. Would be happy to get your opinion on this proposal. marco +--+ | Control-Plane | +--+ | | | | | | | | | \ /V V V +--+ -o- +---+ +---+ +---+ +--+ |MN| |---|DPA||DPA||DPA|--|CN| +--+ | +---+ +---+ +---+ +--+ Rules: Rules: Rules: Decap, Encap, host-route Forward Forward, qos _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
Re: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment
Marco, Should some of this discussion on terminology be part of the other arch/deployment spec ? We should use a consist terminology across all of these 4 documents. I think the discussions we have had early this year on the DMM functional entities, terminology and the deployment models should still be applicable here. Regards Sri From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu Date: Thursday, December 18, 2014 3:03 AM To: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment Folks, at IETF91 we received the valid comment to converge on a definition of the term ‘anchor’. In the FPSM discussion, we so far distinguished Data-Plane Anchor (DPA), traditionally a downlink encap function, Data-Plane Node (DPN), which is more located in the access to terminate tunnels, and regular transport nodes. Another comment was about a scenario where a single flow may traverse multiple DPAs on its way to the MN. I’d like to propose and discuss the following: In a decentralized data-plane and a control-/data-plane separated deployment, I consider it a reasonable assumption that each of the so far unambiguously named data-plane nodes can take the role of the other. So, we may solely refer to a single type of function, e.g. Data-Plane Anchor (DPA), which receives policies from the Control-Plane. For a certain deployment, it’s the Control-Plane that determines the role and associated policies for each involved DPA. Data-Plane nodes are agnostic to the role they play in mobility management. Control-Plane determines the role of each DPA according to the preferred deployment and configures the policies accordingly. I think such assumption allows flexible deployment and eases description in our specifications. I am not good in drawing ASCII, but I gave it a try (for downlink operation only). Using PMIP6 terms, the middle-DPA in the figure below serves as kind of LMA, left DPA as MAG, right DPA (one or multiple) may enforce per-host rules for traffic steering. Would be happy to get your opinion on this proposal. marco +--+ | Control-Plane | +--+ | | | | | | | | | \ /V V V +--+ -o- +---+ +---+ +---+ +--+ |MN| |---|DPA||DPA||DPA|--|CN| +--+ | +---+ +---+ +---+ +--+ Rules: Rules: Rules: Decap, Encap, host-route Forward Forward, qos ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment
Sri, I agree that some of the discussion is related to the deployment document. On the other hand, for the specs about the interface between Control-/Data-Plane, which is what the FPSM topic is about, the differentiation of data-plane functional entities does not matter, since the characteristics associated with the functional entity comes with the policy configuration. Assuming a single type of data-plane node simplifies the FPSM specification, IMO. marco From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Donnerstag, 18. Dezember 2014 18:11 To: Marco Liebsch; dmm@ietf.org Subject: Re: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment Marco, Should some of this discussion on terminology be part of the other arch/deployment spec ? We should use a consist terminology across all of these 4 documents. I think the discussions we have had early this year on the DMM functional entities, terminology and the deployment models should still be applicable here. Regards Sri From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu Date: Thursday, December 18, 2014 3:03 AM To: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment Folks, at IETF91 we received the valid comment to converge on a definition of the term 'anchor'. In the FPSM discussion, we so far distinguished Data-Plane Anchor (DPA), traditionally a downlink encap function, Data-Plane Node (DPN), which is more located in the access to terminate tunnels, and regular transport nodes. Another comment was about a scenario where a single flow may traverse multiple DPAs on its way to the MN. I'd like to propose and discuss the following: In a decentralized data-plane and a control-/data-plane separated deployment, I consider it a reasonable assumption that each of the so far unambiguously named data-plane nodes can take the role of the other. So, we may solely refer to a single type of function, e.g. Data-Plane Anchor (DPA), which receives policies from the Control-Plane. For a certain deployment, it's the Control-Plane that determines the role and associated policies for each involved DPA. Data-Plane nodes are agnostic to the role they play in mobility management. Control-Plane determines the role of each DPA according to the preferred deployment and configures the policies accordingly. I think such assumption allows flexible deployment and eases description in our specifications. I am not good in drawing ASCII, but I gave it a try (for downlink operation only). Using PMIP6 terms, the middle-DPA in the figure below serves as kind of LMA, left DPA as MAG, right DPA (one or multiple) may enforce per-host rules for traffic steering. Would be happy to get your opinion on this proposal. marco +--+ | Control-Plane | +--+ | | | | | | | | | \ /V V V +--+ -o- +---+ +---+ +---+ +--+ |MN| |---|DPA||DPA||DPA|--|CN| +--+ | +---+ +---+ +---+ +--+ Rules: Rules: Rules: Decap, Encap, host-route Forward Forward, qos ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment
Is there such a thing? I did not know that. What thing ? There are 4 work items that we discussed and that the chairs are tracking. One of the work item is Architectural/Deployment considerations. Please refer to presentations in IETF90 and IETF89. Also, there were two f2f discussions during IETF 88, IETF 89 and also couple of conf calls early this year. Regards Sri On 12/18/14 9:28 AM, Behcet Sarikaya sarikaya2...@gmail.com wrote: On Thu, Dec 18, 2014 at 11:10 AM, Sri Gundavelli (sgundave) sgund...@cisco.com wrote: Marco, Should some of this discussion on terminology be part of the other arch/deployment spec ? Is there such a thing? I did not know that. Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
