idnits 2.17.1 draft-ietf-idr-enhanced-gr-06.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 -- The document date (June 7, 2016) is 2877 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Patel 3 Internet-Draft E. Chen 4 Intended status: Informational R. Fernando 5 Expires: December 9, 2016 Cisco Systems 6 J. Scudder 7 Juniper Networks 8 June 7, 2016 10 Accelerated Routing Convergence for BGP Graceful Restart 11 draft-ietf-idr-enhanced-gr-06.txt 13 Abstract 15 In this document we specify extensions to BGP graceful restart in 16 order to avoid unnecessary transmission of the routing information 17 preserved across a session restart, thus accelerating the routing 18 convergence. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on December 9, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Version Numbers for Routing Entities . . . . . . . . . . . . 3 57 3. UPDATE-VERSION Message . . . . . . . . . . . . . . . . . . . 3 58 4. Enhanced Graceful Restart Capability . . . . . . . . . . . . 4 59 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 7 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 Currently the BGP graceful restart (GR) mechanism specified in 70 [RFC4724] requires a complete re-advertisement of the routing 71 information across a session restart, even though the routing 72 information may have been preserved. For example, as described in 73 [RFC4724], the "Receiving Speaker" temporarily maintains the routes 74 received from its neighbor with the GR Capability. In addition, the 75 "Restarting Speaker" may also be able to preserve routing information 76 across a BGP restart by check-pointing routing information to a 77 standby or secondary facility. 79 Clearly the routing re-convergence post a session restart would be 80 faster if we can avoid unnecessary transmission of the routing 81 information preserved across a session restart. That is the goal of 82 this document. 84 In this document we specify extensions to BGP graceful restart in 85 order to avoid unnecessary transmission of the routing information 86 preserved across a session restart, thus accelerating the routing 87 convergence. More specifically, we describe a "version number" based 88 mechanism for keeping track of the routing information across a 89 session restart. A new BGP message type, UPDATE-VERSION, is 90 introduced for checkpointing the update version maintained for a 91 neighbor. We also introduce the Enhanced Graceful Restart 92 Capability, and specify procedures for handling routing update across 93 a session restart. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Version Numbers for Routing Entities 103 In order to avoid unnecessary transmission of the routing information 104 preserved across a session restart, a BGP speaker will need to 105 identify exactly "what" has been preserved by a remote speaker. 107 The approach described here is "version number" (or "sequence 108 number") based, and it consists of (a) assigning a unique, 109 monotonically increasing number as the version number for each 110 routing entity (e.g., route or message) when it is created or 111 modified; and (b) maintaining an update version (for each neighbor) 112 calculated as the maximum of the version numbers of all the routing 113 entities that have been sent to the neighbor. 115 A BGP speaker can tell whether a given routing entity has been sent 116 to a neighbor by comparing the version number of the entity with the 117 update version for the neighbor. Thus by checkpointing the update 118 version for a neighbor across a session restart, a BGP speaker would 119 be able to identify exactly "what" has been preserved by a remote 120 speaker, and also "what" remains to be sent. 122 In this document a version number is a 8-octet unsigned integer. 123 Value 0 is used to indicate the beginning (or "epoch") of the update 124 generation. The version number is not expected to wrap. However, in 125 the unlikely scenario that it does wrap, the sender MUST maintain its 126 internal consistency, and also MUST perform a route refresh 127 [RFC2918], [RFC7313] toward the receiver. 129 The number space for the version numbers should be AFI/SAFI [RFC4760] 130 specific. Version numbers are also assigned (from the same number 131 space) to other AFI/SAFI specific, non-update information (such as 132 ROUTE-REFRESH [RFC2918]), and are included in the calculation of the 133 update version for a neighbor. 135 3. UPDATE-VERSION Message 137 The UPDATE-VERSION message is a new BGP message type with type code 138 . In addition to the fixed-size BGP header [RFC4271], the 139 UPDATE-VERSION message contains the following fields: 141 +------------------------------------------------+ 142 | Address Family Identifier (2 octets) | 143 +------------------------------------------------+ 144 | Subsequent Address Family Identifier (1 octet) | 145 +------------------------------------------------+ 146 | Message Subtype (1 octet) | 147 +------------------------------------------------+ 148 | Version (8 octets) | 149 +------------------------------------------------+ 151 The "Address Family Identifier" (AFI) field and the "Subsequent 152 Address Family Identifier" (SAFI) field are the same as the ones used 153 in [RFC4760]. 155 The "Message Subtype" field indicates whether the sender is (a) 156 sending an update version (value 1), (b) acknowledging the receipt of 157 an update version (value 2), or (c) requesting updates from the very 158 last update version the sender has acknowledged (value 3). 160 The Version field contains an update version associated with the 161 message subtypes 1 and 2. The value of this field is irrelevant for 162 the message subtype 3. This value of the field is opaque to the 163 receiver. 165 As detailed in the Operation section, the UPDATE-VERSION message can 166 be used by a BGP speaker to either carry an update version, or 167 acknowledge the receipt of an update version, or request updates from 168 the very last update version acknowledged. 170 4. Enhanced Graceful Restart Capability 172 The Enhanced Graceful Restart (GR) Capability is a new BGP capability 173 [RFC5492]. The Capability Code for this capability is specified in 174 the IANA Considerations section of this document. The Capability 175 Length field of this capability is 0. 177 By advertising the Enhanced GR Capability to a peer, a BGP speaker 178 conveys to the peer that the speaker is capable of receiving and 179 properly handling the UPDATE-VERSION message from the peer, as well 180 as recognizing the two new bit flags defined below for the GR 181 Capability. 183 The two new bit flags for the "Flags for Address Family" field of the 184 GR Capability are defined as follows: 186 0 1 2 3 4 5 6 7 187 +-+-+-+-+-+-+-+-+ 188 | | |R|T| | 189 +-+-+-+-+-+-+-+-+ 191 The third most significant bit (R) is defined as the "RX Routing 192 State", which is used to indicate whether during the previous session 193 restart the routes of the given AFI/SAFI that were received have 194 indeed been preserved up to the update version acknowledged by the 195 speaker previously. When set (value 1), the bit indicates that the 196 routes have been preserved. 198 The fourth most significant bit (T) is defined as the "TX Routing 199 State", which is used to indicate whether the speaker has indeed 200 preserved enough state to resume advertising routes of the given AFI/ 201 SAFI from the update version acknowledged by the neighbor previously. 202 When set (value 1), the bit indicates that the state has been 203 preserved. 205 5. Operation 207 In order for a BGP speaker to be able to resume sending routing 208 information for an AFI/SAFI from the last update version that was 209 previously acknowledged by a peer, the speaker MUST maintain enough 210 state for all the routing information that has been sent until their 211 acknowledgment is received by the speaker. The routing information 212 includes reachable / unreachable information as well as other AFI/ 213 SAFI specific, non-update information. Furthermore, the route 214 advertisement state needs to be maintained properly in order to 215 minimize spurious route withdraws across a session restart. 217 An implementation SHOULD impose an upper bound on how much state it 218 would maintain in the case that a receiver ("slow peer") is not able 219 to generate an acknowledgment in a timely manner. The upper bound 220 might be based on a number of factors such as the number of pending 221 unacknowledged withdraws or more generally, the volume of 222 unacknowledged state, and a timer. Once the acknowledgment from a 223 peer is not received within the specified upper bound, and the 224 maintained state is compromised, then the speaker MUST clear the "TX 225 Routing State" in the GR Capability to be advertised to the peer in 226 the next session restart. 228 A BGP speaker MAY advertise the Enhanced GR Capability to its peer if 229 the speaker is capable of receiving and properly handling the UPDATE- 230 VERSION message from the peer, and also recognizing the two new bit 231 flags in the GR Capability. If the GR Capability is to be sent by 232 the speaker, the "RX Routing State" for an AFI/SAFI in the GR 233 Capability SHOULD be set if the speaker has preserved the routing 234 information from the peer up to the update version that the speaker 235 acknowledged previously. In addition, the "TX Routing State" for an 236 AFI/SAFI in the GR Capability SHOULD be set if the speaker has 237 preserved enough routing state to resume sending messages from the 238 update version acknowledged by the peer previously. 240 When both the GR Capability and the Enhanced GR Capability are to be 241 included in an OPEN message, it is RECOMMENDED (though not required) 242 that the Enhanced GR Capability be placed ahead of the GR Capability. 244 In processing the GR Capability in an OPEN message from a peer, a BGP 245 speaker MUST NOT examine the two new bit flags defined in this 246 document for the GR Capability unless the Enhanced GR Capability is 247 also present in the OPEN message. 249 A BGP speaker MAY send an UPDATE-VERSION message to a peer only if 250 the Enhanced GR Capability is received from the peer. 252 Once a BGP speaker receives the Enhanced GR Capability from its peer, 253 the speaker SHOULD send an UPDATE-VERSION message carrying the update 254 version after sending significant amount of routing information 255 (including non-UPDATE messages) for an AFI/SAFI. This SHALL continue 256 as long as routing information is being sent. To reduce the overhead 257 by excessive number of UPDATE-VERSION messages, we highly recommend 258 the "batching" approach, that is, use one UPDATE-VERSION message to 259 cover a number of routing updates, and/or a meaningful duration of 260 time. 262 When a BGP speaker receives an UPDATE-VERSION message carrying an 263 update version, if the AFI/SAFI carried by the message does not match 264 any AFI/SAFI that the speaker is willing to receive from the peer, 265 the UPDATE-VERSION message SHALL be ignored. Otherwise, the speaker 266 MUST send an UPDATE-VERSION message back promptly acknowledging the 267 receipt of the update version. The UPDATE-VERSION messages carrying 268 the acknowledgments MUST be sent in the same order as the received 269 UPDATE-VERSION messages carrying the update versions. 271 When a BGP speakers receives an UPDATE-VERSION message acknowledging 272 an update version, the speaker MUST record this latest update version 273 being acknowledged for future use. 275 Consider the case that both the GR Capability and the Enhanced GR 276 Capability are exchanged between Speaker A and Speaker B, and for an 277 AFI/SAFI the "TX Routing State" is set in the GR advertised by A, and 278 the "RX Routing State" is also set in the GR received from B. Then 279 Speaker A SHALL send routing information from the last update version 280 that was previously acknowledged by Speaker B. Note that it may be 281 advantageous for Speaker B to send an UPDATE-VERSION message 282 acknowledging the most recent update version immediately after the 283 session is established. Also, Speaker B MUST NOT follow the 284 procedures described in [RFC4724] for purging stale routes. If the 285 conditions specified in this paragraph are not satisfied, then the 286 procedures described in [RFC4724] remain unchanged. 288 During the lifetime of an established session, if needed, a BGP 289 speaker MAY use the UPDATE-VERSION message to request updates from 290 the last update version that was previously acknowledged as long as 291 the speaker has received the Enhanced GR Capability from its peer. 293 When a BGP speaker receives such a request, it SHALL try to send 294 routing information from the last acknowledged update version that 295 the speaker has recorded. If the speaker is unable to do so for some 296 reason (e.g., "slow peer"), then it SHOULD perform a route refresh 297 using mechanism defined in [RFC7313] if possible. Otherwise, the BGP 298 speaker SHOULD reset the session. 300 6. Error Handling 302 This document defines a new NOTIFICATION error code: 304 +------------+------------------------------+ 305 | Error Code | Symbolic Name | 306 +------------+------------------------------+ 307 | TBD | UPDATE-VERSION Message Error | 308 +------------+------------------------------+ 310 The following error subcodes are defined as well: 312 +--------+-------------------------+ 313 | Subode | Symbolic Name | 314 +--------+-------------------------+ 315 | 1 | Invalid Message Length | 316 | 2 | Invalid Message Subtype | 317 +--------+-------------------------+ 319 If a BGP speaker detects an error while processing an UPDATE-VERSION 320 message, it MUST send a NOTIFICATION message with Error Code UPDATE- 321 VERSION Message Error. The Data field of the NOTIFICATION message 322 MUST contain the complete UPDATE-VERSION message. 324 If the Length field for the UPDATE-VERSION message is incorrect, then 325 the error subcode is set to "Invalid Message Length". 327 If the Message Subtype in the UPDATE-VERSION message is not any of 328 the defined value, then the error subcode is set to "Invalid Message 329 Subtype". 331 7. Acknowledgements 333 Thanks to Jonathan Looney for valuable review and suggestions. 335 8. IANA Considerations 337 This document introduces the Enhanced Graceful Restart Capability. 338 The capability code needs to be assigned by IANA per [RFC5492]. 340 This document introduce a new BGP message type, UPDATE-VERSION. The 341 type code needs to be assigned by IANA. 343 In addition, this document defines an NOTIFICATION error code and 344 several error subcodes for the UPDATE-VERSION message. They need to 345 be registered with the IANA. 347 9. Security Considerations 349 This extension to BGP does not change the underlying security issues 350 inherent in the existing BGP [RFC4271] [RFC4724]. 352 10. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, 356 DOI 10.17487/RFC2119, March 1997, 357 . 359 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 360 DOI 10.17487/RFC2918, September 2000, 361 . 363 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 364 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 365 DOI 10.17487/RFC4271, January 2006, 366 . 368 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 369 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 370 DOI 10.17487/RFC4724, January 2007, 371 . 373 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 374 "Multiprotocol Extensions for BGP-4", RFC 4760, 375 DOI 10.17487/RFC4760, January 2007, 376 . 378 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 379 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 380 2009, . 382 [RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced 383 Route Refresh Capability for BGP-4", RFC 7313, 384 DOI 10.17487/RFC7313, July 2014, 385 . 387 Authors' Addresses 389 Keyur Patel 390 Cisco Systems 391 170 W. Tasman Drive 392 San Jose, CA 95134 393 USA 395 Email: keyupate@cisco.com 397 Enke Chen 398 Cisco Systems 399 170 W. Tasman Drive 400 San Jose, CA 95134 401 USA 403 Email: enkechen@cisco.com 405 Rex Fernando 406 Cisco Systems 407 170 W. Tasman Drive 408 San Jose, CA 95134 409 USA 411 Email: rex@cisco.com 413 John Scudder 414 Juniper Networks 415 1133 Innovation Way 416 Sunnyvale, CA 94089 417 USA 419 Email: jgs@juniper.net