At the March 2016 Netnod Spring Meeting Ignas Bagdonas (Equinix) presented his perspective on some form of “larger” BGP communities. In this presentation he identified issues faced by 4-byte ASNs Network Operators and provided an up to date overview of current and past attempts to mitigate those issues. After this presentation Job Snijders (NTT) and Bagdonas teamed up to jointly drive this effort forward.

In April 2016 Snijders flew to the US and was introduced by Jared Mauch (NTT) to Jakob Heitz (Cisco) over lunch. Heitz was intrigued by the effort and committed to provide running code for some form of a simple bigger BGP Community. This meant the first router vendor got on the train!

In May 2016 at the RIPE 72 meeting Bagdonas presented again in the Routing Working Group: video, pdf. In the Q&A session (starts at 16:30) Ruediger Volk (Deutsche Telekom) made on of the most formative comments on the larger communities effort. Volk said:

The discussions in IETF about extending this (red: communities) have been around for many years, and no progress has been made. Any proposal that has an extended functionality, comes with the problem that that discussion of the additional functionality does not have a proof of termination.

In other words, the IETF suffers from Bikeshedding. Volk went on to say that something similar to the opaque approach of RFC 1997 should be done, where the first bits indicate “Who owns the namespace” followed by some extra bits for the actual routing policy work.

It was this specific argument about namespace that led to define Large BGP Communities as a 96-bit entity: Every operator, whether they have a 2-byte or a 4-byte ASN, should have 64 bits (8 bytes) of room to signal information or trigger actions in their network. With 8 bytes available to the network operator, there even is enough to target a 4-byte ASN and still have space for an action such as ‘prepend’ or ‘dont export’.

Volk also provided the effort with a challenge:

If we go really fast track, we’ll be there in 5 years time, not before.

Challenge accepted! :-) Our mission is to get deployable code into the hands of operators in 2017. Progress can be followed here: Current implementation overview.

If you follow the Large BGP Communities technical specification in the IETF, the sharp observer will notice something unusual: instead of piling on new features and extra functionality as the draft matures, the exact opposite is happening. Any unnecessary fat is being cut away, for example see the difference between version -01 and -02.

And this is what the future looks like: a bigger BGP community that is not only simple to implement, but also easy to explain over lunch.