idnits 2.17.1 draft-ali-ccamp-mpls-graceful-shutdown-03.txt: -(198): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(199): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(227): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(234): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(260): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(380): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(381): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(388): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(393): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(397): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(398): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(405): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 338. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 18 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2006) is 6615 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) == Missing Reference: 'ISIS-LINK-ATTRI' is mentioned on line 261, but not defined == Unused Reference: 'RSVP-TE' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC4205' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'ISIS-CAP' is defined on line 387, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'RFC4205') -- Possible downref: Normative reference to a draft: ref. 'ISIS-CAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPF-LINK-ATTRI' == Outdated reference: A later version (-02) exists of draft-ietf-ccamp-loose-path-reopt-01 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-loose-path-reopt (ref. 'PATH-REOPT') == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-inter-domain-framework-04 -- No information found for draft-ietf-mpls-bunle - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group 3 Zafar Ali 4 Jean Philippe Vasseur 5 Anca Zamfir 6 Cisco Systems, Inc. 8 IETF Internet Draft 9 Category: Standard track 10 Expires: September 2006 11 March 2006 13 draft-ali-ccamp-mpls-graceful-shutdown-03.txt 15 Graceful Shutdown in GMPLS Traffic Engineering Networks 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 GMPLS-TE Graceful shutdown is a method for explicitly notifying the 42 nodes in a TE network that the TE protocol on a link or on an entire 43 TE node is going to be disabled. GMPLS-TE graceful shutdown 44 mechanisms are tailored towards addressing the planned outage in the 45 network. 47 This document provides requirements and protocol mechanisms so as to 48 reduce/eliminate traffic disruption in the event of a planned 49 shutdown of a network resource. These operations are equally 50 applicable for both classical MPLS and its GMPLS extensions. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [i]. 58 Table of Contents 60 1. Terminology........................................................2 61 2. Introduction.......................................................3 62 3. Requirements for Graceful Shutdown.................................3 63 4. Mechanisms for Graceful Shutdown...................................4 64 4.1 RSVP-TE Signaling Mechanism for graceful shutdown...............4 65 4.1.1 Graceful Shutdown of TE link(s)...............................4 66 4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link...5 67 4.1.3 Graceful Shutdown of TE Node..................................5 68 4.2 OSPF/ ISIS Mechanisms for graceful shutdown.....................5 69 4.2.1 Graceful Shutdown of TE link(s)...............................6 70 4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link...6 71 4.2.3 Graceful Shutdown of TE Node..................................6 72 5. Security Considerations............................................7 73 6. IANA Considerations................................................7 74 7. Intellectual Property Considerations...............................7 75 8. Full Copyright Statement...........................................7 76 9. Acknowledgments....................................................7 77 10. Reference.........................................................8 78 10.1 Normative Reference............................................8 79 10.2 Informative Reference..........................................8 81 1. 82 Terminology 84 Node - Label Switching Device. 86 LSP - An MPLS Label Switched Path 88 Head-end or Ingress node: In the draft term head-end node equally 89 applies to the Ingress node that initiated signaling for the Path, or 90 an intermediate node (in the case of loose hops path computation) or 91 a Path Computation Element (PCE) that computes the routes on behalf 92 of its clients (PCC). 94 GMPLS - 95 - The term GMPLS is used in this document to refer to both 96 classic MPLS, as well as the GMPLS extensions to MPLS. 98 TE Link - 99 - The term TE link refers to a physical link or an FA-LSP, on 100 which traffic engineering is enabled. A TE link can be bundled or 101 unbundled. 103 2. 104 Introduction 106 When outages in a network are planned, some mechanisms can be used to 107 avoid traffic disruption. This is in contrast with unplanned network 108 element failure, where traffic disruption can be reduced but may not 109 avoided. Hence, a Service Provider may desire to gracefully 110 (temporarily or definitely) disable Traffic Engineering on a TE Link, 111 a group of TE Links or an entire node for administrative reasons such 112 as link maintenance, software/hardware upgrade at a node or 113 significant TE configuration changes. In all these cases, the goal is 114 to minimize impact on the GMPLS Traffic Engineered flows in the 115 network by bringing down the protocol before the administrative 116 procedures are started. 118 Graceful shutdown of a resource may require several steps. These 119 steps can be broadly divided into two sets: disabling the resource in 120 the control plane and removing the resource for forwarding. The node 121 initiating the graceful shutdown condition SHOULD delay the removal 122 of the resources for forwarding, for some period determined by local 123 policy. This is to allow control plane to gracefully divert the 124 traffic away from the resource being gracefully shutdown. 126 This document describes the mechanisms that can be used to gracefully 127 shutdown GMPLS Traffic Engineering on a resource. As mentioned 128 earlier, the graceful shutdown of Traffic Engineering could be 129 incorporated in the traditional shutdown operation of an interface, 130 but it is a separate step that is taken before the IGP on the link is 131 brought down and before the interface is brought down at different 132 layers. This document only talks applicable for TE node and TE 133 resources. 135 3. 136 Requirements for Graceful Shutdown 138 This section lists the requirements for graceful shutdown in the 139 context of GMPLS Traffic Engineering. 141 - Graceful shutdown must address graceful removal of one TE link, one 142 component link within a bundled TE link, a set of TE links, a set of 143 component links or an entire node. 145 resources that are about to be shutdown, should new TE LSP be set up. 147 Similarly it is required to reduce/eliminate traffic disruption on 148 the LSP-s using the network resources which are about to be shutdown. 150 - Trigger for the graceful shutdown event is a local matter at the 151 node initiating the graceful shutdown. Typically, graceful shutdown 152 is triggered for administrative reasons, such as link maintenance or 153 software/hardware upgrade at a node. 155 - Graceful shutdown mechanisms are required to address TE LSPs 156 spanning multiple domains, as well as intra domain TE LSPs. Here, a 157 domain is defined as either an IGP area or an Autonomous System 158 [INTER-AREA-AS]. 160 - Graceful shutdown is equally applicable to GMPLS-TE, as well as 161 classical MPLS-TE LSPs. 163 - In order to make rerouting effective, it is required to communicate 164 information about the TE resource under graceful shutdown. 166 4. 167 Mechanisms for Graceful Shutdown 169 An IGP only based solution is not applicable when dealing with Inter- 170 area and Inter-AS traffic engineering, as LSA or LSP flooding is 171 restricted to IGP areas/levels. Consequently, RSVP based mechanisms 172 are required to cope with TE LSPs spanning multiple domains. At the 173 same time, as RSVP mechanisms only convey the information for the 174 transiting LSPs to the router along the upstream Path and not to all 175 nodes in the network, indication of graceful shutdown via IGP 176 flooding is required to discourage a node from establishing new LSPs 177 through the resources being shut-down. In the following sections the 178 complementary mechanisms for RSVP-TE and IGP for Graceful Shutdown 179 are described. 181 4.1 182 RSVP-TE Signaling Mechanism for graceful shutdown 184 As discussed in Section 3, one of the requirements for the signaling 185 mechanism for graceful shutdown is to carry information about the 186 resource under graceful shutdown. Therefore, the Graceful Shutdown 187 mechanism outlined in the following section, uses Path Error and 188 where available, Notify message, in order to achieve this 189 requirement. These mechanisms are applicable to the existing LSPs. 190 Setup request for new LSPs over the TE resource being gracefully 191 shutdown SHOULD be rejected using the existing mechanisms that are 192 applied when the TE resource is not available. 194 4.1.1 Graceful Shutdown of TE link(s) 196 The node where graceful-shutdown of a link or a set of links is 197 desired MUST trigger a Path Error message with ��local link 198 maintenance required�� sub-code for all affected LSPs. The ��local TE 199 link maintenance required�� error code as defined in [PATH-REOPT]. If 200 available, and where notify requests were included when the LSPs were 201 initially setup, Notify message MAY also be used for fast delivery of 202 this information to the head-end nodes. 204 When a head-end node receives Path Error (or Notify message) message 205 with sub-code "Local Maintenance on TE Link required Flag", it SHOULD 206 immediately trigger a make-before-break procedure. If the LSP is 207 protected, switchover procedure may be triggered. A head-end node 208 SHOULD avoid the IP address contained in the PathErr (or Notify 209 message) when performing path computation for the new LSP. 211 4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 213 MPLS TE Link Bundling draft [BUNDLE] requires that an LSP is pinned 214 down to component link(s). Hence, when a component link is shut-down, 215 the LSPs affected by such maintenance action needs to be re-signaled. 217 Graceful shutdown of a component link in a bundled TE link differs 218 from graceful shutdown of unbundled TE link or entire bundled TE 219 link. Specifically, in the former case, when only a subset of 220 component links and not the entire TE bundled link is being shutdown, 221 the remaining component links of the TE links may still be able to 222 admit new LSPs. Consequently a new error sub-code for PathError or 223 Notify message is needed: 225 9 (TBA) Local component link maintenance required 227 Error Sub-code for ��Local component link maintenance required�� is to 228 be assigned by IANA. 230 If the last component link is being shut-down, the procedure outlined 231 in Section 5.1 is used. 233 When a head-end node receives an RSVP PathError or Notify message 234 with sub-code "local component link maintenance required�� Flag set, 235 it SHOULD immediately perform a make-before-break to avoid traffic 236 loss. The head-end node MAY still use the IP address contained in the 237 PathErr or Notify message in performing path computation for 238 rerouting the LSP. This is because, this address is an IP address of 239 the component link and the flag is an implicit indication that the TE 240 link may still have capacity to admit new LSPs. However, if the ERO 241 is computed such that it also provides details of the component link 242 selection(s) along the Path, the component link selection with IP 243 address contained in the PathErr or Notify message SHOULD be avoided. 245 4.1.3 Graceful Shutdown of TE Node 247 When graceful shutdown at node level is desired, the node in question 248 follows the procedure specified in the previous section for all TE 249 Links. 251 4.2 252 OSPF/ ISIS Mechanisms for graceful shutdown 253 The procedures provided in this section are equally applicable to 254 OSPF and ISIS. 256 4.2.1 Graceful Shutdown of TE link(s) 258 The node where graceful-shutdown of a link is desired MUST originate 259 the TE LSA/LSP containing link-attribute sub-TLV with ��local 260 maintenance required�� bit set. The link-attribute sub-TLV defined in 261 [OSPF-LINK-ATTRI] and [ISIS-LINK-ATTRI]. 263 Extension to link attribute sub-TLV is preferred over the use of 264 (MAX-METRIC, zero Bandwidth) based solution. This is because a link 265 may end-up with max metric for multiple reasons and without the link 266 attribute there is no way a node can tell what the reason is, e.g. a 267 restarting node may advertises the max matrices. Furthermore, if the 268 resource under graceful deletion is the last resort then the node 269 hosting the graceful deletion resource will not receive new signaling 270 messages. Nonetheless, to deal with nodes not compliant with this 271 document (i.e., does not implement link attribute sub-TLV based 272 solution), the node initiating graceful shutdown MAY originate the TE 273 LSA/LSP containing Link TLV with 0 unreserved bandwidth, Traffic 274 Engineering metric set to 0xffffffff, and if the Link is non-PSC then 275 also with 0 as Max LSP Bandwidth. 277 Neighbors of the node where graceful shutdown procedure is in 278 progress SHOULD continue to advertise the actual unreserved bandwidth 279 of the TE links from the neighbors to that node, without any routing 280 adjacency change. 282 The nodes receiving link-attribute sub-TLV with graceful shutdown 283 indication SHOULD mark the link as unusable for further path 284 computation in both directions. 286 4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 288 If graceful shutdown procedure is performed for a component link 289 within a TE Link bundle and it is not the last component link 290 available within the TE link, the link attributes associated with the 291 TE link are recomputed. If the removal of the component link results 292 in a significant change event, the TE link is re-flooded with the new 293 traffic parameters. If the last component link is being shut-down, 294 the routing procedure outlined in Section 4.2.1 is used. 296 4.2.3 Graceful Shutdown of TE Node 298 When graceful shutdown at node level is desired, the node in question 299 follows the procedure specified in the previous section for all TE 300 Links. 302 5. 303 Security Considerations 305 This document does not introduce new security issues. The security 306 considerations pertaining to the original RSVP protocol [RSVP] remain 307 relevant. 309 6. 310 IANA Considerations 312 A new error sub-code for Path Error and Notify message is needed for 313 ��Local component link maintenance required�� flag. 315 7. 316 Intellectual Property Considerations 318 The IETF takes no position regarding the validity or scope of any 319 Intellectual Property Rights or other rights that might be claimed to 320 pertain to the implementation or use of the technology described in 321 this document or the extent to which any license under such rights 322 might or might not be available; nor does it represent that it has 323 made any independent effort to identify any such rights. Information 324 on the procedures with respect to rights in RFC documents can be 325 found in BCP 78 and BCP 79. 327 Copies of IPR disclosures made to the IETF Secretariat and any 328 assurances of licenses to be made available, or the result of an 329 attempt made to obtain a general license or permission for the use of 330 such proprietary rights by implementers or users of this 331 specification can be obtained from the IETF on-line IPR repository at 332 http://www.ietf.org/ipr. 334 The IETF invites any interested party to bring to its attention any 335 copyrights, patents or patent applications, or other proprietary 336 rights that may cover technology that may be required to implement 337 this standard. Please address the information to the IETF at ietf- 338 ipr@ietf.org. 340 8. 341 Full Copyright Statement 343 Copyright (C) The Internet Society (2006). This document is subject to 344 the rights, licenses and restrictions contained in BCP 78, and except as 345 set forth therein, the authors retain all their rights. 347 This document and the information contained herein are provided on an 348 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 349 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 350 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 351 IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 352 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 353 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 355 9. 357 The authors would like to acknowledge useful comments from David Ward, 358 Sami Boutros, Adrian Farrel and Dimitri Papadimitriou. 360 10. 361 Reference 363 10.1 364 Normative Reference 366 [RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version 367 1, Functional Specification", RFC 2205, September 1997. 369 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 370 3209, December 2001. 372 [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS) 373 Signaling Functional Description, RFC 3471, L. Berger, et al, January 374 2003. 376 [RFC3473] L. Berger, et al, "Generalized Multi-Protocol Label 377 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 378 Engineering (RSVP-TE) Extensions", RFC 3473. 380 [RFC4203] K. Kompella, Y. Rekhter, et al, ��OSPF Extensions in Support 381 of Generalized MPLS��, draft-ietf-ccamp-ospf-gmpls-extensions-12.txt. 383 [RFC4205] K. Kompella, Y. Rekhter, et al, ��IS-IS Extensions in 384 Support of Generalized MPLS��, draft-ietf-isis-gmpls-extensions- 385 19.txt. 387 [ISIS-CAP] Jean-Philippe Vasseur, S. Previdi, J. Mabey, and Jean- 388 Louis Le Roux, ��IS-IS MPLS Traffic Engineering capabilities��, draft- 389 vasseur-ccamp-isis-te-caps-00.txt. 391 [OSPF-LINK-ATTRI] work in progress. 393 [ISIS-LINK_ATTRI] Jean-Philippe Vasseur, S. Previdi, ��Definition of 394 an IS-IS Link Attribute sub-TLV��, draft-vasseur-isis-link-attr- 395 00.txt. 397 [PATH-REOPT] Jean-Philippe Vasseur, and Y. Ikejiri, ��Reoptimization 398 of MPLS Traffic Engineering loosely routed LSP paths��, draft-ietf- 399 ccamp-loose-path-reopt-01.txt. 401 10.2 402 Informative Reference 404 [INTER-AREA-AS] Adrian Farrel, Jean-Philippe Vasseur, Arthi Ayyangar, 405 ��A Framework for Inter-Domain MPLS Traffic Engineering��, draft-ietf- 406 ccamp-inter-domain-framework-04.txt. 408 [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 409 MPLS Traffic Engineering", draft-ietf-mpls-bunle-04.txt (work in 410 progress) 412 Authors' Address: 414 Zafar Ali 415 Cisco systems, Inc., 416 2000 Innovation Drive 417 Kanata, Ontario, K2K 3E8 418 Canada. 419 Email: zali@cisco.com 421 Jean Philippe Vasseur 422 Cisco Systems, Inc. 423 300 Beaver Brook Road 424 Boxborough , MA - 01719 425 USA 426 Email: jpv@cisco.com 428 Anca Zamfir 429 Cisco Systems, Inc. 430 2000 Innovation Drive 431 Kanata, Ontario, K2K 3E8 432 Canada 433 Email: ancaz@cisco.com