Networking Working Group
Internet Draft
                                                           Zafar Ali
                                               Jean-Philippe Vasseur
                                                         Anca Zamfir
                                                 Cisco Systems, Inc.
                                                     Jonathan Newton
                                                  Cable and Wireless

Category: Informational
           Graceful Shutdown in GMPLS 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 December 07, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

        draft-ietf-ccamp-mpls-graceful-shutdown-03.txt      June

        draft-ietf-ccamp-mpls-graceful-shutdown-04.txt      July 07

   Abstract

   GMPLS-TE

   MPLS-TE Graceful shutdown 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. GMPLS-TE MPLS-TE graceful shutdown
   mechanisms are tailored towards toward addressing the planned outage in the
   network.

   This document provides requirements and protocol mechanisms so as to
   reduce/eliminate traffic disruption in the event of a planned
   shutdown of a network resource. These operations are equally
   applicable for to both MPLS and its GMPLS 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 [i]. [RFC2119].

Table of Contents

1. Terminology.....................................................2 Terminology.....................................................3
2. Introduction....................................................3
3. Requirements for Graceful Shutdown..............................4
4. Mechanisms for Graceful Shutdown................................4 Shutdown................................5
4.1 RSVP-TE Signaling Mechanism OSPF/ ISIS Mechanisms for graceful shutdown............5 shutdown....................5
4.1.1 Graceful Shutdown of TE link(s)............................5 link(s)..............................5
4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 5 .5
4.1.3 Graceful Shutdown of TE Node...............................6 Node.................................6
4.1.4 Graceful Shutdown of Label Resource..........................6
4.2 OSPF/ ISIS Mechanisms RSVP-TE Signaling Mechanism for graceful shutdown..................6 shutdown..............6
4.2.1 Graceful Shutdown of TE link(s)............................6 link(s)..............................6
4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 7 .7
4.2.3 Graceful Shutdown of TE Node...............................7 Node.................................8
4.2.2 Graceful Shutdown of a Label Resource........................8
5. Security Considerations.........................................7 Considerations.........................................8
6. IANA Considerations.............................................7 Considerations.............................................9
7. Acknowledgments.................................................7 Acknowledgments.................................................9
8. Reference.......................................................7 Reference.......................................................9
8.1 Normative Reference..........................................7 Reference............................................9
8.2 Informative Reference........................................8 Reference..........................................9
9. Authors' Address:...............................................8 Address:..............................................10
10. Intellectual Property Considerations...........................8 Considerations..........................10
11. Disclaimer of Validity.........................................9 Validity........................................11
12. Copyright Statement............................................9 Statement...........................................11
        draft-ietf-ccamp-mpls-graceful-shutdown-04.txt      July 07

1. Terminology

   LSR - Label (Label Switching Device.

        draft-ietf-ccamp-mpls-graceful-shutdown-03.txt      June 07

   LSP - 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 MPLS-TE/ GMPLS-TE Label Switched Path Path.

   Head-end or Ingress node: In this document the terms "head-end
   node equally applies to the Ingress node LSR that initiated signaling for the Path or an intermediate node (in the case Path.

   Border node: Ingress LSR of loose hops
   path computation) or a an LSP segment (S-LSP).

   Path Computation Element (PCE) (PCE): An entity that computes the
   routes on behalf of its clients (PCC).

   GMPLS - The term GMPLS is used in this document to refer to both
   classic MPLS, as well as the GMPLS extensions to MPLS.

   TE Link - Link: The term TE link refers to single or a bundle of
   physical link link(s) or an FA-
   LSP, FA-LSP(s) on which traffic engineering is enabled. A TE link can be
   bundled or unbundled.

   The terms node and LSR will be used interchangeably in this
   document.
   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)
   disable Traffic Engineering on
   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 GMPLS traffic engineered flows carried
   over TE LSPs in the network by triggering notifications so as to
   graceful
   gracefully reroute such flows before the administrative
   procedures are started.

   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
   SHOULD introduce a delay between disabling the removal of resource in the resources for forwarding,
   control plane and removing the resource for
   some period determined by local policy. forwarding. This is
   to allow the control plane to gracefully divert the traffic away
   from the resource being gracefully shutdown. Similarly, 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 at a node. upgrade.

        draft-ietf-ccamp-mpls-graceful-shutdown-04.txt      July 07

   This document describes the mechanisms that can be used to
   gracefully shutdown GMPLS Traffic Engineering on a resource. As
   mentioned earlier, the graceful shutdown of the Traffic
        draft-ietf-ccamp-mpls-graceful-shutdown-03.txt      June 07
   Engineering capability on a resource could be incorporated in the
   traditional
   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 node nodes and TE resources.

