On Mon, Nov 02, 2009 at 01:38:00PM -0600, Jack Bates wrote:
Communities (except the standardized well known ones) are extremely diverse. For those that support even more granular traffic engineering by limiting which of their peers your routes might be transiting, I believe there are 2 distinct methods of using communities.
Even the standardized ones aren't guaranteed to be useful. For example RFC3765 defines a NOPEER community, i.e. a standardized way to say "do not export this route to peers" (in the settlement free bilateral sense of the word). But there is no possible way for the router to know what is or isn't a peer, so it's up to the operator to implement the matching for this supposedly "standard" community. But guess what, most people don't, and those that do implement the functionality end up writing their own network specific version anyways (either because they want to keep it secret, or because they need to implement far more powerful version anyways). If we want to turn this into a discussion on useful things to do with communities (to try and recover some value from this otherwise brain rotting thread), how about this one. We as network operators are currently facing a problem with BGP communities, and that problem is called 32 bit ASNs. Quite simply, 32 bit ASNs don't fit into the existing 16:16 scheme. There are new 64 bit communities (extended communities) out there, but they aren't a 1:1 mapping of the way communities work today. 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. So why do I bring this up? Because of those top 16 bits for type and subtype. Two of the type fields that are newly introduced in extended communities are "target" and "origin", which specifically mean "this tag is trying to tell $ASN something", vs "this $ASN is trying to tell you something". This actually has the benefit of addressing one of the most common problems with communities today, namespace collision between folks trying to both send instructions and receive data within the same ASN:xxxxx tag. Since we're all going to need to start updating our routing policies to support 32 bit ASNs soon anyways (unless you want to tell people getting them that they aren't allowed to use communities :P), now is a good time to start thinking about taking advantage of these new features to resolve age-old problems in your new community design. Another feature I think would be beneficial for router vendors to consider implementing is a way to "map" between regular and extended communities. For example, I might be able to apply a policy at the edge of my network which "imports" regular communities from my neighbor, and turns them into origin: tags of extended communities. I might then be able to update my internal network to work on extended communities, and translate them back again to regular for backwards compatibility at the edge. Also, now is a good time to find out if your router vendor ACTUALLY supports extended communities in all of their features (for example, regexp support), or if they only exist for l3vpn support and are not actually prepared to use them to work with 32-bit ASNs. Hint: Some vendors still fall into this category last I looked. Apologies if this post contained too much "clever" and made Randy's head explode. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)