< draft-przygienda-idr-compressed-updates-00.txt   draft-przygienda-idr-compressed-updates-01.txt >
Network Working Group A. Przygienda Network Working Group A. Przygienda
Internet-Draft Juniper Internet-Draft Juniper
Intended status: Standards Track March 10, 2017 Intended status: Standards Track A. Lingala
Expires: September 11, 2017 Expires: December 19, 2017 AT&T
J. Tantsura
Futurewei Technologies Inc
June 17, 2017
Compressed BGP Update Message Compressed BGP Update Message
draft-przygienda-idr-compressed-updates-00 draft-przygienda-idr-compressed-updates-01
Abstract Abstract
Specification of compressed BGP update message formats and This document provides specification of an optional compressed BGP
procedures. update message format to allow family independent reduction in BGP
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
skipping to change at page 1, line 37 skipping to change at page 1, line 41
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 September 11, 2017. This Internet-Draft will expire on December 19, 2017.
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 18 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . 6
4.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Decompressor Capability . . . . . . . . . . . . . . . . . 7 6.1. Decompressor Capability . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
BGP as a protocol evolved over the years to carry more and more BGP as a protocol evolved over the years to carry larger and larger
information and this trend seems to continue unabated. And while volumes of information and this trend seems to continue unabated.
lots of the growth can be contributed to the advent of new address And while lots of the growth can be contributed to the advent of new
families spurred by [RFC2283], steady increase in attributes and address families spurred by [RFC2283], steady increase in attributes
their size adds to that. Recently, even the same NLRI may be and their size amplifies this tendency. Recently, even the same NLRI
advertised multiple times by the means of ADD-PATH may be advertised multiple times by the means of ADD-PATH [RFC7911]
[ID.draft-ietf-idr-add-paths-15] extensions. All those developments extensions. All those developments drive up the volume of
drive up the volume of information BGP needs to exchange to information BGP needs to exchange to synchronize RIBs of the peers.
synchronize RIBs of the peers.
Although BGP update format provides a simple "semantic" compression Although BGP update format provides a simple "semantic" compression
mechanism that avoids the repetition of attributes if multiple NLRIs mechanism that avoids the repetition of attributes if multiple NLRIs
share them already, in practical terms, the packing of updates has share them already, in practical terms, the packing of updates has
proven a difficult challenge. The packing attempts are further proven a difficult challenge. The packing attempts are further
undermined by the plethora of "per NLRI-tagging" attributes such as undermined by the plethora of "per NLRI-tagging" attributes such as
extended communities [RFC4360]. extended communities [RFC4360].
One could of course dismiss the growing, raw volume of the data One could of course dismiss the growing, raw volume of the data
necessary to exchange BGP information between two peers as a mere necessary to exchange BGP information between two peers as a mere
skipping to change at page 3, line 30 skipping to change at page 3, line 34
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-12] 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 the number of IP packets TCP TCP MSS in virtualized environments and the number of IP packets
starts to generate more and more overhead before real BGP update TCP generates, more and more context switching overhead per update
processing can happen. is necessary before good-put BGP processing can happen.
Obviously, unless we change BGP encoding drastically by e.g. Obviously, unless we change BGP encoding drastically by e.g.
introducing more context to allow for semantic compression, we cannot introducing more context to allow for semantic compression, we cannot
expect a reduction in data volume without paying some kind of price. expect a reduction in data volume without paying some kind of price.
Ideas such as changing BGP format to allow for decoupling of Ideas such as changing BGP format to allow for decoupling of
attribute value updates from the NLRI updates could be a viable attribute value updates from the NLRI updates could be a viable
course of action. The challenges of such a scheme are significant course of action. The challenges of such a scheme are significant
and since such "compression" would extend the semantics and formats and since such "compression" would extend the semantics and formats
of the updates as we have them today, former and future drafts may of the updates as we have them today, former and future drafts may
interact with such an approach in ways not discernible today. Last interact with such an approach in ways not discernible today. Last
but not least, attempting to introduce a smarter, context-rich but not least, attempting to introduce a smarter, context-rich
encoding is likely to cause dependency problems and slow-down in BGP encoding is likely to cause dependency problems and slow-down in BGP
encoding procedures. encoding procedures.
Fortunately, some observations can be made and an emerging trend Fortunately, some observations can be made and emerging trends
exploited to attempt a reduction in BGP data volumes without this exploited to attempt a reduction in BGP data volumes without the
kind of disadvantage: mentioned disadvantages:
o BGP updates are very repetitive. Smallest change in attribute o BGP updates are very repetitive. Smallest change in attribute
values causes extensive repetition of all attributes and any values causes extensive repetition of all attributes and any
difference prevents packing of NLRIs in same update. On top, each difference prevents packing of NLRIs in same update. On top, each
update message BGP still carries a marker that largely lost its update message BGP still carries a marker that largely lost its
practical value some time ago. One could summarize that by saying practical value some time ago. One could generalize those facts
that BGP updates tend to exhibit very low entropy. by saying that BGP updates tend to exhibit very low entropy.
o CPU cycles available to run control protocols are getting more and o CPU cycles available to run control protocols are getting more and
more abundant as does to a certain extent memory. They tend to more abundant as does to a certain extent memory. They tend to
not be available anymore in easily harvested "single core with not be available anymore in easily harvested "single core with
higher frequency" form factors but as multiple cores that higher frequency" form factors but as multiple cores that
introduce the usual pitfalls of parallelization. In short, introduce the usual pitfalls of parallelization. In short,
getting a lot of independent work done is getting cheaper and getting a lot of independent work done is getting cheaper and
cheaper while speeding up a single strain of execution depending cheaper while speeding up a single strain of execution depending
on previous results less so. This opens nevertheless the on previous results less so. This opens nevertheless the
possibility to apply different filters on BGP streams, possibly possibility to apply different filters on BGP streams, possibly
skipping to change at page 4, line 42 skipping to change at page 4, line 46
In broadest terms, such a scheme will be beneficial if a BGP In broadest terms, such a scheme will be beneficial if a BGP
implementation finds itself in an I/O constrained scenario while implementation finds itself in an I/O constrained scenario while
having spare CPU cycles disponible. Compression will ease the having spare CPU cycles disponible. Compression will ease the
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 requests IANA to assign new BGP message type value and This document will request IANA to assign new BGP message type value
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 is 6 and for the Capability Code the suggested value is 76. type in this process will be 6 and for the Capability Code the
suggested value will be 76.
IANA is requested as well to assign a new subcode in the "BGP Cease IANA will be requested as well to assign a new subcode in the "BGP
NOTIFICATION message subcodes" registry. The suggested name for the Cease NOTIFICATION message subcodes" registry. The suggested name
code point is "Decompression Error". The suggested value is 10. for the code point will be "Decompression Error". The suggested
value will be 10.
4. Procedures 4. Procedures
4.1. Decompression Capability Negotiation 4.1. Decompression Capability Negotiation
The capability to *decompress* a new, optional message type carrying The capability to *decompress* a new, optional message type carrying
compressed updates is advertised via the usual BGP optional compressed updates is advertised via the usual BGP optional
capability negotiation technique. capability negotiation technique.
A peer MUST NOT send any compressed updates towards peers that did A peer MUST NOT send any compressed updates towards peers that did
not advertise the capability to decompress. A peer MAY send not advertise the capability to decompress. A peer MAY send
compressed updates towards peers that advertised such capability. compressed updates towards peers that advertised such capability.
4.2. Compressed BGP Update Messages 4.2. Compressed BGP Update Messages
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 normal BGP update Update". It contains inside arbitrary number of following message
messages following each other and compressed while following the types
rules below:
o normal BGP updates
o Enhanced Route Refresh [RFC7313] subtype 1 and 2 (BoRR and EoRR)
o Route Refresh with Options
[ID.draft-idr-bgp-route-refresh-options-02] subtype 4 and 5 (BoRR
and EoRR with options)
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 compressed per Section 4.3. After decompression of the stream of
and interleaved uncompressed BGP update messages the resulting interleaved compressed and uncompressed BGP update messages the
sequence of updates does not have to be identical to the sequence resulting sequence of updates does not have to be identical to
in a stream generated without compression. However, the the sequence in a stream generated without compression. However,
uncompressed sequence MUST ensure that the ultimate semantics of the uncompressed sequence MUST ensure that the ultimate semantics
the updates are the same to the peer as in the no-compression of the updates are the same to the peer as in the no-compression
case. case.
2. The updates contained within the compressed BGP update message 2. The updates contained within the compressed BGP update message
MUST be stripped of the initial marker while preserving the BGP MUST be stripped of the initial marker while preserving the BGP
update message header. The length field in the BGP update header update message header. The length field in the BGP update header
retains its original value. retains its original value.
3. Each compressed BGP Update MUST carry a sequence of non- 3. Each compressed BGP Update MUST carry a sequence of non-
fragmented original updates, i.e. it cannot contain a part of an fragmented original updates, i.e. it cannot contain a part of an
original BGP update. Section 4.3 presents the only exception to original BGP update. Section 4.3 presents the only exception to
skipping to change at page 8, line 11 skipping to change at page 8, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document specifies only DEFLATE Huffman support per [RFC1950]. This document specifies only DEFLATE Huffman support per [RFC1950].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | CM | CINFO | Reserved | | Code | Length | CM | CINFO | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: TBD, suggested value of 76. Code: To be obtained by early allocation, suggested value in this
process will be 76.
Length: 1 octet. Length: 1 octet.
CM: 3 bits of CM indicating DEFLATE compressed format value as CM: 3 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.
skipping to change at page 8, line 35 skipping to change at page 8, line 44
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: TBD, suggested value is 6. Type: To be obtained by early allocation, suggested value in this
process will be 6.
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 32 skipping to change at page 9, line 45
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 and creative process. Thanks to Eric Rosen, Jeff Haas, Acee Lindem and
Jeff Tantsura for their careful reviews. Jeff Tantsura for their careful reviews.
9. Normative References 9. Normative References
[ID.draft-ietf-idr-add-paths-15] [ID.draft-idr-bgp-route-refresh-options-02]
Walton et al., D., "Advertisement of Multiple Paths in Patel et al., K., "Extension to BGP's Route Refresh
BGP", internet-draft draft-ietf-idr-add-paths-15.txt, May Message", internet-draft draft-idr-bgp-route-refresh-
2016. 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., "Advertisement of Multiple Paths in 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,
<http://www.rfc-editor.org/info/rfc1950>. <http://www.rfc-editor.org/info/rfc1950>.
skipping to change at page 10, line 37 skipping to change at page 11, line 5
[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, <http://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,
<http://www.rfc-editor.org/info/rfc7313>. <http://www.rfc-editor.org/info/rfc7313>.
Author's Address [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016,
<http://www.rfc-editor.org/info/rfc7911>.
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
AT&T
200 S Laurel Ave
Middletown, NJ
USA
Email: ar977m@att.com
Jeff Tantsura
Futurewei Technologies Inc
Email: jefftant.ietf@gmail.com
 End of changes. 21 change blocks. 
48 lines changed or deleted 69 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/