--- 1/draft-ietf-mpls-psc-updates-02.txt 2014-03-26 13:14:34.974034100 -0700 +++ 2/draft-ietf-mpls-psc-updates-03.txt 2014-03-26 13:14:34.994034589 -0700 @@ -1,19 +1,19 @@ Network Working Group E. Osborne Internet-Draft -Updates: RFC6378 (if approved) March 5, 2014 +Updates: 6378 (if approved) March 25, 2014 Intended status: Standards Track -Expires: September 6, 2014 +Expires: September 26, 2014 Updates to MPLS Transport Profile Linear Protection - draft-ietf-mpls-psc-updates-02 + draft-ietf-mpls-psc-updates-03 Abstract This document contains four updates to the Protection State Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile (MPLS-TP) Linear Protection" . Two of the updates correct existing behavior. The third clarifies a behavior which was not explained in the RFC, and the fourth adds rules around handling capabilities mismatches. @@ -31,72 +31,96 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Incorrect local status after failure . . . . . . . . . . . . 3 - 3. Reversion deadlock due to a race condition . . . . . . . . . 3 - 4. Clarifying PSC's behavior in the face of multiple inputs . . 4 - 5. Handling a capabilities mismatch . . . . . . . . . . . . . . 6 - 5.1. Protection Type mismatch . . . . . . . . . . . . . . . . 6 - 5.2. R mismatch . . . . . . . . . . . . . . . . . . . . . . . 7 - 5.3. Unsupported modes . . . . . . . . . . . . . . . . . . . . 7 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 - 9.2. Informative References . . . . . . . . . . . . . . . . . 8 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2. PSC TLV Format . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Incorrect local status after failure . . . . . . . . . . . . 3 + 4. Reversion deadlock due to a race condition . . . . . . . . . 4 + 5. Clarifying PSC's behavior in the face of multiple inputs . . 5 + 6. Handling a capabilities mismatch . . . . . . . . . . . . . . 7 + 6.1. Protection Type mismatch . . . . . . . . . . . . . . . . 7 + 6.2. R mismatch . . . . . . . . . . . . . . . . . . . . . . . 7 + 6.3. Unsupported modes . . . . . . . . . . . . . . . . . . . . 7 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 10.2. Informative References . . . . . . . . . . . . . . . . . 9 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction - This document contains four updates to PSC [RFC6378]. Three of them - address issues #2, #7 and #8 as identified in the ITU's liaison - statement "Recommendation ITU-T G.8131/Y.1382 revision - Linear - protection switching for MPLS-TP networks" [LIAISON]. The fourth - clears up a behavior which was not well explained in RFC6378. These - updates are not changes to the protocol's packet format or to PSC's - design, but are corrections and clarifications to specific aspects of - the protocol's procedures. + This document contains firve updates to PSC [RFC6378]. The first + clarifies the use of TLVs in PSC. Three of them address issues #2, + #7 and #8 as identified in the ITU's liaison statement + "Recommendation ITU-T G.8131/Y.1382 revision - Linear protection + switching for MPLS-TP networks" [LIAISON]. The fifth clears up a + behavior which was not well explained in RFC6378. These updates are + not changes to the protocol's packet format or to PSC's design, but + are corrections and clarifications to specific aspects of 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. 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 RFC6378 leaves a node reporting an inaccurate status: 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, 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 is replaced with the following three bullets: @@ -107,21 +131,21 @@ o If the LER is in local Protecting Administrative state due to a local Forced Switch, a local Signal Fail indication on the protection path SHALL be ignored. o If the LER is in remote Protecting Administrative state due to a remote Forced Switch, a local Signal Fail indication on the protection path SHALL cause the LER to remain in remote Protecting 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 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 appropriate for the protection domain). The root of the issue is that a pair of nodes can simultaneously enter WTR state, receive an out of date SF-W indication and transition into a remotely triggered WTR, and remain in remotely triggered WTR waiting for the other end to trigger a change in status. @@ -153,21 +177,21 @@ o A remote No Request message SHALL be ignored if in local Protecting administrative state. This indicates that a remote NR triggers the same behavior regardless 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 while in Remote administrative state, the value of FPath and Path 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 two inputs into the PSC Control logic - Local Request logic and Remote PSC Request. When there is only one input into the PSC Control logic - a local request or a remote request but not both - the PSC Control logic decides what that input signifies and then takes one or more actions, as necessary. This is what the PSC State Machine in section 4.3 describes. RFC6378 does not sufficiently describe the behavior in the face of @@ -245,116 +269,113 @@ So the quoted paragraph is replaced with the following text: "The PSC Control logic may simultaneously have Local and Remote requests, and the highest priority of these requests ultimately drives the behavior of the PSC Control logic. When this highest priority request is removed or is replaced with another input, then the PSC Control logic SHALL immediately reevaluate all inputs (both the local input and the remote message), transitioning into a new 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 protection domain. It does, however, have the ability to signal two properties of that domain, via the Protection Type (PT) and Revertive (R) bits. RFC6378 specifies that if these bits do not match an operator "SHALL [be notified]" (PT, section 4.2.3) or "SHOULD be notified" (R, section 4.2.4). However, there is no text which specifies the behavior of the end nodes of a protection domain in case of a mismatch. This section provides that text, as requested by 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 Type (PT) mismatch. Section 4.2.3 of RFC6378 specifies three protection types - bidirectional switching using a permanent bridge, bidirectional switching using a selector bridge, and unidirectional 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, - BS]. The priority is: + There are three possible mismatches: {BP, UP}, {BP, BS}, and {UP, + BS}. The priority is: UP > BS > BP In other words: o If the PT mismatch is {BP, UP}, the node transmitting BP MUST switch to UP mode if it is supported. o If the PT mismatch is {BP, BS}, the node transmitting BP MUST switch to BS mode if it is supported. o If the PT mismatch is {UP, BS}, the node transmitting BS MUST 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 Non-Revertive behavior. If the R bits do not match, the node 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 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 intervention. An implementation SHOULD alert the operator to an irreconcilable mismatch. 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 R have to do with how nodes recover from a failure. An 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 mismatch. 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 carry traffic. -6. Security Considerations +7. Security Considerations These changes and clarifications raise no new security concerns. -7. IANA Considerations - - There are no requests for IANA actions in this document.. +8. IANA Considerations - Note to RFC Editor: this section may be removed on publication as an - RFC. + IANA is requested to mark the value 0 in the "MPLS PSC TLV Registry" + as "Reserved, not to be allocated" and to update the references to + 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 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 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011. - [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive - Connectivity Verification, Continuity Check, and Remote - Defect Indication for the MPLS Transport Profile", RFC - 6428, November 2011. - -9.2. Informative References +10.2. Informative References [LIAISON] ITU-T SG15, "Liaison Statement: Recommendation ITU-T G.8131/Y.1382 revision - Linear protection switching for MPLS-TP networks", . Author's Address Eric Osborne