Subject: [mpls] FW: [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"

From: Eric Gray <[email-masked]>
Date: Thu, 16 Jun 2011 06:43:25 -0400

Forwarding in plain text...
________________________________

From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, June 14, 2011 7:31 AM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"

Hi Nurit,

The exact same argument can be made for LSP linear protection as in draft-ietf-mpls-tp-linear-protection - it protects LSRs (transit LERs) but doesn't protect head/tail LERs. So why not drop LSP linear protection altogether and protect the client service layer instead? 

Protection is a statistical business. Protecting S-PE will improve availability, even when T-PE is not protected - especially when you remember that typically there are many more S-PEs than T-PEs in a given PW. Also as the T-PE is typically closest to the edge, a T-PE will typically carry less PWs than an S-PE so S-PE protection would be more significant for the operator. 

AC protection (required in order to protect T-PE) using ICCP or similar, as Greg pointed out, is not defined as part of the MPLS-TP framework. In the most extreme case, which is gradually becoming the norm, operators deploy MPLS to the customer edge, so the T-PE will actually be a CE in which case CE/T-PE protection is technically an impossibility.

On the other hand, there is a clear MPLS-TP requirement to provide protection for MPLS-TP transport paths, which includes PWs. The purpose of this draft is to meet this requirement, for which there is currently no solution. If you have an alternative solution please share it with the list so we can discuss it.

Thanks,

Daniel

From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:[email-masked]] 
Sent: Monday, June 13, 2011 6:23 PM
To: ext Alexander Vainshtein; Daniel Cohn
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"

If you do it on the client service layer, you can protect also the T-PE...

Why do you want to protect only against a failure of the S-PE? The PW starts at the T-PE...

From: ext Alexander Vainshtein [mailto:[email-masked]] 
Sent: Monday, June 13, 2011 6:11 PM
To: Daniel Cohn
Cc: [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]
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:[email-masked]] 
Sent: Monday, June 13, 2011 5:55 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]
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.

First of all a word on scalability. Please note that in an MPLS-TP environment without a control plane, the PW redundancy mechanism must also rely on proactive connectivity check for fast failure detection to  meet the sub-50 ms requirement. [[[Sasha]]] IMO there is nothing specific to MPLS-TP here. Detecting S-PE failures based on the control plane would  not fast enough.

Therefore any scalability considerations that apply to the PW protection draft apply to the PW redundancy draft as well.[[[Sasha]]] I have not raised the scalability issue. My issue was limited applicability scope when compared to PW redundancy. 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.

Also wrt scalability, there is no such thing as "scales" or "doesn't scale" - scalability is not a binary concept. You can say that PW protection scales worse than LSP protection, just like you can say that LSP protection scales worse than interface protection. Which didn't stop IETF from defining LSP protection for scenarios where interface protection doesn't do the job.

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.

-          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.

-          It's a two-phase protocol, with the consequent impact on timing[[[Sasha]]] Could you please elaborate? 

-          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). 

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.

Regards,

Daniel

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Monday, June 13, 2011 4:02 PM
To: ext Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of ext Alexander Vainshtein
Sent: Monday, June 13, 2011 3:43 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 13, 2011 3:25 PM
To: [email-masked]
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.

---

From: Eric Gray <[email-masked]>
Date: Thu, 16 Jun 2011 06:45:47 -0400

Forwarded in plain text...

From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, June 14, 2011 7:34 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]
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:[email-masked]] 
Sent: Monday, June 13, 2011 6:11 PM
To: Daniel Cohn
Cc: [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]
Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"

Daniel and all,

Regards,

     Sasha

Hi,

[DC] Agreed - I just pointed our that MPLS-TP has a requirement for sub-50ms protection.

Therefore any scalability considerations that apply to the PW protection draft apply to the PW redundancy draft as well.[[[Sasha]]] I have not raised the scalability issue. My issue was limited applicability scope when compared to PW redundancy. 

[DC] Correct - scalability issue was a response to Nurit's comment.

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". 

[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). 

[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.

[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). 

[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

Hi,

Best regards,

Nurit

Dear Ma and all,

Regards,

     Sasha

Hi all, 

 " 

-----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,

The abstract goes:

Daniel 

[Disclaimer Elided]

---

From: Eric Gray <[email-masked]>
Date: Thu, 16 Jun 2011 06:48:55 -0400

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Tuesday, June 14, 2011 8:02 AM
To: Daniel Cohn
Cc: [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]
Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"

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:[email-masked]]
Sent: Tuesday, June 14, 2011 2:34 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]
Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"

Daniel and all,

Regards,

     Sasha

Hi,

[[[Sasha]]] ... snipped ...

[[[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 ...

[[[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.

[[[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.

Regards,

Daniel

Hi,

Best regards,

Nurit

Dear Ma and all,

Regards,

     Sasha

Hi all,

 "

-----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,

The abstract goes:

Daniel
[Disclaimer Elided]

---

From: Eric Gray <[email-masked]>
Date: Tue, 21 Jun 2011 10:54:34 -0400

Forwarding in plain text - with ZTE disclaimer removed...

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 20, 2011 4:31 AM
To: Alexander Vainshtein
Cc: Daniel Cohn; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]
Subject: 答复: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"

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 <[email-masked]> 写于 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
>
> Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-
> TPLinearProtectionApplicability to MS-PW"
>
> Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-
> TPLinearProtectionApplicability to MS-PW"
>
> Daniel and all,
> 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”.
> 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.
> -          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?
> [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
>
>
> Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-
> TPLinearProtection Applicability to MS-PW"
>
> Hi,
> 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.
> 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).
>
> The linear protection mechanism for LSP and PW(including MS-PW)
> should be the same and it is valuable to describe it clearly.
>
> 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. ﹎z冠??br>