RE: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Hi all, I concur with both parts of Dave's message :-( and support publication of the draft. I have an editorial/factual comment regarding Section 4.2 of the draft. Let's begin with the fact that SAToP (i.e. RFC 4553) is not a Draft Standard, it is a Proposed Standard RFC. Further, I am not sure that the relationship between SAToP and other TDM PW modes - CESoPSN (RFC 5086) and TDMoIP (RFC 5087) - is correctly described in Section 4.2 of the draft. At least neither RFC 5086 not RFC 5087 contain any explicit statements about SAToP as the MUST to implement protocol. My 2c, Sasha From: mpls-boun...@ietf.org [mpls-boun...@ietf.org] On Behalf Of David Allan I [david.i.al...@ericsson.com] Sent: Thursday, October 06, 2011 1:05 AM To: ietf@ietf.org; m...@ietf.org Subject: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: unresolved technical concerns
Dear Alessandro, Lots of thanks for a prompt response. Unfortunately your response does not really help (at least, me) to identify even a single specific technical issue. You may attribute it to my faulty memory, but I could not remember any. Presenting these cocerns in the form of an I-D as suggested by Stewart would be the right first step. My 2c Sasha From: D'Alessandro Alessandro Gerardo [alessandro.dalessan...@telecomitalia.it] Sent: Wednesday, October 05, 2011 6:54 PM To: stbry...@cisco.com; Alexander Vainshtein Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org Subject: unresolved technical concerns Dear Stewart, Dear Sasha, I think there are already enough contributions in that direction I (with many other experts) contributed to in the form of IETF mailing list discussion and ITU-T liaisons. Unfortunately I regret to say that some questions for clarification and concerns risen in those emails (for sure some of mine) still remain without an answer. At the same time, some comments provided by ITU-T liaisons still remain unresolved. Best regards, Alessandro -- Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -Messaggio originale- Da: Stewart Bryant [mailto:stbry...@cisco.com] Inviato: mercoledì 5 ottobre 2011 12:24 A: D'Alessandro Alessandro Gerardo Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org Oggetto: Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these major unresolved technical concerns so that we can all understand them. Such a draft needs to be technical, and describe the actions that the network operator is unable to perform, or the fault cases that they are unable to diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, you need to tell the community what it is. I believe that this request has been made a number of times, in various forums, and, as far as I know, no document has yet been produced. An argument of the form you must standardize what I want will not fly. What is needed is a very clear technical definition of the issue(s). When we have the major unresolved technical concerns on the table, we will be in a position to determine the best disposition of those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Alessandro, Stewart and all, I concur with Stewart: please write a draft detailing your major technical concerns. I'd like to add a quote from Malcolm's presentation at the IETF meeting in Prague: Differences between the solution approved by the IETF and its ITU-T sponsored alternatives - Sasha are close to invisible at the level of the requirements in RFC5860. Just to remind you that RFC 5680 is the MPLS-TP OAM requirements document. Malcolm has also said: Many of the issues only become apparent when the protocol and equipment behavior isexplored but, AFAIK, these issues have never been explicitly brought for the consideration. My 2c, Sasha -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, October 05, 2011 12:24 PM To: D'Alessandro Alessandro Gerardo Cc: ietf@ietf.org; m...@ietf.org Subject: Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam- considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these major unresolved technical concerns so that we can all understand them. Such a draft needs to be technical, and describe the actions that the network operator is unable to perform, or the fault cases that they are unable to diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, you need to tell the community what it is. I believe that this request has been made a number of times, in various forums, and, as far as I know, no document has yet been produced. An argument of the form you must standardize what I want will not fly. What is needed is a very clear technical definition of the issue(s). When we have the major unresolved technical concerns on the table, we will be in a position to determine the best disposition of those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC
Luca, and all, I concur with Andy's opinion that the reference to RFC 4447 must become Normative (this will not delay the publication is too often the case:-). As for Informational vs. Historical, I think that Informational is more appropriate because, AFAIK, the technique defined in draft-kompella is not just a documenting an existing solution - it describes is THE ONLY deployed solution for the problem. (If this statement happens to be factually incorrect, I would be happy to learn about the deployed alternatives.) Regards, Sasha -Original Message- From: l2vpn-boun...@ietf.org [mailto:l2vpn-boun...@ietf.org] On Behalf Of Luca Martini Sent: Tuesday, September 13, 2011 6:24 PM To: Andrew G. Malis Cc: l2...@ietf.org; pwe3; IETF Discussion Subject: Re: Last Call: draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC I concurr with Andy. Given that the WG has made a decision on which control plane technology is the standard track technology we should have a statement in this document pointing to the standard track rfc4447 so it is clear to anyone reading the document. In the same way we published the draft-martini documents as historical ee should publish this document as historical rfc, to document existing implementations. Luca On 09/01/11 05:42, Andrew G. Malis wrote: Speaking as an individual, the solution in this draft has been has been operationally deployed in a number of service provider networks, and it should be documented in an informational RFC. Speaking as PWE3 co-chair, I would be happier if this draft required that routers that implement this solution also implement RFC 4447, that RFC 4447 be configured as the default mechanism for pseudowire signaling, and that RFC 4447 was moved from an informational to a normative reference. In practice, I know that routers that implement this also do implement RFC 4447, but I would like to see it in the RFC as well. Thanks, Andy Subject:Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Date: Tue, 30 Aug 2011 10:50:05 -0700 From: The IESG iesg-secret...@ietf.org mailto:iesg-secret...@ietf.org Reply-To: ietf@ietf.org mailto:ietf@ietf.org To: IETF-Announce ietf-annou...@ietf.org mailto:ietf-annou...@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling' draft-kompella-l2vpn-l2vpn-07.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailto:ietf@ietf.org mailing lists by 2011-09-27. Exceptionally, comments may be sent to i...@ietf.org mailto:i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type, and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional Layer 2 VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs and the Internet, as well as a common provisioning methodology for all services. The file can be obtained via http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1149/ ___ IETF-Announce mailing list ietf-annou...@ietf.org mailto:ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all
RE: Last Call: draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC
Luca, The draft in question exists for almost 8 years (the -00 version has been posted 2004-01-13), has been implemented and deployed. I have not heard that solutions compliant with RFC 6074 (which is the proper analog of 4447 in this case IMO) have been deployed in this interval - and that in spite of 6074 sitting in the RFC Editor queue (i.e., sufficiently stable for any potential implementer) for almost 6 years (from 2006-06-12). Hence I do not see this case as similar to what happened to the original draft-martini vs. RFC 4447. Do I miss something substantial here? Regards, Sasha From: Luca Martini [lmart...@cisco.com] Sent: Tuesday, September 13, 2011 9:16 PM To: Alexander Vainshtein Cc: l2...@ietf.org; pwe3; IETF Discussion; Andrew G. Malis Subject: Re: Last Call: draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC On 09/13/11 10:03, Alexander Vainshtein wrote: Luca, and all, I concur with Andy's opinion that the reference to RFC 4447 must become Normative (this will not delay the publication is too often the case:-). As for Informational vs. Historical, I think that Informational is more appropriate because, AFAIK, the technique defined in draft-kompella is not just a documenting an existing solution - it describes is THE ONLY deployed solution for the problem. (If this statement happens to be factually incorrect, I would be happy to learn about the deployed alternatives.) no, there are several ( I think 3 ) implementations of the l2vpn-singalling standards track document also known as rfc6074. There are several deployments of rfc6074. As 10 years ago we had several deployments of draft-martini which over time are being updated to rfc4447 , there are some deployments of the solution described in the draft-kompella-l2vpn-l2vpn-07.txt. I still think that an historical RFC would fit this solution , unless we plan on expanding it , and pursuing new enhancements to it. Luca Regards, Sasha -Original Message- From: l2vpn-boun...@ietf.org [mailto:l2vpn-boun...@ietf.org] On Behalf Of Luca Martini Sent: Tuesday, September 13, 2011 6:24 PM To: Andrew G. Malis Cc: l2...@ietf.org; pwe3; IETF Discussion Subject: Re: Last Call: draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC I concurr with Andy. Given that the WG has made a decision on which control plane technology is the standard track technology we should have a statement in this document pointing to the standard track rfc4447 so it is clear to anyone reading the document. In the same way we published the draft-martini documents as historical ee should publish this document as historical rfc, to document existing implementations. Luca On 09/01/11 05:42, Andrew G. Malis wrote: Speaking as an individual, the solution in this draft has been has been operationally deployed in a number of service provider networks, and it should be documented in an informational RFC. Speaking as PWE3 co-chair, I would be happier if this draft required that routers that implement this solution also implement RFC 4447, that RFC 4447 be configured as the default mechanism for pseudowire signaling, and that RFC 4447 was moved from an informational to a normative reference. In practice, I know that routers that implement this also do implement RFC 4447, but I would like to see it in the RFC as well. Thanks, Andy Subject:Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Date: Tue, 30 Aug 2011 10:50:05 -0700 From: The IESG iesg-secret...@ietf.org mailto:iesg-secret...@ietf.org Reply-To: ietf@ietf.org mailto:ietf@ietf.org To: IETF-Announce ietf-annou...@ietf.org mailto:ietf-annou...@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling' draft-kompella-l2vpn-l2vpn-07.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailto:ietf@ietf.org mailing lists by 2011-09-27. Exceptionally, comments may be sent to i...@ietf.org mailto:i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider
RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Stewart, Lots of thanks for a prompt response. My original email contained a typo (S-PE instead of T-PE named as inserting ) which I've acknowledged and corrected in this thread (please see http://www.ietf.org/mail-archive/web/pwe3/current/msg12586.html). With this correction in mind, the example I've presented (an MS-PW that originates in a T-PE in a MPLS-TP domain and them crosses - at S-PE - into an IP/MPLS domain) matches, IMHO, Yaakov's question. And if the operator wishes to improve traffic distribution in the IP/MPLS domain which employs ECMP, flow labels would be inserted by T-PE. I believe that the change in draft-ietf-pwe3-gal-in-pw that you've proposed in http://www.ietf.org/mail-archive/web/pwe3/current/msg12613.html resolves the original issue I've raised of both GAL and flow label competing for the BoS position. However, a conceptual question - can any MPLS-TP restrictions be placed on PWs?- remains open as noted in Greg's comment (please see http://www.ietf.org/mail-archive/web/pwe3/current/msg12620.html). IMHO and FWIW we should acknowledge the fact (implicitly recognized already in RFC 5920) that there is simply no such thing as a MPLS-TP PW. Hopefully this note clarifies my position on the subject. Regards, and apologies for the original typo, Sasha From: Stewart Bryant [stbry...@cisco.com] Sent: Thursday, September 01, 2011 8:33 PM To: Alexander Vainshtein Cc: Yaakov Stein; m...@ietf.org; pwe3; i...@ietf.org; pwe3-cha...@tools.ietf.org; Luca Martini; IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw On 01/09/2011 17:07, Alexander Vainshtein wrote: Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the draft (for MS-PW) - please see my email (to several lists) that explains that in some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html. Regards, Sasha The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of flow labels at the two S-PEs. Speaking as an author of the FAT-PW draft I do not recall any text that proposes that S-PEs insert FLs in the stack, and it never occurred to me that anyone anyone would try, since would require a change to the design of the S-PEs. Stewart This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Matthew, Lots of thanks for a prompt response. Please see a couple of comments inline below. Regards, Sasha From: Bocci, Matthew (Matthew) [matthew.bo...@alcatel-lucent.com] Sent: Friday, September 02, 2011 1:06 PM To: Alexander Vainshtein; Stewart Bryant Cc: Yaakov Stein; m...@ietf.org; pwe3; i...@ietf.org; pwe3-cha...@tools.ietf.org; Luca Martini; IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Sasha, On your final comment on the concept of an MPLS-TP PW, RFC5586 has already made the distinction between the use of the GAL on PWs in MPLS-TP and in other MPLS environments. This draft aligns the two cases in terms of the applicability of the GAL, by updating RFC5586 to remove the restriction on its use and position in an MPLS-TP environment. [[Sasha]] IMHO and FWIW this is one more indication that there is no such thing as an MPLS-TP PW as different from an MPLS TP. Did I miss something important? The case of interconnecting PW segments on MPLS-TP to PW segments on general MPLS networks should be discussed elsewhere, IMHO, as the interaction between the GAL and hashing on some PW segments is most likely not the only issue. [[Sasha]] Sounds OK with me. RFC5921 rules out the use of ECMP in MPLS-TP networks, so one would not expect an MPLS-TP PSN to hash the flow label today. [[Sasha]] I make a distinction between inserting a flow label at T-PE and hashing on the label stack (or lack thereof) in some of the network domains that are crossed by the MS-PW packet. The hashing is done (or not done) by P routers that do not specifically care about PWs. If that is going to change or if there are other flow label applications in MPLS-TP, then IMHO drafts detailing those applications should discuss the interaction with the GAL. [[Sasha]] Please see above. IMHO there is no need for a new application to study the interaction. Regards, Matthew On 02/09/2011 06:05, Alexander Vainshtein alexander.vainsht...@ecitele.commailto:alexander.vainsht...@ecitele.com wrote: Stewart, Lots of thanks for a prompt response. My original email contained a typo (S-PE instead of T-PE named as inserting ) which I've acknowledged and corrected in this thread (please see http://www.ietf.org/mail-archive/web/pwe3/current/msg12586.html). With this correction in mind, the example I've presented (an MS-PW that originates in a T-PE in a MPLS-TP domain and them crosses - at S-PE - into an IP/MPLS domain) matches, IMHO, Yaakov's question. And if the operator wishes to improve traffic distribution in the IP/MPLS domain which employs ECMP, flow labels would be inserted by T-PE. I believe that the change in draft-ietf-pwe3-gal-in-pw that you've proposed inhttp://www.ietf.org/mail-archive/web/pwe3/current/msg12613.html resolves the original issue I've raised of both GAL and flow label competing for the BoS position. However, a conceptual question - can any MPLS-TP restrictions be placed on PWs?- remains open as noted in Greg's comment (please see http://www.ietf.org/mail-archive/web/pwe3/current/msg12620.html). IMHO and FWIW we should acknowledge the fact (implicitly recognized already in RFC 5920) that there is simply no such thing as a MPLS-TP PW. Hopefully this note clarifies my position on the subject. Regards, and apologies for the original typo, Sasha From: Stewart Bryant [stbry...@cisco.commailto:stbry...@cisco.com] Sent: Thursday, September 01, 2011 8:33 PM To: Alexander Vainshtein Cc: Yaakov Stein; m...@ietf.orgmailto:m...@ietf.org; pwe3; i...@ietf.orgmailto:i...@ietf.org; pwe3-cha...@tools.ietf.orgmailto:pwe3-cha...@tools.ietf.org; Luca Martini; IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw On 01/09/2011 17:07, Alexander Vainshtein wrote: Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the draft (for MS-PW) - please see my email (to several lists) that explains that in some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html. Regards, Sasha The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of flow labels at the two S-PEs. Speaking as an author of the FAT-PW draft I do not recall any text that proposes that S-PEs insert FLs in the stack, and it never occurred to me that anyone anyone would try, since would require a change to the design of the S-PEs. Stewart This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only
RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the draft (for MS-PW) - please see my email (to several lists) that explains that in some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html. Regards, Sasha From: mpls-boun...@ietf.org [mpls-boun...@ietf.org] On Behalf Of Yaakov Stein [yaako...@rad.com] Sent: Thursday, September 01, 2011 5:37 PM To: stbry...@cisco.com; Luca Martini; IETF Discussion Cc: m...@ietf.org; pwe3; i...@ietf.org; pwe3-cha...@tools.ietf.org Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Stewart Was this email meant to address my email to the IETF discussion list (from Tues 16 Aug) or just the discussion on MPLS and PWE lists ? It does to SOME extent, as it leaves open the possibility of the GAL not being at BoS; but it does not rule out that possibility either. However, you did not address my other final comment that a PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain. What does one do then ? (My email also identified a wording issue and what I consider to be a completely inaccurate explanation of what the draft is trying to accomplish.) Y(J)S From: pwe3-boun...@ietf.org [mailto:pwe3-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Tuesday, August 30, 2011 15:05 To: Luca Martini; IETF Discussion Cc: ietf@ietf.org; Vladimir Kleiner; m...@ietf.org; Idan Kaspit; Mishael Wexler; pwe3; i...@ietf.org; Oren Gal; John Shirron; pwe3-cha...@tools.ietf.org; Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Reviewing this discussion there are three components. 1) The update of RFC5586 to allow PW to use the GAL. 2) The PW OAM application that is to use the GAL. 3) The label stack structure when teh GAL is used with a PW This draft is only concerned with point 1 above. Points 2 and 3 need to be resolved in any PWE3 draft that describes the use of the GAL. To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01 - Section 4.2http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586http://tools.ietf.org/html/rfc5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack. = should be replaced by = - Section 4.2http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586http://tools.ietf.org/html/rfc5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. The presence of a GAL indicates that an ACH immediately follows the MPLS label stack. == - Stewart This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Stewart, I believe that your item #1 is presumably addressed by draft-ietf-pwe3-gal-in-pw (with the changes you've proposed), draft-nadeau-pwe3-vccv-2 is an attempt to address your item #2, and your item #3 is not yet addressed. Is this understanding correct? I also think that one of the items in the discussion was the restriction on ECMP in MPLS to skip reserved labels. I am not sure if it has been properly addressed anywhere, so should not it constitute item #4? Regards, Sasha From: Stewart Bryant [mailto:stbry...@cisco.com] Sent: Tuesday, August 30, 2011 3:05 PM To: Luca Martini; IETF Discussion Cc: John E Drake; m...@ietf.org; Alexander Vainshtein; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; pwe3-cha...@tools.ietf.org; i...@ietf.org Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Reviewing this discussion there are three components. 1) The update of RFC5586 to allow PW to use the GAL. 2) The PW OAM application that is to use the GAL. 3) The label stack structure when teh GAL is used with a PW This draft is only concerned with point 1 above. Points 2 and 3 need to be resolved in any PWE3 draft that describes the use of the GAL. To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01 - Section 4.2http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586http://tools.ietf.org/html/rfc5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack. = should be replaced by = - Section 4.2http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586http://tools.ietf.org/html/rfc5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. The presence of a GAL indicates that an ACH immediately follows the MPLS label stack. == - Stewart This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Luca and all, I have not found the statement you've proposed in draft-ietf-pwe3-fat-pw-06. Instead, it contans the following text in Section 8.5 Applicability to MPLS-TP: quote The flow aware transport of a PW reorders packets, therefore MUST NOT be deployed in a network conforming to the MPLS-TP unless these integrity requirements specified in the SLA can be satisfied. end quote (In the -07 version this text is repeated but followed by an incomplete statement In a immediately followed by the heading of Section 8.6. Since this addition is difficult to parse, I will ignore it for the moment.) IMHO and FWIW this means that prohibition on using flow aware PW in MPLS-TP environments is conditional on meeting specific SLA requirements for the service. So I think that the use case I've presented still holds. Please note also that, regardless of the restriction in draft-ietf-pwe3-fat-pw, be it conditional or absolute, usage of flow labels in an MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the label stack and taking one of multiple NHLFEs for the given incoming label in the ILM) were not used in this domain, e.g., by associating exactly one ILM entry with each incoming label in the ILM. And since MPLS-TP is supposed to carry not just PW clients but also IP ones, I would expect that this would be the case in any MPLS-TP deployment. I also think that releasing one restriction (on using GAL in PWs) at the expense of making another, conditional one (on usage of flow labels in MPLS-TP environments) absolute is not the most appropriate method for resolving technical issues. IMHO and FWIW better way to resolve the problem would be by: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels. I think that these considerations have been presented already in the discussion on draft-nadeau-pwe-vccv-2. Of course it would be even better if we could agree on transition to universal usage of the CW and VCCV Type 1 in PWs. But this is a different story. Regards, Sasha From: Luca Martini [lmart...@cisco.com] Sent: Wednesday, August 17, 2011 9:58 PM To: Alexander Vainshtein Cc: Pablo Frank; m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw The solution is quite simple: Flow Labels MUST not be used in an MPLS-TP environment. Luca On 08/16/11 21:46, Alexander Vainshtein wrote: Pablo, Sorry, but I think you're wrong. Only T-PE can insert the flow label (because only T=PE can be flow-aware). S-PE simply performs swap on PW label. Regards, Sasha *From:* Pablo Frank [pablois...@gmail.com] *Sent:* Wednesday, August 17, 2011 12:17 AM *To:* Alexander Vainshtein *Cc:* ietf@ietf.org; m...@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain in the middle segment, you're no longer in an MPLS-TP environment and so the GAL is not required to be BOS. During that middle segment, the PW flow label would be placed below the GAL and above the GACh. It gets removed when it hits the S-PE that switches you back into the MPLS-TP environment. In other words, whether you're in an MPLS-TP environment is determined segment by segment in a MS-PW. Pablo On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein alexander.vainsht...@ecitele.com mailto:alexander.vainsht...@ecitele.com wrote: Hi all, After having sent out my comments I've noticed that the specific example to illustrate the need to combine GAL and flow label was inaccurate. A more relevant example would look like following (I do not include a diagram, but it can be easily provided if necessary) 1. A MS-PW: * Starts at an S-PE that resides at the edge of an MPLS-TP domain (no ECMP) * Crosses this domain and enters an IP/MPLS domain with ECMP enabled using a T-PE that resides at the age of these two domains * Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T-PE) * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain 2. The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of flow labels at the two S-PEs. Note that: * This does
RE: IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Hi all, After having sent out my comments I've noticed that the specific example to illustrate the need to combine GAL and flow label was inaccurate. A more relevant example would look like following (I do not include a diagram, but it can be easily provided if necessary) 1. A MS-PW: * Starts at an S-PE that resides at the edge of an MPLS-TP domain (no ECMP) * Crosses this domain and enters an IP/MPLS domain with ECMP enabled using a T-PE that resides at the age of these two domains * Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T-PE) * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain 2. The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of flow labels at the two S-PEs. Note that: * This does not violate the MPLS-TP restriction on ECMP: ECMP does not happen in he MPLS-TP domains * T-PEs do not even have to be aware of flow labels 3. The operator also intends to operate some end-to-end OAM for this MS-PW using GAL-in-PW. This results in a conflict since both GAL and flow label are defined (in the corresponding drafts) as bottom of stack. IMHO this describes a realistic scenario where the two drafts are in controversy. Regards, Sasha From: mpls-boun...@ietf.org [mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein [alexander.vainsht...@ecitele.com] Sent: Tuesday, August 16, 2011 4:26 PM To: ietf@ietf.org Cc: m...@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi all, I would like to raise the following issue with regard to draft-ietf-pwe3-gal-in-pwhttp://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-in-pw/?include_text=1: controversy vs. draft-ietf-pwe3-fat-pwhttp://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/?include_text=1 with regard to bottom-of-stack position. As stated in the Introduction, this draft removes the restriction imposed by RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack(i.e., S bit set to 1). draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586 with the following In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). I.e., while removing this restriction of 5586, it does not modify its requirement for the GAL being always at the bottom of the label stack. At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) reserves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.1: This document describes a method of adding an additional label stack entry (LSE) at the bottom of stack in order to facilitate the load balancing of the flows within a PW over the available ECMPs. One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and FWIW, such an argument, were it presented, would be highly problematic, because: 1. RFC 5960 (which defines the MPLS-TP data plane) did not define any differences between the PW data plane in IP/MPLS and MPLS-TP. 2. One of the most popular scenarios for using multi-segment pseudowires is the case when an edge-to-edge service emulation crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) would potentially compete with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, e.g., for relying a PW status message that it has received over a Targeted LDP session from the IP/MPLS domain to a static PW status message to cross the MPLS-TP domain) for the bottom-of-stack position. The issue I am raising Is not new. It has been actively discussed on the PWE3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for both the flow label and GAL taking the bottom-of-the-stack position. But, to the best of my understanding, consensus on this issue has not been reached. Hopefully this comment will be useful. Regards, Sasha This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only
RE: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Pablo, Sorry, but I think you're wrong. Only T-PE can insert the flow label (because only T=PE can be flow-aware). S-PE simply performs swap on PW label. Regards, Sasha From: Pablo Frank [pablois...@gmail.com] Sent: Wednesday, August 17, 2011 12:17 AM To: Alexander Vainshtein Cc: ietf@ietf.org; m...@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain in the middle segment, you're no longer in an MPLS-TP environment and so the GAL is not required to be BOS. During that middle segment, the PW flow label would be placed below the GAL and above the GACh. It gets removed when it hits the S-PE that switches you back into the MPLS-TP environment. In other words, whether you're in an MPLS-TP environment is determined segment by segment in a MS-PW. Pablo On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein alexander.vainsht...@ecitele.commailto:alexander.vainsht...@ecitele.com wrote: Hi all, After having sent out my comments I've noticed that the specific example to illustrate the need to combine GAL and flow label was inaccurate. A more relevant example would look like following (I do not include a diagram, but it can be easily provided if necessary) 1. A MS-PW: * Starts at an S-PE that resides at the edge of an MPLS-TP domain (no ECMP) * Crosses this domain and enters an IP/MPLS domain with ECMP enabled using a T-PE that resides at the age of these two domains * Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T-PE) * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain 2. The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of flow labels at the two S-PEs. Note that: * This does not violate the MPLS-TP restriction on ECMP: ECMP does not happen in he MPLS-TP domains * T-PEs do not even have to be aware of flow labels 3. The operator also intends to operate some end-to-end OAM for this MS-PW using GAL-in-PW. This results in a conflict since both GAL and flow label are defined (in the corresponding drafts) as bottom of stack. IMHO this describes a realistic scenario where the two drafts are in controversy. Regards, Sasha From: mpls-boun...@ietf.orgmailto:mpls-boun...@ietf.org [mpls-boun...@ietf.orgmailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein [alexander.vainsht...@ecitele.commailto:alexander.vainsht...@ecitele.com] Sent: Tuesday, August 16, 2011 4:26 PM To: ietf@ietf.orgmailto:ietf@ietf.org Cc: m...@ietf.orgmailto:m...@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi all, I would like to raise the following issue with regard to draft-ietf-pwe3-gal-in-pwhttp://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-in-pw/?include_text=1: controversy vs. draft-ietf-pwe3-fat-pwhttp://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/?include_text=1 with regard to bottom-of-stack position. As stated in the Introduction, this draft removes the restriction imposed by RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack(i.e., S bit set to 1). draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586 with the following In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). I.e., while removing this restriction of 5586, it does not modify its requirement for the GAL being always at the bottom of the label stack. At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) reserves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.1: This document describes a method of adding an additional label stack entry (LSE) at the bottom of stack in order to facilitate the load balancing of the flows within a PW over the available ECMPs. One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and FWIW, such an argument, were it presented, would be highly problematic, because: 1. RFC 5960 (which defines the MPLS-TP data plane) did not define any differences between the PW data plane in IP/MPLS and MPLS-TP. 2. One of the most popular scenarios for using multi-segment pseudowires
IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Hi all, I would like to raise the following issue with regard to draft-ietf-pwe3-gal-in-pwhttp://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-in-pw/?include_text=1: controversy vs. draft-ietf-pwe3-fat-pwhttp://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/?include_text=1 with regard to bottom-of-stack position. As stated in the Introduction, this draft removes the restriction imposed by RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack(i.e., S bit set to 1). draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586 with the following In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). I.e., while removing this restriction of 5586, it does not modify its requirement for the GAL being always at the bottom of the label stack. At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) reserves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.1: This document describes a method of adding an additional label stack entry (LSE) at the bottom of stack in order to facilitate the load balancing of the flows within a PW over the available ECMPs. One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and FWIW, such an argument, were it presented, would be highly problematic, because: 1. RFC 5960 (which defines the MPLS-TP data plane) did not define any differences between the PW data plane in IP/MPLS and MPLS-TP. 2. One of the most popular scenarios for using multi-segment pseudowires is the case when an edge-to-edge service emulation crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) would potentially compete with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, e.g., for relying a PW status message that it has received over a Targeted LDP session from the IP/MPLS domain to a static PW status message to cross the MPLS-TP domain) for the bottom-of-stack position. The issue I am raising Is not new. It has been actively discussed on the PWE3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for both the flow label and GAL taking the bottom-of-the-stack position. But, to the best of my understanding, consensus on this issue has not been reached. Hopefully this comment will be useful. Regards, Sasha This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks
Italo, My original comment on SPME has been sent to the list on 07-Jul-10. You can see it at http://www.ietf.org/mail-archive/web/mpls-tp/current/msg04369.html . It has not been posted as an LC comment, presumably because the draft has not been in any kind of LC at that moment. Adrian, Please consider this comment as an IESG LC comment. Regards, Sasha -Original Message- From: Alexander Vainshtein Sent: Monday, November 15, 2010 9:03 AM To: BUSI, ITALO (ITALO) Cc: mpls...@ietf.org; adr...@olddog.co.uk Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks Italo, Lots of thanks for a prompt response. I will look up my archives and resend the specific comment regarding SPME. But the gist of this comment has been, that SPME is a new LSP, so that monitoring it does not necessarily say anything about the original LSP passing thru the segment in question. The simplest use case demonstrating the difference is a case of incomplete configuration, when the original LSP has not been configured in one of the internal nodes of the segment, but SPME was (and vice versa). Regarding MIPs, I'd like to explain my doubts. 1. We all agree (or so it seems) that intermediate points of LSPs and PWs can only be reached due to TTL expiration. 2. By default TTL expiration extracts a packet from the data plane and sends it to the control plane instead. As per RFC 4379, this process includes preservation of the original received label stack and noting the actual ingress interface so that they are available for the CP processing. 3. Taking (1) and (2) above as given, could you please clarify, what exactly does it mean if: (a) A per-node MIP is disabled? (b) A per-interface MIP is disabled? 4. Are MIPs bound to specific Managed Entities (LSPs)? If they are, what should happen if: a) An LSP uses labels from the per-platform label stace, and hence packets associated with this LSP can be received from any interface? b) A per-interface MIP is enabled for this LSP on one interface and disabled on another one? Regards, Sasha From: BUSI, ITALO (ITALO) [italo.b...@alcatel-lucent.com] Sent: Monday, November 15, 2010 12:54 AM To: Alexander Vainshtein; adr...@olddog.co.uk Cc: mpls...@ietf.org Subject: R: [mpls-tp] about open discussion about MIP MEP inMPLS-TP networks Sasha, See in line marked with [ib] Thanks in advance Italo -Messaggio originale- Da: mpls-tp-boun...@ietf.org [mailto:mpls-tp-boun...@ietf.org] Per conto di Alexander Vainshtein Inviato: venerdì 12 novembre 2010 11.37 A: adr...@olddog.co.uk Cc: mpls...@ietf.org Oggetto: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks Adrian, I've looked up the MPLS-TP OAM framework draft and it indeed discusses per-interface MIPs that have not been considered (according to my reading) in RFC 5654. I think that, at the very least, the notion of a per-interface MIP requires additional clarification. E.g., can you introduce a per-interface MIP in an LSP that uses labels from the per-platform space? [ib] Could you be more specific about how the label space impacts the support of per-interface vs per-node MIP? On a more generic level, taking into account that the only way to reach a MIP in an LSP is to send a packet that would experience TTL expiration in the node of interest, what is the difference in behavior of LSPs with configured MIPs and LSPs without them? [ib] We discussed this point during the development of the OAM framework and we have agreed that every node has MIP(s) and that the operator can disable them. See the following text extracts from section 3.4: An intermediate node within a MEG can either: o Support per-node MIP (i.e. a single MIP per node in an unspecified location within the node); o Support per-interface MIP (i.e. two or more MIPs per node on both sides of the forwarding engine). And Once a MEG is configured, the operator can enable/disable the MIPs on the nodes within the MEG. All the intermediate nodes and possibly the end nodes host MIP(s). Local policy allows them to be enabled per function and per MEG. The local policy is controlled by the management system, which may delegate it to the control plane. I hope this would help. I also note that the framework draft still promotes hierarchy of labels for SPMEs and/or TCM. I believe that I've commented on this concept earlier, and in any case I plan to send an IESG LC comment on this point: IMO my previous comments in this regard have not been resolved. [ib] Could you please re-send your comment? This would help expediting its resolution as I fear we have missed it. I apologize for that. Regards, Sasha From: mpls-tp-boun...@ietf.org [mpls-tp-boun...@ietf.org] On Behalf Of Adrian Farrel [adr...@olddog.co.uk] Sent
