--- 1/draft-ietf-idr-restart-04.txt 2006-02-04 23:31:22.000000000 +0100 +++ 2/draft-ietf-idr-restart-05.txt 2006-02-04 23:31:22.000000000 +0100 @@ -1,20 +1,20 @@ Network Working Group Srihari R. Sangli (Procket Networks) Internet Draft Yakov Rekhter (Juniper Networks) Expiration Date: December 2002 Rex Fernando (Procket Networks) John G. Scudder (Cisco Systems) Enke Chen (Redback Networks) Graceful Restart Mechanism for BGP - draft-ietf-idr-restart-04.txt + draft-ietf-idr-restart-05.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -34,20 +34,26 @@ This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. + The mechanisms described in this document are applicable to all + routers, both those with the ability to preserve forwarding state + during BGP restart and those without (although the latter need to + implement only a subset of the mechanisms described in this + document). + 3. Introduction Usually when BGP on a router restarts, all the BGP peers detect that the session went down, and then came up. This "down/up" transition results in a "routing flap" and causes BGP route re-computation, generation of BGP routing updates and flap the forwarding tables. It could spread across multiple routing domains. Such routing flaps may create transient forwarding blackholes and/or transient forwarding loops. They also consume resources on the control plane of the routers affected by the flap. As such they are detrimental to the @@ -176,23 +182,24 @@ bit which can be used to indicate if the forwarding state for the has indeed been preserved during the previous BGP restart. When set (value 1), the bit indicates that the forwarding state has been preserved. The remaining bits are reserved, and should be set to zero by the sender and ignored by the receiver. When a sender of this capability doesn't include any in the capability, it means that the sender is not capable of preserving - its forwarding state during BGP restart, but is going to generate the - End-of-RIB marker upon the completion of its initial routing updates. - The value of the "Restart Time" field is irrelevant in that case. + its forwarding state during BGP restart, but supports procedures for + the Receiving Speaker (as defined in Section 6.2 of this document). + In that case the value of the "Restart Time" field advertised by the + sender is irrelevant. A BGP speaker should not include more than one instance of the Graceful Restart Capability in the capability advertisement [BGP- CAP]. If more than one instance of the Graceful Restart Capability is carried in the capability advertisement, the receiver of the advertisement should ignore all but the last instance of the Graceful Restart Capability. Including into the Graceful Restart Capability doesn't imply that the IPv4 unicast routing information @@ -200,25 +207,27 @@ - it could be carried in the NLRI field of the BGP UPDATE message. 6. Operation A BGP speaker may advertise the Graceful Restart Capability for an address family to its peer if it has the ability to preserve its forwarding state for the address family when BGP restarts. In addition, even if the speaker does not have the ability to preserve its forwarding state for any address family during BGP restart, it is still recommended that the speaker advertise the Graceful Restart - Capability to its peer to indicate its intention of generating the - End-of-RIB marker upon the completion of its initial routing updates - (as mentioned before this is done by not including any in - the advertised capability), as doing this would be useful for routing - convergence in general. + Capability to its peer (as mentioned before this is done by not + including any in the advertised capability). There are + two reasons for doing this. First, to indicate its intention of + generating the End-of-RIB marker upon the completion of its initial + routing updates, as doing this would be useful for routing + convergence in general. Second, to indicate its support for a peer + which wishes to perform a graceful restart. The End-of-RIB marker should be sent by a BGP speaker to its peer once it completes the initial routing update (including the case when there is no update to send) for an address family after the BGP session is established. It is noted that the normal BGP procedures must be followed when the TCP session terminates due to the sending or receiving of a BGP NOTIFICATION message. @@ -376,21 +385,21 @@ It is thus concluded that this proposal does not change the underlying security model (and issues) of BGP-4. 9. Acknowledgments The authors would like to thank Bruce Cole, Bill Fenner, Eric Gray Jeffrey Haas, Alvaro Retana, Naiming Shen, Satinder Singh, David Ward, Shane Wright and Alex Zinin for their review and comments. -10. References +10. Normative References [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP- 4)", RFC 1771, March 1995. [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., "Multiprotocol Extensions for BGP-4", RFC2858, June 2000. [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002.