< draft-shawam-pwe3-ms-pw-protection-00.txt		draft-shawam-pwe3-ms-pw-protection-01.txt >
	Network Working Group H. van Helvoort		Network Working Group A. Malis
	Internet-Draft L. Andersson		Internet-Draft L. Andersson
	Intended status: Standards Track A. Malis		Updates: 6870 (if approved) Huawei Technologies Co., Ltd
	Expires: January 2, 2015 Huawei Technologies Co., Ltd		Intended status: Standards Track H. van Helvoort
			Expires: March 30, 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
	July 1, 2014		September 26, 2014
	Encapsulation for PSC for Multi-Segment Pseudowires		S-PE Outage Protection for Static Multi-Segment Pseudowires
	draft-shawam-pwe3-ms-pw-protection-00.txt		draft-shawam-pwe3-ms-pw-protection-01.txt
	Abstract		Abstract
	In RFC 6378 'MPLS Transport Profile (MPLS-TP) Linear Protection', as		In MPLS and MPLS-TP environments, statically provisioned Single-
	well as in the later updates of this RFC, the Protection State		Segment Pseudowires (SS-PWs) are protected against tunnel failure via
	Coordiantion (PSC) protocol was defined for MPLS LSPs only. This		MPLS-level and MPLS-TP-level tunnel protection. With statically
	draft extends RFC 6378 to be applicable for pseudowires as well.		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 PEs
			(S-PEs) along the path of the MS-PW. This document describes how to
			achieve this protection by updating the existing procedures in RFC
			6870.
	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 January 2, 2015.		This Internet-Draft will expire on March 30, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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
	2. Encapsulation of the PSC protocol for Pseudowires . . . . . . 2		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 3		2. Extension to RFC 6870 to Protect Statically Provisioned SS-
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3		PWs and MS-PWs . . . . . . . . . . . . . . . . . . . . . . . 3
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3		3. Operational Considerations . . . . . . . . . . . . . . . . . 3
	6. Normative References . . . . . . . . . . . . . . . . . . . . 3		4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 3		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
			6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
			7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
			7.1. Normative References . . . . . . . . . . . . . . . . . . 4
			7.2. Informative References . . . . . . . . . . . . . . . . . 4
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Introduction		1. Introduction
	In RFC 6378 'MPLS Transport Profile (MPLS-TP) Linear Protection'		As described in RFC 5659 [RFC5659], Multi-Segment Pseudowires (MS-
	[RFC6378], as well as in the later updates of this RFC in 'MPLS		PWs) consist of terminating PEs (T-PEs), switching PEs (S-PEs), and
	Transport Profile (MPLS-TP) Linear Protection to Match the		PW segments between the T-PEs at each of the MS-PW and the interior
	Operational Expectations of SDH, OTN and Ethernet Transport Network		S-PEs. In MPLS and MPLS-TP environments, statically provisioned
	Operators' [RFC7271] and in 'Updates to MPLS Transport Profile Linear		Single-Segment Pseudowires (SS-PWs) are protected against tunnel
	Protection' [I-D.ietf-mpls-psc-updates], the Protection State		failure via MPLS-level and MPLS-TP-level tunnel protection. With
	Coordination (PSC) protocol was defined for MPLS LSPs only.		statically provisioned Multi-Segment Pseudowires (MS-PWs), each PW
			segment of the MS-PW is likewise 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.
	This draft extends RFC 6378 to be applicable for pseudowires (PWs) as		RFC 6718 [RFC6718] provides a general framework for PW protection,
	well. This is useful especially in the case of end-to-end static		and RFC 6870 [RFC6870], which is based upon that framework, describes
	provisioned Multi-Segment PWs (MS-PWs) running over MPLS-TP where we		protection procedures for MS-PWs that are dynamically signaled using
	can't rely on tunnel protection alone for end-to- end protection of		LDP. This document describes how to achieve protection against S-PE
	PWs against switching PE (S-PE) failure.		failure in a static MS-PW by extending RFC 6870 to be applicable for
			statically provisioned MS-PWs pseudowires (PWs) as well.
	2. Encapsulation of the PSC protocol for Pseudowires		1.1. Requirements Language
	The PSC protocol can be used to protect against defects on any LSP		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	(segment, link or path). Linear protection protects an LSP end-to-		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	end and if a failure is detected, switches traffic over to another		document are to be interpreted as described in RFC 2119 [RFC2119].
	(redundant) set of resources.
	Obviously, the protected entity does not need to be of the same type		2. Extension to RFC 6870 to Protect Statically Provisioned SS-PWs and
	as the protecting, it is possible to protect a link by a path.		MS-PWs
	Likewise it is possible to protect a PW with a MS-PW.
	From a PSC protocol point of view it is possible to view a PW as a		Section 3.2.3 of RFC 6718 and Section A.5 of RFC 6870 document how to
	single hop LSP, and a MS-PW as a multiple hop LSP. The PSC protocol		use redundant MS-PWs to protect an MS-PW against S-PE failure. The
	will work just as specified in RFC 6378.		procedures in these RFCs 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.
	Thus the G-ACh carrying the PSC protocol information is placed in the		However, statically provisioned PWs (SS-PWs or MS-PWs) do not use the
	label stack directly beneath the PW identifier.		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
			their path. They also do not use the LDP protocol for status
			signaling. Rather, they use procedures defined in RFC 6478 [RFC6478]
			for status signaling via the PW OAM message using the PW Associated
			Channel Header (ACH). The PW Status TLV carried via this status
			signaling is itself identical to the PW Status TLV carried via LDP-
			based status signaling, including the identical PW Status Codes.
	3. Security Considerations		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
			primary PW. They use status codes transmitted between endpoint T-PEs
			using the PW Status TLV transmitted by LDP. For this management to
			apply to statically provisioned PWs, the PW status signaling defined
			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
			provided by RFC 6478 in the place of LDP-based status signaling, but
			otherwise operate identically as described in RFC 6870.
	The security considerations defined for RFC 6378 apply to this		3. Operational Considerations
	document as well. As this is simply a re-use of RFC 6378, there are
	no new security considerations.
	4. IANA Considerations		Because LDP is not used between the T-PEs for statically provisioned
			MS-PWs, the negotiation procedures described in RFC 6870 cannot be
			used. Thus, operational care must be taken so that the endpoint
			T-PEs are identically provisioned regarding the use of this document,
			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
			precedence of the secondary MS-PWs.
			4. Security Considerations
			The security considerations defined for RFC 6478 apply to this
			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
			document.
			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.
	5. Acknowledgements		6. Acknowledgements
	TBA		The authors would like to thank Matthew Bocci, Yaakov Stein, and
			David Sinicrope for their comments on this document.
	6. Normative References		7. References
	[I-D.ietf-mpls-psc-updates]		7.1. Normative References
	Osborne, E., "Updates to MPLS Transport Profile Linear
	Protection", draft-ietf-mpls-psc-updates-06 (work in
	progress), May 2014.
	[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear		Requirement Levels", BCP 14, RFC 2119, March 1997.
	Protection", RFC 6378, October 2011.
	[RFC7271] Ryoo, J., Gray, E., van Helvoort, H., D'Alessandro, A.,		[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci,
	Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-		"Pseudowire Status for Static Pseudowires", RFC 6478, May
	TP) Linear Protection to Match the Operational		2012.
	Expectations of Synchronous Digital Hierarchy, Optical
	Transport Network, and Ethernet Transport Network		[RFC6870] Muley, P. and M. Aissaoui, "Pseudowire Preferential
	Operators", RFC 7271, June 2014.		Forwarding Status Bit", RFC 6870, February 2013.
			7.2. Informative References
			[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
			Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
			October 2009.
			[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
			Redundancy", RFC 6718, August 2012.
	Authors' Addresses		Authors' Addresses
	Huub van Helvoort		Andrew G. Malis
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	Email: huub.van.helvoort@huawei.com		Email: agmalis@gmail.com
	Loa Andersson		Loa Andersson
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	Email: loa@mail01.huawei.com		Email: loa@mail01.huawei.com
	Andrew G. Malis		Huub van Helvoort
	Huawei Technologies Co., Ltd		Hai Gaoming BV
	Email: Andrew.Malis@huawei.com		Email: huubatwork@gmail.com
	Jongyoon Shin		Jongyoon Shin
	SK Telecom		SK Telecom
	Email: jongyoon.shin@sk.com		Email: jongyoon.shin@sk.com
	Lei Wang		Lei Wang
	China Mobile		China Mobile
	Email: wangleiyj@chinamobile.com		Email: wangleiyj@chinamobile.com
End of changes. 27 change blocks.
	68 lines changed or deleted		123 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/