idnits 2.17.1 draft-ietf-idr-enhanced-gr-04.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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: Consider the case that both the GR Capability and the Enhanced GR Capability are exchanged between Speaker A and Speaker B, and for an AFI/SAFI the "TX Routing State" is set in the GR advertised by A, and the "RX Routing State" is also set in the GR received from B. Then Speaker A SHALL send routing information from the last update version that was previously acknowledged by Speaker B. Note that it may be advantageous for Speaker B to send an UPDATE-VERSION message acknowledging the most recent update version immediately after the session is established. Also, Speaker B MUST not follow the procedures described in [RFC4724] for purging stale routes. If the conditions specified in this paragraph are not satisfied, then the procedures described in [RFC4724] remain unchanged. -- The document date (February 5, 2014) is 3704 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'EH-RR' Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Patel 3 Internet Draft E. Chen 4 Intended Status: Standards Track R. Fernando 5 Expiration Date: August 6, 2014 Cisco Systems 6 J. Scudder 7 Juniper Networks 8 February 5, 2014 10 Accelerated Routing Convergence for BGP Graceful Restart 11 draft-ietf-idr-enhanced-gr-04.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on August 6, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Abstract 53 In this document we specify extensions to BGP graceful restart in 54 order to avoid unnecessary transmission of the routing information 55 preserved across a session restart, thus accelerating the routing 56 convergence. 58 1. Introduction 60 Currently the BGP graceful restart (GR) mechanism specified in 61 [RFC4724] requires a complete re-advertisement of the routing 62 information across a session restart, even though the routing 63 information may have been preserved. For example, as described in 64 [RFC4724], the "Receiving Speaker" temporarily maintains the routes 65 received from its neighbor with the GR Capability. In addition, the 66 "Restarting Speaker" may also be able to preserve routing information 67 across a BGP restart by check-pointing routing information to a 68 standby or secondary facility. 70 Clearly the routing re-convergence post a session restart would be 71 faster if we can avoid unnecessary transmission of the routing 72 information preserved across a session restart. That is the goal of 73 this document. 75 In this document we specify extensions to BGP graceful restart in 76 order to avoid unnecessary transmission of the routing information 77 preserved across a session restart, thus accelerating the routing 78 convergence. More specifically, we describe a "version number" based 79 mechanism for keeping track of the routing information across a 80 session restart. A new BGP message type, UPDATE-VERSION, is 81 introduced for checkpointing the update version maintained for a 82 neighbor. We also introduce the Enhanced Graceful Restart 83 Capability, and specify procedures for handling routing update across 84 a session restart. 86 1.1. Specification of Requirements 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. Version Numbers for Routing Entities 94 In order to avoid unnecessary transmission of the routing information 95 preserved across a session restart, a BGP speaker will need to 96 identify exactly "what" has been preserved by a remote speaker. 98 The approach described here is "version number" (or "sequence 99 number") based, and it consists of (a) assigning a unique, 100 monotonically increasing number as the version number for each 101 routing entity (e.g., route or message) when it is created or 102 modified; and (b) maintaining an update version (for each neighbor) 103 calculated as the maximum of the version numbers of all the routing 104 entities that have been sent to the neighbor. 106 A BGP speaker can tell whether a given routing entity has been sent 107 to a neighbor by comparing the version number of the entity with the 108 update version for the neighbor. Thus by checkpointing the update 109 version for a neighbor across a session restart, a BGP speaker would 110 be able to identify exactly "what" has been preserved by a remote 111 speaker, and also "what" remains to be sent. 113 In this document a version number is a 8-octet unsigned integer. 114 Value 0 is used to indicate the beginning (or "epoch") of the update 115 generation. The version number is not expected to wrap. However, in 116 the unlikely scenario that it does wrap, the sender MUST maintain its 117 internal consistency, and also MUST perform a route refresh [RFC2918, 118 EH-RR] toward the receiver. 120 The number space for the version numbers should be AFI/SAFI [RFC4760] 121 specific. Version numbers are also assigned (from the same number 122 space) to other AFI/SAFI specific, non-update information (such as 123 ROUTE-REFRESH [RFC2918]), and are included in the calculation of the 124 update version for a neighbor. 126 3. UPDATE-VERSION Message 128 The UPDATE-VERSION message is a new BGP message type with type code 129 . In addition to the fixed-size BGP header [RFC4271], the 130 UPDATE-VERSION message contains the following fields: 132 +------------------------------------------------+ 133 | Address Family Identifier (2 octets) | 134 +------------------------------------------------+ 135 | Subsequent Address Family Identifier (1 octet) | 136 +------------------------------------------------+ 137 | Message Subtype (1 octet) | 138 +------------------------------------------------+ 139 | Version (8 octets) | 140 +------------------------------------------------+ 142 The "Address Family Identifier" (AFI) field and the "Subsequent 143 Address Family Identifier" (SAFI) field are the same as the ones used 144 in [RFC4760]. 146 The "Message Subtype" field indicates whether the sender is (a) 147 sending an update version (value 1), (b) acknowledging the receipt of 148 an update version (value 2), or (c) requesting updates from the very 149 last update version the sender has acknowledged (value 3). 151 The Version field contains an update version associated with the 152 message subtypes 1 and 2. The value of this field is irrelevant for 153 the message subtype 3. This value of the field is opaque to the 154 receiver. 156 As detailed in the Operation section, the UPDATE-VERSION message can 157 be used by a BGP speaker to either carry an update version, or 158 acknowledge the receipt of an update version, or request updates from 159 the very last update version acknowledged. 161 4. Enhanced Graceful Restart Capability 163 The Enhanced Graceful Restart (GR) Capability is a new BGP capability 164 [RFC5492]. The Capability Code for this capability is specified in 165 the IANA Considerations section of this document. The Capability 166 Length field of this capability is 0. 168 By advertising the Enhanced GR Capability to a peer, a BGP speaker 169 conveys to the peer that the speaker is capable of receiving and 170 properly handling the UPDATE-VERSION message from the peer, as well 171 as recognizing the two new bit flags defined below for the GR 172 Capability. 174 The two new bit flags for the "Flags for Address Family" field of the 175 GR Capability are defined as follows: 177 0 1 2 3 4 5 6 7 178 +-+-+-+-+-+-+-+-+ 179 | | |R|T| | 180 +-+-+-+-+-+-+-+-+ 182 The third most significant bit (R) is defined as the "RX Routing 183 State", which is used to indicate whether during the previous session 184 restart the routes of the given AFI/SAFI that were received have 185 indeed been preserved up to the update version acknowledged by the 186 speaker previously. When set (value 1), the bit indicates that the 187 routes have been preserved. 189 The fourth most significant bit (T) is defined as the "TX Routing 190 State", which is used to indicate whether the speaker has indeed 191 preserved enough state to resume advertising routes of the given 192 AFI/SAFI from the update version acknowledged by the neighbor 193 previously. When set (value 1), the bit indicates that the state has 194 been preserved. 196 5. Operation 198 In order for a BGP speaker to be able to resume sending routing 199 information for an AFI/SAFI from the last update version that was 200 previously acknowledged by a peer, the speaker MUST maintain enough 201 state for all the routing information that has been sent until their 202 acknowledgment is received by the speaker. The routing information 203 includes reachable / unreachable information as well as other 204 AFI/SAFI specific, non-update information. Furthermore, the route 205 advertisement state needs to be maintained properly in order to 206 minimize spurious route withdraws across a session restart. 208 An implementation SHOULD impose an upper bound on how much state it 209 would maintain in the case that a receiver ("slow peer") is not able 210 to generate an acknowledgment in a timely manner. The upper bound 211 might be based on a number of factors such as the number of pending 212 unacknowledged withdraws or more generally, the volume of 213 unacknowledged state, and a timer. Once the acknowledgment from a 214 peer is not received within the specified upper bound, and the 215 maintained state is compromised, then the speaker MUST clear the "TX 216 Routing State" in the GR Capability to be advertised to the peer in 217 the next session restart. 219 A BGP speaker MAY advertise the Enhanced GR Capability to its peer if 220 the speaker is capable of receiving and properly handling the UPDATE- 221 VERSION message from the peer, and also recognizing the two new bit 222 flags in the GR Capability. If the GR Capability is to be sent by 223 the speaker, the "RX Routing State" for an AFI/SAFI in the GR 224 Capability SHOULD be set if the speaker has preserved the routing 225 information from the peer up to the update version that the speaker 226 acknowledged previously. In addition, the "TX Routing State" for an 227 AFI/SAFI in the GR Capability SHOULD be set if the speaker has 228 preserved enough routing state to resume sending messages from the 229 update version acknowledged by the peer previously. 231 When both the GR Capability and the Enhanced GR Capability are to be 232 included in an OPEN message, it is RECOMMENDED (though not required) 233 that the Enhanced GR Capability be placed ahead of the GR Capability. 235 In processing the GR Capability in an OPEN message from a peer, a BGP 236 speaker MUST NOT examine the two new bit flags defined in this 237 document for the GR Capability unless the Enhanced GR Capability is 238 also present in the OPEN message. 240 A BGP speaker MAY send an UPDATE-VERSION message to a peer only if 241 the Enhanced GR Capability is received from the peer. 243 Once a BGP speaker receives the Enhanced GR Capability from its peer, 244 the speaker SHOULD send an UPDATE-VERSION message carrying the update 245 version after sending significant amount of routing information 246 (including non-UPDATE messages) for an AFI/SAFI. This SHALL continue 247 as long as routing information is being sent. To reduce the overhead 248 by excessive number of UPDATE-VERSION messages, we highly recommend 249 the "batching" approach, that is, use one UPDATE-VERSION message to 250 cover a number of routing updates, and/or a meaningful duration of 251 time. 253 When a BGP speaker receives an UPDATE-VERSION message carrying an 254 update version, if the AFI/SAFI carried by the message does not match 255 any AFI/SAFI that the speaker is willing to receive from the peer, 256 the UPDATE-VERSION message SHALL be ignored. Otherwise, the speaker 257 MUST send an UPDATE-VERSION message back promptly acknowledging the 258 receipt of the update version. The UPDATE-VERSION messages carrying 259 the acknowledgments MUST be sent in the same order as the received 260 UPDATE-VERSION messages carrying the update versions. 262 When a BGP speakers receives an UPDATE-VERSION message acknowledging 263 an update version, the speaker MUST record this latest update version 264 being acknowledged for future use. 266 Consider the case that both the GR Capability and the Enhanced GR 267 Capability are exchanged between Speaker A and Speaker B, and for an 268 AFI/SAFI the "TX Routing State" is set in the GR advertised by A, and 269 the "RX Routing State" is also set in the GR received from B. Then 270 Speaker A SHALL send routing information from the last update version 271 that was previously acknowledged by Speaker B. Note that it may be 272 advantageous for Speaker B to send an UPDATE-VERSION message 273 acknowledging the most recent update version immediately after the 274 session is established. Also, Speaker B MUST not follow the 275 procedures described in [RFC4724] for purging stale routes. If the 276 conditions specified in this paragraph are not satisfied, then the 277 procedures described in [RFC4724] remain unchanged. 279 During the lifetime of an established session, if needed, a BGP 280 speaker MAY use the UPDATE-VERSION message to request updates from 281 the last update version that was previously acknowledged as long as 282 the speaker has received the Enhanced GR Capability from its peer. 284 When a BGP speaker receives such a request, it SHALL try to send 285 routing information from the last acknowledged update version that 286 the speaker has recorded. If the speaker is unable to do so for some 287 reason (e.g., "slow peer"), then it SHOULD perform a route refresh 288 using mechanism defined in [EH-RR] if possible. Otherwise, the BGP 289 speaker SHOULD reset the session. 291 6. Error Handling 293 This document defines a new NOTIFICATION error code: 295 Error Code Symbolic Name 297 TBD UPDATE-VERSION Message Error 299 The following error subcodes are defined as well: 301 Subcode Symbolic Name 303 1 Invalid Message Length 304 2 Invalid Message Subtype 306 If a BGP speaker detects an error while processing an UPDATE-VERSION 307 message, it MUST send a NOTIFICATION message with Error Code UPDATE- 308 VERSION Message Error. The Data field of the NOTIFICATION message 309 MUST contain the complete UPDATE-VERSION message. 311 If the Length field for the UPDATE-VERSION message is incorrect, then 312 the error subcode is set to "Invalid Message Length". 314 If the Message Subtype in the UPDATE-VERSION message is not any of 315 the defined value, then the error subcode is set to "Invalid Message 316 Subtype". 318 7. IANA Considerations 320 This document introduces the Enhanced Graceful Restart Capability. 321 The capability code needs to be assigned by IANA per [RFC5492]. 323 This document introduce a new BGP message type, UPDATE-VERSION. The 324 type code needs to be assigned by IANA. 326 In addition, this document defines an NOTIFICATION error code and 327 several error subcodes for the UPDATE-VERSION message. They need to 328 be registered with the IANA. 330 8. Security Considerations 332 This extension to BGP does not change the underlying security issues 333 inherent in the existing BGP [RFC4271, RFC4724]. 335 9. Acknowledgments 337 TBD. 339 10. Normative References 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, March 1997. 344 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 345 September 2000. 347 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 348 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 349 2006. 351 [RFC4724] Sangli, S., E. Chen, R. Rernando, J. Scudder, and Y. 352 Rekhter, "Graceful Restart Mechanism for BGP", January 353 2007 355 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 356 "Multiprotocol Extensions for BGP-4", RFC 4760, 357 January 2007. 359 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 360 with BGP-4", RFC 5492, February 2009. 362 [EH-RR] Patel, K., E. Chen and B. Venkatachalapathy, "Enhanced 363 Route Refresh Capability for BGP-4", work in progress. 365 11. Authors' Addresses 367 Keyur Patel 368 Cisco Systems 369 170 W. Tasman Drive 370 San Jose, CA 95134 371 USA 373 Email: keyupate@cisco.com 375 Enke Chen 376 Cisco Systems, Inc. 377 170 W. Tasman Dr. 378 San Jose, CA 95134 379 USA 381 EMail: enkechen@cisco.com 383 Rex Fernando 384 Cisco Systems 385 170 W. Tasman Drive 386 San Jose, CA 95134 387 USA 389 Email: rex@cisco.com 391 John Scudder 392 Juniper Networks 394 Email: jgs@juniper.net