idnits 2.17.1 draft-ietf-mpls-psc-updates-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6378, but the abstract doesn't seem to directly say this. It does mention RFC6378 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2014) is 3655 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-ietf-mpls-psc-updates-03' is mentioned on line 349, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Osborne 3 Internet-Draft 4 Updates: 6378 (if approved) March 26, 2014 5 Intended status: Standards Track 6 Expires: September 27, 2014 8 Updates to MPLS Transport Profile Linear Protection 9 draft-ietf-mpls-psc-updates-03 11 Abstract 13 This document contains four updates to the Protection State 14 Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile 15 (MPLS-TP) Linear Protection" . Two of the updates correct existing 16 behavior. The third clarifies a behavior which was not explained in 17 the RFC, and the fourth adds rules around handling capabilities 18 mismatches. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 27, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. PSC TLV Format . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Incorrect local status after failure . . . . . . . . . . . . 3 63 4. Reversion deadlock due to a race condition . . . . . . . . . 4 64 5. Clarifying PSC's behavior in the face of multiple inputs . . 5 65 6. Handling a capabilities mismatch . . . . . . . . . . . . . . 7 66 6.1. Protection Type mismatch . . . . . . . . . . . . . . . . 7 67 6.2. R mismatch . . . . . . . . . . . . . . . . . . . . . . . 7 68 6.3. Unsupported modes . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 10.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 This document contains firve updates to PSC [RFC6378]. The first 80 clarifies the use of TLVs in PSC. Three of them address issues #2, 81 #7 and #8 as identified in the ITU's liaison statement 82 "Recommendation ITU-T G.8131/Y.1382 revision - Linear protection 83 switching for MPLS-TP networks" [LIAISON]. The fifth clears up a 84 behavior which was not well explained in RFC6378. These updates are 85 not changes to the protocol's packet format or to PSC's design, but 86 are corrections and clarifications to specific aspects of the 87 protocol's procedures. 89 This document assumes familiarity with RFC6378 and its terms, 90 conventions and acronyms. Any term used in this document but not 91 defined herein can be found in RFC6378. In particular, this document 92 shares the acronyms defined in RFC6378 section 2.1. 94 2. PSC TLV Format 96 [RFC6378] defines the capability to carry TLVs in the PSC messages. 97 This section defines the format to be used by all such TLVs. 99 Type field (T): 101 A two octet field that encodes a type value in network byte order. 102 The type values are recorded in the IANA registry "MPLS PSC TLV 103 Registry". 105 Length field (L) : 107 A two octet field that encodes the length in octets of the Value 108 field in network byte order. The value of this field MUST be a 109 multiple of 4. 111 Value field (V) : 113 The contents of the TLV. This field MUST be a multiple of 4 octets 114 and so may contain explicit padding. 116 3. Incorrect local status after failure 118 Issue #2 in the liaison identifies a case where a strict reading of 119 RFC6378 leaves a node reporting an inaccurate status: 121 A node can end up sending incorrect status - NR(0,1) - despite the 122 failure of the protection LSP (P-LSP). This is clearly not correct, 123 as a node should not be sending NR if it has a local failure. To 124 address this issue, the fourth bullet in section 4.3.3.3 of RFC6378 125 is replaced with the following three bullets: 127 o If the current state is due to a local or remote Manual Switch, a 128 local Signal Fail indication on the protection path SHALL cause 129 the LER to enter local Unavailable state and begin transmission of 130 an SF(0,0) message. 132 o If the LER is in local Protecting Administrative state due to a 133 local Forced Switch, a local Signal Fail indication on the 134 protection path SHALL be ignored. 136 o If the LER is in remote Protecting Administrative state due to a 137 remote Forced Switch, a local Signal Fail indication on the 138 protection path SHALL cause the LER to remain in remote Protecting 139 administrative state and transmit an SF(0,1) message. 141 4. Reversion deadlock due to a race condition 143 Issue #8 in the liaison identifies a deadlock case where each node 144 can end up sending NR(0,1) when it should instead be in the process 145 of recovering from the failure (i.e. entering into WTR or DNR, as 146 appropriate for the protection domain). The root of the issue is 147 that a pair of nodes can simultaneously enter WTR state, receive an 148 out of date SF-W indication and transition into a remotely triggered 149 WTR, and remain in remotely triggered WTR waiting for the other end 150 to trigger a change in status. 152 In the case identified in issue #8, each node can end up sending 153 NR(0,1), which is an indication that the transmitting node has no 154 local failure, but is instead reacting to the remote SF-W. If a node 155 which receives NR(0,1) is in fact not indicating a local error, the 156 receive node can take the received NR(0,1) as an indication that 157 there is no error in the protection domain, and recovery procedures 158 (WTR or DNR) should begin. 160 This is addressed by adding the following text as the penultimate 161 bullet in section 4.3.3.4 of RFC6378: 163 o If a node is in Protecting Failure state due to a remote SF-W and 164 receives NR(0,1), this SHALL cause the node to begin recovery 165 procedures. If the LER is configured for revertive behavior, it 166 enters into Wait-to-Restore state, starts the WTR timer, and 167 begins transmitting WTR(0,1). If the LER is configured for non- 168 revertive behavior, it enters into Do-Not-Revert state and begins 169 transmitting a DNR(0,1) message. 171 Additionally, the final bullet in section 4.3.3.3 is changed from 173 o A remote NR(0,0) message SHALL be ignored if in local Protecting 174 administrative state. 176 to 178 o A remote No Request message SHALL be ignored if in local 179 Protecting administrative state. 181 This indicates that a remote NR triggers the same behavior regardless 182 of the value of FPath and Path. This change does not directly 183 address issue #8, but fixes a similar issue - if a node receives NR 184 while in Remote administrative state, the value of FPath and Path 185 have no bearing on the node's reaction to this NR. 187 5. Clarifying PSC's behavior in the face of multiple inputs 189 RFC6378 describes the PSC state machine. Figure 1 in section 3 shows 190 two inputs into the PSC Control logic - Local Request logic and 191 Remote PSC Request. When there is only one input into the PSC 192 Control logic - a local request or a remote request but not both - 193 the PSC Control logic decides what that input signifies and then 194 takes one or more actions, as necessary. This is what the PSC State 195 Machine in section 4.3 describes. 197 RFC6378 does not sufficiently describe the behavior in the face of 198 multiple inputs into the PSC Control Logic (one Local Request and one 199 Remote Request). This section clarifies the expected behavior. 201 There are two cases to think about when considering dual inputs into 202 the PSC Control logic. The first is when the same request is 203 presented from both local and remote sources. One example of this 204 case is a Forced Switch (FS) configured on both ends of an LSP. This 205 will result in the PSC Control logic receiving both a local FS and 206 remove FS. For convenience, this scenario is written as [L(FS), 207 R(FS))] - that is, Local(Forced Switch) and Remote(Forced Switch). 209 The second case, which is handled in exactly the same way as the 210 first, is when the two inputs into the PSC Control logic describe 211 different events. There are a number of variations on this case. 212 One example is when there is a Lockout of Protection from the Local 213 request logic and a Signal Fail on the Working parh from the Remote 214 PSC Request. This is shortened to [L(LO), R(SF-W)]. 216 In both cases the question is not how the PSC Control logic decides 217 which of these is the one it acts upon. Section 4.3.2 of RFC6378 218 lists the priority order, and prioritizes the local input over the 219 remote input in case both inputs are of the same priority. So in the 220 first example it is the local SF that drives the PSC Control logic, 221 and in the second example it is the local Lockout which drives the 222 PSC Control logic. 224 The point that this section clears up is around what happens when the 225 highest priority input goes away. Consider the first case. 226 Initially, the PSC Control logic has [L(FS), R(FS)] and L(FS) is 227 driving PSC's behavior. When L(FS) is removed but R(FS) remains, 228 what does PSC do? A strict reading of the FSM would suggest that PSC 229 transition from PA:F:L into N, and at some future time (perhaps after 230 the remote request refreshes) PSC would transition from N to PA:F:R. 231 This is an unreasonable behavior, as there is no sensible 232 justification for a node behaving as if things were normal (i.e. N 233 state) when it is clear that they are not. 235 The second case is similar. If a node starts with [L(LO), R(SF-W)] 236 and the local lockout is removed, a strict reading of the state 237 machine would suggest that the node transition from UA:LO:L to N, and 238 then at some future time presumably notice the R(SF-W) and transition 239 from N to PF:W:R. As with the first case, this is clearly not a 240 useful behavior. 242 In both cases the request which was driving PSC's behavior was 243 removed. What should happen is that the PSC Control logic should, 244 upon removal of an input, immediately reevaluate all other inputs to 245 decide on the next course of action. This requires an implementation 246 to store the most recent local and remote inputs regardless of their 247 eventual use as triggers for the PSC Control Logic. 249 There is a third case. Consider a node with [L(FS), R(LO)]. At some 250 point in time the remote node replaces its Lockout request with a 251 Signal Fail on Working, so that the inputs into the PSC Control logic 252 on the receiving node go to [L(FS), R(SF-W)]. Similar to the first 253 two cases, the node should immediately reevaluate both its local and 254 remote inputs to determine the highest priority among them, and act 255 on that input accordingly. That is in fact what happens, as defined 256 in Section 4.3.3: 258 "When a LER is in a remote state, i.e., state transition in reaction 259 to a PSC message received from the far-end LER, and receives a new 260 PSC message from the far-end LER that indicates a contradictory 261 state, e.g., in remote Unavailable state receiving a remote FS(1,1) 262 message, then the PSC Control logic SHALL reevaluate all inputs (both 263 the local input and the remote message) as if the LER is in the 264 Normal state." 266 This section extends that paragraph to handle the first two cases. 267 The essence of the quoted paragraph is that when faced with multiple 268 inputs, PSC must reevaluate any changes as if it was in Normal state. 269 So the quoted paragraph is replaced with the following text: 271 "The PSC Control logic may simultaneously have Local and Remote 272 requests, and the highest priority of these requests ultimately 273 drives the behavior of the PSC Control logic. When this highest 274 priority request is removed or is replaced with another input, then 275 the PSC Control logic SHALL immediately reevaluate all inputs (both 276 the local input and the remote message), transitioning into a new 277 state only upon reevaluation of all inputs". 279 6. Handling a capabilities mismatch 281 PSC has no explicit facility to negotiate any properties of the 282 protection domain. It does, however, have the ability to signal two 283 properties of that domain, via the Protection Type (PT) and Revertive 284 (R) bits. RFC6378 specifies that if these bits do not match an 285 operator "SHALL [be notified]" (PT, section 4.2.3) or "SHOULD be 286 notified" (R, section 4.2.4). However, there is no text which 287 specifies the behavior of the end nodes of a protection domain in 288 case of a mismatch. This section provides that text, as requested by 289 issue #7 in the liaison. 291 6.1. Protection Type mismatch 293 The behavior of the protection domain depends on the exact Protection 294 Type (PT) mismatch. Section 4.2.3 of RFC6378 specifies three 295 protection types - bidirectional switching using a permanent bridge, 296 bidirectional switching using a selector bridge, and unidirectional 297 switching using a permanent bridge. They are abbreviated here as BP, 298 BS and UP. 300 There are three possible mismatches: {BP, UP}, {BP, BS}, and {UP, 301 BS}. The priority is: 303 UP > BS > BP 305 In other words: 307 o If the PT mismatch is {BP, UP}, the node transmitting BP MUST 308 switch to UP mode if it is supported. 310 o If the PT mismatch is {BP, BS}, the node transmitting BP MUST 311 switch to BS mode if it is supported. 313 o If the PT mismatch is {UP, BS}, the node transmitting BS MUST 314 switch to UP mode if it is supported. 316 6.2. R mismatch 318 The R bit indicates whether the protection domain is in Revertive or 319 Non-Revertive behavior. If the R bits do not match, the node 320 indicating Non-Revertive MUST switch to Revertive if it is supported. 322 6.3. Unsupported modes 324 An implementation may not support all three PT modes and/or both R 325 modes, and thus a pair of nodes may be unable to converge on a common 326 mode. This creates a permanent mismatch, resolvable only by operator 327 intervention. An implementation SHOULD alert the operator to an 328 irreconcilable mismatch. 330 It is desirable to allow the protection domain to function in a non- 331 failure mode even if there is a mismatch, as the mismatches of PT or 332 R have to do with how nodes recover from a failure. An 333 implementation SHOULD allow traffic to be sent on the Working LSP as 334 long as there is no failure (e.g. NR state) regardless of any PT or R 335 mismatch. 337 If there is a trigger which would cause the protection LSP to be 338 used, such as SF or MS, a node MUST NOT use the protection LSP to 339 carry traffic. 341 7. Security Considerations 343 These changes and clarifications raise no new security concerns. 345 8. IANA Considerations 347 IANA is requested to mark the value 0 in the "MPLS PSC TLV Registry" 348 as "Reserved, not to be allocated" and to update the references to 349 show [RFC6378] and [RFC-ietf-mpls-psc-updates-03]. Note that this 350 action provides documentation of an action already taken by IANA but 351 not recorded in RFC 6378. 353 9. Acknowledgements 355 The author of this document thanks Taesik Cheung, Alessandro 356 D'Alessandro, Annamaria Fulignoli, Sagar Soni, George Swallow and 357 Yaacov Weingarten for their contributions and review, and Adrian 358 Farrel for the text of Section 2. 360 10. References 362 10.1. Normative References 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, March 1997. 367 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 368 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 369 Protection", RFC 6378, October 2011. 371 10.2. Informative References 373 [LIAISON] ITU-T SG15, "Liaison Statement: Recommendation ITU-T 374 G.8131/Y.1382 revision - Linear protection switching for 375 MPLS-TP networks", . 378 Author's Address 380 Eric Osborne 382 Email: eric.osborne@notcom.com