draft-ietf-mpls-psc-updates-02.txt   draft-ietf-mpls-psc-updates-03.txt 
Network Working Group E. Osborne Network Working Group E. Osborne
Internet-Draft Internet-Draft
Updates: RFC6378 (if approved) March 5, 2014 Updates: 6378 (if approved) March 25, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: September 6, 2014 Expires: September 26, 2014
Updates to MPLS Transport Profile Linear Protection Updates to MPLS Transport Profile Linear Protection
draft-ietf-mpls-psc-updates-02 draft-ietf-mpls-psc-updates-03
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 clarifies 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.
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 September 6, 2014. This Internet-Draft will expire on September 26, 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. Incorrect local status after failure . . . . . . . . . . . . 3 2. PSC TLV Format . . . . . . . . . . . . . . . . . . . . . . . 3
3. Reversion deadlock due to a race condition . . . . . . . . . 3 3. Incorrect local status after failure . . . . . . . . . . . . 3
4. Clarifying PSC's behavior in the face of multiple inputs . . 4 4. Reversion deadlock due to a race condition . . . . . . . . . 4
5. Handling a capabilities mismatch . . . . . . . . . . . . . . 6 5. Clarifying PSC's behavior in the face of multiple inputs . . 5
5.1. Protection Type mismatch . . . . . . . . . . . . . . . . 6 6. Handling a capabilities mismatch . . . . . . . . . . . . . . 7
5.2. R mismatch . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Protection Type mismatch . . . . . . . . . . . . . . . . 7
5.3. Unsupported modes . . . . . . . . . . . . . . . . . . . . 7 6.2. R mismatch . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6.3. Unsupported modes . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
This document contains four updates to PSC [RFC6378]. Three of them This document contains firve updates to PSC [RFC6378]. The first
address issues #2, #7 and #8 as identified in the ITU's liaison clarifies the use of TLVs in PSC. Three of them address issues #2,
statement "Recommendation ITU-T G.8131/Y.1382 revision - Linear #7 and #8 as identified in the ITU's liaison statement
protection switching for MPLS-TP networks" [LIAISON]. The fourth "Recommendation ITU-T G.8131/Y.1382 revision - Linear protection
clears up a behavior which was not well explained in RFC6378. These switching for MPLS-TP networks" [LIAISON]. The fifth clears up a
updates are not changes to the protocol's packet format or to PSC's behavior which was not well explained in RFC6378. These updates are
design, but are corrections and clarifications to specific aspects of not changes to the protocol's packet format or to PSC's design, but
the protocol's procedures. are corrections and clarifications to specific aspects of the
protocol's procedures.
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. Incorrect local status after failure 2. PSC TLV Format
[RFC6378] defines the capability to carry TLVs in the PSC messages.
This section defines the format to be used by all such TLVs.
Type field (T):
A two octet field that encodes a type value in network byte order.
The type values are recorded in the IANA registry "MPLS PSC TLV
Registry".
Length field (L) :
A two octet field that encodes the length in octets of the Value
field in network byte order. The value of this field MUST be a
multiple of 4.
Value field (V) :
The contents of the TLV. This field MUST be a multiple of 4 octets
and so may contain explicit padding.
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
is replaced with the following three bullets: is replaced with the following three bullets:
skipping to change at page 3, line 30 skipping to change at page 4, line 5
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.
3. Reversion deadlock due to a race condition 4. 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.
skipping to change at page 4, line 29 skipping to change at page 5, line 5
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 fixes a similar issue - if a node receives NR
while in Remote administrative state, the value of FPath and Path 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.
4. Clarifying PSC's behavior in the face of multiple inputs 5. Clarifying PSC's behavior in the face of multiple inputs
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
skipping to change at page 6, line 26 skipping to change at page 7, line 5
So the quoted paragraph is replaced with the following text: 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, 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 6. 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. 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. Protection Type mismatch 6.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 RFC6378 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 {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 6.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 6.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 R long as there is no failure (e.g. NR state) regardless of any PT or R
mismatch. 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 7. Security Considerations
These changes and clarifications raise no new security concerns. These changes and clarifications raise no new security concerns.
7. IANA Considerations 8. IANA Considerations
There are no requests for IANA actions in this document..
Note to RFC Editor: this section may be removed on publication as an IANA is requested to mark the value 0 in the "MPLS PSC TLV Registry"
RFC. as "Reserved, not to be allocated" and to update the references to
show [RFC6378] and [RFC-ietf-mpls-psc-updates-03]. Note that this
action provides documentation of an action already taken by IANA but
not recorded in RFC 6378.
8. 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. Yaacov Weingarten for their contributions and review, and Adrian
Farrel for the text of Section 2.
9. References 10. References
9.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.
[RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive 10.2. Informative References
Connectivity Verification, Continuity Check, and Remote
Defect Indication for the MPLS Transport Profile", RFC
6428, November 2011.
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
 End of changes. 22 change blocks. 
51 lines changed or deleted 72 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/