The Internet works the way it works because of Internet Standards. These standards essentially are agreements between network operators “This is how our systems talk to each other”. For a technical specification such as Large BGP Community to become an officially recognised Internet Standard, there is a certain process to follow.

The IETF IDR Working Group governs the BGP specification. A crucial step in the standardisation process is to ask the Working Group to adopt the specification, and jointly refine and improve the document. The email below is our call to action.

Date: Tue, 06 Sep 2016 13:39:19 +0200
From: Job Snijders <job@ntt.net>
To: idr@ietf.org
Subject: [Idr] Request to adopt draft-heitz-idr-large-community

Dear IDR, fellow network operators,

I would like to request that the IDR Working Group adopts draft-heitz-idr-large-community as a working group document.

Background

RFC 1997 BGP communities are the most common method to signal meta-information between autonomous systems. RFC 1997 communities are a 32 bit entity. The convention is that the first 16 bits are the ASN in which the last 16 bits have a meaning. RFC 1997 is so popular because of its elegant simplicity and ubiquitous support.

The operator community (no pun intended!) is suffering from a fatal flaw. One in five ASNs in the Default-free zone are a 4-byte ASN (RFC 4893). One cannot fit a 32-bit value into a 16-bit field.

4-byte ASN Operators work around this issue by either resorting to kludges such as using private 16-bit ASNs as in the “Global Administrator” field, or by returning the ASN to their respective RIR and requesting a 16-bit ASN. However, both the RIRs and the IANA have depleted their supply of 16-bit ASNs.

Work to address the issue of BGP communities has been ongoing for years. Notable examples are ‘flexible communities’ (12 years ago) and ‘wide communities’ (6 years ago). The WG so far has been unable to produce an internet standard which enjoys a status similar to RFC 1997. Now that the RIRs are running out, the issue has become a matter of extreme urgency.

The Large BGP Community specification gives every network operator (regardless of whether they have a 2-byte ASN or a 4-byte ASN) 8 bytes to signal meta-information in an opaque fashion. This will align with current, well-established practices deployed by network operators.

The Large BGP Community has purposefully been specified to be narrow and as simple as possible to meet the operator community immediate needs, without dissuading from existing community extensions that are in the standards process pipeline.

The Large Community, by design, is not extendable, because extensibility comes at a cost. Knowing that the amount of noise generated by an idea is inversely proportional to the complexity of the idea, I urge the WG to consider the Large Community’s simplicity not a disadvantage, but a virtue.

We ask for your support in this narrow focus to re-imagine the RFC 1997 communities in this way as it should have been done when RFC 4893 was published.

Kind regards,

Job Snijders (co-author draft-heitz-idr-large-community)