draft-ietf-idr-restart-02.txt   draft-ietf-idr-restart-03.txt 
Network Working Group Srihari Ramachandra (Procket Networks) Network Working Group Srihari R. Sangli (Procket Networks)
Internet Draft Yakov Rekhter (Juniper Networks) Internet Draft Yakov Rekhter (Juniper Networks)
Expiration Date: July 2002 Rex Fernando (Procket Networks) Expiration Date: October 2002 Rex Fernando (Procket Networks)
John G. Scudder (Cisco Systems) John G. Scudder (Cisco Systems)
Enke Chen (Redback Networks) Enke Chen (Redback Networks)
Graceful Restart Mechanism for BGP Graceful Restart Mechanism for BGP
draft-ietf-idr-restart-02.txt draft-ietf-idr-restart-03.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 6, line 39 skipping to change at page 6, line 39
imposes this upper bound. imposes this upper bound.
6.2. Procedures for the Receiving Speaker 6.2. Procedures for the Receiving Speaker
When the Restarting Speaker restarts, the Receiving Speaker may or When the Restarting Speaker restarts, the Receiving Speaker may or
may not detect the termination of the TCP session with the Restarting may not detect the termination of the TCP session with the Restarting
Speaker, depending on the underlying TCP implementation, whether or Speaker, depending on the underlying TCP implementation, whether or
not [BGP-AUTH] is in use, and the specific circumstances of the not [BGP-AUTH] is in use, and the specific circumstances of the
restart. In case it does not detect the TCP reset and still restart. In case it does not detect the TCP reset and still
considers the BGP session as being established, it shall treat the considers the BGP session as being established, it shall treat the
subsequent open connection from the Restarting Speaker as an subsequent open connection from the peer as an indication of TCP
indication of TCP reset and act accordingly. reset and act accordingly (when the Graceful Restart Capabilty has
been received from the peer).
When the TCP reset is detected by the Receiving Speaker, it shall When the Receiving Speaker detects TCP reset for a BGP session with a
retain the routes received from the Restarting Speaker for all the peer that has advertised the Graceful Restart Capability, it shall
address families that were previously received in the Graceful retain the routes received from the peer for all the address families
Restart Capability, and shall mark them as stale routing information. that were previously received in the Graceful Restart Capability, and
To deal with possible consecutive restarts, a route (from the shall mark them as stale routing information. To deal with possible
Restarting Speaker) previously marked as stale shall be deleted. The consecutive restarts, a route (from the peer) previously marked as
router should not differentiate between stale and other routing stale shall be deleted. The router should not differentiate between
information during forwarding. stale and other routing information during forwarding.
In re-establishing the session, the "Restart State" bit in the In re-establishing the session, the "Restart State" bit in the
Graceful Restart Capability of the OPEN message sent by the Receiving Graceful Restart Capability of the OPEN message sent by the Receiving
Speaker shall not be set unless the Receiving Speaker has also Speaker shall not be set unless the Receiving Speaker has restarted.
restarted. The presence and the setting of the "Forwarding State" bit The presence and the setting of the "Forwarding State" bit for an
for an address family depends upon the actual forwarding state and address family depends upon the actual forwarding state and
configuration. configuration.
If the session does not get re-established within the "Restart Time" If the session does not get re-established within the "Restart Time"
that the Restarting Speaker advertised previously, the Receiving that the peer advertised previously, the Receiving Speaker shall
Speaker shall delete all the stale routes from the Restarting Speaker delete all the stale routes from the peer that it is retaining.
that it is retaining.
Once the session is re-established, if the "Forwarding State" bit for Once the session is re-established, if the "Forwarding State" bit for
an address family is not set in the received Graceful Restart an address family is not set in the received Graceful Restart
Capability, or if the capability is not received for an address Capability, or if the capability is not received for an address
family, the Receiving Speaker shall immediately remove all the stale family, the Receiving Speaker shall immediately remove all the stale
routes from the Restarting Speaker that it is retaining for that routes from the peer that it is retaining for that address family.
address family.
The Receiving Speaker shall send the End-of-RIB marker once it The Receiving Speaker shall send the End-of-RIB marker once it
completes the initial update for an address family (including the completes the initial update for an address family (including the
case that it has no routes to send) to the Restarting Speaker. case that it has no routes to send) to the peer.
The Receiving Speaker shall replace the stale routes by the routing The Receiving Speaker shall replace the stale routes by the routing
updates received from the Restarting Speaker. Once the End-of-RIB updates received from the peer. Once the End-of-RIB marker for an
marker for an address family is received from the Restarting Speaker, address family is received from the peer, it shall immediately remove
it shall immediately remove any routes from the Restarting Speaker any routes from the peer that are still marked as stale for that
that are still marked as stale for that address family. address family.
To put an upper bound on the amount of time a router retains the To put an upper bound on the amount of time a router retains the
stale routes, an implementation may support a (configurable) timer stale routes, an implementation may support a (configurable) timer
that imposes this upper bound. that imposes this upper bound.
7. Deployment Considerations 7. Deployment Considerations
While the procedures described in this document would help minimize While the procedures described in this document would help minimize
the effect of routing flaps, it is noted, however, that when a BGP the effect of routing flaps, it is noted, however, that when a BGP
Graceful-Restart capable router restarts, there is a potential for Graceful-Restart capable router restarts, there is a potential for
skipping to change at page 9, line 7 skipping to change at page 9, line 7
"Multiprotocol Extensions for BGP-4", RFC 2283, March 1998. "Multiprotocol Extensions for BGP-4", RFC 2283, March 1998.
[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
BGP-4", RFC 2842, May 2000. BGP-4", RFC 2842, May 2000.
[BGP-AUTH] Heffernan A., "Protection of BGP Sessions via the TCP MD5 [BGP-AUTH] Heffernan A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
11. Author Information 11. Author Information
Srihari Ramachandra Srihari R. Sangli
Procket Networks, Inc. Procket Networks, Inc.
1100 Cadillac Court 1100 Cadillac Court
Milpitas, CA 95035 Milpitas, CA 95035
e-mail: srihari@procket.com e-mail: srihari@procket.com
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
e-mail: yakov@juniper.net e-mail: yakov@juniper.net
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/