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/