< draft-idr-bgp-route-refresh-options-03.txt		draft-idr-bgp-route-refresh-options-04.txt >
	Network Working Group K. Patel		Network Working Group K. Patel
	Internet-Draft Arrcus, Inc		Internet-Draft Arrcus, Inc
	Intended status: Standards Track A. Vyavaharkar		Intended status: Standards Track A. Vyavaharkar
	Expires: March 1, 2018 Cisco Systems		Expires: September 2, 2018 Cisco Systems
	N. Fazlollahi		N. Fazlollahi
			Unaffiliated
	A. Przygienda		A. Przygienda
	Juniper Networks		Juniper Networks
	August 28, 2017		Mar 1, 2018
	Extension to BGP's Route Refresh Message		Extension to BGP's Route Refresh Message
	draft-idr-bgp-route-refresh-options-03		draft-idr-bgp-route-refresh-options-04
	Abstract		Abstract
	[RFC2918] defines a route refresh capability to be exchanged between		[RFC2918] defines a route refresh capability to be exchanged between
	BGP speakers. BGP speakers that support this capability are		BGP speakers. BGP speakers that support this capability are
	advertising that they can resend the entire BGP Adj-RIB-Out on		advertising that they can resend the entire BGP Adj-RIB-Out on
	receipt of a refresh request. By supporting this capability, BGP		receipt of a refresh request. By supporting this capability, BGP
	speakers are more flexible in applying any inbound routing policy		speakers are more flexible in applying any inbound routing policy
	changes as they no longer have to store received routes in their		changes as they no longer have to store received routes in their
	unchanged form or reset the session when an inbound routing policy		unchanged form or reset the session when an inbound routing policy
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	requests.		requests.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 https://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 March 1, 2018.		This Internet-Draft will expire on September 2, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 31 ¶
	The Option Length field will occupy the two octets immediately		The Option Length field will occupy the two octets immediately
	following the Route Refresh message containing the AFI, SAFI and sub-		following the Route Refresh message containing the AFI, SAFI and sub-
	type. The purpose of this field is to allow the BGP speaker to		type. The purpose of this field is to allow the BGP speaker to
	calculate the length of any attached ORF fields by subtracting the		calculate the length of any attached ORF fields by subtracting the
	Option Length from the Route Refresh message length.		Option Length from the Route Refresh message length.
	7. Route Refresh ID		7. Route Refresh ID
	The Refresh ID field will occupy twelve bits following the Route		The Refresh ID field will occupy twelve bits following the Route
	Refresh Options Length. It is a value assigned by the requesting BGP		Refresh Options Length. It is infeasible to use a wide number like a
	speaker. It MUST be a strictly monotonically increasing number per		64-bit unsigned integer since this number must be stored per route
	peer AFI and SAFI using sequence number arithmetic based on two-		entry associated with any peer supporting this feature, at least
	complements given in Appendix A. It is comparable to the		during the time any refresh is pending. It is a value assigned by
	calculations standardized in [RFC1982] but fixes several of its		the requesting BGP speaker. It MUST be a strictly monotonically
	anomalies. The purpose of this field is to allow the requesting BGP		increasing number per peer AFI and SAFI using sequence number
	speaker to correlate concurrent, overlapping refresh requests and		arithmetic based on two-complements given in Appendix A. It is
	ultimately delete correct stale routes. The Refresh ID MUST be		comparable to the calculations standardized in [RFC1982] but fixes
	reflected in the BoRR and EoRR messages sent by the BGP speaker		several of its anomalies. The purpose of this field is to allow the
	servicing the refresh request.		requesting BGP speaker to correlate concurrent, overlapping refresh
			requests and ultimately delete correct stale routes. The Refresh ID
			MUST be reflected in the BoRR and EoRR messages sent by the BGP
			speaker servicing the refresh request.
	A Refresh ID value MUST NOT be reused until an EoRR with this ID has		A Refresh ID value MUST NOT be reused until an EoRR with this ID has
	been received by the requesting speaker or the last resort time has		been received by the requesting speaker or the last resort time has
	expired. The behavior is unspecified otherwise. More specifically,		expired. The behavior is unspecified otherwise. More specifically,
	defining the interval [ LID, HID ] by the values		defining the interval [ LID, HID ] by the values
	LID = MAX(lowest requested Refresh ID# without BoRR,		LID = MAX(lowest requested Refresh ID# without BoRR,
	lowest received BoRR without EoRR)		lowest received BoRR without EoRR)
	and		and
	HID = highest requested Refresh ID#		HID = highest requested Refresh ID#
	the requesting speaker MUST only use values V where V >: LID and V >:		the requesting speaker MUST only use values V where V >: LID and V >:
	HID as defined by the relation given in Appendix A. Beside that, HID		HID as defined by the relation given in Appendix A. Beside that, HID
	=>: LID MUST hold by the same algebra.		=>: LID MUST hold by the same algebra.
	If no such number V exists, LID must catch up to HID, i.e. no further		If no such number V exists, LID must catch up to HID, i.e. no further
	requests can be issued. To use a 3 bit example in Appendix A, if LID		requests can be issued. To use a 3 bit example in Appendix A, if LID
	was 1 and HID was 4, we cannot progress to unsigned 5 since 1 ? 5.		was 1 and HID was 4, we cannot progress to unsigned 5 since 1 ? 5.
	When LID progresses to unsigned 2 however, we have 5 >: 2 and 5 >: 4		When LID progresses to unsigned 2 however, we have 5 >: 2 and 5 >: 4
	skipping to change at page 12, line 46 ¶		skipping to change at page 12, line 49 ¶
	The authors would like to thank Anant Utgikar for initial discussions		The authors would like to thank Anant Utgikar for initial discussions
	resulting in this work. John Scudder and Jeff Hass provided further		resulting in this work. John Scudder and Jeff Hass provided further
	comments.		comments.
	15. References		15. References
	15.1. Normative References		15.1. Normative References
	[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,		[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
	DOI 10.17487/RFC1982, August 1996, <https://www.rfc-		DOI 10.17487/RFC1982, August 1996,
	editor.org/info/rfc1982>.		<https://www.rfc-editor.org/info/rfc1982>.
	[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,		[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
	DOI 10.17487/RFC2918, September 2000, <https://www.rfc-		DOI 10.17487/RFC2918, September 2000,
	editor.org/info/rfc2918>.		<https://www.rfc-editor.org/info/rfc2918>.
	[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,		[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
	R., Patel, K., and J. Guichard, "Constrained Route		R., Patel, K., and J. Guichard, "Constrained Route
	Distribution for Border Gateway Protocol/MultiProtocol		Distribution for Border Gateway Protocol/MultiProtocol
	Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual		Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
	Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,		Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
	November 2006, <https://www.rfc-editor.org/info/rfc4684>.		November 2006, <https://www.rfc-editor.org/info/rfc4684>.
	[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering		[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering
	Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291,		Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291,
	August 2008, <https://www.rfc-editor.org/info/rfc5291>.		August 2008, <https://www.rfc-editor.org/info/rfc5291>.
	[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement		[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
	with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February		with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
	2009, <https://www.rfc-editor.org/info/rfc5492>.		2009, <https://www.rfc-editor.org/info/rfc5492>.
	[RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced		[RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced
	Route Refresh Capability for BGP-4", RFC 7313,		Route Refresh Capability for BGP-4", RFC 7313,
	DOI 10.17487/RFC7313, July 2014, <https://www.rfc-		DOI 10.17487/RFC7313, July 2014,
	editor.org/info/rfc7313>.		<https://www.rfc-editor.org/info/rfc7313>.
	[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.		[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
	Patel, "Revised Error Handling for BGP UPDATE Messages",		Patel, "Revised Error Handling for BGP UPDATE Messages",
	RFC 7606, DOI 10.17487/RFC7606, August 2015,		RFC 7606, DOI 10.17487/RFC7606, August 2015,
	<https://www.rfc-editor.org/info/rfc7606>.		<https://www.rfc-editor.org/info/rfc7606>.
	15.2. Information References		15.2. Information References
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A		[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
	Border Gateway Protocol 4 (BGP-4)", RFC 4271,		Border Gateway Protocol 4 (BGP-4)", RFC 4271,
	DOI 10.17487/RFC4271, January 2006, <https://www.rfc-		DOI 10.17487/RFC4271, January 2006,
	editor.org/info/rfc4271>.		<https://www.rfc-editor.org/info/rfc4271>.
	[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,		[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
	Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based		Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
	Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February		Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
	2015, <https://www.rfc-editor.org/info/rfc7432>.		2015, <https://www.rfc-editor.org/info/rfc7432>.
	[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and		[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
	S. Ray, "North-Bound Distribution of Link-State and		S. Ray, "North-Bound Distribution of Link-State and
	Traffic Engineering (TE) Information Using BGP", RFC 7752,		Traffic Engineering (TE) Information Using BGP", RFC 7752,
	DOI 10.17487/RFC7752, March 2016, <https://www.rfc-		DOI 10.17487/RFC7752, March 2016,
	editor.org/info/rfc7752>.		<https://www.rfc-editor.org/info/rfc7752>.
	[Wikipedia]		[Wikipedia]
	Wikipedia, "https://en.wikipedia.org/wiki/		Wikipedia,
	Serial_number_arithmetic", 2016.		"https://en.wikipedia.org/wiki/Serial_number_arithmetic",
			2016.
	Appendix A. Sequence Number Binary Arithmetic		Appendix A. Sequence Number Binary Arithmetic
	The only reasonably reference to a cleaner than [RFC1982] sequence		The only reasonably reference to a cleaner than [RFC1982] sequence
	number solution is given in [Wikipedia]. It basically converts the		number solution is given in [Wikipedia]. It basically converts the
	problem into two complement's arithmetic. Assuming a straight two		problem into two complement's arithmetic. Assuming a straight two
	complement's substractions on the bit-width of the sequence number		complement's substractions on the bit-width of the sequence number
	the according >: and =: relations are defined as:		the according >: and =: relations are defined as:
	U_1, U_2 are 12-bits aligned unsigned version number		U_1, U_2 are 12-bits aligned unsigned version number
	skipping to change at page 15, line 22 ¶		skipping to change at page 15, line 32 ¶
	Aamod Vyavaharkar		Aamod Vyavaharkar
	Cisco Systems		Cisco Systems
	821 Alder Drive		821 Alder Drive
	Milpitas, CA 95035		Milpitas, CA 95035
	USA		USA
	Email: avyavaha@cisco.com		Email: avyavaha@cisco.com
	Niloofar Fazlollahi		Niloofar Fazlollahi
			Unaffiliated
	USA		USA
	Email: Niloofar_fazlollahi@yahoo.com		Email: Niloofar_fazlollahi@yahoo.com
	Tony Przygienda		Tony Przygienda
	Juniper Networks		Juniper Networks
	1194 N. Mathilda Ave		1194 N. Mathilda Ave
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	USA		USA
End of changes. 19 change blocks.
	33 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/