idnits 2.17.1 draft-ali-ccamp-mpls-graceful-shutdown-01.txt: 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 3667, Section 5.1 on line 40. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 421. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 389), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 341 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 (February 2005) is 7008 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: 'RFC 3209' is mentioned on line 84, but not defined == Missing Reference: 'RFC 3473' is mentioned on line 84, but not defined == Missing Reference: 'FRR' is mentioned on line 311, but not defined == Missing Reference: 'ISIS-LINK-ATTRI' is mentioned on line 248, but not defined == Unused Reference: 'RSVP-TE' is defined on line 438, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'OSPF-GMPLS' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'ISIS-GMPLS' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'OSPF-TE' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'OSPF-CAP' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'ISIS-CAP' is defined on line 469, 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') == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-05 -- 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: 12 errors (**), 0 flaws (~~), 19 warnings (==), 11 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: August, 2005 11 February 2005 13 draft-ali-ccamp-mpls-graceful-shutdown-01.txt 15 Graceful Shutdown in MPLS Traffic Engineering Networks 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC2026. Internet-Drafts are 21 Working documents of the Internet Engineering Task Force (IETF), its 22 areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 IPR Disclosure Acknowledgement 37 By submitting this Internet-Draft, I certify that any applicable 38 patent or other IPR claims of which I am aware have been disclosed, 39 and any of which I become aware will be disclosed, in accordance with 40 RFC 3668. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). All Rights Reserved. 46 Z. Ali, et al. Page 1 2/20/2005 48 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 50 Abstract 52 Graceful shutdown is a method for explicitly notifying a set of nodes 53 that either a Link or an entire node will remove itself from the 54 network or the protocol is going to be disabled for a link or a node. 55 Graceful shut down mechanisms are tailored towards addressing the 56 planned outage in the network. 58 This document provides requirements and protocol mechanisms so as to 59 reduce/eliminate traffic disruption in the event of a planned shutdown 60 of a network resource. 62 Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC-2119 [i]. 68 Routing Area ID Summary 70 (This section to be removed before publication.) 72 SUMMARY 74 This document describes graceful shutdown mechanisms used in MPLS 75 Traffic Engineering network. 77 WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK? 79 This work requires protocol extension to signaling (RSVP-TE) and 80 routing (OSPF/ ISIS) protocols being defined under IETF Routing Area. 82 WHY IS IT TARGETED AT THIS WG? 84 This work fits in the context of [RFC 3209], [RFC 3473] and 85 extensions to these RFCs being defined in CCAMP. 87 RELATED REFERENCES 89 See the reference section. 91 Table of Contents 93 1. Terminology........................................................3 94 2. Introduction.......................................................3 95 3. Requirements for Graceful Shutdown Mechanisms......................4 96 4. OSPF/ ISIS Mechanisms for graceful shutdown........................5 97 4.1 Graceful Shutdown of TE link(s).................................5 98 4.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link.....6 99 4.3 Graceful Shutdown of TE Node....................................6 101 Z. Ali, et al. Page 2 2/20/2005 103 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 105 4.4 Grace Period and Removal of Resource............................6 106 5. RSVP-TE Signaling Mechanism for graceful shutdown..................6 107 5.1 Graceful Shutdown of TE link(s).................................6 108 5.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link.....7 109 5.3 Graceful Shutdown of TE Node....................................7 110 6. Security Considerations............................................8 111 7. IANA Considerations................................................8 112 8. Full Copyright Statement...........................................8 113 9. Intellectual Property..............................................8 114 10. Acknowledgments...................................................8 115 11. Reference.........................................................9 116 11.1 Normative Reference............................................9 117 11.2 Informative Reference.........................................10 119 1. Terminology 121 Node - Label Switching Device. 123 LSP - An MPLS Label Switched Path 125 Inter-AS MPLS TE LSP: TE LSP whose Head-end node and Tail-end node do 126 not reside within the same Autonomous System (AS) or both Head-end node 127 and Tail-end node are in the same AS but the TE tunnel transiting path 128 may be across different ASes. 130 Inter-Area MPLS TE LSP: TE LSP whose Head-end node and Tail-end node do 131 not reside within the same IGP area/ level or both Head-end node and 132 Tail-end node are in the same area/ level but the TE tunnel transiting 133 path may be across different areas/ levels. 135 Head-end node: In the draft term head-end node equally applies to the 136 Ingress node that initiated signaling for the Path, or an intermediate 137 node (in the case of loose hops path computation) or a Path Computation 138 Element (PCS) that computes the routes on behave of its clients (PCC). 139 Specification of PCE-PCC communication is beyond the scope of this 140 document. However, the document lists set of roles that any entity 141 computing a path should follow, i.e., Ingress node, intermediate nodes 142 performing ERO extensions or PCE. 144 2. Introduction 146 Some of the outages in a network are planned, in which case protocols 147 extensions can be used so as to avoid traffic disruption by contrast 148 with unplanned network element failure, where traffic disruption can be 149 reduced but may not avoided. Hence, a Service Provider may desire to 150 gracefully (temporarily or definitely) remove a TE Link, a group of TE 151 Links or an entire node for administrative reasons such as link 152 maintenance or software/hardware upgrade at a node. In all these cases, 154 Z. Ali, et al. Page 3 2/20/2005 156 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 158 the goal is to minimize impact on the MPLS traffic engineered flows in 159 the network. 161 In an MPLS Traffic Engineering (TE) enabled network, there are 162 currently no defined mechanisms to allow for graceful shutdown of 163 network resources (TE links or TE nodes). In this document, we describe 164 graceful shutdown mechanisms for MPLS Traffic Engineering network. 165 Specifically, this document proposes signaling and routing extensions 166 to alert the head-end node of the graceful shutdown events. 168 3. Requirements for Graceful Shutdown Mechanisms 170 This section lists the requirements for graceful shutdown mechanisms. 172 - Graceful shutdown mechanisms are applicable to removal a TE 173 resource (e.g., link, a group of TE Links or an entire node). Trigger 174 for the graceful shutdown event is a local matter at the node 175 initiating the graceful shutdown. Typically graceful shutdown is 176 triggered for administrative reasons, such as link maintenance or 177 software/hardware upgrade at a node. 179 - Graceful shutdown mechanisms are required to address graceful 180 removal of a TE link (bundled or unbundled), a component link within 181 a bundled TE link, a set of TE links, a set of component links or an 182 entire node. 184 - Graceful shutdown is equally applicable to MPLS, as well as GMPLS 185 LSPs. 187 - It is required to prevent other network nodes to use network 188 resources which are about to be shutdown, should new TE LSP be set 189 up. As RSVP mechanisms only convey the information for the transiting 190 LSPs to the router along the upstream Path and not to all nodes in 191 the network, indication of graceful shutdown via IGP flooding is 192 required to discourage a node from establishing new LSPs through the 193 resources being shut-down. 195 - Graceful shutdown mechanisms are required to address TE LSPs 196 spanning multiple domains, as well as intra domain TE LSPs. Here, a 197 domain is defined as either an IGP area or an Autonomous System 198 [INTER-AREA-AS]. An IGP based solution is not applicable when dealing 199 with Inter-area and Inter-AS traffic engineering, as LSA or LSP 200 flooding is restricted to IGP areas/levels. Consequently, RSVP based 201 mechanisms are required to cope with TE LSPs spanning multiple 202 domains. 204 - Graceful shutdown mechanisms are required to reduce/eliminate 205 traffic disruption by rerouting of the TE LSPs using the resource 206 under graceful shutdown, in a non disruptive fashion. It is required 207 to rely on existing mechanisms like make-before-break and protection 209 Z. Ali, et al. Page 4 2/20/2005 211 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 213 (FRR, path/ segment protection); selection of actual mechanism is a 214 local matter at the node handling graceful shutdown event. 216 - It is required to co-ordinate graceful shutdown with the protection 217 available for the TE link or the affected LSP, e.g., in packet 218 switching capable nodes, when a graceful shutdown operation is 219 performed along the path of a protected LSP, the PLR MAY trigger Fast 220 Reroute [FRR] for the appropriate set of affected TE LSPs. Similarly, 221 when unbundled TE link is protected and maintenance of components 222 within the protected TE link is possible using means other than 223 graceful shutdown mechanisms (e.g., by L2), graceful shutdown may be 224 handled by a local switchover without informing the network of 225 graceful shutdown condition. 227 - In case of bundled TE links, RSVP flows are pinned to a component 228 link, removal of the component link does affect the LSP using it. 229 Hence, mechanisms to gracefully shutdown a component link(s) within a 230 bundled TE link is/ are required. 232 - In order to make rerouting effective, it is required to carry 233 information about the resource under graceful shutdown in the 234 signaling message. 236 4. OSPF/ ISIS Mechanisms for graceful shutdown 238 The procedures provided in this section are equally applicable to OSPF 239 and ISIS. 241 4.1 Graceful Shutdown of TE link(s) 243 The link-attribute sub-TLV defined in [OSPF-LINK-ATTRI] and [ISIS-LINK- 244 ATTRI] has been extended to allow a Service Provider to take a TE Link 245 or a group of TE Links out of service for administrative reasons. 246 Specifically, the node where graceful-shutdown of a link is desired 247 MUST originate the TE LSA/LSP containing link-attribute sub-TLV with 248 "local maintenance required" bit set (see OSPF-LINK-ATTRI] and [ISIS- 249 LINK-ATTRI] for encoding details). 251 Extension to link attribute sub-TLV is preferred over use of MAX-METRIC 252 based solution, as links with MAX-METRIC bandwidth can be used as last 253 resort links in path computation. Nonetheless, to deal with nodes not 254 compliant with this document, the node initiating graceful shutdown MAY 255 also originate the TE LSA/LSP containing Link TLV with 0 unreserved 256 bandwidth, Traffic Engineering metric set to 0xffffffff, and if the 257 Link is non-PSC then also with 0 as Max LSP Bandwidth. 259 Neighbors of the node under graceful shutdown procedure (either at the 260 link, or a group of links) SHOULD continue advertise the actual 261 unreserved bandwidth on the TE links from the neighbors to that node, 262 without any routing adjacency change. 264 Z. Ali, et al. Page 5 2/20/2005 266 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 268 The motivation behind procedure outlined in this section is to 269 discourage new LSP establishment through the resource being shutdown. 270 Hence, nodes receiving link-attribute sub-TLV with graceful shutdown 271 indication SHOULD mark the link as unusable for further path 272 computation in both directions. 274 4.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 276 If graceful shutdown procedure is performed for a component link within 277 a TE Link bundle and it is not the last component link available within 278 the TE link, the link attributes associated with the TE link are 279 recomputed. If the removal of the component link results in a 280 significant change event, the TE link is re-flooded with the new 281 traffic parameters. If the last component link is being shut-down, the 282 routing procedure outlined in Section 4.1 is used. 284 4.3 Graceful Shutdown of TE Node 286 In the event of Graceful Shutdown of the entire node, the node removes 287 the Router Address TLV from the TE advertisement. Neighbors of the node 288 under graceful shutdown procedure SHOULD continue advertise the actual 289 unreserved bandwidth on the TE links from the neighbors to that node, 290 without any routing adjacency change. 292 4.4 Grace Period and Removal of Resource 294 The node initiating the graceful shutdown condition SHOULD delay the 295 removal of resources in question for some period determined by local 296 policy. This is to allow other nodes in the network to gracefully 297 reroute their TE LSP away from the resources being removed. 299 5. RSVP-TE Signaling Mechanism for graceful shutdown 301 5.1 Graceful Shutdown of TE link(s) 303 The "local TE link maintenance required" error code as defined in 304 [PATH-REOPT] is used to explicitly signal graceful shutdown of a link 305 to the head-end node for triggering the reroute of an affected TE LSP. 306 Specifically, the node where graceful-shutdown of a link or a set of 307 links is desired MUST trigger a Path Error message with "local link 308 maintenance required" sub-code for all affected LSPs. However, in 309 packet switching capable network, when a graceful shutdown operation is 310 performed along the path of a protected LSP, the PLR MAY trigger Fast 311 Reroute [FRR] for the appropriate set of affected TE LSPs and forward a 312 Path Error with "Tunnel locally repaired" sub-code, as per the 313 procedures specified in [MPLS-FRR]. 315 When a head-end node receives Path Error notify message with sub-code 316 "Local Maintenance on TE Link required Flag", it SHOULD immediately 317 Z. Ali, et al. Page 6 2/20/2005 319 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 321 immediately perform switchover to avoid traffic loss. In either case, a 322 head-end node SHOULD avoid the IP address contained in the PathErr in 323 performing path computation for rerouting the LSP. 325 5.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 327 MPLS TE Link Bundling draft [BUNDLE] requires that an LSP is pinned 328 down to component link(s). Hence, when a component link is shut-down, 329 the LSPs affected by such maintenance action needs to be re-signaled. 331 Graceful shutdown of a component link in a bundled TE link differs from 332 graceful shutdown of unbundled TE link or entire bundled TE link. 333 Specifically, in the former case, when only a subset of component links 334 and not the entire TE bundled link is being shutdown, the remaining 335 component links of the TE links may still be able to admit new LSPs. 336 Consequently a new error sub-code for Path Error - Notify Error is 337 needed: 339 9 (TBA) Local component link maintenance required 341 Error Sub-code for "Local component link maintenance required" is to be 342 assigned by IANA. 344 If the last component link is being shut-down, the procedure outlined 345 in Section 5.1 is used. 347 When a head-end node receives an RSVP Path Error notification with sub- 348 code "local component link maintenance required" Flag set, it SHOULD 349 immediately perform a make-before-break to avoid traffic loss. The 350 head-end node MAY still use the IP address contained in the PathErr in 351 performing path computation for rerouting the LSP. This is because, as 352 mentioned earlier, this address is an IP address of the component link 353 and the flag is an implicit indication that the TE link may still have 354 capacity to admit new LSPs. However, if the ERO is to be computed such 355 that it also provides details of the component link selection(s) along 356 the Path, the component link selection with IP address contained in the 357 PathErr SHOULD be avoided. 359 As in the case of singling for bundled TE link, the choice of the 360 component link to use is always made by the sender of the Path/REQUEST 361 message, a node receiving the Path Err with "Maintenance on component 362 link required" Flag set SHOULD mark the component link blocked for any 363 future selection. 365 5.3 Graceful Shutdown of TE Node 367 When graceful shutdown at node level is desired, the node in question 368 follows procedure specified in this section for all LSPs. 370 Z. Ali, et al. Page 7 2/20/2005 372 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 374 6. Security Considerations 376 This document does not introduce new security issues. The security 377 considerations pertaining to the original RSVP protocol [RSVP] remain 378 relevant. 380 7. IANA Considerations 382 A new error sub-code for Path Error - Notify Error is needed for 383 "Local component link maintenance required" flag. 385 8. Full Copyright Statement 387 Copyright (C) The Internet Society (2004). This document is subject to 388 the rights, licenses and restrictions contained in BCP 78 and except as 389 set forth therein, the authors retain all their rights. 391 This document and the information contained herein are provided on an 392 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 393 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 394 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 395 IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 396 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 397 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 399 9. Intellectual Property 401 The IETF takes no position regarding the validity or scope of any 402 Intellectual Property Rights or other rights that might be claimed to 403 pertain to the implementation or use of the technology described in this 404 document or the extent to which any license under such rights might or 405 might not be available; nor does it represent that it has made any 406 independent effort to identify any such rights. Information on the 407 procedures with respect to rights in RFC documents can be found in BCP 408 78 and BCP 79. 410 Copies of IPR disclosures made to the IETF Secretariat and any 411 assurances of licenses to be made available, or the result of an attempt 412 made to obtain a general license or permission for the use of such 413 proprietary rights by implementers or users of this specification can be 414 obtained from the IETF on-line IPR repository at 415 http://www.ietf.org/ipr. 417 The IETF invites any interested party to bring to its attention any 418 copyrights, patents or patent applications, or other proprietary rights 419 that may cover technology that may be required to implement this 420 standard. Please address the information to the IETF at ietf- 421 ipr@ietf.org. 423 10. Acknowledgments 425 Z. Ali, et al. Page 8 2/20/2005 427 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 429 The authors would like to acknowledge useful comments from David Ward, 430 Sami Boutros and Adrian Farrel. 432 11. Reference 434 11.1 Normative Reference 435 [RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version 436 1, Functional Specification", RFC 2205, September 1997. 438 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 439 3209, December 2001. 441 [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS) Signaling 442 Functional Description, RFC 3471, L. Berger, et al, January 2003. 444 [RFC3473] L. Berger, et al, "Generalized Multi-Protocol Label Switching 445 (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering 446 (RSVP-TE) Extensions", RFC 3473. 448 [OSPF-GMPLS] K. Kompella, Y. Rekhter, et al, "OSPF Extensions in 449 Support of Generalized MPLS", draft-ietf-ccamp-ospf-gmpls-extensions- 450 12.txt. 452 [ISIS-GMPLS] K. Kompella, Y. Rekhter, et al, "IS-IS Extensions in 453 Support of Generalized MPLS", draft-ietf-isis-gmpls-extensions-19.txt. 455 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 456 Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic-10.txt. 458 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", 459 draft-ietf-isis-traffic-04.txt (work in progress). 461 [MPLS-FRR] Ping Pan, George Swallow, Alia Atlas, et al "Fast Reroute 462 Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp- 463 fastreroute-05.txt. 465 [OSPF-CAP] Jean-Philippe Vasseur, P. Psenak, and S. Yasukawa, "OSPF 466 MPLS Traffic Engineering capabilities" draft-vasseur-ccamp-ospf-te- 467 caps-00.txt. 469 [ISIS-CAP] Jean-Philippe Vasseur, S. Previdi, J. Mabey, and Jean-Louis 470 Le Roux, "IS-IS MPLS Traffic Engineering capabilities", draft-vasseur- 471 ccamp-isis-te-caps-00.txt. 473 [OSPF-LINK-ATTRI] work in progress. 475 [ISIS-LINK_ATTRI] Jean-Philippe Vasseur, S. Previdi, "Definition of an 476 IS-IS Link Attribute sub-TLV", draft-vasseur-isis-link-attr-00.txt. 478 Z. Ali, et al. Page 9 2/20/2005 480 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 482 [PATH-REOPT] Jean-Philippe Vasseur, and Y. Ikejiri, "Reoptimization of 483 MPLS Traffic Engineering loosely routed LSP paths", draft-vasseur- 484 ccamp-loose-path-reopt-01.txt. 486 11.2 Informative Reference 488 [INTER-AREA-AS] Adrian Farrel, Jean-Philippe Vasseur, Arthi Ayyangar, 489 "A Framework for Inter-Domain MPLS Traffic Engineering", draft-farrel- 490 ccamp-inter-domain-framework-00.txt. 492 [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 493 MPLS Traffic Engineering", draft-ietf-mpls-bunle-04.txt (work in 494 progress) 496 Authors' Address: 498 Zafar Ali 499 Cisco systems, Inc., 500 2000 Innovation Drive 501 Kanata, Ontario, K2K 3E8 Email: zali@cisco.com 502 Canada. 503 Email: zali@cisco.com 505 Jean Philippe Vasseur 506 Cisco Systems, Inc. 507 300 Beaver Brook Road 508 Boxborough , MA - 01719 509 USA 510 Email: jpv@cisco.com 512 Anca Zamfir 513 Cisco Systems, Inc. 514 2000 Innovation Drive 515 Kanata, Ontario, K2K 3E8 516 Canada 517 Email: ancaz@cisco.com 519 Z. Ali, et al. Page 10 2/20/2005