idnits 2.17.1 draft-ietf-mpls-tp-aps-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 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 (February 21, 2017) is 2621 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: August 25, 2017 Hai Gaoming BV 7 I. Busi 8 G. Wen 9 Huawei Technologies 10 February 21, 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-03.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 August 25, 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 i ignore 133 MS-P Manual Switch to Protection path 134 MS-W Manual Switch to Working path 135 MPLS-TP MPLS Transport Profile 136 N Normal state 137 NR No Request 138 PF:DW:R Protecting Failure state due to remote SD-W message 139 PF:W:L Protecting Failure state due to local SF-W 140 PF:W:R Protecting Failure state due to remote SF-W message 141 PSC Protection State Coordination 142 RR Reverse Request 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 4.3. Operation related to State Transition Table Lookup 238 In addition to the rules related to the state transition table lookup 239 listed in Section 11 of [RFC7271], the following rule is also applied 240 to the operation related to the state transition table lookup: 242 o When the local SF-P is cleared and the priorities of the local and 243 remote requests are re-evaluated, the last received remote message 244 may not be valid any more due to the previous failure of the 245 protection path. Therefore, the last received message MUST be 246 treated as if it were NR and only the local request shall be 247 evaluated. 249 The last paragraph in Section 11 of [RFC7271] is modified as follows: 251 --------- 252 Old text: 253 --------- 254 In the state transition tables below, the letter 'i' stands for 255 "ignore" and is an indication to remain in the current state and 256 continue transmitting the current PSC message. 257 --------- 258 New text: 259 --------- 260 In the state transition tables below, the letter 'i' is the 261 "ignore" flag, and if it is set it means that the top-priority 262 global request is ignored. 264 If re-evaluation is triggered, it is checked if the ignore flag is 265 set. If it is, the state machine will transit to the supposed state, 266 which can be Normal or DNR as indicated in the footnotes to the 267 state transition tables. If the ignore flag is not set, the state 268 machine will transit to the state indicated in the cell of the state 269 transition table. 271 If re-evaluation is not triggered, it is checked if the ignore flag 272 is set. If it is, the state machine will remain in the current state, 273 and the current PSC message continues to be transmitted. If the 274 ignore flag is not set, the state machine will transit to the state 275 indicated in the cell of the state transition table. 277 5. Security Considerations 279 No specific security issue is raised in addition to those ones 280 already documented in [RFC7271]. It may be noted that tightening the 281 description of initializing behavior may help to protect networks 282 from re-start attacks. 284 6. IANA Considerations 286 This document makes no request of IANA. 288 Note to RFC Editor: this section may be removed on publication as an 289 RFC. 291 7. Acknowledgements 293 The authors would like to thank Joaquim Serra for bringing up the 294 issue related to initialization of the PSC Control Logic at the very 295 beginning. The authors would also like to thank Adrian Farrel and 296 Loa Andersson for their valuable comments and suggestions on this 297 document. 299 8. References 301 8.1. Normative References 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, 305 DOI 10.17487/RFC2119, March 1997, 306 . 308 [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., 309 D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS 310 Transport Profile (MPLS-TP) Linear Protection to Match the 311 Operational Expectations of Synchronous Digital Hierarchy, 312 Optical Transport Network, and Ethernet Transport Network 313 Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, 314 . 316 8.2. Informative References 318 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 319 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 320 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 321 October 2011, . 323 Authors' Addresses 325 Jeong-dong Ryoo 326 ETRI 328 EMail: ryoo@etri.re.kr 330 Taesik Cheung 331 ETRI 333 EMail: cts@etri.re.kr 335 Huub van Helvoort 336 Hai Gaoming BV 338 EMail: huubatwork@gmail.com 340 Italo Busi 341 Huawei Technologies 343 EMail: Italo.Busi@huawei.com 344 Guangjuan Wen 345 Huawei Technologies 347 EMail: wenguangjuan@huawei.com