Job Schneiders, NTT: “Large BGP Communities — A Solution to the Routing Problem between AS Operators”
In August of this year, a discussion appeared on the IETF archives about how to solve the problem of sharing meta-information between autonomous systems (AS) using the RFC1997 BGP communities method.
The fact is that the Internet again threatens to “end”, and in a most unexpected way - because of the “skeleton in the closet” or a particular, 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 pool of IPv4 addresses, as a solution to which the non-100% functioning IPv6 standard was put into operation. Now, before our eyes, another tumor is brewing, connected, however, with all the same network routing.
The open letter to the IETF, written by Job Schneiders of NTT, 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 the ASN, the last 16 bits carry some meaning. However, now one of the five autonomous system operators in the network has a 4-byte ASN (RFC4893) (4 bytes = 32 bits), which makes it impossible to use 16-bit writing (the 32-bit value simply does not hold).
')
Job Schneiders , IP Development Engineer at NTT Communications, founder of NLNOG RING , vice president of PeeringDB.
Yob, in a nutshell, can you explain why the larger BGP community is the solution to this problem?
It's simple: RFC 1997 BGP Communities is what all ISP (Internet Service Providers) use to exchange meta-information between autonomous systems. RFC 1997 style offers you 2 bytes, new Large Communities - 8 bytes, which meets the requirements of many operators.
Why is the problem aggravated with each new ASN placed?
IANA has exhausted 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 markup and routing will not be available to you. At least in standard ways, as other operators and networks do. You cannot simply increase the complexity of network policies using existing documents — this increases the likelihood of errors.
How does this problem affect Internet providers and regular users?
Ordinary end users, such as our parents, are unlikely to ever encounter this problem, but its direct consequence is imperfect routing, sending traffic across the ocean when it could be localized. Most people will not feel the difference, but for workers of the “Internet sewage” any network distances above 50 ms are usually noticeable and require avoidance.
How can you understand or test the problem?
If you have a BGP session with a 4-byte ASN or you have been assigned a 4-byte ASN by the RIPE NCC, this is your concern. This limits the options that you can provide to consumers, as it is necessary to 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 problems. RFC 1997 BGP communities is some “Lingua Franca” (a term that unites one 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 RFC 1997 communities, and other operators use Extended BGP Communities for other purposes. The result is “not the best” methods that harm the operator community.
Finally, why is this an emergency?
It is because of the exhaustion of the IANA numbers for AS. Your local RIR, ARIN, APNIC, Afrinic, LACNIC and RIPE will no longer have resources to exchange. Previously, they allowed networks with problems to return 32-bit ASN instead of 16-bit, but this option will close for them soon.
Anyone who wants to be 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 IETF Specification .
» Large BGP Communities webpage.
For support of Large BGP communities, contact your vendor.
The fact is that the Internet again threatens to “end”, and in a most unexpected way - because of the “skeleton in the closet” or a particular, 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 pool of IPv4 addresses, as a solution to which the non-100% functioning IPv6 standard was put into operation. Now, before our eyes, another tumor is brewing, connected, however, with all the same network routing.
The open letter to the IETF, written by Job Schneiders of NTT, 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 the ASN, the last 16 bits carry some meaning. However, now one of the five autonomous system operators in the network has a 4-byte ASN (RFC4893) (4 bytes = 32 bits), which makes it impossible to use 16-bit writing (the 32-bit value simply does not hold).
We contacted Yob Schneiders directly to comment on this issue.An example of a Large BGP Community is: 2914: 1299: 40 .
')
Job Schneiders , IP Development Engineer at NTT Communications, founder of NLNOG RING , vice president of PeeringDB.
Yob, in a nutshell, can you explain why the larger BGP community is the solution to this problem?
It's simple: RFC 1997 BGP Communities is what all ISP (Internet Service Providers) use to exchange meta-information between autonomous systems. RFC 1997 style offers you 2 bytes, new Large Communities - 8 bytes, which meets the requirements of many operators.
Why is the problem aggravated with each new ASN placed?
IANA has exhausted 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 markup and routing will not be available to you. At least in standard ways, as other operators and networks do. You cannot simply increase the complexity of network policies using existing documents — this increases the likelihood of errors.
How does this problem affect Internet providers and regular users?
Ordinary end users, such as our parents, are unlikely to ever encounter this problem, but its direct consequence is imperfect routing, sending traffic across the ocean when it could be localized. Most people will not feel the difference, but for workers of the “Internet sewage” any network distances above 50 ms are usually noticeable and require avoidance.
How can you understand or test the problem?
If you have a BGP session with a 4-byte ASN or you have been assigned a 4-byte ASN by the RIPE NCC, this is your concern. This limits the options that you can provide to consumers, as it is necessary to 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 problems. RFC 1997 BGP communities is some “Lingua Franca” (a term that unites one 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 RFC 1997 communities, and other operators use Extended BGP Communities for other purposes. The result is “not the best” methods that harm the operator community.
Finally, why is this an emergency?
It is because of the exhaustion of the IANA numbers for AS. Your local RIR, ARIN, APNIC, Afrinic, LACNIC and RIPE will no longer have resources to exchange. Previously, they allowed networks with problems to return 32-bit ASN instead of 16-bit, but this option will close for them soon.
Anyone who wants to be 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 IETF Specification .
» Large BGP Communities webpage.
For support of Large BGP communities, contact your vendor.
Source: https://habr.com/ru/post/309864/
All Articles