Upstream BGP community support

Fri Nov 6 05:06:56 UTC 2009

On Fri, Nov 06, 2009 at 12:04:18AM +0100, Daniel Roesen wrote:
> On Mon, Nov 02, 2009 at 02:13:38PM -0600, Richard A Steenbergen wrote:
> > Rather than simply double the size and break it
> > up into 32:32, the designers reserved the top 16 bits for "type" and
> > "subtype" attributes, leaving you only 48 bits to work with. Clearly the
> > only suitable mapping for support of 32-bit ASNs on the Internet is
> > 32:16, leaving us with exactly the same range of "data" values that we
> > have today.
> 
> ... which breaks schemes such as
> 
> 65123:45678
> 
> where 45678 is the neighboring AS to apply the action defined by
> 65123 to. Seen those multiple times.
> 
> Of course using anything else then your own ASN in the "AS part" of
> TE communities is certainly debatable.

Definitely a problem. The point of using 65123:45678 in the first place
(with a private ASN field in the "AS part") is to avoid stepping on
anyone else's ASN with your internal use community. Clearly we won't be
able to continue implementing this pattern AND fully support 32 bit
ASNs, so the type field is going to have to come to the rescue here. 

Fortunately there is a "transitive" bit on the extended community type
that could be used to signal a behavior to your upstream network without
allowing that community to leak any further, so in theory one could use
something like that to do a "localtarget:45678:actiondata" tag without
poluting the namespace. Uou would lose the ability to send a community
to your "upstream's upstream", but that is probably of questionable
legitimacy anyhow. But the way I read RFC5668 and the IANA extended
community registry it doesn't look like there is an explicit definition
of a non-transitive target type, and the way I read RFC4360 it doesn't
look like the non-transitive value gets automatically reserved. So I
guess someone will need to request 0x4002 and 0x4202 non-transitive
target types for this purpose. Unless someone has a better idea of how
to handle the problem stated above?

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)