idnits 2.17.1 draft-ali-ccamp-mpls-graceful-shutdown-02.txt: -(190): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(191): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(219): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(226): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(251): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(362): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(365): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(374): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(375): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(379): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(384): 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 -(389): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(395): 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 307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 320. ** 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 20 instances of lines with non-ascii characters in the document. 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 (October 2005) is 6739 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 252, but not defined == Unused Reference: 'RSVP-TE' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'OSPF-GMPLS' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'ISIS-GMPLS' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'OSPF-TE' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'OSPF-CAP' is defined on line 374, but no explicit reference was found in the text == Unused Reference: 'ISIS-CAP' is defined on line 378, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'ISIS-GMPLS') == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') -- Possible downref: Normative reference to a draft: ref. 'OSPF-CAP' -- 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: 7 errors (**), 0 flaws (~~), 15 warnings (==), 10 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: April 2005 11 October 2005 13 draft-ali-ccamp-mpls-graceful-shutdown-02.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 MPLS-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. MPLS-TE graceful shutdown mechanisms 44 are tailored towards addressing the planned outage in the network. 46 This document provides requirements and protocol mechanisms so as to 47 reduce/eliminate traffic disruption in the event of a planned 48 shutdown of a network resource. These operations are equally 49 applicable for both classical MPLS and its GMPLS extensions. 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC-2119 [i]. 57 Table of Contents 59 1. Terminology........................................................2 60 2. Introduction.......................................................3 61 3. Requirements for Graceful Shutdown.................................3 62 4. Mechanisms for Graceful Shutdown...................................4 63 4.1 RSVP-TE Signaling Mechanism for graceful shutdown...............4 64 4.1.1 Graceful Shutdown of TE link(s)...............................4 65 4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link...5 66 4.1.3 Graceful Shutdown of TE Node..................................5 67 4.2 OSPF/ ISIS Mechanisms for graceful shutdown.....................5 68 4.2.1 Graceful Shutdown of TE link(s)...............................6 69 4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link...6 70 4.2.3 Graceful Shutdown of TE Node..................................6 71 5. Security Considerations............................................6 72 6. IANA Considerations................................................6 73 7. Intellectual Property Considerations...............................7 74 8. Full Copyright Statement...........................................7 75 9. Acknowledgments....................................................7 76 10. Reference.........................................................7 77 10.1 Normative Reference............................................7 78 10.2 Informative Reference..........................................8 80 1. 81 Terminology 83 Node - Label Switching Device. 85 LSP - An MPLS Label Switched Path 87 Head-end or Ingress node: In the draft term head-end node equally 88 applies to the Ingress node that initiated signaling for the Path, or 89 an intermediate node (in the case of loose hops path computation) or 90 a Path Computation Element (PCE) that computes the routes on behalf 91 of its clients (PCC). 93 GMPLS - The term GMPLS is used in this document to refer to both 94 classic MPLS, as well as the GMPLS extensions to MPLS. 96 TE Link - The term TE link refers to a physical link or an FA-LSP, on 97 which traffic engineering is enabled. A TE link can be bundled or 98 unbundled. 100 2. Introduction 102 When outages in a network are planned, some mechanisms can be used to 103 avoid traffic disruption. This is in contrast with unplanned network 104 element failure, where traffic disruption can be reduced but may not 105 avoided. Hence, a Service Provider may desire to gracefully 106 (temporarily or definitely) disable TE on a TE Link, a group of TE 107 Links or an entire node for administrative reasons such as link 108 maintenance, software/hardware upgrade at a node or significant TE 109 configuration changes. In all these cases, the goal is to minimize 110 impact on the GMPLS Traffic Engineered flows in the network by 111 bringing down the protocol before the administrative procedures are 112 started. 114 Graceful shutdown of a resource may require several steps. These 115 steps can be broadly divided into two sets: disabling the resource in 116 the control plane and removing the resource for forwarding. The node 117 initiating the graceful shutdown condition SHOULD delay the removal 118 of the resources for forwarding, for some period determined by local 119 policy. This is to allow control plane to gracefully divert the 120 traffic away from the resource being gracefully shutdown. 122 This document describes the mechanisms that can be used to gracefully 123 shutdown GMPLS Traffic Engineering on a resource. As mentioned 124 earlier, the graceful shutdown of Traffic Engineering could be 125 incorporated in the traditional shutdown operation of an interface, 126 but it is a separate step that is taken before the IGP on the link is 127 brought down and before the interface is brought down at different 128 layers. This document only talks applicable for TE node and TE 129 resources. 131 3. Requirements for Graceful Shutdown 133 This section lists the requirements for graceful shutdown in the 134 context of GMPLS Traffic Engineering. 136 - Graceful shutdown must address graceful removal of one TE link, one 137 component link within a bundled TE link, a set of TE links, a set of 138 component links or an entire node. 140 - It is required to prevent other network nodes to use the network 141 Similarly it is required to reduce/eliminate traffic disruption on 142 the LSP-s using the network resources which are about to be shutdown. 144 - Trigger for the graceful shutdown event is a local matter at the 145 node initiating the graceful shutdown. Typically, graceful shutdown 146 is triggered for administrative reasons, such as link maintenance or 147 software/hardware upgrade at a node. 149 - Graceful shutdown mechanisms are required to address TE LSPs 150 spanning multiple domains, as well as intra domain TE LSPs. Here, a 151 domain is defined as either an IGP area or an Autonomous System 152 [INTER-AREA-AS]. 154 - Graceful shutdown is equally applicable to GMPLS-TE, as well as 155 classical MPLS-TE LSPs. 157 - In order to make rerouting effective, it is required to communicate 158 information about the TE resource under graceful shutdown. 160 4. Mechanisms for Graceful Shutdown 162 An IGP only based solution is not applicable when dealing with Inter- 163 area and Inter-AS traffic engineering, as LSA or LSP flooding is 164 restricted to IGP areas/levels. Consequently, RSVP based mechanisms 165 are required to cope with TE LSPs spanning multiple domains. At the 166 same time, as RSVP mechanisms only convey the information for the 167 transiting LSPs to the router along the upstream Path and not to all 168 nodes in the network, indication of graceful shutdown via IGP 169 flooding is required to discourage a node from establishing new LSPs 170 through the resources being shut-down. In the following sections the 171 complementary mechanisms for RSVP-TE and IGP for Graceful Shutdown 172 are described. 174 4.1 RSVP-TE Signaling Mechanism for graceful shutdown 176 As discussed in Section 3, one of the requirements for the signaling 177 mechanism for graceful shutdown is to carry information about the 178 resource under graceful shutdown. Therefore, the Graceful Shutdown 179 mechanism outlined in the following section, uses Path Error and 180 where available, Notify message, in order to achieve this 181 requirement. These mechanisms are applicable to the existing LSPs. 182 Setup request for new LSPs over the TE resource being gracefully 183 shutdown SHOULD be rejected using the existing mechanisms that are 184 applied when the TE resource is not available. 186 4.1.1 Graceful Shutdown of TE link(s) 188 The node where graceful-shutdown of a link or a set of links is 189 desired MUST trigger a Path Error message with ��local link 190 maintenance required�� sub-code for all affected LSPs. The ��local TE 191 link maintenance required�� error code as defined in [PATH-REOPT]. If 192 available, and where notify requests were included when the LSPs were 193 initially setup, Notify message MAY also be used for fast delivery of 194 this information to the head-end nodes. 196 When a head-end node receives Path Error (or Notify message) message 197 with sub-code "Local Maintenance on TE Link required Flag", it SHOULD 198 immediately trigger a make-before-break procedure. If the LSP is 199 protected, switchover procedure may be triggered. A head-end node 200 SHOULD avoid the IP address contained in the PathErr (or Notify 201 message) when performing path computation for the new LSP. 203 4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 205 MPLS TE Link Bundling draft [BUNDLE] requires that an LSP is pinned 206 down to component link(s). Hence, when a component link is shut-down, 207 the LSPs affected by such maintenance action needs to be re-signaled. 209 Graceful shutdown of a component link in a bundled TE link differs 210 from graceful shutdown of unbundled TE link or entire bundled TE 211 link. Specifically, in the former case, when only a subset of 212 component links and not the entire TE bundled link is being shutdown, 213 the remaining component links of the TE links may still be able to 214 admit new LSPs. Consequently a new error sub-code for PathError or 215 Notify message is needed: 217 9 (TBA) Local component link maintenance required 219 Error Sub-code for ��Local component link maintenance required�� is to 220 be assigned by IANA. 222 If the last component link is being shut-down, the procedure outlined 223 in Section 5.1 is used. 225 When a head-end node receives an RSVP PathError or Notify message 226 with sub-code "local component link maintenance required�� Flag set, 227 it SHOULD immediately perform a make-before-break to avoid traffic 228 loss. The head-end node MAY still use the IP address contained in the 229 PathErr or Notify message in performing path computation for 230 rerouting the LSP. This is because, this address is an IP address of 231 the component link and the flag is an implicit indication that the TE 232 link may still have capacity to admit new LSPs. However, if the ERO 233 is computed such that it also provides details of the component link 234 selection(s) along the Path, the component link selection with IP 235 address contained in the PathErr or Notify message SHOULD be avoided. 237 4.1.3 Graceful Shutdown of TE Node 239 When graceful shutdown at node level is desired, the node in question 240 follows the procedure specified in the previous section for all TE 241 Links. 243 4.2 OSPF/ ISIS Mechanisms for graceful shutdown 244 The procedures provided in this section are equally applicable to 245 OSPF and ISIS. 247 4.2.1 Graceful Shutdown of TE link(s) 249 The node where graceful-shutdown of a link is desired MUST originate 250 the TE LSA/LSP containing link-attribute sub-TLV with ��local 251 maintenance required�� bit set. The link-attribute sub-TLV defined in 252 [OSPF-LINK-ATTRI] and [ISIS-LINK-ATTRI]. 254 Extension to link attribute sub-TLV is preferred over the use of 255 (MAX-METRIC, zero Bandwidth) based solution, as links with (MAX- 256 METRIC, zero bandwidth) can be used as last resort links in path 257 computation, for zero bandwidth LSPs. Nonetheless, to deal with nodes 258 not compliant with this document, the node initiating graceful 259 shutdown MAY originate the TE LSA/LSP containing Link TLV with 0 260 unreserved bandwidth, Traffic Engineering metric set to 0xffffffff, 261 and if the Link is non-PSC then also with 0 as Max LSP Bandwidth. 263 Neighbors of the node where graceful shutdown procedure is in 264 progress SHOULD continue to advertise the actual unreserved bandwidth 265 of the TE links from the neighbors to that node, without any routing 266 adjacency change. 268 The nodes receiving link-attribute sub-TLV with graceful shutdown 269 indication SHOULD mark the link as unusable for further path 270 computation in both directions. 272 4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 274 If graceful shutdown procedure is performed for a component link 275 within a TE Link bundle and it is not the last component link 276 available within the TE link, the link attributes associated with the 277 TE link are recomputed. If the removal of the component link results 278 in a significant change event, the TE link is re-flooded with the new 279 traffic parameters. If the last component link is being shut-down, 280 the routing procedure outlined in Section 4.2.1 is used. 282 4.2.3 Graceful Shutdown of TE Node 284 When graceful shutdown at node level is desired, the node in question 285 follows the procedure specified in the previous section for all TE 286 Links. 288 5. Security Considerations 290 This document does not introduce new security issues. The security 291 considerations pertaining to the original RSVP protocol [RSVP] remain 292 relevant. 294 6. IANA Considerations 295 A new error sub-code for Path Error and Notify message is needed for 296 ��Local component link maintenance required�� flag. 298 7. Intellectual Property Considerations 300 The IETF takes no position regarding the validity or scope of any 301 Intellectual Property Rights or other rights that might be claimed to 302 pertain to the implementation or use of the technology described in 303 this document or the extent to which any license under such rights 304 might or might not be available; nor does it represent that it has 305 made any independent effort to identify any such rights. Information 306 on the procedures with respect to rights in RFC documents can be 307 found in BCP 78 and BCP 79. 309 Copies of IPR disclosures made to the IETF Secretariat and any 310 assurances of licenses to be made available, or the result of an 311 attempt made to obtain a general license or permission for the use of 312 such proprietary rights by implementers or users of this 313 specification can be obtained from the IETF on-line IPR repository at 314 http://www.ietf.org/ipr. 316 The IETF invites any interested party to bring to its attention any 317 copyrights, patents or patent applications, or other proprietary 318 rights that may cover technology that may be required to implement 319 this standard. Please address the information to the IETF at ietf- 320 ipr@ietf.org. 322 8. Full Copyright Statement 324 Copyright (C) The Internet Society (2005). This document is subject to 325 the rights, licenses and restrictions contained in BCP 78, and except as 326 set forth therein, the authors retain all their rights. 328 Disclaimer of Validity 330 This document and the information contained herein are provided on an 331 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 332 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 333 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 334 IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 335 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 336 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 338 9. Acknowledgments 340 The authors would like to acknowledge useful comments from David Ward, 341 Sami Boutros, Adrian Farrel and Dimitri Papadimitriou. 343 10. Reference 345 10.1 Normative Reference 347 [RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version 348 1, Functional Specification", RFC 2205, September 1997. 350 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 351 3209, December 2001. 353 [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS) 354 Signaling Functional Description, RFC 3471, L. Berger, et al, January 355 2003. 357 [RFC3473] L. Berger, et al, "Generalized Multi-Protocol Label 358 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 359 Engineering (RSVP-TE) Extensions", RFC 3473. 361 [OSPF-GMPLS] K. Kompella, Y. Rekhter, et al, ��OSPF Extensions in 362 Support of Generalized MPLS��, draft-ietf-ccamp-ospf-gmpls-extensions- 363 12.txt. 365 [ISIS-GMPLS] K. Kompella, Y. Rekhter, et al, ��IS-IS Extensions in 366 Support of Generalized MPLS��, draft-ietf-isis-gmpls-extensions- 367 19.txt. 369 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 370 Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic-10.txt. 372 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 373 Engineering", draft-ietf-isis-traffic-04.txt. 374 [OSPF-CAP] Jean-Philippe Vasseur, P. Psenak, and S. Yasukawa, ��OSPF 375 MPLS Traffic Engineering capabilities�� draft-vasseur-ccamp-ospf-te- 376 caps-00.txt. 378 [ISIS-CAP] Jean-Philippe Vasseur, S. Previdi, J. Mabey, and Jean- 379 Louis Le Roux, ��IS-IS MPLS Traffic Engineering capabilities��, draft- 380 vasseur-ccamp-isis-te-caps-00.txt. 382 [OSPF-LINK-ATTRI] work in progress. 384 [ISIS-LINK_ATTRI] Jean-Philippe Vasseur, S. Previdi, ��Definition of 385 an IS-IS Link Attribute sub-TLV��, draft-vasseur-isis-link-attr- 386 00.txt. 388 [PATH-REOPT] Jean-Philippe Vasseur, and Y. Ikejiri, ��Reoptimization 389 of MPLS Traffic Engineering loosely routed LSP paths��, draft-ietf- 390 ccamp-loose-path-reopt-01.txt. 392 10.2 Informative Reference 394 [INTER-AREA-AS] Adrian Farrel, Jean-Philippe Vasseur, Arthi Ayyangar, 395 ��A Framework for Inter-Domain MPLS Traffic Engineering��, draft-ietf- 396 ccamp-inter-domain-framework-04.txt. 398 [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 399 MPLS Traffic Engineering", draft-ietf-mpls-bunle-04.txt (work in 400 progress) 402 Authors' Address: 404 Zafar Ali 405 Cisco systems, Inc., 406 2000 Innovation Drive 407 Kanata, Ontario, K2K 3E8 408 Canada. 409 Email: zali@cisco.com 411 Jean Philippe Vasseur 412 Cisco Systems, Inc. 413 300 Beaver Brook Road 414 Boxborough , MA - 01719 415 USA 416 Email: jpv@cisco.com 418 Anca Zamfir 419 Cisco Systems, Inc. 420 2000 Innovation Drive 421 Kanata, Ontario, K2K 3E8 422 Canada 423 Email: ancaz@cisco.com