draft-ietf-idr-bgp-enhanced-route-refresh-09.txt		draft-ietf-idr-bgp-enhanced-route-refresh-10.txt
	IDR K. Patel		IDR K. Patel
	Internet-Draft E. Chen		Internet-Draft E. Chen
	Updates: 2918 (if approved) Cisco Systems		Updates: 2918 (if approved) Cisco Systems
	Intended status: Standards Track B. Venkatachalapathy		Intended status: Standards Track B. Venkatachalapathy
	Expires: December 11, 2014		Expires: December 11, 2014
	June 9, 2014		June 9, 2014
	Enhanced Route Refresh Capability for BGP-4		Enhanced Route Refresh Capability for BGP-4
	draft-ietf-idr-bgp-enhanced-route-refresh-09.txt		draft-ietf-idr-bgp-enhanced-route-refresh-10.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. This document		of BGP RIB inconsistencies in a non-disruptive manner. This document
	updates RFC 2918.		updates RFC 2918.
	Status of This Memo		Status of This Memo
	skipping to change at page 2, line 25		skipping to change at page 2, line 25
	5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4		5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 6		7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	9. Normative References . . . . . . . . . . . . . . . . . . . . 6		9. Normative References . . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	It is sometimes necessary to perform routing consistency validations		It is sometimes necessary to perform routing consistency validations
	such as checking for possible missing withdraws between BGP speakers		such as checking for possible missing route withdrawals between BGP
	[RFC4271]. Currently such validations typically involve off-line,		speakers [RFC4271]. Currently such validations typically involve
	manual operations which can be tedious and time consuming.		off-line, manual operations which can be tedious and time consuming.
	In this document we enhance the existing BGP route refresh mechanisms		In this document we enhance the existing BGP route refresh mechanisms
	[RFC2918] to provide for the demarcation of the beginning and the		[RFC2918] to provide for the demarcation of the beginning and the
	ending of a route refresh (which refers to the complete re-		ending of a route refresh (which refers to the complete re-
	advertisement of the Adj-RIB-Out to a peer, subject to routing		advertisement of the Adj-RIB-Out to a peer, subject to routing
	policies). The enhancement can be used to facilitate on-line, non-		policies). The enhancement can be used to facilitate on-line, non-
	disruptive consistency validation of BGP routing updates.		disruptive consistency validation of BGP routing updates.
	This document updates [RFC2918] by redefining a field in the ROUTE-		This document updates [RFC2918] by redefining a field in the ROUTE-
	REFRESH message that was previously designated as Reserved.		REFRESH message that was previously designated as Reserved.
	skipping to change at page 5, line 5		skipping to change at page 5, line 5
	<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		for an <AFI, SAFI> from the neighbor before the speaker receives the
	EoR for the given <AFI, SAFI> from the neighbor. The BGP speaker		EoR for the given <AFI, SAFI> from the neighbor. The BGP speaker
	SHOULD log an error of the condition for further analysis.		SHOULD log an error of the condition for further analysis.
	5. Error Handling		5. Error Handling
	This document defines a new NOTIFICATION error code:		This document defines a new NOTIFICATION error code:
	Error Code Symbolic Name		Error Code Symbolic Name
	TBD ROUTE-REFRESH Message Error		TBD ROUTE-REFRESH Message Error
	The following error subcodes are defined as well:		The following error subcodes are defined as well:
	Subcode Symbolic Name		Subcode Symbolic Name
	1 Invalid Message Length		1 Invalid Message Length
	The error handling specified in this section is applicable only when		The error handling specified in this section is applicable only when
	skipping to change at page 5, line 42		skipping to change at page 5, line 42
	This document defines the Enhanced Route Refresh Capability for BGP.		This document defines the Enhanced Route Refresh Capability for BGP.
	The Capability Code 70 has been assigned by the IANA from the "BGP		The Capability Code 70 has been assigned by the IANA from the "BGP
	Capability Codes" registry. IANA should update that registry entry		Capability Codes" registry. IANA should update that registry entry
	to reference this document when it is published as an RFC. This		to reference this document when it is published as an RFC. This
	document also defines two new subcodes for the Route Refresh message.		document also defines two new subcodes for the Route Refresh message.
	They need to be registered with the IANA. We request IANA to create		They need to be registered with the IANA. We request IANA to create
	a new registry for the Route Refresh message subcodes as follows:		a new registry for the Route Refresh message subcodes as follows:
	Under "Border Gateway Protocol (BGP) Parameters":		Under "Border Gateway Protocol (BGP) Parameters":
	Registry: "BGP Route Refresh Subcodes"		Registry: "BGP Route Refresh Subcodes"
	Reference: [This Document]		Reference: [RFC-to-Be]
	Registration Procedure(s): Values 0-127 Standards Action, values		Registration Procedure(s): Values 0-127 Standards Action, values
	128-254 First Come, First Served, Value 255 reserved		128-254 First Come, First Served, Value 255 reserved
	Value Code Reference		Value Code Reference
	0 Route-Refresh [RFC2918], [RFC5291]		0 Route-Refresh [RFC2918], [RFC5291]
	1 BoRR [This Document]		1 BoRR [RFC-to-Be]
	2 EoRR [This Document]		2 EoRR [RFC-to-Be]
	3-127 Unassigned		3-127 Unassigned
	128-254 Unassigned		128-254 Unassigned
	255 Reserved [This Document]		255 Reserved [RFC-to-Be]
	In addition, this document defines a NOTIFICATION error code and an		In addition, this document defines a NOTIFICATION error code and an
	error subcode related to the ROUTE-REFRESH message. We request IANA		error subcode related to the ROUTE-REFRESH message. We request IANA
	to allocate a new error code from the "BGP Error Codes" registry with		to allocate a new error code from the "BGP Error Codes" registry with
	the symbolic name "ROUTE-REFRESH Message Error", referencing this		the symbolic name "ROUTE-REFRESH Message Error", referencing this
	document. We request IANA to create a new registry for the error		document. We request IANA to create a new registry for the error
	subcodes as follows:		subcodes as follows:
	Under "BGP Error Subcodes":		Under "BGP Error Subcodes":
	Registry: "BGP ROUTE-REFRESH Message Error subcodes"		Registry: "BGP ROUTE-REFRESH Message Error subcodes"
	Reference: [This Document]		Reference: [RFC-to-Be]
	Registration Procedure(s): Values 0-127 Standards Action, values		Registration Procedure(s): Values 0-127 Standards Action, values
	128-255 First Come, First Served		128-255 First Come, First Served
	Value Code Reference		Value Code Reference
	0 Reserved		0 Reserved
	1 Invalid Message Length [This Document]		1 Invalid Message Length [RFC-to-Be]
	2-127 Unassigned		2-127 Unassigned
	128-255 Unassigned		128-255 Unassigned
	7. Security Considerations		7. Security Considerations
	This extension to BGP does not change the underlying security issues.		Security considerations are given in [RFC4272] , but do not cover
			Route-Refresh and many other BGP extensions. This draft does not
			significantly change the underlying security issues regarding Route-
			Refresh, although improved error handling may aid operational
			security.
	8. Acknowledgements		8. Acknowledgements
	The authors would like to thank Pedro Marques, Pradosh Mohapatra,		The authors would like to thank Pedro Marques, Pradosh Mohapatra,
	Robert Raszuk, Pranav Mehta, Shyam Sethuram, Bruno Decraene, Martin		Robert Raszuk, Pranav Mehta, Shyam Sethuram, Bruno Decraene, Martin
	Djernaes, Jeff Haas, Ilya Varlashkin, Rob Shakir, Paul Jakma, Jie		Djernaes, Jeff Haas, Ilya Varlashkin, Rob Shakir, Paul Jakma, Jie
	Dong, Qing Zeng, Albert Tian, Jakob Heitz and Chris Hall for their		Dong, Qing Zeng, Albert Tian, Jakob Heitz and Chris Hall for their
	review and comments. The authors would like to thank John Scudder		review and comments. The authors would like to thank John Scudder
	for the review and contribution to this document.		for the review and contribution to this document.
	skipping to change at page 6, line 48		skipping to change at page 7, line 5
	[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.
	[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,		[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
	September 2000.		September 2000.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
			[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
			4272, January 2006.
	[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.		[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
	Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,		Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
	January 2007.		January 2007.
	[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering		[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering
	Capability for BGP-4", RFC 5291, August 2008.		Capability for BGP-4", RFC 5291, August 2008.
	[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement		[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
	with BGP-4", RFC 5492, February 2009.		with BGP-4", RFC 5492, February 2009.
End of changes. 10 change blocks.
	12 lines changed or deleted		19 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/