draft-ietf-idr-restart-03.txt

xorp源码hg

   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 that



draft-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 2002


11. Author Information

   Srihari R. Sangli
   Procket Networks, Inc.
   1100 Cadillac Court
   Milpitas, CA 95035
   e-mail: [e-mail]

   Yakov Rekhter
   Juniper Networks, Inc.
   1194 N. Mathilda Avenue
   Sunnyvale, CA 94089
   e-mail: [e-mail]

   Rex Fernando
   Procket Networks, Inc.
   1100 Cadillac Court
   Milpitas, CA 95035
   e-mail: [e-mail]

   John G. Scudder
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: [e-mail]

   Enke Chen
   Redback Networks, Inc.
   350 Holger Way
   San Jose, CA 95134
   e-mail: [e-mail]




















draft-ietf-idr-restart-03.txt                                   [Page 9]