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 your routers have built-in support for
RFC 5668. So this creates a huge chicken and egg problem.
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 something useful and backward
compatible here while we wait for RFC 5668 support.
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
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
