< draft-przygienda-idr-compressed-updates-02.txt		draft-przygienda-idr-compressed-updates-03.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: February 6, 2018 AT&T		Expires: March 1, 2018 AT&T
			C. Mate
			NIIF/Hungarnet
	J. Tantsura		J. Tantsura
	Futurewei Technologies Inc		Futurewei Technologies Inc
	August 5, 2017		August 28, 2017
	Compressed BGP Update Message		Compressed BGP Update Message
	draft-przygienda-idr-compressed-updates-02		draft-przygienda-idr-compressed-updates-03
	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 41 ¶		skipping to change at page 1, line 43 ¶
	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 February 6, 2018.		This Internet-Draft will expire on March 1, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 2, line 21 ¶		skipping to change at page 2, line 24 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Decompression Capability Negotiation . . . . . . . . . . 5		4.1. Decompression Capability Negotiation . . . . . . . . . . 5
	4.2. Compressed BGP Update Messages . . . . . . . . . . . . . 5		4.2. Compressed BGP Update Messages . . . . . . . . . . . . . 5
	4.3. Compressor Overflow . . . . . . . . . . . . . . . . . . . 6		4.3. Compressor Overflow . . . . . . . . . . . . . . . . . . . 6
	4.4. Compressor Restarts . . . . . . . . . . . . . . . . . . . 6		4.4. Compressor Restarts . . . . . . . . . . . . . . . . . . . 7
	4.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 7		4.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 7
	5. Special Considerations . . . . . . . . . . . . . . . . . . . 7		5. Special Considerations . . . . . . . . . . . . . . . . . . . 7
	5.1. Impact on Network Sniffing Tools . . . . . . . . . . . . 7		5.1. Impact on Network Sniffing Tools . . . . . . . . . . . . 7
	6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7		6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8
	6.1. Decompressor Capability . . . . . . . . . . . . . . . . . 7		6.1. Decompressor Capability . . . . . . . . . . . . . . . . . 8
	6.2. Compressed Update Messages . . . . . . . . . . . . . . . 8		6.2. Compressed Update Messages . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	9. Normative References . . . . . . . . . . . . . . . . . . . . 9		9. Normative References . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	BGP as a protocol evolved over the years to carry larger and larger		BGP as a protocol evolved over the years to carry larger and larger
	volumes of information and this trend seems to continue unabated.		volumes of information and this trend seems to continue unabated.
	And while lots of the growth can be contributed to the advent of new		And while lots of the growth can be contributed to the advent of new
	address families spurred by [RFC2283], steady increase in attributes		address families spurred by [RFC2283], steady increase in attributes
	and their size amplifies this tendency. Recently, even the same NLRI		and their size amplifies this tendency. Recently, even the same NLRI
	may be advertised multiple times by the means of ADD-PATH [RFC7911]		may be advertised multiple times by the means of ADD-PATH [RFC7911]
	skipping to change at page 4, line 49 ¶		skipping to change at page 4, line 49 ¶
	pressure on TCP processing and synchronization as well as reduce raw		pressure on TCP processing and synchronization as well as reduce raw
	number of IP packets exchanged between peers.		number of IP packets exchanged between peers.
	2. Terminology		2. Terminology
	3. IANA Considerations		3. IANA Considerations
	This document will request IANA to assign new BGP message type value		This document will request IANA to assign new BGP message type value
	and and a new optional capability value in the BGP Capability Codes		and and a new optional capability value in the BGP Capability Codes
	registry. The suggested value for the Compressed Updates message		registry. The suggested value for the Compressed Updates message
	type in this process will be 6 and for the Capability Code the		type in this process will be 7 and for the Capability Code the
	suggested value will be 76.		suggested value will be 76.
	IANA will be requested as well to assign a new subcode in the "BGP		IANA will be requested as well to assign a new subcode in the "BGP
	Cease NOTIFICATION message subcodes" registry. The suggested name		Cease NOTIFICATION message subcodes" registry. The suggested name
	for the code point will be "Decompression Error". The suggested		for the code point will be "Decompression Error". The suggested
	value will be 10.		value will be 10.
	4. Procedures		4. Procedures
	4.1. Decompression Capability Negotiation		4.1. Decompression Capability Negotiation
	skipping to change at page 5, line 40 ¶		skipping to change at page 5, line 40 ¶
	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-02] 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. After decompression of the stream of		per Section 4.3.
	interleaved compressed and uncompressed BGP updates and route
	refresh messages the resulting sequence of messages does not have
	to be identical to the sequence in a stream that would be
	generated without compression. However, the uncompressed
	sequence MUST ensure that the ultimate semantics of the message
	stream is the same to the peer as of a correct uncompressed case.
	2. The updates and refreshes contained within the compressed BGP		2. After decompression of the stream of interleaved compressed and
			uncompressed BGP update messages the resulting uncompressed
			sequence does not have to be identical to the sequence in a
			stream that would be generated without compression. However, the
			processing of the uncompressed sequence MUST ensure that the
			ultimate semantics of the message stream is the same to the peer
			as of a correct uncompressed case.
			3. The sender is explicitly permitted to generate outgoing updates
			in a manner that reorders them as compared to uncompressed
			stream, but if it does so it MUST ensure that the resulting
			stream of updates retains the original semantics as if
			compression was not in use.
			4. The updates and refreshes contained within the compressed BGP
	update message MUST be stripped of the initial marker while		update message MUST be stripped of the initial marker while
	preserving the BGP update or route refresh message header. The		preserving the BGP update or route refresh message header. The
	length field in the BGP header retains its original value.		length field in the BGP header retains its original value.
	3. Each compressed BGP Update MUST carry a sequence of non-		5. Each compressed BGP Update MUST carry a sequence of non-
	fragmented original messages, i.e. it cannot e.g. contain a part		fragmented original messages, i.e. it cannot e.g. contain a part
	of an original BGP update. Section 4.3 presents the only		of an original BGP update. Section 4.3 presents the only
	exception to this rule.		exception to this rule.
	4. Each compressed BGP Update MUST be sent as a block, i.e. the		6. Each compressed BGP Update MUST be sent as a block, i.e. the
	decompression MUST be able to yield decompressed results of the		decompression MUST be able to yield decompressed results of the
	update without waiting for further compressed updates. This is		update without waiting for further compressed updates. This is
	different from the normally used stream compression mode.		different from the normally used stream compression mode.
	Section 4.3 presents the only exception to this rule.		Section 4.3 presents the only exception to this rule.
	5. The compressed update message MAY exceed the maximum message size		7. The compressed update message MAY exceed the maximum message size
	but in such case compressor overflow per Section 4.3 MUST be		but in such case compressor overflow per Section 4.3 MUST be
	invoked.		invoked.
	4.3. Compressor Overflow		4.3. Compressor Overflow
	To achieve optimal compression rates it is desirable to provide to		To achieve optimal compression rates it is desirable to provide to
	the compressor enough data so the resulting compressed update is as		the compressor enough data so the resulting compressed update is as
	close to the maximum BGP update size as possible. Unfortunately, a		close to the maximum BGP update size as possible. Unfortunately, a
	Huffman with adapting dictionary compresses at always varying ratio		Huffman with adapting dictionary compresses at always varying ratio
	which can lead to an overflow unless it is used very conservatively.		which can lead to an overflow unless it is used very conservatively.
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 32 ¶
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Code | Length | CM | CINFO | Reserved |		| Code | Length | CM | CINFO | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Code: To be obtained by early allocation, suggested value in this		Code: To be obtained by early allocation, suggested value in this
	process will be 76.		process will be 76.
	Length: 1 octet.		Length: 1 octet.
	CM: 3 bits of CM indicating DEFLATE compressed format value as		CM: 4 bits of CM indicating DEFLATE compressed format value as
	specified in [RFC1950].		specified in [RFC1950].
	CINFO: 4 bits of CINFO as specified in [RFC1950]. Invalid values		CINFO: 4 bits of CINFO as specified in [RFC1950]. Invalid values
	MUST lead to the capability being ignored. The compressing peer		MUST lead to the capability being ignored. The compressing peer
	MUST use this value for the parametrization of its algorithm.		MUST use this value for the parametrization of its algorithm.
	6.2. Compressed Update Messages		6.2. Compressed Update Messages
	This carries the original updates in a single message with content		This carries the original updates in a single message with content
	adhering to Section 4.2.		adhering to Section 4.2.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Type |R|O| ULI | ID# |		| Length | Type |R|O| ULI | ID# |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| compressed data ...		| compressed data ...
	+-+-+-+-+-+-+-+-+-+- ...		+-+-+-+-+-+-+-+-+-+- ...
	Type: To be obtained by early allocation, suggested value in this		Type: To be obtained by early allocation, suggested value in this
	process will be 6.		process will be 7.
	Length: 2 octets.		Length: 2 octets.
	ID#: 3 bits. Indicates the number of the compressor used. Up to 8		ID#: 3 bits. Indicates the number of the compressor used. Up to 8
	compressors MAY be used by the compressing peer to allow for		compressors MAY be used by the compressing peer to allow for
	multiple thread of execution to compress the BGP update stream.		multiple thread of execution to compress the BGP update stream.
	Accordingly the decompressing side MUST support up to 8		Accordingly the decompressing side MUST support up to 8
	independent decompressors.		independent decompressors.
	R: If the bit is set, the according de-compressor MUST be initialized		R: If the bit is set, the according de-compressor MUST be initialized
	skipping to change at page 9, line 40 ¶		skipping to change at page 10, line 8 ¶
	overflow fragment.		overflow fragment.
	7. Security Considerations		7. Security Considerations
	This document introduces no new security concerns to BGP or other		This document introduces no new security concerns to BGP or other
	specifications referenced in this document.		specifications referenced in this document.
	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, Acee Lindem, Jeff		creative process. Thanks to Eric Rosen, Jeff Haas and Acee Lindem
	Tantsura and Csaba Mate for their careful reviews.		for their careful reviews. Thanks to David Lamperter for discussions
			on reordering issues.
	9. Normative References		9. Normative References
	[ID.draft-idr-bgp-route-refresh-options-02]		[ID.draft-idr-bgp-route-refresh-options-02]
	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-02.txt, May 2017.
	[ID.draft-ietf-idr-bgp-extended-messages-12]		[ID.draft-ietf-idr-bgp-extended-messages-12]
	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.		12.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,		DOI 10.17487/RFC1950, May 1996, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc1950>.		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,
	<http://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,		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2119>.		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,		DOI 10.17487/RFC2283, February 1998, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2283>.		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, <http://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,		DOI 10.17487/RFC4724, January 2007, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc4724>.		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, <http://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,		DOI 10.17487/RFC7313, July 2014, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc7313>.		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,		DOI 10.17487/RFC7911, July 2016, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc7911>.		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
	Avinash Lingala		Avinash Lingala
	AT&T		AT&T
	200 S Laurel Ave		200 S Laurel Ave
	Middletown, NJ		Middletown, NJ
	USA		USA
	Email: ar977m@att.com		Email: ar977m@att.com
			Csaba Mate
			NIIF/Hungarnet
			18-22 Victor Hugo
			Budapest 1132
			Hungary
			Email: matecs@niif.hu
	Jeff Tantsura		Jeff Tantsura
	Futurewei Technologies Inc		Futurewei Technologies Inc
			USA
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
End of changes. 27 change blocks.
	40 lines changed or deleted		59 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/