draft-ietf-idr-bgp-enhanced-route-refresh-06.txt		draft-ietf-idr-bgp-enhanced-route-refresh-07.txt
	IDR K. Patel		IDR K. Patel
	Internet-Draft E. Chen		Internet-Draft E. Chen
	Intended status: Standards Track Cisco Systems		Updates: 2918 (if approved) Cisco Systems
	Expires: August 10, 2014 B. Venkatachalapathy		Intended status: Standards Track B. Venkatachalapathy
			Expires: December 7, 2014
	February 6, 2014		June 5, 2014
	Enhanced Route Refresh Capability for BGP-4		Enhanced Route Refresh Capability for BGP-4
	draft-ietf-idr-bgp-enhanced-route-refresh-06.txt		draft-ietf-idr-bgp-enhanced-route-refresh-07.txt
	Abstract		Abstract
	In this document we enhance the existing BGP route refresh mechanisms		In this document we enhance the existing BGP route refresh mechanisms
	to provide for the demarcation of the beginning and the ending of a		to provide for the demarcation of the beginning and the ending of a
	route refresh. The enhancement can be used to facilitate correction		route refresh. The enhancement can be used to facilitate correction
	of BGP RIB inconsistencies in a non-disruptive manner.		of BGP RIB inconsistencies in a non-disruptive manner.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on August 10, 2014.		This Internet-Draft will expire on December 7, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 4, line 21		skipping to change at page 4, line 21
	A BGP speaker can receive a BoRR message from a peer at anytime,		A BGP speaker can receive a BoRR message from a peer at anytime,
	either as a result of a peer responding to a ROUTE-REFESH message, or		either as a result of a peer responding to a ROUTE-REFESH message, or
	as a result of a peer unilaterally initiating a route refresh. When		as a result of a peer unilaterally initiating a route refresh. When
	a BGP speaker receives a BoRR message from a peer, it MUST mark all		a BGP speaker receives a BoRR message from a peer, it MUST mark all
	the routes with the given <AFI, SAFI> from that peer as stale. As it		the routes with the given <AFI, SAFI> from that peer as stale. As it
	receives routes from its peer's subsequent Adj-RIB-Out re-		receives routes from its peer's subsequent Adj-RIB-Out re-
	advertisement, these replace any corresponding stale routes. When a		advertisement, these replace any corresponding stale routes. When a
	BGP speaker receives an EoRR message from a peer, it MUST immediately		BGP speaker receives an EoRR message from a peer, it MUST immediately
	remove any routes from the peer that are still marked as stale for		remove any routes from the peer that are still marked as stale for
	that <AFI, SAFI>. Such purged routes MAY be logged for future		that <AFI, SAFI>. Such purged routes MAY be logged for future
	analysis.		analysis. A BGP speaker MAY ignore any EoRR message received without
			a prior receipt of an associated BoRR message. Such messages MAY be
			logged for future analysis.
	An implementation MAY impose a locally configurable upper bound on		An implementation MAY impose a locally configurable upper bound on
	how long it would retain any stale routes. Once the upper bound is		how long it would retain any stale routes. Once the upper bound is
	reached, the implementation MAY remove any routes from the peer that		reached, the implementation MAY remove any routes from the peer that
	are still marked as stale for that <AFI, SAFI> without waiting for an		are still marked as stale for that <AFI, SAFI> without waiting for an
	EoRR message.		EoRR message.
	The following procedures are specified in order to simplify the		The following procedures are specified in order to simplify the
	interaction with the BGP Graceful Restart [RFC4724]. For a BGP		interaction with the BGP Graceful Restart [RFC4724]. In particular,
			these procedures ensure that End-of-RIB (EoR) defined in Graceful
			Restart and EoRR as defined in this specification are kept separate,
			thereby avoiding any premature cleanup of stale routes. For a BGP
	speaker that supports the BGP Graceful Restart, it MUST NOT send a		speaker that supports the BGP Graceful Restart, it MUST NOT send a
	BoRR for an AFI/SAFI to a neighbor before it sends the EOR for the		BoRR for an AFI/SAFI to a neighbor before it sends the EOR for the
	AFI/SAFI to the neighbor. A BGP speaker that has received the		AFI/SAFI to the neighbor. A BGP speaker that has received the
	Graceful Restart Capability from its neighbor, MUST ignore any BoRRs		Graceful Restart Capability from its neighbor, MUST ignore any BoRRs
	for an AFI/SAFI from the neighbor before the speaker receives the EoR		for an AFI/SAFI from the neighbor before the speaker receives the EoR
	for the given AFI/SAFI from the neighbor. The BGP speaker SHOULD log		for the given AFI/SAFI from the neighbor. The BGP speaker SHOULD log
	an error of the condition for further analysis.		an error of the condition for further analysis.
	5. Error Handling		5. Error Handling
End of changes. 5 change blocks.
	8 lines changed or deleted		13 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/