draft-osborne-mpls-psc-updates-02.txt   draft-osborne-mpls-psc-updates-03.txt 
Network Working Group E. Osborne Network Working Group E. Osborne
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track September 11, 2013 Intended status: Standards Track October 04, 2013
Expires: March 15, 2014 Expires: April 07, 2014
Updates to PSC Updates to PSC
draft-osborne-mpls-psc-updates-02 draft-osborne-mpls-psc-updates-03
Abstract Abstract
This document contains four updates to RFC6378, "MPLS Transport This document contains four updates to the Protection State
Profile (MPLS-TP) Linear Protection". Two of them correct existing Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile
(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 clears up 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].
skipping to change at page 1, line 40 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 15, 2014. This Internet-Draft will expire on April 07, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 20
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 . . . . . . . . . . . . 2
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. PT mismatch . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. R mismatch . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. R mismatch . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 7
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 identified in the ITU's liaison statement "Recommendation fix issues #2, #7 and #8 as identified in the ITU's liaison statement
ITU-T G.8131/Y.1382 revision - Linear protection switching for MPLS- "Recommendation ITU-T G.8131/Y.1382 revision - Linear protection
TP networks" [LIAISON]. The fourth clears up a behavior which was switching for MPLS-TP networks" [LIAISON]. The fourth clears up a
not well explained in RFC6378. These updates are not changes to the behavior which was not well explained in RFC6378. These updates are
protocol's packet format or to PSC's design, but are corrections and not changes to the protocol's packet format or to PSC's design, but
clarifications to specific aspects of the protocol's procedures. are corrections and clarifications to specific aspects of the
protocol's procedures.
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 is replaced
with the following three bullets: 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
skipping to change at page 4, line 25 skipping to change at page 4, line 28
RFC6378 describes the PSC state machine. Figure 1 in section 3 shows RFC6378 describes the PSC state machine. Figure 1 in section 3 shows
two inputs into the PSC Control logic - Local Request logic and two inputs into the PSC Control logic - Local Request logic and
Remote PSC Request. When there is only one input into the PSC Remote PSC Request. When there is only one input into the PSC
Control logic - a local request or a remote request but not both - 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 describes.
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 desired 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 failure of the Working LSP. A bidirectional fiber cut will case is a Forced Switch (FS) configured on both ends of an LSP. This
result in the PSC Control logic receiving both a local SF-W (due to will result in the PSC Control logic receiving both a local FS and
loss of light on the underlying fiber) and a remote SF-W (due to the remove FS. For convenience, this scenario is written as [L(FS),
peer node's loss of light). Incidentally, a unidirectional fiber cut R(FS))]
will very likely result in a bidirectional failure scenario as it is
expected that most MPLS-TP deployments will be running CC/CV
[RFC6428]. For convenience, this scenario is written as [L(SF-W),
R(SF-W)]
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 (that is, a forced switch to the request logic and a Forced Switch from the Remote PSC Request. This
protection LSP) from the Remote PSC Request. This is shortened to is shortened to [L(LO), R(FS)].
[L(LO), R(FS)].
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(SF-W), R(SF-W)] and L(SF-W) Initially, the PSC Control logic has [L(FS), R(FS)] and L(FS) is
is driving PSC's behavior. When L(SF-W) is removed but R(SF-W) driving PSC's behavior. When L(FS) is removed but R(FS) remains,
remains, what does PSC do? A strict reading of the FSM would suggest what does PSC do? A strict reading of the FSM would suggest that PSC
that PSC transition from PA:F:L into N, and at some future time transition from PA:F:L into N, and at some future time (perhaps after
(perhaps after the remote request refreshes) PSC would transition the remote request refreshes) PSC would transition from N to PA:F:R.
from N to PA:F:R. This is an unreasonable behavior, as there is no This is an unreasonable behavior, as there is no sensible
sensible justification for a node behaving as if things were normal justification for a node behaving as if things were normal (i.e. N
(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(FS)] and
the local lockout is removed, a strict reading of the state machine 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 then at would suggest that the node transition from UA:LO:L to N, and then at
some future time presumably notice the R(FS) and transition from N to some future time presumably notice the R(FS) and transition from N to
PA:F:R. As with the first case, this is clearly not a useful PA:F:R. As with the first case, this is clearly not a useful
behavior. 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
Signal Fail on Working, so that the inputs into the PSC Control logic 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 first on the receiving node go to [L(FS), R(SF-W)]. Similar to the first
skipping to change at page 6, line 21 skipping to change at page 6, line 17
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".
5. Handling a capabilities mismatch 5. 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 and Revertive properties of that domain, via the Protection Type (PT) and Revertive
bits. RFC6378 specifies that if these bits do not match an operator (R) bits. RFC6378 specifies that if these bits do not match an
"SHALL [be notified]" (PT, section 4.2.3) or "SHOULD be notified" (R, operator "SHALL [be notified]" (PT, section 4.2.3) or "SHOULD be
section 4.2.4). However, there is no text which specifies the notified" (R, section 4.2.4). However, there is no text which
behavior of the end nodes of a protection domain in case of a specifies the behavior of the end nodes of a protection domain in
mismatch case of a mismatch. This section provides that text, as requested by
issue #7 in the liaison.
5.1. PT mismatch 5.1. PT mismatch
The behavior of the protection domain depends on the exact PT The behavior of the protection domain depends on the exact PT
mismatch. Section 4.2.3 of RFC6378 specifies three protection types mismatch. Section 4.2.3 of RFC6378 specifies three protection types
- bidirectional switching using a permanent bridge, bidirectional - bidirectional switching using a permanent bridge, bidirectional
switching using a selector bridge, and unidirectional switching using switching using a selector bridge, and unidirectional switching using
a permanent bridge. They are abbreviated here as BP, BS and UP. 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.
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.
5.2. R mismatch 5.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.
5.3. Unsupported modes 5.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
skipping to change at page 7, line 20 skipping to change at page 7, line 17
5.3. Unsupported modes 5.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-
failuremode even if there is a mismatch, as the mismatches of PT or R failure mode even if there is a mismatch, as the mismatches of PT or
have to do with how nodes recover from a failure. An implementation R have to do with how nodes recover from a failure. An
SHOULD allow traffic to be sent on the Working LSP as long as there implementation SHOULD allow traffic to be sent on the Working LSP as
is no failure (e.g. NR state) regardless of any PT or R mismatch. long as there is no failure (e.g. NR state) regardless of any PT or 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.
6. Security Considerations 6. Security Considerations
These changes and clarifications raise no new security concerns. These changes and clarifications raise no new security concerns.
7. IANA Considerations 7. IANA Considerations
None. There are no requests for IANA actions in this document..
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
8. Acknowledgements 8. 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. Yaacov Weingarten for their contributions and review.
 End of changes. 20 change blocks. 
51 lines changed or deleted 49 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/