< draft-shawam-pwe3-ms-pw-protection-01.txt		draft-shawam-pwe3-ms-pw-protection-02.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: March 30, 2015 Hai Gaoming BV		Expires: April 13, 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
	September 26, 2014		October 10, 2014
	S-PE Outage Protection for Static Multi-Segment Pseudowires		S-PE Outage Protection for Static Multi-Segment Pseudowires
	draft-shawam-pwe3-ms-pw-protection-01.txt		draft-shawam-pwe3-ms-pw-protection-02.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 by updating the existing procedures in RFC
	6870.		6870. It also contains an optional approach based 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 March 30, 2015.		This Internet-Draft will expire on April 13, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 26 ¶		skipping to change at page 2, line 26 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	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 . . . . . . . . . . . . . . . . . 3		3. Operational Considerations . . . . . . . . . . . . . . . . . 5
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 4		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Normative References . . . . . . . . . . . . . . . . . . 4		7.1. Normative References . . . . . . . . . . . . . . . . . . 6
	7.2. Informative References . . . . . . . . . . . . . . . . . 4		7.2. Informative References . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5		Appendix A. Optional Linear Protection Approach . . . . . . . . 6
			A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 6
			A.2. Encapsulation of the PSC Protocol for Pseudowires . . . . 7
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	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), switching PEs (S-PEs), and
	PW segments between the T-PEs at each of the MS-PW and the interior		PW segments between the T-PEs at each of the MS-PW and the interior
	S-PEs. In MPLS and MPLS-TP environments, statically provisioned		S-PEs. In MPLS and MPLS-TP environments, statically provisioned
	Single-Segment Pseudowires (SS-PWs) are protected against tunnel		Single-Segment Pseudowires (SS-PWs) are protected against tunnel
	failure via MPLS-level and MPLS-TP-level tunnel protection. With		failure via MPLS-level and MPLS-TP-level tunnel protection. With
	statically provisioned Multi-Segment Pseudowires (MS-PWs), each PW		statically provisioned Multi-Segment Pseudowires (MS-PWs), each PW
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 12 ¶
	protection does not protect static MS-PWs from failures of S-PEs		protection does not protect static MS-PWs from failures of S-PEs
	along the path of the MS-PW.		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
			MPLS-TP Linear Protection. This approach, described in Appendix A,
			MUST be identically provisioned in the PE endpoints for the protected
			MS-PW in order to be used. See Appendix A for further details on
			this alternative approach.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Extension to RFC 6870 to Protect Statically Provisioned SS-PWs and		2. Extension to RFC 6870 to Protect Statically Provisioned SS-PWs and
	MS-PWs		MS-PWs
	Section 3.2.3 of RFC 6718 and Section A.5 of RFC 6870 document how to		Section 3.2.3 of RFC 6718 and Section A.5 of RFC 6870 document how to
	use redundant MS-PWs to protect an MS-PW against S-PE failure. The		use redundant MS-PWs to protect an MS-PW against S-PE failure in the
	procedures in these RFCs rely on LDP-based PW status signaling to		case of a singly-homed CE, using the following network model from RFC
	signal the state of the primary MS-PW that is being protected, and		6718:
	the precedence in which redundant MS-PW(s) should be used to protect
	the primary MS-PW should it fail. These procedures make use of		Native |<----------- Pseudowires ----------->| Native
	information carried by the PW Status TLV, which for dynamically		Service | | Service
	signaled PWs is carried by the LDP protocol.		(AC) | |<-PSN1-->| |<-PSN2-->| | (AC)
			| V V V V V V |
			| +-----+ +-----+ +-----+ |
			+----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+
			| |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| |
			| CE1| | |=========| |=========| | | CE2|
			| | +-----+ +-----+ +-----+ | |
			+----+ |.||.| |.||.| +----+
			|.||.| +-----+ |.||.|
			|.||.|=========| |========== .||.|
			|.||...PW2-Seg1......|.PW2-Seg2...||.|
			|.| ===========|S-PE2|============ |.|
			|.| +-----+ |.|
			|.|============+-----+============= .|
			|.....PW3-Seg1.| | PW3-Seg2......|
			==============|S-PE3|===============
			| |
			+-----+
			Figure 1: Single-Homed CE with Redundant MS-PWs
			In this figure, CE1 is connected to PE1 and CE2 is connected to PE2.
			There are three MS PWs. PW1 is switched at S-PE1, PW2 is switched at
			S-PE2, and PW3 is switched at S-PE3. This scenario provides N:1
			protection against S-PE failure for the subset of the path of the
			emulated service from T-PE1 to T-PE2.
			The procedures in RFCs 6718 and 6870 rely on LDP-based PW status
			signaling to signal the state of the primary MS-PW that is being
			protected, and the precedence in which redundant MS-PW(s) should be
			used to protect the primary MS-PW should it fail. These procedures
			make use of information carried by the PW Status TLV, which for
			dynamically signaled PWs is carried by the LDP protocol.
	However, statically provisioned PWs (SS-PWs or MS-PWs) do not use the		However, statically provisioned PWs (SS-PWs or MS-PWs) do not use the
	LDP protocol for PW set and signaling, rather they are provisioned by		LDP protocol for PW set and signaling, rather they are provisioned by
	network management systems or other means at each T-PE and S-PE along		network management systems or other means at each T-PE and S-PE along
	their path. They also do not use the LDP protocol for status		their path. They also do not use the LDP protocol for status
	signaling. Rather, they use procedures defined in RFC 6478 [RFC6478]		signaling. Rather, they use procedures defined in RFC 6478 [RFC6478]
	for status signaling via the PW OAM message using the PW Associated		for status signaling via the PW OAM message using the PW Associated
	Channel Header (ACH). The PW Status TLV carried via this status		Channel Header (ACH). The PW Status TLV carried via this status
	signaling is itself identical to the PW Status TLV carried via LDP-		signaling is itself identical to the PW Status TLV carried via LDP-
	based status signaling, including the identical PW Status Codes.		based status signaling, including the identical PW Status Codes.
	skipping to change at page 4, line 14 ¶		skipping to change at page 5, line 29 ¶
	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.
	4. Security Considerations		4. Security Considerations
	The security considerations defined for RFC 6478 apply to this		The security considerations defined for RFC 6478 apply to this
	document as well. As the security considerations in RFCs 6718 and		document as well. As the security considerations in RFCs 6718 and
	6870 are related to their use of LDP, they are not required for this		6870 are related to their use of LDP, they are not required for this
	document.		document.
			If the alternative approach in Appendix A is used, then the security
			considerations defined for RFCs 6378, 7271, and 7324 also apply.
	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, and
	David Sinicrope for their comments on this document.		David Sinicrope for their comments on this document.
	7. References		Figure 1 and the explanatory paragraph following the figure were
			taken from RFC 6718.
			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
			A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
			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,
	"Pseudowire Status for Static Pseudowires", RFC 6478, May		"Pseudowire Status for Static Pseudowires", RFC 6478, May
	2012.		2012.
	[RFC6870] Muley, P. and M. Aissaoui, "Pseudowire Preferential		[RFC6870] Muley, P. and M. Aissaoui, "Pseudowire Preferential
	Forwarding Status Bit", RFC 6870, February 2013.		Forwarding Status Bit", RFC 6870, February 2013.
			[RFC7271] Ryoo, J., Gray, E., van Helvoort, H., D'Alessandro, A.,
			Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-
			TP) Linear Protection to Match the Operational
			Expectations of Synchronous Digital Hierarchy, Optical
			Transport Network, and Ethernet Transport Network
			Operators", RFC 7271, June 2014.
			[RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear
			Protection", RFC 7324, July 2014.
	7.2. Informative References		7.2. Informative References
	[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-		[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
	Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,		Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
	October 2009.		October 2009.
	[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire		[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
	Redundancy", RFC 6718, August 2012.		Redundancy", RFC 6718, August 2012.
			Appendix A. Optional Linear Protection Approach
			A.1. Introduction
			In "MPLS Transport Profile (MPLS-TP) Linear Protection" [RFC6378], as
			well as in the later updates of this RFC in "MPLS Transport Profile
			(MPLS-TP) Linear Protection to Match the Operational Expectations of
			SDH, OTN and Ethernet Transport Network Operators" [RFC7271] and in
			"Updates to MPLS Transport Profile Linear Protection" [RFC7324], the
			Protection State Coordination (PSC) protocol was defined for MPLS
			LSPs only.
			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
			static provisioned MS-PWs running over MPLS-TP where tunnel
			protection alone cannot be relied upon for end-to-end protection of
			PWs against S-PE failure. It also enables a uniform operational
			approach for protection at LSP and PW layers and an easier management
			integration for networks that already use RFCs 6378, 7271, and 7324.
			This Appendix is optional alternative approach to the one in
			Section 2, therefore all implementations MUST include the approach in
			Section 2 even if this alternative approach is used. The operational
			considerations in Section 3 continue to apply when this approach is
			used, and operational care must be taken so that the endpoint T-PEs
			are identically provisioned regarding the use of this document.
			A.2. Encapsulation of the PSC Protocol for Pseudowires
			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
			also protect failed intermediate nodes (S-PE). Linear protection
			protects an LSP or PW end-to-end and if a failure is detected,
			switches traffic over to another (redundant) set of resources.
			Obviously, the protected entity does not need to be of the same type
			as the protecting. For example, it is possible to protect a link by
			a path. Likewise it is possible to protect a SS-PW with a MS-PW and
			vice versa.
			From a PSC protocol point of view it is possible to view a SS-PW as a
			single hop LSP, and a MS-PW as a multiple hop LSP. Thus, this
			provides end-to-end protection for the SS-PW or MS-PW. The G-ACh
			carrying the PSC protocol information is placed in the label stack
			directly beneath the PW identifier. The PSC protocol will then work
			as specified in RFCs 6378, 7271, and 7324.
	Authors' Addresses		Authors' Addresses
	Andrew G. Malis		Andrew G. Malis
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	Email: agmalis@gmail.com		Email: agmalis@gmail.com
	Loa Andersson		Loa Andersson
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
End of changes. 14 change blocks.
	21 lines changed or deleted		129 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/