[PWE3] 答复: RE: [mpls] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"

[[e-mail]]

Hi Sasha,

"Linear protection" is different from "Multi-homed CE redundancy" and has 
no reference with AC.

Working path(s) and protection path(s) have same source and sink endpoints 
in linear protection type.

IMHO, When S-PE fails, it is more simple to use "Linear protection" to 
protect it.



Best Regards,
Ma


Alexander Vainshtein <[e-mail]> дÓÚ 2011-06-14 
20:02:10:

> 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:[e-mail]] 
> Sent: Tuesday, June 14, 2011 2:34 PM
> To: Alexander Vainshtein
> Cc: [e-mail]; [e-mail]; Sprecher, Nurit (NSN - IL/Hod 
> HaSharon); [e-mail]
> 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:[e-mail]] 
> Sent: Monday, June 13, 2011 6:11 PM
> To: Daniel Cohn
> Cc: [e-mail]; [e-mail]; Sprecher, Nurit (NSN - IL/Hod 
> HaSharon); [e-mail]
> 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:[e-mail]] 
> Sent: Monday, June 13, 2011 5:55 PM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; 
> [e-mail]
> Cc: [e-mail]; [e-mail]
> 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
> ¨C 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 ¨C 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 ¨C 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 ¨C 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 ¨C 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: [e-mail] [mailto:[e-mail]] On Behalf Of 
> Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Sent: Monday, June 13, 2011 4:02 PM
> To: ext Alexander Vainshtein; [e-mail]
> Cc: [e-mail]; [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of 
> ext Alexander Vainshtein
> Sent: Monday, June 13, 2011 3:43 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> 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 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( if, for whatever reason, you do not
> want  to, or cannot, use RFC 4447).
> 
> Hence I doubt the need for yet another PW redundancy  mechanism with
> narrow scope of applicability.
> 
> Regards,
>      Sasha
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Monday, June 13, 2011 3:25 PM
> To: [e-mail]
> 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. 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.