Job Schneiders, NTT: “Large BGP Communities - Solving the Routing Problem Between AS Operators”

    In August this year, a discussion appeared in the IETF archives of ways to solve the problem of exchanging meta-information between autonomous systems (AS) using the RFC1997 BGP communities method. The fact is that the Internet again threatens to "end", and in the most unexpected way - because of a "skeleton in the closet" or a private but widespread case illustrating how serious the problem of technical debt known to any developer can be. First, we observed the problem of exhaustion of the IPv4 address pool, as a solution to which the non-100% functioning IPv6 standard was put into operation. Now, before our eyes, another tumor is brewing, however, it is connected with the same network routing. Written by Yob Schneiders from NTT



    An open letter to the IETF serves as the start of a public discussion of a problem that threatens to become critical soon. The fact is that the main convenience of RFC1997 is 32-bit recording. The first 16 bits belong to ASN, the last 16 carry some value. However, now one of the five operators of autonomous systems on the network has a 4-byte ASN (RFC4893) (4 bytes = 32 bits), which makes it impossible to use 16-bit recording (a 32-bit value simply does not work).

    An example of the Large BGP Community is: 2914: 1299: 40.

    We contacted Job Schneiders directly for comment on this issue.


    Yob Schneiders , IP Development Engineer at NTT Communications, Founder of NLNOG RING , Vice President of PeeringDB.

    Yob, in a nutshell, can you explain why larger BGP community is a solution to this problem?

    It's simple: RFC 1997 BGP Communities is what all ISPs (Internet Service Providers) use to exchange meta-information between autonomous systems. RFC 1997 style offers you 2 bytes, the new Large Communities - 8 bytes, which meets the requirements of many operators.

    Why is the problem compounded with every new hosted ASN?

    IANA has run out of 2-byte ASNs, so by default you will be assigned a 4-byte ASN, unless you ask otherwise. This means that using best practices, such as communities, for internal layout and routing will not be available to you. In at least standard ways, as other operators and networks do. You cannot just increase the complexity of network policies using existing documents - this increases the likelihood of errors.

    How does this problem affect ISPs and regular users?

    Ordinary end users, such as our parents, are unlikely to ever encounter this problem, but its direct consequence is imperfect routing, the transfer of traffic overseas when it could be localized. Most people will not feel the difference, but for workers of the "Internet sewer" any network distances above 50 ms are usually noticeable and require avoidance.

    How can I understand or test for a problem?

    If you have a BGP session with a 4-byte ASN or you have been assigned a 4-byte ASN by RIPE NCC, then this applies to you. This limits the options that you can provide to consumers, since you must use either a private number or capture someone else's.

    Is there any way to avoid or solve the problem?

    To date, there is no good way to avoid the problem. RFC 1997 BGP communities is some “Lingua Franca” (a term that unites the same language of different ethnic groups) between network operators, but there is no international agreement. Some network operators use private 2-byte ASNs in the first two bytes of the RFC 1997 communities, while other operators use Extended BGP Communities for other purposes. The result is “not the best” methods that harm the operator community.

    Finally, why is it urgent?

    It is because of the exhaustion of IANA numbers for AS. Your local RIR, ARIN, APNIC, Afrinic, LACNIC, and RIPE will no longer have resources to share. Previously, they allowed networks with problems to return a 32-bit ASN instead of 16-bit, but this option will close for them soon.

    Anyone wishing to become part of the process should join the IDR mailing list and read the archive. The IETF will vote on this issue until September 20.

    » Large BGP Communities Specification on the IETF.
    » Large BGP Communities Webpage .

    For support for Large BGP communities, contact your vendor.

    Also popular now: