idnits 2.17.1 draft-ietf-mpls-tp-aps-updates-04.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 RFC7271, but the abstract doesn't seem to directly say this. It does mention RFC7271 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 (June 3, 2017) is 2518 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group J. Ryoo 3 Internet-Draft T. Cheung 4 Updates: 7271 (if approved) ETRI 5 Intended status: Standards Track H. van Helvoort 6 Expires: December 5, 2017 Hai Gaoming BV 7 I. Busi 8 G. Wen 9 Huawei Technologies 10 June 3, 2017 12 Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in 13 Automatic Protection Switching (APS) Mode 14 draft-ietf-mpls-tp-aps-updates-04.txt 16 Abstract 18 This document contains updates to MPLS Transport Profile (MPLS-TP) 19 linear protection in Automatic Protection Switching (APS) mode 20 defined in RFC 7271. The updates provide rules related to the 21 initialization of the Protection State Coordination (PSC) Control 22 Logic, in which the state machine resides, when operating in APS 23 mode, and clarify some operation related to state transition table 24 lookup. 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 December 5, 2017. 43 Copyright Notice 45 Copyright (c) 2017 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. Conventions Used in This Document . . . . . . . . . . . . . . 3 62 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Initialization Behavior . . . . . . . . . . . . . . . . . 4 65 4.2. State Transition Modification . . . . . . . . . . . . . . 5 66 4.3. Operation related to State Transition Table Lookup . . . 6 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 8.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 MPLS Transport Profile (MPLS-TP) linear protection in Automatic 78 Protection Switching (APS) mode is defined in RFC 7271 [RFC7271]. It 79 defines a set of alternate and additional mechanisms to perform some 80 of the functions of linear protection described in RFC 6378 81 [RFC6378]. The actions performed at initialization of the Protection 82 State Coordination (PSC) Control Logic are not described in either 83 [RFC7271] or [RFC6378]. Although it is a common perception that the 84 state machine starts at the Normal state, this is not explicitly 85 specified in any of the documents and various questions have been 86 raised by implementers and in discussions on the MPLS working group 87 mailing list concerning the detailed actions that the PSC Control 88 Logic should take. 90 The state machine described in [RFC7271] operates under the 91 assumption that both end nodes of a linear protection domain start in 92 the Normal state. In the case that one node reboots while the other 93 node is still in operation, various scenarios may arise resulting in 94 problematic situations. This document resolves all the problematic 95 cases and minimizes traffic disruptions related to initialization 96 including both cold and warm reboots that require re-initialization 97 of the PSC Control Logic. 99 This document contains updates to the MPLS-TP linear protection in 100 APS mode defined in [RFC7271]. The updates provide rules related to 101 initialization of the PSC Control Logic, in which the state machine 102 resides, when operating in APS mode. The updates also include 103 modifications to the state transition table defined in Section 11.2 104 of [RFC7271]. The changes in the state transition table have been 105 examined to make sure that they do not introduce any new problems. 107 This document does not introduce backward compatibility issues with 108 implementations of [RFC7271]. In case a node implementing this 109 document restarts, the new state changes will not cause problems at 110 the remote node implementing [RFC7271] and the two ends will converge 111 to the same local and remote states. In case a node implementing 112 [RFC7271] restarts, the two ends behave as today. 114 This document also provides some clarifications on the operation 115 related to state transition table lookup. 117 The reader of this document is assumed to be familiar with [RFC7271]. 119 2. Conventions Used in This Document 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 3. Acronyms 126 This document uses the following acronyms: 128 APS Automatic Protection Switching 129 DNR Do-not-Revert 130 E::R Exercise state due to remote EXER message 131 EXER Exercise 132 MS-P Manual Switch to Protection path 133 MS-W Manual Switch to Working path 134 MPLS-TP MPLS Transport Profile 135 NR No Request 136 PF:DW:R Protecting Failure state due to remote SD-W message 137 PF:W:L Protecting Failure state due to local SF-W 138 PF:W:R Protecting Failure state due to remote SF-W message 139 PSC Protection State Coordination 140 RR Reverse Request 141 SA:MP:R Switching Administrative state due to remote MS-P message 142 SA:MW:R Switching Administrative state due to remote MS-W message 143 SD Signal Degrade 144 SF-P Signal Fail on Protection path 145 SF-W Signal Fail on Working path 146 UA:P:L Unavailable state due to local SF-P 147 WTR Wait-to-Restore 149 4. Updates 151 This section specifies the actions that will be performed at the 152 initialization of the PSC Control Logic and the modifications of the 153 state transition table defined in Section 11.2 of [RFC7271]. Some 154 clarifications on the operation related to state transition table 155 lookup are also provided. 157 4.1. Initialization Behavior 159 This section defines initialization behavior that is not described in 160 [RFC7271]. 162 When the PSC Control Logic is initialized, the following actions MUST 163 be performed: 165 o Stop the WTR timer if it is running. 167 o Clear any operator command in the Local Request Logic. 169 o If an SF-W or SF-P exists as the highest local request, the node 170 being initialized starts at the PF:W:L or UA:P:L state, 171 respectively. 173 o If the node being initialized has no local request: 175 * If the node being initialized does not remember the active path 176 or if the node being initialized remembers the working path as 177 the active path, the node starts at the Normal state. 179 * Else (the node being initialized remembers the protection path 180 as the active path), the node starts at the WTR state sending 181 NR(0,1) or at the DNR state sending DNR(0,1) depending on the 182 configuration that allows or prevents automatic reversion to 183 the Normal state. 185 o In case any local SD exists, the local SD MUST be considered as an 186 input to the Local Request Logic only after the local node has 187 received the first protocol message from the remote node and 188 completed the processing (i.e., updated the PSC Control Logic and 189 decided which action, if any, to be sent to the PSC Message 190 Generator). 192 o If the local node receives an EXER message as the first protocol 193 message after initialization and the remote EXER becomes the top- 194 priority global request, the local node MUST set the position of 195 the bridge and selector according to the Path value in the EXER 196 message and transit to the E::R state. 198 Remembering the active path in case of no local request minimizes 199 traffic switchovers in cases where the remote node is still in 200 operation. This approach does not cause a problem even if the 201 remembered active path is no longer valid due to any local input that 202 occurred at the remote node while the initializing node was out of 203 operation. 205 It is worth noting that in some restart scenarios (e.g., cold 206 rebooting) no valid SF/SD indications may be present at the input of 207 the Local Request logic. In this case, the PSC Control Logic would 208 restart as if no local requests are present. If a valid SF/SD 209 indication is detected later, this would be notified to the PSC 210 Control Logic and trigger state change. 212 4.2. State Transition Modification 214 In addition to the initialization behavior described in Section 4.1, 215 four cells of the remote state transition table need to be changed to 216 make two end nodes converge after initialization. State transition 217 by remote message defined in Section 11.2 of [RFC7271] is modified as 218 follows (only modified cells are shown): 220 | MS-W | MS-P | WTR | EXER | RR | DNR | NR 221 --------+---------+---------+-----+------+----+------+---- 222 N | | | (13)| | | DNR | 223 PF:W:R | | | | | | DNR | 224 PF:DW:R | | | | | | DNR | 226 The changes in two rows of remote protecting failure states lead to 227 the replacement of note (10) with DNR, therefore note (10) is no 228 longer needed. The resultant three rows read: 230 | MS-W | MS-P | WTR | EXER | RR | DNR | NR 231 --------+---------+---------+-----+------+----+------+---- 232 N | SA:MW:R | SA:MP:R | (13)| E::R | i | DNR | i 233 PF:W:R | SA:MW:R | SA:MP:R | (9) | E::R | i | DNR | (11) 234 PF:DW:R | SA:MW:R | SA:MP:R | (9) | E::R | i | DNR | (11) 236 In the tables above, the letters 'i' and 'N' stand for "ignore" and 237 "Normal state", respectively. Other acronyms can be found in 238 Section 3. 240 4.3. Operation related to State Transition Table Lookup 242 In addition to the rules related to the state transition table lookup 243 listed in Section 11 of [RFC7271], the following rule is also applied 244 to the operation related to the state transition table lookup: 246 o When the local SF-P is cleared and the priorities of the local and 247 remote requests are re-evaluated, the last received remote message 248 may not be valid any more due to the previous failure of the 249 protection path. Therefore, the last received message MUST be 250 treated as if it were NR and only the local request shall be 251 evaluated. 253 The last paragraph in Section 11 of [RFC7271] is modified as follows: 255 --------- 256 Old text: 257 --------- 258 In the state transition tables below, the letter 'i' stands for 259 "ignore" and is an indication to remain in the current state and 260 continue transmitting the current PSC message. 261 --------- 262 New text: 263 --------- 264 In the state transition tables below, the letter 'i' is the 265 "ignore" flag, and if it is set it means that the top-priority 266 global request is ignored. 268 If re-evaluation is triggered, it is checked if the ignore flag is 269 set. If it is, the state machine will transit to the supposed state, 270 which can be Normal or DNR as indicated in the footnotes to the 271 state transition tables. If the ignore flag is not set, the state 272 machine will transit to the state indicated in the cell of the state 273 transition table. 275 If re-evaluation is not triggered, it is checked if the ignore flag 276 is set. If it is, the state machine will remain in the current state, 277 and the current PSC message continues to be transmitted. If the 278 ignore flag is not set, the state machine will transit to the state 279 indicated in the cell of the state transition table. 281 5. Security Considerations 283 No specific security issue is raised in addition to those ones 284 already documented in [RFC7271]. It may be noted that tightening the 285 description of initializing behavior may help to protect networks 286 from re-start attacks. 288 6. IANA Considerations 290 This document makes no request of IANA. 292 Note to RFC Editor: this section may be removed on publication as an 293 RFC. 295 7. Acknowledgements 297 The authors would like to thank Joaquim Serra for bringing up the 298 issue related to initialization of the PSC Control Logic at the very 299 beginning. The authors would also like to thank Adrian Farrel and 300 Loa Andersson for their valuable comments and suggestions on this 301 document. 303 8. References 305 8.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, 309 DOI 10.17487/RFC2119, March 1997, 310 . 312 [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., 313 D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS 314 Transport Profile (MPLS-TP) Linear Protection to Match the 315 Operational Expectations of Synchronous Digital Hierarchy, 316 Optical Transport Network, and Ethernet Transport Network 317 Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, 318 . 320 8.2. Informative References 322 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 323 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 324 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 325 October 2011, . 327 Authors' Addresses 329 Jeong-dong Ryoo 330 ETRI 332 EMail: ryoo@etri.re.kr 334 Taesik Cheung 335 ETRI 337 EMail: cts@etri.re.kr 339 Huub van Helvoort 340 Hai Gaoming BV 342 EMail: huubatwork@gmail.com 344 Italo Busi 345 Huawei Technologies 347 EMail: Italo.Busi@huawei.com 348 Guangjuan Wen 349 Huawei Technologies 351 EMail: wenguangjuan@huawei.com