3. Requirements for Graceful Shutdown

   This section lists the requirements for graceful shutdown in the
   context of 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.

   - It is required to prevent other network nodes to use the Once an operator has initiated graceful shutdown of a network resources that are about to be shutdown, should
   resource, no new TE
   LSP LSPs may be set up. However, if up that use the resource being shutdown is resource.
   Any signaling message for a last
   resort, it can be used. Time new LSP that explicitly specifies the
   resource, or decision for removal that would require the use of the resource being shutdown is based on a due to
   local decision at constraints, must 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 [INTER-
   AREA-AS]. [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-04.txt      July 07

     identifies to
   communicate information about 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.

4. Mechanisms for Graceful Shutdown

   An IGP only based solution is 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 that graceful shutdown notification via IGP
   flooding is required to discourage a node from establishing new
   LSPs through the resources being shutdown. In the following
        draft-ietf-ccamp-mpls-graceful-shutdown-03.txt      June 07
   sections the complementary mechanisms for RSVP-TE and IGP for
   Graceful Shutdown are described.

4.1 RSVP-TE Signaling Mechanism for graceful

   A node where a link or the whole node is being shutdown

   As discussed SHOULD
   first trigger the IGP updates as described in Section 3, one of the requirements for 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 is to carry information
   about the resource under graceful shutdown.

   The Graceful Shutdown
   mechanism outlined in the following section, uses Path Error and
   where available, Notify message, procedures provided in order to achieve this
   requirement. Such mechanisms relying on signaling section are only equally applicable to the existing LSPs.
   Setup request for new LSPs over the TE resource being gracefully
   shutdown SHOULD be rejected using the existing mechanisms that
   are applied when the TE resource is not available.
   OSPF and ISIS.

4.1.1 Graceful Shutdown of TE link(s)

   The node where graceful shutdown graceful-shutdown of a link or a set of links is desired MUST trigger a Path Error message with "local link
   maintenance required" sub-code for all affected LSPs. The "local
   originate the TE link 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 MAY 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 where graceful shutdown procedure is in
   progress SHOULD continue to advertise the actual unreserved
   bandwidth of the TE links from the neighbors to that node,
   without any routing adjacency change.

4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link
        draft-ietf-ccamp-mpls-graceful-shutdown-04.txt      July 07

   If 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. If the removal of the component link
   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.1 is used.

4.1.3 Graceful Shutdown of TE Node

   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 Mechanism 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, 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 a link or a set of links is
   desired MUST trigger 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 [PATH-
   REOPT].
   [RFC3209] while the "local link maintenance required" error value
   is defined in [RFC4736]. The PathErr message SHOULD include the
   ERROR_SPEC object containing IP address of the TE Link being
   gracefully shutdown. If TE link is unnumbered, the PathErr
   message SHOULD include the ERROR_SPEC object containing
   unnumbered ID and TE router ID 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 nodes. node, border node or PCE.

        draft-ietf-ccamp-mpls-graceful-shutdown-04.txt      July 07

   When a GS 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 any case, all cases, the PLR or branch node MUST forward the Path Error
   PathErr to the head-end LSR. node, border node, or PCE.

   When a head-end LSR node, border node, or PCE receives a Path Error PathErr (or
   Notify) message with sub-code "Local Maintenance on TE Link required Flag", error value of " Local link maintenance
   required", it
   SHOULD immediately MAY trigger a make-before-break procedure. A head-
   end node 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) when performing path computation for the new LSP.

   If the resource being gracefully shutdown is on the Path of the
   protecting LSP/ local detour, the branch node/ PLR reroutes the
   protecting LSP/ local detour just a head-end LSR would reroute
   any other LSP.

