< draft-ietf-ccamp-mpls-graceful-shutdown-12.txt		draft-ietf-ccamp-mpls-graceful-shutdown-13.txt >
	CCAMP Working Group		CCAMP Working Group
	Internet Draft		Internet Draft
	Zafar Ali		Zafar Ali
	Jean-Philippe Vasseur		Jean-Philippe Vasseur
	Anca Zamfir		Anca Zamfir
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Jonathan Newton		Jonathan Newton
	Cable and Wireless		Cable and Wireless
	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
	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. 26 change blocks.
	60 lines changed or deleted		87 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/