Subject: [GROW] AS:nn community format and 32-bit ASNs

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Oct 2016 10:40:53 +0200

Hi all,

If this has been discussed before, my apologies.

RFC 1997 already talks about using the first 16 bits of the BGP community value to identify an AS and then the remaining 16 bits to indicate something relevant in that AS. Later this was made easier by formatting communities as AS:nn rather than a 32-bit integer in decimal form.

But now we have 32-bit AS numbers. The obvious solution is to use an extended community as per RFC 5668. However, the trouble with that is that you can't do anything with such a community unless your routers have built-in support for RFC 5668. So this creates a huge chicken and egg problem.

(If anyone has any data on RFC 5668 support out in the wild that would be useful.)

Obviously using AS:nn where AS:nn is 32 bits and AS is 32 bits doesn't leave much room for nn. But AS numbers are given out at ~ 10k/year so if we can support a million or so then we can still do something useful and backward compatible here while we wait for RFC 5668 support.

My question: have there been any previous efforts to define an AS:nn format for regular BGP communities that support 32-bit ASNs to some degree?

---

From: Job Snijders <[email-masked]>
Date: Tue, 4 Oct 2016 10:47:46 +0200

Hi Iljitsch,

On Tue, Oct 04, 2016 at 10:40:53AM +0200, Iljitsch van Beijnum wrote:
> My question: have there been any previous efforts to define an AS:nn
> format for regular BGP communities that support 32-bit ASNs to some
> degree?

Please review https://tools.ietf.org/html/draft-ietf-idr-large-community
and http://largebgpcommunities.net/

Kind regards,

Job

---

From: Ignas Bagdonas <[email-masked]>
Date: Tue, 4 Oct 2016 12:12:16 +0100

Hi Iljitsch,

> But now we have 32-bit AS numbers. The obvious solution is to use an extended community as per RFC 5668. However, the trouble with that is that you can't do anything with such a community unless yo…

Extended communities cannot represent an equivalent of AS4:AS4 in a form 
that standard communities can do with AS2:AS2, extended communities 
define a container for 6 bytes of payload total regardless of 
interpretation.

> (If anyone has any data on RFC 5668 support out in the wild that would be useful.)

Pretty much any implementation. It is still the same extended community, 
just with a different interpretation. It is up to the policy language of 
the implementation to allow to interpret it as an AS4 and not as a 
sequence of octets.

> Obviously using AS:nn where AS:nn is 32 bits and AS is 32 bits doesn't leave much room for nn. But AS numbers are given out at ~ 10k/year so if we can support a million or so then we can still do s…
5668 actually cannot solve this problem - there is not enough space in 
the path attribute available to carry full AS4:AS4.

> My question: have there been any previous efforts to define an AS:nn format for regular BGP communities that support 32-bit ASNs to some degree?

Yes, and Job beat me here. There are at least a couple of options 
(-large and -wide) plus some hacks (remapping and AS4 marker, both reuse 
standard communities, and both are ugly).

Ignas

---

From: [email-masked]
Date: Tue, 4 Oct 2016 13:28:11 +0200

On 4 Oct 2016, at 13:12, Ignas Bagdonas <[email-masked]> wrote:

> Extended communities cannot represent an equivalent of AS4:AS4 in a form that standard communities can do with AS2:AS2, extended communities define a container for 6 bytes of payload total regardless of interpretation.

Right, but the case where in XX:YY YY is also an AS number is much less common than the case where XX is an AS number but YY is just a small integer.

> Pretty much any implementation.

Not sure what you mean here.

> It is still the same extended community, just with a different interpretation.

Unless I'm mistaken, as a user you can't interact with extended communities unless the BGP implementation knows about the kind of extended community that you're dealing with. So if a router doesn't implement RFC 5668 there's no way for me to use the RFC 5668 communities.

> some hacks (remapping and AS4 marker, both reuse standard communities, and both are ugly).

I'm interested in those hacks. Maybe they're ugly but at least we can start using them today, and when the router vendors implement the hacks they'll show up as AS:nn as usual without any chicken/egg or boil the ocean issues.

---

From: Ignas Bagdonas <[email-masked]>
Date: Tue, 4 Oct 2016 13:13:53 +0100

> Right, but the case where in XX:YY YY is also an AS number is much less common than the case where XX is an AS number but YY is just a small integer.

For a particular use case that can be implemented with a small number 
having a specific meaning - yes, but for a more generic use case in a 
form of "AS this do not advertise to AS that", whete "this" and "that" 
are both AS4s, it is not possible. From the practical point of view, if 
a new path attribute is defined, it should be generic enough to cover 
all use cases reasonably known at present time. Otherwise it will be yet 
another short term hack that will result in problems later.

> Not sure what you mean here.

