< draft-przygienda-idr-compressed-updates-03.txt		draft-przygienda-idr-compressed-updates-04.txt >
	Network Working Group A. Przygienda		Network Working Group A. Przygienda
	Internet-Draft Juniper		Internet-Draft Juniper
	Intended status: Standards Track A. Lingala		Intended status: Standards Track A. Lingala
	Expires: March 1, 2018 AT&T		Expires: August 30, 2018 AT&T
	C. Mate		C. Mate
	NIIF/Hungarnet		NIIF/Hungarnet
	J. Tantsura		J. Tantsura
	Futurewei Technologies Inc		Nuage Networks
	August 28, 2017		Feb 26, 2018
	Compressed BGP Update Message		Compressed BGP Update Message
	draft-przygienda-idr-compressed-updates-03		draft-przygienda-idr-compressed-updates-04
	Abstract		Abstract
	This document provides specification of an optional compressed BGP		This document provides specification of an optional compressed BGP
	update message format to allow family independent reduction in BGP		update message format to allow family independent reduction in BGP
	control traffic volume.		control traffic volume.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	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 August 30, 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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	skipping to change at page 3, line 26 ¶		skipping to change at page 3, line 26 ¶
	bandwith-delay product.		bandwith-delay product.
	o The data volume, which for one peer may be reasonable, becomes		o The data volume, which for one peer may be reasonable, becomes
	less so when many of those need to be refreshed due to [RFC4724]		less so when many of those need to be refreshed due to [RFC4724]
	and [RFC7313] interactions. Use of those techniques is expected		and [RFC7313] interactions. Use of those techniques is expected
	to increase due to increasing demands on BGP reliability and novel		to increase due to increasing demands on BGP reliability and novel
	variants of state synchronization between peers.		variants of state synchronization between peers.
	o BGP message length is limited to 4K which in itself is a		o BGP message length is limited to 4K which in itself is a
	recognized problem. Extensions to the message length		recognized problem. Extensions to the message length
	[ID.draft-ietf-idr-bgp-extended-messages-12] are being worked on		[ID.draft-ietf-idr-bgp-extended-messages-21] are being worked on
	but this puts its own requirements and memory pressure on the		but this puts its own requirements and memory pressure on the
	implementations and ultimately will not help with attributes		implementations and ultimately will not help with attributes
	exceeding 4K size limit in mixed environments.		exceeding 4K size limit in mixed environments.
	o Virtualization techniques introduce an increasing amount of		o Virtualization techniques introduce an increasing amount of
	context switches an IP packet has to cross between two BGP		context switches an IP packet has to cross between two BGP
	instances. Coupled with difficulties in estimating a reasonable		instances. Coupled with difficulties in estimating a reasonable
	TCP MSS in virtualized environments and the number of IP packets		TCP MSS in virtualized environments and the number of IP packets
	TCP generates, more and more context switching overhead per update		TCP generates, more and more context switching overhead per update
	is necessary before good-put BGP processing can happen.		is necessary before good-put BGP processing can happen.
	skipping to change at page 5, line 33 ¶		skipping to change at page 5, line 33 ¶
	A new BGP message is introduced under the name of "Compressed BGP		A new BGP message is introduced under the name of "Compressed BGP
	Update". It contains inside arbitrary number of following message		Update". It contains inside arbitrary number of following message
	types		types
	o normal BGP updates		o normal BGP updates
	o Enhanced Route Refresh [RFC7313] subtype 1 and 2 (BoRR and EoRR)		o Enhanced Route Refresh [RFC7313] subtype 1 and 2 (BoRR and EoRR)
	o Route Refresh with Options		o Route Refresh with Options
	[ID.draft-idr-bgp-route-refresh-options-02] subtype 4 and 5 (BoRR		[ID.draft-idr-bgp-route-refresh-options-03] subtype 4 and 5 (BoRR
	and EoRR with options)		and EoRR with options)
	following each other and compressed while following the rules below:		following each other and compressed while following the rules below:
	1. Compressed and uncompressed BGP updates MAY follow each other in		1. Compressed and uncompressed BGP updates MAY follow each other in
	arbitrary order with exception of compressor overflow scenario		arbitrary order with exception of compressor overflow scenario
	per Section 4.3.		per Section 4.3.
	2. After decompression of the stream of interleaved compressed and		2. After decompression of the stream of interleaved compressed and
	uncompressed BGP update messages the resulting uncompressed		uncompressed BGP update messages the resulting uncompressed
	skipping to change at page 10, line 14 ¶		skipping to change at page 10, line 14 ¶
	8. Acknowledgements		8. Acknowledgements
	Thanks to John Scudder for some bar discussions that primed the		Thanks to John Scudder for some bar discussions that primed the
	creative process. Thanks to Eric Rosen, Jeff Haas and Acee Lindem		creative process. Thanks to Eric Rosen, Jeff Haas and Acee Lindem
	for their careful reviews. Thanks to David Lamperter for discussions		for their careful reviews. Thanks to David Lamperter for discussions
	on reordering issues.		on reordering issues.
	9. Normative References		9. Normative References
	[ID.draft-idr-bgp-route-refresh-options-02]		[ID.draft-idr-bgp-route-refresh-options-03]
	Patel et al., K., "Extension to BGP's Route Refresh		Patel et al., K., "Extension to BGP's Route Refresh
	Message", internet-draft draft-idr-bgp-route-refresh-		Message", internet-draft draft-idr-bgp-route-refresh-
	options-02.txt, May 2017.		options-03.txt, May 2017.
	[ID.draft-ietf-idr-bgp-extended-messages-12]		[ID.draft-ietf-idr-bgp-extended-messages-21]
	Bush et al., R., "Extended Message support for BGP",		Bush et al., R., "Extended Message support for BGP",
	internet-draft draft-ietf-idr-bgp-extended-messages-		internet-draft draft-ietf-idr-bgp-extended-messages-
	12.txt, May 2016.		21.txt, May 2016.
	[QUANT] Zyga, L., "Worldwide Quantum Web May Be Possible with Help		[QUANT] Zyga, L., "Worldwide Quantum Web May Be Possible with Help
	from Graphs", New Journal on Physics , June 2016.		from Graphs", New Journal on Physics , June 2016.
	[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format		[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
	Specification version 3.3", RFC 1950,		Specification version 3.3", RFC 1950,
	DOI 10.17487/RFC1950, May 1996, <https://www.rfc-		DOI 10.17487/RFC1950, May 1996,
	editor.org/info/rfc1950>.		<https://www.rfc-editor.org/info/rfc1950>.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
	version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,		version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
	<https://www.rfc-editor.org/info/rfc1951>.		<https://www.rfc-editor.org/info/rfc1951>.
	[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>.
	[RFC2283] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,		[RFC2283] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
	"Multiprotocol Extensions for BGP-4", RFC 2283,		"Multiprotocol Extensions for BGP-4", RFC 2283,
	DOI 10.17487/RFC2283, February 1998, <https://www.rfc-		DOI 10.17487/RFC2283, February 1998,
	editor.org/info/rfc2283>.		<https://www.rfc-editor.org/info/rfc2283>.
	[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended		[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
	Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,		Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
	February 2006, <https://www.rfc-editor.org/info/rfc4360>.		February 2006, <https://www.rfc-editor.org/info/rfc4360>.
	[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,
	DOI 10.17487/RFC4724, January 2007, <https://www.rfc-		DOI 10.17487/RFC4724, January 2007,
	editor.org/info/rfc4724>.		<https://www.rfc-editor.org/info/rfc4724>.
	[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>.
	[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,		[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
	"Advertisement of Multiple Paths in BGP", RFC 7911,		"Advertisement of Multiple Paths in BGP", RFC 7911,
	DOI 10.17487/RFC7911, July 2016, <https://www.rfc-		DOI 10.17487/RFC7911, July 2016,
	editor.org/info/rfc7911>.		<https://www.rfc-editor.org/info/rfc7911>.
	Authors' Addresses		Authors' Addresses
	Tony Przygienda		Tony Przygienda
	Juniper		Juniper
	1137 Innovation Way		1137 Innovation Way
	Sunnyvale, CA		Sunnyvale, CA
	USA		USA
	Email: prz@juniper.net		Email: prz@juniper.net
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	Email: ar977m@att.com		Email: ar977m@att.com
	Csaba Mate		Csaba Mate
	NIIF/Hungarnet		NIIF/Hungarnet
	18-22 Victor Hugo		18-22 Victor Hugo
	Budapest 1132		Budapest 1132
	Hungary		Hungary
	Email: matecs@niif.hu		Email: matecs@niif.hu
	Jeff Tantsura		Jeff Tantsura
	Futurewei Technologies Inc		Nuage Networks
			755 Ravendale Drive
			Mountain View, CA 94043
	USA		USA
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
End of changes. 20 change blocks.
	27 lines changed or deleted		29 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/