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

[Eric Gray <[e-mail]>]

Forwarded in plain text...

________________________________

From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Tuesday, June 14, 2011 8:02 AM
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,

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 - 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: [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 <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: [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
[Disclaimer Elided]