idnits 2.17.1 draft-boutros-mpls-ldp-gs-adj-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 310. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2008) is 5773 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Siva Sivabalan (Ed.) 3 Internet Draft Sami Boutros 4 Intended status: Standards Track Kamran Raza 5 Expires: January 2009 Cisco Systems, Inc., 7 Bob Thomas 9 July 6, 2008 11 Graceful Shutdown of LDP Adjacency 12 draft-boutros-mpls-ldp-gs-adj-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that 17 any applicable patent or other IPR claims of which he or she is 18 aware have been or will be disclosed, and any of which he or she 19 becomes aware will be disclosed, in accordance with Section 6 of 20 BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on January 6, 2009. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document specifies an extension to Label Distribution Protocol 46 (LDP) using which a Label Switched Router (LSR) can explicitly notify 47 its neighbor LSR its intention to shutdown one or more LDP 48 adjacencies. This extension shall be used to shutdown LDP adjacencies 49 for planned maintenance without interrupting traffic. 51 Table of Contents 53 1. Introduction...................................................3 54 2. Terminology....................................................4 55 3. Graceful Shutdown Mechanism....................................4 56 4. Graceful Shutdown TLV..........................................5 57 5. Operation......................................................6 58 6. Security Considerations........................................7 59 7. IANA Considerations............................................8 60 8. Acknowledgments................................................8 61 9. References.....................................................8 62 9.1. Normative References......................................8 63 Author's Addresses................................................8 64 Intellectual Property Statement...................................9 65 Disclaimer of Validity...........................................10 67 1. Introduction 69 In an MPLS network where LDP is used to establish Label Switched 70 Paths (LSPs), there could be more than one LDP-enabled links between 71 a pair of Label Switched Routers (LSRs). In this case, LDP Hello 72 adjacency can be formed over more than one such links between the 73 LSRs, and MPLS traffic can be sent over all links supporting 74 adjacency for load balancing purpose. 76 In case where multiple links exist between a pair of LSRs, an 77 operator may want to gracefully shutdown LDP adjacency(ies) on one or 78 more links (but not all) without bringing down the LDP session 79 between the corresponding LSRs. Such planned shutdown can be required 80 for maintenance purpose. In this context, the word "gracefully" means 81 ceasing to use the specified link(s) for forwarding MPLS traffic with 82 minimal or no traffic loss. It is possible to tweak the IGP metric of 83 the link(s) so that IGP best paths do not include the link(s) from 84 which MPLS traffic is to be diverted. However, this approach moves 85 not only MPLS traffic but also IP traffic thereby causing unnecessary 86 churn in the network. Furthermore, since IGP metric is tweaked, IGP 87 updates must be triggered and advertised throughout the network which 88 also creates unnecessary routing messages. It is also possible that 89 LDP paths are learned via static routing in which case no amount of 90 IGP tweaking would help. Using LDP mechanisms available today, 91 operator could gracefully shutdown one or more LDP sessions on a 92 given LSR. However, such mechanisms cannot be used for gracefully 93 disabling LDP on specific adjacency(ies) between LSRs. 95 In this document, we propose a mechanism to gracefully shutdown Hello 96 adjacency(ies) between a pair of LSRs without shutting down the LDP 97 session if multiple Hello adjacencies exist between those LSRs. Note 98 that the proposed method can also be used to gracefully shutdown 99 targeted Hello adjacency as well provided that there is such a need. 101 2. Terminology 103 GS: Graceful Shutdown 105 IGP: Interior Gateway Protocol 107 LSP: Label Switch Path 109 LSR: Label Switch Router 111 TLV: Type Length Value 113 3. Graceful Shutdown Mechanism 115 The proposed mechanism is based on a new optional TLV called 116 "Graceful Shutdown" TLV to be included in LDP Hello message. This TLV 117 is similar to the existing optional parameters specified in RFC5036 118 [1]. An LSR that intends to terminate a Hello adjacency sends a Hello 119 message with the Graceful Shutdown (GS) TLV. Since Hello messages are 120 sent over UDP, the proposed mechanism expects the receiving LSR to 121 acknowledge the receipt of GS request by sending a Hello message with 122 a GS TLV back to the sender. The value of GS TLV indicates whether 123 the GS TLV represents the request or acknowledgement as described 124 later in this document. However, if the receiver does not support GS 125 TLV, the sender will not receive an acknowledgement. In this case, 126 the sender will shutdown the corresponding adjacency based on a local 127 policy (e.g., after sending a certain number of Hello messages with 128 GS TLV or after a certain period of time since the Hello message with 129 GS TLV was sent). 131 Note that an LSR can have multiple adjacencies over a shared media 132 link; one for each neighbor LSR connected via the link. Thus, each 133 Hello message originating from an LSR will be sent over all the 134 adjacencies on the link. The LSR initiating GS will bring down an 135 adjacency after either getting GS acknowledgement from the 136 corresponding neighbor LSR or a certain period of time (whichever 137 comes first). An operator may want to disable LDP on a shared media 138 link after gracefully shutting down all adjacencies over the link. 140 If an LSR capable of recognizing GS TLV receives a Hello message with 141 GS request TLV and the adjacency does not exist, it will immediately 142 send a Hello message with GS acknowledgement TLV. 144 If an LSR capable of recognizing GS TLV receives a Hello message with 145 GS acknowledgement TLV from a neighbor and the LSR has not sent GS 146 request TLV, it will simply ignores the GS TLV. 148 4. Graceful Shutdown TLV 150 The GS TLV has the following format: 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 |1|0| 0x0404 | Length | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 |R| Reserved | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Type is to be assigned by IANA (recommended value is 0x0404). 162 Length is set to 4 indicating that the value field is 4 Octet long. 164 R-bit: indicates whether the Hello message is for graceful shutdown 165 request or acknowledgement. This bit is set to 1 and 0 for request 166 and acknowledgement respectively. 168 Reserved: This field is ignored. 170 If an LSR does not support GS TLV, it should silently ignore the GS 171 TLV and process the rest of the message. Furthermore, the LSR does 172 not forward the GS TLV any further. Thus, the U and F bits are set to 173 1 and 0 respectively in accordance with RFC5036. 175 If the Hello message contains multiple GS TLVs, only the first one is 176 taken into consideration. 178 5. Operation 180 An LSR initiating GS carries out the following steps: 182 1. Update the forwarding entries such that the adjacency being 183 shutdown is no longer used in the data plane to transmit MPLS 184 packets belonging to LDP applications to the receiver. 186 2. Send up to N Hello messages with GS request (R bit set to 1) TLV. 187 These messages are sent at the configured Hello interval. The 188 default value of N is 2. The LSR does not send more than N Hello 189 messages even if it does not receive GS acknowledgement TLV (R bit 190 set to 0) from the receiver. 192 3. Stop sending any more Hello messages (even if it has not sent N 193 Hello messages) and go to step 7 if the LSR receives a Hello 194 message with GS acknowledgement TLV. 196 4. After sending N Hello messages with GS request TLV without getting 197 any Hello message with GS acknowledgement TLV from the receiver, 198 stop sending any more Hello messages and start a timer (let us 199 call it the "GS timer"). The expiry value of the GS timer can be 200 configured and has a default value equal to the Hello adjacency 201 expiry timer value. 203 5. While waiting for the GS timer to expire, if a Hello message with 204 GS acknowledgment TLV arrives from the receiver, stop the GS timer 205 and go to step 7. 207 6. Wait until the GS timer expires and then go to step 7. 209 7. Update the forwarding plane such that MPLS packets belonging to 210 LDP applications are no longer received from the receiver over the 211 shutdown adjacency. 213 An LSR receiving GS request carries out the following steps: 215 1. If the GS TLV is recognized, update the forwarding plane such that 216 the adjacency being shutdown is no longer used in the data plane 217 to transmit MPLS packets belonging to LDP applications. If GS TLV 218 is not recognized, simply ignore the TLV. 220 2. Send a Hello message with GS acknowledgement TLV if the GS TLV is 221 recognized. If the GS TLV is not recognized and Hello messages are 222 not received from the sender during the Hello adjacency expiry 223 period, update the forwarding plane such that the adjacency is no 224 longer used in the data plane to transmit MPLS packets belonging 225 to LDP applications to the sender. 227 3. Continue to send Hello messages corresponding to the adjacency 228 being shutdown so that the adjacency can be brought up again if 229 necessary. 231 In case both LSRs corresponding to an adjacency initiate GS at the 232 same time, each LSR removes the adjacency from the forwarding plane 233 upon getting the GS acknowledgement from its neighbor or on the 234 expiry of GS timer (whichever comes first). 236 6. Security Considerations 238 The security considerations pertaining to LDP Hello messages are 239 discussed in RFC5036. The optional GS TLV introduced in this document 240 does not impose any extra security concern or requirement. 242 7. IANA Considerations 244 IANA is requested to make new allocation from its registry as 245 follows: 247 Optional Parameter Type Reference 249 Graceful Shutdown 0x0404 draft-boutros-ldp-gs-adj-00.txt 251 8. Acknowledgments 253 The authors would like to thank George Swallow for his valuable 254 comments. 256 9. References 258 9.1. Normative References 260 [1] Andersson, L., Minei, I, Thomas, B. (Editors), "LDP 261 Specification", RFC 5036, October 2007. 263 Author's Addresses 265 Siva Sivabalan 266 Cisco Systems, Inc. 267 2000 Innovation Drive 268 Kanata, Ontario, K2K 3E8 269 Canada 270 Email: msiva@cisco.com 271 Sami Boutros 272 Cisco Systems, Inc. 273 3750 Cisco Way 274 San Jose, California 95134 275 USA 276 Email: sboutros@cisco.com 278 Kamran Raza 279 Cisco Systems, Inc. 280 2000 Innovation Drive 281 Kanata, Ontario, K2K 3E8 282 Canada 283 Email: skraza@cisco.com 285 Bob Thomas 286 Email: bobthomas@alum.mit.edu 288 Intellectual Property Statement 290 The IETF takes no position regarding the validity or scope of any 291 Intellectual Property Rights or other rights that might be claimed to 292 pertain to the implementation or use of the technology described in 293 this document or the extent to which any license under such rights 294 might or might not be available; nor does it represent that it has 295 made any independent effort to identify any such rights. Information 296 on the procedures with respect to rights in RFC documents can be 297 found in BCP 78 and BCP 79. 299 Copies of IPR disclosures made to the IETF Secretariat and any 300 assurances of licenses to be made available, or the result of an 301 attempt made to obtain a general license or permission for the use of 302 such proprietary rights by implementers or users of this 303 specification can be obtained from the IETF on-line IPR repository at 304 http://www.ietf.org/ipr. 306 The IETF invites any interested party to bring to its attention any 307 copyrights, patents or patent applications, or other proprietary 308 rights that may cover technology that may be required to implement 309 this standard. Please address the information to the IETF at 310 ietf-ipr@ietf.org. 312 Disclaimer of Validity 314 This document and the information contained herein are provided on an 315 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 316 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 317 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 318 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 319 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 320 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 322 Copyright Statement 324 Copyright (C) The IETF Trust (2008). 326 This document is subject to the rights, licenses and restrictions 327 contained in BCP 78, and except as set forth therein, the authors 328 retain all their rights. 330 Acknowledgment 332 Funding for the RFC Editor function is currently provided by the 333 Internet Society.