draft-ietf-mpls-psc-updates-06.txt   rfc7324.txt 
Network Working Group E. Osborne Internet Engineering Task Force (IETF) E. Osborne
Internet-Draft Request for Comments: 7324 July 2014
Updates: 6378 (if approved) May 29, 2014 Updates: 6378
Intended status: Standards Track Category: Standards Track
Expires: November 30, 2014 ISSN: 2070-1721
Updates to MPLS Transport Profile Linear Protection Updates to MPLS Transport Profile Linear Protection
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 RFC 6378, "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 RFC 6378.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 30, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7324.
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Message Formatting and Error Handling . . . . . . . . . . . . 3 2. Message Formatting and Error Handling . . . . . . . . . . . . 3
2.1. PSC TLV Format . . . . . . . . . . . . . . . . . . . . . 3 2.1. PSC TLV Format . . . . . . . . . . . . . . . . . . . . . 3
2.2. Error handling . . . . . . . . . . . . . . . . . . . . . 4 2.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Malformed messages . . . . . . . . . . . . . . . . . 4 2.2.1. Malformed Messages . . . . . . . . . . . . . . . . . 4
2.2.2. Well-formed but unknown or unexpected TLV . . . . . . 4 2.2.2. Well-Formed but Unknown or Unexpected TLV . . . . . . 4
3. Incorrect local status after failure . . . . . . . . . . . . 5 3. Incorrect Local Status after Failure . . . . . . . . . . . . 5
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 . . . . . . . . . 7
6. Clarifying PSC's behavior in the face of multiple inputs . . 7 6. Clarifying PSC's Behavior in the Face of Multiple Inputs . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 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 the updates address issues #2, #7, and #8 as
ITU's liaison statement "Recommendation ITU-T G.8131/Y.1382 revision identified in the ITU's liaison statement "Recommendation ITU-T
- Linear protection switching for MPLS-TP networks" [LIAISON]. G.8131/Y.1382 revision - Linear protection switching for MPLS-TP
Another clears up a behavior which was not well explained in RFC6378. networks" [LIAISON]. Another clears up a behavior that was not well
These updates are not changes to the protocol's packet format or to explained in RFC 6378. These updates are not changes to the
PSC's design, but are corrections and clarifications to specific protocol's packet format or to PSC's design; they are corrections and
aspects of the protocol's procedures. This document does not clarifications to specific aspects of the protocol's procedures.
introduce backward compatibility issues with implementations of RFC This document does not introduce backward compatibility issues with
6378. implementations of RFC 6378.
It should be noted that [I-D.ietf-mpls-tp-psc-itu] contains protocol It should be noted that [RFC7271] contains protocol mechanisms for an
mechanisms for an alternate mode of operating MPLS-TP PSC. Those alternate mode of operating MPLS-TP PSC. Those modes are built on
modes are built on the message structures and procedures of [RFC6378] the message structures and procedures of [RFC6378], and so, while
and so, while this document does not update this document does not update [RFC7271], it has an impact on that
[I-D.ietf-mpls-tp-psc-itu], it has an impact on that work through its work through its update to [RFC6378].
update to [RFC6378].
This document assumes familiarity with RFC6378 and its terms, This document assumes familiarity with RFC 6378 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 RFC 6378. In particular, this
shares the acronyms defined in RFC6378 section 2.1. document shares the acronyms defined in Section 2.1 of RFC 6378.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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. PSC TLV Format 2.1. 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.
All fields are encoded in network byte order. Each TLV contains All fields are encoded in network byte order. Each TLV contains
three fields, as follows: three fields, as follows:
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | 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
field.
The value of this field MUST be a multiple of 4. A two-octet field that encodes the length in octets of the Value
field. The value of this field MUST be a multiple of 4.
Value field (V) : Value field (V):
The payload of the TLV. The length of this field (which is the value The payload of the TLV. The length of this field (which is the value
of the Length field) MUST be a multiple of 4 octets, and so this 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 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 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 field + 4. The overall TLV Length field in the PSC message contains
the total length of all TLVs in octets. the total length of all TLVs in octets.
2.2. 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 This text is not intended to limit the error or bounds checking a
checking a device performs. The recommendations herein should be device performs. The recommendations herein should be taken as a
taken as a starting point. starting point.
2.2.1. Malformed messages 2.2.1. Malformed Messages
A implementation SHOULD: An 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 of that document.
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 that 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.2.2. Well-formed but unknown or 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 or unexpected TLV value MUST be ignored, A well-formed but unknown or unexpected TLV value MUST be ignored,
and the rest of the message processed as if the ignored TLV did not and the rest of the message processed as if the ignored TLV did not
exist. An implementation detecting a malformed TLV SHOULD alert the exist. An implementation detecting a malformed TLV SHOULD alert the
operator as described in Section 2.2.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 statement identifies a case where a strict
RFC6378 leaves a node reporting an inaccurate status: reading of RFC 6378 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 RFC 6378
is replaced 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.
o If the LER is in remote Protecting Administrative state due to a o If the LER is in remote Protecting Administrative state due to a
remote Forced Switch, a local Signal Fail indication on the remote Forced Switch, a local Signal Fail indication on the
protection path SHALL cause the LER to remain in remote Protecting protection path SHALL cause the LER to remain in remote Protecting
administrative state and transmit an SF(0,1) message. administrative state and transmit an SF(0,1) message.
4. Handling a capabilities mismatch 4. Handling a Capabilities Mismatch
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. RFC 6378 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 that
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 statement.
4.1. Protection Type mismatch 4.1. Protection Type Mismatch
The behavior of the protection domain depends on the exact Protection The behavior of the protection domain depends on the exact Protection
Type (PT) mismatch. Section 4.2.3 of RFC6378 specifies three Type (PT) mismatch. Section 4.2.3 of RFC 6378 specifies three
protection types - bidirectional switching using a permanent bridge, protection types -- bidirectional switching using a permanent bridge,
bidirectional switching using a selector bridge, and unidirectional bidirectional switching using a selector bridge, and unidirectional
switching using a permanent bridge. They are abbreviated here as BP, switching using a permanent bridge. They are abbreviated here as BP,
BS and UP. BS, and UP.
There are three possible mismatches: {BP, UP}, {BP, BS}, and {UP, There are three possible mismatches: {BP, UP}, {BP, BS}, and
BS}. The priority is: {UP, 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.
o If the PT mismatch is {BP, BS}, the node transmitting BP MUST o If the PT mismatch is {BP, BS}, the node transmitting BP MUST
switch to BS mode if it is supported. switch to BS mode if it is supported.
o If the PT mismatch is {UP, BS}, the node transmitting BS MUST o If the PT mismatch is {UP, BS}, the node transmitting BS MUST
switch to UP mode if it is supported. switch to UP mode if it is supported.
If a node does not support a mode to which it is required to switch If a node does not support a mode to which it is required to switch,
then that node MUST behave as in Section 4.3. then that node MUST behave as in Section 4.3.
4.2. R mismatch 4.2. R Mismatch
The R bit indicates whether the protection domain is in Revertive or The R bit indicates whether the protection domain is in revertive or
Non-Revertive behavior. If the R bits do not match, the node non-revertive behavior. If the R bits do not match, the node
indicating Non-Revertive MUST switch to Revertive if it is supported. indicating non-revertive MUST switch to Revertive if it is supported.
If it is not supported a node must behave as in Section 4.3 If it is not supported, a node must behave as in Section 4.3.
4.3. Unsupported modes 4.3. Unsupported Modes
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 long as there is no failure (e.g., NR state) regardless of any PT or
R mismatch. R mismatch.
If there is a trigger which would cause the protection LSP to be If there is a trigger that would cause the protection LSP to be used,
used, such as SF or MS, a node MUST NOT use the protection LSP to such as SF or MS, a node MUST NOT use the protection LSP to carry
carry traffic. 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 statement identifies a deadlock case where
can end up sending NR(0,1) when it should instead be in the process each node can end up sending NR(0,1) when it should instead be in the
of recovering from the failure (i.e. entering into WTR or DNR, as process of recovering from the failure (i.e., entering into WTR or
appropriate for the protection domain). The root of the issue is DNR, as appropriate for the protection domain). The root of the
that a pair of nodes can simultaneously enter WTR state, receive an issue is that a pair of nodes can simultaneously enter WTR state,
out of date SF-W indication and transition into a remotely triggered receive an out-of-date SF-W indication, transition into a remotely
WTR, and remain in remotely triggered WTR waiting for the other end triggered WTR, and remain in remotely triggered WTR waiting for the
to trigger a change in status. other end 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 that 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 RFC 6378:
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 penultimate bullet in Section 4.3.3.3 is changed
from
o A remote NR(0,0) message SHALL be ignored if in local Protecting o A remote NR(0,0) message SHALL be ignored if in local Protecting
administrative state. administrative state.
to to
o A remote No Request message SHALL be ignored if in local o A remote No Request message SHALL be ignored if in local
Protecting administrative state. Protecting administrative state.
This indicates that a remote NR triggers the same behavior regardless This indicates that a remote NR triggers the same behavior regardless
of the value of FPath and Path. This change does not directly of the value of FPath and Path. This change does not directly
address issue #8, but fixes a similar issue - if a node receives NR address issue #8, but it fixes a similar issue -- if a node receives
while in Remote administrative state, the value of FPath and Path NR while in Remote administrative state, the value of FPath and Path
have no bearing on the node's reaction to this NR. have no bearing on the node's reaction to this NR.
6. Clarifying PSC's behavior in the face of multiple inputs 6. Clarifying PSC's Behavior in the Face of Multiple Inputs
RFC6378 describes the PSC state machine. Figure 1 in section 3 shows RFC 6378 describes the PSC state machine. Figure 1 in Section 3 of
two inputs into the PSC Control logic - Local Request logic and RFC 6378 shows two inputs into the PSC Control logic -- Local Request
Remote PSC Request. When there is only one input into the PSC logic and Remote PSC Request. When there is only one input into the
Control logic - a local request or a remote request but not both - PSC Control logic -- a local request or a remote request but not both
the PSC Control logic decides what that input signifies and then -- the PSC Control logic decides what that input signifies and then
takes one or more actions, as necessary. This is what the PSC State takes one or more actions, as necessary. This is what the PSC State
Machine in section 4.3 describes. Machine in Section 4.3 of RFC 6378 describes.
RFC6378 does not sufficiently describe the behavior in the face of RFC 6378 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)] - that is, Local(Forced Switch) and Remote(Forced Switch). 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 Signal Fail on the Working path from the Remote request logic and a Signal Fail on the Working path from the Remote
PSC Request. This is shortened to [L(LO), R(SF-W)]. 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 RFC 6378
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
first example it is the local SF that drives the PSC Control logic, the first example it is the local SF that drives the PSC Control
and in the second example it is the local Lockout which drives the logic, and in the second example it is the local Lockout that drives
PSC Control logic. the 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 Finite State Machine (FSM)
transition from PA:F:L into N, and at some future time (perhaps after would suggest that PSC transition from PA:F:L into N, and at some
the remote request refreshes) PSC would transition from N to PA:F:R. future time (perhaps after the remote request refreshes), PSC would
This is an unreasonable behavior, as there is no sensible transition from N to PA:F:R. This is an unreasonable behavior, as
justification for a node behaving as if things were normal (i.e., N there is no sensible justification for a node behaving as if things
state) when it is clear that they are not. were normal (i.e., N 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 also a third case. Consider a node with [L(FS), R(LO)]. At There is also a third case. Consider a node with [L(FS), R(LO)]. At
some point in time the remote node replaces its Lockout request with some point in time, the remote node replaces its Lockout request with
a Signal Fail on Working, so that the inputs into the PSC Control a Signal Fail on Working, so that the inputs into the PSC Control
logic on the receiving node go to [L(FS), R(SF-W)]. Similar to the logic on the receiving node go to [L(FS), R(SF-W)]. Similar to the
first two cases, the node should immediately reevaluate both its first two cases, the node should immediately reevaluate both its
local and remote inputs to determine the highest priority among them, local and remote inputs to determine the highest priority among them
and act on that input accordingly. That is in fact what happens, as and act on that input accordingly. That is in fact what happens, as
defined in Section 4.3.3: defined in Section 4.3.3 of RFC 6378:
"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
to a PSC message received from the far-end LER, and receives a new reaction to a PSC message received from the far-end LER, and
PSC message from the far-end LER that indicates a contradictory receives a new PSC message from the far-end LER that indicates a
state, e.g., in remote Unavailable state receiving a remote FS(1,1) contradictory state, e.g., in remote Unavailable state receiving a
message, then the PSC Control logic SHALL reevaluate all inputs (both remote FS(1,1) message, then the PSC Control logic SHALL
the local input and the remote message) as if the LER is in the reevaluate all inputs (both the local input and the remote
Normal state." message) as if the LER is in the 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 were in Normal
So the quoted paragraph is replaced with the following text: state. So, the quoted paragraph is replaced with the following text:
"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,
the PSC Control logic SHALL immediately reevaluate all inputs (both then the PSC Control logic SHALL immediately reevaluate all inputs
the local input and the remote message), transitioning into a new (both the local input and the remote message), transitioning into
state only upon reevaluation of all inputs". a new state only upon reevaluation of all inputs.
7. Security Considerations 7. Security Considerations
These changes and clarifications raise no new security concerns. RFC These changes and clarifications raise no new security concerns. RFC
6941 [RFC6941] provides the baseline security discussion for MPLS-TP, 6941 [RFC6941] provides the baseline security discussion for MPLS-TP,
and PSC (both RFC 6378 and this document) fall under that umbrella. and PSC (as described in both RFC 6378 and this document) falls under
Additionally, Section 2.2 clarifies how to react to malformed or that umbrella. Additionally, Section 2.2 clarifies how to react to
unexpected messages. 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 has marked the value 0 in the "MPLS PSC TLV Registry" as
as "Reserved, not to be allocated" and to update the references to "Reserved, not to be allocated" and updated the references to show
show [RFC6378] and [RFC-ietf-mpls-psc-updates-04]. Note that this [RFC6378] and this document (RFC 7324). Note that this document
action provides documentation of an action already taken by IANA but provides documentation of an action already taken by IANA but not
not recorded in RFC 6378. recorded in RFC 6378.
9. Acknowledgements 9. Acknowledgements
The author of this document thanks Taesik Cheung, Alessandro The author of this document thanks Taesik Cheung, Alessandro
D'Alessandro, Annamaria Fulignoli, Sagar Soni, George Swallow and D'Alessandro, Annamaria Fulignoli, Sagar Soni, George Swallow, and
Yaacov Weingarten for their contributions and review, and Adrian Yaacov Weingarten for their contributions and review, and Adrian
Farrel for the text of Section 2. Farrel for the text of Section 2.
10. References 10. References
10.1. Normative References 10.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.
10.2. Informative References 10.2. Informative References
[I-D.ietf-mpls-tp-psc-itu] [LIAISON] ITU-T SG15, "Liaison Statement: Recommendation ITU-T
Ryoo, J., Gray, E., Helvoort, H., D'Alessandro, A., G.8131/Y.1382 revision - Linear protection switching for
Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-
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/ MPLS-TP networks", <https://datatracker.ietf.org/
liaison/1205/>. liaison/1205/>.
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
Graveman, "MPLS Transport Profile (MPLS-TP) Security Graveman, "MPLS Transport Profile (MPLS-TP) Security
Framework", RFC 6941, April 2013. Framework", RFC 6941, April 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.
Author's Address Author's Address
Eric Osborne Eric Osborne
Email: eric.osborne@notcom.com EMail: eric.osborne@notcom.com
 End of changes. 71 change blocks. 
183 lines changed or deleted 176 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/