draft-ietf-idr-restart-04.txt		draft-ietf-idr-restart-05.txt
	Network Working Group Srihari R. Sangli (Procket Networks)		Network Working Group Srihari R. Sangli (Procket Networks)
	Internet Draft Yakov Rekhter (Juniper Networks)		Internet Draft Yakov Rekhter (Juniper Networks)
	Expiration Date: December 2002 Rex Fernando (Procket Networks)		Expiration Date: December 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-04.txt		draft-ietf-idr-restart-05.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 2, line 5		skipping to change at page 1, line 45
	This document proposes a mechanism for BGP that would help minimize		This document proposes a mechanism for BGP that would help minimize
	the negative effects on routing caused by BGP restart. An End-of-RIB		the negative effects on routing caused by BGP restart. An End-of-RIB
	marker is specified and can be used to convey routing convergence		marker is specified and can be used to convey routing convergence
	information. A new BGP capability, termed "Graceful Restart		information. A new BGP capability, termed "Graceful Restart
	Capability", is defined which would allow a BGP speaker to express		Capability", is defined which would allow a BGP speaker to express
	its ability to preserve forwarding state during BGP restart. Finally,		its ability to preserve forwarding state during BGP restart. Finally,
	procedures are outlined for temporarily retaining routing information		procedures are outlined for temporarily retaining routing information
	across a TCP transport reset.		across a TCP transport reset.
			The mechanisms described in this document are applicable to all
			routers, both those with the ability to preserve forwarding state
			during BGP restart and those without (although the latter need to
			implement only a subset of the mechanisms described in this
			document).
	3. Introduction		3. Introduction
	Usually when BGP on a router restarts, all the BGP peers detect that		Usually when BGP on a router restarts, all the BGP peers detect that
	the session went down, and then came up. This "down/up" transition		the session went down, and then came up. This "down/up" transition
	results in a "routing flap" and causes BGP route re-computation,		results in a "routing flap" and causes BGP route re-computation,
	generation of BGP routing updates and flap the forwarding tables. It		generation of BGP routing updates and flap the forwarding tables. It
	could spread across multiple routing domains. Such routing flaps may		could spread across multiple routing domains. Such routing flaps may
	create transient forwarding blackholes and/or transient forwarding		create transient forwarding blackholes and/or transient forwarding
	loops. They also consume resources on the control plane of the		loops. They also consume resources on the control plane of the
	routers affected by the flap. As such they are detrimental to the		routers affected by the flap. As such they are detrimental to the
	skipping to change at page 5, line 7		skipping to change at page 5, line 7
	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, SAFI> has indeed been preserved during the previous		the <AFI, SAFI> 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, and should be set to zero by		The remaining bits are reserved, and should be set to zero by
	the sender and ignored by the receiver.		the sender and ignored by the receiver.
	When a sender of this capability doesn't include any <AFI, SAFI> in		When a sender of this capability doesn't include any <AFI, SAFI> in
	the capability, it means that the sender is not capable of preserving		the capability, it means that the sender is not capable of preserving
	its forwarding state during BGP restart, but is going to generate the		its forwarding state during BGP restart, but supports procedures for
	End-of-RIB marker upon the completion of its initial routing updates.		the Receiving Speaker (as defined in Section 6.2 of this document).
	The value of the "Restart Time" field is irrelevant in that case.		In that case the value of the "Restart Time" field advertised by the
			sender is irrelevant.
	A BGP speaker should not include more than one instance of the		A BGP speaker should not include more than one instance of the
	Graceful Restart Capability in the capability advertisement [BGP-		Graceful Restart Capability in the capability advertisement [BGP-
	CAP]. If more than one instance of the Graceful Restart Capability		CAP]. If more than one instance of the Graceful Restart Capability
	is carried in the capability advertisement, the receiver of the		is carried in the capability advertisement, the receiver of the
	advertisement should ignore all but the last instance of the Graceful		advertisement should ignore all but the last instance of the Graceful
	Restart Capability.		Restart Capability.
	Including <AFI=IPv4, SAFI=unicast> into the Graceful Restart		Including <AFI=IPv4, SAFI=unicast> into the Graceful Restart
	Capability doesn't imply that the IPv4 unicast routing information		Capability doesn't imply that the IPv4 unicast routing information
	skipping to change at page 5, line 31		skipping to change at page 5, line 32
	- it could be carried in the NLRI field of the BGP UPDATE message.		- it could be carried in the NLRI field of the BGP UPDATE message.
	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 if it has the ability to preserve its		address family to its peer if it has the ability to preserve its
	forwarding state for the address family when BGP restarts. In		forwarding state for the address family when BGP restarts. In
	addition, even if the speaker does not have the ability to preserve		addition, even if the speaker does not have the ability to preserve
	its forwarding state for any address family during BGP restart, it is		its 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
	Capability to its peer to indicate its intention of generating the		Capability to its peer (as mentioned before this is done by not
	End-of-RIB marker upon the completion of its initial routing updates		including any <AFI, SAFI> in the advertised capability). There are
	(as mentioned before this is done by not including any <AFI, SAFI> in		two reasons for doing this. First, to indicate its intention of
	the advertised capability), as doing this would be useful for routing		generating the End-of-RIB marker upon the completion of its initial
	convergence in general.		routing updates, as doing this would be useful for routing
			convergence in general. Second, to indicate its support for a peer
			which wishes to perform a graceful restart.
	The End-of-RIB marker should be sent by a BGP speaker to its peer		The End-of-RIB marker should be sent by a BGP speaker to its peer
	once it completes the initial routing update (including the case when		once it completes the initial routing update (including the case when
	there is no update to send) for an address family after the BGP		there is no update to send) for an address family after the BGP
	session is established.		session is established.
	It is noted that the normal BGP procedures must be followed when the		It is noted that the normal BGP procedures must be followed when the
	TCP session terminates due to the sending or receiving of a BGP		TCP session terminates due to the sending or receiving of a BGP
	NOTIFICATION message.		NOTIFICATION message.
	skipping to change at page 9, line 24		skipping to change at page 9, line 24
	It is thus concluded that this proposal does not change the		It is thus concluded that this proposal does not change the
	underlying security model (and issues) of BGP-4.		underlying security model (and issues) of BGP-4.
	9. Acknowledgments		9. Acknowledgments
	The authors would like to thank Bruce Cole, Bill Fenner, Eric Gray		The authors would like to thank Bruce Cole, Bill Fenner, Eric Gray
	Jeffrey Haas, Alvaro Retana, Naiming Shen, Satinder Singh, David		Jeffrey Haas, Alvaro Retana, Naiming Shen, Satinder Singh, David
	Ward, Shane Wright and Alex Zinin for their review and comments.		Ward, Shane Wright and Alex Zinin for their review and comments.
	10. References		10. Normative References
	[BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-		[BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-
	4)", RFC 1771, March 1995.		4)", RFC 1771, March 1995.
	[BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y.,		[BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y.,
	"Multiprotocol Extensions for BGP-4", RFC2858, June 2000.		"Multiprotocol Extensions for BGP-4", RFC2858, June 2000.
	[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with		[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
	BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002.		BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/