ras at e-gerbil
Nov 2, 2009, 12:13 PM
Post #50 of 61
(894 views)
Permalink
|
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 [at] e-gerbil> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
|
