ietf-corpus

rfc-7771

Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires

A. Malis (Editor), L. Andersson, H. van Helvoort, J. Shin, L. Wang, A. D'Alessandro
date2016-01 streamIETF areartg wgpals statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc7771 doi10.17487/RFC7771
In MPLS and MPLS Transport Profile (MPLS-TP) environments, statically provisioned Single-Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection. With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures via MPLS-level and MPLS-TP-level tunnel protection. However, static MS-PWs are not protected end-to-end against failure of one of the Switching Provider Edge Routers (S-PEs) along the path of the MS-PW. This document describes how to achieve this protection via redundant MS-PWs by updating the existing procedures in RFC 6870. It also contains an optional approach based on MPLS-TP Linear Protection.

updates

Extracted elements (18)

design-rationale §A.1

Applying the PSC protocol to PWs enables a uniform operational approach for protection at both the LSP and PW layers and easier management integration for networks already implementing RFC 6378/7271/7324, especially for end-to-end static MS-PWs over MPLS-TP where tunnel protection alone is insufficient.

mpls, routing

design-rationale §A.2

From a PSC protocol perspective, an SS-PW is treated as a single-hop LSP and an MS-PW as a multi-hop LSP. This abstraction allows the existing PSC machinery to provide end-to-end protection for both SS-PWs and MS-PWs, including protection against failed intermediate S-PE nodes in the MS-PW case.

mpls, routing

design-rationale §1

MPLS-level and MPLS-TP-level tunnel protection covers individual PW segment tunnel failures but cannot protect against the failure of an S-PE node itself along the path of a static MS-PW. This gap motivates end-to-end protection via redundant MS-PWs.

mpls, routing

design-rationale §2

Statically provisioned PWs do not use LDP for setup, signaling, or status; instead they rely on RFC 6478 PW OAM status signaling via the PW Associated Channel Header (ACH). The PW Status TLV carried via this OAM path is identical to the LDP-carried version, including the same PW Status Codes, enabling RFC 6870 procedures to operate identically.

mpls, routing

design-rationale §1

This document differs from [PW-REDUNDANCY] in that it provides end-to-end resiliency for static MS-PWs, whereas [PW-REDUNDANCY] provides resiliency at intermediate S-PEs and covers both dynamically signaled and static MS-PWs. The two approaches address distinct but complementary failure scenarios.

mpls, routing

interoperability-note §3

Because LDP is not used between T-PEs for statically provisioned MS-PWs, the RFC 6870 LDP-based negotiation procedures cannot be used. Operators must take care to identically provision both endpoint T-PEs with respect to whether MS-PW redundancy is enabled, which PW is primary, and the precedence of secondary MS-PWs.

mpls, routing

interoperability-note §1

PWs based on the Layer 2 Tunneling Protocol Version 3 (L2TPv3) are explicitly outside the scope of this document. Only MPLS and MPLS-TP pseudowires are addressed.

mpls

interoperability-note §2

The optional S-PE Bypass Mode defined in Section 5.5 of RFC 6478 cannot be used with static MS-PW protection because it requires LDP signaling, which is not present in statically provisioned environments.

mpls, routing

interoperability-note §A.2

The protected entity and the protecting entity need not be of the same type. For example, it is valid to protect an SS-PW with an MS-PW or vice versa, and to protect a link by a path, providing flexibility in how linear protection is deployed.

mpls, routing

normative-requirement §A.1 MUST

For interoperability, all implementations MUST include the RFC 6478-based status signaling approach described in Section 2, even if the optional MPLS-TP Linear Protection approach in Appendix A is also implemented and used.

mpls, routing

normative-requirement §2 MUST

For the RFC 6870 management procedures to apply to statically provisioned PWs, the PW status signaling defined in RFC 6478 MUST be used for both the primary and secondary PWs, replacing LDP-based status signaling.

mpls, routing

normative-requirement §1 MUST

The optional MPLS-TP Linear Protection alternative approach in Appendix A MUST be identically provisioned in the PE endpoints for the protected MS-PW in order to be used.

mpls, routing

protocol-element §1

Multi-Segment Pseudowires (MS-PWs) consist of Terminating Provider Edge Routers (T-PEs), one or more Switching Provider Edge Routers (S-PEs), and a sequence of tunneled PW segments connecting adjacent nodes. Static MS-PWs lack end-to-end protection against S-PE failure even though each individual tunnel segment may be MPLS- or MPLS-TP-protected.

mpls, routing

protocol-element §A.1

The optional Linear Protection approach defines the protection domain of a point-to-point PW as consisting of two T-PEs and the transport paths (working path and protection path) connecting them, using the protection architectures from RFC 6378.

mpls, routing

protocol-element §2

The redundant MS-PW protection model provides N:1 protection against S-PE failure for the path between T-PE1 and T-PE2 using multiple MS-PWs switched at different S-PEs (S-PE1, S-PE2, S-PE3). Only one MS-PW is active at a time; the others serve as protection paths.

mpls, routing

security-consideration §4

If the optional MPLS-TP Linear Protection approach described in Appendix A is used, then the security considerations defined for RFCs 6378, 7271, and 7324 (MPLS-TP Linear Protection and its updates) also apply.

mpls, security

security-consideration §4

The security considerations defined for RFC 6478 (Pseudowire Status for Static Pseudowires) apply to this document. The LDP-related security considerations from RFCs 6718 and 6870 are not applicable because this document does not use LDP.

mpls, security

wire-format §A.2

The Generic Associated Channel (G-Ach) carrying the PSC protocol information for PW protection is placed in the label stack directly beneath the PW identifier label. With this placement, the PSC protocol operates exactly as specified in RFCs 6378, 7271, and 7324.

mpls, routing