Network Working Group Ina Minei INTERNET DRAFT Rahul Aggarwal Expiration Date:August 2004April 2005 Juniper Networks Albert Tian Redback Networks Vasile Radoaca Nortel Networks, Inc. Jason Rusmisel Alcatel LDP graceful restart for planned outagesdraft-minei-mpls-ldp-planned-restart-00.txtdraft-minei-mpls-ldp-planned-restart-01.txt Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. 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"work inprogress.''progress." The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txthttp://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society 2003. All Rights Reserved.http://www.ietf.org/shadow.html 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 (asoppossedopposed 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]. 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. LDPFrom a functionality point of view, the extensionsA new Optional Parameter is defined for usedescribed innotification messages. Optional Parameter Type Length Value GR Data TLV TBD 16 see below The typethis document add the capability to do controlled shutdown and restart of theGR(Graceful Restart) Data TLVcontrol plane described in [RFC3479], to LSRs running the graceful restart procedures described in [RFC3478]. This capability is attractive to network operators since: a) it allows in- service software upgrades for networks where graceful restart is notyet assigned, but will be such thatpart of theU-bit is 1normal operation mode andthe F-bit is 0. Thus, an LSR receiving this TLVb) it allows network operators to gain experience andwhich doesn't support it, will simply ignore the TLV, but process the message that carried it.confidence with graceful restart in a controlled environment. 2. LDP extensions Thevalue field of the GR Data TLV contains anFT Session TLVasdefined in RFC3479. The values filled3479 is added as an Optional Parameter for use inthenotification messages. The FT Session TLVfollow the requirements from RFC 3478. The GR Data optional parameter will only show upis used in notification messages with Shutdown Status Code. By virtue of the settings of the U and F bits in theGR DataFT Session TLV, an LSR receiving a shutdown notification with the optionalGR DataFT Session TLV parameter, which does not support it, will ignore theGR DataFT Session TLVparamterparameter but process the notification. The values filled in the FT Session TLV follow the requirements from RFC 3478. A new flag P is defined for use in the FT Session TLV that is exchanged in the initialization message. The new flag is part of the "Flags" field of the FT Session TLV and is used to indicate whether the LSR supports graceful restart for planned outages, as described in this draft. The value of the flag is not yet assigned. The P flag is only used in conjunction with the L flag, when using the FT Session TLV as described in [RFC3478]. Using the P flag, the LSR determines which of its neighbors supports the extensions described in this document. This knowledge is not needed for the correct operation of the extensions described here. However, it brings value from a network operations point of view. Before issuing a planned restart, the network operator will want to verify that all the neighbors of the restarting LSR can provide the behavior described in this document. Thus, the operator can determine if he will get the expected benefits of doing a planned restart. Rather than individually checking all neighbors, the operator can obtain this information from the LSR that is the candidate for planned restart. 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. Both LSRA and LSRB set the P flag in the FT Session TLV that is exchanged at session initialization time, to indicate that they support the extensions described in this document. 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 parameterGR DataFT Session TLV. The valuesfilledin the FT Session TLVincluded in the GR Data TLV MUST be as follows:are: a) the Reconnect TimeisMUST be non-zero and long enough to allow the LDP component on LSRA to reach the stage where it can exchange LDPmessages.messages, b) the Recovery Timeis zero.MUST be zero, and c) The P bit SHOULD be set. The values filled in the FT Session TLV in the initialization message MUST be set as follows: a) the Reconnect Time iszerozero, b) the Recovery Time is set according to whether LSRA could preserve its state after the restart, and c) the P bit is set. 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 parameterGR DataFT Session 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. 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 atinitinitialization time is zero) 4. Security considerations The security considerations pertaining to the original LDP protocol [RFC3036] remain relevant. 5. Intellectual PropertyConsiderations Juniper Networks may have intellectual propertyStatement 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 inregardthis document or the extent tosomewhich 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 specificationcontained incan 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 thisdocument.standard. Please address the information to the IETF at ietf- ipr@ietf.org. 6. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. Additional copyright notices are not permitted in IETF Documents except in the case where such document is the product of a joint development effort between the IETF and another standards development organization or the document is a republication of the work of another standards organization. Such exceptions must be approved on an individual basis by the IAB. 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 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. 7. 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.8. References 8.1. Normative 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)"8.9. Authors' Addresses Ina Minei Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: ina@juniper.netphone: 408.745.2000Rahul Aggarwal Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: rahul@juniper.netphone: 408.745.2000Albert Tian Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 Email: tian@redback.com Vasile Radoaca Nortel Networks 600 Technology Park Drive Billerica, MA 01821 USA Email: vasile@nortelnetworks.com Jason Rusmisel Alcatel 600 March Road, Kanata, Ontario, Canada, K2K 2E6 Email: jason.rusmisel@alcatel.com