idnits 2.17.1 draft-ietf-mpls-tp-aps-updates-00.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 (March 19, 2016) is 2953 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: September 20, 2016 Hai Gaoming BV 7 I. Busi 8 G. Weng 9 Huawei Technologies 10 March 19, 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-00.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. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 20, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 61 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Initialization Behavior . . . . . . . . . . . . . . . . . 4 64 4.2. State Transition Modification . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 MPLS Transport Profile (MPLS-TP) linear protection in Automatic 76 Protection Switching (APS) mode is defined in RFC 7271 [RFC7271]. It 77 defines a set of alternate and additional mechanisms to perform some 78 of the functions of linear protection described in RFC 6378 79 [RFC6378]. The actions performed at initialization of the Protection 80 State Coordination (PSC) Control Logic are not described in either 81 [RFC7271] or [RFC6378]. Although it is a common perception that the 82 state machine starts at the Normal state, this is not explicitly 83 specified in any of the documents and various questions have been 84 raised by implementers and in discussions on the MPLS working group 85 mailing list concerning the detailed actions that the PSC Control 86 Logic should take. 88 The state machine described in [RFC7271] operates under the 89 assumption that both end nodes of a linear protection domain start in 90 the Normal state. In the case that one node reboots while the other 91 node is still in operation, various scenarios may arise resulting in 92 problematic situations. This document resolves all the problematic 93 cases and minimizes traffic disruptions related to initialization 94 including both cold and warm reboots that require re-initialization 95 of the PSC Control Logic. 97 This document contains updates to the MPLS-TP linear protection in 98 APS mode defined in [RFC7271]. The updates provide rules related to 99 initialization of the PSC Control Logic, in which the state machine 100 resides, when operating in APS mode. The updates also include 101 modifications to the state transition table defined in Section 11.2 102 of [RFC7271]. The changes in the state transition table have been 103 examined to make sure that they do not introduce any new problems. 105 This document does not introduce backward compatibility issues with 106 implementations of [RFC7271]. In case a node implementing this 107 document restarts, the new state changes will not cause problems at 108 the remote node implementing [RFC7271] and the two ends will converge 109 to the same local and remote states. In case a node implementing 110 [RFC7271] restarts, the two ends behave as today. 112 The reader of this document is assumed to be familiar with [RFC7271]. 114 2. Conventions Used in This Document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 3. Acronyms 122 This document uses the following acronyms: 124 APS Automatic Protection Switching 125 DNR Do-not-Revert 126 E::R Exercise state due to remote EXER message 127 EXER Exercise 128 MS-P Manual Switch to Protection path 129 MS-W Manual Switch to Working path 130 MPLS-TP MPLS Transport Profile 131 N Normal state 132 NR No Request 133 PF:DW:R Protecting Failure state due to remote SD-W message 134 PF:W:L Protecting Failure state due to local SF-W 135 PF:W:R Protecting Failure state due to remote SF-W message 136 PSC Protection State Coordination 137 RR Reverse Request 138 SD Signal Degrade 139 SF-P Signal Fail on Protection path 140 SF-W Signal Fail on Working path 141 UA:P:L Unavailable state due to local SF-P 142 WTR Wait-to-Restore 144 4. Updates 146 This document updates [RFC7271] by specifying the actions that will 147 be performed at the initialization of the PSC Control Logic and 148 modifies the state transition table defined in Section 11.2 of 149 [RFC7271]. 151 4.1. Initialization Behavior 153 This section defines initialization behavior that is not described in 154 [RFC7271]. 156 When the PSC Control Logic is initialized, the following actions MUST 157 be performed: 159 o Stop the WTR timer if it is running. 161 o Clear any operator command in the Local Request Logic. 163 o If an SF-W or SF-P exists as the highest local request, the node 164 being initialized starts at the PF:W:L or UA:P:L state, 165 respectively. 167 o If the node being initialized has no local request: 169 * If the node being initialized does not remember the active path 170 or if the node being initialized remembers the working path as 171 the active path, the node starts at the Normal state. 173 * Else (the node being initialized remembers the protection path 174 as the active path), the node starts at the WTR state sending 175 NR(0,1) or at the DNR state sending DNR(0,1) depending on the 176 configuration that allows or prevents automatic reversion to 177 the Normal state. 179 o In case any local SD exists, the local SD MUST be considered as an 180 input to the Local Request Logic only after the local node has 181 received the first protocol message from the remote node and 182 completed the processing (i.e., updated the PSC Control Logic and 183 decided which action, if any, to be sent to the PSC Message 184 Generator). 186 o If the local node receives an EXER message as the first protocol 187 message after initialization and the remote EXER becomes the top- 188 priority global request, the local node MUST set the position of 189 the bridge and selector according to the Path value in the EXER 190 message and transit to the E::R state. 192 Remembering the active path in case of no local request minimizes 193 traffic switchovers in cases where the remote node is still in 194 operation. This approach does not cause a problem even if the 195 remembered active path is no longer valid due to any local input that 196 occurred at the remote node while the initializing node was out of 197 operation. 199 It is worth noting that in some restart scenarios (e.g., cold 200 rebooting) no valid SF/SD indications may be present at the input of 201 the Local Request logic. In this case, the PSC Control Logic would 202 restart as if no local requests are present. If a valid SF/SD 203 indication is detected later, this would be notified to the PSC 204 Control Logic and trigger state change. 206 4.2. State Transition Modification 208 In addition to the initialization behavior described in Section 4.1, 209 four cells of the remote state transition table need to be changed to 210 make two end nodes converge after initialization. State transition 211 by remote message defined in Section 11.2 of [RFC7271] is modified as 212 follows (only modified cells are shown): 214 | MS-W | MS-P | WTR | EXER | RR | DNR | NR 215 --------+---------+---------+-----+------+----+------+---- 216 N | | | (13)| | | DNR | 217 PF:W:R | | | | | | DNR | 218 PF:DW:R | | | | | | DNR | 220 The changes in two rows of remote protecting failure states lead to 221 the replacement of note (10) with DNR, therefore note (10) is no 222 longer needed. The resultant three rows read: 224 | MS-W | MS-P | WTR | EXER | RR | DNR | NR 225 --------+---------+---------+-----+------+----+------+---- 226 N | SA:MW:R | SA:MP:R | (13)| E::R | i | DNR | i 227 PF:W:R | SA:MW:R | SA:MP:R | (9) | E::R | i | DNR | (11) 228 PF:DW:R | SA:MW:R | SA:MP:R | (9) | E::R | i | DNR | (11) 230 5. Security Considerations 232 No specific security issue is raised in addition to those ones 233 already documented in [RFC7271]. It may be noted that tightening the 234 description of initializing behavior may help to protect networks 235 from re-start attacks. 237 6. IANA Considerations 239 This document makes no request of IANA. 241 Note to RFC Editor: this section may be removed on publication as an 242 RFC. 244 7. Acknowledgements 246 The authors would like to thank Joaquim Serra for bringing up the 247 issue related to initialization of the PSC Control Logic at the very 248 beginning. The authors would also like to thank Adrian Farrel for 249 his valuable comments and suggestions on this document. 251 8. References 253 8.1. Normative References 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, 257 DOI 10.17487/RFC2119, March 1997, 258 . 260 [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., 261 D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS 262 Transport Profile (MPLS-TP) Linear Protection to Match the 263 Operational Expectations of Synchronous Digital Hierarchy, 264 Optical Transport Network, and Ethernet Transport Network 265 Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, 266 . 268 8.2. Informative References 270 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 271 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 272 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 273 October 2011, . 275 Authors' Addresses 277 Jeong-dong Ryoo 278 ETRI 280 EMail: ryoo@etri.re.kr 281 Taesik Cheung 282 ETRI 284 EMail: cts@etri.re.kr 286 Huub van Helvoort 287 Hai Gaoming BV 289 EMail: huubatwork@gmail.com 291 Italo Busi 292 Huawei Technologies 294 EMail: Italo.Busi@huawei.com 296 Guangjuan Weng 297 Huawei Technologies 299 EMail: wenguangjuan@huawei.com