4.1.2

4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link

   MPLS TE Link Bundling [BUNDLE] [RFC4201] requires that an LSP is pinned
   down to component link(s). Hence, when a component link is
   shutdown, the TE LSPs affected by such maintenance this action needs need to be
   resignaled.

        draft-ietf-ccamp-mpls-graceful-shutdown-03.txt      June 07

   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 links
   link may still be able to admit new LSPs. Consequently
   The node where graceful shutdown of a new component link is desired
   MUST trigger a PathErr message with the error sub- 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 RSVP error-code "Routing Problem" (24) [RSVP-TE] "local component link maintenance
   required" error value is
   needed:

         9 introduced by this proposal:

         12 (TBA)   Local component link maintenance required

   Error Sub-code value for "Local component link maintenance required" is to
   be assigned by IANA.
   The PathErr message should include in the ERROR_SPEC the TE Link
   ID address.

   If the last component link is being shutdown, the procedure
   outlined in Section 5.1 4.2.1 is used.

   When a head-end LSR node, border node, or PCE receives an RSVP Path Error
   PathErr or Notify message with sub-code error value "local component link
   maintenance required" Flag set, it SHOULD MAY immediately perform a
   make-before-break to avoid traffic loss. The head-end LSR node,
   border node, or PCE MAY still use the IP address contained in the Path Error
   PathErr or Notify message in performing path computation for
   rerouting the LSP. This is because, this address
   is an IP address of the component link and the flag is an
   implicit indication that the TE link may still have capacity to
   admit new LSPs. However, if the ERO is computed such that it also
   provides details of the component link selection(s) along the
   Path, the component link selection with IP address contained in
   the Path Error or Notify message SHOULD be avoided.

   Based on a local decision, PLR/ branch node MAY trigger FRR/
   segment recovery to recover from failure of a component link.

4.1.3 Graceful Shutdown of TE Node

   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.2 OSPF/ ISIS Mechanisms for graceful shutdown

   The procedures provided in LSP. This is because, this section are equally applicable to
   OSPF and ISIS.

4.2.1 Graceful Shutdown address is an IP address
   of the TE link(s)

   The node where graceful-shutdown of a link and the flag is desired MUST
   originate an implicit indication that the TE LSA/LSP containing Link TLV for the
        draft-ietf-ccamp-mpls-graceful-shutdown-04.txt      July 07

   link under
   graceful shutdown with Traffic Engineering metric set may still have capacity to
   0xffffffff, 0 as unreserved bandwidth, and admit new LSPs. However, if the link has LSC or
   FSC as its   Switching Capability then
   ERO is computed such that it also with 0 as Max LSP
        draft-ietf-ccamp-mpls-graceful-shutdown-03.txt      June 07

   Bandwidth.  This would discourage new LSP establishment through provides details of the
   component link under graceful shutdown.

   Neighbors of selection(s) along the Path, the component link
   previously selected MAY be avoided.

4.2.3 Graceful Shutdown of TE Node

   The node where graceful that is being gracefully shutdown procedure MUST trigger a PathErr
   message with the error code "Notify" and an error value of "Local
   node maintenance required" for all LSPs. The "Notify" error code
   is defined in
   progress SHOULD continue to advertise [RFC3209] while the actual unreserved
   bandwidth of "local node maintenance
   required" error value is defined in [RFC4736].
   The PathErr message should include in the TE links from ERROR_SPEC object the neighbors to that node,
   without any routing adjacency change.
   MPLS-TE Node ID address

