idnits 2.17.1 draft-ietf-mpls-ldp-end-of-lib-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 28, 2009) is 5317 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 (-07) exists of draft-ietf-mpls-ldp-typed-wildcard-03 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 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: Feb 2010 Pradosh Mohapatra 5 Cisco Systems 7 Emily Chen 8 Huawei Technologies 10 Bob Thomas 12 August 28, 2009 14 Signaling LDP Label Advertisement Completion 15 draft-ietf-mpls-ldp-end-of-lib-04.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may contain material 21 from IETF Documents or IETF Contributions published or made publicly 22 available before November 10, 2008. The person(s) controlling the 23 copyright in some of this material may not have granted the IETF 24 Trust the right to allow modifications of such material outside the 25 IETF Standards Process. Without obtaining an adequate license from 26 the person(s) controlling the copyright in such materials, this 27 document may not be modified outside the IETF Standards Process, and 28 derivative works of it may not be created outside the IETF Standards 29 Process, except to format it for publication as an RFC or to 30 translate it into languages other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on Feb 28, 2010. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents in effect on the date of 57 publication of this document (http://trustee.ietf.org/license-info). 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. 61 Abstract 63 There are situations following Label Distribution Protocol (LDP) 64 session establishment where it would be useful for an LDP speaker to 65 know when its peer has advertised all of its labels. The LDP 66 specification provides no mechanism for an LDP speaker to notify a 67 peer when it has completed its initial label advertisements to that 68 peer. This document specifies means for an LDP speaker to signal 69 completion of its initial label advertisements following session 70 establishment. 72 Table of Contents 74 1. Introduction...................................................3 75 2. Specification Language.........................................3 76 3. Unrecognized Notification Capability...........................4 77 4. Signaling Completion of Label Advertisement....................4 78 4.1. Missing Expected End-of-LIB Notifications.................5 79 5. Usage Guidelines...............................................6 80 5.1. LDP-IGP Sync..............................................7 81 5.2. LDP Graceful Restart......................................7 82 5.3. Wildcard Label Request....................................8 83 6. Security Considerations........................................8 84 7. IANA Considerations............................................8 85 8. Acknowledgments................................................9 86 9. References....................................................10 87 9.1. Normative References.....................................10 88 9.2. Informative References...................................10 89 Author's Addresses...............................................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 the labels from its Label Information Base (LIB). 96 For example, when an LDP speaker is using LDP-IGP synchronization 97 procedures [RFC5443], it would be useful for the speaker to know when 98 its peer has completed advertisement of its IP label bindings. 99 Similarly, after an LDP session is re-established when LDP Graceful 100 Restart [RFC3478] is in effect, it would be helpful for each peer to 101 signal the other after 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 [RFC5561] 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 2. Specification Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. Unrecognized Notification Capability 128 An LDP speaker MAY include a Capability Parameter [RFC5561] in the 129 Initialization message to inform a peer that it ignores Notification 130 Messages that carry a Status Type-Length-Value (TLV) with a non-fatal 131 Status Code unknown to it. 133 The Capability Parameter for the Unrecognized Notification capability 134 is a TLV with the following format: 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |U|F| Unrecog Notif (IANA) | Length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 |S| Reserved | 142 +-+-+-+-+-+-+-+-+ 144 Figure 1 Unrecognized Notification Capability format 146 Where: 148 U and F bits: MUST be 1 and 0 respectively as per section 3 of LDP 149 Capabilities [RFC5561]. 151 Unrecog Notif: TLV code point to be assigned by IANA. 153 S-bit: MUST be 1 (indicates that capability is being advertised). 155 Upon receiving a Notification with an unrecognized Status Code an LDP 156 speaker MAY generate a console or system log message for trouble 157 shooting purposes. 159 4. Signaling Completion of Label Advertisement 161 An LDP speaker that conforms to this specification SHOULD signal 162 completion of its label advertisements to a peer by means of a 163 Notification message, if its peer has advertised the Unrecognized 164 Notification capability during session establishment. The LDP speaker 165 SHOULD send the Notification message (per Forwarding Equivalence 166 Class (FEC) Type) to a peer even if the LDP speaker had zero Label 167 bindings to advertise to that peer. 169 Such a Notification message MUST carry: 171 - A status TLV (with TLV E- and F-bits set to zero) that carries 172 an "End-of-LIB" Status Code (value to be assigned by IANA). 174 - A FEC TLV with the Typed Wildcard FEC Element [TypedWC] that 175 identifies the FEC type for which initial label advertisements 176 have been completed. In terms of Section 3.5.1 of RFC5036, 177 this TLV is an "Optional Parameter" of the Notification 178 message. 180 An LDP speaker MUST NOT send a Notification which carries a Status 181 TLV with the End-of-LIB Status Code to a peer unless the peer had 182 advertised the Unrecognized Notification capability during session 183 establishment. 185 This applies to any LDP peers discovered via either basic discovery 186 or extended discovery mechanism (per section 2.4 of [RFC5036]). 188 4.1. Missing Expected End-of-LIB Notifications 190 There is no guarantee that an LDP speaker will receive (or send) End- 191 of-LIB Notification from (or to) a peer even if the LDP speaker has 192 signaled the 'Unrecognized Notification' capability (section 3). 194 Although it is expected that an LDP speaker supporting Unrecognized 195 Notification Capability would support sending and receiving End-of- 196 LIB Notication, it is not mandatory by definition. 198 Please note that this is not a concern since the LDP speaker would 199 simply ignore the received Notification with End-of-LIB status code 200 (or any status code) that is not recognized or supported, by 201 definition. 203 To deal with the possibility of missing End-of-LIB Notifications 204 after the LDP session establishment, an LDP speaker MAY time out 205 receipt of an expected End-of-LIB Notification. An LDP speaker SHOULD 206 start a per-peer internal timer, called 'EOL Notification' timer (the 207 default value of 60 seconds is RECOMMENDED, though the value of this 208 timer SHOULD be configurable) immediately following the LDP session 209 establishment. 211 This timer is reset by the subsequent label advertisement, and 212 stopped by the End-of-LIB Notification message. Lacking any label 213 advertisement from the peer, the timer would expire, resulting in the 214 LDP speaker to behave as if it had received the End-of-LIB 215 notification from the peer. 217 If the End-of-LIB Notification message is received after the timer 218 expires, then the message SHOULD be ignored. 220 5. Usage Guidelines 222 The FECs known to an LDP speaker and the labels the speaker has bound 223 to those FECs may change over the course of time. This makes 224 determining when an LDP speaker has advertised "all" of its label 225 bindings for a given FEC type an issue. Ultimately, this 226 determination is a judgment call the LDP speaker makes. The 227 following guidelines may be useful. 229 An LDP speaker is assumed to "know" a set of FECs. Depending on a 230 variety of criteria, such as: 232 - The label distribution control mode in use (Independent or 233 Ordered); 235 - The set of FEC's to which the speaker has bound local labels; 237 - Configuration settings which may constrain which label bindings 238 the speaker may advertise to peers; 240 the speaker can determine the set of bindings for a given FEC type 241 that it is permitted to advertise to a given peer. 243 LDP-IGP Sync, LDP Graceful Restart, and the response to a Wildcard 244 Label Request [TypedWC] are situations that would benefit from End- 245 of-LIB Notification. In these situations, after an LDP speaker 246 completes its label binding advertisements to a peer, sending an End- 247 of-LIB Notification to the peer makes their outcome deterministic. 248 The following subsections further explain each of these situations 249 one by one. 251 5.1. LDP-IGP Sync 253 The LDP-IGP Synchronization [RFC5443] specifies a mechanism by which 254 directly connected LDP speakers may delay the use of the link between 255 them, for transit IP traffic forwarding until the labels required to 256 support IP over MPLS traffic forwarding have been distributed and 257 installed. 259 Without an End-of-LIB Notification, the speaker must rely on some 260 heuristic to determine when it has received all of its peer's label 261 bindings. The heuristic chosen could cause LDP to signal the IGP too 262 soon in which case the likelihood that traffic will be dropped 263 increases, or too late in which case traffic is kept on sub-optimal 264 paths longer than necessary. 266 Following session establishment, with a directly connected peer that 267 has advertised the Unrecognized Notification capability, an LDP 268 speaker using LDP-IGP Sync may send the peer an End-of-LIB 269 Notification after it completes advertisement of its IP label 270 bindings to the peer. Similarly, the LDP speaker may use the End-of- 271 LIB Notification received from a directly connected peer to determine 272 when the peer has completed advertisement of its label bindings for 273 IP prefixes. After receiving the notification, the LDP speaker 274 should consider LDP to be fully operational for the link and signal 275 the IGP to start advertising the link with normal cost. 277 5.2. LDP Graceful Restart 279 LDP Graceful Restart [RFC3478] helps to reduce the loss of MPLS 280 traffic caused by the restart of a router's LDP component. It 281 defines procedures that allow routers capable of preserving MPLS 282 forwarding state across the restart to continue forwarding MPLS 283 traffic using forwarding state installed prior to the restart for a 284 configured time period. 286 The current behavior without End-of-LIB Notification is as follows: 287 the restarting router and its peers consider the preserved forwarding 288 state to be usable but stale until it is refreshed by receipt of new 289 label advertisements following re-establishment of new LDP sessions 290 or until the time period expires. When the time period expires, any 291 remaining stale forwarding state is removed by the router. 293 Receiving End-of-LIB Notification from a peer in an LDP Graceful 294 Restart scenario enables an LDP speaker to stop using stale 295 forwarding information learned from that peer and to recover the 296 resources it requires without having to wait until the time period 297 expiry. The time period expiry can still be used if the End-of-LIB- 298 Notification message is not received. 300 5.3. Wildcard Label Request 302 When an LDP speaker receives a Label Request message for a Typed 303 Wildcard FEC (e.g. a particular FEC element type) from a peer it 304 determines the set of bindings, it is permitted to advertise the peer 305 for the FEC type specified by the request. Assuming the peer had 306 advertised the Unrecognized Notification capability at session 307 initialization time, the speaker should send the peer an End-of-LIB 308 Notification for the FEC type when it completes advertisement of the 309 permitted bindings. 311 As in the previous applications, receipt of the Notification 312 eliminates uncertainty as to when the peer has completed its 313 advertisements of label bindings for the requested Wildcard FEC 314 Element Type. 316 6. Security Considerations 318 No security considerations beyond those that apply to the base LDP 319 specification [RFC5036] and further described in [MPLSsec] apply to 320 signaling the End-of-LIB condition as described in this document. 322 7. IANA Considerations 324 This draft introduces a new LDP Status Code and a new LDP Capability 325 both of which require IANA assignment - 327 The 'End-of-LIB' status code requires a code point from the Status 328 Code Name Space. [RFC5036] partitions the Status Code Name Space 329 into 3 regions: IETF Consensus region, First Come First Served 330 region, and Private Use region. The authors recommend that a code 331 point from the IETF Consensus range be assigned to the 'End-of- 332 LIB' status code. 334 The 'Unrecognized Notification' Capability requires a code point 335 from the TLV Type name space. [RFC5036] partitions the TLV TYPE 336 name space into 3 regions: IETF Consensus region, First Come 337 First Served region, and Private Use region. The authors 338 recommend that a code point from the IETF Consensus range be 339 assigned to the 'Unrecognized Notification' Capability. 341 8. Acknowledgments 343 The authors would like to recognize Kamran Raza, who helped to 344 formulate this draft. 346 The authors would like to thank Ina Minei, Alia Atlas, Yakov Rekhter, 347 Loa Andersson and Luyuan Fang for their valuable feedback and 348 contribution. 350 This document was prepared using 2-Word-v2.0.template.dot. 352 9. References 354 9.1. Normative References 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, March 1997. 359 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 360 Thomas, B., "LDP Specification", RFC 5036, January 2001. 362 [RFC5561] Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L., "LDP 363 Capabilities", RFC5561, May 2007. 365 [TypedWC] Thomas, B., Minei, I., "LDP Typed Wildcard FEC", draft- 366 ietf-mpls-ldp-typed-wildcard-03, Work in Progress, March 367 2008. 369 9.2. Informative References 371 [RFC5443] Jork, M., Atlas, A., Fang, L., "LDP IGP Synchronization", 372 RFC5443, Dec 2007. 374 [RFC3478] Leelanivas, M., Rekhter, Y., Aggarwal, R., "Graceful 375 Restart Mechanism for Label Distribution Protocol", 376 February 2003. 378 [MPLSsec] Fang, L., "Security Framework for MPLS and GMPLS Networks", 379 draft-ietf-mpls-mpls-and-gmpls-security-framework-06, Work 380 in Progress, July 13 2009. 382 Author's Addresses 384 Rajiv Asati 385 Cisco Systems, 386 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 387 Email: rajiva@cisco.com 389 Pradosh Mohapatra 390 Cisco Systems, 391 3750 Cisco Way, San Jose, CA, 95134 392 Email: pmohapat@cisco.com 394 Bob Thomas 395 Email: bobthomas@alum.mit.edu 397 Emily Chen 398 Huawei Technologies 399 No.5 Street, Shangdi Information, Haidian, Beijing, China 400 Email: chenying220@huawei.com