NetworkingCCAMP Working Group Internet Draft Zafar Ali Jean-Philippe Vasseur Anca Zamfir Cisco Systems, Inc. Jonathan Newton Cable and Wireless Category:Intended status: Informational Expires:July 03, 2008 Expires: January 2008 draft-ietf-ccamp-mpls-graceful-shutdown-05.txt02, 2009 draft-ietf-ccamp-mpls-graceful-shutdown-06.txt Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 2008.January 02, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). draft-ietf-ccamp-mpls-graceful-shutdown-05.txtdraft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 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 reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS and its Generalized MPLS (GMPLS) extensions. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119].Table of Contents 1. Terminology.....................................................3Introduction................................................2 2. Introduction....................................................3Terminology.................................................3 3. Requirements for Graceful Shutdown..............................4Shutdown..........................4 4. Mechanisms for Graceful Shutdown................................5Shutdown............................5 4.1 OSPF/ ISIS Mechanisms for graceful shutdown....................5 4.1.1 Graceful Shutdown of TE link(s)..............................5 4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link .5 4.1.3 Graceful Shutdown of TE Node.................................6 4.1.4 Graceful Shutdown of Label Resource..........................6shutdown................5 4.2 RSVP-TE Signaling MechanismMechanisms for graceful shutdown..............6 4.2.1 Graceful Shutdown of TE link(s)..............................6 4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link .7 4.2.3 Graceful Shutdown of TE Node.................................8 4.2.2 Graceful Shutdown of a Label Resource........................8shutdown.........6 5. Security Considerations.........................................8Considerations.....................................8 6. IANA Considerations.............................................9Considerations.........................................8 7. Acknowledgments.................................................9Acknowledgments.............................................8 8. Reference.......................................................9Reference...................................................8 8.1 Normative Reference............................................9Reference........................................8 8.2 Informative Reference..........................................9Reference......................................9 9. Authors' Address:..............................................10Address:..........................................10 10. Intellectual Property Considerations..........................10Considerations......................10 11. Disclaimer of Validity........................................11Validity....................................11 12. Copyright Statement...........................................11 draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07Statement.......................................11 1. Terminology LSR (Label Switching Router): The terms node and LSR are used interchangeably in this document. GMPLS: The term GMPLS is used in this document to refer to packet MPLS-TE, as well as GMPLS extensions to MPLS-TE. LSP: An MPLS-TE/ GMPLS-TE Label Switched Path. Head-end node: Ingress LSR that initiated signaling for the Path. Border node: Ingress LSR of an LSP segment (S-LSP). Path Computation Element (PCE): An entity that computes the routes on behalf of its clients (PCC). TE Link: The term TE link refers to single or a bundle of physical link(s) or FA-LSP(s) on which traffic engineering is enabled [RFC4206], [RFC4201]. 2.Introduction When outages in a network are planned (e.g. for maintenance purpose), some mechanisms can be used to avoid traffic disruption. This is in contrast with unplanned network element failure, where traffic disruption can be minimized thanks to recovery mechanisms but may not be avoided. Hence, a Service Provider may desire to gracefully (temporarily or definitely)indefinitely) remove a TE Link, a group of TE Links or an entire node for administrative reasons such as link maintenance, software/hardware upgrade at a node or significant TE configuration changes. In all these cases, the goal is to minimize the impact on the GMPLStraffic engineered flowscarried over TE LSPs in the network by triggering notifications so as to gracefully reroute draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 such flows before the administrative procedures are started. These operations are equally applicable to both MPLS and its Generalized MPLS (GMPLS) extensions. Graceful shutdown of a resource may require several steps. These steps can be broadly divided into two sets: disabling the resource in the control plane and removing the resource for forwarding. The node initiating the graceful shutdown condition SHOULDis expected to introduce a delay between disabling the resource in the control plane and removing the resource for forwarding. This is to allow the control plane to gracefully divert the traffic away from the resource being gracefully shutdown. The trigger for the graceful shutdown event is a local matter at the node initiating the graceful shutdown. Typically, graceful shutdown is triggered for administrative reasons, such as link maintenance or software/hardware upgrade. draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07This document describes the mechanisms that can be used to gracefully shutdown MPLS/ GMPLS Traffic Engineering on a resource. As mentioned earlier, the graceful shutdown of the Traffic Engineering capability on a resource could be incorporated in the shutdown operation of an interface, but it is a separate step that is taken before the IGP on the link is brought down and before the interface is brought down at different layers. This document only addresses TE nodes and TE resources. 3. Requirements for Graceful Shutdown This section lists the requirements for graceful shutdown2. Terminology LSR - Label Switching Router. The terms node and LSR are used interchangeably in the context ofthis document. GMPLS Traffic Engineering.- Graceful shutdown must address graceful removal of one TE link, one component link within a bundled TE link, a set of TE links, a set of component links or an entire node.- Once an operator has initiatedThe term GMPLS is used in this document to refer to packet MPLS-TE, as well as GMPLS extensions to MPLS-TE. LSP - An MPLS-TE/ GMPLS-TE Label Switched Path. Head-end node: Ingress LSR that initiated signaling for the Path. Border node: Ingress LSR of an LSP segment (S-LSP). Path Computation Element (PCE): An entity that computes the routes on behalf of its clients (PCC). TE Link - - The term TE link refers to single or a bundle of physical link(s) or FA-LSP(s) on which traffic engineering is enabled [RFC4206], [RFC4201]. Last resort resource: If a path to a destination from a given head-end node cannot be found upon removal of a resource (e.g., draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 TE link, TE node), the resource is called last resort to reach that destination from the given head-end node. 3. Requirements for Graceful Shutdown This section lists the requirements for graceful shutdown in the context of GMPLS Traffic Engineering. - Graceful shutdown is required to address graceful removal of one TE link, one component link within a bundled TE link, a set of TE links, a set of component links, label resource(s) or an entire node. - Once an operator has initiated graceful shutdown of a network resource, no new TE LSPs may be set up that use the resource. Any signaling message for a new LSP that explicitly specifies the resource, or that would require the use of the resource due to local constraints, mustis required to be rejected as if the resource were unavailable. - It is desirable for new LSP setup attempts that would be rejected because of graceful shutdown of a resource (as described in the previous requirement) to avoid any attempt to use the resource by selecting an alternate route or other resources. - If the resource being shutdown is a last resort, it can be used. Time or decision for removal of the resource being shutdown is based on a local decision at the node initiating the graceful shutdown procedure. - It is required to give the ingress node the opportunity to take actions in order to reduce/eliminate traffic disruption on the LSP(s) that are using the network resources which are about to be shutdown. - Graceful shutdown mechanisms are equally applicable to intra- domain and TE LSPs spanning multiple domains. Here, a domain is defined as either an IGP area or an Autonomous System [RFC4726]. - Graceful shutdown is equally applicable to GMPLS-TE, as well as packet-based (MPLS) TE LSPs. - In order to make rerouting effective, it is required that when a node initiates the graceful shutdown of a resource, it draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07identifies to all other network nodes the TE resource under graceful shutdown. - Depending on switching technology, it may be possible to shutdown a label resource, e.g., shutting down a lambda in a Lambda Switch Capable (LSC) node. draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 4. Mechanisms for Graceful Shutdown An IGP only basedsolution isbased on [RFC3630], [RFC3784], [RFC4203] and [RFC4205] are not applicable when dealing with Inter-area and Inter-AS traffic engineering, as IGP LSA/LSP flooding is restricted to IGP areas/levels. Consequently, RSVP based mechanisms are required to cope with TE LSPs spanning multiple domains. At the same time, RSVP mechanisms only convey the information for the transiting LSPs to the router along the upstream Path and not to all nodes in the network. Furthermore, it must be noted thatgraceful shutdown notification via IGP flooding is required to discourage a node from establishing new LSPs through the resources being shutdown. In the following sections the complementary mechanisms for RSVP-TE and IGP for Graceful Shutdown are described. A node where a link or the whole node is being shutdown SHOULDmay first trigger the IGP updates as described in Section 4.1, introduce a delay to allow network convergence and only then use the signaling mechanism described in Section 4.2. 4.1 OSPF/ ISIS Mechanisms for graceful shutdown The procedures provided in this section are equally applicable to OSPF and ISIS. 4.1.1 Graceful ShutdownOSPF and ISIS procedure for graceful shutdown of TE link(s) Theis similar to graceful restart of OSPF and ISIS as described in [RFC4203] and [RFC4205], respectively. Specifically, the node where graceful-shutdown of a link is desired MUST originateoriginates the TE LSA/LSP containing Link TLV for the link under graceful shutdown with Traffic Engineering metric set to 0xffffffff, 0 as unreserved bandwidth, and if the link has LSC or FSC as its Switching Capability then also with 0 as Max LSP Bandwidth. A node MAYmay also specify a value for Minimum LSP bandwidth which is greater than the available bandwidth. This would discourage new LSP establishment through the link under graceful shutdown. Neighbors of the node whereIf graceful shutdown procedure is in progress SHOULD continue to advertiseperformed for a component link within a TE Link bundle and it is not the actual unreserved bandwidth oflast component link available within the TE links fromlink, the link attributes associated with the neighbors to that node, without any routing adjacency change. 4.1.2 Graceful Shutdown of Component Link(s) in a BundledTE Link draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07link are recomputed. Similarly, If graceful shutdown procedure is performed foron a component linklabel resource within a TE Link bundle and it is not the last component link available within the TE link,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 shutdown, the routing procedure outlined in Section 4.2.1related to TE link removal is used. 4.1.3 Graceful Shutdowndraft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 Neighbors of the node where graceful shutdown procedure is in progress continues to advertise the actual unreserved bandwidth of the TE Nodelinks from the neighbors to that node, without any routing adjacency change. When graceful shutdown at node level is desired, the node in question follows the procedure specified in the previous section for all TE Links. 4.1.4 Graceful Shutdown of Label Resource If 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 label resource results in a significant change event, a new LSA is originated with the new traffic parameters.4.2 RSVP-TE Signaling MechanismMechanisms for graceful shutdown As discussed in Section 3, one of the requirements for the signaling mechanism for graceful shutdown is to carry information about the resource under graceful shutdown. The Graceful Shutdown mechanism outlined in the following section,section uses PathErr and where available, Notify message,in order to achieve this requirement. These mechanisms apply to both existing and new LSPs. 4.2.1 Graceful Shutdown of TE link(s)The node where graceful shutdown of aan unbundled link or a set of linksan entire bundled TE link is desired MUST triggertriggers a PathErr message with the error code "Notify" and an error value of "Local link maintenance required" for all affected LSPs. The "Notify" error code is defined in [RFC3209] whileSimilarly, the "local link maintenance required" error valuenode that is defined in [RFC4736]. The PathErr message SHOULD include the ERROR_SPEC object containing IP address of the TE Linkbeing gracefully shutdown. If TE link is unnumbered, theshutdown triggers a PathErr message SHOULD includewith the ERROR_SPEC object containing unnumbered IDerror code "Notify" and TE router IDan error value of "Local node maintenance required" for the TE Link being gracefully shutdown. If available, and where notify requests were included when the LSPs were initially setup, Notify message (as defined in RFC 3471, RFC 3473) MAY also be used for delivery of this information to the head-end node, border node or PCE. draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07 When a graceful shutdown operation is performed along the path of a protected LSP, based on a local decision, the PLR or branch node MAY redirect the traffic onto the local detour or protecting segment. In all cases, the PLR or branch node MUST forward the PathErr to the head-end node, border node, or PCE. When a head-end node, border node, or PCE receives a PathErr (or Notify) message with error value of " Local link maintenance required", it MAY trigger a make-before-break procedure. When performing path computation for the new LSP, the head-end node, border node, or PCE SHOULD avoid using the TE resources identified by the IP address contained in the PathErr (or Notify message) 4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link MPLSall LSPs. MPLS TE Link Bundling [RFC4201] requires that an LSP is pinned down to component link(s). Hence, whena component link is shutdown, the TE LSPs affected by this action need to be resignaled. Gracefullink(s). Consequently, graceful shutdown of a component link in a bundled TE link differs from graceful shutdown of unbundled TE link or entire bundled TE link. Specifically, in the former case, when only a subset of component links and not the entire TE bundled link is being shutdown, the remaining component links of the bundled TE link may still be able to admit new LSPs. The node where graceful shutdown of a component link is desired MUST triggertriggers a PathErr message with the error code "Notify" and the new error value of "Local component link maintenance required" for all affected LSPs. The "Notify" error code is defined in [RFC3209] while the "local component link maintenance required" error value is introduced by this proposal: 12 (TBA) Local component link maintenance required Error value for "Local component link maintenance required" is to be assigned by IANA. ThePathErr message should includeincludes in the ERROR_SPEC the TE Link ID address. If the last component link is being shutdown, theprocedure for gracefully shutdown entire bundled TE link outlined in Section 4.2.1above is used. Whenbe used, instead. If graceful shutdown of a label resource is desired, the node initiating this action triggers a head-end node, border node, or PCE receives an RSVPPathErr or Notifymessage with the error code "Notify" and the new error value "local component linkof "Local label resource maintenance required" Flag set, it MAY immediately perform a make-before-break to avoid traffic loss. The head-end node, border node, or PCE MAY still use the IP address contained infor the affected LSP. The PathErr or Notifymessage includes in performing path computation for reroutingthe LSP. This is because, this address is an IP address ofERROR_SPEC the TE link andLink ID address. The "Notify" error code for the flagERROR SPEC object is an implicit indication thatdefined in [RFC3209]. The "local link maintenance required" and "local node maintenance required" error value for the TE draft-ietf-ccamp-mpls-graceful-shutdown-05.txt"Notify" error code are draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 link may still have capacity to admit new LSPs. However, if the ERO is computed such that it also provides details ofdefined in [RFC4736]. This document defines following two error value for the "Notify" error code: 12 (TBA) Local component link selection(s) alongmaintenance required 13 (TBA) Local label resource maintenance required The PathErr message includes in the Path,ERROR_SPEC the TE Link ID address. If unbundled TE link, component link previously selected MAY be avoided. 4.2.3 Graceful Shutdownof a bundled TE Node The node thatlink, entire bundled TE link, or label resource of a TE link is being gracefully shutdown MUST trigger ashutdown, the PathErr message withincludes the error code "Notify" and an error valueERROR_SPEC object containing IP address of "Localthe TE Link being gracefully shutdown. If TE link is unnumbered, the PathErr message includes the ERROR_SPEC object containing unnumbered ID and TE node maintenance required"ID for all LSPs. The "Notify" error code is defined in [RFC3209] whilethe "localTE Link being gracefully shutdown. Similarly, if the TE node maintenance required" error valueis defined in [RFC4736]. Thebeing gracefully shutdown, the PathErr message should includeincludes in the ERROR_SPEC object the MPLS-TE Nodenode ID address 4.2.2 Graceful Shutdown ofaddress. When a Label Resource Thehead-end node, or border node where graceful shutdown of a label resource is desired MUST triggerreceives a PathErr message with the"Notify" error code "Notify"and the newerror value of "Local component"local link maintenance required" for the affected LSP. The "Notify" error code is defined in [RFC3209] while theor "local node maintenance required", or "local component link maintenance required", or "local label resource maintenance required" error value is introduced by this proposal: 13 (TBA) Local label resource maintenance required Error valueit triggers a make-before-break procedure. When performing path computation for "Local label resource maintenance required" is to be assigned by IANA. The PathErr message should include inthe ERROR_SPECnew LSP, the TE Link ID address. Ifhead-end node, or border node avoids using the last component link is being shutdown,TE resources identified by the procedure outlinedIP address contained in Section 4.2.1the PathErr. If PCE is used. When aused for path computation, head-end node,node or border node acts as PCC to request the PCE via PCEP for path computation avoiding resource being gracefully shutdown. The amount of time the head- end node, or PCE receives an RSVPborder node avoid using the TE resources identified by the IP address contained in the PathErr is based on a local decision at head-end node or Notifyborder node. If node initiating the graceful shutdown procedure received path setup request for a new tunnel using resource being gracefully shutdown, it sends a Path Error message with "Notify" error code in the ERROR SPEC object and an error value "local labelconsistent with the type of resource maintenance required" Flag set, it MAY immediately performbeing gracefully shutdown. However, based on a make-before-breaklocal decision, if node initiating the graceful shutdown procedure received path setup request for an existing tunnel, it may allow signaling for it. This is to avoid traffic loss.allow resource being gracefully shutdown as a "last resort". The head-end node, border node,node initiating the graceful shutdown procedure can distinguish between new and existing tunnels based on the tunnel ID in the SESSION object. Time or PCE MAY still usedecision for removal of the resource being shutdown from forwarding is based on a local decision at the node initiating the graceful shutdown procedure. draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 5. Security Considerations This document introduces two new error values for "Notify" error code of the IP address containedERROR SPEC object defined in the PathErr or Notify message[RFC3209]. The procedure in performing path computation for rerouting the LSP. This is because,this address is an IP addressdocument also uses two error values for "Notify" error code of the TE link andERROR SPEC object already defined in [RFC4736]. This document also introduces ways to make resources unavailable for the flagcontrol plane. It is an implicit indicationtherefore recommended that procedures in [RFC2747], which provides mechanisms to protect against external agents compromising the TE link may still have capacityRSVP signaling state in an RSVP agent, be used. Specifically, [RFC2747] mechanisms provide some degree of protection to admit new LSPs. 5. Security Considerations This document introduces nothe head-end node or border node RSVP agent against making resources unavailable for control plan from an external agent sending Path Error messages with existing or new error code and error values. In summary, existing security considerations beyond those already addressed forspecified in [RFC2747], [RFC2205], [RFC3209], [RFC4736], [RFC3471], [RFC3473] and [MPLS-GMPLS-SECURITY] remain relevant and suffice. This document relies on existing RSVP PathErr or Notify messages, orprocedures for advertisement of TE LSA/LSP containing Link TLV. In this regard,Tampering with TE LSAs may have an effect on traffic engineering computations, and it is suggested that any mechanisms used for securing the transmission of normal OSPF LSAs/ ISIS LSPs be applied equally to all Opaque LSAs/ LSPs this document uses. In summary, existing security considerations specified in [RFC2205], [RFC3209][RFC3630], [RFC3784], [RFC4203], [RFC4205] and [MPLS-GMPLS-SECURITY] remain relevant. draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07relevant and suffice. 6. IANA Considerations The following assignment is required in the "Notify" subsection of "Error Codes and Values" section of the "RSVP PARAMETERS" registry (located at http://www.iana.org/assignments/rsvp- parameters): 12 (TBA) - "Local component link maintenance required" flag. 13 (TBA) Local label resource maintenance required. 7. Acknowledgments The authors would like to thank Adrian Farrel for his detailed comments and suggestions. The authors would also like to acknowledge useful comments from David Ward, Sami Boutros, and Dimitri Papadimitriou. 8. Reference 8.1 Normative Reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC3209] D. Awduche, L.Awduche D., Berger, D.L., Gan, T. Li, V.D., Li T., Srinivasan, and G.V., Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 [RFC4736] Jean-Philippe Vasseur, et al "Reoptimization of MPLS Traffic Engineering loosely routed LSP paths", RFC 4736.4736, November 2006. 8.2 Informative Reference [RFC3630] Katz D., Kompella K., Yeung D., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005. [RFC2205] Braden, R. Ed. et al, "Resource ReSerVation Protocol (RSVP) Version 1, Functional Specification", RFC 2205, December 1997. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4726] Adrian Farrel, Jean-PhilippeFarrel A, Vasseur, Arthi Ayyangar,J.-P., Ayyangar A., "A Framework for Inter-Domain MPLS Traffic Engineering", RFC 4726.4726, November 2006. [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS Traffic Engineering", RFC 4201.4201, October 2005. [RFC4206] LabelKompella K., Rekhter Y., "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE),(TE)", RFC 4206, October 2005. [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 4206.2747, January 2000. [MPLS-GMPLS-SECURITY] Fang, L. et al, "Security Framework for MPLS and GMPLS Networks", draft-fang-mpls-gmpls-security-framework- 00.txt,draft-fang-mpls-gmpls-security- framework-01.txt, work in progress. draft-ietf-ccamp-mpls-graceful-shutdown-05.txtdraft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 9. Authors' Address: Zafar Ali Cisco systems, Inc., 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada. Email: email@example.com Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: firstname.lastname@example.org Anca Zamfir Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada Email: email@example.com Jonathan Newton Cable and Wireless firstname.lastname@example.org 10. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. draft-ietf-ccamp-mpls-graceful-shutdown-05.txtdraft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07 11. Disclaimer of Validity This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 12. Copyright Statement Copyright (C) The IETF Trust (2007).(2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.