This week I was mindlessly going around “the internet” and stumbled upon an interesting IETF RFC draft from the Inter Domain Routing Working Group (IDR WG). The draft is for Large BGP Communities and is currently its 6th version.

What is it why do we need it?

You probably heard of BGP communities. This BGP attribute is defined in RFC 1997 is one of the most used attributes to help service providers apply specific routing policies to a group of prefixes sharing some common property.

BGP Communities are 4 Byte (32bit) values represented as A:B, where A is the decimal representation of the first 2 Bytes and B the decimal representation of the lower 2 Bytes. It is common practice to use the first 2 Bytes as an AS number and the last 2 Bytes to convey information to upstream routers (such as a Local Preference value to be set).

But there is a problem with this. RFC 1997 has been in use since 1996 and since then a lot has changed. One of these changes is the RFC6793 which defined the capability of BGP speakers to use 4 Byte (32bit) AS numbers instead of the shorter 2 Byte (16 bit) AS numbers.Since RFC6793, any company assigned with a 4 Byte ASN has no way of correctly encoding BGP communities with the first group of octets as their ASN. That would use all use all 4 Bytes available and no extra information could be added. Using only the first 2 Bytes of the ASN or private ASNs is not recommended as this has the potential for collisions with existing 2 Byte ASNs.

This is where Large BGP Communities comes in.

How big are these Large Communities?

The Internet Draft document defines a new BGP attribute with type code 32 (initially 30 ). The attribute is 12 Bytes in length (3 times the current BGP communities).

Each 12 Byte Large BGP Communities value represents three four-octet values, as follows:

• Global Administrator: Should be the Autonomous System Number
• Local Data Part 1: Operator defined value
• Local Data Part 2: Another operator defined value

A large community must be represented in 3 parts: A:B:C each one represented as a decimal number. For example:

64496:1:2   /    64497:0:0   /    64496:64511:500   ….

If you are confused, don’t worry. Just like RFC1997 communities (“the original”), Large Communities are just numbers that are split and represented in a special way with each portion of the number given a special meaning. If you are familiar with IPv4 addressing you are already familiar with this concept. IPv4 addresses are 4 Byte (32bit) numbers that are represented as 4 groups of decimal numbers (called octets). Your organization may plan addressing in such a way that each octet’s value has a meaning inside your organization.

The draft does not have any rigid mandatory use for the 3 fields. It is up to the entities peering to define what the values represent. But usually as implementations come out we converge to at least a small set of common rules. One of the authors of the Large Communities draft already created a new draft “Usage of Large BGP Communities” which should provide some guidance.

Implementers liked this new attribute because it is simply larger with not much extension or additional functionalities and are easy to implement. The old 2 Byte ASN are easily supported by simply setting all higher order Bytes to 0 (zero) and even the well-known community values can simply be encoded as 0:0:VALUE.

Implementations

The site has a page dedicated to tracking existing implementations. Currently, most of them are by open source BGP software with the only big name being Cisco Systems in IOS XR. I did not find any public Cisco configuration guides referring to this new attribute but its probably coming in the next software releases/SMU’s.

Want to know more?

If you want to follow up on the progress of this document you may do so not only on the IETF pages but also on its own website:

largebgpcommunities.net

4 Byte ASNs in Angola

Here, 11 of the 42 ASNs (26%) are 4 Byte ASNs. The first one was allocated in August/2010 and the most recent one less than a month ago in October/2016 (data from 8/November/2016).

AS 327691    11/08/2010
AS 327775    07/07/2014
AS 327788    01/09/2014
AS 327801    01/10/2014
AS 327806    13/10/2014
AS 327833    28/01/2015
AS 327918    11/08/2015
AS 327932    17/09/2015
AS 328042    12/07/2016
AS 328046    19/07/2016
AS 328085    14/10/2016

… And Africa?

In Africa, of the 1409 ASNs allocated, 401 are 4 Byte ASNs. That’s 28% of ASNs, getting close to a 3rd!!

To tell you the truth, the numbers surprised me. There is indeed reason enough for us to care about this draft.

Where did I get this ASN data?

From AFRINIC, our Regional Internet Registry (RIR). All RIR’s publish IP and ASN delegations daily and make it available via FTP. You are free to browse current and past data in: ftp.afrinic.net/pub/stats/afrinic/

——-

Large BGP Communities Internet Draft
https://tools.ietf.org/html/draft-heitz-idr-large-community

Large BGP Communities Website
http://largebgpcommunities.net/

NLNOG 2016 – Large BGP Communities – Job Snijders (Youtube)

BGP Communities Attribute
https://tools.ietf.org/html/rfc1997

An Application of the BGP Community Attribute in Multi-home Routing
https://tools.ietf.org/html/rfc1998

BGP Support for Four-Octet Autonomous System (AS) Number Space
https://tools.ietf.org/html/rfc6793

A Border Gateway Protocol 4 (BGP-4)
https://tools.ietf.org/html/rfc4271

IANA BGP Parameters
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml

Afrinic extended allocation and assignment report (Latest)
http://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-extended-latest

Understanding BGP Communities and Configuration
https://www.noction.com/blog/understanding_bgp_communities
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/28784-bgp-community.html