doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc5710.txt b/doc/rfc/rfc5710.txt
new file mode 100644
index 0000000..b365553
--- /dev/null
+++ b/doc/rfc/rfc5710.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         L. Berger
+Request for Comments: 5710                                          LabN
+Category: Standards Track                               D. Papadimitriou
+ISSN: 2070-1721                                           Alcatel Lucent
+                                                             JP. Vasseur
+                                                                   Cisco
+                                                            January 2010
+
+
+         PathErr Message Triggered MPLS and GMPLS LSP Reroutes
+
+Abstract
+
+   This document describes how Resource ReserVation Protocol (RSVP)
+   PathErr messages may be used to trigger rerouting of Multi-Protocol
+   Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point
+   Traffic Engineering (TE) Label Switched Paths (LSPs) without first
+   removing LSP state or resources.  Such LSP rerouting may be desirable
+   in a number of cases, including, for example, soft-preemption and
+   graceful shutdown.  This document describes the usage of existing
+   Standards Track mechanisms to support LSP rerouting.  In this case,
+   it relies on mechanisms already defined as part of RSVP-TE and simply
+   describes a sequence of actions to be executed.  While existing
+   protocol definitions can be used to support reroute applications,
+   this document also defines a new reroute-specific error code to allow
+   for the future definition of reroute-application-specific error
+   values.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5710.
+
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 1]
+
+RFC 5710              MPLS and GMPLS LSP Reroutes           January 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Conventions Used in This Document ..........................4
+   2. Reroute Requests ................................................4
+      2.1. Processing at Requesting Node ..............................4
+           2.1.1. Reroute Request Timeouts ............................5
+      2.2. Processing at Upstream Node ................................6
+      2.3. Processing at Ingress ......................................6
+   3. Example Reroute Requests ........................................7
+      3.1. Node Reroute Request .......................................7
+      3.2. Interface Reroute Request ..................................7
+      3.3. Component Reroute Request ..................................8
+      3.4. Label Reroute Request ......................................9
+   4. IANA Considerations .............................................9
+   5. Security Considerations ........................................10
+   6. References .....................................................10
+      6.1. Normative References ......................................10
+      6.2. Informative References ....................................11
+   7. Acknowledgments ................................................11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 2]
+
+RFC 5710              MPLS and GMPLS LSP Reroutes           January 2010
+
+
+1.  Introduction
+
+   The Resource ReserVation Protocol (RSVP), see [RFC2205], has been
+   extended to support the control of Traffic Engineering (TE) Label
+   Switched Paths (LSPs) for both Multi-Protocol Label Switching (MPLS)
+   and Generalized MPLS (GMPLS) in, respectively, [RFC3209] and
+   [RFC3473].  In all cases, a PathErr message is used to report errors
+   to nodes upstream of the error-detecting node.  As defined in
+   [RFC2205] and left unmodified by [RFC3209], PathErr messages "do not
+   change path state in the nodes through which they pass".
+   Notwithstanding this definition, PathErr messages are most commonly
+   used to report errors during LSP establishment, i.e., the RSVP-TE
+   processing that occurs prior to the ingress receiving a Resv message.
+   (See [RFC5711] for a broader discussion on PathErr message handling.)
+   Support for such usage was enhanced via the introduction of the
+   Path_State_Removed flag in [RFC3473], which enables a processing node
+   to free related LSP state and resources.  The usage of PathErr
+   messages during LSP establishment was further covered in [RFC4920],
+   which describes in detail how a node may indicate that it or one of
+   its associated resources should be avoided, i.e., routed around,
+   during LSP establishment.
+
+   PathErr messages can also be used to support a number of other cases
+   that can occur after an LSP is established.  This document focuses on
+   the cases where PathErr messages can be used for a node to indicate
+   that it desires an upstream node to reroute an LSP around the
+   indicating node or resources associated with the indicating node.
+   Some examples of such cases are soft-preemption and graceful shutdown
+   (see [RFC5712] and [GRACEFUL]).
+
+   This document uses the terminology "reroute request" to refer to the
+   indication by a node that an upstream reroute should take place.
+   This document describes how a node can initiate a reroute request
+   without disrupting LSP data traffic or, when so desired, with the
+   disruption of data traffic and removal of LSP-associated state and
+   resources.  The applicability of this document is limited to point-
+   to-point LSPs.  Support for point-to-multipoint LSPs are for further
+   study.
+
+   The mechanisms used to indicate reroute requests are derived from the
+   mechanisms described in [RFC4920] and the error codes defined in
+   [RFC4736].  This document describes (1) how a non-disruptive reroute
+   request may be issued and, (2) based on an optional "timeout" period,
+   how rerouting may be forced by removing LSP state and associated
+   resources and signaling such removal.  While this document describes
+   how existing protocol definitions can be used to support rerouting,
+   it also defines a new reroute-specific error code to allow for the
+   future definition of reroute-application-specific error values.
+
+
+
+Berger, et al.              Standards Track                     [Page 3]
+
+RFC 5710              MPLS and GMPLS LSP Reroutes           January 2010
+
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Reroute Requests
+
+   This section describes how a downstream node can indicate that it
+   desires a node upstream (along the LSP path) to initiate the
+   rerouting of an LSP, and how the upstream nodes can respond to such a
+   request.  Initiating nodes, transit nodes, and ingress nodes are
+   described separately.
+
+2.1.  Processing at Requesting Node
+
+   When a transit or egress node desires to request the rerouting of an
+   established LSP, it first determines if it can act on the reroute
+   request locally.  Such a check MUST be performed on the condition
+   that the Explicit Route Object (ERO), see [RFC3209], received in the
+   LSP's incoming Path message does not preclude LSP rerouting.
+   Examples of requests that may trigger reroutes are avoiding an
+   outgoing interface, a component, label resource, or a next hop not
+   explicitly listed in the ERO.  In all cases, the actual repair action
+   SHOULD be performed after verification that the local policy allows
+   local repair for that LSP/state.  That is, any traffic-rerouting
+   action (associated to this state) must be initiated and completed
+   only as allowed by local node policy.
+
+   When the node cannot act locally, it MUST issue a PathErr message
+   indicating its inability to perform local rerouting.  The PathErr
+   message MUST contain an ERROR_SPEC object of the format defined in
+   [RFC2205] or [RFC3473].  Such a message MUST include one of the
+   following combinations of error codes and error values:
+
+      1. "Notify/Local node maintenance required" to support backwards
+         compatibility and to reroute around the local node.
+
+      2. "Notify/Local link maintenance required" to support backwards
+         compatibility and to reroute around a local interface.
+
+      3. "Reroute/<any Reroute error value>" for future compatibility
+         and when backwards compatibility is not a concern.
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 4]
+
+RFC 5710              MPLS and GMPLS LSP Reroutes           January 2010
+
+
+   The rest of the ERROR_SPEC object is constructed based on the local
+   rerouting decision and the resource that is to be avoided by an
+   upstream node.  It is important to note that the address and TLVs
+   carried by the ERROR_SPEC object identify the resource to be avoided
+   and not the error code and value.
+
+   When the reroute decision redirects traffic around the local node,
+   the local node MUST be indicated in the ERROR_SPEC object.
+   Otherwise, i.e., when the reroute decision does not redirect traffic
+   around the local node, the impacted interface MUST be indicated in
+   the ERROR_SPEC object and the IF_ID [RFC3473] ERROR_SPEC object
+   formats SHOULD be used to indicate the impacted interface.
+
+   The IF_ID [RFC3473] ERROR_SPEC object format MUST be used to indicate
+   a reroute request that is more specific than an interface.  The TLVs
+   defined in [RFC3471], as updated by [RFC3477], [RFC4201], and
+   [RFC4920] MAY be used to provide specific, additional reroute request
+   information, e.g., reroute around a specific label.  The principles
+   related to ERROR_SPEC object construction, defined in Section 6.3.1
+   of [RFC4920], SHOULD be followed.
+
+2.1.1.  Reroute Request Timeouts
+
+   Reroute request timeouts are used to remove an LSP when there is no
+   response to a reroute request.  A reroute request timeout is used
+   when an LSP is to be removed at the expiration of the reroute request
+   timeout period.  When such LSP removal is desired, and after
+   initiating a reroute request, the initiating node MUST initiate a
+   timeout during which it expects to receive a response to the reroute
+   request.  Valid responses are a PathTear message or a trigger Path
+   message with an ERO, avoiding the resource that was indicated in the
+   reroute request.  If either type of message is received, the timeout
+   period MUST be canceled and no further action is needed.  Note,
+   normal refresh processing is not modified by the introduction of
+   reroute request timeouts.  Such processing may result in Path state
+   being removed during the timeout period, in which case the timeout
+   period MUST also be canceled.
+
+   If the reroute request timeout is reached, the initiating node MUST
+   remove the LSP and its associated state and resources.  Removal of
+   LSP state is indicated downstream via a corresponding PathTear
+   message.  Removal is indicated upstream via a PathErr message with
+   the error code of "Service preempted".  The Path_State_Removed flag
+   MUST be set if supported.  When the Path_State_Removed flag is not
+   supported, a corresponding ResvTear MUST also be sent.
+
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 5]
+
+RFC 5710              MPLS and GMPLS LSP Reroutes           January 2010
+
+
+2.2.  Processing at Upstream Node
+
+   When a transit node's policy permits it to support reroute request
+   processing and local repair, the node MUST examine incoming PathErr
+   messages to see it the node can perform a requested reroute.  A
+   reroute request is indicated in a received PathErr message, which
+   carries one of the error code and value combinations listed above in
+   Section 2.1.  Note that a conformant implementation MUST check for
+   any of the three combinations listed in Section 2.1.
+
+   A transit node MAY act on a reroute request locally when the ERO
+   received in the LSP's incoming Path message does not preclude the
+   reroute.  As before, examples include loosely routed LSP next hops.
+   When the reroute request can be processed locally, standard, local
+   repair processing MUST be followed.  The node SHOULD limit the number
+   of local repair attempts.  Again, the expected norm is for local
+   repair, and thereby this case, to be precluded due to policy.
+
+   When the transit node supports [RFC4920] and is a boundary node, and
+   Boundary rerouting is allowed, it SHOULD use a route request as a
+   trigger to reroute the LSP.  (Per [RFC4920], the Flags field of the
+   LSP_ATTRIBUTES object of the initial Path message indicates "Boundary
+   rerouting".)  In the case the node triggers rerouting, it first MUST
+   identify an alternate path within the domain.  When such a path is
+   available, the node MUST terminate the PathErr message and issue a
+   Path message reflecting the identified alternate path.  Processing
+   then continues per [RFC4920].  When an alternate path is not
+   available, the node cannot act on the reroute request.
+
+   When a transit node cannot act on a reroute request locally, per
+   standard processing, it MUST propagate the received PathErr message
+   to the previous hop.
+
+2.3.  Processing at Ingress
+
+   When reroute processing is supported, an ingress node MUST check
+   received PathErr messages to identify them as indicating reroute
+   requests.  A reroute request is indicated in a received PathErr
+   message, which carries one of the error code and value combinations
+   listed above in Section 2.1.  Note that a conformant implementation
+   MUST check for any of the three combinations listed in Section 2.1.
+
+   Upon receiving a reroute request, the ingress MUST attempt to
+   identify an alternate path, avoiding the node, interface, resource,
+   etc. identified within the ERROR_SPEC object.  When an alternate path
+   cannot be identified, the reroute request MUST be discarded.  When an
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 6]
+
+RFC 5710              MPLS and GMPLS LSP Reroutes           January 2010
+
+
+   alternate path is identified, a corresponding make-before-break LSP
+   SHOULD be initiated and standard make-before-break procedures MUST be
+   followed.
+
+3.  Example Reroute Requests
+
+   This section provides example reroute requests.  This section is
+   informative rather than prescriptive.  Reroute requests are always
+   sent via PathErr messages.  As described above, a PathErr message may
+   contain either an [RFC2205] format ERROR_SPEC object, or an IF_ID
+   [RFC3473] format ERROR_SPEC object; it is the address and TLVs
+   carried by the ERROR_SPEC object, and not the error value, that
+   indicates the resource that is to be avoided by the reroute.
+
+3.1.  Node Reroute Request
+
+   To indicate that the node should be avoided by an upstream node, the
+   node originating the reroute may format the ERROR_SPEC per [RFC2205],
+   for example:
+
+      o    IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
+
+      +-------------+-------------+-------------+-------------+
+      |            IPv4 Error Node Address (4 bytes)          |
+      +-------------+-------------+-------------+-------------+
+      |    Flags    |  Error Code |        Error Value        |
+      +-------------+-------------+-------------+-------------+
+
+   The node address is set to the local node's TE router address.  Error
+   code is set to either "Notify/Local node maintenance required" or
+   "Reroute/<any Reroute error value>".
+
+3.2.  Interface Reroute Request
+
+   To indicate that a numbered interface should be avoided by an
+   upstream node, the node originating the reroute may format the
+   ERROR_SPEC per [RFC3473], for example:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 7]
+
+RFC 5710              MPLS and GMPLS LSP Reroutes           January 2010
+
+
+       0                   1                   2                   3
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            Length             | Class-Num (6) | C-Type (3)    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     IPv4 Error Node Address                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Flags     |   Error Code  |          Error Value          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Type (1)         |             Length (8)        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                            IP Address                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The node address is set to the local node's TE router address.  Error
+   code is set to either "Notify/Local link maintenance required" or
+   "Reroute/<any Reroute error value>".  IP address is set to the TE
+   address of the interface to be avoided.
+
+3.3.  Component Reroute Request
+
+   To indicate that an unnumbered component should be avoided by an
+   upstream node, the node originating the reroute formats the
+   ERROR_SPEC per [RFC4201], for example:
+
+       0                   1                   2                   3
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            Length             | Class-Num (6) | C-Type (3)    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     IPv4 Error Node Address                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Flags     |   Error Code  |          Error Value          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Type (3)         |             Length (12)       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           Router ID                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     Interface ID (32 bits)                    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The node address is set to the local TE address used in the
+   advertisement of the bundle associated with the component.  Error
+   code is set to either "Notify/Local link maintenance required" or
+   "Reroute/<any Reroute error value>".  Router ID is set to the local
+   router ID, and Interface ID is the identifier assigned to the
+   component link by the local node.
+
+
+
+
+Berger, et al.              Standards Track                     [Page 8]
+
+RFC 5710              MPLS and GMPLS LSP Reroutes           January 2010
+
+
+3.4.  Label Reroute Request
+
+   To indicate that a label should be avoided by an upstream node, the
+   node originating the reroute may format the ERROR_SPEC per [RFC4920],
+   for example:
+
+       0                   1                   2                   3
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            Length             | Class-Num (6) | C-Type (3)    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     IPv4 Error Node Address                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Flags     |   Error Code  |          Error Value          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Type (1)         |             Length (8)        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                            IP Address                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Type (6)         |             Length (8)        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         DOWNSTREAM_LABEL                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The node address is set to the local node's TE router address.  Error
+   code is set to either "Notify/Local link maintenance required" or
+   "Reroute/<any Reroute error value>".  IP address is set to the TE
+   address of the interface that supports the label to be avoided.
+   DOWNSTREAM_LABEL indicates the label to be avoided.
+
+4.  IANA Considerations
+
+   IANA assigned values for namespaces defined in this document and
+   reviewed in this section.
+
+   IANA made the assignment in the "Error Codes and Globally-Defined
+   Error Value Sub-Codes" section of the "RSVP Parameters" registry:
+
+         34  Reroute                                [RFC5710]
+
+      This error code has the following defined Error Value sub-code:
+
+            0 = Generic LSP reroute request
+
+      Reroute error values should be allocated based on the following
+      allocation policy as defined in [RFC5226].
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 9]
+
+RFC 5710              MPLS and GMPLS LSP Reroutes           January 2010
+
+
+            Range         Registration Procedures
+            --------      ------------------------
+            0-32767       IETF Consensus
+            32768-65535   Private Use
+
+5.  Security Considerations
+
+   Sections 9 of [RFC4920] and [RFC4736] should be used as the starting
+   point for reviewing the security considerations related to the
+   formats and mechanisms discussed in this document.  This document
+   introduces a new error code, but this code is functionally equivalent
+   to existing semantics, in particular, the error code/error value
+   combinations of "Notify/Local node maintenance required" and
+   "Notify/Local link maintenance required".  As such, this document
+   introduces no new security considerations beyond what already applies
+   to these existing formats and mechanisms.  Future documents may
+   define new error values; any considerations specific to those values
+   should be discussed in the document defining them.
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2205]    Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
+                S. Jamin, "Resource ReSerVation Protocol (RSVP) --
+                Version 1 Functional Specification", RFC 2205, September
+                1997.
+
+   [RFC3209]    Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
+                V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+                Tunnels", RFC 3209, December 2001.
+
+   [RFC3471]    Berger, L., Ed., "Generalized Multi-Protocol Label
+                Switching (GMPLS) Signaling Functional Description", RFC
+                3471, January 2003.
+
+   [RFC3473]    Berger, L., Ed., "Generalized Multi-Protocol Label
+                Switching (GMPLS) Signaling Resource ReserVation
+                Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
+                3473, January 2003.
+
+   [RFC3477]    Kompella, K. and Y. Rekhter, "Signalling Unnumbered
+                Links in Resource ReSerVation Protocol - Traffic
+                Engineering (RSVP-TE)", RFC 3477, January 2003.
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 10]
+
+RFC 5710              MPLS and GMPLS LSP Reroutes           January 2010
+
+
+   [RFC4201]    Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
+                in MPLS Traffic Engineering (TE)", RFC 4201, October
+                2005.
+
+   [RFC4920]    Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
+                N., and G. Ash, "Crankback Signaling Extensions for MPLS
+                and GMPLS RSVP-TE", RFC 4920, July 2007.
+
+   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
+                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+                May 2008.
+
+6.2.  Informative References
+
+   [RFC4736]    Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang,
+                "Reoptimization of Multiprotocol Label Switching (MPLS)
+                Traffic Engineering (TE) Loosely Routed Label Switched
+                Path (LSP)", RFC 4736, November 2006.
+
+   [GRACEFUL]   Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton,
+                "Graceful Shutdown in MPLS and Generalized MPLS Traffic
+                Engineering Networks", Work in Progress, September 2009.
+
+   [RFC5711]    Vasseur, JP., Ed., Swallow, G., and I. Minei, "Node
+                Behavior upon Originating and Receiving Resource
+                Reservation Protocol (RSVP) Path Error Messages", RFC
+                5711, January 2010.
+
+   [RFC5712]    Meyer, M., Ed. and JP. Vasseur, Ed., "MPLS Traffic
+                Engineering Soft Preemption", RFC 5712, January 2010.
+
+7.  Acknowledgments
+
+   This document was conceived along with Matthew Meyer.  George Swallow
+   provided valuable feedback.  The General Area Review Team (Gen-ART)
+   review was performed by Francis Dupont.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 11]
+
+RFC 5710              MPLS and GMPLS LSP Reroutes           January 2010
+
+
+Authors' Addresses
+
+   Lou Berger
+   LabN Consulting, L.L.C.
+   Phone: +1-301-468-9228
+   EMail: lberger@labn.net
+
+
+   Dimitri Papadimitriou
+   Alcatel Lucent
+   Francis Wellesplein 1,
+   B-2018 Antwerpen, Belgium
+   Phone: +32 3 240-8491
+   EMail: Dimitri.Papadimitriou@alcatel-lucent.be
+
+
+   JP Vasseur
+   Cisco Systems, Inc
+   11, Rue Camille Desmoulins
+   L'Atlantis
+   92782 Issy Les Moulineaux
+   France
+   EMail: jpv@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 12]
+