Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"
Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Tue, 14 June 2011 12:02 UTC
Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F2311E80AF; Tue, 14 Jun 2011 05:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.782
X-Spam-Level:
X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUjyl1prLlrM; Tue, 14 Jun 2011 05:02:17 -0700 (PDT)
Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 79EF211E808A; Tue, 14 Jun 2011 05:02:15 -0700 (PDT)
X-AuditID: 93eaf2e8-b7c74ae000000a6f-96-4df74d6235df
Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id DC.FF.02671.26D47FD4; Tue, 14 Jun 2011 15:00:35 +0300 (IDT)
Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 14 Jun 2011 15:02:12 +0300
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Daniel Cohn <DanielC@orckit.com>
Date: Tue, 14 Jun 2011 15:02:10 +0300
Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"
Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygAAADmpwACeE3pAAA/tUMA==
Message-ID: <A3C5DF08D38B6049839A6F553B331C76E9BDCA9D92@ILPTMAIL02.ecitele.com>
References: <OF7EF3F6D6.7AE4C202-ON482578AE.00430DDE-482578AE.0044404E@zte.com.cn><A3C5DF08D38B6049839A6F553B331C76E9BDCA9A38@ILPTMAIL02.ecitele.com> <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> <44F4E579A764584EA9BDFD07D0CA081306CF33B5@tlvmail1> <A3C5DF08D38B6049839A6F553B331C76E9BDCA9AB7@ILPTMAIL02.ecitele.com> <44F4E579A764584EA9BDFD07D0CA081306CF354A@tlvmail1>
In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306CF354A@tlvmail1>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9D92ILPTMAIL02eci_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELsWRmVeSWpSXmKPExsUy+dWnL7rJvt99DWbPFrRouLSYyeLrjJvM FreWrmS1uH1/O7tF36ctLA6sHkuW/GTy+Ln+KrtH94bJzB5r9v1gCWCJamC0SczLyy9JLElV SEktTrZVCijKLEtMrlRSyEyxVTJUUijISUxOzU3NK7FVSiwoSM1LUbLjUsAANkBlmXkKqXnJ +SmZeem2Sp7B/roWFqaWuoZKdmrKhsbWXCEZmcUKqbq5iZk5CrmpxcWJ6akKQJGELcwZS46+ Zi64e56l4tGPKywNjPN6WLoYOTkkBEwkfmzcwwhhi0lcuLeerYuRi0NIYCejxLKdt6GcKYwS J1Z/ZQepYhOwldi0+i4biC0ioCKx8dpHsDgzSMeVMz4gNouAqsSpR33MILawQIrEokk3WSDq UyVe794L1RsmcajzOJjNK+AvcWHeQ2aIZb3MEtOb3oGdxCngILHlxT0wmxHovO+n1jBBLBOX uPVkPhPE2QISS/acZ4awRSVePv7HClEvKnGnfT0jRH2+xOVbp9ghlglKnJz5BOp9SYmDK26w TGAUm4Vk7CwkLbOQtEDEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjKKZOQUlSbnpBkZ6 qcmZJak5qXrJ+bmbGCEJ68UOxttnNA8xCnAwKvHwbrD45ivEmlhWXJl7iFGSg0lJlFfN57uv EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHe3ldffIV4UxIrq1KL8mFSrsDgn8gsxZ2cD0zCeSXx xgYGuDlK4rzdyW98hQTSgakzOzW1ILUIZo4MB4eSBO8bkPWCRanpqRVpmTklCGkmDk6QM3iA zpAGZg0h3uKCxNzizHSI/ClGS473h9cfYuT4O2cTkJy8DEgKseTl56VKifOeBxkqANKQUZoH NxOU1er/////ilEcGBjCvA9AqniAGRFu6iughUxAC2+9/AayEJij4FJSDYzmtpEp7rlHTG/N u+o5RWknp6n8Cr01oR/raxWWXX2mvmjizgt9nByF1gqvH1ivtNvR18f2e7HXD13P3/PCjxkL hzz1WcJbFBbBPrlO+OOUmCn6+SwShyRZ178JtHaZdfXCVSaFpQ+ONqwwrg+yWc27NfNhmPu1 xeu3/F1jkFeTZx0eeDjuUoESS3FGoqEWc1FxIgBy16YKRQQAAA==
Cc: "ma.yuxia@zte.com.cn" <ma.yuxia@zte.com.cn>, "mpls@ietf.org" <mpls@ietf.org>, "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2011 12:02:26 -0000
Daniel, Please see more inline (bold purple italics). I've also stripped the portions of the text that are not related to this round of comments. Regards, Sasha From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Tuesday, June 14, 2011 2:34 PM To: Alexander Vainshtein Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" Hi Sasha, thanks again and see inline with [DC]. From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, June 13, 2011 6:11 PM To: Daniel Cohn Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" Daniel and all, Please see some comments inline below. Regards, Sasha From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, June 13, 2011 5:55 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" Hi, Thanks all for the feedback. I believe we all agree that PW protection is only required in the event of S-PE failure at an MS-PW - this is clearly stated in the draft. Now, both Sasha and Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW protection requirements. [[[Sasha]]] ... snipped ... E.g., the PW redundancy mechanisms take care of dual-homed CEs in SS- and MS-PWs - something that liner protection of PWs cannot do. [DC] I'm afraid I don't follow you here. Where does PW redundancy take care of dual-homed CE? Actually PW redundancy draft explicitly states: "The method for dual-homing of CE1 to PE1 and to PE3 nodes, and the protocols used, are outside the scope of this document". [[[Sasha]]] Quoting from the draft: 15.2. Multiple Multi-homed CEs with single SS-PW redundancy |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnels-->| | | | V V (not shown) V V | V AC +----+ +----+ AC V +-----+ | |....|.......PW1........|....| | +-----+ | |----------| PE1|...... .........| PE3|----------| | | CE1 | +----+ \ / PW3 +----+ | CE2 | | | +----+ X +----+ | | | | | |....../ \..PW4....| | | | | |----------| PE2| | PE4|--------- | | +-----+ | |....|.....PW2..........|....| | +-----+ AC +----+ +----+ AC Figure 15-2 Multiple Multi-homed CEs with single SS-PW redundancy The application in Figure 15-2 makes use of the Independent mode of operation. CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed PE3 and PE4. The method for dual-homing and the used protocols are outside the scope of this document. Note that the PSN tunnels are not shown in this figure for clarity. However, it can be assumed that each of the PWs shown is encapsulated in a separate PSN tunnel. Assume that the AC from CE1 to PE1 is Active, from CE1 to PE2 is Standby; furthermore, assume that the AC from CE2 to PE3 is Standby and from CE2 to PE4 is Active. The method of deriving Active/Standby status of the AC is outside the scope of this document. PE1 advertises the preferential status "Active" and operational status "Pseudowire forwarding" for pseudowires PW1 and PW4 connected to PE3 and PE4. This status reflects the forwarding state of the AC attached to PE1. PE2 advertises preferential status "Standby" and operational status "Pseudowire forwarding" for pseudowires PW2 and PW3 to PE3 and PE4. PE3 advertises preferential status "Standby" and operational status "Pseudowire forwarding" for pseudowires PW1 and PW3 to PE1 and PE2. PE4 advertise the preferential status "Active" and operational status "Pseudowire forwarding" for pseudowires PW2 and PW4 to PE2 and PE1 respectively. Thus by matching the local and remote preferential forwarding status of "Active" and operational status of "Pseudowire forwarding" of pseudowires, the PE nodes determine which PW should be in the Active state. In this case it is PW4 that will be selected. On failure of the AC between CE1 and PE1, the forwarding state of the AC on PE2 is changed to Active. PE2 then announces the newly changed 'preferential forwarding' status bit of "active" to PE3 and PE4. PE1 will advertise a PW status notification message indicating that the AC between CE1 and PE1 is operationally down. PE2 and PE4 match the local and remote preferential forwarding status of "Active" and operational status "Pseudowire forwarding" and select PW2 as the new active pseudowire to send traffic to. On failure of PE1 node, PE2 will detect it and will transition the forwarding state of its AC to Active. The method by which PE2 detects that PE1 is down is outside the scope of this document. PE2 then announces the newly changed 'preferential forwarding' status bit of "Active" to PE3 and PE4. PE2 and PE4 match the local and remote preferential forwarding status of "Active" and operational status "Pseudowire forwarding" and select PW2 as the new active pseudowire to send traffic to. Note that PE3 and PE4 may have detected that the PW to PE1 went down via T-LDP Hello timeout or via other means. However, they will not be able to forward user traffic until they received the updated status bit from PE2. Because each dual-homing algorithm running on the two node sets, i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC independently, there is a need to signal the active status of the AC such that the PE nodes can select a common active PW for end-to-end forwarding between CE1 and CE2 as per the procedures in the independent mode. Note that any primary/secondary procedures, as defined in sections 5.1. and 5.2. , do not apply in this use case as the Active/Standby status is driven by the AC forwarding state as determined by the AC dual-homing protocol used. I believe you've taken your "out of scope" reference from this text, but IMHO you misinterpreted it. What it means (or so I read it) is that specific dual-homing protocol is out of scope as long as it meets certain assumptions. Aside: It would be good if the authors of the PW redundancy drafts could explicitly specify these assumptions. [[[Sasha]]] ... snipped ... Now let's turn our attention back to whether the PW redundancy draaft can be used to meet MPLS-TP PW protection requirements. I can identify the following reasons why in its current form it doesn't: - It explicitly ("outside the scope") does not define protection triggers and how to handle coexisting triggers, as requested in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and #79 [[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinated protection switching happens. [DC] It is. But still it needs to be defined by the recovery framework, e.g. what should the endpoint do when one PW is in SF and the other is in SD, or when both are in SD. Operators expect well-defined behavior in these and other scenarios, and PW redundancy does not define them (because it was not in their scope). [[[Sasha]]] I wonder if you have followed the discussion regarding ability to define SD condition for LSPs and PWs on the MPLS-TP list? IMO it is not possible to define it in a meaningful way. Hence I do not see a proposal that does not address a scenario that does not exist in reality as a flawed one. - It does not support the ability to distinguish between different types of triggers (i.e. one end doesn't know why the other end triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially important to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP Requirements), req #65 [[[Sasha]]] All these claims are correct - and this should not be a surprise, because MPLS-TP requirements have been defined much later than the PW redundancy mechanism. But I do not think that this justifies co-existence of two different mechanisms. [DC] So how do you propose to meet the PW protection requirement? - It's a two-phase protocol, with the consequent impact on timing[[[Sasha]]] Could you please elaborate? [DC] In draft-ietf-mpls-tp-linear-protection, each endpoint will immediately switch traffic to the other path upon identifying an SF condition in a path, without waiting for the far end to acknowledge the switch (1-phase). In PW redundancy, an endpoint detecting an SF condition in a path will not switch until the far end has acknowledged the switch (2-phase). Needless to say, recovery is slower in a 2-phase protocol. [[[Sasha]]] To the best of my understanding, 1-phase protection is only possible in 1+1 unidirectional architectures. And yes, I know that MPLS-TP requires a mechanism to support this; whether anybody would really do that in the packet-switching network is not clear to me. And I acknowledge that the PW redundancy drafts do not support 1+1 unidirectional scheme. - It doesn't define retransmission of protection coordination messages, so loss of a single PDU can result in switchover not taking place, thus not supporting sub-50 ms recovery in this case [[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which benefits from TCP retransmissions) or on top of static PW status messages (where retransmission is defined). [DC] True - but static PW status defines slow retransmission ("will be transmitted twice at an initial interval of one second") while draft-ietf-mpls-tp-linear-protection specifies fast retransmission when required for fast recovery (section 3.1.4). In summary, PW redundancy was not designed with TP requirements in mind, and as such does not meet the TP requirements. Of course modifications may be introduced, but why reinvent the wheel when there is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards track that supports all the above requirements and can be applied to MS-PW protection with minor modifications? [[[Sasha]]] As I said, because the applicability scope is by far too narrow to justify a dedicated protocol. [DC] If we were discussing designing a new protocol, I might agree with you. But from a practical standpoint, the PW protection draft is not a dedicated protocol - it's an applicability statement to an existing protocol. Both from the implementation and the operational point of view it defines a new use case for an existing protocol and concept. Regards, Daniel From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources. MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried. I also doubt why there is a need for additional mechanism. Best regards, Nurit From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" Dear Ma and all, Adding the PWE3 WG to my response. The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft<http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/?include_text=1> describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft<http://datatracker.ietf.org/doc/draft-ietf-pwe3-static-pw-status/?include_text=1>( if, for whatever reason, you do not want to, or cannot, use RFC 4447<http://datatracker.ietf.org/doc/rfc4447/?include_text=1>) Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Hi all, The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly. BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". " Figure 1 illustrates such a scenario, where two MS-PWs are established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 respectively. Each PW segment is established over an LSP (e.g. PW- s12 over LSP12). " -----Original Message----- From: Daniel Cohn Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author? Looking forward to your feedback, Daniel 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 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 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.
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Alexander Vainshtein
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… binny jeshan
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… binny jeshan
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Daniel Cohn
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Alexander Vainshtein
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Gregory Mirsky
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Daniel Cohn
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Daniel Cohn
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Maarten vissers
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Daniel Cohn
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Alexander Vainshtein
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Alexander Vainshtein
- Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-T… Daniel Cohn
- [PWE3] 答复: RE: [mpls] Seeking feedback on I-D "MP… ma.yuxia
- [PWE3] R: [mpls] Seeking feedback on I-D "MPLS-TP… D'Alessandro Alessandro Gerardo