draft-ietf-mpls-psc-updates-00.txt		draft-ietf-mpls-psc-updates-01.txt
	Network Working Group E. Osborne		Network Working Group E. Osborne
	Internet-Draft Cisco Systems		Internet-Draft
	Intended status: Standards Track October 21, 2013		Updates: RFC6378 (if approved) January 24, 2014
	Expires: April 24, 2014		Intended status: Standards Track
			Expires: July 28, 2014
	Updates to PSC		Updates to PSC
	draft-ietf-mpls-psc-updates-00		draft-ietf-mpls-psc-updates-01
	Abstract		Abstract
	This document contains four updates to the Protection State		This document contains four 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" . Two of the updates correct existing		(MPLS-TP) Linear Protection" . Two of the updates correct existing
	behavior. The third clears up a behavior which was not explained in		behavior. The third clarifies a behavior which was not explained in
	the RFC, and the fourth adds rules around handling capabilities		the RFC, and the fourth adds rules around handling capabilities
	mismatches.		mismatches.
	Requirements Language		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].
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 41		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 April 24, 2014.		This Internet-Draft will expire on July 28, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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. Incorrect local status after failure . . . . . . . . . . . . 2		2. Incorrect local status after failure . . . . . . . . . . . . 3
	3. Reversion deadlock due to a race condition . . . . . . . . . 3		3. Reversion deadlock due to a race condition . . . . . . . . . 3
	4. Clarifying PSC's behavior in the face of multiple inputs . . 4		4. Clarifying PSC's behavior in the face of multiple inputs . . 4
	5. Handling a capabilities mismatch . . . . . . . . . . . . . . 6		5. Handling a capabilities mismatch . . . . . . . . . . . . . . 6
	5.1. PT mismatch . . . . . . . . . . . . . . . . . . . . . . . 6		5.1. Protection Type mismatch . . . . . . . . . . . . . . . . 6
	5.2. R mismatch . . . . . . . . . . . . . . . . . . . . . . . 6		5.2. R mismatch . . . . . . . . . . . . . . . . . . . . . . . 7
	5.3. Unsupported modes . . . . . . . . . . . . . . . . . . . . 7		5.3. Unsupported modes . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		9.2. Informative References . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	This document contains four updates to PSC [RFC6378]. Three of them		This document contains four updates to PSC [RFC6378]. Three of them
	fix issues #2, #7 and #8 as identified in the ITU's liaison statement		address issues #2, #7 and #8 as identified in the ITU's liaison
	"Recommendation ITU-T G.8131/Y.1382 revision - Linear protection		statement "Recommendation ITU-T G.8131/Y.1382 revision - Linear
	switching for MPLS-TP networks" [LIAISON]. The fourth clears up a		protection switching for MPLS-TP networks" [LIAISON]. The fourth
	behavior which was not well explained in RFC6378. These updates are		clears up a behavior which was not well explained in RFC6378. These
	not changes to the protocol's packet format or to PSC's design, but		updates are not changes to the protocol's packet format or to PSC's
	are corrections and clarifications to specific aspects of the		design, but are corrections and clarifications to specific aspects of
	protocol's procedures.		the protocol's procedures.
			This document assumes familiarity with RFC6378 and its terms,
			conventions and acronyms. Any term used in this document but not
			defined herein can be found in RFC6378. In particular, this document
			shares the acronyms defined in RFC6378 section 2.1.
	2. Incorrect local status after failure		2. 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 is replaced		address this issue, the fourth bullet in section 4.3.3.3 of RFC6378
	with the following three bullets:		is replaced with the following three bullets:
	o If the current state is due to a local or remote Manual Switch, a		o If the current state is due to a local or remote Manual Switch, a
	local Signal Fail indication on the protection path SHALL cause		local Signal Fail indication on the protection path SHALL cause
	the LER to enter local Unavailable state and begin transmission of		the LER to enter local Unavailable state and begin transmission of
	an SF(0,0) message.		an SF(0,0) message.
	o If the LER is in local Protecting Administrative state due to a		o If the LER is in local Protecting Administrative state due to a
	local Forced Switch, a local Signal Fail indication on the		local Forced Switch, a local Signal Fail indication on the
	protection path SHALL be ignored.		protection path SHALL be ignored.
	skipping to change at page 3, line 39		skipping to change at page 3, line 50
	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
	receive node can take the received NR(0,1) as an indication that		receive node can take the received NR(0,1) as an indication that
	there is no error in the protection domain, and recovery procedures		there is no error in the protection domain, and recovery procedures
	(WTR or DNR) should begin.		(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:		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
	procedures. If the LER is configured for revertive behavior, it		procedures. If the LER is configured for revertive behavior, it
	enters into Wait-to-Restore state, starts the WTR timer, and		enters into Wait-to-Restore state, starts the WTR timer, and
	begins transmitting WTR(0,1). If the LER is configured for non-		begins transmitting WTR(0,1). If the LER is configured for non-
	revertive behavior, it enters into Do-Not-Revert state and begins		revertive behavior, it enters into Do-Not-Revert state and begins
	transmitting a DNR(0,1) message.		transmitting a DNR(0,1) message.
	Additionally, the final bullet in section 4.3.3.3 is changed from		Additionally, the final bullet in section 4.3.3.3 is changed from
	skipping to change at page 4, line 36		skipping to change at page 4, line 49
	RFC6378 does not sufficiently describe the behavior in the face of		RFC6378 does not sufficiently describe the behavior in the face of
	multiple inputs into the PSC Control Logic (one Local Request and one		multiple inputs into the PSC Control Logic (one Local Request and one
	Remote Request). This section clarifies the expected behavior.		Remote Request). This section clarifies the expected behavior.
	There are two cases to think about when considering dual inputs into		There are two cases to think about when considering dual inputs into
	the PSC Control logic. The first is when the same request is		the PSC Control logic. The first is when the same request is
	presented from both local and remote sources. One example of this		presented from both local and remote sources. One example of this
	case is a Forced Switch (FS) configured on both ends of an LSP. This		case is a Forced Switch (FS) configured on both ends of an LSP. This
	will result in the PSC Control logic receiving both a local FS and		will result in the PSC Control logic receiving both a local FS and
	remove FS. For convenience, this scenario is written as [L(FS),		remove FS. For convenience, this scenario is written as [L(FS),
	R(FS))]		R(FS))] - that is, Local(Forced Switch) and Remote(Forced Switch).
	The second case, which is handled in exactly the same way as the		The second case, which is handled in exactly the same way as the
	first, is when the two inputs into the PSC Control logic describe		first, is when the two inputs into the PSC Control logic describe
	different events. There are a number of variations on this case.		different events. There are a number of variations on this case.
	One example is when there is a Lockout of Protection from the Local		One example is when there is a Lockout of Protection from the Local
	request logic and a Forced Switch from the Remote PSC Request. This		request logic and a Signal Fail on the Working parh from the Remote
	is shortened to [L(LO), R(FS)].		PSC Request. This is shortened to [L(LO), R(SF-W)].
	In both cases the question is not how the PSC Control logic decides		In both cases the question is not how the PSC Control logic decides
	which of these is the one it acts upon. Section 4.3.2 of RFC6378		which of these is the one it acts upon. Section 4.3.2 of RFC6378
	lists the priority order, and prioritizes the local input over the		lists the priority order, and prioritizes the local input over the
	remote input in case both inputs are of the same priority. So in the		remote input in case both inputs are of the same priority. So in the
	first example it is the local SF that drives the PSC Control logic,		first example it is the local SF that drives the PSC Control logic,
	and in the second example it is the local Lockout which drives the		and in the second example it is the local Lockout which drives the
	PSC Control logic.		PSC Control logic.
	The point that this section clears up is around what happens when the		The point that this section clears up is around what happens when the
	highest priority input goes away. Consider the first case.		highest priority input goes away. Consider the first case.
	Initially, the PSC Control logic has [L(FS), R(FS)] and L(FS) is		Initially, the PSC Control logic has [L(FS), R(FS)] and L(FS) is
	driving PSC's behavior. When L(FS) is removed but R(FS) remains,		driving PSC's behavior. When L(FS) is removed but R(FS) remains,
	what does PSC do? A strict reading of the FSM would suggest that PSC		what does PSC do? A strict reading of the FSM would suggest that PSC
	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(FS)] and		The second case is similar. If a node starts with [L(LO), R(SF-W)]
	the local lockout is removed, a strict reading of the state machine		and the local lockout is removed, a strict reading of the state
	would suggest that the node transition from UA:LO:L to N, and then at		machine would suggest that the node transition from UA:LO:L to N, and
	some future time presumably notice the R(FS) and transition from N to		then at some future time presumably notice the R(SF-W) and transition
	PA:F:R. As with the first case, this is clearly not a useful		from N to PF:W:R. As with the first case, this is clearly not a
	behavior.		useful behavior.
	In both cases the request which was driving PSC's behavior was		In both cases the request which 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 a third case. Consider a node with [L(FS), R(LO)]. At some
	point in time the remote node replaces its Lockout request with a		point in time the remote node replaces its Lockout request with a
	skipping to change at page 6, line 25		skipping to change at page 6, line 38
	PSC has no explicit facility to negotiate any properties of the		PSC has no explicit facility to negotiate any properties of the
	protection domain. It does, however, have the ability to signal two		protection domain. It does, however, have the ability to signal two
	properties of that domain, via the Protection Type (PT) and Revertive		properties of that domain, via the Protection Type (PT) and Revertive
	(R) bits. RFC6378 specifies that if these bits do not match an		(R) bits. RFC6378 specifies that if these bits do not match an
	operator "SHALL [be notified]" (PT, section 4.2.3) or "SHOULD be		operator "SHALL [be notified]" (PT, section 4.2.3) or "SHOULD be
	notified" (R, section 4.2.4). However, there is no text which		notified" (R, section 4.2.4). However, there is no text which
	specifies the behavior of the end nodes of a protection domain in		specifies the behavior of the end nodes of a protection domain in
	case of a mismatch. This section provides that text, as requested by		case of a mismatch. This section provides that text, as requested by
	issue #7 in the liaison.		issue #7 in the liaison.
	5.1. PT mismatch		5.1. Protection Type mismatch
	The behavior of the protection domain depends on the exact PT		The behavior of the protection domain depends on the exact Protection
	mismatch. Section 4.2.3 of RFC6378 specifies three protection types		Type (PT) mismatch. Section 4.2.3 of RFC6378 specifies three
	- bidirectional switching using a permanent bridge, bidirectional		protection types - bidirectional switching using a permanent bridge,
	switching using a selector bridge, and unidirectional switching using		bidirectional switching using a selector bridge, and unidirectional
	a permanent bridge. They are abbreviated here as BP, BS and UP.		switching using a permanent bridge. They are abbreviated here as BP,
			BS and UP.
	There are three possible mismatches: [BP, UP], [BP, BS], and [UP,		There are three possible mismatches: [BP, UP], [BP, BS], and [UP,
	BS]. The priority is:		BS]. The priority is:
	UP > BS > BP		UP > BS > BP
	In other words:		In other words:
	o If the PT mismatch is {BP, UP}, the node transmitting BP MUST		o If the PT mismatch is {BP, UP}, the node transmitting BP MUST
	switch to UP mode if it is supported.		switch to UP mode if it is supported.
	skipping to change at page 8, line 18		skipping to change at page 8, line 31
	[RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive		[RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive
	Connectivity Verification, Continuity Check, and Remote		Connectivity Verification, Continuity Check, and Remote
	Defect Indication for the MPLS Transport Profile", RFC		Defect Indication for the MPLS Transport Profile", RFC
	6428, November 2011.		6428, November 2011.
	9.2. Informative References		9.2. Informative References
	[LIAISON] ITU-T SG15, "Liaison Statement: Recommendation ITU-T		[LIAISON] ITU-T SG15, "Liaison Statement: Recommendation ITU-T
	G.8131/Y.1382 revision - Linear protection switching for		G.8131/Y.1382 revision - Linear protection switching for
	MPLS-TP networks", , <https://datatracker.ietf.org/liaison		MPLS-TP networks", <https://datatracker.ietf.org/liaison/
	/1205/>.		1205/>.
	Author's Address		Author's Address
	Eric Osborne		Eric Osborne
	Cisco Systems
	Email: eosborne@cisco.com		Email: eric.osborne@notcom.com
End of changes. 20 change blocks.
	42 lines changed or deleted		48 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/