draft-ietf-idr-restart-09.txt		draft-ietf-idr-restart-10.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: October 2004 Rex Fernando (Procket Networks)		Expiration Date: December 2004 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-09.txt		draft-ietf-idr-restart-10.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 7, line 30		skipping to change at page 7, line 30
	7.2. Procedures for the Receiving Speaker		7.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 peer as an indication of TCP		subsequent open connection from the peer as an indication of TCP
	reset and act accordingly (when the Graceful Restart Capability has		reset and act accordingly (when the Graceful Restart Capability has
	been received from the peer).		been received from the peer). See Section 8 for a description of this
			behavior in terms of the BGP finite state machine.
	"Acting accordingly" in this context means that the previous TCP		"Acting accordingly" in this context means that the previous TCP
	session SHOULD be closed, and the new one retained. Note that this		session SHOULD be closed, and the new one retained. Note that this
	behavior differs from the default behavior, as specified in [BGP-4]		behavior differs from the default behavior, as specified in [BGP-4]
	section 6.8. Since the previous connection is considered to be		section 6.8. Since the previous connection is considered to be
	reset, no NOTIFICATION message should be sent -- the previous TCP		reset, no NOTIFICATION message should be sent -- the previous TCP
	session is simply closed.		session is simply closed.
	When the Receiving Speaker detects TCP reset for a BGP session with a		When the Receiving Speaker detects TCP reset for a BGP session with a
	peer that has advertised the Graceful Restart Capability, it SHALL		peer that has advertised the Graceful Restart Capability, it SHALL
	skipping to change at page 8, line 35		skipping to change at page 8, line 35
	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 peer. Once the End-of-RIB marker for an		updates received from the peer. Once the End-of-RIB marker for an
	address family is received from the peer, it SHALL immediately remove		address family is received from the peer, it SHALL immediately remove
	any routes from the peer that are still marked as stale for that		any routes from the peer 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.
	8. Deployment Considerations		8. Changes to BGP Finite State Machine
			As mentioned under "Procedures for the Receiving Speaker" above, this
			specification modifies the BGP finite state machine.
			The specific state machine modifications to [BGP-4] Section 8.2.2 are
			as follows. In the Established state, replace this text:
			If a TcpConnection_Valid (Event 14) or Tcp_CR_Acked (Event 16) is
			received, or a TcpConnectionConfirmed event (Event 17) is
			received, a second TCP connection may be in progress. This second
			TCP connection is tracked per Connection Collision processing
			(Section 6.8) until an OPEN message is received.
			with this:
			If a TcpConnection_Valid (Event 14) or Tcp_CR_Acked (Event 16) is
			received, a second TCP connection may be in progress. This second
			TCP connection is tracked per Connection Collision processing
			(Section 6.8) until an OPEN message is received.
			If the Graceful Restart capability with one or more AFI/SAFI has
			been received for the session, then TcpConnectionConfirmed (Event
			17) is treated as TcpConnectionFails (Event 18).
			If a TcpConnectionConfirmed event (Event 17) is received and if
			the Graceful Restart capability with one or more AFI/SAFI has not
			been received for the session, a second TCP connection may be in
			progress. This second TCP connection is tracked per Connection
			Collision processing (Section 6.8) until an OPEN message is
			received.
			9. 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
	transient routing loops or blackholes in the network if routing		transient routing loops or blackholes in the network if routing
	information changes before the involved routers complete routing		information changes before the involved routers complete routing
	updates and convergence. Also, depending on the network topology, if		updates and convergence. Also, depending on the network topology, if
	not all IBGP speakers are Graceful Restart capable, there could be an		not all IBGP speakers are Graceful Restart capable, there could be an
	increased exposure to transient routing loops or blackholes when the		increased exposure to transient routing loops or blackholes when the
	Graceful Restart procedures are exercised.		Graceful Restart procedures are exercised.
	skipping to change at page 9, line 9		skipping to change at page 10, line 5
	The Restart Time, the upper bound for retaining routes and the upper		The Restart Time, the upper bound for retaining routes and the upper
	bound for deferring route selection may need to be tuned as more		bound for deferring route selection may need to be tuned as more
	deployment experience is gained.		deployment experience is gained.
	Finally, it is noted that the benefits of deploying BGP Graceful		Finally, it is noted that the benefits of deploying BGP Graceful
	Restart in an AS whose IGPs and BGP are tightly coupled (i.e., BGP		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		and IGPs would both restart) and IGPs have no similar Graceful
	Restart capability are reduced relative to the scenario where IGPs do		Restart capability are reduced relative to the scenario where IGPs do
	have similar Graceful Restart capability.		have similar Graceful Restart capability.
	9. Security Considerations		10. Security Considerations
	Since with this proposal a new connection can cause an old one to be		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		terminated, it might seem to open the door to denial of service
	attacks. However, it is noted that unauthenticated BGP is already		attacks. However, it is noted that unauthenticated BGP is already
	known to be vulnerable to denials of service through attacks on the		known to be vulnerable to denials of service through attacks on the
	TCP transport. The TCP transport is commonly protected through use		TCP transport. The TCP transport is commonly protected through use
	of [BGP-AUTH]. Such authentication will equally protect against		of [BGP-AUTH]. Such authentication will equally protect against
	denials of service through spurious new connections.		denials of service through spurious new connections.
	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.
	10. Acknowledgments		11. 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.
	11. Normative References		12. Normative References
	[BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-		[BGP-4] Rekhter, Y., T. Li, Hares, S., "A Border Gateway Protocol 4
	4)", RFC 1771, March 1995.		(BGP- 4)", work in progress.
	[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.
	[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.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[IANA-AFI] http://www.iana.org/assignments/address-family-numbers.		[IANA-AFI] http://www.iana.org/assignments/address-family-numbers.
	[IANA-SAFI] http://www.iana.org/assignments/safi-namespace.		[IANA-SAFI] http://www.iana.org/assignments/safi-namespace.
	12. Author Information		13. Author Information
	Srihari R. Sangli		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
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/