In the following sections, "Restarting Speaker" refers to a router   whose BGP has restarted, and "Receiving Speaker" refers to a router   that peers with the restarting speaker.   Consider that the Graceful Restart Capability for an address family   is advertised by the Restarting Speaker, and is understood by the   Receiving Speaker, and a BGP session between them is established.   The following sections detail the procedures that shall be followed   by the Restarting Speaker as well as the Receiving Speaker once the   Restarting Speaker restarts.6.1. Procedures for the Restarting Speaker   When the Restarting Speaker restarts, if possible it shall retain the   forwarding state for the BGP routes in the Loc-RIB, and shall mark   them as stale.  It should not differentiate between stale and other   information during forwarding.   To re-establish the session with its peer, the Restarting Speaker   must set the "Restart State" bit in the Graceful Restart Capability   of the OPEN message.  Unless allowed via configuration, the   "Forwarding State" bit for an address family in the capability can be   set only if the forwarding state has indeed been preserved for thatdraft-ietf-idr-restart-03.txt                                   [Page 5]Internet Draft        draft-ietf-idr-restart-03.txt           April 2002   address family during the restart.   Once the session between the Restarting Speaker and the Receiving   Speaker is re-established, the Restarting Speaker will receive and   process BGP messages from its peers. However, it shall defer route   selection for an address family until it receives the End-of-RIB   marker from all its peers (excluding the ones with the "Restart   State" bit set in the received capability and excluding the ones   which do not advertise the graceful restart capability).  It is noted   that prior to route selection, the speaker has no routes to advertise   to its peers and no routes to update the forwarding state.   In situations where both IGP and BGP have restarted, it might be   advantageous to wait for IGP to converge before the BGP speaker   performs route selection.   After the BGP speaker performs route selection, the forwarding state   of the speaker shall be updated and any previously marked stale   information shall be removed. The Adj-RIB-Out can then be advertised   to its peers. Once the initial update is complete for an address   family (including the case that there is no routing update to send),   the End-of-RIB marker shall be sent.   To put an upper bound on the amount of time a router defers its route   selection, an implementation must support a (configurable) timer that   imposes this upper bound.6.2. Procedures for the Receiving Speaker   When the Restarting Speaker restarts, the Receiving Speaker may or   may not detect the termination of the TCP session with the Restarting   Speaker, depending on the underlying TCP implementation, whether or   not [BGP-AUTH] is in use, and the specific circumstances of the   restart.  In case it does not detect the TCP reset and still   considers the BGP session as being established, it shall treat the   subsequent open connection from the peer as an indication of TCP   reset and act accordingly (when the Graceful Restart Capabilty has   been received from the peer).   When the Receiving Speaker detects TCP reset for a BGP session with a   peer that has advertised the Graceful Restart Capability, it shall   retain the routes received from the peer for all the address families   that were previously received in the Graceful Restart Capability, and   shall mark them as stale routing information. To deal with possible   consecutive restarts, a route (from the peer) previously marked as   stale shall be deleted. The router should not differentiate between   stale and other routing information during forwarding.draft-ietf-idr-restart-03.txt                                   [Page 6]Internet Draft        draft-ietf-idr-restart-03.txt           April 2002   In re-establishing the session, the "Restart State" bit in the   Graceful Restart Capability of the OPEN message sent by the Receiving   Speaker shall not be set unless the Receiving Speaker has restarted.   The presence and the setting of the "Forwarding State" bit for an   address family depends upon the actual forwarding state and   configuration.   If the session does not get re-established within the "Restart Time"   that the peer advertised previously, the Receiving Speaker shall   delete all the stale routes from the peer that it is retaining.   Once the session is re-established, if the "Forwarding State" bit for   an address family is not set in the received Graceful Restart   Capability, or if the capability is not received for an address   family, the Receiving Speaker shall immediately remove all the stale   routes from the peer that it is retaining for that address family.   The Receiving Speaker shall send the End-of-RIB marker once it   completes the initial update for an address family (including the   case that it has no routes to send) to the peer.   The Receiving Speaker shall replace the stale routes by the routing   updates received from the peer. Once the End-of-RIB marker for an   address family is received from the peer, it shall immediately remove   any routes from the peer that are still marked as stale for that   address family.   To put an upper bound on the amount of time a router retains the   stale routes, an implementation may support a (configurable) timer   that imposes this upper bound.7. Deployment Considerations   While the procedures described in this document would help minimize   the effect of routing flaps, it is noted, however, that when a BGP   Graceful-Restart capable router restarts, there is a potential for   transient routing loops or blackholes in the network if routing   information changes before the involved routers complete routing   updates and convergence. Also, depending on the network topology, if   not all IBGP speakers are Graceful-Restart capable, there could be an   increased exposure to transient routing loops or blackholes when the   Graceful-Restart procedures are exercised.   The Restart Time, the upper bound for retaining routes and the upper   bound for deferring route selection may need to be tuned as more   deployment experience is gained.draft-ietf-idr-restart-03.txt                                   [Page 7]Internet Draft        draft-ietf-idr-restart-03.txt           April 2002   Finally, it is noted that there is little benefit deploying BGP   Graceful-Restart in an AS whose IGPs and BGP are tightly coupled   (i.e., BGP and IGPs would both restart), and IGPs have no similar   Graceful-Restart capability.8. Security Considerations   Since with this proposal a new connection can cause an old one to be   terminated, it might seem to open the door to denial of service   attacks.  However, it is noted that unauthenticated BGP is already   known to be vulnerable to denials of service through attacks on the   TCP transport.  The TCP transport is commonly protected through use   of [BGP-AUTH]. Such authentication will equally protect against   denials of service through spurious new connections.   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 Alvaro Retana, Satinder Singh, David   Ward, Naiming Shen and Bruce Cole for their review and comments.10. 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", RFC 2283, March 1998.   [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with   BGP-4", RFC 2842, May 2000.   [BGP-AUTH] Heffernan A., "Protection of BGP Sessions via the TCP MD5   Signature Option", RFC 2385, August 1998.draft-ietf-idr-restart-03.txt                                   [Page 8]Internet Draft        draft-ietf-idr-restart-03.txt           April 200211. Author Information   Srihari R. Sangli   Procket Networks, Inc.   1100 Cadillac Court   Milpitas, CA 95035   e-mail: srihari@procket.com   Yakov Rekhter   Juniper Networks, Inc.   1194 N. Mathilda Avenue   Sunnyvale, CA 94089   e-mail: yakov@juniper.net   Rex Fernando   Procket Networks, Inc.   1100 Cadillac Court   Milpitas, CA 95035   e-mail: rex@procket.com   John G. Scudder   Cisco Systems, Inc.   170 West Tasman Drive   San Jose, CA 95134   e-mail: jgs@cisco.com   Enke Chen   Redback Networks, Inc.   350 Holger Way   San Jose, CA 95134   e-mail: enke@redback.comdraft-ietf-idr-restart-03.txt                                   [Page 9]