draft-ietf-ccamp-mpls-graceful-shutdown-10.txt   draft-ietf-ccamp-mpls-graceful-shutdown-11.txt 
CCAMP Working Group CCAMP Working Group
Internet Draft Internet Draft
Category: Informational Zafar Ali Zafar Ali
Expires: September 08, 2009 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
March 09, 2009
Category: Informational
Expires: March 12, 2010 September 13, 2009
draft-ietf-ccamp-mpls-graceful-shutdown-11.txt
Graceful Shutdown in MPLS and Generalized MPLS Graceful Shutdown in MPLS and Generalized MPLS
Traffic Engineering Networks Traffic Engineering Networks
draft-ietf-ccamp-mpls-graceful-shutdown-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. This document may contain the provisions of BCP 78 and BCP 79. This document may contain
material from IETF Documents or IETF Contributions published or material from IETF Documents or IETF Contributions published or
made publicly available before November 10, 2008. The person(s) made publicly available before November 10, 2008. The person(s)
controlling the copyright in some of this material may not have controlling the copyright in some of this material may not have
granted the IETF Trust the right to allow modifications of such granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining material outside the IETF Standards Process. Without obtaining
an adequate license from the person(s) controlling the copyright an adequate license from the person(s) controlling the copyright
skipping to change at page 1, line 39 skipping to change at page 1, line 41
IETF Standards Process, and derivative works of it may not be IETF Standards Process, and derivative works of it may not be
created outside the IETF Standards Process, except to format it created outside the IETF Standards Process, except to format it
for publication as an RFC or to translate it into languages other for publication as an RFC or to translate it into languages other
than English. than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of
months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by other
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.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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-TE 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..............................3 3. Requirements for Graceful Shutdown..............................4
4. Mechanisms for Graceful Shutdown................................4 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.........................................7 5. Security Considerations.........................................7
6. IANA Considerations.............................................7 6. IANA Considerations.............................................8
7. Acknowledgments.................................................7 7. Acknowledgments.................................................8
8. Reference.......................................................8 8. Reference.......................................................8
8.1 Normative Reference...........................................8 8.1 Normative Reference...........................................8
8.2 Informative Reference.........................................8 8.2 Informative Reference.........................................8
9. Authors' Address:...............................................9 9. Authors' Address:...............................................9
10. Copyright Notice..............................................10 10. Copyright Notice..............................................10
11. Legal.........................................................10 11. Legal.........................................................10
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 purposes), 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. Therefore, 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
such flows before the administrative procedures are started. such flows before the administrative procedures are started.
These operations are equally applicable to both MPLS [RFC3209] These operations are equally applicable to both MPLS-TE [RFC3209]
and its Generalized MPLS (GMPLS) extensions [RFC3471], [RFC3473]. and its Generalized MPLS (GMPLS) extensions [RFC3471], [RFC3473].
This document describes the mechanisms that can be used to
gracefully shutdown MPLS-TE/ GMPLS Traffic Engineering on a
resource such as a TE link, a component link within a bundled TE
link, a label resource or an entire TE node.
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 disabling the resource in the
forwarding. The node initiating the graceful shutdown condition data plane. The node initiating the graceful shutdown condition
is expected to introduce a delay between disabling the resource introduces a delay between the two sets to allow the control
in the control plane and removing the resource for forwarding. plane to gracefully divert the traffic away from the resource
This is to allow the control plane to gracefully divert the being gracefully shutdown. The trigger for the graceful shutdown
traffic away from the resource being gracefully shutdown. The event is a local matter at the node initiating the graceful
trigger for the graceful shutdown event is a local matter at the shutdown. Typically, graceful shutdown is triggered for
node initiating the graceful shutdown. Typically, graceful administrative reasons, such as link maintenance or
shutdown is triggered for administrative reasons, such as link software/hardware upgrade.
maintenance or software/hardware upgrade.
This document describes the mechanisms that can be used to
gracefully shutdown MPLS/ GMPLS Traffic Engineering on a resource
such as a TE link, a component link within a bundled TE link, a
label resource or an entire TE node.
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
packet MPLS-TE, as well as GMPLS extensions to MPLS-TE. MPLS-TE, as well as GMPLS extensions to MPLS-TE.
LSP - An MPLS-TE/ GMPLS-TE Label Switched Path. TE Link: The term TE link refers to single or a bundle of
physical links or FA-LSPs (see below) on which traffic
engineering is enabled [RFC4206], [RFC4201].
Head-end node: Ingress LSR that initiated signaling for the Path. TE LSP: A GMPLS Label Switched Path.
Border node: Ingress LSR of an LSP segment (S-LSP). S-LSP: A segment of a TE LSP
Path Computation Element (PCE): An entity that computes the FA-LSP (Forwarding Adjacency LSP): An LSP that is announced as a
routes on behalf of its clients (PCC). TE link into the same instance of the GMPLS control plane as the
one that was used to create the LSP [RFC4206].
TE Link - The term TE link refers to single or a bundle of ISIS-LSP: Link State Packets generated by ISIS routers and that
physical link(s) or FA-LSP(s) on which traffic engineering is contain routing information.
enabled [RFC4206], [RFC4201].
LSA: Link State Advertisements generated by OSPF routers and that
contain routing information.
TE-LSA/ TE-ISIS-LSP: The traffic engineering extensions to OSPF/
ISIS.
Head-end node: Ingress LSR that initiated signaling for the Path.
Border node: Ingress LSR of a TE LSP segment (S-LSP).
PCE (Path Computation Element): An entity that computes the
routes on behalf of its clients (PCC) [RFC4655].
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.,
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.
- Graceful shutdown is required to address graceful removal of - Graceful shutdown is required to address graceful removal of
one TE link, one component link within a bundled TE link, a set one TE link, one component link within a bundled TE link, a set
of TE links, a set of component links, label resource(s) or an of TE links, a set of component links, label resources, or an
entire node. entire node.
- Once an operator has initiated graceful shutdown of a network - Once an operator has initiated graceful shutdown of a network
resource, no new TE LSPs may be set up that use the resource. resource, no new TE LSPs may be set up that use the resource.
Any signaling message for a new LSP that explicitly specifies the Any signaling message for a new TE LSP that explicitly specifies
resource, or that would require the use of the resource due to the resource, or that would require the use of the resource due
local constraints, is required to be rejected as if the resource to local constraints, is required to be rejected as if the
were unavailable. resource were unavailable.
- It is desirable for new LSP setup attempts that would be - It is desirable for new TE LSP setup attempts that would be
rejected because of graceful shutdown of a resource (as described rejected because of graceful shutdown of a resource (as described
in the previous requirement) to avoid any attempt to use the in the previous requirement) to avoid any attempt to use the
resource by selecting an alternate route or other resources. resource by selecting an alternate route or other resources.
- If the resource being shutdown is a last resort, it can be - If the resource being shut down is a last resort resource, it
used. Time or decision for removal of the resource being shutdown can be used. Time or decision for removal of the resource being
is based on a local decision at the node initiating the graceful shut down is based on a local decision at the node initiating the
shutdown procedure. graceful shutdown procedure.
- It is required to give the ingress node the opportunity to take - It is required to give the ingress node the opportunity to take
actions in order to reduce/eliminate traffic disruption on the actions in order to reduce/eliminate traffic disruption on the TE
LSP(s) that are using the network resources which are about to be LSPs that are using the network resources which are about to be
shutdown. shutdown.
- Graceful shutdown mechanisms are equally applicable to intra- - Graceful shutdown mechanisms are equally applicable to intra-
domain and TE LSPs spanning multiple domains. Here, a domain is domain and TE LSPs spanning multiple domains, as defined in
defined as either an IGP area or an Autonomous System [RFC4726]. [RFC4726]. Examples of such domains include IGP areas and
Autonomous Systems.
- Graceful shutdown is equally applicable to GMPLS-TE, as well as - Graceful shutdown is equally applicable to packet and non-
packet-based (MPLS) TE LSPs. packet networks.
- 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 shut
shutdown a label resource, e.g., shutting down a lambda in a down a label resource, e.g., shutting down a lambda in a Lambda
Lambda Switch Capable (LSC) node. Switch Capable (LSC) node.
4. Mechanisms for Graceful Shutdown 4. Mechanisms for Graceful Shutdown
An IGP only solution based on [RFC3630], [RFC5305], [RFC4203] and An IGP only solution based on [RFC3630], [RFC5305], [RFC4203] and
[RFC5307] are not applicable when dealing with Inter-area and [RFC5307] is not applicable when dealing with inter-area and
Inter-AS traffic engineering, as IGP LSA/LSP flooding is inter-AS traffic engineering, as IGP flooding is restricted to
restricted to IGP areas/levels. Consequently, RSVP based IGP areas/levels. An RSVP based solution is proposed in this
mechanisms are required to cope with TE LSPs spanning multiple document to handle TE LSPs spanning multiple domains.
domains. At the same time, RSVP mechanisms only convey the In addition, in order to prevent LSRs in a domain to use the
information for the transiting LSPs to the router along the resource being shut down.
upstream Path and not to all nodes in the network. Furthermore, In addition, in order to discourage nodes from establishing new
graceful shutdown notification via IGP flooding is required to TE LSPs through the resources being shutdown, existing IGP
discourage a node from establishing new LSPs through the mechanisms are used for the shutdown notification.
resources being shutdown. In the following sections the
complementary mechanisms for RSVP-TE and IGP for Graceful
Shutdown are described.
A node where a link or the whole node is being shutdown may first A node where a link or the whole node is being shutdown first
trigger the IGP updates as described in Section 4.1, introduce a triggers the IGP updates as described in Section 4.1 and then,
delay to allow network convergence and only then use the with some delay to allow network convergence, uses the signaling
signaling mechanism described in Section 4.2. mechanism described in Section 4.2.
4.1 OSPF/ ISIS Mechanisms for graceful shutdown 4.1 OSPF/ ISIS Mechanisms for graceful shutdown
The procedures provided in this section are equally applicable to This section describes the use of existing OSPF and ISIS
OSPF and ISIS. mechanisms for the graceful shutdown in GMPLS networks.
OSPF and ISIS procedure for graceful shutdown of TE link(s) is The OSPF and ISIS procedures for graceful shutdown of TE links
similar to graceful restart of OSPF and ISIS as described in are similar to the graceful restart of OSPF and ISIS as described
[RFC4203] and [RFC5307], respectively. Specifically, the node in [RFC4203] and [RFC5307], respectively. Specifically, the node
where graceful-shutdown of a link is desired originates the TE where graceful shutdown of a link is desired originates the TE
LSA/LSP containing Link TLV for the link under graceful shutdown LSA/ISIS-LSP containing a Link TLV for the link under graceful
with Traffic Engineering metric set to 0xffffffff, 0 as shutdown with Traffic Engineering metric set to 0xffffffff, 0 as
unreserved bandwidth, and if the link has LSC or FSC as its unreserved bandwidth, and if the TE link has LSC or FSC as its
Switching Capability then also with 0 as Max LSP Bandwidth. A Switching Capability then also with 0 in the "Max LSP Bandwidth"
node may also specify a value for Minimum LSP bandwidth which is field of the Interface Switching Capability Descriptor (ISCD)
greater than the available bandwidth. This would discourage new sub-TLV. A node may also specify a value which is greater than
LSP establishment through the link under graceful shutdown. the available bandwidth in the "Minimum LSP bandwidth" field of
the same ISCD sub-TLV. This would discourage new TE LSP
establishment through the link under graceful shutdown.
If graceful shutdown procedure is performed for a component link If graceful shutdown procedure is performed for a component link
within a TE Link bundle and it is not the last component link within a TE Link bundle and it is not the last component link
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.
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 continue to advertise the actual unreserved bandwidth of
of the TE links from the neighbors to that node, without any the TE links from the neighbors to that node, without any routing
routing adjacency change. 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. For this purpose the about the resource under graceful shutdown. For this purpose the
Graceful Shutdown uses LSP rerouting mechanism as defined in Graceful Shutdown uses TE LSP rerouting mechanism as defined in
[LSP-REROUTE]. [LSP-REROUTE].
Specifically, the node where graceful shutdown of an unbundled TE Specifically, the node where graceful shutdown of an unbundled TE
link or an entire bundled TE link is desired triggers a PathErr link or an entire bundled TE link is desired triggers a PathErr
message with the error codes and error values of "Notify/Local message with the error code "Notify" and error value "Local link
link maintenance required", for all affected LSPs. Similarly, the maintenance required", for all affected TE LSPs. Similarly, the
node that is being gracefully shutdown triggers a PathErr message node that is being gracefully shut down triggers a PathErr
with the error codes and error values of "Notify/ Local node message with the error code "Notify" and error value "Local node
maintenance required", for all LSPs. For graceful shutdown of a maintenance required", for all TE LSPs. For graceful shutdown of
node, an unbundled TE link or an entire bundled TE link, the a node, an unbundled TE link or an entire bundled TE link, the
PathErr message may contain either an [RFC2205] format ERROR_SPEC PathErr message may contain either an [RFC2205] format ERROR_SPEC
object, or an IF_ID [RFC3473] format ERROR_SPEC object. In either object, or an IF_ID [RFC3473] format ERROR_SPEC object. In either
case, it is the address and TLVs carried by the ERROR_SPEC object case, 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 and not the error value that indicates the resource that is to be
gracefully shutdown. gracefully shutdown.
MPLS TE Link Bundling [RFC4201] requires that an LSP is pinned MPLS TE Link Bundling [RFC4201] requires that an TE LSP is pinned
down to a component link. 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 bundled TE 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 TE 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 codes and error values of "Notify/Local link maintenance error code "Notify" and error value of "Local link maintenance
required". The rest of the ERROR_SPEC object is constructed using required". The rest of the ERROR_SPEC object is constructed using
Component Reroute Request procedure defined in [LSP-REROUTE]. Component Reroute Request procedure defined in [LSP-REROUTE].
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
codes and error values of "Notify/Local link maintenance codes and error values of "Notify/Local link maintenance
required". The rest of the ERROR_SPEC object is constructed using required". The rest of the ERROR_SPEC object is constructed using
Label Reroute Request procedure defined in [LSP-REROUTE]. Label Reroute Request procedure defined in [LSP-REROUTE].
When a head-end node, a transit node or a border node receive a When a head-end node, a transit node or a border node receives a
PathErr message with error codes and error values of "Notify/Local PathErr message with the error code "Notify" and error value
link maintenance required" or "Notify/ Local node maintenance "Local link maintenance required" or "Local node maintenance
required", it follows the procedures defined in [LSP-REROUTE] to required", it follows the procedures defined in [LSP-REROUTE] to
reroute the traffic around the resource being gracefully shutdown. reroute the traffic around the resource being gracefully
When performing path computation for the new LSP, the head-end node, shutdown. When performing path computation for the new TE LSP,
or border node avoids using the TE resources identified by the the head-end node, or border node avoids using the TE resources
ERROR_SPEC object. If PCE is used for path computation, head-end identified by the ERROR_SPEC object. If PCE is used for path
node or border node acts as PCC to request the PCE via PCEP for path computation, head-end (or border) node acting as PCC specifies in
computation avoiding resource being gracefully shutdown. The its requests to the PCE that path computation should avoid the
amount of time the head-end node, or border node avoid using the resource being gracefully shutdown. The amount of time the head-
TE resources identified by the IP address contained in the end node, or border node avoids using the TE resources identified
PathErr is based on a local decision at head-end node or border by the IP address contained in the PathErr is based on a local
node. decision at head-end node or border node.
If node initiating the graceful shutdown procedure received path If the node initiating the graceful shutdown procedure receives a
setup request for a new tunnel using resource being gracefully path setup request for a new tunnel using resource being
shutdown, it sends a Path Error message with "Notify" error code gracefully shutdown, it sends a Path Error message with "Notify"
in the ERROR SPEC object and an error value consistent with the error code in the ERROR SPEC object and an error value consistent
type of resource being gracefully shutdown. However, based on a with the type of resource being gracefully shut down. However,
local decision, if an existing tunnel continues to use the based on a local decision, if an existing tunnel continues to use
resource being gracefully shutdown, the node initiating the the resource being gracefully shutdown, the node initiating the
graceful shutdown procedure may allow resource being gracefully graceful shutdown procedure may allow resource being gracefully
shutdown to be used as a "last resort". The node initiating the shutdown to be used 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 by inspecting the SENDER TEMPLATE and SESSION
objects.
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. For this purpose, the node the graceful shutdown procedure. For this purpose, the node
initiating graceful shutdown procedure follows the Reroute initiating graceful shutdown procedure follows the Reroute
Request Timeout procedure defined in [LSP-REROUTE]. Request Timeout procedure defined in [LSP-REROUTE].
5. Security Considerations 5. Security Considerations
This document introduces no new security considerations as this This document introduces no new security considerations as this
document describes usage of existing formats and mechanisms. This document describes usage of existing formats and mechanisms. This
document relies on existing procedures for advertisement of TE document relies on existing procedures for advertisement of TE
LSA/LSP containing Link TLV. Tampering with TE LSAs may have an LSA/ISIS-LSP containing Link TLV. Tampering with TE LSAs/ISIS-
effect on traffic engineering computations, and it is suggested LSPs may have an effect on traffic engineering computations, and
that any mechanisms used for securing the transmission of normal it is suggested that any mechanisms used for securing the
OSPF LSAs/ ISIS LSPs be applied equally to all Opaque LSAs/ LSPs transmission of normal LSAs/ISIS-LSPs be applied equally to all
this document uses. Existing security considerations specified Opaque LSAs/ISIS-LSPs this document uses. Existing security
in [RFC3630], [RFC5305], [RFC4203], [RFC5307] and [MPLS-GMPLS- considerations specified in [RFC3630], [RFC5305], [RFC4203],
SECURITY] remain relevant and suffice. Furthermore, security [RFC5307] and [MPLS-GMPLS-SECURITY] remain relevant and suffice.
considerations section in [LSP-REROUTE] and the Section 9 of
[RFC4736] should be used for understanding the security Furthermore, security considerations section in [LSP-REROUTE] and
considerations related to the formats and mechanisms used in this section 9 of [RFC4736] should be used for understanding the
document. security considerations related to the formats and mechanisms
used in this document.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
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
skipping to change at page 9, line 9 skipping to change at page 9, line 22
[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. in MPLS Traffic Engineering", RFC 4201.
[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. Traffic Engineering (TE)", RFC 4206.
[RFC4655] A. Farrel, J.-P. Vasseur, J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655.
[MPLS-GMPLS-SECURITY] Luyuan Fang, Ed. "Security Framework for [MPLS-GMPLS-SECURITY] Luyuan Fang, Ed. "Security Framework for
MPLS and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls- MPLS and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls-
security-framework, work in progress. security-framework, work in progress.
9. Authors' Address: 9. Authors' Address:
Zafar Ali Zafar Ali
Cisco systems, Inc., Cisco systems, Inc.,
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada.
Email: zali@cisco.com Email: zali@cisco.com
Jean Philippe Vasseur Jean Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: jpv@cisco.com Email: jpv@cisco.com
Anca Zamfir Anca Zamfir
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada
Email: ancaz@cisco.com Email: ancaz@cisco.com
Jonathan Newton Jonathan Newton
Cable and Wireless Cable and Wireless
jonathan.newton@cw.com jonathan.newton@cw.com
10. Copyright Notice 10. Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-
Please review these documents carefully, as they describe your info). Please review these documents carefully, as they describe
rights and restrictions with respect to this document. your rights and restrictions with respect to this document.
11. Legal 11. Legal
This documents and the information contained therein are provided This documents and the information contained therein 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 THEREIN WILL NOT WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE. OR FITNESS FOR A PARTICULAR PURPOSE.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
 End of changes. 50 change blocks. 
141 lines changed or deleted 171 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/