Network Working Group Siva Sivabalan (Ed.) Internet Draft Sami Boutros Intended status: Standards Track Kamran Raza Expires: January 2009 Cisco Systems, Inc., Bob Thomas July 6, 2008 Graceful Shutdown of LDP Adjacency draft-boutros-mpls-ldp-gs-adj-00.txt 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 Sivabalan Expires January 6, 2009 [Page 1] Internet-Draft draft-boutros-mpls-gs-ldp-adj-00.txt July 2008 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 6, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document specifies an extension to Label Distribution Protocol (LDP) using which a Label Switched Router (LSR) can explicitly notify its neighbor LSR its intention to shutdown one or more LDP adjacencies. This extension shall be used to shutdown LDP adjacencies for planned maintenance without interrupting traffic. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................4 3. Graceful Shutdown Mechanism....................................4 4. Graceful Shutdown TLV..........................................5 5. Operation......................................................6 6. Security Considerations........................................7 7. IANA Considerations............................................8 8. Acknowledgments................................................8 9. References.....................................................8 9.1. Normative References......................................8 Author's Addresses................................................8 Intellectual Property Statement...................................9 Disclaimer of Validity...........................................10 Sivabalan Expires January 6, 2009 [Page 2] Internet-Draft draft-boutros-mpls-gs-ldp-adj-00.txt July 2008 1. Introduction In an MPLS network where LDP is used to establish Label Switched Paths (LSPs), there could be more than one LDP-enabled links between a pair of Label Switched Routers (LSRs). In this case, LDP Hello adjacency can be formed over more than one such links between the LSRs, and MPLS traffic can be sent over all links supporting adjacency for load balancing purpose. In case where multiple links exist between a pair of LSRs, an operator may want to gracefully shutdown LDP adjacency(ies) on one or more links (but not all) without bringing down the LDP session between the corresponding LSRs. Such planned shutdown can be required for maintenance purpose. In this context, the word "gracefully" means ceasing to use the specified link(s) for forwarding MPLS traffic with minimal or no traffic loss. It is possible to tweak the IGP metric of the link(s) so that IGP best paths do not include the link(s) from which MPLS traffic is to be diverted. However, this approach moves not only MPLS traffic but also IP traffic thereby causing unnecessary churn in the network. Furthermore, since IGP metric is tweaked, IGP updates must be triggered and advertised throughout the network which also creates unnecessary routing messages. It is also possible that LDP paths are learned via static routing in which case no amount of IGP tweaking would help. Using LDP mechanisms available today, operator could gracefully shutdown one or more LDP sessions on a given LSR. However, such mechanisms cannot be used for gracefully disabling LDP on specific adjacency(ies) between LSRs. In this document, we propose a mechanism to gracefully shutdown Hello adjacency(ies) between a pair of LSRs without shutting down the LDP session if multiple Hello adjacencies exist between those LSRs. Note that the proposed method can also be used to gracefully shutdown targeted Hello adjacency as well provided that there is such a need. Sivabalan Expires January 6, 2009 [Page 3] Internet-Draft draft-boutros-mpls-gs-ldp-adj-00.txt July 2008 2. Terminology GS: Graceful Shutdown IGP: Interior Gateway Protocol LSP: Label Switch Path LSR: Label Switch Router TLV: Type Length Value 3. Graceful Shutdown Mechanism The proposed mechanism is based on a new optional TLV called "Graceful Shutdown" TLV to be included in LDP Hello message. This TLV is similar to the existing optional parameters specified in RFC5036 [1]. An LSR that intends to terminate a Hello adjacency sends a Hello message with the Graceful Shutdown (GS) TLV. Since Hello messages are sent over UDP, the proposed mechanism expects the receiving LSR to acknowledge the receipt of GS request by sending a Hello message with a GS TLV back to the sender. The value of GS TLV indicates whether the GS TLV represents the request or acknowledgement as described later in this document. However, if the receiver does not support GS TLV, the sender will not receive an acknowledgement. In this case, the sender will shutdown the corresponding adjacency based on a local policy (e.g., after sending a certain number of Hello messages with GS TLV or after a certain period of time since the Hello message with GS TLV was sent). Note that an LSR can have multiple adjacencies over a shared media link; one for each neighbor LSR connected via the link. Thus, each Hello message originating from an LSR will be sent over all the adjacencies on the link. The LSR initiating GS will bring down an adjacency after either getting GS acknowledgement from the corresponding neighbor LSR or a certain period of time (whichever Sivabalan Expires January 6, 2009 [Page 4] Internet-Draft draft-boutros-mpls-gs-ldp-adj-00.txt July 2008 comes first). An operator may want to disable LDP on a shared media link after gracefully shutting down all adjacencies over the link. If an LSR capable of recognizing GS TLV receives a Hello message with GS request TLV and the adjacency does not exist, it will immediately send a Hello message with GS acknowledgement TLV. If an LSR capable of recognizing GS TLV receives a Hello message with GS acknowledgement TLV from a neighbor and the LSR has not sent GS request TLV, it will simply ignores the GS TLV. 4. Graceful Shutdown TLV The GS TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| 0x0404 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type is to be assigned by IANA (recommended value is 0x0404). Length is set to 4 indicating that the value field is 4 Octet long. R-bit: indicates whether the Hello message is for graceful shutdown request or acknowledgement. This bit is set to 1 and 0 for request and acknowledgement respectively. Reserved: This field is ignored. If an LSR does not support GS TLV, it should silently ignore the GS TLV and process the rest of the message. Furthermore, the LSR does Sivabalan Expires January 6, 2009 [Page 5] Internet-Draft draft-boutros-mpls-gs-ldp-adj-00.txt July 2008 not forward the GS TLV any further. Thus, the U and F bits are set to 1 and 0 respectively in accordance with RFC5036. If the Hello message contains multiple GS TLVs, only the first one is taken into consideration. 5. Operation An LSR initiating GS carries out the following steps: 1. Update the forwarding entries such that the adjacency being shutdown is no longer used in the data plane to transmit MPLS packets belonging to LDP applications to the receiver. 2. Send up to N Hello messages with GS request (R bit set to 1) TLV. These messages are sent at the configured Hello interval. The default value of N is 2. The LSR does not send more than N Hello messages even if it does not receive GS acknowledgement TLV (R bit set to 0) from the receiver. 3. Stop sending any more Hello messages (even if it has not sent N Hello messages) and go to step 7 if the LSR receives a Hello message with GS acknowledgement TLV. 4. After sending N Hello messages with GS request TLV without getting any Hello message with GS acknowledgement TLV from the receiver, stop sending any more Hello messages and start a timer (let us call it the "GS timer"). The expiry value of the GS timer can be configured and has a default value equal to the Hello adjacency expiry timer value. 5. While waiting for the GS timer to expire, if a Hello message with GS acknowledgment TLV arrives from the receiver, stop the GS timer and go to step 7. 6. Wait until the GS timer expires and then go to step 7. Sivabalan Expires January 6, 2009 [Page 6] Internet-Draft draft-boutros-mpls-gs-ldp-adj-00.txt July 2008 7. Update the forwarding plane such that MPLS packets belonging to LDP applications are no longer received from the receiver over the shutdown adjacency. An LSR receiving GS request carries out the following steps: 1. If the GS TLV is recognized, update the forwarding plane such that the adjacency being shutdown is no longer used in the data plane to transmit MPLS packets belonging to LDP applications. If GS TLV is not recognized, simply ignore the TLV. 2. Send a Hello message with GS acknowledgement TLV if the GS TLV is recognized. If the GS TLV is not recognized and Hello messages are not received from the sender during the Hello adjacency expiry period, update the forwarding plane such that the adjacency is no longer used in the data plane to transmit MPLS packets belonging to LDP applications to the sender. 3. Continue to send Hello messages corresponding to the adjacency being shutdown so that the adjacency can be brought up again if necessary. In case both LSRs corresponding to an adjacency initiate GS at the same time, each LSR removes the adjacency from the forwarding plane upon getting the GS acknowledgement from its neighbor or on the expiry of GS timer (whichever comes first). 6. Security Considerations The security considerations pertaining to LDP Hello messages are discussed in RFC5036. The optional GS TLV introduced in this document does not impose any extra security concern or requirement. Sivabalan Expires January 6, 2009 [Page 7] Internet-Draft draft-boutros-mpls-gs-ldp-adj-00.txt July 2008 7. IANA Considerations IANA is requested to make new allocation from its registry as follows: Optional Parameter Type Reference Graceful Shutdown 0x0404 draft-boutros-ldp-gs-adj-00.txt 8. Acknowledgments The authors would like to thank George Swallow for his valuable comments. 9. References 9.1. Normative References [1] Andersson, L., Minei, I, Thomas, B. (Editors), "LDP Specification", RFC 5036, October 2007. Author's Addresses Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada Email: msiva@cisco.com Sivabalan Expires January 6, 2009 [Page 8] Internet-Draft draft-boutros-mpls-gs-ldp-adj-00.txt July 2008 Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA Email: sboutros@cisco.com Kamran Raza Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada Email: skraza@cisco.com Bob Thomas Email: bobthomas@alum.mit.edu Intellectual Property Statement 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 Sivabalan Expires January 6, 2009 [Page 9] Internet-Draft draft-boutros-mpls-gs-ldp-adj-00.txt July 2008 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. 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. Copyright Statement Copyright (C) The IETF Trust (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sivabalan Expires January 6, 2009 [Page 10]