idnits 2.17.1 draft-ietf-mpls-tp-aps-updates-01.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 (September 15, 2016) is 2780 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: March 19, 2017 Hai Gaoming BV 7 I. Busi 8 G. Weng 9 Huawei Technologies 10 September 15, 2016 12 Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in 13 Automatic Protection Switching (APS) Mode 14 draft-ietf-mpls-tp-aps-updates-01.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 March 19, 2017. 43 Copyright Notice 45 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . 7 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 N Normal state 136 NR No Request 137 PF:DW:R Protecting Failure state due to remote SD-W message 138 PF:W:L Protecting Failure state due to local SF-W 139 PF:W:R Protecting Failure state due to remote SF-W message 140 PSC Protection State Coordination 141 RR Reverse Request 142 SD Signal Degrade 143 SF-P Signal Fail on Protection path 144 SF-W Signal Fail on Working path 145 UA:P:L Unavailable state due to local SF-P 146 WTR Wait-to-Restore 148 4. Updates 150 This section specifies the actions that will be performed at the 151 initialization of the PSC Control Logic and the modifications of the 152 state transition table defined in Section 11.2 of [RFC7271]. Some 153 clarifications on the operation related to state transition table 154 lookup are also provided. 156 4.1. Initialization Behavior 158 This section defines initialization behavior that is not described in 159 [RFC7271]. 161 When the PSC Control Logic is initialized, the following actions MUST 162 be performed: 164 o Stop the WTR timer if it is running. 166 o Clear any operator command in the Local Request Logic. 168 o If an SF-W or SF-P exists as the highest local request, the node 169 being initialized starts at the PF:W:L or UA:P:L state, 170 respectively. 172 o If the node being initialized has no local request: 174 * If the node being initialized does not remember the active path 175 or if the node being initialized remembers the working path as 176 the active path, the node starts at the Normal state. 178 * Else (the node being initialized remembers the protection path 179 as the active path), the node starts at the WTR state sending 180 NR(0,1) or at the DNR state sending DNR(0,1) depending on the 181 configuration that allows or prevents automatic reversion to 182 the Normal state. 184 o In case any local SD exists, the local SD MUST be considered as an 185 input to the Local Request Logic only after the local node has 186 received the first protocol message from the remote node and 187 completed the processing (i.e., updated the PSC Control Logic and 188 decided which action, if any, to be sent to the PSC Message 189 Generator). 191 o If the local node receives an EXER message as the first protocol 192 message after initialization and the remote EXER becomes the top- 193 priority global request, the local node MUST set the position of 194 the bridge and selector according to the Path value in the EXER 195 message and transit to the E::R state. 197 Remembering the active path in case of no local request minimizes 198 traffic switchovers in cases where the remote node is still in 199 operation. This approach does not cause a problem even if the 200 remembered active path is no longer valid due to any local input that 201 occurred at the remote node while the initializing node was out of 202 operation. 204 It is worth noting that in some restart scenarios (e.g., cold 205 rebooting) no valid SF/SD indications may be present at the input of 206 the Local Request logic. In this case, the PSC Control Logic would 207 restart as if no local requests are present. If a valid SF/SD 208 indication is detected later, this would be notified to the PSC 209 Control Logic and trigger state change. 211 4.2. State Transition Modification 213 In addition to the initialization behavior described in Section 4.1, 214 four cells of the remote state transition table need to be changed to 215 make two end nodes converge after initialization. State transition 216 by remote message defined in Section 11.2 of [RFC7271] is modified as 217 follows (only modified cells are shown): 219 | MS-W | MS-P | WTR | EXER | RR | DNR | NR 220 --------+---------+---------+-----+------+----+------+---- 221 N | | | (13)| | | DNR | 222 PF:W:R | | | | | | DNR | 223 PF:DW:R | | | | | | DNR | 225 The changes in two rows of remote protecting failure states lead to 226 the replacement of note (10) with DNR, therefore note (10) is no 227 longer needed. The resultant three rows read: 229 | MS-W | MS-P | WTR | EXER | RR | DNR | NR 230 --------+---------+---------+-----+------+----+------+---- 231 N | SA:MW:R | SA:MP:R | (13)| E::R | i | DNR | i 232 PF:W:R | SA:MW:R | SA:MP:R | (9) | E::R | i | DNR | (11) 233 PF:DW:R | SA:MW:R | SA:MP:R | (9) | E::R | i | DNR | (11) 235 4.3. Operation related to State Transition Table Lookup 237 In addition to the rules related to the state transition table lookup 238 listed in Section 11 of [RFC7271], the following rule is also applied 239 to the operation related to the state transition table lookup: 241 o When the local SF-P is cleared and the priorities of the local and 242 remote requests are re-evaluated, the last received remote message 243 may not be valid any more due to the previous failure of the 244 protection path. Therefore, the last received message MUST be 245 treated as if it were NR and only the local request shall be 246 evaluated. 248 The last paragraph in Section 11 of [RFC7271] is modified as follows: 250 --------- 251 Old text: 252 --------- 253 In the state transition tables below, the letter 'i' stands for 254 "ignore" and is an indication to remain in the current state and 255 continue transmitting the current PSC message. 256 --------- 257 New text: 258 --------- 259 In the state transition tables below, the letter 'i' stands for 260 "ignore" and the top-priority global request is ignored. 261 Therefore, the next state can be either the current state 262 transmitting the current PSC message or the supposed state 263 (Normal or DNR depending on the footnotes to the state transition 264 tables) in case of re-evaluation. 266 5. Security Considerations 268 No specific security issue is raised in addition to those ones 269 already documented in [RFC7271]. It may be noted that tightening the 270 description of initializing behavior may help to protect networks 271 from re-start attacks. 273 6. IANA Considerations 275 This document makes no request of IANA. 277 Note to RFC Editor: this section may be removed on publication as an 278 RFC. 280 7. Acknowledgements 282 The authors would like to thank Joaquim Serra for bringing up the 283 issue related to initialization of the PSC Control Logic at the very 284 beginning. The authors would also like to thank Adrian Farrel for 285 his valuable comments and suggestions on this document. 287 8. References 289 8.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., 297 D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS 298 Transport Profile (MPLS-TP) Linear Protection to Match the 299 Operational Expectations of Synchronous Digital Hierarchy, 300 Optical Transport Network, and Ethernet Transport Network 301 Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, 302 . 304 8.2. Informative References 306 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 307 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 308 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 309 October 2011, . 311 Authors' Addresses 313 Jeong-dong Ryoo 314 ETRI 316 EMail: ryoo@etri.re.kr 318 Taesik Cheung 319 ETRI 321 EMail: cts@etri.re.kr 323 Huub van Helvoort 324 Hai Gaoming BV 326 EMail: huubatwork@gmail.com 328 Italo Busi 329 Huawei Technologies 331 EMail: Italo.Busi@huawei.com 333 Guangjuan Weng 334 Huawei Technologies 336 EMail: wenguangjuan@huawei.com