At last months NANOG 68 and RIPE 73 events, both Greg Hankins and Job Snijders presented on the status of Large BGP Communities.
BGP (Border Gateway Protocol) has been a part of global Internet routing since 1989. Some of its design reflects what we knew of ‘scale’ in those days, including the use of 16-bit numbers for the Autonomous System (AS) identifiers.
These are pretty fundamental to how BGP operates; marking the set of Internet address prefixes that are managed collectively by that AS Number (ASN). So, carrying an ASN around in BGP is reasonably fundamental to how it works.
The problem is that ASNs were designed for a simpler world and a simpler time. And just like IPv4 addresses, it turns out we don’t have enough 16-bit ASNs, and have had to adapt the AS numbering system to cope with larger values.
From 16-bit ASNs we have grown to 32-bit ASNs – 32 bits occupying four 8-bit bytes. Deployment of these so-called 4-byte ASNs has been underway for some time now. Work has been done inside the RIR policy process to ensure a smooth migration to these ASN values including how to specify them for use in the BGP with 4-byte ASNs and 2-byte ASNs at the same time. In most cases, this has worked well; we have substantive deployment of both kinds in the global routing table.
But there is one sub-area of BGP which can’t handle 4-byte ASNs: the BGP communities mechanism. BGP uses special sub-packets inside the protocol to exchange values that encode as 32-bit values, and use one of these 32-bit values to associate two 16-bit numbers; one identified as an ASN and the other as an arbitrary community tag. This permits a relationship between the two values to be specified cleanly and permit BGP routing decisions to be informed by the community tag associated with a given ASN.
This worked fine for 2-byte ASNs, but can’t cope with making statements about a 4-byte ASN, or even worse, about two 4-byte ASNs. This means the BGP communities mechanism can’t be used simply with 4-byte ASNs to mark routes inside the BGP and so affects the ability to specify more complex routing policies.
This has led to pressure on the very small remaining pool of 2-byte ASNs, and hence a problem for the longer term; we give out a 4-byte ASN by default, but have had to conserve some supply of 2-byte ASNs to give to people unable to perform their routing adequately in this model.
Job Snijders, along with others, has been specifying the mechanism to define a new BGP community mechanism: the large BGP community draft, which is now going through the IETF process. This specifies how to send 96 bits of information, which is enough to send two 4-byte ASNs and an additional 32 bits of extra data (which comprises 16 bits of extra routing information) and some overhead. It’s more than enough to mark any combination of two ASNs from either all 4-byte, all 2-byte, or a mixture of the two.
Why does this matter?
Well, it matters immensely. Having two kinds of things, which really want to be a single unitary number space, is a huge hassle. It leads to: sub-divisions in the behaviour of routing; the mixture of can and cannot interoperate; and/or express complex routing policy, which causes problems on both sides of a given divide in meaning and understanding.
What this draft does is reunify the space into a single cohesive ASN number field, where it makes no difference if you have a 2-byte or a 4-byte ASN, and want to interoperate with other BGP speakers.
But that depends on *implementation* – it depends on the vendors deploying the code changes and ensuring they work, as well as getting vendors to run BGP in the wide. That’s where you, the community come in, because Job wants to encourage you all to think about this and make sure your supply chain for BGP routing understands you need this behaviour deployed.
Job and Greg have set up a website where they are writing more information on deployment and testing experiences as the draft goes through the IETF process. It’s well worth a look, and we’ve invited Job to come into the APNIC region and talk to us about large BGP communities, and get some work started here to ensure it gets deployed.
Have a look at his work at http://largebgpcommunities.net/
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.