draft-ietf-ccamp-mpls-graceful-shutdown-06.txt   draft-ietf-ccamp-mpls-graceful-shutdown-07.txt 
CCAMP Working Group CCAMP Working Group
Internet Draft Internet Draft
Zafar Ali Zafar Ali
Jean-Philippe Vasseur Jean-Philippe Vasseur
Anca Zamfir Anca Zamfir
Cisco Systems, Inc. Cisco Systems, Inc.
Jonathan Newton Jonathan Newton
Cable and Wireless Cable and Wireless
Intended status: Informational July 03, 2008
Expires: January 02, 2009
draft-ietf-ccamp-mpls-graceful-shutdown-06.txt Category: Informational
Expires: April 27, 2009 October 28, 2008
draft-ietf-ccamp-mpls-graceful-shutdown-07.txt
Graceful Shutdown in MPLS and Generalized MPLS Graceful Shutdown in MPLS and Generalized MPLS
Traffic Engineering Networks Traffic Engineering Networks
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
skipping to change at page 1, line 44 skipping to change at page 1, line 45
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress." in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 02, 2009. This Internet-Draft will expire on January 03, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 draft-ietf-ccamp-mpls-graceful-shutdown-07.txt October 07
Abstract Abstract
MPLS-TE Graceful Shutdown is a method for explicitly notifying MPLS-TE Graceful Shutdown is a method for explicitly notifying
the nodes in a Traffic Engineering (TE) enabled network that the the nodes in a Traffic Engineering (TE) enabled network that the
TE capability on a link or on an entire Label Switching Router TE capability on a link or on an entire Label Switching Router
(LSR) is going to be disabled. MPLS-TE graceful shutdown (LSR) is going to be disabled. MPLS-TE graceful shutdown
mechanisms are tailored toward addressing planned outage in the mechanisms are tailored toward addressing planned outage in the
network. network.
This document provides requirements and protocol mechanisms to This document provides requirements and protocol mechanisms to
reduce/eliminate traffic disruption in the event of a planned reduce/eliminate traffic disruption in the event of a planned
shutdown of a network resource. These operations are equally shutdown of a network resource. These operations are equally
applicable to both MPLS and its Generalized MPLS (GMPLS) applicable to both MPLS and its Generalized MPLS (GMPLS)
extensions. extensions.
Table of Contents Table of Contents
1. Introduction................................................2 1. Introduction....................................................2
2. Terminology.................................................3 2. Terminology.....................................................3
3. Requirements for Graceful Shutdown..........................4 3. Requirements for Graceful Shutdown..............................4
4. Mechanisms for Graceful Shutdown............................5 4. Mechanisms for Graceful Shutdown................................5
4.1 OSPF/ ISIS Mechanisms for graceful shutdown................5 4.1 OSPF/ ISIS Mechanisms for graceful shutdown..................5
4.2 RSVP-TE Signaling Mechanisms for graceful shutdown.........6 4.2 RSVP-TE Signaling Mechanisms for graceful shutdown...........6
5. Security Considerations.....................................8 5. Security Considerations.........................................8
6. IANA Considerations.........................................8 6. IANA Considerations.............................................8
7. Acknowledgments.............................................8 7. Acknowledgments.................................................8
8. Reference...................................................8 8. Reference.......................................................8
8.1 Normative Reference........................................8 8.1 Normative Reference..........................................8
8.2 Informative Reference......................................9 8.2 Informative Reference........................................9
9. Authors' Address:..........................................10 9. Authors' Address:..............................................10
10. Intellectual Property Considerations......................10 10. Intellectual Property Considerations..........................10
11. Disclaimer of Validity....................................11 11. Disclaimer of Validity........................................11
12. Copyright Statement.......................................11 12. Copyright Statement...........................................11
1. Introduction 1. Introduction
When outages in a network are planned (e.g. for maintenance When outages in a network are planned (e.g. for maintenance
purpose), some mechanisms can be used to avoid traffic purpose), some mechanisms can be used to avoid traffic
disruption. This is in contrast with unplanned network element disruption. This is in contrast with unplanned network element
failure, where traffic disruption can be minimized thanks to failure, where traffic disruption can be minimized thanks to
recovery mechanisms but may not be avoided. Hence, a Service recovery mechanisms but may not be avoided. Hence, a Service
Provider may desire to gracefully (temporarily or indefinitely) Provider may desire to gracefully (temporarily or indefinitely)
remove a TE Link, a group of TE Links or an entire node for remove a TE Link, a group of TE Links or an entire node for
administrative reasons such as link maintenance, administrative reasons such as link maintenance,
software/hardware upgrade at a node or significant TE software/hardware upgrade at a node or significant TE
configuration changes. In all these cases, the goal is to configuration changes. In all these cases, the goal is to
minimize the impact on the traffic carried over TE LSPs in the minimize the impact on the traffic carried over TE LSPs in the
network by triggering notifications so as to gracefully reroute network by triggering notifications so as to gracefully reroute
draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 draft-ietf-ccamp-mpls-graceful-shutdown-07.txt October 07
such flows before the administrative procedures are started. such flows before the administrative procedures are started.
These operations are equally applicable to both MPLS and its These operations are equally applicable to both MPLS and its
Generalized MPLS (GMPLS) extensions. Generalized MPLS (GMPLS) extensions.
Graceful shutdown of a resource may require several steps. These Graceful shutdown of a resource may require several steps. These
steps can be broadly divided into two sets: disabling the steps can be broadly divided into two sets: disabling the
resource in the control plane and removing the resource for resource in the control plane and removing the resource for
forwarding. The node initiating the graceful shutdown condition forwarding. The node initiating the graceful shutdown condition
is expected to introduce a delay between disabling the resource is expected to introduce a delay between disabling the resource
skipping to change at page 3, line 38 skipping to change at page 3, line 38
a separate step that is taken before the IGP on the link is a separate step that is taken before the IGP on the link is
brought down and before the interface is brought down at brought down and before the interface is brought down at
different layers. This document only addresses TE nodes and TE different layers. This document only addresses TE nodes and TE
resources. resources.
2. Terminology 2. Terminology
LSR - Label Switching Router. The terms node and LSR are used LSR - Label Switching Router. The terms node and LSR are used
interchangeably in this document. interchangeably in this document.
GMPLS - - The term GMPLS is used in this document to refer to GMPLS - The term GMPLS is used in this document to refer to
packet MPLS-TE, as well as GMPLS extensions to MPLS-TE. packet MPLS-TE, as well as GMPLS extensions to MPLS-TE.
LSP - An MPLS-TE/ GMPLS-TE Label Switched Path. LSP - An MPLS-TE/ GMPLS-TE Label Switched Path.
Head-end node: Ingress LSR that initiated signaling for the Path. Head-end node: Ingress LSR that initiated signaling for the Path.
Border node: Ingress LSR of an LSP segment (S-LSP). Border node: Ingress LSR of an LSP segment (S-LSP).
Path Computation Element (PCE): An entity that computes the Path Computation Element (PCE): An entity that computes the
routes on behalf of its clients (PCC). routes on behalf of its clients (PCC).
TE Link - - The term TE link refers to single or a bundle of TE Link - The term TE link refers to single or a bundle of
physical link(s) or FA-LSP(s) on which traffic engineering is physical link(s) or FA-LSP(s) on which traffic engineering is
enabled [RFC4206], [RFC4201]. enabled [RFC4206], [RFC4201].
Last resort resource: If a path to a destination from a given Last resort resource: If a path to a destination from a given
head-end node cannot be found upon removal of a resource (e.g., head-end node cannot be found upon removal of a resource (e.g.,
draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 draft-ietf-ccamp-mpls-graceful-shutdown-07.txt October 07
TE link, TE node), the resource is called last resort to reach TE link, TE node), the resource is called last resort to reach
that destination from the given head-end node. that destination from the given head-end node.
3. Requirements for Graceful Shutdown 3. Requirements for Graceful Shutdown
This section lists the requirements for graceful shutdown in the This section lists the requirements for graceful shutdown in the
context of GMPLS Traffic Engineering. context of GMPLS Traffic Engineering.
- Graceful shutdown is required to address graceful removal of - Graceful shutdown is required to address graceful removal of
skipping to change at page 5, line 5 skipping to change at page 5, line 5
packet-based (MPLS) TE LSPs. packet-based (MPLS) TE LSPs.
- In order to make rerouting effective, it is required that when - In order to make rerouting effective, it is required that when
a node initiates the graceful shutdown of a resource, it a node initiates the graceful shutdown of a resource, it
identifies to all other network nodes the TE resource under identifies to all other network nodes the TE resource under
graceful shutdown. graceful shutdown.
- Depending on switching technology, it may be possible to - Depending on switching technology, it may be possible to
shutdown a label resource, e.g., shutting down a lambda in a shutdown a label resource, e.g., shutting down a lambda in a
Lambda Switch Capable (LSC) node. Lambda Switch Capable (LSC) node.
draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 draft-ietf-ccamp-mpls-graceful-shutdown-07.txt October 07
4. Mechanisms for Graceful Shutdown 4. Mechanisms for Graceful Shutdown
An IGP only solution based on [RFC3630], [RFC3784], [RFC4203] and An IGP only solution based on [RFC3630], [RFC3784], [RFC4203] and
[RFC4205] are not applicable when dealing with Inter-area and [RFC4205] are not applicable when dealing with Inter-area and
Inter-AS traffic engineering, as IGP LSA/LSP flooding is Inter-AS traffic engineering, as IGP LSA/LSP flooding is
restricted to IGP areas/levels. Consequently, RSVP based restricted to IGP areas/levels. Consequently, RSVP based
mechanisms are required to cope with TE LSPs spanning multiple mechanisms are required to cope with TE LSPs spanning multiple
domains. At the same time, RSVP mechanisms only convey the domains. At the same time, RSVP mechanisms only convey the
information for the transiting LSPs to the router along the information for the transiting LSPs to the router along the
skipping to change at page 6, line 5 skipping to change at page 6, line 5
available within the TE link, the link attributes associated with available within the TE link, the link attributes associated with
the TE link are recomputed. Similarly, If graceful shutdown the TE link are recomputed. Similarly, If graceful shutdown
procedure is performed on a label resource within a TE Link, the procedure is performed on a label resource within a TE Link, the
link attributes associated with the TE link are recomputed. If link attributes associated with the TE link are recomputed. If
the removal of the component link or label resource results in a the removal of the component link or label resource results in a
significant bandwidth change event, a new LSA is originated with significant bandwidth change event, a new LSA is originated with
the new traffic parameters. If the last component link is being the new traffic parameters. If the last component link is being
shutdown, the routing procedure related to TE link removal is shutdown, the routing procedure related to TE link removal is
used. used.
draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 draft-ietf-ccamp-mpls-graceful-shutdown-07.txt October 07
Neighbors of the node where graceful shutdown procedure is in Neighbors of the node where graceful shutdown procedure is in
progress continues to advertise the actual unreserved bandwidth progress continues to advertise the actual unreserved bandwidth
of the TE links from the neighbors to that node, without any of the TE links from the neighbors to that node, without any
routing adjacency change. routing adjacency change.
When graceful shutdown at node level is desired, the node in When graceful shutdown at node level is desired, the node in
question follows the procedure specified in the previous section question follows the procedure specified in the previous section
for all TE Links. for all TE Links.
4.2 RSVP-TE Signaling Mechanisms for graceful shutdown 4.2 RSVP-TE Signaling Mechanisms for graceful shutdown
As discussed in Section 3, one of the requirements for the As discussed in Section 3, one of the requirements for the
signaling mechanism for graceful shutdown is to carry information signaling mechanism for graceful shutdown is to carry information
about the resource under graceful shutdown. The Graceful Shutdown about the resource under graceful shutdown. For this purpose the
mechanism outlined in the following section uses PathErr in order Graceful Shutdown uses LSP rerouting mechanism as defined in
to achieve this requirement. These mechanisms apply to both [LSP-REROUTE]. Specifically, the node where graceful shutdown of
existing and new LSPs. an unbundled TE link or an entire bundled TE link is desired
triggers a PathErr message with the error code "Reroute" and an
The node where graceful shutdown of an unbundled link or an error value of "TE link Graceful Shutdown required" for all
entire bundled TE link is desired triggers a PathErr message with affected LSPs. Similarly, the node that is being gracefully
the error code "Notify" and an error value of "Local link shutdown triggers a PathErr message with the error code "Reroute"
maintenance required" for all affected LSPs. Similarly, the node and an error value of "Node Graceful Shutdown required" for all
that is being gracefully shutdown triggers a PathErr message with LSPs.
the error code "Notify" and an error value of "Local node
maintenance required" for all LSPs.
MPLS TE Link Bundling [RFC4201] requires that an LSP is pinned MPLS TE Link Bundling [RFC4201] requires that an LSP is pinned
down to a component link(s). Consequently, graceful shutdown of a down to a component link. Consequently, graceful shutdown of a
component link in a bundled TE link differs from graceful component link in a bundled TE link differs from graceful
shutdown of unbundled TE link or entire bundled TE link. shutdown of unbundled TE link or entire bundled TE link.
Specifically, in the former case, when only a subset of component Specifically, in the former case, when only a subset of component
links and not the entire TE bundled link is being shutdown, the links and not the entire TE bundled link is being shutdown, the
remaining component links of the bundled TE link may still be remaining component links of the bundled TE link may still be
able to admit new LSPs. The node where graceful shutdown of a able to admit new LSPs. The node where graceful shutdown of a
component link is desired triggers a PathErr message with the component link is desired triggers a PathErr message with the
error code "Notify" and the new error value of "Local component error code "Reroute" and the new error value of "Component link
link maintenance required" for all affected LSPs. The PathErr Graceful Shutdown required" for all affected LSPs. The PathErr
message includes in the ERROR_SPEC the TE Link ID address. If the message includes in the ERROR_SPEC the TE Link ID address. If the
last component link is being shutdown, procedure for gracefully last component link is being shutdown, procedure for gracefully
shutdown entire bundled TE link outlined above is be used, shutdown entire bundled TE link outlined above is be used,
instead. instead.
If graceful shutdown of a label resource is desired, the node If graceful shutdown of a label resource is desired, the node
initiating this action triggers a PathErr message with the error initiating this action triggers a PathErr message with the error
code "Notify" and the new error value of "Local label resource code "Reroute" and the new error value of "Label resource
maintenance required" for the affected LSP. The PathErr message Graceful Shutdown required" for the affected LSP. The PathErr
includes in the ERROR_SPEC the TE Link ID address. message includes in the ERROR_SPEC the TE Link ID address.
The "Notify" error code for the ERROR SPEC object is defined in The "Reroute" error code for the ERROR SPEC object is defined in
[RFC3209]. The "local link maintenance required" and "local node [LSP-REROUTE]. This document defines following four error value
maintenance required" error value for the "Notify" error code are for the "Reroute" error code [To Be Confirmed (TBC) by IANA upon
draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 publication of this document]:
defined in [RFC4736]. This document defines following two error draft-ietf-ccamp-mpls-graceful-shutdown-07.txt October 07
value for the "Notify" error code:
12 (TBA) Local component link maintenance required Error-value Meaning Reference
13 (TBA) Local label resource maintenance required 2 (TBC) Node Graceful Shutdown required This doc
3 (TBC) TE link Graceful Shutdown required This doc
4 (TBC) Component link Graceful Shutdown required This doc
5 (TBC) Label resource Graceful Shutdown required This doc
The PathErr message includes in the ERROR_SPEC the TE Link ID The PathErr message includes in the ERROR_SPEC the TE Link ID
address. address.
If unbundled TE link, component link of a bundled TE link, entire If unbundled TE link, component link of a bundled TE link, entire
bundled TE link, or label resource of a TE link is being bundled TE link, or label resource of a TE link is being
gracefully shutdown, the PathErr message includes the ERROR_SPEC gracefully shutdown, the PathErr message includes the ERROR_SPEC
object containing IP address of the TE Link being gracefully object containing IP address of the TE Link being gracefully
shutdown. If TE link is unnumbered, the PathErr message includes shutdown. If TE link is unnumbered, the PathErr message includes
the ERROR_SPEC object containing unnumbered ID and TE node ID for the ERROR_SPEC object containing unnumbered ID and TE node ID for
the TE Link being gracefully shutdown. Similarly, if the TE node the TE Link being gracefully shutdown. Similarly, if the TE node
is being gracefully shutdown, the PathErr message includes in the is being gracefully shutdown, the PathErr message includes in the
ERROR_SPEC object the MPLS-TE node ID address. ERROR_SPEC object the MPLS-TE node ID address.
When a head-end node, or border node receives a PathErr message When a head-end node, or border node receives a PathErr message
with "Notify" error code and error value of "local link with "Reroute" error code and error value of "Node Graceful
maintenance required" or "local node maintenance required", or Shutdown required" or "TE link Graceful Shutdown required", or
"local component link maintenance required", or "local label "Component link Graceful Shutdown required", or "Label resource
resource maintenance required" it triggers a make-before-break Graceful Shutdown required" it follows the procedures defined in
procedure. When performing path computation for the new LSP, the [LSP-REROUTE]. When performing path computation for the new LSP,
head-end node, or border node avoids using the TE resources the head-end node, or border node avoids using the TE resources
identified by the IP address contained in the PathErr. If PCE is identified by the IP address contained in the PathErr. If PCE is
used for path computation, head-end node or border node acts as used for path computation, head-end node or border node acts as
PCC to request the PCE via PCEP for path computation avoiding PCC to request the PCE via PCEP for path computation avoiding
resource being gracefully shutdown. The amount of time the head- resource being gracefully shutdown. The amount of time the head-
end node, or border node avoid using the TE resources identified end node, or border node avoid using the TE resources identified
by the IP address contained in the PathErr is based on a local by the IP address contained in the PathErr is based on a local
decision at head-end node or border node. decision at head-end node or border node.
If node initiating the graceful shutdown procedure received path If node initiating the graceful shutdown procedure received path
setup request for a new tunnel using resource being gracefully setup request for a new tunnel using resource being gracefully
shutdown, it sends a Path Error message with "Notify" error code shutdown, it sends a Path Error message with "Reroute" error code
in the ERROR SPEC object and an error value consistent with the in the ERROR SPEC object and an error value consistent with the
type of resource being gracefully shutdown. However, based on a type of resource being gracefully shutdown. However, based on a
local decision, if node initiating the graceful shutdown local decision, if node initiating the graceful shutdown
procedure received path setup request for an existing tunnel, it procedure received path setup request for an existing tunnel, it
may allow signaling for it. This is to allow resource being may allow signaling for it. This is to allow resource being
gracefully shutdown as a "last resort". The node initiating the gracefully shutdown as a "last resort". The node initiating the
graceful shutdown procedure can distinguish between new and graceful shutdown procedure can distinguish between new and
existing tunnels based on the tunnel ID in the SESSION object. existing tunnels based on the tunnel ID in the SESSION object.
Time or decision for removal of the resource being shutdown from Time or decision for removal of the resource being shutdown from
forwarding is based on a local decision at the node initiating forwarding is based on a local decision at the node initiating
the graceful shutdown procedure. the graceful shutdown procedure.
draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 draft-ietf-ccamp-mpls-graceful-shutdown-07.txt October 07
5. Security Considerations 5. Security Considerations
This document introduces two new error values for "Notify" error This document introduces two new error values for "Reroute" error
code of the ERROR SPEC object defined in [RFC3209]. The procedure code of the ERROR SPEC object defined in [LSP-REROUTE]. This
in this document also uses two error values for "Notify" error
code of the ERROR SPEC object already defined in [RFC4736]. This
document also introduces ways to make resources unavailable for document also introduces ways to make resources unavailable for
the control plane. It is therefore recommended that procedures in the control plane. It is therefore recommended that procedures in
[RFC2747], which provides mechanisms to protect against external [RFC2747], which provides mechanisms to protect against external
agents compromising the RSVP signaling state in an RSVP agent, be agents compromising the RSVP signaling state in an RSVP agent, be
used. Specifically, [RFC2747] mechanisms provide some degree of used. Specifically, [RFC2747] mechanisms provide some degree of
protection to the head-end node or border node RSVP agent against protection to the head-end node or border node RSVP agent against
making resources unavailable for control plan from an external making resources unavailable for control plan from an external
agent sending Path Error messages with existing or new error code agent sending Path Error messages with existing or new error code
and error values. In summary, existing security considerations and error values. In summary, existing security considerations
specified in [RFC2747], [RFC2205], [RFC3209], [RFC4736], specified in [LSP-REROUTE], [RFC2747], [RFC2205], [RFC3209],
[RFC3471], [RFC3473] and [MPLS-GMPLS-SECURITY] remain relevant [RFC4736], [RFC3471], [RFC3473] and [MPLS-GMPLS-SECURITY] remain
and suffice. relevant and suffice.
This document relies on existing procedures for advertisement of This document relies on existing procedures for advertisement of
TE LSA/LSP containing Link TLV. Tampering with TE LSAs may have TE LSA/LSP containing Link TLV. Tampering with TE LSAs may have
an effect on traffic engineering computations, and it is an effect on traffic engineering computations, and it is
suggested that any mechanisms used for securing the transmission suggested that any mechanisms used for securing the transmission
of normal OSPF LSAs/ ISIS LSPs be applied equally to all Opaque of normal OSPF LSAs/ ISIS LSPs be applied equally to all Opaque
LSAs/ LSPs this document uses. In summary, existing security LSAs/ LSPs this document uses. In summary, existing security
considerations specified in [RFC3630], [RFC3784], [RFC4203], considerations specified in [RFC3630], [RFC3784], [RFC4203],
[RFC4205] and [MPLS-GMPLS-SECURITY] remain relevant and suffice. [RFC4205] and [MPLS-GMPLS-SECURITY] remain relevant and suffice.
6. IANA Considerations 6. IANA Considerations
The following assignment is required in the "Notify" subsection The "Reroute" error code for the ERROR SPEC object is defined in
of "Error Codes and Values" section of the "RSVP PARAMETERS" [LSP-REROUTE]. This document defines following four error value
registry (located at http://www.iana.org/assignments/rsvp- for the "Reroute" error code [To Be Confirmed (TBC) by IANA upon
parameters): publication of this document]:
12 (TBA) - "Local component link maintenance required" flag.
13 (TBA) Local label resource maintenance required. Error-value Meaning Reference
2 (TBC) Node Graceful Shutdown required This doc
3 (TBC) TE link Graceful Shutdown required This doc
4 (TBC) Component link Graceful Shutdown required This doc
5 (TBC) Label resource Graceful Shutdown required This doc
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Adrian Farrel for his detailed The authors would like to thank Adrian Farrel for his detailed
comments and suggestions. The authors would also like to comments and suggestions. The authors would also like to
acknowledge useful comments from David Ward, Sami Boutros, and acknowledge useful comments from David Ward, Sami Boutros, and
Dimitri Papadimitriou. Dimitri Papadimitriou.
8. Reference 8. Reference
8.1 Normative Reference 8.1 Normative Reference
draft-ietf-ccamp-mpls-graceful-shutdown-07.txt October 07
[RFC3209] Awduche D., Berger, L., Gan, D., Li T., Srinivasan, V., [RFC3209] Awduche D., Berger, L., Gan, D., Li T., Srinivasan, V.,
Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001. 3209, December 2001.
draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07
[RFC4736] Jean-Philippe Vasseur, et al "Reoptimization of MPLS [RFC4736] Jean-Philippe Vasseur, et al "Reoptimization of MPLS
Traffic Engineering loosely routed LSP paths", RFC 4736, November Traffic Engineering loosely routed LSP paths", RFC 4736, November
2006. 2006.
[LSP-REROUTE] Berger, L., Papadimitriou, D., and J. Vasseur,
"PathErr Message Triggered MPLS and GMPLS LSP Reroute", draft-
ietf-mpls-gmpls-lsp-reroute-01 (work in progress) September 2008.
8.2 Informative Reference 8.2 Informative Reference
[RFC3630] Katz D., Kompella K., Yeung D., "Traffic Engineering [RFC3630] Katz D., Kompella K., Yeung D., "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September 2003. (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to [RFC3784] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic Engineering Intermediate System (IS-IS) Extensions for Traffic Engineering
(TE)", RFC 3784, June 2004. (TE)", RFC 3784, June 2004.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
skipping to change at page 9, line 51 skipping to change at page 10, line 5
[RFC4726] Farrel A, Vasseur, J.-P., Ayyangar A., "A Framework for [RFC4726] Farrel A, Vasseur, J.-P., Ayyangar A., "A Framework for
Inter-Domain MPLS Traffic Engineering", RFC 4726, November 2006. Inter-Domain MPLS Traffic Engineering", RFC 4726, November 2006.
[RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling
in MPLS Traffic Engineering", RFC 4201, October 2005. in MPLS Traffic Engineering", RFC 4201, October 2005.
[RFC4206] Kompella K., Rekhter Y., "Label Switched Paths (LSP) [RFC4206] Kompella K., Rekhter Y., "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS)
Traffic Engineering (TE)", RFC 4206, October 2005. Traffic Engineering (TE)", RFC 4206, October 2005.
draft-ietf-ccamp-mpls-graceful-shutdown-07.txt October 07
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000. Cryptographic Authentication", RFC 2747, January 2000.
[MPLS-GMPLS-SECURITY] Fang, L. et al, "Security Framework for [MPLS-GMPLS-SECURITY] Fang, L. et al, "Security Framework for
MPLS and GMPLS Networks", draft-fang-mpls-gmpls-security- MPLS and GMPLS Networks", draft-fang-mpls-gmpls-security-
framework-01.txt, work in progress. framework-01.txt, work in progress.
draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07
9. Authors' Address: 9. Authors' Address:
Zafar Ali Zafar Ali
Cisco systems, Inc., Cisco systems, Inc.,
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada. Canada.
Email: zali@cisco.com Email: zali@cisco.com
Jean Philippe Vasseur Jean Philippe Vasseur
skipping to change at page 10, line 52 skipping to change at page 11, line 5
such rights. Information on the procedures with respect to such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79. rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr. repository at http://www.ietf.org/ipr.
draft-ietf-ccamp-mpls-graceful-shutdown-07.txt October 07
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to to implement this standard. Please address the information to
the IETF at ietf-ipr@ietf.org. the IETF at ietf-ipr@ietf.org.
draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07
11. Disclaimer of Validity 11. Disclaimer of Validity
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 31 change blocks. 
80 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/