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 network operators using 4-byte ASNs and provided an up to date overview of current and past attempts to mitigate those issues. After this presentation, I teamed up with Ignas to jointly drive this effort forward.
In April 2016, I flew to the US and was introduced by my colleague 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, Ignas presented again in the Routing Working Group: video, pdf. During the following Q&A session (starts at 16:30), Ruediger Volk (Deutsche Telekom) made one of the most formative comments on the larger communities effort. Ruediger said:
The discussions in IETF about extending this (read: 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. Ruediger 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 the definition of 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 is even enough to target a 4-byte ASN and still have space for an action such as “prepend” or “don’t export”.
Ruediger 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.
Original post appeared on Large BGP Communities.
Job Snijders is IP Development Engineer at NTT Communications.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.