draft-ietf-ccamp-mpls-graceful-shutdown-12.txt   draft-ietf-ccamp-mpls-graceful-shutdown-13.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 12
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
Category: Informational Category: Informational
Expires: March 14, 2010 September 15, 2009 Expires: July 19, 2010 January 20, 2010
draft-ietf-ccamp-mpls-graceful-shutdown-12.txt draft-ietf-ccamp-mpls-graceful-shutdown-13.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
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance
the provisions of BCP 78 and BCP 79. This document may contain with the provisions of BCP 78 and BCP 79. This document may
material from IETF Documents or IETF Contributions published or contain material from IETF Documents or IETF Contributions
made publicly available before November 10, 2008. The person(s) published or made publicly available before November 10, 2008.
controlling the copyright in some of this material may not have The person(s) controlling the copyright in some of this material
granted the IETF Trust the right to allow modifications of such may not have granted the IETF Trust the right to allow
material outside the IETF Standards Process. Without obtaining modifications of such material outside the IETF Standards
an adequate license from the person(s) controlling the copyright Process. Without obtaining an adequate license from the
in such materials, this document may not be modified outside the person(s) controlling the copyright in such materials, this
IETF Standards Process, and derivative works of it may not be document may not be modified outside the IETF Standards Process,
created outside the IETF Standards Process, except to format it and derivative works of it may not be created outside the IETF
for publication as an RFC or to translate it into languages other Standards Process, except to format it for publication as an RFC
than English. or to translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet
Task Force (IETF), its areas, and its working groups. Note that Engineering Task Force (IETF), its areas, and its working
other groups may also distribute working documents as Internet- groups. Note that other groups may also distribute working
Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of six
six months and may be updated, replaced, or obsoleted by other 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.
This Internet-Draft will expire on September 08, 2009. This Internet-Draft will expire on July 19, 2010.
Copyright
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
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.
skipping to change at page 2, line 28 skipping to change at page 2, line 43
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.........................................7 5. Manageability Considerations....................................7
6. IANA Considerations.............................................8 6. Security Considerations.........................................8
7. Acknowledgments.................................................8 7. IANA Considerations.............................................8
8. Reference.......................................................8 8. Acknowledgments.................................................8
8.1 Normative Reference...........................................8 9. Reference.......................................................8
8.2 Informative Reference.........................................8 9.1 Normative Reference...........................................8
9. Authors' Address:...............................................9 9.2 Informative Reference.........................................8
10. Copyright Notice..............................................10 10. Authors' Address:..............................................9
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
purposes), 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. Therefore, 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
skipping to change at page 4, line 35 skipping to change at page 4, line 42
Any signaling message for a new TE LSP that explicitly specifies Any signaling message for a new TE LSP that explicitly specifies
the resource, or that would require the use of the resource due the resource, or that would require the use of the resource due
to local constraints, is required to be rejected as if the to local constraints, is required to be rejected as if the
resource were unavailable. resource were unavailable.
- It is desirable for new TE 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 shut down is a last resort resource, it - If the resource being shut down is a last resort resource,
can be used. Time or decision for removal of the resource being based on a local decision, the node initiating the graceful
shut down is based on a local decision at the node initiating the shutdown procedure can cancel the shutdown operation.
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 TE actions in order to reduce/eliminate traffic disruption on the TE
LSPs that are using the network resources which are about to be LSPs that are using the network resources which 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 and TE LSPs spanning multiple domains, as defined in domain and TE LSPs 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.
skipping to change at page 6, line 26 skipping to change at page 6, line 26
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 TE LSP rerouting mechanism as defined in Graceful Shutdown uses TE LSP rerouting mechanism as defined in
[LSP-REROUTE]. [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 that is being gracefully shut down triggers a PathErr node that is being gracefully shut down triggers a PathErr
message with the error code "Notify" and error value "Local node message with the error code "Notify" and error value "Local node
maintenance required", for all TE LSPs. For graceful shutdown of maintenance required", for all TE LSPs. For graceful shutdown of
a 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
skipping to change at page 6, line 53 skipping to change at page 6, line 53
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 bundled TE 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 TE 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 code "Notify" and error value of "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 [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". 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 [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 link maintenance required" or "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 [RFC5710] to
reroute the traffic around the resource being gracefully reroute the traffic around the resource being gracefully
shutdown. When performing path computation for the new TE LSP, shutdown. When performing path computation for the new TE LSP,
the 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 ERROR_SPEC object. If PCE is used for path identified by the ERROR_SPEC object. If PCE is used for path
computation, head-end (or border) node acting as PCC specifies in computation, head-end (or border) node acting as PCC specifies in
its requests to the PCE that path computation should avoid the its requests to the PCE that path computation should avoid the
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 avoids using the TE resources identified end node, or border node avoids 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.
skipping to change at page 7, line 39 skipping to change at page 7, line 39
error code in the ERROR SPEC object and an error value consistent error code in the ERROR SPEC object and an error value consistent
with the type of resource being gracefully shut down. However, with the type of resource being gracefully shut down. However,
based on a local decision, if an existing tunnel continues to use based on a local decision, if an existing tunnel continues to use
the 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 by inspecting the SENDER TEMPLATE and SESSION existing tunnels by inspecting the SENDER TEMPLATE and SESSION
objects. objects.
Time or decision for removal of the resource being shut down from If the resource being shut down is a last resort resource, it
forwarding is based on a local decision at the node initiating can be used, i.e., based on a local decision the node initiating
the graceful shutdown procedure. For this purpose, the node the graceful shutdown procedure can cancel the shutdown operation.
initiating graceful shutdown procedure follows the Reroute Similarly, based on a local decision the node initiating
Request Timeout procedure defined in [LSP-REROUTE]. 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. Security Considerations 5. Manageability Considerations
When a TE link is being showdown, a linkDown trap as defined in
[RFC2863] should be generated for the TE link. Similarly, if a
bundled TE links is being showdown, a linkDown trap as defined
in [RFC2863] should be generated for the bundled TE link, as well
as for each of its component links. If a TE node is being
shutdown, a linkDown trap as defined in [RFC2863] should be
generated for all TE links at the node.
6. 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/ISIS-LSP containing Link TLV. Tampering with TE LSAs/ISIS- LSA/ISIS-LSP containing Link TLV. Tampering with TE LSAs/ISIS-
LSPs may have an effect on traffic engineering computations, and LSPs may have an effect on traffic engineering computations, and
it is suggested that any mechanisms used for securing the it is suggested that any mechanisms used for securing the
transmission of normal LSAs/ISIS-LSPs be applied equally to all transmission of normal LSAs/ISIS-LSPs be applied equally to all
Opaque LSAs/ISIS-LSPs this document uses. Existing security Opaque LSAs/ISIS-LSPs this document uses. Existing security
considerations specified in [RFC3630], [RFC5305], [RFC4203], considerations specified in [RFC3630], [RFC5305], [RFC4203],
[RFC5307] and [MPLS-GMPLS-SECURITY] remain relevant and suffice. [RFC5307] and [MPLS-GMPLS-SECURITY] remain relevant and suffice.
Furthermore, security considerations section in [RFC5710] and
Furthermore, security considerations section in [LSP-REROUTE] and
section 9 of [RFC4736] should be used for understanding the section 9 of [RFC4736] should be used for understanding the
security considerations related to the formats and mechanisms security considerations related to the formats and mechanisms
used in this document. used in this document.
6. IANA Considerations 7. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. Acknowledgments 8. 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 9. Reference
8.1 Normative Reference 9.1 Normative Reference
[RFC2205] Braden, R. Ed. et al, "Resource ReSerVation Protocol [RFC2205] Braden, R. Ed. et al, "Resource ReSerVation Protocol
(RSVP) Version 1, Functional Specification", RFC 2205. (RSVP) Version 1, Functional Specification", RFC 2205.
[LSP-REROUTE] Berger, L., Papadimitriou, D., and J. Vasseur, [RFC5710] Berger, L., Papadimitriou, D., and J. Vasseur,
"PathErr Message Triggered MPLS and GMPLS LSP Reroute", draft- "PathErr Message Triggered MPLS and GMPLS LSP Reroute",
ietf-mpls-gmpls-lsp-reroute (work in progress). RFC5710.
8.2 Informative Reference 9.2 Informative Reference
[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. 3209.
[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. Traffic Engineering loosely routed LSP paths", RFC 4736.
[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. (TE) Extensions to OSPF Version 2", RFC 3630.
skipping to change at page 9, line 25 skipping to change at page 9, line 33
[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 [RFC4655] A. Farrel, J.-P. Vasseur, J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655. Element (PCE)-Based Architecture", RFC 4655.
[MPLS-GMPLS-SECURITY] Luyuan Fang, Ed. "Security Framework for [RFC2863] McCloghrie K., Kastenholz F., "The Interfaces Group
MIB", RFC 2863.
[MPLS-GMPLS-SECURITY] Luyuan F., 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: 10. 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
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
skipping to change at page 10, line 4 skipping to change at line 486
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 jonathan.newton@cw.com
10. Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-
info). Please review these documents carefully, as they describe
your rights and restrictions with respect to this document.
11. Legal
This documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 25 change blocks. 
59 lines changed or deleted 87 lines changed or added

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