Network Working Group Ina Minei INTERNET DRAFT Rahul Aggarwal Expiration Date: August 2004 Juniper Networks Albert Tian Redback Networks LDP graceful restart for planned outages draft-minei-mpls-ldp-planned-restart-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society 2003. All Rights Reserved. Abstract This document proposes an enhancement to the LDP graceful restart procedures defined in RFC 3478. The proposed extension allows operators to apply graceful restart only when the restart is planned (as oppossed to both planned and unplanned restart). 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]. draft-minei-mpls-ldp-planned-restart-00.txt [Page 1] Internet Draft draft-minei-mpls-ldp-planned-restart-00.txt February 2004 1. Introduction Graceful restart assumes that the restarting LSR could preserve its MPLS forwarding state across the restart of its control plane. Under this assumption, RFC 3478 describes the procedures used in order to avoid perturbing the LSPs going through the LSR whose control plane restarted. In a nutshell, to achieve graceful restart, both the behaviour of the restarting LSR (LSRA) and of the neighbor of the restarting LSR (LSRB) is changed. Most importantly for this discussion, LSRB needs to maintain the session with LSRA, and help LSRA recover its state from before the restart. To accomplish this, LSRB needs to know 1) if LSRA is graceful restart capable, 2) what is the upper bound on the time it will take LSRA to reestablish the peering and 3) what is the time that LSRB needs to maintain LSRA's stale state. The graceful restart capabilities and parameters are negotiated in the Fault Tolerant (FT) Session TLV optional parameter in the session initialization message [RFC3479]. Thus, a change in the graceful restart capabilities requires resetting the LDP session, since the new information needs to be signaled in a new initialization message. A control plane restart may be an unplanned event such as a router crash, or a planned event, such as planned downtime. An operator may choose to use graceful restart selectively, for planned restarts only, for example in order to achieve smooth software upgrades. However, if toggling the graceful functionality resets the session, the usefulness of graceful restart in such scenarios is defeated. The proposed extension allows operators to apply graceful restart only when the restart is planned, without having to reset the session first. 2. LDP extensions A new Optional Parameter is defined for use in notification messages. Optional Parameter Type Length Value GR Data TLV TBD 16 see below The type of the GR(Graceful Restart) Data TLV is not yet assigned, but will be such that the U-bit is 1 and the F-bit is 0. Thus, an LSR receiving this TLV and which doesn't support it, will simply ignore the TLV, but process the message that carried it. The value field of the GR Data TLV contains an FT Session TLV as draft-minei-mpls-ldp-planned-restart-00.txt [Page 2] Internet Draft draft-minei-mpls-ldp-planned-restart-00.txt February 2004 defined in RFC 3479. The values filled in the FT Session TLV follow the requirements from RFC 3478. The GR Data optional parameter will only show up in notification messages with Shutdown Status Code. By virtue of the settings of the U and F bits in the GR Data TLV, an LSR receiving a shutdown notification with the optional GR Data TLV parameter, which does not support it, will ignore the GR Data TLV paramter but process the notification. 3. Operation In the discussion below, LSRA is the restarting LSR, and LSRB is the neighbor of LSRA. The goal is for LSRA to do graceful restart only for planned restarts, and do ungraceful restarts in all other cases. 3.1. Changes for the LSR doing a planned restart When performing a planned restart, LSRA MUST send a notification message with Shutdown Status Code and with optional parameter GR Data TLV. The values filled in the FT Session TLV included in the GR Data TLV MUST be as follows: a) the Reconnect Time is non-zero and long enough to allow the LDP component on LSRA to reach the stage where it can exchange LDP messages. b) the Recovery Time is zero. The values filled in the FT Session TLV in the initialization message MUST be set as follows: a) the Reconnect Time is zero b) the Recovery Time is set according to whether LSRA could preserve its state after the restart, 3.2. Changes for the neighbor of the LSR doing a planned restart When the neighbor LSRB receives a notification with Shutdown Status Code and with the optional parameter GR Data TLV, LSRB SHOULD do the following: Read the values in the FT Session TLV and update the graceful restart state for the session as if these values were received in the initialization message. From this point on, LSRB will do the appropriate graceful restart procedures as defined in RFC 3478. The procedures above yield the following behaviour: If the neighbor doesn't support graceful restart helper mode - ungraceful restart will take place. draft-minei-mpls-ldp-planned-restart-00.txt [Page 3] Internet Draft draft-minei-mpls-ldp-planned-restart-00.txt February 2004 If the neighbor supports graceful restart helper mode, then there are two cases: a) the neighbor supports the extensions defined here - graceful restart will be performed, assuming LSRA could maintain its state across the restart. b) the neighbor doesn't support the extensions defined here - ungraceful restart will be performed (since the reconnect time advertised at init time is zero) 4. Security considerations The security considerations pertaining to the original LDP protocol [RFC3036] remain relevant. 5. Intellectual Property Considerations Juniper Networks may have intellectual property rights claimed in regard to some of the specification contained in this document. 6. Acknowledgments This work is the outcome of discussions with Kireeti Kompella, Yakov Rekhter and Arthi Ayyangar. The authors would like to thank them for their suggestions and insight. 7. References [RFC1700] Reynolds, J., Postel, J., "Assigned numbers", RFC 1700, October 1994 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC3036] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP Specification", RFC 3036, January 2001 [RFC3478] Leelanivas M., Rekhter Y., Aggarwal R., "Graceful Restart Mechanism for Label Distribution Protocol" [RFC3479] Farrel A., " Fault Tolerance for the Label Distribution Protocol (LDP)" draft-minei-mpls-ldp-planned-restart-00.txt [Page 4] Internet Draft draft-minei-mpls-ldp-planned-restart-00.txt February 2004 8. Authors' Addresses Ina Minei Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: ina@juniper.net phone: 408.745.2000 Rahul Aggarwal Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: rahul@juniper.net phone: 408.745.2000 Albert Tian Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 Email: tian@redback.com draft-minei-mpls-ldp-planned-restart-00.txt [Page 5]