idnits 2.17.1 draft-ietf-mpls-ldp-end-of-lib-02.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 393. 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 (December 29, 2008) is 5597 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 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Rajiv Asati 2 Internet Draft Cisco Systems 3 Intended status: Standards Track 4 Expires: June 2009 Pradosh Mohapatra 5 Cisco Systems 7 Bob Thomas 9 Emily Chen 10 Huawei Technologies 12 December 29, 2008 14 LDP End-of-LIB 15 draft-ietf-mpls-ldp-end-of-lib-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that 20 any applicable patent or other IPR claims of which he or she is 21 aware have been or will be disclosed, and any of which he or she 22 becomes aware will be disclosed, in accordance with Section 6 of 23 BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on June 29, 2009. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2008). 47 Abstract 49 There are situations following Label Distribution Protocol (LDP) 50 session establishment where it would be useful for an LDP speaker to 51 know when its peer has advertised all of its labels. The LDP 52 specification provides no mechanism for an LDP speaker to notify a 53 peer when it has completed its initial label advertisements to that 54 peer. This document specifies means for an LDP speaker to signal 55 completion of its initial label advertisements following session 56 establishment. 58 Table of Contents 60 1. Introduction...................................................2 61 2. Specification Language.........................................3 62 3. Unrecognized Notification Capability...........................3 63 4. Signaling Completion of Label Advertisement....................4 64 5. Usage Guidelines...............................................5 65 5.1. LDP-IGP Sync..............................................5 66 5.2. LDP Graceful Restart......................................6 67 5.3. Wildcard Label Request....................................7 68 5.4. Missing Expected End-of-LIB Notifications.................7 69 6. Security Considerations........................................7 70 7. IANA Considerations............................................7 71 8. Acknowledgments................................................8 72 9. References.....................................................9 73 9.1. Normative References......................................9 74 9.2. Informative References....................................9 75 Author's Addresses...............................................10 76 Intellectual Property Statement..................................10 77 Disclaimer of Validity...........................................11 79 1. Introduction 81 There are situations following LDP session establishment where it 82 would be useful for an LDP speaker to know when its peer has 83 advertised all of its labels. For example, when an LDP speaker is 84 using LDP-IGP synchronization procedures [LDPSync], it would be 85 useful for the speaker to know when its peer has completed 86 advertisement of its IP label bindings. Similarly, after an LDP 87 session is re-established when LDP Graceful Restart [RFC3478] is in 88 effect, it would be helpful for each peer to signal the other after 89 it has advertised all its label bindings. 91 The LDP specification [RFC5036] provides no mechanism for an LDP 92 speaker to notify a peer when it has completed its initial label 93 advertisements to that peer. 95 This document specifies use of a Notification message with the "End- 96 of-LIB" Status Code for an LDP speaker to signal completion of its 97 label advertisements following session establishment. 99 RFC5036 implicitly assumes that new Status Codes will be defined over 100 the course of time. However, it does not explicitly define the 101 behavior of an LDP speaker which does not understand the Status Code 102 in a Notification message. To avoid backward compatibility issues 103 this document specifies use of the LDP capability mechanism [LDPCap] 104 at session establishment time for informing a peer that an LDP 105 speaker is capable of handling a Notification message that carries an 106 unrecognized Status Code. 108 2. Specification Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Unrecognized Notification Capability 116 An LDP speaker MAY include a Capability Parameter [LDPCap] in the 117 Initialization message to inform a peer that it ignores Notification 118 Messages that carry a Status TLV with a non-fatal Status Code unknown 119 to it. 121 The Capability Parameter for the Unrecognized Notification capability 122 is a TLV with the following format: 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 |U|F| Unrecog Notif (IANA) | Length | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 |S| Reserved | 130 +-+-+-+-+-+-+-+-+ 132 Figure 1 Unrecognized Notification Capability format 134 Where: 136 U and F bits: Should be set 1 and 0 respectively as per section 4 137 of LDP Capabilities [LDPCap]. 139 Unrecog Notif: TLV code point to be assigned by IANA. 141 S-bit: Must be 1 (indicates that capability is being advertised). 143 Upon receiving a Notification with an unrecognized Status Code an LDP 144 speaker MAY generate a console or system log message for trouble 145 shooting purposes. 147 4. Signaling Completion of Label Advertisement 149 An LDP speaker MAY signal completion of its label advertisements to a 150 peer by means of a Notification message, if its peer had advertised 151 the Unrecognized Notification capability during session 152 establishment. The LDP speaker MAY send the Notification message (per 153 FEC Type) to a peer even if the LDP speaker had zero Label bindings 154 to advertise to that peer. 156 Such a Notification message MUST carry: 158 - A status TLV (with TLV E- and F-bits set to zero) that carries 159 an "End-of-LIB" Status Code (value to be assigned by IANA). 161 - A FEC TLV with the Typed Wildcard FEC Element [TypedWC] that 162 identifies the FEC type for which initial label advertisements 163 have been completed. In terms of Section 3.5.1 of RFC5036, 164 this TLV is an "Optional Parameter" of the Notification 165 message. 167 An LDP speaker MUST NOT send a Notification which carries a Status 168 TLV with the End-of-LIB Status Code to a peer unless the peer had 169 advertised the Unrecognized Notification capability during session 170 establishment. 172 This applies to any LDP peers discovered via either basic discovery 173 or extended discovery mechanism (per section 2.4 of [RFC5036]). 175 5. Usage Guidelines 177 The FECs known to an LDP speaker and the labels the speaker has bound 178 to those FECs may change over the course of time. This makes 179 determining when an LDP speaker has advertised "all" of its label 180 bindings for a given FEC type an issue. Ultimately, this 181 determination is a judgement call the LDP speaker makes. The 182 following guidelines may be useful. 184 An LDP speaker is assumed to "know" a set of FECs. Depending on a 185 variety of criteria, such as: 187 - The label distribution control mode in use (Independent or 188 Ordered); 190 - The set of FEC's to which the speaker has bound local labels; 192 - Configuration settings which may constrain which label bindings 193 the speaker may advertise to peers; 195 the speaker can determine the set of bindings for a given FEC type 196 that it is permitted to advertise to a given peer. 198 LDP-IGP Sync, LDP Graceful Restart, and the response to a Wildcard 199 Label Request [TypedWC] are situations that would benefit from End- 200 of-LIB Notification. In these situations, after an LDP speaker 201 completes its label binding advertisements to a peer, sending an End- 202 of-LIB Notification to the peer makes their outcome deterministic. 203 The following subsections further explain each of these situations 204 one by one. 206 5.1. LDP-IGP Sync 208 The LDP-IGP Synchronization [LDPSync] specifies a mechanism by which 209 directly connected LDP speakers may delay the use of the link between 210 them, for transit IP traffic forwarding until the labels required to 211 support IP over MPLS traffic forwarding have been distributed and 212 installed. 214 Without an End-of-LIB Notification, the speaker must rely on some 215 heuristic to determine when it has received all of its peer's label 216 bindings. The heuristic chosen could cause LDP to signal the IGP too 217 soon in which case the likelihood that traffic will be dropped 218 increases, or too late in which case traffic is kept on sub-optimal 219 paths longer than necessary. 221 Following session establishment, with a directly connected peer that 222 has advertised the Unrecognized Notification capability, an LDP 223 speaker using LDP-IGP Sync may send the peer an End-of-LIB 224 Notification after it completes advertisement of its IP label 225 bindings to the peer. Similarly, the LDP speaker may use the End-of- 226 LIB Notification received from a directly connected peer to determine 227 when the peer has completed advertisement of its label bindings for 228 IP prefixes. After receiving the notification, the LDP speaker 229 should consider LDP to be fully operational for the link and signal 230 the IGP to start advertising the link with normal cost. 232 5.2. LDP Graceful Restart 234 LDP Graceful Restart [RFC3478] helps to reduce the loss of MPLS 235 traffic caused by the restart of a router's LDP component. It 236 defines procedures that allow routers capable of preserving MPLS 237 forwarding state across the restart to continue forwarding MPLS 238 traffic using forwarding state installed prior to the restart for a 239 configured time period. 241 The current behavior without End-of-LIB Notification is as follows: 242 the restarting router and its peers consider the preserved forwarding 243 state to be usable but stale until it is refreshed by receipt of new 244 label advertisements following re-establishment of new LDP sessions 245 or until the time period expires. When the time period expires, any 246 remaining stale forwarding state is removed by the router. 248 Receiving End-of-LIB Notification from a peer in an LDP Graceful 249 Restart scenario enables an LDP speaker to stop using stale 250 forwarding information learned from that peer and to recover the 251 resources it requires without having to wait until the time period 252 expiry. The time period expiry can still be used if the End-of-LIB- 253 Notification message is not received. 255 5.3. Wildcard Label Request 257 When an LDP speaker receives a Label Request message for a Typed 258 Wildcard FEC (e.g. a particular FEC element type) from a peer it 259 determines the set of bindings, it is permitted to advertise the peer 260 for the FEC type specified by the request. Assuming the peer had 261 advertised the Unrecognized Notification capability at session 262 initialization time, the speaker should send the peer an End-of-LIB 263 Notification for the FEC type when it completes advertisement of the 264 permitted bindings. 266 As in the previous applications, receipt of the Notification 267 eliminates uncertainty as to when the peer has completed its 268 advertisements of label bindings for the requested Wildcard FEC 269 Element Type. 271 5.4. Missing Expected End-of-LIB Notifications 273 There is no guarantee that an LDP speaker will receive End-of-LIB 274 Notifications from a peer even if the LDP speaker has signaled its 275 capability. Therefore, an implementation SHOULD NOT depend on the 276 receipt of such a Notification. 278 To deal with the possibility of missing notifications, an LDP speaker 279 may time out receipt of an expected End-of-LIB Notification, and if 280 the timeout occurs, it may behave as if it had received the 281 notification. If the End-of-LIB Notification message is received 282 after the time-out occurs, then the message should be ignored. 284 6. Security Considerations 286 No security considerations beyond those that apply to the base LDP 287 specification [RFC5036] and further described in [MPLSsec] apply to 288 signaling the End-of-LIB condition as described in this document. 290 7. IANA Considerations 292 This draft introduces a new LDP Status Code and a new LDP Capability 293 both of which require IANA assignment - 294 The 'End-of-LIB' status code requires a code point from the Status 295 Code Name Space. [RFC5036] partitions the Status Code Name Space 296 into 3 regions: IETF Consensus region, First Come First Served 297 region, and Private Use region. The authors recommend that a code 298 point from the IETF Consensus range be assigned to the 'End-of- 299 LIB' status code. 301 The 'Unrecognized Notification' Capability requires a code point 302 from the TLV Type name space. [RFC5036] partitions the TLV TYPE 303 name space into 3 regions: IETF Consensus region, First Come 304 First Served region, and Private Use region. The authors 305 recommend that a code point from the IETF Consensus range be 306 assigned to the 'Unrecognized Notification' Capability. 308 8. Acknowledgments 310 The authors would like to thank Ina Minei, Alia Atlas, Yakov Rekhter, 311 Loa Andersson and Luyuan Fang for their valuable feedback and 312 contribution. 314 The authors would like to recognize Kamran Raza, who helped to 315 formulate this draft. 317 This document was prepared using 2-Word-v2.0.template.dot. 319 9. References 321 9.1. Normative References 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997. 326 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 327 Thomas, B., "LDP Specification", RFC 5036, January 2001. 329 [LDPCap] Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L., "LDP 330 Capabilities", draft-ietf-mpls-ldp-capabilities-02, Work in 331 Progress, May 2007. 333 [TypedWC] Thomas, B., Minei, I., "LDP Typed Wildcard FEC", draft- 334 ietf-mpls-ldp-typed-wildcard-03, Work in Progress, March 335 2008. 337 9.2. Informative References 339 [LDPSync] Jork, M., Atlas, A., Fang, L., "LDP IGP Synchronization", 340 draft-ietf-mpls-ldp-igp-sync-02, Work in Progress, June 341 2008. 343 [RFC3478] Leelanivas, M., Rekhter, Y., Aggarwal, R., "Graceful 344 Restart Mechanism for Label Distribution Protocol", 345 February 2003. 347 [MPLSsec] Fang, L., "Security Framework for MPLS and GMPLS Networks", 348 draft-ietf-mpls-mpls-and-gmpls-security-framework-04, Work 349 in Progress, Nov 2008. 351 Author's Addresses 353 Rajiv Asati 354 Cisco Systems, 355 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 356 Email: rajiva@cisco.com 358 Pradosh Mohapatra 359 Cisco Systems, 360 3750 Cisco Way, San Jose, CA, 95134 361 Email: pmohapat@cisco.com 363 Bob Thomas 364 Email: bobthomas@alum.mit.edu 366 Emily Chen 367 Huawei Technologies 368 No.5 Street, Shangdi Information, Haidian, Beijing, China 369 Email: chenying220@huawei.com 371 Intellectual Property Statement 373 The IETF takes no position regarding the validity or scope of any 374 Intellectual Property Rights or other rights that might be claimed to 375 pertain to the implementation or use of the technology described in 376 this document or the extent to which any license under such rights 377 might or might not be available; nor does it represent that it has 378 made any independent effort to identify any such rights. Information 379 on the procedures with respect to rights in RFC documents can be 380 found in BCP 78 and BCP 79. 382 Copies of IPR disclosures made to the IETF Secretariat and any 383 assurances of licenses to be made available, or the result of an 384 attempt made to obtain a general license or permission for the use of 385 such proprietary rights by implementers or users of this 386 specification can be obtained from the IETF on-line IPR repository at 387 http://www.ietf.org/ipr. 389 The IETF invites any interested party to bring to its attention any 390 copyrights, patents or patent applications, or other proprietary 391 rights that may cover technology that may be required to implement 392 this standard. Please address the information to the IETF at 393 ietf-ipr@ietf.org. 395 Disclaimer of Validity 397 This document and the information contained herein are provided on an 398 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 399 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 400 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 401 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 402 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 403 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 405 Copyright Statement 407 Copyright (C) The IETF Trust (2008). 409 This document is subject to the rights, licenses and restrictions 410 contained in BCP 78, and except as set forth therein, the authors 411 retain all their rights. 413 Acknowledgment 415 Funding for the RFC Editor function is currently provided by the 416 Internet Society.