< draft-ietf-pals-ms-pw-protection-00.txt   draft-ietf-pals-ms-pw-protection-01.txt >
Network Working Group A. Malis Network Working Group A. Malis
Internet-Draft L. Andersson Internet-Draft L. Andersson
Updates: 6870 (if approved) Huawei Technologies Co., Ltd Updates: 6870 (if approved) Huawei Technologies Co., Ltd
Intended status: Standards Track H. van Helvoort Intended status: Standards Track H. van Helvoort
Expires: July 31, 2015 Hai Gaoming BV Expires: October 24, 2015 Hai Gaoming BV
J. Shin J. Shin
SK Telecom SK Telecom
L. Wang L. Wang
China Mobile China Mobile
A. D'Alessandro A. D'Alessandro
Telecom Italia Telecom Italia
January 27, 2015 April 22, 2015
S-PE Outage Protection for Static Multi-Segment Pseudowires S-PE Outage Protection for Static Multi-Segment Pseudowires
draft-ietf-pals-ms-pw-protection-00.txt draft-ietf-pals-ms-pw-protection-01.txt
Abstract Abstract
In MPLS and MPLS-TP environments, statically provisioned Single- In MPLS and MPLS-TP environments, statically provisioned Single-
Segment Pseudowires (SS-PWs) are protected against tunnel failure via Segment Pseudowires (SS-PWs) are protected against tunnel failure via
MPLS-level and MPLS-TP-level tunnel protection. With statically MPLS-level and MPLS-TP-level tunnel protection. With statically
provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the
MS-PW is likewise protected from tunnel failures via MPLS-level and MS-PW is likewise protected from tunnel failures via MPLS-level and
MPLS-TP-level tunnel protection. However, static MS-PWs are not MPLS-TP-level tunnel protection. However, static MS-PWs are not
protected end-to-end against failure of one of the switching PEs protected end-to-end against failure of one of the switching PEs
(S-PEs) along the path of the MS-PW. This document describes how to (S-PEs) along the path of the MS-PW. This document describes how to
achieve this protection by updating the existing procedures in RFC achieve this protection via redundant MS-PWs by updating the existing
6870. It also contains an optional approach based on MPLS-TP Linear procedures in RFC 6870. It also contains an optional approach based
Protection. on MPLS-TP Linear Protection.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 31, 2015. This Internet-Draft will expire on October 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Extension to RFC 6870 to Protect Statically Provisioned SS- 2. Extension to RFC 6870 to Protect Statically Provisioned SS-
PWs and MS-PWs . . . . . . . . . . . . . . . . . . . . . . . 3 PWs and MS-PWs . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operational Considerations . . . . . . . . . . . . . . . . . 5 3. Operational Considerations . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Optional Linear Protection Approach . . . . . . . . 6 Appendix A. Optional Linear Protection Approach . . . . . . . . 6
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 6 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 6
A.2. Encapsulation of the PSC Protocol for Pseudowires . . . . 7 A.2. Encapsulation of the PSC Protocol for Pseudowires . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
As described in RFC 5659 [RFC5659], Multi-Segment Pseudowires (MS- As described in RFC 5659 [RFC5659], Multi-Segment Pseudowires (MS-
PWs) consist of terminating PEs (T-PEs), switching PEs (S-PEs), and PWs) consist of terminating PEs (T-PEs), one or more switching PEs
PW segments between the T-PEs at each of the MS-PW and the interior (S-PEs), and a sequence of PW segments that connects one of the T-PEs
S-PEs. In MPLS and MPLS-TP environments, statically provisioned with its "adjacent" S-PE, connects this S-PE with the next S-PE in
Single-Segment Pseudowires (SS-PWs) are protected against tunnel the sequence and so on until the last S-PE is connected by the last
failure via MPLS-level and MPLS-TP-level tunnel protection. With PW segment to the remaining T-PE. In MPLS and MPLS-TP environments,
statically provisioned Multi-Segment Pseudowires (MS-PWs), each PW statically provisioned Single-Segment Pseudowires (SS-PWs) are
segment of the MS-PW is likewise protected from tunnel failure via protected against tunnel failure via MPLS-level and MPLS-TP-level
MPLS-level and MPLS-TP-level tunnel protection. However, PSN tunnel tunnel protection. With statically provisioned Multi-Segment
protection does not protect static MS-PWs from failures of S-PEs Pseudowires (MS-PWs), each PW segment of the MS-PW is likewise
along the path of the MS-PW. protected from tunnel failure via MPLS-level and MPLS-TP-level tunnel
protection. However, PSN tunnel protection does not protect static
MS-PWs from failures of S-PEs along the path of the MS-PW.
RFC 6718 [RFC6718] provides a general framework for PW protection, RFC 6718 [RFC6718] provides a general framework for PW protection,
and RFC 6870 [RFC6870], which is based upon that framework, describes and RFC 6870 [RFC6870], which is based upon that framework, describes
protection procedures for MS-PWs that are dynamically signaled using protection procedures for MS-PWs that are dynamically signaled using
LDP. This document describes how to achieve protection against S-PE LDP. This document describes how to achieve protection against S-PE
failure in a static MS-PW by extending RFC 6870 to be applicable for failure in a static MS-PW by extending RFC 6870 to be applicable for
statically provisioned MS-PWs pseudowires (PWs) as well. statically provisioned MS-PWs pseudowires (PWs) as well.
This document also contains an optional alternative approach based on This document also contains an optional alternative approach based on
MPLS-TP Linear Protection. This approach, described in Appendix A, MPLS-TP Linear Protection. This approach, described in Appendix A,
skipping to change at page 5, line 10 skipping to change at page 5, line 10
based status signaling, including the identical PW Status Codes. based status signaling, including the identical PW Status Codes.
Sections 6 and 7 of RFC 6870 describes the management of a primary PW Sections 6 and 7 of RFC 6870 describes the management of a primary PW
and its secondary PW(s) to provide resiliency to the failure of the and its secondary PW(s) to provide resiliency to the failure of the
primary PW. They use status codes transmitted between endpoint T-PEs primary PW. They use status codes transmitted between endpoint T-PEs
using the PW Status TLV transmitted by LDP. For this management to using the PW Status TLV transmitted by LDP. For this management to
apply to statically provisioned PWs, the PW status signaling defined apply to statically provisioned PWs, the PW status signaling defined
in RFC 6478 MUST be used for the primary and secondary PWs. In that in RFC 6478 MUST be used for the primary and secondary PWs. In that
case, the endpoint T-PEs can then use the PW status signaling case, the endpoint T-PEs can then use the PW status signaling
provided by RFC 6478 in the place of LDP-based status signaling, but provided by RFC 6478 in the place of LDP-based status signaling, but
otherwise operate identically as described in RFC 6870. otherwise operate identically as described in RFC 6870. Note that
the optional S-PE Bypass Mode defined in Section 5.5 of RFC 6478
cannot be used, as it requires LDP signaling.
3. Operational Considerations 3. Operational Considerations
Because LDP is not used between the T-PEs for statically provisioned Because LDP is not used between the T-PEs for statically provisioned
MS-PWs, the negotiation procedures described in RFC 6870 cannot be MS-PWs, the negotiation procedures described in RFC 6870 cannot be
used. Thus, operational care must be taken so that the endpoint used. Thus, operational care must be taken so that the endpoint
T-PEs are identically provisioned regarding the use of this document, T-PEs are identically provisioned regarding the use of this document,
specifically whether or not MS-PW redundancy is being used, and for specifically whether or not MS-PW redundancy is being used, and for
each protected MS-PW, the identity of the primary MS-PW and the each protected MS-PW, the identity of the primary MS-PW and the
precedence of the secondary MS-PWs. precedence of the secondary MS-PWs.
skipping to change at page 5, line 41 skipping to change at page 5, line 43
5. IANA Considerations 5. IANA Considerations
There are no requests for IANA actions in this document. There are no requests for IANA actions in this document.
Note to the RFC Editor - this section can be removed before Note to the RFC Editor - this section can be removed before
publication. publication.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Matthew Bocci, Yaakov Stein, and The authors would like to thank Matthew Bocci, Yaakov Stein, David
David Sinicrope for their comments on this document. Sinicrope, Sasha Vainshtein, and Italo Busi for their comments on
this document.
Figure 1 and the explanatory paragraph following the figure were Figure 1 and the explanatory paragraph following the figure were
taken from RFC 6718. taken from RFC 6718. Figure 2 was adapted from RFC 6378.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
Protection", RFC 6378, October 2011. Protection", RFC 6378, October 2011.
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci,
skipping to change at page 7, line 13 skipping to change at page 7, line 13
LSPs only. LSPs only.
This Appendix extends these RFCs to be applicable for PWs (SS-PW and This Appendix extends these RFCs to be applicable for PWs (SS-PW and
MS-PW) as well. This is useful especially in the case of end-to-end MS-PW) as well. This is useful especially in the case of end-to-end
static provisioned MS-PWs running over MPLS-TP where tunnel static provisioned MS-PWs running over MPLS-TP where tunnel
protection alone cannot be relied upon for end-to-end protection of protection alone cannot be relied upon for end-to-end protection of
PWs against S-PE failure. It also enables a uniform operational PWs against S-PE failure. It also enables a uniform operational
approach for protection at LSP and PW layers and an easier management approach for protection at LSP and PW layers and an easier management
integration for networks that already use RFCs 6378, 7271, and 7324. integration for networks that already use RFCs 6378, 7271, and 7324.
This Appendix is optional alternative approach to the one in The protection architectures are those defined in [RFC6378]. For the
purposes of this Appendix, we define the protection domain of a
point-to-point PW as consisting of two terminating PEs (T-PEs) and
the transport paths that connect them (see Figure 2).
+-----+ //=======================\\ +-----+
|T-PE1|// Working Path \\|T-PE2|
| /| |\ |
| ?< | | >? |
| \|\\ Protection Path //|/ |
+-----+ \\=======================// +-----+
|<-------Protection Domain------->|
Figure 2: Protection Domain
This Appendix is an optional alternative approach to the one in
Section 2, therefore all implementations MUST include the approach in Section 2, therefore all implementations MUST include the approach in
Section 2 even if this alternative approach is used. The operational Section 2 even if this alternative approach is used. The operational
considerations in Section 3 continue to apply when this approach is considerations in Section 3 continue to apply when this approach is
used, and operational care must be taken so that the endpoint T-PEs used, and operational care must be taken so that the endpoint T-PEs
are identically provisioned regarding the use of this document. are identically provisioned regarding the use of this document.
A.2. Encapsulation of the PSC Protocol for Pseudowires A.2. Encapsulation of the PSC Protocol for Pseudowires
The PSC protocol can be used to protect against defects on any LSP The PSC protocol can be used to protect against defects on any LSP
(segment, link or path). In the case of MS-PW, the PSC protocol can (segment, link or path). In the case of MS-PW, the PSC protocol can
 End of changes. 13 change blocks. 
24 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/