--- 1/draft-osborne-mpls-psc-updates-02.txt 2013-10-04 05:14:26.608382990 -0700 +++ 2/draft-osborne-mpls-psc-updates-03.txt 2013-10-04 05:14:26.628383506 -0700 @@ -1,23 +1,24 @@ Network Working Group E. Osborne Internet-Draft Cisco Systems -Intended status: Standards Track September 11, 2013 -Expires: March 15, 2014 +Intended status: Standards Track October 04, 2013 +Expires: April 07, 2014 Updates to PSC - draft-osborne-mpls-psc-updates-02 + draft-osborne-mpls-psc-updates-03 Abstract - This document contains four updates to RFC6378, "MPLS Transport - Profile (MPLS-TP) Linear Protection". Two of them correct existing + 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 clears up a behavior which was not explained in the RFC, and the fourth adds rules around handling capabilities mismatches. 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]. @@ -29,21 +30,21 @@ 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 March 15, 2014. + This Internet-Draft will expire on April 07, 2014. Copyright Notice Copyright (c) 2013 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 @@ -54,44 +55,45 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Incorrect local status after failure . . . . . . . . . . . . 2 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. PT mismatch . . . . . . . . . . . . . . . . . . . . . . . 6 - 5.2. R mismatch . . . . . . . . . . . . . . . . . . . . . . . 7 + 5.2. R mismatch . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Unsupported modes . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction This document contains four updates to PSC [RFC6378]. Three of them - fix issues 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. + fix 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. 2. 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 + 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 is replaced with the following three bullets: 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 the LER to enter local Unavailable state and begin transmission of @@ -156,69 +159,64 @@ 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 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 the PSC Control logic. The first is when the same request is presented from both local and remote sources. One example of this - case is a failure of the Working LSP. A bidirectional fiber cut will - result in the PSC Control logic receiving both a local SF-W (due to - loss of light on the underlying fiber) and a remote SF-W (due to the - peer node's loss of light). Incidentally, a unidirectional fiber cut - 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)] + 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 + remove FS. For convenience, this scenario is written as [L(FS), + R(FS))] 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 different events. There are a number of variations on this case. 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 - protection LSP) from the Remote PSC Request. This is shortened to - [L(LO), R(FS)]. + request logic and a Forced Switch from the Remote PSC Request. This + is shortened to [L(LO), R(FS)]. 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 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 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 PSC Control logic. The point that this section clears up is around what happens when the 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) - is driving PSC's behavior. When L(SF-W) is removed but R(SF-W) - remains, what does PSC do? A strict reading of the FSM would suggest - that PSC transition from PA:F:L into N, and at some future time - (perhaps after the remote request refreshes) PSC would transition - from N to PA:F:R. This is an unreasonable behavior, as there is no - sensible justification for a node behaving as if things were normal - (i.e. N state) when it is clear that they are not. + 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, + what does PSC do? A strict reading of the FSM would suggest that PSC + transition from PA:F:L into N, and at some future time (perhaps after + the remote request refreshes) PSC would transition from N to PA:F:R. + This is an unreasonable behavior, as there is no sensible + justification for a node behaving as if things 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(FS)] 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 then at 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 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, upon removal of an input, immediately reevaluate all other inputs to decide on the next course of action. This requires an implementation to store the most recent local and remote inputs regardless of their eventual use as triggers for the PSC Control Logic. 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 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 @@ -244,53 +243,53 @@ 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 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 and Revertive - 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 + 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. PT mismatch The behavior of the protection domain depends on the exact 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: UP > BS > BP 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. - 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. - 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. 5.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 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 @@ -290,36 +289,37 @@ 5.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- - failuremode 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. + 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 These changes and clarifications raise no new security concerns. 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 RFC. 8. 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.