idnits 2.17.1 draft-ali-ccamp-mpls-graceful-shutdown-04.txt: -(197): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(198): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(225): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(232): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(358): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(359): 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 -(366): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(372): 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 3978, Section 5.5 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 319. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 13 instances of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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 (June 2006) is 6526 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) == Unused Reference: 'RSVP-TE' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 354, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'RFC4205' is defined on line 361, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'RFC4205') ** 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 (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking 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: December 2006 11 June 2006 13 draft-ali-ccamp-mpls-graceful-shutdown-04.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 Traffic Engineering (TE) enabled network that the TE 43 capability on a link or on an entire Label Switching Router (LSR) is 44 going to be disabled. GMPLS-TE graceful shutdown mechanisms are 45 tailored towards addressing the planned outage in the 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 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)...............................5 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.....................6 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............................................6 73 6. IANA Considerations................................................6 74 7. Intellectual Property Considerations...............................7 75 8. Full Copyright Statement...........................................7 76 9. Acknowledgments....................................................7 77 10. Reference.........................................................7 78 10.1 Normative Reference............................................7 79 10.2 Informative Reference..........................................8 81 1. Terminology 83 LSR - Label Switching Device. 85 LSP - An MPLS Label Switched Path 87 Head-end or Ingress node: In this document the terms head-end node 88 equally applies to the Ingress node that initiated signaling for the 90 Path, or an intermediate node (in the case of loose hops path 91 computation) or a Path Computation Element (PCE) that computes the 92 routes on behalf of its clients (PCC). 94 GMPLS - The term GMPLS is used in this document to refer to both 95 classic MPLS, as well as the GMPLS extensions to MPLS. 97 TE Link - The term TE link refers to a physical link or an FA-LSP, on 98 which traffic engineering is enabled. A TE link can be bundled or 99 unbundled. 101 The terms node and LSR will be used interchangeably in this document. 103 2. Introduction 105 When outages in a network are planned (e.g. for maintenance purpose), 106 some mechanisms can be used to avoid traffic disruption. This is in 107 contrast with unplanned network element failure, where traffic 108 disruption can be minimized thanks to recovery mechanisms but may not 109 be 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 the impact on the GMPLS traffic engineered flows carried 115 over TE LSPs in the network by triggering notifications so as to 116 graceful reroute such flows before the administrative procedures are 117 started. 119 Graceful shutdown of a resource may require several steps. These 120 steps can be broadly divided into two sets: disabling the resource in 121 the control plane and removing the resource for forwarding. The node 122 initiating the graceful shutdown condition SHOULD delay the removal 123 of the resources for forwarding, for some period determined by local 124 policy. This is to allow control plane to gracefully divert the 125 traffic away from the resource being gracefully shutdown. Similarly, 126 trigger for the graceful shutdown event is a local matter at the node 127 initiating the graceful shutdown. Typically, graceful shutdown is 128 triggered for administrative reasons, such as link maintenance or 129 software/hardware upgrade at a node. 131 This document describes the mechanisms that can be used to gracefully 132 shutdown GMPLS Traffic Engineering on a resource. As mentioned 133 earlier, the graceful shutdown of the Traffic Engineering capability 134 on a resource could be incorporated in the traditional shutdown 135 operation of an interface, but it is a separate step that is taken 136 before the IGP on the link is brought down and before the interface 137 is brought down at different layers. This document only addresses TE 138 node and TE resources. 140 3. Requirements for Graceful Shutdown 142 This section lists the requirements for graceful shutdown in the 143 context of GMPLS Traffic Engineering. 145 - Graceful shutdown must address graceful removal of one TE link, one 146 component link within a bundled TE link, a set of TE links, a set of 147 component links or an entire node. 149 - It is required to prevent other network nodes to use the network 150 resources that are about to be shutdown, should new TE LSP be set up. 151 Similarly it is required to reduce/eliminate traffic disruption on 152 the LSP(s) using the network resources which are about to be 153 shutdown. 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 packet-based (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. Mechanisms for Graceful Shutdown 168 An IGP only based solution is not applicable when dealing with Inter- 169 area and Inter-AS traffic engineering, as IGP LSA/LSP flooding is 170 restricted to IGP areas/levels. Consequently, RSVP based mechanisms 171 are required to cope with TE LSPs spanning multiple domains. At the 172 same time, RSVP mechanisms only convey the information for the 173 transiting LSPs to the router along the upstream Path and not to all 174 nodes in the network. Furthermore, it must be noted that graceful 175 shutdown notification via IGP flooding is required to discourage a 176 node from establishing new LSPs through the resources being shutdown. 177 In the following sections the complementary mechanisms for RSVP-TE 178 and IGP for Graceful Shutdown are described. 180 4.1 RSVP-TE Signaling Mechanism for graceful shutdown 182 As discussed in Section 3, one of the requirements for the signaling 183 mechanism for graceful shutdown is to carry information about the 184 resource under graceful shutdown. The Graceful Shutdown mechanism 185 outlined in the following section, uses Path Error and where 186 available, Notify message, in order to achieve this requirement. Such 187 mechanisms relying on signaling are only applicable to the existing 188 LSPs. 189 Setup request for new LSPs over the TE resource being gracefully 190 shutdown SHOULD be rejected using the existing mechanisms that are 191 applied when the TE resource is not available. 193 4.1.1 Graceful Shutdown of TE link(s) 195 The node where graceful shutdown of a link or a set of links is 196 desired MUST trigger a Path Error message with ��local link 197 maintenance required�� sub-code for all affected LSPs. The ��local TE 198 link maintenance required�� error code is defined in [PATH-REOPT]. If 199 available, and where notify requests were included when the LSPs were 200 initially setup, Notify message (as defined in []) MAY also be used 201 for delivery of this information to the head-end nodes. 203 When a head-end LSR receives a Path Error (or Notify) message with 204 sub-code "Local Maintenance on TE Link required Flag", it SHOULD 205 immediately trigger a make-before-break procedure. A head-end node 206 SHOULD avoid the IP address contained in the PathErr (or Notify 207 message) when performing path computation for the new LSP. 209 4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 211 MPLS TE Link Bundling [BUNDLE] requires that an LSP is pinned down to 212 component link(s). Hence, when a component link is shutdown, the TE 213 LSPs affected by such maintenance action needs to be resignaled. 215 Graceful shutdown of a component link in a bundled TE link differs 216 from graceful shutdown of unbundled TE link or entire bundled TE 217 link. Specifically, in the former case, when only a subset of 218 component links and not the entire TE bundled link is being shutdown, 219 the remaining component links of the TE links may still be able to 220 admit new LSPs. Consequently a new error sub-code for PathError and 221 Notify message is needed: 223 9 (TBA) Local component link maintenance required 225 Error Sub-code for ��Local component link maintenance required�� is to 226 be assigned by IANA. 228 If the last component link is being shutdown, the procedure outlined 229 in Section 5.1 is used. 231 When a head-end LSR receives an RSVP Path Error or Notify message 232 with sub-code "local component link maintenance required�� Flag set, 233 it SHOULD immediately perform a make-before-break to avoid traffic 234 loss. The head-end LSR MAY still use the IP address contained in the 235 Path Error or Notify message in performing path computation for 236 rerouting the LSP. This is because, this address is an IP address of 237 the component link and the flag is an implicit indication that the TE 238 link may still have capacity to admit new LSPs. However, if the ERO 239 is computed such that it also provides details of the component link 240 selection(s) along the Path, the component link selection with IP 241 address contained in the Path Error or Notify message SHOULD be 242 avoided. 244 4.1.3 Graceful Shutdown of TE Node 246 When graceful shutdown at node level is desired, the node in question 247 follows the procedure specified in the previous section for all TE 248 Links. 250 4.2 OSPF/ ISIS Mechanisms for graceful shutdown 252 The procedures provided in this section are equally applicable to 253 OSPF and ISIS. 255 4.2.1 Graceful Shutdown of TE link(s) 257 The node where graceful-shutdown of a link is desired MUST originate 258 the TE LSA/LSP containing Link TLV for the link under graceful 259 shutdown with Traffic Engineering metric set to 0xffffffff, 0 as 260 unreserved bandwidth, and if the link has LSC or FSC as its 261 Switching Capability then also with 0 as Max LSP Bandwidth. This 262 would discourage new LSP establishment through the link under 263 graceful shutdown. 265 Neighbors of the node where graceful shutdown procedure is in 266 progress SHOULD continue to advertise the actual unreserved bandwidth 267 of the TE links from the neighbors to that node, without any routing 268 adjacency change. 270 4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 272 If graceful shutdown procedure is performed for a component link 273 within a TE Link bundle and it is not the last component link 274 available within the TE link, the link attributes associated with the 275 TE link are recomputed. If the removal of the component link results 276 in a significant bandwidth change event, a new LSA is originated with 277 the new traffic parameters. If the last component link is being 278 shutdown, the routing procedure outlined in Section 4.2.1 is used. 280 4.2.3 Graceful Shutdown of TE Node 282 When graceful shutdown at node level is desired, the node in question 283 follows the procedure specified in the previous section for all TE 284 Links. 286 5. Security Considerations 288 This document does not introduce new security issues. The security 289 considerations pertaining to the original RSVP protocol [RSVP] remain 290 relevant. 292 6. IANA Considerations 294 A new error sub-code for Path Error and Notify message is needed for 295 ��Local component link maintenance required�� flag. 297 7. Intellectual Property Considerations 299 The IETF takes no position regarding the validity or scope of any 300 Intellectual Property Rights or other rights that might be claimed to 301 pertain to the implementation or use of the technology described in 302 this document or the extent to which any license under such rights 303 might or might not be available; nor does it represent that it has 304 made any independent effort to identify any such rights. Information 305 on the procedures with respect to rights in RFC documents can be 306 found in BCP 78 and BCP 79. 308 Copies of IPR disclosures made to the IETF Secretariat and any 309 assurances of licenses to be made available, or the result of an 310 attempt made to obtain a general license or permission for the use of 311 such proprietary rights by implementers or users of this 312 specification can be obtained from the IETF on-line IPR repository at 313 http://www.ietf.org/ipr. 315 The IETF invites any interested party to bring to its attention any 316 copyrights, patents or patent applications, or other proprietary 317 rights that may cover technology that may be required to implement 318 this standard. Please address the information to the IETF at 319 ietf-ipr@ietf.org. 321 8. Full Copyright Statement 323 Copyright (C) The Internet Society (2006). This document is subject 324 to the rights, licenses and restrictions contained in BCP 78, and 325 except as set forth therein, the authors retain all their rights. 327 This document and the information contained herein are provided on an 328 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 329 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 330 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 331 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 332 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 333 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 335 9. Acknowledgments 337 The authors would like to acknowledge useful comments from David Ward, 338 Sami Boutros, Adrian Farrel and Dimitri Papadimitriou. 340 10. Reference 342 10.1 Normative Reference 344 [RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version 345 1, Functional Specification", RFC 2205, September 1997. 347 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 348 3209, December 2001. 350 [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS) 351 Signaling Functional Description, RFC 3471, L. Berger, et al, January 352 2003. 354 [RFC3473] L. Berger, et al, "Generalized Multi-Protocol Label 355 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 356 Engineering (RSVP-TE) Extensions", RFC 3473. 358 [RFC4203] K. Kompella, Y. Rekhter, et al, ��OSPF Extensions in Support 359 of Generalized MPLS��, draft-ietf-ccamp-ospf-gmpls-extensions-12.txt. 361 [RFC4205] K. Kompella, Y. Rekhter, et al, ��IS-IS Extensions in 362 Support of Generalized MPLS��, draft-ietf-isis-gmpls-extensions- 363 19.txt. 365 [PATH-REOPT] Jean-Philippe Vasseur, and Y. Ikejiri, ��Reoptimization 366 of MPLS Traffic Engineering loosely routed LSP paths��, draft-ietf- 367 ccamp-loose-path-reopt-02.txt. 369 10.2 Informative Reference 371 [INTER-AREA-AS] Adrian Farrel, Jean-Philippe Vasseur, Arthi Ayyangar, 372 ��A Framework for Inter-Domain MPLS Traffic Engineering��, draft-ietf- 373 ccamp-inter-domain-framework-04.txt. 375 [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 376 MPLS Traffic Engineering", draft-ietf-mpls-bunle-04.txt (work in 377 progress) 379 Authors' Address: 381 Zafar Ali 382 Cisco systems, Inc., 383 2000 Innovation Drive 384 Kanata, Ontario, K2K 3E8 385 Canada. 386 Email: zali@cisco.com 388 Jean Philippe Vasseur 389 Cisco Systems, Inc. 390 300 Beaver Brook Road 391 Boxborough , MA - 01719 392 USA 393 Email: jpv@cisco.com 395 Anca Zamfir 396 Cisco Systems, Inc. 397 2000 Innovation Drive 398 Kanata, Ontario, K2K 3E8 399 Canada 400 Email: ancaz@cisco.com