draft-ietf-ccamp-mpls-graceful-shutdown-13.txt   rfc5817.txt 
CCAMP Working Group
Internet Draft
Zafar Ali
Jean-Philippe Vasseur
Anca Zamfir
Cisco Systems, Inc.
Jonathan Newton
Cable and Wireless
Category: Informational
Expires: July 19, 2010 January 20, 2010
draft-ietf-ccamp-mpls-graceful-shutdown-13.txt Internet Engineering Task Force (IETF) Z. Ali
Request for Comments: 5817 JP. Vasseur
Category: Informational A. Zamfir
ISSN: 2070-1721 Cisco Systems, Inc.
J. Newton
Cable and Wireless
April 2010
Graceful Shutdown in MPLS and Generalized MPLS Graceful Shutdown in MPLS and Generalized MPLS
Traffic Engineering Networks Traffic Engineering Networks
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance MPLS-TE Graceful Shutdown is a method for explicitly notifying the
with the provisions of BCP 78 and BCP 79. This document may nodes in a Traffic Engineering (TE) enabled network that the TE
contain material from IETF Documents or IETF Contributions capability on a link or on an entire Label Switching Router (LSR) is
published or made publicly available before November 10, 2008. going to be disabled. MPLS-TE graceful shutdown mechanisms are
The person(s) controlling the copyright in some of this material tailored toward addressing planned outage in the network.
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.
Internet-Drafts are working documents of the Internet This document provides requirements and protocol mechanisms to reduce
Engineering Task Force (IETF), its areas, and its working or eliminate traffic disruption in the event of a planned shutdown of
groups. Note that other groups may also distribute working a network resource. These operations are equally applicable to both
documents as Internet-Drafts. MPLS-TE and its Generalized MPLS (GMPLS) extensions.
Internet-Drafts are draft documents valid for a maximum of six Status of This Memo
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (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). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on July 19, 2010. 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/rfc5817.
Copyright Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described include Simplified BSD License text as described in Section 4.e of
in Section 4.e of the Trust Legal Provisions and are provided the Trust Legal Provisions and are provided without warranty as
without warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
MPLS-TE Graceful Shutdown is a method for explicitly notifying
the nodes in a Traffic Engineering (TE) enabled network that the
TE capability on a link or on an entire Label Switching Router
(LSR) is going to be disabled. MPLS-TE graceful shutdown
mechanisms are tailored toward addressing planned outage in the
network.
This document provides requirements and protocol mechanisms to This document may contain material from IETF Documents or IETF
reduce/eliminate traffic disruption in the event of a planned Contributions published or made publicly available before November
shutdown of a network resource. These operations are equally 10, 2008. The person(s) controlling the copyright in some of this
applicable to both MPLS-TE and its Generalized MPLS (GMPLS) material may not have granted the IETF Trust the right to allow
extensions. 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.
Table of Contents Table of Contents
1. Introduction....................................................2 1. Introduction ....................................................3
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 / IS-IS 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. Manageability Considerations....................................7 5. Manageability Considerations ....................................8
6. Security Considerations.........................................8 6. Security Considerations .........................................8
7. IANA Considerations.............................................8 7. Acknowledgments .................................................8
8. Acknowledgments.................................................8 8. References ......................................................9
9. Reference.......................................................8 8.1. Normative References .......................................9
9.1 Normative Reference...........................................8 8.2. Informative References .....................................9
9.2 Informative Reference.........................................8
10. Authors' Address:..............................................9
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
purposes), some mechanisms can be used to avoid traffic purposes), some mechanisms can be used to avoid traffic disruption.
disruption. This is in contrast with unplanned network element This is in contrast with unplanned network element failure, where
failure, where traffic disruption can be minimized thanks to traffic disruption can be minimized thanks to recovery mechanisms,
recovery mechanisms, but may not be avoided. Therefore, a Service but may not be avoided. Therefore, a Service Provider may desire to
Provider may desire to gracefully (temporarily or indefinitely) gracefully (temporarily or indefinitely) remove a TE link, a group of
remove a TE Link, a group of TE Links or an entire node for TE links, or an entire node for administrative reasons such as link
administrative reasons such as link maintenance, 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 minimize
configuration changes. In all these cases, the goal is to the impact on the traffic carried over TE LSPs in the network by
minimize the impact on the traffic carried over TE LSPs in the triggering notifications so as to gracefully reroute such flows
network by triggering notifications so as to gracefully reroute before the administrative procedures are started.
such flows before the administrative procedures are started.
These operations are equally applicable to both MPLS-TE [RFC3209] These operations are equally applicable to both MPLS-TE [RFC3209] and
and its Generalized MPLS (GMPLS) extensions [RFC3471], [RFC3473]. its Generalized MPLS (GMPLS) extensions [RFC3471] [RFC3473].
This document describes the mechanisms that can be used to This document describes the mechanisms that can be used to gracefully
gracefully shutdown MPLS-TE/ GMPLS Traffic Engineering on a shut down MPLS-TE / GMPLS-TE on a resource such as a TE link, a
resource such as a TE link, a component link within a bundled TE component link within a bundled TE link, a label resource, or an
link, a label resource or an entire TE node. 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
resource in the control plane and disabling the resource in the the control plane and disabling the resource in the data plane. The
data plane. The node initiating the graceful shutdown condition node initiating the graceful shutdown condition introduces a delay
introduces a delay between the two sets to allow the control between the two sets to allow the control plane to gracefully divert
plane to gracefully divert the traffic away from the resource the traffic away from the resource being gracefully shut down. The
being gracefully shutdown. The trigger for the graceful shutdown trigger for the graceful shutdown event is a local matter at the node
event is a local matter at the node initiating the graceful initiating the graceful shutdown. Typically, graceful shutdown is
shutdown. Typically, graceful shutdown is triggered for triggered for administrative reasons, such as link maintenance or
administrative reasons, such as link maintenance or
software/hardware upgrade. software/hardware upgrade.
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 packet GMPLS: The term GMPLS is used in this document to refer to packet
MPLS-TE, as well as GMPLS extensions to MPLS-TE. MPLS-TE, as well as GMPLS extensions to MPLS-TE.
TE Link: The term TE link refers to single or a bundle of TE Link: The term TE link refers to a single link or a bundle of
physical links or FA-LSPs (see below) on which traffic physical links or FA-LSPs (see below) on which traffic engineering
engineering is enabled. is enabled.
TE LSP: A Traffic Engineered Label Switched Path. TE LSP: A Traffic Engineered Label Switched Path.
S-LSP: A segment of a TE LSP S-LSP: A segment of a TE LSP.
FA-LSP (Forwarding Adjacency LSP): An LSP that is announced as a FA-LSP (Forwarding Adjacency LSP): An LSP that is announced as a TE
TE link into the same instance of the GMPLS control plane as the link into the same instance of the GMPLS control plane as the one
one that was used to create the LSP [RFC4206]. that was used to create the LSP [RFC4206].
ISIS-LSP: Link State Packets generated by ISIS routers and that ISIS-LSP: Link State Packet that is generated by IS-IS routers and
contain routing information. that contains routing information.
LSA: Link State Advertisements generated by OSPF routers and that LSA: Link State Advertisement that is generated by OSPF routers and
contain routing information. that contains routing information.
TE-LSA/ TE-ISIS-LSP: The traffic engineering extensions to OSPF/ TE LSA / TE-IS-IS-LSP: The traffic engineering extensions to OSPF /
ISIS. IS-IS.
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 a TE LSP segment (S-LSP). Border node: Ingress LSR of a TE LSP segment (S-LSP).
PCE (Path Computation Element): An entity that computes the PCE (Path Computation Element): An entity that computes the routes on
routes on behalf of its clients (PCC) [RFC4655]. 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-
head-end node cannot be found upon removal of a resource (e.g., end node cannot be found upon removal of a resource (e.g., TE
TE link, TE node), the resource is called last resort to reach link, TE node), the resource is called "last resort" to reach that
that destination from the given head-end node. 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. context of GMPLS.
- Graceful shutdown is required to address graceful removal of - Graceful shutdown is required to address graceful removal of one TE
one TE link, one component link within a bundled TE link, a set link, one component link within a bundled TE link, a set of TE
of TE links, a set of component links, label resources, or an links, a set of component links, label resources, or an entire
entire node. 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
Any signaling message for a new TE LSP that explicitly specifies signaling message for a new TE LSP that explicitly specifies the
the resource, or that would require the use of the resource due resource, or that would require the use of the resource due to
to local constraints, is required to be rejected as if the local constraints, is required to be rejected as if the resource
resource were unavailable. were unavailable.
- It is desirable for new TE LSP setup attempts that would be - It is desirable for new TE LSP set-up 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 shut down is a last resort resource, - If the resource being shut down is a last-resort resource, based on
based on a local decision, the node initiating the graceful a local decision, the node initiating the graceful shutdown
shutdown procedure can cancel the shutdown operation. procedure can cancel the shutdown operation.
- 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 TE actions in order to reduce or eliminate traffic disruption on the
LSPs that are using the network resources which are about to be TE LSPs that are using the network resources that are about to be
shut down. shut down.
- Graceful shutdown mechanisms are equally applicable to intra- - Graceful shutdown mechanisms are equally applicable to intra-domain
domain and TE LSPs spanning multiple domains, as defined in TE LSPs and those spanning multiple domains, as defined in
[RFC4726]. Examples of such domains include IGP areas and [RFC4726]. Examples of such domains include IGP areas and
Autonomous Systems. Autonomous Systems.
- Graceful shutdown is equally applicable to packet and non- - Graceful shutdown is equally applicable to packet and non-packet
packet networks. networks.
- In order to make rerouting effective, it is required that when - In order to make rerouting effective, it is required that when a
a node initiates the graceful shutdown of a resource, it node initiates the graceful shutdown of a resource, it notifies all
identifies to all other network nodes the TE resource under other network nodes about the TE resource under graceful shutdown.
graceful shutdown.
- Depending on switching technology, it may be possible to shut
down a label resource, e.g., shutting down a lambda in a Lambda
Switch Capable (LSC) node.
4. Mechanisms for Graceful Shutdown - Depending on switching technology, it may be possible to shut down
a label resource, e.g., shutting down a lambda in a Lambda Switch
Capable (LSC) node.
An IGP only solution based on [RFC3630], [RFC5305], [RFC4203] and 4. Mechanisms for Graceful Shutdown
[RFC5307] is not applicable when dealing with inter-area and
inter-AS traffic engineering, as IGP flooding is restricted to
IGP areas/levels. An RSVP based solution is proposed in this
document to handle TE LSPs spanning multiple domains.
In addition, in order to prevent LSRs in a domain to use the
resource being shut down.
In addition, in order to discourage nodes from establishing new
TE LSPs through the resources being shutdown, existing IGP
mechanisms are used for the shutdown notification.
A node where a link or the whole node is being shutdown first An IGP-only solution based on [RFC3630], [RFC5305], [RFC4203] and
triggers the IGP updates as described in Section 4.1 and then, [RFC5307] is not applicable when dealing with inter-area and inter-AS
with some delay to allow network convergence, uses the signaling traffic engineering, as IGP flooding is restricted to IGP
mechanism described in Section 4.2. areas/levels. An RSVP-based solution is proposed in this document to
handle TE LSPs spanning multiple domains. In addition, in order to
discourage nodes from establishing new TE LSPs through the resources
being shut down, existing IGP mechanisms are used for the shutdown
notification.
4.1 OSPF/ ISIS Mechanisms for graceful shutdown A node where a link or the whole node is being shut down first
triggers the IGP updates as described in Section 4.1 and then, with
some delay to allow network convergence, uses the signaling mechanism
described in Section 4.2.
This section describes the use of existing OSPF and ISIS 4.1. OSPF / IS-IS Mechanisms for Graceful Shutdown
mechanisms for the graceful shutdown in GMPLS networks.
The OSPF and ISIS procedures for graceful shutdown of TE links This section describes the use of existing OSPF and IS-IS mechanisms
are similar to the graceful restart of OSPF and ISIS as described for the graceful shutdown in GMPLS networks.
in [RFC4203] and [RFC5307], respectively. Specifically, the node
where graceful shutdown of a link is desired originates the TE
LSA/ISIS-LSP containing a Link TLV for the link under graceful
shutdown with Traffic Engineering metric set to 0xffffffff, 0 as
unreserved bandwidth, and if the TE link has LSC or FSC as its
Switching Capability then also with 0 in the "Max LSP Bandwidth"
field of the Interface Switching Capability Descriptor (ISCD)
sub-TLV. A node may also specify a value which is greater than
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 The OSPF and IS-IS procedures for graceful shutdown of TE links are
within a TE Link bundle and it is not the last component link similar to the graceful restart of OSPF and IS-IS as described in
available within the TE link, the link attributes associated with [RFC4203] and [RFC5307], respectively. Specifically, the node where
the TE link are recomputed. Similarly, If graceful shutdown graceful shutdown of a link is desired originates the TE LSA or IS-
procedure is performed on a label resource within a TE Link, the IS-LSP containing a Link TLV for the link under graceful shutdown
link attributes associated with the TE link are recomputed. If with the Traffic Engineering metric set to 0xffffffff, 0 as
the removal of the component link or label resource results in a unreserved bandwidth. If the TE link has LSC or FSC as its Switching
significant bandwidth change event, a new LSA is originated with Capability, then it also has 0 in the "Max LSP Bandwidth" field of
the new traffic parameters. If the last component link is being the Interface Switching Capability Descriptor (ISCD) sub-TLV. A node
shut down, the routing procedure related to TE link removal is may also specify a value that is greater than the available bandwidth
used. 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 the graceful shutdown procedure is performed for a 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 the
TE link are recomputed. Similarly, if the graceful shutdown
procedure is performed on a label resource within a TE link, the link
attributes associated with the TE link are recomputed. If the
removal of the component link or label resource results in a
significant bandwidth change event, a new LSA is originated with the
new traffic parameters. If the last component link is being shut
down, the routing procedure related to TE link removal is used.
Neighbors of the node where graceful shutdown procedure is in Neighbors of the node where graceful shutdown procedure is in
progress continue to advertise the actual unreserved bandwidth of progress continue to advertise the actual unreserved bandwidth of the
the TE links from the neighbors to that node, without any routing TE links from the neighbors to that node, without any 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
question follows the procedure specified in the previous section follows the procedure specified in the previous section for all TE
for all TE Links. 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
signaling mechanism for graceful shutdown is to carry information mechanism for graceful shutdown is to carry information about the
about the resource under graceful shutdown. For this purpose the resource under graceful shutdown. For this purpose, the graceful
Graceful Shutdown uses TE LSP rerouting mechanism as defined in shutdown procedure uses TE LSP rerouting mechanism as defined in
[RFC5710]. [RFC5710].
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 code "Notify" and error value "Local link message with the error code "Notify" and error value "Local link
maintenance required", for all affected TE LSPs. Similarly, the maintenance required", for all affected TE LSPs. Similarly, the node
node that is being gracefully shut down triggers a PathErr that is being gracefully shut down triggers a PathErr message with
message with the error code "Notify" and error value "Local node the error code "Notify" and error value "Local node maintenance
maintenance required", for all TE LSPs. For graceful shutdown of required", for all TE LSPs. For graceful shutdown of a node, an
a node, an unbundled TE link or an entire bundled TE link, the unbundled TE link, or an entire bundled TE link, the PathErr message
PathErr message may contain either an [RFC2205] format ERROR_SPEC may contain either an [RFC2205] format ERROR_SPEC object or an IF_ID
object, or an IF_ID [RFC3473] format ERROR_SPEC object. In either [RFC3473] format ERROR_SPEC object. In either case, it is the
case, it is the address and TLVs carried by the ERROR_SPEC object address and TLVs carried by the ERROR_SPEC object and not the error
and not the error value that indicates the resource that is to be value that indicate the resource that is to be gracefully shut down.
gracefully shut down.
MPLS TE Link Bundling [RFC4201] requires that an TE 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
shutdown of unbundled TE link or entire bundled TE link. unbundled TE link or entire bundled TE link. Specifically, in the
Specifically, in the former case, when only a subset of component former case, when only a subset of component links and not the entire
links and not the entire bundled TE link is being shutdown, the bundled TE link is being shut down, the remaining component links of
remaining component links of the bundled TE link may still be the bundled TE link may still be able to admit new TE LSPs. The node
able to admit new TE LSPs. The node where graceful shutdown of a where graceful shutdown of a component link is desired triggers a
component link is desired triggers a PathErr message with the PathErr message with the error code "Notify" and error value of
error code "Notify" and error value of "Local link maintenance "Local link maintenance required". The rest of the ERROR_SPEC object
required". The rest of the ERROR_SPEC object is constructed using is constructed using Component Reroute Request procedure defined in
Component Reroute Request procedure defined in [RFC5710]. [RFC5710].
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".
required". The rest of the ERROR_SPEC object is constructed using The rest of the ERROR_SPEC object is constructed using the Label
Label Reroute Request procedure defined in [RFC5710]. Reroute Request procedure defined in [RFC5710].
When a head-end node, a transit node or a border node receives a When a head-end node, a transit node, or a border node receives a
PathErr message with the error code "Notify" and error value PathErr message with the error code "Notify" and error value "Local
"Local link maintenance required" or "Local node maintenance link maintenance required" or "Local node maintenance required", it
required", it follows the procedures defined in [RFC5710] to follows the procedures defined in [RFC5710] to reroute the traffic
reroute the traffic around the resource being gracefully around the resource being gracefully shut down. When performing path
shutdown. When performing path computation for the new TE LSP, computation for the new TE LSP, the head-end node or border node
the head-end node, or border node avoids using the TE resources avoids using the TE resources identified by the ERROR_SPEC object.
identified by the ERROR_SPEC object. If PCE is used for path If the PCE is used for path computation, the head-end (or border)
computation, head-end (or border) node acting as PCC specifies in node acting as PCC specifies in its requests to the PCE that path
its requests to the PCE that path computation should avoid the computation should avoid the resource being gracefully shut down.
resource being gracefully shutdown. The amount of time the head- The amount of time the head-end node or border node avoids using the
end node, or border node avoids using the TE resources identified TE resources identified by the IP address contained in the PathErr is
by the IP address contained in the PathErr is based on a local based on a local decision at that node.
decision at head-end node or border node.
If the node initiating the graceful shutdown procedure receives a If the node initiating the graceful shutdown procedure receives a
path setup request for a new tunnel using resource being path setup request for a new tunnel-using resource being gracefully
gracefully shutdown, it sends a Path Error message with "Notify" shut down, it sends a PathErr message with "Notify" error code in the
error code in the ERROR SPEC object and an error value consistent ERROR SPEC object and an error value consistent with the type of
with the type of resource being gracefully shut down. However, resource being gracefully shut down. However, based on a local
based on a local decision, if an existing tunnel continues to use decision, if an existing tunnel continues to use the resource being
the resource being gracefully shutdown, the node initiating the gracefully shut down, the node initiating the graceful shutdown
graceful shutdown procedure may allow resource being gracefully procedure may allow that resource being gracefully shut down to be
shutdown to be used as a "last resort". The node initiating the used as a "last resort". The node initiating the graceful shutdown
graceful shutdown procedure can distinguish between new and procedure can distinguish between new and existing tunnels by
existing tunnels by inspecting the SENDER TEMPLATE and SESSION inspecting the SENDER TEMPLATE and SESSION objects.
objects.
If the resource being shut down is a last resort resource, it
can be used, i.e., based on a local decision the node initiating
the graceful shutdown procedure can cancel the shutdown operation.
Similarly, based on a local decision the node initiating
the graceful shutdown procedure can delay the actual removal of
resource for forwarding. This is to give time to network to move
traffic from the resource being shutdown. For this purpose, the
node initiating graceful shutdown procedure follows the Reroute
Request Timeout procedure defined in [RFC5710].
5. Manageability Considerations
When a TE link is being showdown, a linkDown trap as defined in If the resource being shut down is a last-resort resource, it can be
[RFC2863] should be generated for the TE link. Similarly, if a used; i.e., based on a local decision, the node initiating the
bundled TE links is being showdown, a linkDown trap as defined graceful shutdown procedure can cancel the shutdown operation.
in [RFC2863] should be generated for the bundled TE link, as well Similarly, based on a local decision, the node initiating the
as for each of its component links. If a TE node is being graceful shutdown procedure can delay the actual removal of resource
shutdown, a linkDown trap as defined in [RFC2863] should be for forwarding. This is to give time to the network to move traffic
generated for all TE links at the node. from the resource being shut down. For this purpose, the node
initiating graceful shutdown procedure follows the Reroute Request
Timeout procedure defined in [RFC5710].
6. Security Considerations 5. Manageability Considerations
This document introduces no new security considerations as this When a TE link is being shut down, a linkDown trap as defined in
document describes usage of existing formats and mechanisms. This [RFC2863] should be generated for the TE link. Similarly, if a
document relies on existing procedures for advertisement of TE bundled TE link is being shut down, a linkDown trap as defined in
LSA/ISIS-LSP containing Link TLV. Tampering with TE LSAs/ISIS- [RFC2863] should be generated for the bundled TE link, as well as for
LSPs may have an effect on traffic engineering computations, and each of its component links. If a TE node is being shut down, a
it is suggested that any mechanisms used for securing the linkDown trap as defined in [RFC2863] should be generated for all TE
transmission of normal LSAs/ISIS-LSPs be applied equally to all links at the node.
Opaque LSAs/ISIS-LSPs this document uses. Existing security
considerations specified in [RFC3630], [RFC5305], [RFC4203],
[RFC5307] and [MPLS-GMPLS-SECURITY] remain relevant and suffice.
Furthermore, security considerations section in [RFC5710] and
section 9 of [RFC4736] should be used for understanding the
security considerations related to the formats and mechanisms
used in this document.
7. IANA Considerations 6. Security Considerations
This document has no IANA actions. This document introduces no new security considerations as it
describes usage of existing formats and mechanisms. This document
relies on existing procedures for advertisement of TE LSA / IS-IS-
LSPs containing Link TLVs. Tampering with TE LSAs / IS-IS-LSPs may
have an effect on traffic engineering computations, and it is
suggested that any mechanisms used for securing the transmission of
normal LSAs / IS-IS-LSPs be applied equally to all Opaque LSAs / IS-
IS-LSPs that this document uses. Existing security considerations
specified in [RFC3630], [RFC5305], [RFC4203], [RFC5307], and
[MPLS-GMPLS-SEC] remain relevant and suffice. Furthermore, the
Security Considerations section in [RFC5710] and section 9 of
[RFC4736] should be used for understanding the security
considerations related to the formats and mechanisms used in this
document.
8. 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
acknowledge useful comments from David Ward, Sami Boutros, and useful comments from David Ward, Sami Boutros, and Dimitri
Dimitri Papadimitriou. Papadimitriou.
9. Reference 8. References
9.1 Normative Reference 8.1. Normative References
[RFC2205] Braden, R. Ed. et al, "Resource ReSerVation Protocol [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,
(RSVP) Version 1, Functional Specification", RFC 2205. and S. Jamin, "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC5710] Berger, L., Papadimitriou, D., and J. Vasseur, [RFC5710] Berger, L., Papadimitriou, D., and JP. Vasseur,
"PathErr Message Triggered MPLS and GMPLS LSP Reroute", "PathErr Message Triggered MPLS and GMPLS LSP
RFC5710. Reroutes", RFC 5710, January 2010.
9.2 Informative Reference 8.2. Informative References
[RFC3209] Awduche D., Berger, L., Gan, D., Li T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions
3209. to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC4736] Jean-Philippe Vasseur, et al "Reoptimization of MPLS [RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang,
Traffic Engineering loosely routed LSP paths", RFC 4736. "Reoptimization of Multiprotocol Label Switching
(MPLS) Traffic Engineering (TE) Loosely Routed Label
Switched Path (LSP)", RFC 4736, November 2006.
[RFC3630] Katz D., Kompella K., Yeung D., "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
(TE) Extensions to OSPF Version 2", RFC 3630. Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[RFC5305] Smit, H. and T. Li, "Intermediate System to [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Intermediate System (IS-IS) Extensions for Traffic Engineering Engineering", RFC 5305, October 2008.
(TE)", RFC 5305.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
Extensions in Support of Generalized Multi-Protocol Label Extensions in Support of Generalized Multi-Protocol
Switching (GMPLS)", RFC 4203. Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS
System to Intermediate System (IS-IS) Extensions in Support of Extensions in Support of Generalized Multi-Protocol
Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307. Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471. Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Switching (GMPLS) Signaling Resource ReserVation
Engineering (RSVP-TE) Extensions", RFC 3473. Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC4726] Farrel A, Vasseur, J.-P., Ayyangar A., "A Framework for [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
Inter-Domain MPLS Traffic Engineering", RFC 4726, November 2006. Framework for Inter-Domain Multiprotocol Label
Switching Traffic Engineering", RFC 4726, November
2006.
[RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link
in MPLS Traffic Engineering", RFC 4201. Bundling in MPLS Traffic Engineering (TE)", RFC
4201, October 2005.
[RFC4206] Kompella K., Rekhter Y., "Label Switched Paths (LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) (LSP) Hierarchy with Generalized Multi-Protocol
Traffic Engineering (TE)", RFC 4206. Label Switching (GMPLS) Traffic Engineering (TE)",
RFC 4206, October 2005.
[RFC4655] A. Farrel, J.-P. Vasseur, J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Element (PCE)-Based Architecture", RFC 4655. Computation Element (PCE)-Based Architecture", RFC
4655, August 2006.
[RFC2863] McCloghrie K., Kastenholz F., "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces
MIB", RFC 2863. Group MIB", RFC 2863, June 2000.
[MPLS-GMPLS-SECURITY] Luyuan F., Ed. "Security Framework for [MPLS-GMPLS-SEC] Luyuan F., Ed., "Security Framework for PLS and
MPLS and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls- GMPLS Networks", Work in Progress, March 2010.
security-framework, work in progress.
10. Authors' Address: Authors' Addresses
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
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough , MA - 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com EMail: jpv@cisco.com
Anca Zamfir Anca Zamfir
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada Canada
Email: ancaz@cisco.com EMail: ancaz@cisco.com
Jonathan Newton Jonathan Newton
Cable and Wireless Cable and Wireless
jonathan.newton@cw.com EMail: jonathan.newton@cw.com
 End of changes. 88 change blocks. 
354 lines changed or deleted 337 lines changed or added

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