idnits 2.17.1 draft-ietf-idr-restart-13.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 35. -- Found old boilerplate from RFC 3978, Section 5.5 on line 589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 573. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 782 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2858 (ref. 'BGP-MP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 3392 (ref. 'BGP-CAP') (Obsoleted by RFC 5492) ** Obsolete normative reference: RFC 2385 (ref. 'BGP-AUTH') (Obsoleted by RFC 5925) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AFI' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SAFI' == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-03 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Srihari R. Sangli 3 Internet Draft Yakov Rekhter 4 Expiration Date: January 2007 Rex Fernando 5 John G. Scudder 6 Enke Chen 8 Graceful Restart Mechanism for BGP 10 draft-ietf-idr-restart-13.txt 12 Status of this Memo 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 IPR Disclosure Acknowledgement 32 By submitting this Internet-Draft, each author represents that any 33 applicable patent or other IPR claims of which he or she is aware 34 have been or will be disclosed, and any of which he or she becomes 35 aware will be disclosed, in accordance with Section 6 of BCP 79. 37 Abstract 39 This document describes a mechanism for BGP that would help minimize 40 the negative effects on routing caused by BGP restart. An End-of-RIB 41 marker is specified and can be used to convey routing convergence 42 information. A new BGP capability, termed "Graceful Restart 43 Capability", is defined which would allow a BGP speaker to express 44 its ability to preserve forwarding state during BGP restart. Finally, 45 procedures are outlined for temporarily retaining routing information 46 across a TCP session termination/re-establishment. 48 The mechanisms described in this document are applicable to all 49 routers, both those with the ability to preserve forwarding state 50 during BGP restart and those without (although the latter need to 51 implement only a subset of the mechanisms described in this 52 document). 54 1. Specification of Requirements 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC2119 [RFC2119]. 60 2. Introduction 62 Usually when BGP on a router restarts, all the BGP peers detect that 63 the session went down, and then came up. This "down/up" transition 64 results in a "routing flap" and causes BGP route re-computation, 65 generation of BGP routing updates and flap the forwarding tables. It 66 could spread across multiple routing domains. Such routing flaps may 67 create transient forwarding blackholes and/or transient forwarding 68 loops. They also consume resources on the control plane of the 69 routers affected by the flap. As such they are detrimental to the 70 overall network performance. 72 This document describes a mechanism for BGP that would help minimize 73 the negative effects on routing caused by BGP restart. An End-of-RIB 74 marker is specified and can be used to convey routing convergence 75 information. A new BGP capability, termed "Graceful Restart 76 Capability", is defined which would allow a BGP speaker to express 77 its ability to preserve forwarding state during BGP restart. Finally, 78 procedures are outlined for temporarily retaining routing information 79 across a TCP session termination/re-establishment. 81 3. Marker for End-of-RIB 83 An UPDATE message with no reachable NLRI and empty withdrawn NLRI is 84 specified as the End-Of-RIB Marker that can be used by a BGP speaker 85 to indicate to its peer the completion of the initial routing update 86 after the session is established. For IPv4 unicast address family, 87 the End-Of-RIB Marker is an UPDATE message with the minimum length 88 [BGP-4]. For any other address family, it is an UPDATE message that 89 contains only the MP_UNREACH_NLRI attribute [BGP-MP] with no 90 withdrawn routes for that . 92 Although the End-of-RIB Marker is specified for the purpose of BGP 93 graceful restart, it is noted that the generation of such a marker 94 upon completion of the initial update would be useful for routing 95 convergence in general, and thus the practice is recommended. 97 In addition, it would be beneficial for routing convergence if a BGP 98 speaker can indicate to its peer up-front that it will generate the 99 End-Of-RIB marker, regardless of its ability to preserve its 100 forwarding state during BGP restart. This can be accomplished using 101 the Graceful Restart Capability described in the next section. 103 4. Graceful Restart Capability 105 The Graceful Restart Capability is a new BGP capability [BGP-CAP] 106 that can be used by a BGP speaker to indicate its ability to preserve 107 its forwarding state during BGP restart. It can also be used to 108 convey to its peer its intention of generating the End-Of-RIB marker 109 upon the completion of its initial routing updates. 111 This capability is defined as follows: 113 Capability code: 64 115 Capability length: variable 117 Capability value: Consists of the "Restart Flags" field, "Restart 118 Time" field, and 0 to 63 of the tuples as follows: 121 +--------------------------------------------------+ 122 | Restart Flags (4 bits) | 123 +--------------------------------------------------+ 124 | Restart Time in seconds (12 bits) | 125 +--------------------------------------------------+ 126 | Address Family Identifier (16 bits) | 127 +--------------------------------------------------+ 128 | Subsequent Address Family Identifier (8 bits) | 129 +--------------------------------------------------+ 130 | Flags for Address Family (8 bits) | 131 +--------------------------------------------------+ 132 | ... | 133 +--------------------------------------------------+ 134 | Address Family Identifier (16 bits) | 135 +--------------------------------------------------+ 136 | Subsequent Address Family Identifier (8 bits) | 137 +--------------------------------------------------+ 138 | Flags for Address Family (8 bits) | 139 +--------------------------------------------------+ 141 The use and meaning of the fields are as follows: 143 Restart Flags: 145 This field contains bit flags related to restart. 147 0 1 2 3 148 +-+-+-+-+ 149 |R|Resv.| 150 +-+-+-+-+ 152 The most significant bit is defined as the Restart State (R) 153 bit which can be used to avoid possible deadlock caused by 154 waiting for the End-of-RIB marker when multiple BGP speakers 155 peering with each other restart. When set (value 1), this bit 156 indicates that the BGP speaker has restarted, and its peer MUST 157 NOT wait for the End-of-RIB marker from the speaker before 158 advertising routing information to the speaker. 160 The remaining bits are reserved, and MUST be set to zero by the 161 sender and ignored by the receiver. 163 Restart Time: 165 This is the estimated time (in seconds) it will take for the 166 BGP session to be re-established after a restart. This can be 167 used to speed up routing convergence by its peer in case that 168 the BGP speaker does not come back after a restart. 170 Address Family Identifier (AFI): 172 This field carries the identity of the Network Layer protocol 173 for which the Graceful Restart support is advertised. Presently 174 defined values for this field are specified in [IANA-AFI]. 176 Subsequent Address Family Identifier (SAFI): 178 This field provides additional information about the type of 179 the Network Layer Reachability Information carried in the 180 attribute. Presently defined values for this field are 181 specified in [IANA-SAFI]. 183 Flags for Address Family: 185 This field contains bit flags for the . 187 0 1 2 3 4 5 6 7 188 +-+-+-+-+-+-+-+-+ 189 |F| Reserved | 190 +-+-+-+-+-+-+-+-+ 192 The most significant bit is defined as the Forwarding State (F) 193 bit which can be used to indicate if the forwarding state for 194 the has indeed been preserved during the previous 195 BGP restart. When set (value 1), the bit indicates that the 196 forwarding state has been preserved. 198 The remaining bits are reserved, and MUST be set to zero by the 199 sender and ignored by the receiver. 201 When a sender of this capability doesn't include any in 202 the capability, it means that the sender is not capable of preserving 203 its forwarding state during BGP restart, but supports procedures for 204 the Receiving Speaker (as defined in Section 5.2 of this document). 205 In that case the value of the "Restart Time" field advertised by the 206 sender is irrelevant. 208 A BGP speaker MUST NOT include more than one instance of the Graceful 209 Restart Capability in the capability advertisement [BGP-CAP]. If 210 more than one instance of the Graceful Restart Capability is carried 211 in the capability advertisement, the receiver of the advertisement 212 MUST ignore all but the last instance of the Graceful Restart 213 Capability. 215 Including into the Graceful Restart 216 Capability doesn't imply that the IPv4 unicast routing information 217 should be carried by using the BGP Multiprotocol extensions [BGP-MP] 218 - it could be carried in the NLRI field of the BGP UPDATE message. 220 5. Operation 222 A BGP speaker MAY advertise the Graceful Restart Capability for an 223 address family to its peer if it has the ability to preserve its 224 forwarding state for the address family when BGP restarts. In 225 addition, even if the speaker does not have the ability to preserve 226 its forwarding state for any address family during BGP restart, it is 227 still recommended that the speaker advertise the Graceful Restart 228 Capability to its peer (as mentioned before this is done by not 229 including any in the advertised capability). There are 230 two reasons for doing this. First, to indicate its intention of 231 generating the End-of-RIB marker upon the completion of its initial 232 routing updates, as doing this would be useful for routing 233 convergence in general. Second, to indicate its support for a peer 234 which wishes to perform a graceful restart. 236 The End-of-RIB marker MUST be sent by a BGP speaker to its peer once 237 it completes the initial routing update (including the case when 238 there is no update to send) for an address family after the BGP 239 session is established. 241 It is noted that the normal BGP procedures MUST be followed when the 242 TCP session terminates due to the sending or receiving of a BGP 243 NOTIFICATION message. 245 A suggested default for the Restart Time is a value less than or 246 equal to the HOLDTIME carried in the OPEN. 248 In the following sections, "Restarting Speaker" refers to a router 249 whose BGP has restarted, and "Receiving Speaker" refers to a router 250 that peers with the restarting speaker. 252 Consider that the Graceful Restart Capability for an address family 253 is advertised by the Restarting Speaker, and is understood by the 254 Receiving Speaker, and a BGP session between them is established. 255 The following sections detail the procedures that MUST be followed by 256 the Restarting Speaker as well as the Receiving Speaker once the 257 Restarting Speaker restarts. 259 5.1. Procedures for the Restarting Speaker 261 When the Restarting Speaker restarts, it MUST retain, if possible, 262 the forwarding state for the BGP routes in the Loc-RIB, and MUST mark 263 them as stale. It MUST NOT differentiate between stale and other 264 information during forwarding. 266 To re-establish the session with its peer, the Restarting Speaker 267 MUST set the "Restart State" bit in the Graceful Restart Capability 268 of the OPEN message. Unless allowed via configuration, the 269 "Forwarding State" bit for an address family in the capability can be 270 set only if the forwarding state has indeed been preserved for that 271 address family during the restart. 273 Once the session between the Restarting Speaker and the Receiving 274 Speaker is re-established, the Restarting Speaker will receive and 275 process BGP messages from its peers. However, it MUST defer route 276 selection for an address family until it either (a) receives the End- 277 of-RIB marker from all its peers (excluding the ones with the 278 "Restart State" bit set in the received capability and excluding the 279 ones which do not advertise the graceful restart capability) or (b) 280 the Selection_Deferral_Timer referred to below has expired. It is 281 noted that prior to route selection, the speaker has no routes to 282 advertise to its peers and no routes to update the forwarding state. 284 In situations where both IGP and BGP have restarted, it might be 285 advantageous to wait for IGP to converge before the BGP speaker 286 performs route selection. 288 After the BGP speaker performs route selection, the forwarding state 289 of the speaker MUST be updated and any previously marked stale 290 information MUST be removed. The Adj-RIB-Out can then be advertised 291 to its peers. Once the initial update is complete for an address 292 family (including the case that there is no routing update to send), 293 the End-of-RIB marker MUST be sent. 295 To put an upper bound on the amount of time a router defers its route 296 selection, an implementation MUST support a (configurable) timer that 297 imposes this upper bound. This timer is referred to as the 298 "Selection_Deferral_Timer". The value of this timer should be large 299 enough, as to provide all the peers of the Restarting Speaker with 300 enough time to send all the routes to the Restarting Speaker. 302 If one wants to apply graceful restart only when the restart is 303 planned (as opposed to both planned and unplanned restart), then one 304 way to accomplish this would be to set the Forwarding State bit to 1 305 after a planned restart, and to 0 in all other cases. Other 306 approaches to accomplish this are outside the scope of this document. 308 5.2. Procedures for the Receiving Speaker 310 When the Restarting Speaker restarts, the Receiving Speaker may or 311 may not detect the termination of the TCP session with the Restarting 312 Speaker, depending on the underlying TCP implementation, whether or 313 not [BGP-AUTH] is in use, and the specific circumstances of the 314 restart. In case it does not detect the termination of the old TCP 315 session and still considers the BGP session as being established, it 316 MUST treat the subsequent open connection from the peer as an 317 indication of the termination of the old TCP session and act 318 accordingly (when the Graceful Restart Capability has been received 319 from the peer). See Section 8 for a description of this behavior in 320 terms of the BGP finite state machine. 322 "Acting accordingly" in this context means that the previous TCP 323 session MUST be closed, and the new one retained. Note that this 324 behavior differs from the default behavior, as specified in [BGP-4] 325 section 6.8. Since the previous connection is considered to be 326 terminated, no NOTIFICATION message should be sent -- the previous 327 TCP session is simply closed. 329 When the Receiving Speaker detects termination of the TCP session for 330 a BGP session with a peer that has advertised the Graceful Restart 331 Capability, it MUST retain the routes received from the peer for all 332 the address families that were previously received in the Graceful 333 Restart Capability, and MUST mark them as stale routing information. 334 To deal with possible consecutive restarts, a route (from the peer) 335 previously marked as stale MUST be deleted. The router MUST NOT 336 differentiate between stale and other routing information during 337 forwarding. 339 In re-establishing the session, the "Restart State" bit in the 340 Graceful Restart Capability of the OPEN message sent by the Receiving 341 Speaker MUST NOT be set unless the Receiving Speaker has restarted. 342 The presence and the setting of the "Forwarding State" bit for an 343 address family depends upon the actual forwarding state and 344 configuration. 346 If the session does not get re-established within the "Restart Time" 347 that the peer advertised previously, the Receiving Speaker MUST 348 delete all the stale routes from the peer that it is retaining. 350 A BGP speaker could have some way of determining whether its peer's 351 forwarding state is still viable, for example through [BFD] or 352 through monitoring layer two information. Specifics of such 353 mechanisms are beyond the scope of this document. In the event that 354 it determines that its peer's forwarding state is not viable prior to 355 the re-establishment of the session, the speaker MAY delete all the 356 stale routes from the peer that it is retaining. 358 Once the session is re-established, if the "Forwarding State" bit for 359 a specific address family is not set in the newly received Graceful 360 Restart Capability, or if a specific address family is not included 361 in the newly received Graceful Restart Capability, or if the Graceful 362 Restart Capability isn't received in the re-established session at 363 all, then Receiving Speaker MUST immediately remove all the stale 364 routes from the peer that it is retaining for that address family. 366 The Receiving Speaker MUST send the End-of-RIB marker once it 367 completes the initial update for an address family (including the 368 case that it has no routes to send) to the peer. 370 The Receiving Speaker MUST replace the stale routes by the routing 371 updates received from the peer. Once the End-of-RIB marker for an 372 address family is received from the peer, it MUST immediately remove 373 any routes from the peer that are still marked as stale for that 374 address family. 376 To put an upper bound on the amount of time a router retains the 377 stale routes, an implementation MAY support a (configurable) timer 378 that imposes this upper bound. 380 6. Changes to BGP Finite State Machine 382 As mentioned under "Procedures for the Receiving Speaker" above, this 383 specification modifies the BGP finite state machine. 385 The specific state machine modifications to [BGP-4] Section 8.2.2 are 386 as follows. 388 In the Idle state, make the following changes. 390 Replace this text: 392 - initializes all BGP resources for the peer connection, 394 with 396 - initializes all BGP resources for the peer connection, other 397 than those resources required in order to retain routes according 398 to section "Procedures for the Receiving Speaker" of this 399 (Graceful Restart) specification, 401 In the Established state, make the following changes. 403 Replace this text: 405 In response to an indication that the TCP connection is 406 successfully established (Event 16 or Event 17), the second 407 connection SHALL be tracked until it sends an OPEN message. 409 with 411 If the Graceful Restart capability with one or more AFI/SAFI has 412 not been received for the session, then in response to an 413 indication that a TCP connection is successfully established 414 (Event 16 or Event 17), the second connection SHALL be tracked 415 until it sends an OPEN message. 417 However, if the Graceful Restart capability with one or more 418 AFI/SAFI has been received for the session, then in response to 419 Event 16 or Event 17 the local system: 421 - retains all routes associated with this connection according 422 to section "Procedures for the Receiving Speaker" of this 423 (Graceful Restart) specification, 425 - releases all other BGP resources, 427 - drops the TCP connection associated with the ESTABLISHED 428 session, 430 - initializes all BGP resources for the peer connection, other 431 than those required in order to retain routes according to 432 section "Procedures for the Receiving Speaker" of this 433 specification, 435 - sets ConnectRetryCounter to zero, 437 - starts the ConnectRetryTimer with the initial value, 439 - changes its state to Connect. 441 Replace this text: 443 If the local system receives a NOTIFICATION message (Event 24 or 444 Event 25), or a TcpConnectionFails (Event 18) from the underlying 445 TCP, the local system: 447 - sets the ConnectRetryTimer to zero, 449 - deletes all routes associated with this connection, 451 - releases all the BGP resources, 453 - drops the TCP connection, 455 - increments the ConnectRetryCounter by 1, 457 - changes its state to Idle. 459 with 461 If the local system receives a NOTIFICATION message (Event 24 or 462 Event 25), or if the local system receives a TcpConnectionFails 463 (Event 18) from the underlying TCP and the Graceful Restart 464 capability with one or more AFI/SAFI has not been received for the 465 session, the local system: 467 - sets the ConnectRetryTimer to zero, 469 - deletes all routes associated with this connection, 471 - releases all the BGP resources, 473 - drops the TCP connection, 475 - increments the ConnectRetryCounter by 1, 477 - changes its state to Idle. 479 However, if the local system receives a TcpConnectionFails (Event 480 18) from the underlying TCP, and the Graceful Restart capability 481 with one or more AFI/SAFI has been received for the session, the 482 local system: 484 - sets the ConnectRetryTimer to zero, 486 - retains all routes associated with this connection according 487 to section "Procedures for the Receiving Speaker" of this 488 (Graceful Restart) specification, 490 - releases all other BGP resources, 492 - drops the TCP connection, 494 - increments the ConnectRetryCounter by 1, 496 - changes its state to Idle. 498 7. Deployment Considerations 500 While the procedures described in this document would help minimize 501 the effect of routing flaps, it is noted, however, that when a BGP 502 Graceful Restart capable router restarts, or if it restarts without 503 preserving its forwarding state (for example due to a power failure) 504 there is a potential for transient routing loops or blackholes in the 505 network if routing information changes before the involved routers 506 complete routing updates and convergence. Also, depending on the 507 network topology, if not all IBGP speakers are Graceful Restart 508 capable, there could be an increased exposure to transient routing 509 loops or blackholes when the Graceful Restart procedures are 510 exercised. 512 The Restart Time, the upper bound for retaining routes and the upper 513 bound for deferring route selection may need to be tuned as more 514 deployment experience is gained. 516 Finally, it is noted that the benefits of deploying BGP Graceful 517 Restart in an AS whose IGPs and BGP are tightly coupled (i.e., BGP 518 and IGPs would both restart) and IGPs have no similar Graceful 519 Restart capability are reduced relative to the scenario where IGPs do 520 have similar Graceful Restart capability. 522 8. Security Considerations 524 Since with this proposal a new connection can cause an old one to be 525 terminated, it might seem to open the door to denial of service 526 attacks. However, it is noted that unauthenticated BGP is already 527 known to be vulnerable to denials of service through attacks on the 528 TCP transport. The TCP transport is commonly protected through use 529 of [BGP-AUTH]. Such authentication will equally protect against 530 denials of service through spurious new connections. 532 If an attacker is able to successfully open a TCP connection 533 impersonating a legitimate peer, the attacker's connection will 534 replace the legitimate one, potentially enabling the attacker to 535 advertise bogus routes. We note, however, that the window for such a 536 route insertion attack is small since through normal operation of the 537 protocol the legitimate peer would open a new connection, in turn 538 causing the attacker's connection to be terminated. Thus, this 539 attack devolves to a form of denial of service. 541 It is thus concluded that this proposal does not change the 542 underlying security model (and issues) of BGP-4. 544 We also note that implementations may allow use of graceful restart 545 to be controlled by configuration. If graceful restart is not 546 enabled, naturally the underlying security model of BGP-4 is 547 unchanged. 549 9. Intellectual Property Considerations 551 This section is taken from Section 5 of RFC 3668. 553 The IETF takes no position regarding the validity or scope of any 554 Intellectual Property Rights or other rights that might be claimed to 555 pertain to the implementation or use of the technology described in 556 this document or the extent to which any license under such rights 557 might or might not be available; nor does it represent that it has 558 made any independent effort to identify any such rights. Information 559 on the procedures with respect to rights in RFC documents can be 560 found in BCP 78 and BCP 79. 562 Copies of IPR disclosures made to the IETF Secretariat and any 563 assurances of licenses to be made available, or the result of an 564 attempt made to obtain a general license or permission for the use of 565 such proprietary rights by implementers or users of this 566 specification can be obtained from the IETF on-line IPR repository at 567 http://www.ietf.org/ipr. 569 The IETF invites any interested party to bring to its attention any 570 copyrights, patents or patent applications, or other proprietary 571 rights that may cover technology that may be required to implement 572 this standard. Please address the information to the IETF at ietf- 573 ipr@ietf.org. 575 10. Copyright Notice 577 Copyright (C) The Internet Society (2006). 579 This document is subject to the rights, licenses and restrictions 580 contained in BCP 78, and except as set forth therein, the authors 581 retain all their rights. 583 This document and the information contained herein are provided on an 584 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 585 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 586 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 587 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 588 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 589 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 591 11. IANA Considerations 593 This document defines a new BGP Capability - Graceful Restart 594 Capability. The Capability Code for Graceful Restart Capability is 595 64. 597 12. Acknowledgments 599 The authors would like to thank Bruce Cole, Lars Eggert, Bill Fenner, 600 Eric Gray Jeffrey Haas, Sam Hartman Alvaro Retana, Pekka Savola 601 Naiming Shen, Satinder Singh, Mark Townsley, David Ward, Shane Wright 602 and Alex Zinin for their review and comments. 604 13. Normative References 606 [BGP-4] Rekhter, Y., T. Li, Hares, S., "A Border Gateway Protocol 4 607 (BGP-4)", RFC4271, January 2006. 609 [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., 610 "Multiprotocol Extensions for BGP-4", RFC2858, June 2000. 612 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with 613 BGP-4", RFC3392, November 2002. 615 [BGP-AUTH] Heffernan A., "Protection of BGP Sessions via the TCP MD5 616 Signature Option", RFC 2385, August 1998. 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, March 1997. 621 [IANA-AFI] http://www.iana.org/assignments/address-family-numbers. 623 [IANA-SAFI] http://www.iana.org/assignments/safi-namespace. 625 14. Non-normative References 627 [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection", 628 draft-ietf-bfd-base-03.txt, work in progress 630 15. Author Information 632 Srihari R. Sangli 633 Cisco Systems, Inc. 634 EMail: rsrihari@cisco.com 636 Yakov Rekhter 637 Juniper Networks, Inc. 638 EMail: yakov@juniper.net 640 Rex Fernando 641 e-mail: rex_f@yahoo.com 643 John G. Scudder 644 Cisco Systems, Inc. 645 EMail: jgs@cisco.com 647 Enke Chen 648 Cisco Systems, Inc. 649 EMail: enkechen@cisco.com