draft-ietf-idr-restart-01.txt		draft-ietf-idr-restart-02.txt
	Network Working Group Srihari Ramachandra (Procket Networks)		Network Working Group Srihari Ramachandra (Procket Networks)
	Internet Draft Yakov Rekhter (Juniper Networks)		Internet Draft Yakov Rekhter (Juniper Networks)
	Expiration Date: January 2002 Rex Fernando (Procket Networks)		Expiration Date: July 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-01.txt		draft-ietf-idr-restart-02.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 4, line 45		skipping to change at page 4, line 45
	The most significant bit is defined as the Forwarding State		The most significant bit is defined as the Forwarding State
	bit which can be used to indicate if the forwarding state for		bit which can be used to indicate if the forwarding state for
	the <AFI, Sub-AFI> has indeed been preserved during the previous		the <AFI, Sub-AFI> has indeed been preserved during the previous
	BGP restart. When set (value 1), the bit indicates that the		BGP restart. When set (value 1), the bit indicates that the
	forwarding state has been preserved.		forwarding state has been preserved.
	The remaining bits are reserved.		The remaining bits are reserved.
	The advertisement of this capability by a BGP speaker also implies		The advertisement of this capability by a BGP speaker also implies
	that it will generate the End-of-RIB marker upon completion of its		that it will generate the End-of-RIB marker (for all address families
	initial routing update to its peer. The value of the "Restart Time"		exchanged) upon completion of its initial routing update to its peer.
	field is irrelevant in the case that the capability does not carry		The value of the "Restart Time" field is irrelevant in the case that
	any <AFI, Sub-AFI>.		the capability does not carry any <AFI, Sub-AFI>.
	6. Operation		6. Operation
	A BGP speaker may advertise the Graceful Restart Capability for an		A BGP speaker may advertise the Graceful Restart Capability for an
	address family to its peer only if it has the ability to preserve its		address family to its peer only if it has the ability to preserve its
	forwarding state for the address family when BGP restarts.		forwarding state for the address family when BGP restarts.
	Even if the speaker does not have the ability to preserve its		Even if the speaker does not have the ability to preserve its
	forwarding state for any address family during BGP restart, it is		forwarding state for any address family during BGP restart, it is
	still recommended that the speaker advertise the Graceful Restart		still recommended that the speaker advertise the Graceful Restart
	skipping to change at page 6, line 11		skipping to change at page 6, line 11
	of the OPEN message. Unless allowed via configuration, the		of the OPEN message. Unless allowed via configuration, the
	"Forwarding State" bit for an address family in the capability can be		"Forwarding State" bit for an address family in the capability can be
	set only if the forwarding state has indeed been preserved for that		set only if the forwarding state has indeed been preserved for that
	address family during the restart.		address family during the restart.
	Once the session between the Restarting Speaker and the Receiving		Once the session between the Restarting Speaker and the Receiving
	Speaker is re-established, the Restarting Speaker will receive and		Speaker is re-established, the Restarting Speaker will receive and
	process BGP messages from its peers. However, it shall defer route		process BGP messages from its peers. However, it shall defer route
	selection for an address family until it receives the End-of-RIB		selection for an address family until it receives the End-of-RIB
	marker from all its peers (excluding the ones with the "Restart		marker from all its peers (excluding the ones with the "Restart
	State" bit set in the received capability). It is noted that prior to		State" bit set in the received capability and excluding the ones
	route selection, the speaker has no routes to advertise to its peers		which do not advertise the graceful restart capability). It is noted
	and no routes to update the forwarding state.		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		In situations where both IGP and BGP have restarted, it might be
	advantageous to wait for IGP to converge before the BGP speaker		advantageous to wait for IGP to converge before the BGP speaker
	performs route selection.		performs route selection.
	After the BGP speaker performs route selection, the forwarding state		After the BGP speaker performs route selection, the forwarding state
	of the speaker shall be updated and any previously marked stale		of the speaker shall be updated and any previously marked stale
	information shall be removed. The Adj-RIB-Out can then be advertised		information shall be removed. The Adj-RIB-Out can then be advertised
	to its peers. Once the initial update is complete for an address		to its peers. Once the initial update is complete for an address
	family (including the case that there is no routing update to send),		family (including the case that there is no routing update to send),
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/