5668 is a form of an extended community, yes, it does have a specific 
subtype which will need to be implemented to correctly present the value 
of the extended community via user interface. Extended communities as 
such are implemented and deployed widely, even for plain IPv4 and IPv6 
address families - some examples below, including the AS4 based 5668. 
Any practical implementation that has support for L3VPNs will support 
extended communities.

> Unless I'm mistaken, as a user you can't interact with extended communities unless the BGP implementation knows about the kind of extended community that you're dealing with. So if a router doesn't…

It is specific to how a particular implementation presents it to user 
interface and routing policy language. On the wire, except of the 
specific subtype, the encoding is the same, and it is an agreement 
between the parties to interpret it in a particular way. There are 
various types of extended communities used in the field, a few examples 
from live view of RIPE collectors:

extcomm final RT:65165:132167 (Route Target) (type 0/2) (Two-Octet AS 
Specific Extended Community)
extcomm final RT:65171:132203 (Route Target) (type 0/2) (Two-Octet AS 
Specific Extended Community)
extcomm final RT:65204:222220000 (Route Target) (type 0/2) (Two-Octet AS 
Specific Extended Community)
extcomm final RT:65205:222220000 (Route Target) (type 0/2) (Two-Octet AS 
Specific Extended Community)
extcomm final RT:65207:222220000 (Route Target) (type 0/2) (Two-Octet AS 
Specific Extended Community)
extcomm final RT:0:197580 (Route Target) (type 0/2) (Two-Octet AS 
Specific Extended Community)
extcomm final RT:0:197999 (Route Target) (type 0/2) (Two-Octet AS 
Specific Extended Community)
extcomm final RT:0:198477 (Route Target) (type 0/2) (Two-Octet AS 
Specific Extended Community)
extcomm final RT:0:199399 (Route Target) (type 0/2) (Two-Octet AS 
Specific Extended Community)
extcomm final RT:843:105 (Route Target) (type 2/2) (4-Octet AS Specific 
Extended Community)
extcomm final RT:843:106 (Route Target) (type 2/2) (4-Octet AS Specific 
Extended Community)
extcomm final RT:843:300 (Route Target) (type 2/2) (4-Octet AS Specific 
Extended Community)
extcomm final RT:843:301 (Route Target) (type 2/2) (4-Octet AS Specific 
Extended Community)
extcomm final RT:843:60143 (Route Target) (type 2/2) (4-Octet AS 
Specific Extended Community)
extcomm final OSPF-RT:000000000501 (OSPF Route Type) (type 3/6) (Opaque 
Extended Community)
extcomm final OSPF-RT:0:1234736768 (OSPF Route Type) (type 0/6) 
(Two-Octet AS Specific Extended Community)
extcomm final RO:0:198570 (Route Origin) (type 0/3) (Two-Octet AS 
Specific Extended Community)
extcomm final RO:1027:1 (Route Origin) (type 2/3) (4-Octet AS Specific 
Extended Community)
extcomm final RO:11896:10000 (Route Origin) (type 2/3) (4-Octet AS 
Specific Extended Community)

> I'm interested in those hacks. Maybe they're ugly but at least we can start using them today, and when the router vendors implement the hacks they'll show up as AS:nn as usual without any chicken/e…

The remapping one is based on reusing an available AS2 number to mean a 
specific AS4 number. Ingress policy matches the incoming AS4 and tags 
the route with a new AS2 based standard or extendedc community. This is 
a risk for conflicts though.

AS4 marker one is based on splitting the 32 bit value part into two 16 
bit parts and carrying them as two standard or extended communities 
together. The risk here is that an AS4 split into two may result in a 
conflict with a legitimate AS2 value, therefore additional "marker" 
community is needed, and an implementation needs to allow for matching 
of all three of the elements in order to consider it for a correct match 
of the mapped community.

Both are prone to errors and conflicts - please do not use them, instead 
ask your vendors to implement the correct native AS4 solutions. That is 
not a huge price to pay to get an unambiguous solution to a problem that 
is real and urgent.

Ignas

---

From: [email-masked]
Date: Wed, 5 Oct 2016 00:50:09 +0200

On 4 Oct 2016, at 14:13, Ignas Bagdonas <[email-masked]> wrote:

> Both are prone to errors and conflicts - please do not use them, instead ask your vendors to implement the correct native AS4 solutions. That is not a huge price to pay to get an unambiguous solution to a problem that is real and urgent.

I'm all for a permanent solution, but routers just don't get updated with new features all that often.

A temporary solution could look like this:

I'm going to use AS-DOT notation for a bit here because it's easier for my purposes, obviously that's not a feature of my solution.

The RIRs have received AS number ranges in 2.x, 3.x, 4.x, 5.x and 6.x from IANA. 1.x is unused and 0.x is covered by existing 16-bit solutions. We need 19 bits to encode 32-bit AS numbers up to 7.65535. There are 1024 private AS numbers, so we can borrow 10 bits there. Then we use 9 bits from the nn in AS:nn, leaving us with 7 bits for the actual nn.

