draft-ietf-idr-restart-10.txt		draft-ietf-idr-restart-11.txt
	Network Working Group Srihari R. Sangli (Procket Networks)		Network Working Group Srihari R. Sangli
	Internet Draft Yakov Rekhter (Juniper Networks)		Internet Draft Yakov Rekhter
	Expiration Date: December 2004 Rex Fernando (Procket Networks)		Expiration Date: November 2006 Rex Fernando
	John G. Scudder (Cisco Systems)		John G. Scudder
	Enke Chen (Redback Networks)		Enke Chen
	Graceful Restart Mechanism for BGP		Graceful Restart Mechanism for BGP
	draft-ietf-idr-restart-10.txt		draft-ietf-idr-restart-11.txt
	1. Status of this Memo
	This document is an Internet-Draft and is in full conformance with		Status of this Memo
	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.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as ``work in progress.''		material or to cite them other than as "work in progress".
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	2. Abstract		IPR Disclosure Acknowledgement
			By submitting this Internet-Draft, each author represents that any
			applicable patent or other IPR claims of which he or she is aware
			have been or will be disclosed, and any of which he or she becomes
			aware will be disclosed, in accordance with Section 6 of BCP 79.
			Abstract
	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		The mechanisms described in this document are applicable to all
	routers, both those with the ability to preserve forwarding state		routers, both those with the ability to preserve forwarding state
	during BGP restart and those without (although the latter need to		during BGP restart and those without (although the latter need to
	implement only a subset of the mechanisms described in this		implement only a subset of the mechanisms described in this
	document).		document).
	3. Specification of Requirements		1. Specification of Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119 [RFC2119].		document are to be interpreted as described in RFC2119 [RFC2119].
	4. Introduction		2. 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
	overall network performance.		overall network performance.
	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.
	5. Marker for End-of-RIB		3. Marker for End-of-RIB
	An UPDATE message with no reachable NLRI and empty withdrawn NLRI is		An UPDATE message with no reachable NLRI and empty withdrawn NLRI is
	specified as the End-Of-RIB Marker that can be used by a BGP speaker		specified as the End-Of-RIB Marker that can be used by a BGP speaker
	to indicate to its peer the completion of the initial routing update		to indicate to its peer the completion of the initial routing update
	after the session is established. For IPv4 unicast address family,		after the session is established. For IPv4 unicast address family,
	the End-Of-RIB Marker is an UPDATE message with the minimum length		the End-Of-RIB Marker is an UPDATE message with the minimum length
	[BGP-4]. For any other address family, it is an UPDATE message that		[BGP-4]. For any other address family, it is an UPDATE message that
	contains only the MP_UNREACH_NLRI attribute [BGP-MP] with no		contains only the MP_UNREACH_NLRI attribute [BGP-MP] with no
	withdrawn routes for that <AFI, SAFI>.		withdrawn routes for that <AFI, SAFI>.
	skipping to change at page 3, line 11		skipping to change at line 103
	graceful restart, it is noted that the generation of such a marker		graceful restart, it is noted that the generation of such a marker
	upon completion of the initial update would be useful for routing		upon completion of the initial update would be useful for routing
	convergence in general, and thus the practice is recommended.		convergence in general, and thus the practice is recommended.
	In addition, it would be beneficial for routing convergence if a BGP		In addition, it would be beneficial for routing convergence if a BGP
	speaker can indicate to its peer up-front that it will generate the		speaker can indicate to its peer up-front that it will generate the
	End-Of-RIB marker, regardless of its ability to preserve its		End-Of-RIB marker, regardless of its ability to preserve its
	forwarding state during BGP restart. This can be accomplished using		forwarding state during BGP restart. This can be accomplished using
	the Graceful Restart Capability described in the next section.		the Graceful Restart Capability described in the next section.
	6. Graceful Restart Capability		4. Graceful Restart Capability
	The Graceful Restart Capability is a new BGP capability [BGP-CAP]		The Graceful Restart Capability is a new BGP capability [BGP-CAP]
	that can be used by a BGP speaker to indicate its ability to preserve		that can be used by a BGP speaker to indicate its ability to preserve
	its forwarding state during BGP restart. It can also be used to		its forwarding state during BGP restart. It can also be used to
	convey to its peer its intention of generating the End-Of-RIB marker		convey to its peer its intention of generating the End-Of-RIB marker
	upon the completion of its initial routing updates.		upon the completion of its initial routing updates.
	This capability is defined as follows:		This capability is defined as follows:
	Capability code: 64		Capability code: 64
	skipping to change at page 5, line 31		skipping to change at line 220
	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
	should be carried by using the BGP Multiprotocol extensions [BGP-MP]		should be carried by using the BGP Multiprotocol extensions [BGP-MP]
	- 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.
	7. Operation		5. 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 (as mentioned before this is done by not		Capability to its peer (as mentioned before this is done by not
	including any <AFI, SAFI> in the advertised capability). There are		including any <AFI, SAFI> in the advertised capability). There are
	two reasons for doing this. First, to indicate its intention of		two reasons for doing this. First, to indicate its intention of
	skipping to change at page 6, line 23		skipping to change at line 259
	whose BGP has restarted, and "Receiving Speaker" refers to a router		whose BGP has restarted, and "Receiving Speaker" refers to a router
	that peers with the restarting speaker.		that peers with the restarting speaker.
	Consider that the Graceful Restart Capability for an address family		Consider that the Graceful Restart Capability for an address family
	is advertised by the Restarting Speaker, and is understood by the		is advertised by the Restarting Speaker, and is understood by the
	Receiving Speaker, and a BGP session between them is established.		Receiving Speaker, and a BGP session between them is established.
	The following sections detail the procedures that SHALL be followed		The following sections detail the procedures that SHALL be followed
	by the Restarting Speaker as well as the Receiving Speaker once the		by the Restarting Speaker as well as the Receiving Speaker once the
	Restarting Speaker restarts.		Restarting Speaker restarts.
	7.1. Procedures for the Restarting Speaker		5.1. Procedures for the Restarting Speaker
	When the Restarting Speaker restarts, possible it SHOULD retain, if		When the Restarting Speaker restarts, possible it SHOULD retain, if
	possible, the forwarding state for the BGP routes in the Loc-RIB, and		possible, the forwarding state for the BGP routes in the Loc-RIB, and
	SHALL mark them as stale. It SHOULD NOT differentiate between stale		SHALL mark them as stale. It SHOULD NOT differentiate between stale
	and other information during forwarding.		and other information during forwarding.
	To re-establish the session with its peer, the Restarting Speaker		To re-establish the session with its peer, the Restarting Speaker
	MUST set the "Restart State" bit in the Graceful Restart Capability		MUST set the "Restart State" bit in the Graceful Restart Capability
	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 either (a) receives the End-
	marker from all its peers (excluding the ones with the "Restart		of-RIB marker from all its peers (excluding the ones with the
	State" bit set in the received capability and excluding the ones		"Restart State" bit set in the received capability and excluding the
	which do not advertise the graceful restart capability). It is noted		ones which do not advertise the graceful restart capability) or (b)
	that prior to route selection, the speaker has no routes to advertise		the Selection_Deferral_Timer referred to below has expired. It is
	to its peers and no routes to update the forwarding state.		noted 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),
	the End-of-RIB marker SHALL be sent.		the End-of-RIB marker SHALL be sent.
	To put an upper bound on the amount of time a router defers its route		To put an upper bound on the amount of time a router defers its route
	selection, an implementation MUST support a (configurable) timer that		selection, an implementation MUST support a (configurable) timer that
	imposes this upper bound.		imposes this upper bound. This timer is referred to as the
			"Selection_Deferral_Timer". The value of this timer should be large
			enough, as to provide all the peers of the Restarting Speaker with
			enough time to send all the routes to the Restarting Speaker.
	If one wants to apply graceful restart only when the restart is		If one wants to apply graceful restart only when the restart is
	planned (as opposed to both planned and unplanned restart), then one		planned (as opposed to both planned and unplanned restart), then one
	way to accomplish this would be to set the Forwarding State bit to 1		way to accomplish this would be to set the Forwarding State bit to 1
	after a planned restart, and to 0 in all other cases. Other		after a planned restart, and to 0 in all other cases. Other
	approaches to accomplish this are outside the scope of this document.		approaches to accomplish this are outside the scope of this document.
	7.2. Procedures for the Receiving Speaker		5.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). See Section 8 for a description of this		been received from the peer). See Section 8 for a description of this
	skipping to change at page 8, line 35		skipping to change at line 370
	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. Changes to BGP Finite State Machine		6. Changes to BGP Finite State Machine
	As mentioned under "Procedures for the Receiving Speaker" above, this		As mentioned under "Procedures for the Receiving Speaker" above, this
	specification modifies the BGP finite state machine.		specification modifies the BGP finite state machine.
	The specific state machine modifications to [BGP-4] Section 8.2.2 are		The specific state machine modifications to [BGP-4] Section 8.2.2 are
	as follows. In the Established state, replace this text:		as follows.
	If a TcpConnection_Valid (Event 14) or Tcp_CR_Acked (Event 16) is		In the Idle state, make the following changes.
	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:		Replace this text:
	If a TcpConnection_Valid (Event 14) or Tcp_CR_Acked (Event 16) is		- initializes all BGP resources for the peer connection,
	received, a second TCP connection may be in progress. This second
	TCP connection is tracked per Connection Collision processing		with
	(Section 6.8) until an OPEN message is received.
			- initializes all BGP resources for the peer connection, other
			than those resources required in order to retain routes according
			to section "Procedures for the Receiving Speaker" of this
			(Graceful Restart) specification,
			In the Established state, make the following changes.
			Replace this text:
			In response to an indication that the TCP connection is
			successfully established (Event 16 or Event 17), the second
			connection SHALL be tracked until it sends an OPEN message.
			with
	If the Graceful Restart capability with one or more AFI/SAFI has		If the Graceful Restart capability with one or more AFI/SAFI has
	been received for the session, then TcpConnectionConfirmed (Event		not been received for the session, then in response to an
	17) is treated as TcpConnectionFails (Event 18).		indication that a TCP connection is successfully established
			(Event 16 or Event 17), the second connection SHALL be tracked
			until it sends an OPEN message.
	If a TcpConnectionConfirmed event (Event 17) is received and if		However, if the Graceful Restart capability with one or more
	the Graceful Restart capability with one or more AFI/SAFI has not		AFI/SAFI has been received for the session, then in response to
	been received for the session, a second TCP connection may be in		Event 16 or Event 17 the local system:
	progress. This second TCP connection is tracked per Connection
	Collision processing (Section 6.8) until an OPEN message is
	received.
	9. Deployment Considerations		- retains all routes associated with this connection according
			to section "Procedures for the Receiving Speaker" of this
			(Graceful Restart) specification,
			- releases all other BGP resources,
			- drops the TCP connection associated with the ESTABLISHED
			session,
			- initializes all BGP resources for the peer connection, other
			than those required in order to retain routes according to
			section "Procedures for the Receiving Speaker" of this
			specification,
			- sets ConnectRetryCounter to zero,
			- starts the ConnectRetryTimer with the initial value,
			- changes its state to Connect.
			Replace this text:
			If the local system receives a NOTIFICATION message (Event 24 or
			Event 25), or a TcpConnectionFails (Event 18) from the underlying
			TCP, the local system:
			- sets the ConnectRetryTimer to zero,
			- deletes all routes associated with this connection,
			- releases all the BGP resources,
			- drops the TCP connection,
			- increments the ConnectRetryCounter by 1,
			- changes its state to Idle.
			with
			If the local system receives a NOTIFICATION message (Event 24 or
			Event 25), or if the local system receives a TcpConnectionFails
			(Event 18) from the underlying TCP and the Graceful Restart
			capability with one or more AFI/SAFI has not been received for the
			session, the local system:
			- sets the ConnectRetryTimer to zero,
			- deletes all routes associated with this connection,
			- releases all the BGP resources,
			- drops the TCP connection,
			- increments the ConnectRetryCounter by 1,
			- changes its state to Idle.
			However, if the local system receives a TcpConnectionFails (Event
			18) from the underlying TCP, and the Graceful Restart capability
			with one or more AFI/SAFI has been received for the session, the
			local system:
			- sets the ConnectRetryTimer to zero,
			- retains all routes associated with this connection according
			to section "Procedures for the Receiving Speaker" of this
			(Graceful Restart) specification,
			- releases all other BGP resources,
			- drops the TCP connection,
			- increments the ConnectRetryCounter by 1,
			- changes its state to Idle.
			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
	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 10, line 5		skipping to change at line 510
	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.
	10. Security Considerations		8. 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.
	11. Acknowledgments		9. Intellectual Property Considerations
			This section is taken from Section 5 of RFC 3668.
			The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
			Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at ietf-
			ipr@ietf.org.
			10. Copyright Notice
			Copyright (C) The Internet Society (2006).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			11. IANA Considerations
			This document defines a new BGP Capability - Graceful Restart
			Capability. The Capability Code for Graceful Restart Capability is
			64.
			12. 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.
	12. Normative References		13. Normative References
	[BGP-4] Rekhter, Y., T. Li, Hares, S., "A Border Gateway Protocol 4		[BGP-4] Rekhter, Y., T. Li, Hares, S., "A Border Gateway Protocol 4
	(BGP- 4)", work in progress.		(BGP-4)", RFC4271, January 2006.
	[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", RFC3392, November 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.
	13. Author Information		14. Author Information
	Srihari R. Sangli		Srihari R. Sangli
	Procket Networks, Inc.		Cisco Systems, Inc.
	1100 Cadillac Court		EMail: rsrihari@cisco.com
	Milpitas, CA 95035
	e-mail: srihari@procket.com
	Yakov Rekhter		Yakov Rekhter
	Juniper Networks, Inc.		Juniper Networks, Inc.
	1194 N. Mathilda Avenue		EMail: yakov@juniper.net
	Sunnyvale, CA 94089
	e-mail: yakov@juniper.net
	Rex Fernando		Rex Fernando
	Procket Networks, Inc.		e-mail: rex_f@yahoo.com
	1100 Cadillac Court
	Milpitas, CA 95035
	e-mail: rex@procket.com
	John G. Scudder		John G. Scudder
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 West Tasman Drive		EMail: jgs@cisco.com
	San Jose, CA 95134
	e-mail: jgs@cisco.com
	Enke Chen		Enke Chen
	Redback Networks, Inc.		Cisco Systems, Inc.
	350 Holger Way		EMail: enkechen@cisco.com
	San Jose, CA 95134
	e-mail: enke@redback.com
End of changes. 33 change blocks.
	67 lines changed or deleted		200 lines changed or added
This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/