4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link

   If Label Resource

   The node where graceful shutdown procedure is performed for of a component link
   within label resource is desired
   MUST trigger a TE Link bundle PathErr message with the error code "Notify" and it is not
   the last new error value of "Local component link
   available within the TE link, the link attributes associated with
   the TE link are recomputed. If maintenance
   required" for the removal of affected LSP. The "Notify" error code is
   defined in [RFC3209] while the "local component link
   results in a significant bandwidth change event, a new LSA maintenance
   required" error value is
   originated with introduced by this proposal:

         13 (TBA)   Local label resource maintenance required

   Error value for "Local label resource maintenance required" is to
   be assigned by IANA.
   The PathErr message should include in the new traffic parameters. ERROR_SPEC the TE Link
   ID address.

   If the last component link is being shutdown, the routing procedure
   outlined in Section 4.2.1 is used.

4.2.3 Graceful Shutdown of TE Node

   When graceful shutdown at node level is desired, a head-end node, border node, or PCE receives an RSVP
   PathErr or Notify message with error value "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 node IP address contained in
   question follows the procedure specified
   PathErr or Notify message in the previous section performing path computation for all
   rerouting the LSP. This is because, this address is an IP address
   of the TE Links. link and the flag is an implicit indication that the TE
   link may still have capacity to admit new LSPs.

5. Security Considerations

   This document does not introduce introduces no new security issues. The
   security considerations pertaining to the original beyond
   those already addressed for existing RSVP protocol
   [RSVP] PathErr or Notify
   messages, or advertisement of TE LSA/LSP containing Link TLV. In
   this regard, the security considerations specified in [RFC2205],
   [RFC3209] and [MPLS-GMPLS-SECURITY] remain relevant.

        draft-ietf-ccamp-mpls-graceful-shutdown-04.txt      July 07

6. IANA Considerations

   A new error sub-code for Path Error and Notify message
   The following assignment is needed
   for 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, Adrian Farrel and
   Dimitri Papadimitriou.

8. Reference

8.1 Normative Reference

   [RSVP-TE]

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,
   and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
   RFC 3209, December 2001.

   [PATH-REOPT]

   [RFC4736] Jean-Philippe Vasseur, et al "Reoptimization of MPLS
        draft-ietf-ccamp-mpls-graceful-shutdown-03.txt      June 07
   Traffic Engineering loosely routed LSP paths", RFC 4736.

8.2 Informative Reference

   [RSVP]

   [RFC2205] Braden, et al, "Resource ReSerVation Protocol (RSVP) -
   Version 1, Functional Specification", RFC 2205, December 1997.

   [INTER-AREA-AS]

   [RFC4726] Adrian Farrel, Jean-Philippe Vasseur, Arthi Ayyangar,
   "A Framework for Inter-Domain MPLS Traffic Engineering", RFC
   4726.

   [BUNDLE]

   [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling
   in MPLS Traffic Engineering", RFC 4201.

   [RFC4206] Label Switched Paths (LSP) Hierarchy with Generalized
   Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE),
   RFC 4206.

   [MPLS-GMPLS-SECURITY] Fang, et al, "Security Framework for MPLS
   and GMPLS Networks", draft-fang-mpls-gmpls-security-framework-
   00.txt, work in progress.

        draft-ietf-ccamp-mpls-graceful-shutdown-04.txt      July 07

9. Authors' Address:

   Zafar Ali
   Cisco systems, Inc.,
   2000 Innovation Drive
   Kanata, Ontario, K2K 3E8
   Canada.
   Email: zali@cisco.com

   Jean Philippe Vasseur
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough , MA - 01719
   USA
   Email: jpv@cisco.com

   Anca Zamfir
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario, K2K 3E8
   Canada
   Email: ancaz@cisco.com

   Jonathan Newton
   Cable and Wireless
   jonathan.newton@cw.com

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.

        draft-ietf-ccamp-mpls-graceful-shutdown-03.txt      June 07

   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 ietf-ipr@ietf.org.

        draft-ietf-ccamp-mpls-graceful-shutdown-04.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).
   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.