idnits 2.17.1 draft-ietf-mpls-ldp-end-of-lib-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 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 383. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5036]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 5, 2008) is 5766 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) == Outdated reference: A later version (-04) exists of draft-ietf-mpls-ldp-capabilities-02 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-ldp-typed-wildcard-03 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-ldp-igp-sync-02 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Rajiv Asati 2 Internet Draft Cisco Systems 3 Intended status: Standards Track 4 Expires: January 2009 Pradosh Mohapatra 5 Cisco Systems 7 Bob Thomas 8 Cisco Systems 10 Emily Chen 11 Huawei Technologies 13 July 5, 2008 15 LDP End-of-LIB 16 draft-ietf-mpls-ldp-end-of-lib-00.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that 21 any applicable patent or other IPR claims of which he or she is 22 aware have been or will be disclosed, and any of which he or she 23 becomes aware will be disclosed, in accordance with Section 6 of 24 BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on January 5, 2007. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2008). 48 Abstract 50 There are situations following LDP session establishment where it 51 would be useful for an LDP speaker to know when its peer has 52 advertised all of its labels. These include session establishment 53 when LDP-IGP sync is in use, as well as session re-establishment 54 following loss of an LDP session when LDP graceful restart is in use. 55 The LDP specification [RFC5036] provides no mechanism for an LDP 56 speaker to notify a peer when it has completed its initial label 57 advertisements to that peer. This document specifies means for an 58 LDP speaker to signal completion of its initial label advertisements 59 following session establishment. 61 Conventions used in this document 63 In examples, "C:" and "S:" indicate lines sent by the client and 64 server respectively. 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 Table of Contents 72 1. Introduction...................................................3 73 2. Specification Language.........................................3 74 3. Unrecognized Notification Capability...........................4 75 4. Signaling Completion of Label Advertisement....................4 76 5. Usage Guidelines...............................................5 77 5.1. IGP-Sync..................................................6 78 5.2. LDP Graceful Restart......................................6 79 5.3. Wildcard Label Request....................................7 80 5.4. Missing Expected End-of-LIB Notifications.................7 81 6. Security Considerations........................................7 82 7. IANA Considerations............................................8 83 8. Acknowledgments................................................8 84 9. References.....................................................9 85 9.1. Normative References......................................9 86 9.2. Informative References....................................9 87 Author's Addresses...............................................10 88 Intellectual Property Statement..................................10 89 Disclaimer of Validity...........................................11 91 1. Introduction 93 There are situations following LDP session establishment where it 94 would be useful for an LDP speaker to know when its peer has 95 advertised all of its labels. For example, when an LDP speaker is 96 using LDP-IGP synchronization procedures [LDPSync], it would be 97 useful for the speaker to know when its peer has completed 98 advertisement of its IP label bindings. Similarly, after an LDP 99 session is re-established when LDP Graceful Restart [RFC3478] is in 100 effect, it would be helpful for each peer to signal the other after 101 it has advertised all its label bindings. 103 The LDP specification [RFC5036] provides no mechanism for an LDP 104 speaker to notify a peer when it has completed its initial label 105 advertisements to that peer. 107 This document specifies use of a Notification message with the "End- 108 of-LIB" Status Code for an LDP speaker to signal completion of its 109 label advertisements following session establishment. 111 RFC5036 implicitly assumes that new Status Codes will be defined over 112 the course of time. However, it does not explicitly define the 113 behavior of an LDP speaker which does not understand the Status Code 114 in a Notification message. To avoid backward compatibility issues 115 this document specifies use of the LDP capability mechanism [LDPCap] 116 at session establishment time for informing a peer that an LDP 117 speaker is capable of handling a Notification message that carries an 118 unrecognized Status Code. 120 Copyright (C) The IETF Trust (2008). This version of this MIB module 121 is part of RFC XXXX; see the RFC itself for full legal notices. 123 2. Specification Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 3. Unrecognized Notification Capability 131 An LDP speaker MAY include a Capability Parameter [LDPCap] in the 132 Initialization message to inform a peer that it ignores Notification 133 Messages that carry a Status TLV with a non-fatal Status Code unknown 134 to it. 136 The Capability Parameter for the Unrecognized Notification capability 137 is a TLV with the following format: 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 |U|F| Unrecog Notif (IANA) | Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 |S| Reserved | 145 +-+-+-+-+-+-+-+-+ 147 Figure 1 Unrecognized Notification Capability format 149 Where: 151 U and F bits: Should be set 1 and 0 respectively as per section 4 152 of LDP Capabilities [LDPCap]. 154 Unrecog Notif: TLV code point to be assigned by IANA. 156 S-bit: Must be 1 (indicates that capability is being advertised). 158 Upon receiving a Notification with an unrecognized Status Code an LDP 159 speaker MAY generate a console or system log message for trouble 160 shooting purposes. 162 4. Signaling Completion of Label Advertisement 164 An LDP speaker MAY signal completion of its label advertisements to a 165 peer by means of a Notification message, if its peer had advertised 166 the Unrecognized Notification capability during session 167 establishment. The LDP speaker MAY send the Notification message (per 168 FEC Type) to a peer even if the LDP speaker had no Label bindings to 169 advertise. 171 Such a Notification message MUST carry: 173 - A status TLV with TLV E- and F-bits set to zero that carries an 174 "End-of-LIB" Status Code. 176 - A FEC TLV with the Typed Wildcard FEC Element [TypedWC] that 177 identifies the FEC type for which initial label advertisements 178 have been completed. In terms of Section 3.5.1 of RFC5036, 179 this TLV is an "Optional Parameter" of the Notification 180 message. 182 An LDP speaker MUST NOT send a Notification which carries a Status 183 TLV with the End-of-LIB Status Code to a peer unless the peer had 184 advertised the Unrecognized Notification capability during session 185 establishment. 187 This applies to both non-directed and directed LDP peers. 189 5. Usage Guidelines 191 The FECs known to an LDP speaker and the labels the speaker has bound 192 to those FECs may change over the course of time. This makes 193 determining when an LDP speaker has advertised "all" of its label 194 bindings for a given FEC type an issue. Ultimately, this 195 determination is a judgement call the LDP speaker makes. The 196 following guidelines may be useful. 198 An LDP speaker is assumed to "know" a set of FECs. Depending on a 199 variety of criteria, such as: 201 - The label distribution control mode in use (Independent or 202 Ordered); 204 - The set of FEC's to which the speaker has bound local labels; 206 - Configuration settings which may constrain which label bindings 207 the speaker may advertise to peers; 209 the speaker can determine the set of bindings for a given FEC type 210 that it is permitted to advertise to a given peer. 212 IGP-Sync, LDP Graceful Restart, and the response to a Wildcard Label 213 Request [TypedWC] are situations that would benefit from End-of-LIB 214 Notification. In these situations, after an LDP speaker completes 215 its label binding advertisements to a peer, it should send the peer 216 an End-of-LIB Notification. The following subsections cover each of 217 these situations in turn. 219 5.1. IGP-Sync 221 LDP-IGP Sync is a mechanism directly connected LDP speakers may use 222 to delay using the link connecting them for IP traffic until the 223 labels required to support IP over MPLS traffic on the link have been 224 learned. 226 Without an End-of-LIB Notification the speaker must rely on some 227 heuristic to determine when it has received all of its peer's label 228 bindings. The heuristic chosen could cause LDP to signal the IGP too 229 soon in which case the likelihood that traffic will be dropped 230 increases, or too late in which case traffic is kept on sub-optimal 231 paths longer than necessary. 233 Following session establishment with a directly connected peer that 234 has advertised the Unrecognized Notification capability, an LDP 235 speaker using LDP-IGP Sync may send the peer an End-of-LIB 236 Notification after it completes advertisement of its IP label 237 bindings to the peer. Similarly, the LDP speaker may use the End-of- 238 LIB Notification received from a directly connected peer to determine 239 when the peer has completed advertisement of its label bindings for 240 IP prefixes. After receiving the notification, the speaker should 241 consider LDP to be fully operational for the link and signal the IGP 242 to start advertising the link with normal cost. 244 5.2. LDP Graceful Restart 246 LDP Graceful Restart helps reduce the loss of MPLS traffic caused by 247 the restart of a router's LDP component. It defines procedures that 248 allow routers capable of preserving MPLS forwarding state across the 249 restart to continue forwarding MPLS traffic for a pre-agreed upon 250 period using forwarding state installed prior to the restart. 252 During that period the restarting router and its peers consider the 253 preserved forwarding state to be usable but stale until it is 254 refreshed by receipt of new label advertisements following re- 255 establishment of new LDP sessions. When the period elapses any 256 remaining stale forwarding state is removed by the router. 258 Receipt of the End-of-LIB Notification from a peer in an LDP Graceful 259 Restart scenario enables an LDP speaker to stop using stale 260 forwarding information learned from that peer and to recover the 261 resources it requires without having to wait until the timeout 262 occurs. 264 5.3. Wildcard Label Request 266 When an LDP speaker receives a Label Request message for a Typed 267 Wildcard FEC (e.g. a particular FEC element type) from a peer it 268 determines the set of bindings, it is permitted to advertise the peer 269 for the FEC type specified by the request. Assuming the peer had 270 advertised the Unrecognized Notification capability at session 271 initialization time, the speaker should send the peer an End-of-LIB 272 Notification for the FEC type when it completes advertisement of the 273 permitted bindings. 275 As in the previous applications, receipt of the Notification 276 eliminates uncertainty as to when the peer has completed its 277 advertisements of label bindings for the requested Wildcard FEC 278 Element Type. 280 5.4. Missing Expected End-of-LIB Notifications 282 There is no guarantee that an LDP speaker will receive End-of-LIB 283 Notifications from a peer even if the LDP speaker has signaled its 284 capability. Therefore, an implementation SHOULD NOT depend on the 285 receipt of such a Notification. 287 To deal with the possibility of missing notifications, an LDP speaker 288 may time out receipt of an expected End-of-LIB Notification, and if 289 the timeout occurs, it may behave as if it had received the 290 notification. If the End-of-LIB Notification message is received 291 after the time-out occurs, then the message should be ignored. 293 6. Security Considerations 295 No security considerations beyond those that apply to the base LDP 296 specification and described in [RFC5036] apply to signaling the End- 297 of-LIB condition as described in this document. 299 7. IANA Considerations 301 This draft introduces a new LDP Status Code and a new LDP Capability 302 both of which require IANA assignment. 304 8. Acknowledgments 306 The authors would like to thank Ina Minei, Alia Atlas, Yakov Rekhter 307 and Luyuan Fang for their valuable feedback and contribution. 309 This document was prepared using 2-Word-v2.0.template.dot. 311 9. References 313 9.1. Normative References 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, March 1997. 318 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 319 Thomas, B., "LDP Specification", RFC 5036, January 2001. 321 [LDPCap] Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L., "LDP 322 Capabilities", draft-ietf-mpls-ldp-capabilities-02, Work in 323 Progress, May 2007. 325 [TypedWC] Thomas, B., Minei, I., "LDP Typed Wildcard FEC", draft- 326 ietf-mpls-ldp-typed-wildcard-03, Work in Progress, March 327 2008. 329 9.2. Informative References 331 [LDPSync] Jork, M., Atlas, A., Fang, L., "LDP IGP Synchronization", 332 draft-ietf-mpls-ldp-igp-sync-02, Work in Progress, June 333 2008. 335 [RFC3478] Leelanivas, M., Rekhter, Y., Aggarwal, R., "Graceful 336 Restart Mechanism for Label Distribution Protocol", 337 February 2003. 339 Author's Addresses 341 Rajiv Asati 342 Cisco Systems, 343 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 344 Email: rajiva@cisco.com 346 Pradosh Mohapatra 347 Cisco Systems, 348 3750 Cisco Way, San Jose, CA, 95134 349 Email: pmohapat@cisco.com 351 Bob Thomas 352 Cisco Systems, 353 1414 Massachusetts Ave, Boxborough, MA, 01719 354 Email: rhthomas@cisco.com 356 Emily Chen 357 Huawei Technologies 358 No.5 Street, Shangdi Information, Haidian, Beijing, China 359 Email: chenying220@huawei.com 361 Intellectual Property Statement 363 The IETF takes no position regarding the validity or scope of any 364 Intellectual Property Rights or other rights that might be claimed to 365 pertain to the implementation or use of the technology described in 366 this document or the extent to which any license under such rights 367 might or might not be available; nor does it represent that it has 368 made any independent effort to identify any such rights. Information 369 on the procedures with respect to rights in RFC documents can be 370 found in BCP 78 and BCP 79. 372 Copies of IPR disclosures made to the IETF Secretariat and any 373 assurances of licenses to be made available, or the result of an 374 attempt made to obtain a general license or permission for the use of 375 such proprietary rights by implementers or users of this 376 specification can be obtained from the IETF on-line IPR repository at 377 http://www.ietf.org/ipr. 379 The IETF invites any interested party to bring to its attention any 380 copyrights, patents or patent applications, or other proprietary 381 rights that may cover technology that may be required to implement 382 this standard. Please address the information to the IETF at 383 ietf-ipr@ietf.org. 385 Disclaimer of Validity 387 This document and the information contained herein are provided on an 388 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 389 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 390 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 391 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 392 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 393 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 395 Copyright Statement 397 Copyright (C) The IETF Trust (2008). 399 This document is subject to the rights, licenses and restrictions 400 contained in BCP 78, and except as set forth therein, the authors 401 retain all their rights. 403 Acknowledgment 405 Funding for the RFC Editor function is currently provided by the 406 Internet Society.