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

[Eric Gray <[e-mail]>]

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

________________________________

From: [e-mail] [mailto:[e-mail]]
Sent: Monday, June 20, 2011 4:31 AM
To: Alexander Vainshtein
Cc: Daniel Cohn; [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,

"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. 
©mz¹Ú??br>