idnits 2.17.1 draft-ietf-mpls-gmpls-lsp-reroute-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3209, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3209, updated by this document, for RFC5378 checks: 1998-11-20) -- 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 (September 23, 2009) is 5328 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-13) exists of draft-ietf-ccamp-mpls-graceful-shutdown-10 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-3209-patherr-05 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Updates: 3209 Dimitri Papadimitriou (Alcatel Lucent) 3 Category: Standards Track JP. Vasseur (Cisco) 4 Expiration Date: March 23, 2010 6 September 23, 2009 8 PathErr Message Triggered MPLS and GMPLS LSP Reroute 10 draft-ietf-mpls-gmpls-lsp-reroute-06.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on March 23, 2010. 40 Copyright and License Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 This document describes how Resource ReserVation Protocol (RSVP) 54 PathErr Messages may be used to trigger rerouting of Multi-Protocol 55 Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point 56 Traffic Engineering (TE) Label Switched Paths (LSPs) without first 57 removing LSP state or resources. Such LSP rerouting may be desirable 58 in a number of cases including, for example, soft-preemption and 59 graceful shutdown. This document describes the usage of existing 60 Standards Track mechanisms to support LSP rerouting. In this case, it 61 relies on mechanisms already defined as part of RSVP-TE and simply 62 describes a sequence of actions to be executed. While existing 63 protocol definition can be used to support reroute applications, this 64 document also defines a new reroute-specific error code to allow for 65 the future definition of reroute application-specific error values. 67 Table of Contents 69 1 Introduction ........................................... 3 70 1.1 Conventions used in this document ...................... 4 71 2 Reroute Requests ....................................... 4 72 2.1 Processing at Requesting Node .......................... 4 73 2.1.1 Reroute Request Timeouts ............................... 5 74 2.2 Processing at Upstream Node ............................ 6 75 2.3 Processing at Ingress .................................. 6 76 3 Example Reroute Requests ............................... 7 77 3.1 Node Reroute Request ................................... 7 78 3.2 Interface Reroute Request .............................. 7 79 3.3 Component Reroute Request .............................. 8 80 3.4 Label Reroute Request .................................. 9 81 4 IANA Considerations .................................... 9 82 5 Security Considerations ................................ 10 83 6 References ............................................. 10 84 6.1 Normative References ................................... 10 85 6.2 Informative References ................................. 11 86 7 Acknowledgments ........................................ 12 87 8 Authors' Addresses ..................................... 12 89 1. Introduction 91 Resource ReserVation Protocol (RSVP), see [RFC2205], has been 92 extended to support the control of Traffic Engineering (TE) Label 93 Switched Paths (LSPs) for both Multi-Protocol Label Switching (MPLS) 94 and Generalized MPLS (GMPLS) in, respectively, [RFC3209] and 95 [RFC3473]. In all cases, a PathErr message is used to report errors 96 to nodes upstream of the error detecting node. As defined in 97 [RFC2205], and left unmodified by [RFC3209], PathErr messages "do not 98 change path state in the nodes through which they pass". 99 Notwithstanding this definition, PathErr messages are most commonly 100 used to report errors during LSP establishment, i.e., the RSVP-TE 101 processing that occurs prior to the ingress receiving a Resv message. 102 (See [PATHERR] for a broader discussion on PathErr message handling.) 103 Support for such usage was enhanced via the introduction of the 104 Path_State_Removed flag in [RFC3473], which enables a processing node 105 to free related LSP state and resources. The usage of PathErr 106 messages during LSP establishment was further covered in [RFC4920] 107 which describes in detail how a node may indicate that the node or 108 one of its associated resources should be avoided, i.e., routed 109 around, during LSP establishment. 111 PathErr messages can also be used to support a number of other cases 112 that can occur after an LSP is established. This document focuses on 113 the cases where PathErr messages can be used for a node to indicate 114 that it desires an upstream node to reroute an LSP around the 115 indicating node or a resources associated with the indicating node. 116 Some examples of such cases are soft-preemption and graceful 117 shutdown. (See [PREEMPTION] and [GRACEFUL]). 119 This document uses the terminology "reroute request" to refer to the 120 indication by a node that an upstream reroute should take place. This 121 document describes how a node can initiate a reroute request without 122 disrupting LSP data traffic or, when so desired, with the disruption 123 of data traffic and removal of LSP associated state and resources. 124 The applicability of this document is limited to point-to-point LSPs. 125 Support for point-to-multipoint LSPs are for further study. 127 The mechanisms used to indicate reroute requests are derived from the 128 mechanisms described in [RFC4920], and the error codes defined in 129 [RFC4736]. This document describes (1) how a non-disruptive reroute 130 request may be issued and, (2) based on an optional "timeout" period, 131 how rerouting may be forced by removing LSP state and associated 132 resources and signaling such removal. While this document describes 133 how existing protocol definitions can be used to support rerouting, 134 it also defines a new reroute-specific error code to allow for the 135 future definition of reroute application-specific error values. 137 1.1. Conventions used in this document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 2. Reroute Requests 145 This section describes how a downstream node can indicate that it 146 desires a node upstream (along the LSP path) to initiate the 147 rerouting of an LSP, and how the upstream nodes can respond to such a 148 request. Initiating nodes, transit nodes, and ingress nodes are 149 described separately. 151 2.1. Processing at Requesting Node 153 When a transit or egress node desires to request the rerouting of an 154 established LSP, it first determines if it can act on the reroute 155 request locally. Such a check MUST be performed on the condition that 156 the Explicit Route Object (ERO), see [RFC3209], received in the LSP's 157 incoming Path message does not preclude LSP rerouting. Examples of 158 events that may trigger reroutes are avoiding an outgoing interface, 159 a component, label resource, or a next hop not explicitly listed in 160 the ERO. In all cases, the actual repair action SHOULD be performed 161 after verification that the local policy allows local repair for that 162 LSP/state. That is, any traffic rerouting action (associated to this 163 state) must be initiated and completed only as allowed by local node 164 policy. 166 When the node cannot act locally, it MUST issue a PathErr message 167 indicating its inability to perform local rerouting. The PathErr 168 message MUST contain an ERROR_SPEC object of the format defined in 169 [RFC2205] or [RFC3473]. Such a message MUST include one of the 170 following combinations of error codes and error values: 172 1. "Notify/Local node maintenance required" to support backwards 173 compatibility and to reroute around the local node. 175 2. "Notify/Local link maintenance required" to support backwards 176 compatibility and to reroute around a local interface. 178 3. "Reroute/" for future compatibility 179 and when backwards compatibility is not a concern. 181 The rest of the ERROR_SPEC object is constructed based on the local 182 rerouting decision and the resource that is to be avoided by an 183 upstream node. It is important to note that the address and TLVs 184 carried by the ERROR_SPEC object identify the resource to be avoided 185 and not the error code and value. 187 When the reroute decision redirects traffic around the local node, 188 the local node MUST be indicated in the ERROR_SPEC object. Otherwise, 189 i.e., when the reroute decision does not redirect traffic around the 190 local node, the impacted interface MUST be indicated in the 191 ERROR_SPEC object and the IF_ID [RFC3473] ERROR_SPEC object formats 192 SHOULD be used to indicate the impacted interface. 194 The IF_ID [RFC3473] ERROR_SPEC object format MUST be used to indicate 195 a reroute request that is more specific than an interface. The TLVs 196 defined in [RFC3471], as updated by [RFC3477] and [RFC4201], and 197 [RFC4920] MAY be used to provide specific additional reroute request 198 information, e.g., reroute around a specific label. The principles 199 related to ERROR_SPEC object construction defined in section 6.3.1. 200 of [RFC4920] SHOULD be followed. 202 2.1.1. Reroute Request Timeouts 204 Reroute request timeouts are used to remove an LSP when there is no 205 response to a reroute request. A reroute request timeout is used 206 when an LSP is to be removed at the expiration of the Reroute request 207 timeout period. When such LSP removal is desired and after 208 initiating a reroute request, the initiating node MUST initiate a 209 timeout during which it expects to receive a response to the reroute 210 request. Valid responses are a PathTear message or a trigger Path 211 message with an ERO avoiding the resource that was indicated in the 212 reroute request. If either type of message is received, the timeout 213 period MUST be canceled and no further action is needed. Note, 214 normal refresh processing is not modified by the introduction of 215 reroute request timeouts. Such processing may result in Path state 216 being removed during the timeout period, in which case the timeout 217 period MUST also be canceled. 219 If the reroute request timeout is reached, the initiating node MUST 220 remove the LSP and its associated state and resources. Removal of 221 LSP state is indicated downstream via a corresponding PathTear 222 message. Removal is indicated upstream via a PathErr message with 223 the error code of "Service preempted". The Path_State_Removed flag 224 MUST be set if supported. When the Path_State_Removed flag is not 225 supported, a corresponding ResvTear MUST also be sent. 227 2.2. Processing at Upstream Node 229 When a transit node's policy permits it to support reroute request 230 processing and local repair, the node MUST examine incoming PathErr 231 messages to see it the node can perform a requested reroute. A 232 reroute request is indicated in a received PathErr message which 233 carries one of the error code and value combinations listed above in 234 Section 2.1. Note that a conformant implementation MUST check for 235 any of the the three combinations listed in Section 2.1. 237 A transit node MAY act on a reroute request locally when the ERO 238 received in the LSP's incoming Path message does not preclude the 239 reroute. As before, examples include loosely routed LSP next hops. 240 When the reroute request can be processed locally, standard local 241 repair processing MUST be followed. The node SHOULD limit the number 242 of local repair attempts. Again, the expected norm is for local 243 repair and, thereby, this case to be precluded due to policy. 245 When the transit node supports [RFC4920], is a boundary node and 246 Boundary rerouting is allowed, it SHOULD use a route request as a 247 trigger to reroute the LSP. (Per [RFC4920], the Flags field of the 248 LSP_ATTRIBUTES object of the initial Path message indicate "Boundary 249 rerouting".) In the case the node triggers rerouting, it first MUST 250 identify an alternate path within the domain. When such a path is 251 available, the node MUST terminate the PathErr message and issue a 252 Path message reflecting the identified alternate path. Processing 253 then continues per [RFC4920]. When an alternate path is not 254 available, the node cannot act on the reroute request. 256 When a transit node node cannot act on a reroute request locally, per 257 standard processing, it MUST propagate the received PathErr message 258 to the previous hop. 260 2.3. Processing at Ingress 262 When reroute processing is supported, an ingress node MUST check 263 received PathErr messages to identify them as indicating reroute 264 requests. A reroute request is indicated in a received PathErr 265 message which carries one of the error code and value combinations 266 listed above in Section 2.1. Note that a conformant implementation 267 MUST check for any of the the three combinations listed in Section 268 2.1. 270 Upon receiving a reroute request, the ingress MUST attempt to 271 identify an alternate path, avoiding the node, interface, resource, 272 etc. identified within the ERROR_SPEC object. When an alternate path 273 cannot be identified the reroute request MUST be discarded. When an 274 alternate path is identified, a corresponding make-before-break LSP 275 SHOULD be initiated, and standard make-before-break procedures MUST 276 be followed. 278 3. Example Reroute Requests 280 This section provides example reroute requests. This section is 281 informative rather than prescriptive. Reroute requests are always 282 sent via PathErr messages. As described above, a PathErr message may 283 contain either an [RFC2205] format ERROR_SPEC object, or an IF_ID 284 [RFC3473] format ERROR_SPEC object and it is the address and TLVs 285 carried by the ERROR_SPEC object and not the error value that 286 indicates the resource that is to be avoided by the reroute. 288 3.1. Node Reroute Request 290 To indicate that the node should be avoided by an upstream node, the 291 node originating the reroute may format the ERROR_SPEC per [RFC2205], 292 for example: 294 o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1 296 +-------------+-------------+-------------+-------------+ 297 | IPv4 Error Node Address (4 bytes) | 298 +-------------+-------------+-------------+-------------+ 299 | Flags | Error Code | Error Value | 300 +-------------+-------------+-------------+-------------+ 302 The node address is set to the local node's TE router address. Error 303 code is set to either "Notify/Local node maintenance required" or 304 "Reroute/". 306 3.2. Interface Reroute Request 308 To indicate that a numbered interface should be avoided by an 309 upstream node, the node originating the reroute may format the 310 ERROR_SPEC per [RFC3473], for example: 312 0 1 2 3 313 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Length | Class-Num (6) | C-Type (3) | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | IPv4 Error Node Address | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Flags | Error Code | Error Value | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type (1) | Length (8) | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | IP Address | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 The node address is set to the local node's TE router address. Error 327 code is set to either "Notify/Local link maintenance required" or 328 "Reroute/". IP address is set to the TE 329 address of the interface to be avoided. 331 3.3. Component Reroute Request 333 To indicate that an unnumbered component should be avoided by an 334 upstream node, the node originating the reroute formats the 335 ERROR_SPEC per [RFC4201], for example: 337 0 1 2 3 338 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Length | Class-Num (6) | C-Type (3) | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | IPv4 Error Node Address | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Flags | Error Code | Error Value | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type (3) | Length (12) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Router ID | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Interface ID (32 bits) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 The node address is set to the local TE address used in the 354 advertisement of the bundle associated with the component. Error 355 code is set to either "Notify/Local link maintenance required" or 356 "Reroute/". Router ID is set to the local 357 router ID and Interface ID is the identifier assigned to the 358 component link by the local node. 360 3.4. Label Reroute Request 362 To indicate that a label should be avoided by an upstream node, the 363 node originating the reroute may format the ERROR_SPEC per [RFC4920], 364 for example: 366 0 1 2 3 367 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Length | Class-Num (6) | C-Type (3) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | IPv4 Error Node Address | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Flags | Error Code | Error Value | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type (1) | Length (8) | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | IP Address | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type (6) | Length (8) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | DOWNSTREAM_LABEL | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 The node address is set to the local node's TE router address. Error 385 code is set to either "Notify/Local link maintenance required" or 386 "Reroute/". IP address is set to the TE 387 address of the interface which supports the label to be avoided. 388 DOWNSTREAM_LABEL indicates the label to be avoided. 390 4. IANA Considerations 392 IANA is requested to administer assignment of new values for 393 namespaces defined in this document and reviewed in this section. 395 Upon approval of this document, the IANA will make the assignment in 396 the "Error Codes and Globally-Defined Error Value Sub-Codes" section 397 of the "RSVP Parameters" registry located at 398 http://www.iana.org/assignments/rsvp-parameters: 400 34* Reroute [This document] 402 This Error Code has the following defined Error Value sub-code: 404 0 = Generic LSP reroute request 406 Reroute error values should be allocated based on the following 407 allocation policy as defined in [RFC5226]. 409 Range Registration Procedures 410 -------- ------------------------ 411 0-32767 IETF Consensus 412 32768-65535 Private Use 414 (*) Suggested value. 416 5. Security Considerations 418 Section 9 of [RFC4920] and [RFC4736] should be used as the starting 419 point for reviewing the security considerations related to the 420 formats and mechanisms discussed in this document. This document 421 introduces a new error code, but this code is functionally equivalent 422 to existing semantics, in particular the error code/error value 423 combinations of "Notify/Local node maintenance required" and 424 "Notify/Local link maintenance required". As such, this document 425 introduces no new security considerations beyond what already applies 426 to these existing formats and mechanisms. Future documents may 427 define new error values. Any considerations specific to those values 428 should be discussed in the document defining a new value. 430 6. References 432 6.1. Normative References 434 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 435 "Resource ReSerVation Protocol (RSVP) -- Version 1, 436 Functional Specification", RFC 2205, September 1997. 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels," RFC 2119. 441 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 442 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 443 to RSVP for LSP Tunnels", RFC 3209, December 2001. 445 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 446 Switching (GMPLS) Signaling Functional Description", 447 RFC 3471, January 2003. 449 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 450 Switching (GMPLS) Signaling - Resource ReserVation 451 Protocol-Traffic Engineering (RSVP-TE) Extensions", 452 RFC 3473, January 2003. 454 [RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links 455 in Resource ReSerVation Protocol - Traffic Engineering 456 (RSVP-TE)", RFC 3477, January 2003. 458 [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 459 MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 461 [RFC4920] Farrel, A., Ed., "Crankback Signaling Extensions for 462 MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. 464 [RFC5226] Narten, T., Alvestrand, H., "Guidelines for Writing an 465 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 466 May 2008. 468 6.2. Informative References 470 [RFC4736] Vasseur, JP., et al, "Reoptimization of Multiprotocol 471 Label Switching (MPLS) Traffic Engineering (TE) Loosely 472 Routed Label Switched Path (LSP)", RFC 4736, November 473 2006. 475 [GRACEFUL] Ali, Z., et al., "Graceful Shutdown in MPLS and 476 Generalized MPLS Traffic Engineering Networks", 477 draft-ietf-ccamp-mpls-graceful-shutdown-10.txt, 478 Work in Progress, March 2009. 480 [PATHERR] Vasseur, JP., Ed. "Node behavior upon originating and 481 receiving Resource ReserVation Protocol (RSVP) Path 482 Error message", draft-ietf-mpls-3209-patherr-05.txt, 483 Work in Progress, July 2009. 485 [PREEMPTION] Meyer, M., Ed. "MPLS Traffic Engineering Soft 486 Preemption", draft-ietf-mpls-soft-preemption-18.txt, 487 Work in Progress, July 2009. 489 7. Acknowledgments 491 This document was conceived along with Matthew Meyer. George Swallow 492 provided valuable feedback. The General Area Review Team (Gen-ART) 493 review was performed by Francis Dupont. 495 8. Authors' Addresses 497 Lou Berger 498 LabN Consulting, L.L.C. 499 Phone: +1-301-468-9228 500 Email: lberger@labn.net 502 Dimitri Papadimitriou 503 Alcatel Lucent 504 Francis Wellesplein 1, 505 B-2018 Antwerpen, Belgium 506 Phone: +32 3 240-8491 507 Email: Dimitri.Papadimitriou@alcatel-lucent.be 509 JP Vasseur 510 Cisco Systems, Inc 511 11, Rue Camille Desmoulins 512 L'Atlantis 513 92782 Issy Les Moulineaux 514 France 515 Email: jpv@cisco.com 517 Generated on: Wed Sep 23 18:34:46 EDT 2009