draft-ietf-mpls-psc-updates-05.txt		draft-ietf-mpls-psc-updates-06.txt
	Network Working Group E. Osborne		Network Working Group E. Osborne
	Internet-Draft		Internet-Draft
	Updates: 6378 (if approved) April 22, 2014		Updates: 6378 (if approved) May 29, 2014
	Intended status: Standards Track		Intended status: Standards Track
	Expires: October 24, 2014		Expires: November 30, 2014
	Updates to MPLS Transport Profile Linear Protection		Updates to MPLS Transport Profile Linear Protection
	draft-ietf-mpls-psc-updates-05		draft-ietf-mpls-psc-updates-06
	Abstract		Abstract
	This document contains a number of updates to the Protection State		This document contains a number of updates to the Protection State
	Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile		Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile
	(MPLS-TP) Linear Protection". These updates provide some rules and		(MPLS-TP) Linear Protection". These updates provide some rules and
	recommendations around the use of TLVs in PSC, address some issues		recommendations around the use of TLVs in PSC, address some issues
	raised in an ITU-T liaison statement, and clarify PSC's behavior in a		raised in an ITU-T liaison statement, and clarify PSC's behavior in a
	case not well explained in RFC6378.		case not well explained in RFC6378.
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	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 October 24, 2014.		This Internet-Draft will expire on November 30, 2014.
	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. Message Formatting and Error Handling . . . . . . . . . . . . 3		2. Message Formatting and Error Handling . . . . . . . . . . . . 3
	2.1. Format on the wire . . . . . . . . . . . . . . . . . . . 3		2.1. PSC TLV Format . . . . . . . . . . . . . . . . . . . . . 3
	2.2. PSC TLV Format . . . . . . . . . . . . . . . . . . . . . 3		2.2. Error handling . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Error handling . . . . . . . . . . . . . . . . . . . . . 3		2.2.1. Malformed messages . . . . . . . . . . . . . . . . . 4
	2.3.1. Malformed messages . . . . . . . . . . . . . . . . . 4		2.2.2. Well-formed but unknown or unexpected TLV . . . . . . 4
	2.3.2. Well-formed but unexpected TLV . . . . . . . . . . . 4		3. Incorrect local status after failure . . . . . . . . . . . . 5
	3. Incorrect local status after failure . . . . . . . . . . . . 4
	4. Handling a capabilities mismatch . . . . . . . . . . . . . . 5		4. Handling a capabilities mismatch . . . . . . . . . . . . . . 5
	4.1. Protection Type mismatch . . . . . . . . . . . . . . . . 5		4.1. Protection Type mismatch . . . . . . . . . . . . . . . . 5
	4.2. R mismatch . . . . . . . . . . . . . . . . . . . . . . . 6		4.2. R mismatch . . . . . . . . . . . . . . . . . . . . . . . 6
	4.3. Unsupported modes . . . . . . . . . . . . . . . . . . . . 6		4.3. Unsupported modes . . . . . . . . . . . . . . . . . . . . 6
	5. Reversion deadlock due to a race condition . . . . . . . . . 6		5. Reversion deadlock due to a race condition . . . . . . . . . 6
	6. Clarifying PSC's behavior in the face of multiple inputs . . 7		6. Clarifying PSC's behavior in the face of multiple inputs . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . 10		10.2. Informative References . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	This document contains a number of updates to PSC [RFC6378]. One		This document contains a number of updates to PSC [RFC6378]. One
	provides some rules and recommendations around the use of TLVs in		provides some rules and recommendations around the use of TLVs in
	PSC. Three of them address issues #2, #7 and #8 as identified in the		PSC. Three of them address issues #2, #7 and #8 as identified in the
	ITU's liaison statement "Recommendation ITU-T G.8131/Y.1382 revision		ITU's liaison statement "Recommendation ITU-T G.8131/Y.1382 revision
	- Linear protection switching for MPLS-TP networks" [LIAISON].		- Linear protection switching for MPLS-TP networks" [LIAISON].
	Another clears up a behavior which was not well explained in RFC6378.		Another clears up a behavior which was not well explained in RFC6378.
	These updates are not changes to the protocol's packet format or to		These updates are not changes to the protocol's packet format or to
	PSC's design, but are corrections and clarifications to specific		PSC's design, but are corrections and clarifications to specific
	aspects of the protocol's procedures.		aspects of the protocol's procedures. This document does not
			introduce backward compatibility issues with implementations of RFC
			6378.
			It should be noted that [I-D.ietf-mpls-tp-psc-itu] contains protocol
			mechanisms for an alternate mode of operating MPLS-TP PSC. Those
			modes are built on the message structures and procedures of [RFC6378]
			and so, while this document does not update
			[I-D.ietf-mpls-tp-psc-itu], it has an impact on that work through its
			update to [RFC6378].
	This document assumes familiarity with RFC6378 and its terms,		This document assumes familiarity with RFC6378 and its terms,
	conventions and acronyms. Any term used in this document but not		conventions and acronyms. Any term used in this document but not
	defined herein can be found in RFC6378. In particular, this document		defined herein can be found in RFC6378. In particular, this document
	shares the acronyms defined in RFC6378 section 2.1.		shares the acronyms defined in RFC6378 section 2.1.
	2. Message Formatting and Error Handling		2. Message Formatting and Error Handling
	This section covers message formatting, as well as some recommended		This section covers message formatting, as well as some recommended
	error checking.		error checking.
	2.1. Format on the wire		2.1. PSC TLV Format
	All integer fields in the PSC TLV are encoded as unsigned integers in
	network bit order.
	2.2. PSC TLV Format
	[RFC6378] provides the capability to carry TLVs in the PSC messages.		[RFC6378] provides the capability to carry TLVs in the PSC messages.
	This section defines the format to be used by all such TLVs. All		All fields are encoded in network byte order. Each TLV contains
	fields are encoded in network byte order.		three fields, as follows:
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Value |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type field (T):		Type field (T):
	A two octet field that encodes a type value. The type values are		A two octet field that encodes a type value. The type values are
	recorded in the IANA registry "MPLS PSC TLV Registry".		recorded in the IANA registry "MPLS PSC TLV Registry".
	Length field (L) :		Length field (L) :
	A two octet field that encodes the length in octets of the Value		A two octet field that encodes the length in octets of the Value
	field.		field.
	The TLV Length is the sum of the lengths of all TLVs in the message.
	The length of a TLV is the sum of the lengths of the three TLV
	fields, i.e., the the length of the value field + 4.
	The value of this field MUST be a multiple of 4.		The value of this field MUST be a multiple of 4.
	Value field (V) :		Value field (V) :
	The contents of the TLV. This field MUST be a multiple of 4 octets		The payload of the TLV. The length of this field (which is the value
	and so may contain explicit padding.		of the Length field) MUST be a multiple of 4 octets, and so this
			field may contain explicit padding. The length of each single TLV is
			the sum of the lengths of its three fields: the length of the value
			field + 4. The overall TLV Length field in the PSC message contains
			the total length of all TLVs in octets.
	2.3. Error handling		2.2. Error handling
	It is recommended to implement error and bounds checking to ensure		It is recommended to implement error and bounds checking to ensure
	that received messages, if improperly formatted, are handled in such		that received messages, if improperly formatted, are handled in such
	a way to minimize the impact of this formatting on the behavior of		a way to minimize the impact of this formatting on the behavior of
	the network and its devices. This section covers two such areas -		the network and its devices. This section covers two such areas -
	malformed messages and well-formed but unexpected TLVs.		malformed messages and well-formed but unexpected TLVs.
	Neither of these sections is intended to limit the error or bounds		Neither of these sections is intended to limit the error or bounds
	checking a device performs. The recommendations here should be taken		checking a device performs. The recommendations herein should be
	as a starting point.		taken as a starting point.
	2.3.1. Malformed messages		2.2.1. Malformed messages
	A implementation SHOULD:		A implementation SHOULD:
	o Ensure any fields prior to TLV Length are consistent with RFC		o Ensure any fields prior to TLV Length are consistent with RFC
	6378, particularly Section 4.2.		6378, particularly Section 4.2.
	o Ensure the overall length of the message matches the value in the		o Ensure the overall length of the message matches the value in the
	TLV Length + 12.		TLV Length + 12.
	o Check that the sum of the lengths of all TLVs matches the value in		o Check that the sum of the lengths of all TLVs matches the value in
	the TLV Length.		the TLV Length.
	If an implementation receives a message which fails any malformed		If an implementation receives a message which fails any malformed
	message checks, it MUST drop the message and SHOULD alert the		message checks, it MUST drop the message and SHOULD alert the
	operator to the malformed message. The method(s) used to alert the		operator to the malformed message. The method(s) used to alert the
	operator are outside the scope of this document, but may include		operator are outside the scope of this document, but may include
	things like syslog or console messages.		things like syslog or console messages.
	2.3.2. Well-formed but unexpected TLV		2.2.2. Well-formed but unknown or unexpected TLV
	If a message is deemed to be properly formed, an implementation		If a message is deemed to be properly formed, an implementation
	SHOULD check all TLVs to ensure that it knows what to do with them.		SHOULD check all TLVs to ensure that it knows what to do with them.
	A well-formed but unknown TLV value MUST be ignored, and the rest of		A well-formed but unknown or unexpected TLV value MUST be ignored,
	the message processesed as if the ignored TLV did not exist. An		and the rest of the message processed as if the ignored TLV did not
	implementation detecting a malformed TLV SHOULD alert the operator as		exist. An implementation detecting a malformed TLV SHOULD alert the
	described in Section 2.3.1.		operator as described in Section 2.2.1.
	3. Incorrect local status after failure		3. Incorrect local status after failure
	Issue #2 in the liaison identifies a case where a strict reading of		Issue #2 in the liaison identifies a case where a strict reading of
	RFC6378 leaves a node reporting an inaccurate status:		RFC6378 leaves a node reporting an inaccurate status:
	A node can end up sending incorrect status - NR(0,1) - despite the		A node can end up sending incorrect status - NR(0,1) - despite the
	failure of the protection LSP (P-LSP). This is clearly not correct,		failure of the protection LSP (P-LSP). This is clearly not correct,
	as a node should not be sending NR if it has a local failure. To		as a node should not be sending NR if it has a local failure. To
	address this issue, the fourth bullet in section 4.3.3.3 of RFC6378		address this issue, the fourth bullet in section 4.3.3.3 of RFC6378
	skipping to change at page 6, line 24		skipping to change at page 6, line 40
	An implementation may not support all three PT modes and/or both R		An implementation may not support all three PT modes and/or both R
	modes, and thus a pair of nodes may be unable to converge on a common		modes, and thus a pair of nodes may be unable to converge on a common
	mode. This creates a permanent mismatch, resolvable only by operator		mode. This creates a permanent mismatch, resolvable only by operator
	intervention. An implementation SHOULD alert the operator to an		intervention. An implementation SHOULD alert the operator to an
	irreconcilable mismatch.		irreconcilable mismatch.
	It is desirable to allow the protection domain to function in a non-		It is desirable to allow the protection domain to function in a non-
	failure mode even if there is a mismatch, as the mismatches of PT or		failure mode even if there is a mismatch, as the mismatches of PT or
	R have to do with how nodes recover from a failure. An		R have to do with how nodes recover from a failure. An
	implementation SHOULD allow traffic to be sent on the Working LSP as		implementation SHOULD allow traffic to be sent on the Working LSP as
	long as there is no failure (e.g. NR state) regardless of any PT or R		long as there is no failure (e.g. NR state) regardless of any PT or
	mismatch.		R mismatch.
	If there is a trigger which would cause the protection LSP to be		If there is a trigger which would cause the protection LSP to be
	used, such as SF or MS, a node MUST NOT use the protection LSP to		used, such as SF or MS, a node MUST NOT use the protection LSP to
	carry traffic.		carry traffic.
	5. Reversion deadlock due to a race condition		5. Reversion deadlock due to a race condition
	Issue #8 in the liaison identifies a deadlock case where each node		Issue #8 in the liaison identifies a deadlock case where each node
	can end up sending NR(0,1) when it should instead be in the process		can end up sending NR(0,1) when it should instead be in the process
	of recovering from the failure (i.e. entering into WTR or DNR, as		of recovering from the failure (i.e. entering into WTR or DNR, as
	appropriate for the protection domain). The root of the issue is		appropriate for the protection domain). The root of the issue is
	that a pair of nodes can simultaneously enter WTR state, receive an		that a pair of nodes can simultaneously enter WTR state, receive an
	out of date SF-W indication and transition into a remotely triggered		out of date SF-W indication and transition into a remotely triggered
	WTR, and remain in remotely triggered WTR waiting for the other end		WTR, and remain in remotely triggered WTR waiting for the other end
	to trigger a change in status.		to trigger a change in status.
	In the case identified in issue #8, each node can end up sending		In the case identified in issue #8, each node can end up sending
	NR(0,1), which is an indication that the transmitting node has no		NR(0,1), which is an indication that the transmitting node has no
	local failure, but is instead reacting to the remote SF-W. If a node		local failure, but is instead reacting to the remote SF-W. If a node
	which receives NR(0,1) is in fact not indicating a local error, the		which receives NR(0,1) is in fact not indicating a local error, the
	correct behavior for the receiving node is to take the received		correct behavior for the receiving node is to take the received
	NR(0,1) as an indication that there is no error in the protection		NR(0,1) as an indication that there is no error in the protection
	domain, and recovery procedures (WTR or DNR) should begin.		domain, and recovery procedures (WTR or DNR) should begin.
	This is addressed by adding the following text as the penultimate		This is addressed by adding the following text as the penultimate
	bullet in section 4.3.3.4 of RFC6378:		bullet in section 4.3.3.4 of RFC6378:
	o If a node is in Protecting Failure state due to a remote SF-W and		o If a node is in Protecting Failure state due to a remote SF-W and
	receives NR(0,1), this SHALL cause the node to begin recovery		receives NR(0,1), this SHALL cause the node to begin recovery
	skipping to change at page 8, line 32		skipping to change at page 8, line 49
	transition from PA:F:L into N, and at some future time (perhaps after		transition from PA:F:L into N, and at some future time (perhaps after
	the remote request refreshes) PSC would transition from N to PA:F:R.		the remote request refreshes) PSC would transition from N to PA:F:R.
	This is an unreasonable behavior, as there is no sensible		This is an unreasonable behavior, as there is no sensible
	justification for a node behaving as if things were normal (i.e., N		justification for a node behaving as if things were normal (i.e., N
	state) when it is clear that they are not.		state) when it is clear that they are not.
	The second case is similar. If a node starts with [L(LO), R(SF-W)]		The second case is similar. If a node starts with [L(LO), R(SF-W)]
	and the local lockout is removed, a strict reading of the state		and the local lockout is removed, a strict reading of the state
	machine would suggest that the node transition from UA:LO:L to N, and		machine would suggest that the node transition from UA:LO:L to N, and
	then at some future time presumably notice the R(SF-W) and transition		then at some future time presumably notice the R(SF-W) and transition
	from N to PF:W:R. As with the first case, this is clearly not a		from N to PF:W:R. As with the first case, this is clearly not a
	useful behavior.		useful behavior.
	In both cases the request that was driving PSC's behavior was		In both cases the request that was driving PSC's behavior was
	removed. What should happen is that the PSC Control logic should,		removed. What should happen is that the PSC Control logic should,
	upon removal of an input, immediately reevaluate all other inputs to		upon removal of an input, immediately reevaluate all other inputs to
	decide on the next course of action. This requires an implementation		decide on the next course of action. This requires an implementation
	to store the most recent local and remote inputs regardless of their		to store the most recent local and remote inputs regardless of their
	eventual use as triggers for the PSC Control Logic.		eventual use as triggers for the PSC Control Logic.
	There is a third case. Consider a node with [L(FS), R(LO)]. At some		There is also a third case. Consider a node with [L(FS), R(LO)]. At
	point in time the remote node replaces its Lockout request with a		some point in time the remote node replaces its Lockout request with
	Signal Fail on Working, so that the inputs into the PSC Control logic		a Signal Fail on Working, so that the inputs into the PSC Control
	on the receiving node go to [L(FS), R(SF-W)]. Similar to the first		logic on the receiving node go to [L(FS), R(SF-W)]. Similar to the
	two cases, the node should immediately reevaluate both its local and		first two cases, the node should immediately reevaluate both its
	remote inputs to determine the highest priority among them, and act		local and remote inputs to determine the highest priority among them,
	on that input accordingly. That is in fact what happens, as defined		and act on that input accordingly. That is in fact what happens, as
	in Section 4.3.3:		defined in Section 4.3.3:
	"When a LER is in a remote state, i.e.,, state transition in reaction		"When a LER is in a remote state, i.e., state transition in reaction
	to a PSC message received from the far-end LER, and receives a new		to a PSC message received from the far-end LER, and receives a new
	PSC message from the far-end LER that indicates a contradictory		PSC message from the far-end LER that indicates a contradictory
	state, e.g., in remote Unavailable state receiving a remote FS(1,1)		state, e.g., in remote Unavailable state receiving a remote FS(1,1)
	message, then the PSC Control logic SHALL reevaluate all inputs (both		message, then the PSC Control logic SHALL reevaluate all inputs (both
	the local input and the remote message) as if the LER is in the		the local input and the remote message) as if the LER is in the
	Normal state."		Normal state."
	This section extends that paragraph to handle the first two cases.		This section extends that paragraph to handle the first two cases.
	The essence of the quoted paragraph is that when faced with multiple		The essence of the quoted paragraph is that when faced with multiple
	inputs, PSC must reevaluate any changes as if it was in Normal state.		inputs, PSC must reevaluate any changes as if it was in Normal state.
	skipping to change at page 9, line 28		skipping to change at page 9, line 44
	"The PSC Control logic may simultaneously have Local and Remote		"The PSC Control logic may simultaneously have Local and Remote
	requests, and the highest priority of these requests ultimately		requests, and the highest priority of these requests ultimately
	drives the behavior of the PSC Control logic. When this highest		drives the behavior of the PSC Control logic. When this highest
	priority request is removed or is replaced with another input, then		priority request is removed or is replaced with another input, then
	the PSC Control logic SHALL immediately reevaluate all inputs (both		the PSC Control logic SHALL immediately reevaluate all inputs (both
	the local input and the remote message), transitioning into a new		the local input and the remote message), transitioning into a new
	state only upon reevaluation of all inputs".		state only upon reevaluation of all inputs".
	7. Security Considerations		7. Security Considerations
	These changes and clarifications raise no new security concerns.		These changes and clarifications raise no new security concerns. RFC
			6941 [RFC6941] provides the baseline security discussion for MPLS-TP,
			and PSC (both RFC 6378 and this document) fall under that umbrella.
			Additionally, Section 2.2 clarifies how to react to malformed or
			unexpected messages.
	8. IANA Considerations		8. IANA Considerations
	IANA is requested to mark the value 0 in the "MPLS PSC TLV Registry"		IANA is requested to mark the value 0 in the "MPLS PSC TLV Registry"
	as "Reserved, not to be allocated" and to update the references to		as "Reserved, not to be allocated" and to update the references to
	show [RFC6378] and [RFC-ietf-mpls-psc-updates-04]. Note that this		show [RFC6378] and [RFC-ietf-mpls-psc-updates-04]. Note that this
	action provides documentation of an action already taken by IANA but		action provides documentation of an action already taken by IANA but
	not recorded in RFC 6378.		not recorded in RFC 6378.
	9. Acknowledgements		9. Acknowledgements
	skipping to change at page 10, line 11		skipping to change at page 10, line 33
	[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.
	10.2. Informative References		10.2. Informative References
	[LIAISON] ITU-T SG15, "Liaison Statement: Recommendation ITU-T		[I-D.ietf-mpls-tp-psc-itu]
	G.8131/Y.1382 revision - Linear protection switching for		Ryoo, J., Gray, E., Helvoort, H., D'Alessandro, A.,
	MPLS-TP networks", <https://datatracker.ietf.org/liaison/		Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-
	1205/>.		TP) Linear Protection to Match the Operational
			Expectations of SDH, OTN and Ethernet Transport Network
			Operators", draft-ietf-mpls-tp-psc-itu-04 (work in
			progress), March 2014.
			[LIAISON] ITU-T SG15, "Liaison Statement: Recommendation ITU-T G
			.8131/Y.1382 revision - Linear protection switching for
			MPLS-TP networks", <https://datatracker.ietf.org/
			liaison/1205/>.
			[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
			Graveman, "MPLS Transport Profile (MPLS-TP) Security
			Framework", RFC 6941, April 2013.
	Author's Address		Author's Address
	Eric Osborne		Eric Osborne
	Email: eric.osborne@notcom.com		Email: eric.osborne@notcom.com
End of changes. 24 change blocks.
	57 lines changed or deleted		84 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/