We encode the top 10 of the 19 bits in the private AS number space, but we do a bit of math to make sure that the range around ASN 65000 falls in the unused 0.x and 1.x ranges, because those are the most frequently used private 16-bit ASNs.

This way any 32-bit AS number up to 7.65535 can be used in AS:nn where nn can be 0 - 127, which is just about enough to encode a reasonable local preference value.

There are two ways to do this: with an unambiguous mapping between those AS:nn values and the 32-bit community value, or one where each AS:nn maps to a 32-bit value, but the 32-bit value can map to multiple AS:nn, for instance 263000:0 is equal to 65535:44032. If we allow this that also means we can accommodate ASNs above 7.65535. Those will just map to (AS mod 7):nn.

But if we allow this then there's no unambiguous mapping from the 32-bit community value to a text representation so filtering communities using regular expressions will no longer be possible.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 4 Oct 2016 20:10:29 -0400

On Tue, Oct 4, 2016 at 6:50 PM, <[email-masked]> wrote:

> ask your vendors to implement the correct native AS4 solutions. That is not
> a huge price to pay to get an unambiguous solution to a problem that is
> real and urgent.
>
> I'm going to use AS-DOT notation for a bit here because it's easier for my
> purposes, obviously that's not a feature of my solution.
>
> The RIRs have received AS number ranges in 2.x, 3.x, 4.x, 5.x and 6.x from
> IANA. 1.x is unused and 0.x is covered by existing 16-bit solutions. We
> need 19 bits to encode 32-bit AS numbers up to 7.65535. There are 1024
> private AS numbers, so we can borrow 10 bits there. Then we use 9 bits from
> the nn in AS:nn, leaving us with 7 bits for the actual nn.
>
> We encode the top 10 of the 19 bits in the private AS number space, but we
> do a bit of math to make sure that the range around ASN 65000 falls in the
> unused 0.x and 1.x ranges, because those are the most frequently used
> private 16-bit ASNs.
>
> This way any 32-bit AS number up to 7.65535 can be used in AS:nn where nn
> can be 0 - 127, which is just about enough to encode a reasonable local
> preference value.
>
> There are two ways to do this: with an unambiguous mapping between those
> AS:nn values and the 32-bit community value, or one where each AS:nn maps
> to a 32-bit value, but the 32-bit value can map to multiple AS:nn, for
> instance 263000:0 is equal to 65535:44032. If we allow this that also means
> we can accommodate ASNs above 7.65535. Those will just map to (AS mod 7):nn.
>
> But if we allow this then there's no unambiguous mapping from the 32-bit
> community value to a text representation so filtering communities using
> regular expressions will no longer be possible.
>
>
this proposal seems a bit complex, it doesn't appear to be required to be
so complex, and I think in ~2yrs time most everyone that cares about this
problem gets large-communities support in their devices.

Why pay complexity tax today for something that will be obsolete in ~2yrs
time?

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: [email-masked]
Date: Wed, 5 Oct 2016 07:47:36 +0200

On 5 Oct 2016, at 2:10, Christopher Morrow <[email-masked]> wrote:

> this proposal seems a bit complex, it doesn't appear to be required to be so complex,

The only complexity is the mapping. It would be nice to have something simpler that people can do in their head but I don't see how that can work and leave more than one digit for the nn part. And if it can't be simple enough to do in your head it doesn't really matter how complex the calculation is.

In use it's extremely simple: if your BGP implementation supports this, simply use AS:nn. If it doesn't, look up the mapping between the 32-bit AS:nn and the 16-bit AS:nn and put the 16-bit version in your configuration.

> Why pay complexity tax today for something that will be obsolete in ~2yrs time?

It won't be. You can't really use a new extended attribute until virtually everyone supports it. That's going to take much longer than two years.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 05 Oct 2016 08:58:04 +0100

> with new features all that often.

Extended communities have been around for years. Peoples' lack of
inclination to properly maintain their infrastructure is not a good
reason to introduce additional unnecessary complexity by defining
byzantine workarounds.

There seems to be a good deal of vendor / operator support for large
communities.  This fills in the rfc1997 gap for asn32s extremely well,
and should shortly start appearing in production code.

Nick

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 5 Oct 2016 12:08:38 -0400

> and should shortly start appearing in production code.
noting I don't disagree with nick, but a bit more color / reason for my
comment I think is helpful:

  o these communities are not expected to work across more than the
immediate remote peer, except possibly in the case of  IX's where the same
next bit of logic should hold, I think.

  o the folk that want to exploit the use of these new communities have a
reason to upgrade code to that which supports them

  o upgrade cycles are shorter if people have a reason to upgrade

I think, therefore, that a complex solution as a stopgap isn't worth the
work, when in  'short order' code and ability to use that on the network
will be here.