idnits 2.17.1 draft-ali-ccamp-mpls-graceful-shutdown-00.txt: -(177): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(242): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(274): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(368): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(383): 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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 22 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 514 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 9 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When a head-end node or an intermediate node (in the case of loose hops path computation) or a PCE receives an RSVP Path Error notification with sub-code "local component link maintenance required� Flag set, it SHOULD immediately perform a make-before-break to avoid traffic loss. The head-end router or an intermediate node (in the case of loose hops path computation) or a PCE MAY NOT avoid the IP address contained in the PathErr in performing path computation for rerouting the LSP. This is because, as mentioned earlier, this address is an IP address of the component link and the flag is an implicit indication that the TE link may still have capacity to admit new LSPs. However, if the ERO is to be computed such that it also provides details of the component link selection(s) along the Path, the component link selection with IP address contained in the PathErr SHOULD be avoided. -- 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 2004) is 7226 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3209' is mentioned on line 72, but not defined == Missing Reference: 'RFC 3473' is mentioned on line 72, but not defined == Missing Reference: 'ISIS-LINK-ATTRI' is mentioned on line 177, but not defined == Missing Reference: 'FRR' is mentioned on line 241, but not defined == Unused Reference: 'RSVP-TE' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'OSPF-GMPLS' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'ISIS-GMPLS' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'OSPF-TE' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'OSPF-CAP' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'ISIS-CAP' is defined on line 367, but no explicit reference was found in the text ** Downref: Normative reference to an Proposed Standard RFC: RFC 2205 (ref. 'RSVP') ** Downref: Normative reference to an Proposed Standard RFC: RFC 3209 (ref. 'RSVP-TE') ** Downref: Normative reference to an Proposed Standard RFC: RFC 3471 ** Downref: Normative reference to an Proposed Standard RFC: RFC 3473 ** Downref: Normative reference to an Proposed Standard draft: draft-ietf-ccamp-ospf-gmpls-extensions (ref. 'OSPF-GMPLS') ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'ISIS-GMPLS') ** Downref: Normative reference to an Proposed Standard draft: draft-katz-yeung-ospf-traffic (ref. 'OSPF-TE') == 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') == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-05 ** Downref: Normative reference to an Proposed Standard draft: draft-ietf-mpls-rsvp-lsp-fastreroute (ref. 'MPLS-FRR') -- 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-vasseur-ccamp-loose-path-reopt-01 -- Possible downref: Normative reference to a draft: ref. 'PATH-REOPT' == Outdated reference: A later version (-01) exists of draft-farrel-ccamp-inter-domain-framework-00 -- No information found for draft-ietf-mpls-bunle - is the name correct? Summary: 14 errors (**), 0 flaws (~~), 20 warnings (==), 8 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 10 Expires: December, 2004 June 2004 12 draft-ali-ccamp-mpls-graceful-shutdown-00.txt 14 Graceful Shutdown in MPLS Traffic Engineering Networks 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC2026. Internet-Drafts are 20 Working documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Z. Ali, et al. Page 1 6/14/2004 36 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 38 Abstract 40 Graceful shutdown is a method for explicitly notifying a set of LSRs 41 that either a Link or an entire node will remove itself from the 42 network or the protocol is going to be disabled for a link or a node. 43 Graceful shut down mechanisms are tailored towards addressing the 44 planned outage in the network. 46 This document provides protocol mechanisms so as to reduce/eliminate 47 traffic disruption in the event of a planned shutdown of a network 48 resource. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC-2119 [i]. 56 Routing Area ID Summary 58 (This section to be removed before publication.) 60 SUMMARY 62 This document describes graceful shutdown mechanisms used in MPLS 63 Traffic Engineering network. 65 WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK? 67 This work requires protocol extension to signaling (RSVP-TE) and 68 routing (OSPF/ ISIS) protocols that are under IETF Routing Area. 70 WHY IS IT TARGETED AT THIS WG? 72 This work fits in the context of [RFC 3209], [RFC 3473] and 73 extensions to these RFCs being defined in CCAMP. 75 RELATED REFERENCES 77 See the reference section. 79 Table of Contents 81 4.1. Graceful Shutdown of TE link(s).................................4 82 4.2. Graceful Shutdown of Component Link(s) in a Bundled TE Link.....5 83 4.3. Graceful Shutdown of TE Node....................................5 84 4.4. Grace Period and Removal of Resource............................5 85 5.1. Graceful Shutdown of TE link(s).................................5 86 5.2. Graceful Shutdown of Component Link(s) in a Bundled TE Link.....6 88 Z. Ali, et al. Page 2 6/14/2004 90 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 92 5.3. Graceful Shutdown of TE Node....................................6 93 9.1. Normative Reference.............................................7 94 9.2. Informative Reference...........................................8 96 1. Terminology 98 LSR - Label Switch Router 100 LSP - An MPLS Label Switched Path 102 Inter-AS MPLS TE LSP: TE LSP whose Head-end LSR and Tail-end LSR do not 103 reside within the same Autonomous System (AS) or both Head-end LSR and 104 Tail-end LSR are in the same AS but the TE tunnel transiting path may 105 be across different ASes. 107 Inter-Area MPLS TE LSP: TE LSP whose Head-end LSR and Tail-end LSR do 108 not reside within the same IGP area/ level or both Head-end LSR and 109 Tail-end LSR are in the same area/ level but the TE tunnel transiting 110 path may be across different areas/ levels. 112 PCE: Path Computation Element whose function is to compute the path of a 113 TE LSP it is not the head-end for. The PCE may be an LSR (e.g ABR or 114 ASBR) in the context of some distributed PCE-based path computation 115 scenario as defined in [INTER-AREA-AS] or a centralized Path Computation 116 Element not forwarding packet. 118 2. Introduction 120 Some of the outages in a network are planned, in which case protocols 121 extensions can be used so as to avoid traffic disruption by contrast 122 with unplanned network element failure, where traffic disruption can be 123 reduced but may not avoided. Hence, a Service Provider may desire to 124 gracefully (temporarily or definitely) remove a TE Link, a group of TE 125 Links or an entire node for administrative reasons such as link 126 maintenance or LSR software/hardware upgrade. In all these cases, the 127 goal is to minimize impact on the MPLS traffic engineered flows in the 128 network. 130 In an MPLS Traffic Engineering (TE) enabled network, there are 131 currently no defined mechanisms to allow for graceful shutdown of 132 network resources (TE links or TE nodes). In this document, we describe 133 graceful shutdown mechanisms for MPLS Traffic Engineering network. 134 Specifically, this document proposes signaling and routing extensions 135 to alert the head-end LSR of the graceful shutdown events. 137 Graceful shutdown mechanisms allow for the rerouting of the affected TE 138 LSPs in a non disruptive fashion using the so-called make-before-break 139 technique. Furthermore, such mechanisms also prevent other network 141 Z. Ali, et al. Page 3 6/14/2004 143 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 145 nodes to use network resources which are about to be shutdown, should 146 new TE LSP be set up. 148 3. Applicability of IGP and RSVP-TE Mechanisms 150 An IGP based solution is not applicable when dealing with Inter-area 151 and Inter-AS traffic engineering, as LSA or LSP flooding is restricted 152 to IGP areas/levels. Consequently, RSVP based mechanisms are required 153 to cope with TE LSPs spanning multiple domains, where a domain is 154 defined as either an IGP area or an Autonomous System. 156 Nonetheless, RSVP mechanisms only convey the information for the 157 transiting LSPs to the router along the upstream Path and not to all 158 nodes in the network. Indication of graceful shutdown via IGP flooding 159 is required to discourage a node from establishing new LSPs through the 160 resources being shut-down. 162 The following sections specify OSPF/ISIS flooding and RSVP-TE signaling 163 procedures for graceful removal of resources. 165 4. OSPF/ ISIS Mechanisms for graceful shutdown 167 The procedures provided in this section are equally applicable to OSPF 168 and ISIS. 170 4.1. Graceful Shutdown of TE link(s) 172 The link-attribute sub-TLV defined in [OSPF-LINK-ATTRI] and [ISIS-LINK- 173 ATTRI] has been extended to allow a Service Provider to take a TE Link 174 or a group of TE Links out of service for administrative reasons. 175 Specifically, the node where graceful-shutdown of a link is desired 176 MUST originate the TE LSA/LSP containing link-attribute sub-TLV with 177 �local maintenance required� bit set (see OSPF-LINK-ATTRI] and [ISIS- 178 LINK-ATTRI] for encoding details). 180 Extension to link attribute sub-TLV is preferred over use of MAX-METRIC 181 based solution, as links with MAX-METRIC bandwidth can be used as last 182 resort links in path computation. Nonetheless, to deal with LSRs not 183 compliant with this document, the node initiating graceful shutdown MAY 184 also originate the TE LSA/LSP containing Link TLV with 0 unreserved 185 bandwidth, Traffic Engineering metric set to 0xffffffff, and if the 186 Link has LSC or FSC as its Switching Capability then also with 0 as Max 187 LSP Bandwidth. 189 Neighbors of the node under graceful shutdown procedure (either at the 190 link, or a group of links) SHOULD continue advertise the actual 191 unreserved bandwidth on the TE links from the neighbors to that node, 192 without any routing adjacency change. 194 Z. Ali, et al. Page 4 6/14/2004 196 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 198 The motivation behind procedure outlined in this section is to 199 discourage new LSP establishment through the resource being shutdown. 200 Hence, nodes receiving link-attribute sub-TLV with graceful shutdown 201 indication SHOULD mark the link as unusable for further path 202 computation in both directions. 204 4.2. Graceful Shutdown of Component Link(s) in a Bundled TE Link 206 If graceful shutdown procedure is performed for a component link within 207 a TE Link bundle and it is not the last component link available within 208 the TE link, the link attributes associated with the TE link are 209 recomputed. If the removal of the component link results in a 210 significant change event, the TE link is re-flooded with the new 211 traffic parameters. If the last component link is being shut-down, the 212 routing procedure outlined in Section 4.1 is used. 214 4.3. Graceful Shutdown of TE Node 216 In the event of Graceful Shutdown of the entire node, procedure 217 outlined in Section 4.1 is applied to all the links advertised by the 218 node under shutdown. Neighbors of the node under graceful shutdown 219 procedure SHOULD continue advertise the actual unreserved bandwidth on 220 the TE links from the neighbors to that node, without any routing 221 adjacency change. 223 4.4. Grace Period and Removal of Resource 225 The node initiating the graceful shutdown condition SHOULD delay the 226 removal of resources in question for some period determined by local 227 policy. This is to allow other LSRs in the network to gracefully 228 reroute their TE LSP away from the resources being removed. 230 5. RSVP-TE Signaling Mechanism for graceful shutdown 232 5.1. Graceful Shutdown of TE link(s) 234 The �local TE link maintenance required� error code as defined in 235 [PATH-REOPT] is used to explicitly signal graceful shutdown of a link 236 to the head-end LSR for triggering the reroute of an affected TE LSP. 237 Specifically, the node where graceful-shutdown of a link or a set of 238 links is desired MUST trigger a Path Error message with �local link 239 maintenance required� sub-code for all affected LSPs. However, when a 240 GS operation is performed along the path of a protected LSP, the PLR 241 MAY trigger Fast Reroute [FRR] for the appropriate set of affected TE 242 LSPs and forward a Path Error with �Tunnel locally repaired� sub-code, 243 as per the procedures specified in [MPLS-FRR]. 245 When a head-end node or an intermediate node (in the case of loose hops 246 path computation) or a PCE receives Path Error notify message with sub- 247 code "Local Maintenance on TE Link required Flag", it SHOULD 249 Z. Ali, et al. Page 5 6/14/2004 251 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 253 immediately perform a make-before-break to avoid traffic loss. A head- 254 end router or an intermediate node (in the case of loose hops path 255 computation) or a PCE SHOULD avoid the IP address contained in the 256 PathErr in performing path computation for rerouting the LSP. 258 5.2. Graceful Shutdown of Component Link(s) in a Bundled TE Link 260 MPLS TE Link Bundling draft [BUNDLE] requires that an LSP is pinned 261 down to component link(s). Hence, when a component link is shut-down, 262 the LSPs affected by such maintenance action needs to be re-signaled. 264 Graceful shutdown of a component link in a bundled TE link differs from 265 graceful shutdown of unbundled TE link or entire bundled TE link. 266 Specifically, in the former case, when only a subset of component links 267 and not the entire TE bundled link is being shutdown, the remaining 268 component links of the TE links may still be able to admit new LSPs. 269 Consequently a new error sub-code for Path Error - Notify Error is 270 needed: 272 9 (TBA) Local component link maintenance required 274 Error Sub-code for �Local component link maintenance required� is to be 275 assigned by IANA. 277 If the last component link is being shut-down, the procedure outlined 278 in Section 5.1 is used. 280 When a head-end node or an intermediate node (in the case of loose hops 281 path computation) or a PCE receives an RSVP Path Error notification 282 with sub-code "local component link maintenance required� Flag set, it 283 SHOULD immediately perform a make-before-break to avoid traffic loss. 284 The head-end router or an intermediate node (in the case of loose hops 285 path computation) or a PCE MAY NOT avoid the IP address contained in 286 the PathErr in performing path computation for rerouting the LSP. This 287 is because, as mentioned earlier, this address is an IP address of the 288 component link and the flag is an implicit indication that the TE link 289 may still have capacity to admit new LSPs. However, if the ERO is to be 290 computed such that it also provides details of the component link 291 selection(s) along the Path, the component link selection with IP 292 address contained in the PathErr SHOULD be avoided. 294 As in the case of singling for bundled TE link, the choice of the 295 component link to use is always made by the sender of the Path/REQUEST 296 message, a node receiving the Path Err with "Maintenance on component 297 link required� Flag set SHOULD mark the component link blocked for any 298 future selection. 300 5.3. Graceful Shutdown of TE Node 302 Z. Ali, et al. Page 6 6/14/2004 304 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 306 When graceful shutdown at node level is desired, the node in question 307 follows procedure specified in this section for all LSPs. 309 6. Security Considerations 311 This document does not introduce new security issues. The security 312 considerations pertaining to the original RSVP protocol [RSVP] remain 313 relevant. 315 7. Intellectual Property Considerations 317 Cisco Systems may have intellectual property rights claimed in regard 318 to some of the specification contained in this document 320 8. Acknowledgments 322 The authors would like to acknowledge useful comments from their 323 colleagues David Ward and Sami Boutros. 325 9. Reference 327 9.1. Normative Reference 329 [RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version 330 1, Functional Specification", RFC 2205, September 1997. 332 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 333 3209, December 2001. 335 [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS) Signaling 336 Functional Description, RFC 3471, L. Berger, et al, January 2003. 338 [RFC3473] L. Berger, et al, "Generalized Multi-Protocol Label Switching 339 (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering 340 (RSVP-TE) Extensions", RFC 3473. 342 [OSPF-GMPLS] K. Kompella, Y. Rekhter, et al, �OSPF Extensions in 343 Support of Generalized MPLS�, draft-ietf-ccamp-ospf-gmpls-extensions- 344 12.txt. 346 [ISIS-GMPLS] K. Kompella, Y. Rekhter, et al, �IS-IS Extensions in 347 Support of Generalized MPLS�, draft-ietf-isis-gmpls-extensions-19.txt. 349 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 350 Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic-10.txt. 352 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", 353 draft-ietf-isis-traffic-04.txt (work in progress). 355 Z. Ali, et al. Page 7 6/14/2004 357 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 359 [MPLS-FRR] Ping Pan, George Swallow, Alia Atlas, et al �Fast Reroute 360 Extensions to RSVP-TE for LSP Tunnels�, draft-ietf-mpls-rsvp-lsp- 361 fastreroute-05.txt. 363 [OSPF-CAP] Jean-Philippe Vasseur, P. Psenak, and S. Yasukawa, �OSPF 364 MPLS Traffic Engineering capabilities� draft-vasseur-ccamp-ospf-te- 365 caps-00.txt. 367 [ISIS-CAP] Jean-Philippe Vasseur, S. Previdi, J. Mabey, and Jean-Louis 368 Le Roux, �IS-IS MPLS Traffic Engineering capabilities�, draft-vasseur- 369 ccamp-isis-te-caps-00.txt. 371 [OSPF-LINK-ATTRI] work in progress. 373 [ISIS-LINK_ATTRI] Jean-Philippe Vasseur, S. Previdi, �Definition of an 374 IS-IS Link Attribute sub-TLV�, draft-vasseur-isis-link-attr-00.txt. 376 [PATH-REOPT] Jean-Philippe Vasseur, and Y. Ikejiri, �Reoptimization of 377 MPLS Traffic Engineering loosely routed LSP paths�, draft-vasseur- 378 ccamp-loose-path-reopt-01.txt. 380 9.2. Informative Reference 382 [INTER-AREA-AS] Adrian Farrel, Jean-Philippe Vasseur, Arthi Ayyangar, 383 �A Framework for Inter-Domain MPLS Traffic Engineering�, draft-farrel- 384 ccamp-inter-domain-framework-00.txt. 386 [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 387 MPLS Traffic Engineering", draft-ietf-mpls-bunle-04.txt (work in 388 progress) 390 Authors' Address: 392 Zafar Ali 393 Cisco Systems, Inc. 394 100 South Main St. #200 395 Ann Arbor, MI 48104 396 USA 397 zali@cisco.com 399 Jean Philippe Vasseur 400 Cisco Systems, Inc. 401 300 Beaver Brook Road 402 Boxborough , MA - 01719 403 USA 404 Email: jpv@cisco.com 406 Anca Zamfir 407 Cisco Systems, Inc. 408 2000 Innovation Drive 410 Z. Ali, et al. Page 8 6/14/2004 412 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 414 Kanata, Ontario, K2K 3E8 415 Canada 416 ancaz@cisco.com 418 Z. Ali, et al. Page 9 6/14/2004