idnits 2.17.00 (12 Aug 2021) /tmp/idnits54004/draft-ldp-ila-extension-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An LDP speaker MUST not send this message unless the LDP peer has previously announced its ability to support the ILA capabilities. Only the LDP FEC types supported by both endpoints should appear in the the ILA version TLVs. If unsupported FEC types appear, they will be discarded by the receiver. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (January 1, 2012) is 3786 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) == Unused Reference: 'RFC5561' is defined on line 411, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lo 3 Internet-Draft K. Patel 4 Intended status: Standards Track V. Lim 5 Expires: July 4, 2012 Cisco Systems 6 January 1, 2012 8 Incremental Label Announcement Extensions for LDP 9 draft-ldp-ila-extension-01.txt 11 Abstract 13 The current LDP Graceful Restart (GR) mechanism specified in RFC3478 14 requires a complete re-advertisement of the LDP label binding 15 information across a session restart, even though complete label 16 binding information might be preserved. 18 In this document we specify extensions to LDP graceful restart in 19 order to support avoiding unnecessary transmission of the label 20 binding information preserved across a session restart, thus 21 accelerating the router re-convergence. More specifically, we 22 describe a version number based batching mechanism for keeping track 23 of the label binding information across a session restart. 25 The new 1) LDP ILA capability TLV, 2) LDP VERSION ID TLV and 3) LDP 26 ILA Version message type, is introduced for checkpointing the label 27 binding version maintained for a neighbor. We also specify 28 procedures for handling label binding table version update across a 29 session restart. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 4, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 78 2. Incremental Label Announcement Capability TLV . . . . . . . . 4 79 3. Incremental Label Announcement FEC Version TLV . . . . . . . . 5 80 4. Incremental Label Announcement Version Message . . . . . . . . 6 81 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 5.1. Session Initialization . . . . . . . . . . . . . . . . . . 7 83 5.2. Label Mapping Sender/Receiver (LM-S/LM-R) . . . . . . . . 7 84 5.3. ILA Version ID=0 Handling . . . . . . . . . . . . . . . . 9 85 5.4. ILA Version ID Assignment . . . . . . . . . . . . . . . . 9 86 5.5. ILA Version ID wraparound . . . . . . . . . . . . . . . . 9 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 90 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 93 1. Introduction 95 This document defines a new LDP Incremental Label Announcement 96 extension for LDP Graceful restart. This mechanism avoids 97 unnecessary transmission of the label binding information during 98 session restarts and thus improve the overall router convergence. 100 1.1. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 2. Incremental Label Announcement Capability TLV 108 The LDP Incremental Label Announcement (ILA) Capability TLV is used 109 by an LDP speaker to list the FEC types that support the ILA 110 capability. This TLV MUST be announced in the LDP initialization 111 message along with the LDP FT Session TLV. An implementation that 112 support LDP ILA MUST implement the procedures for Capability 113 Parameters in LDP Initialization Messages. 115 The format of a "Incremental Label Announcement Capability" TLV is as 116 follows: 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 |U|F| ILA Capability (TBD IANA) | Length | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 |S| Reserved | | 124 +-+-+-+-+-+-+-+-+ FEC Type List | 125 | +-+-+-+-+-+-+-+-+-+-+ 126 | | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 U-bit: 130 The Unknown TLV bit should be set to the value 1. 132 F-bit: 133 The forward unknown TLV bit should be set to the value 0. 135 ILA Capability: 136 The ILA Capability code is assigned by IANA (TBD). 138 Length: 139 The length indicates the number of octets for S/Reserved byte 140 and the bytes found in the FEC Type List Data. 142 S-bit: 143 The State Bit MUST always be set to 1. It indicates whether the 144 sender is advertising or withdrawing the capability 145 corresponding to the TLV code point. 147 The State Bit value is used as follows: 149 1 - The TLV is advertising the capability specified by the TLV 150 code point. 152 0 - The TLV is withdrawing the capability specified by the TLV 153 code point. 155 FEC Type List: 156 The FEC type list indicates the sender supported ILA FEC types. 157 Each Octet of FEC Type List Data corresponds to a FEC type 158 defined in the LDP Forwarding Equivalence Class (FEC) Type 159 Namespace. 161 3. Incremental Label Announcement FEC Version TLV 163 The ILA Version TLV is defined for controlling/versioning label 164 mapping advertisements/withdraw messages for a given FEC type. This 165 TLV is used by the receiver of the label advertisements/withdraw 166 message to request which versions of Label bindings the LDP speaker 167 should announce from. Furthermore, it is also used by the LDP 168 speaker to verify that the labels advertisements for a given FEC type 169 do fall within the specified version id. The LDP speaker uses this 170 information in generating incremental announcements. 172 The "ILA Version" TLV has the following format: 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 |U|F| ILA Version (TBD IANA) | Length = 12 | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | FEC Type | Mode | Reserved (must be zero) | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Label Version ID (8 octets) | 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 U-bit: 186 The Unknown TLV bit MUST be set to the value 0. 188 F-bit: 189 The forward unknown TLV bit MUST be set to the value 0. 191 ILA Version: 192 The ILA Version TLV type is assigned by IANA (TBD). 194 Length: 195 The length field is always set to 12. 197 FEC type: 198 Identifies the FEC type for which the ILA version message 199 applies. 201 Mode: 202 0 - Request Mode: Request label bindings starting from 203 specified version. 204 1 - Assign Mode: Assign the specified version ID to the 205 bindings that follow. 207 Label Version ID: 208 A 64 bit version number. 210 4. Incremental Label Announcement Version Message 212 The new Incremental Label Announcement Version message is used by the 213 speaker to send 1 or more ILA Version TLVs. This message contains 214 one or more per FEC type TLVs used to request the peer to start 215 sending labels with a given version number and to inform the peer the 216 current version ID assigned to the bindings that follow. If there 217 are multiple TLVs of a specific FEC type, at most there MUST be one 218 Version-id "request", and Version-ID "assign" TLV for a given FEC 219 type. 221 An LDP speaker MUST not send this message unless the LDP peer has 222 previously announced its ability to support the ILA capabilities. 223 Only the LDP FEC types supported by both endpoints should appear in 224 the the ILA version TLVs. If unsupported FEC types appear, they will 225 be discarded by the receiver. 227 The ILA Version message is defined as following: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |0| ILA (IANA) | Length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Message ID | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | TLV_1 | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | . . . | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | TLV_N | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 where TLV_1 through TLV_N are currently used for ILA Version-ID TLVs. 245 5. Procedures 247 5.1. Session Initialization 249 An LDP speaker that is capable and willing to support the ILA 250 procedures for a given FEC type advertises this ability through the 251 Incremental Label Announcement Capability TLV in the LDP session 252 initialization message. The ILA Capability TLV MUST only be included 253 in the LDP initialization message if LDP initialization message 254 contains a FT session TLV indicating its ability to support LDP 255 Graceful Restart. The sender of the ILA Capability TLV MUST include 256 all the FEC types for which it intends to support ILA procedures. 257 The set of FEC types that is found in both the sent ILA Capability 258 TLV and the received ILA Capability TLV represents the FEC types for 259 which both LDP endpoints will follow ILA procedures when advertising/ 260 withdrawing label bindings. 262 The FEC type list may potentially change across a LDP restart. When 263 this happens, the bindings for FEC types previously supporting ILA 264 that changed disappeared for the new LDP session need to be purged. 266 5.2. Label Mapping Sender/Receiver (LM-S/LM-R) 268 During label mapping advertisement/withdraw, an LDP endpoint plays 269 the role of the label mapping sender (LM-S) or label mapping receiver 270 (LM-R). 272 For FEC types which the ILA procedures apply, the LM-S will need to 273 maintain a local label binding table and associate an ILA VERSION-ID 274 with each binding. Each time a local label binding changes (such 275 that a re-advertisement or withdraw needs to be sent), the VERSION-ID 276 for the binding must be updated such that the value is greater than 277 or equal to the current VERSION-ID being used to advertise/withdraw 278 label mapping bindings. The local label binding table and associated 279 VERSION-ID must be maintained across a LDP session restart. This 280 version id can be managed either on a router basis or on a per 281 session level and is left to the implementer. 283 The LM-R similarly, will need to keep 1) bindings learned from an 284 LM-S in a remote binding table, and 2) the last VERSION-ID "assign" 285 value learned from the LM-S. Both the remote binding table and the 286 LM-S version ID "assign" value needs to be maintained across a LDP 287 session restart. 289 After session establishments, the LM-S must wait for a VERSION-ID 290 "request" message from the LM-R. The LM-R sends the VERSION-ID that 291 it last processed from the LM-S. If the LM-R needs to purge its 292 remote binding table, it can optionally send a VERSION ID=0 "request" 293 to the LM-S request that it re-send all its bindings. The LM-R does 294 not necessarily send a VERSION-ID "request" TLV immediately after a 295 session is established. It sends the request when it's ready to 296 receive bindings. 298 After receiving a VERSION-ID "request" message from the LM-R, an LM-S 299 should send a VERSION-ID "assign" message starting with VERSION-ID 300 not greater than the VERSION-ID requested by the LM-R. The LM-R upon 301 receiving the VERSION-ID "assign", must mark all bindings with 302 VERSION-ID greater than the assigned VERSION-ID as stale and purge 303 them after the graceful restart period expires. The LM-S should then 304 scan its local label binding table and advertise/withdraw bindings 305 with VERSION-IDs starting with the version id less than or equal to 306 the VERSION-ID "assign" message. The LM-S MUST also scan its local 307 label binding table and mark all previously withdrawn bindings with 308 VERSION-ID less than the "request" version ID as released. 310 If the LM-S is not able to honor sending with the requested 311 Version-ID, it should send a VERSION-ID "assign" message with 312 VERSION-ID equal to zero to indicate that all previously advertised 313 label bindings should be discarded and that the LM-S will be re- 314 advertising all bindings. The bindings to be removed needs to be 315 marked stale and purged if not reclaimed after the GR recovery 316 period. 318 Unlike the existing LDP Graceful restart behavior, after a session 319 goes down and is re-established, label bindings previously advertised 320 are not implied withdrawn, so an LM-S MUST keep track of all its 321 bindings and withdraw them. If bindings are deleted from the local 322 label binding table while a "downed" neighbor is still in a LDP GR 323 recovery period, that session must be flagged to indicate that if the 324 LDP session re-establishes, then a VERSION ID "assign" message must 325 use a value=0, to force the LM-R to purge all previously learned 326 bindings. 328 5.3. ILA Version ID=0 Handling 330 VERSION-ID=0 is a special value that MUST NOT be used as a version-id 331 value for a label mapping. If an LM-S sends a VERSION-ID assign TLV 332 with this version ID: 334 1) the LM-R upon processing this message, MUST mark all it's 335 received bindings as stale and follow LDP GR restart procedures. 337 2) The LM-S does not need to send label withdraws for previously 338 advertised bindings, as all previously advertised bindings are 339 implied withdrawn. 341 5.4. ILA Version ID Assignment 343 It's left to the implementer to decide how to assign ILA VERSION-ID 344 values to label mappings and how frequently to send per FEC type ILA 345 Version ID "assign" updates from the LM-S to the LM-R. The simplest 346 approach is to assign a unique version ID per label mapping messages. 347 Unlike BGP, LDP announcements complete in a relative short period 348 after the LDP session re-establishes, so a single ILA VERSION-ID 349 update per FEC type sent after finishing LIB advertisement completes 350 is sufficient. 352 5.5. ILA Version ID wraparound 354 The Version ID field is defined as a 64 bit value, so wraparound is 355 unlikely unless the implementer uses a fewer number of bytes 356 internally to represent the version-id. This section describes how 357 to handle this rare case. Since the each subsequent VERSION-ID needs 358 to be assigned a value greater than the previously assigned value, 359 when wraparound occurs, this situations needs to be handled otherwise 360 the ILA procedures will fail if the session resets before the re- 361 announcment updates to the LM-R completes. 363 When wraparound occurs, the LM-S MUST: 365 mark all the affected LDP peers with a "re-announcement required" 366 flag indicating that labels must be completely re-announced. 368 send an ILA VERSION-ID =1 "assign" update to reset the version id 369 to lest possible value for every affected LM-R. 371 walk entire LIB and update the VERSION-ID value of every label 372 binding. 374 reannounce all local label bindings to the affected LM-R. 376 for each affected LM-R, clear the "re-announce required" flag only 377 after VERSION-ID renumber/re-announcement is complete. 379 If the LDP session goes down and re-establishes with the "re-announce 380 require"d flag still set, the LM-S MUST respond to the LM-R 381 VERSION-ID request with a LM-S VERSION-ID "Assign" with version-id 382 set to 0 and re-announce all its bindings. 384 6. Acknowledgements 386 The authors wish to thank Bin Mo and Eric Rosen for their comments. 388 7. IANA Considerations 390 This draft require any new allocations by IANA for the 1) LDP ILA 391 capability TLV, 2) LDP ILA Version ID TLV, and 3) LDP ILA Version 392 Message.. 394 8. Security Considerations 396 This extension to LDP does not change the underlying security issues 397 inherent in the existing [RFC3478] and [RFC5036] 399 9. Normative References 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful 405 Restart Mechanism for Label Distribution Protocol", 406 RFC 3478, February 2003. 408 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 409 Specification", RFC 5036, October 2007. 411 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and J. 412 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 414 Authors' Addresses 416 Alton Lo 417 Cisco Systems 418 170 W. Tasman Drive 419 San Jose, CA 95134 420 USA 422 Email: altonlo@cisco.com 424 Keyur Patel 425 Cisco Systems 426 170 W. Tasman Drive 427 San Jose, CA 95134 428 USA 430 Email: keyupate@cisco.com 432 Vanson Lim 433 Cisco Systems 434 1414 Massachusetts Avenue 435 Boxborough, MA 01719 436 USA 438 Email: vlim@cisco.com