Comprehensive community Guideline and Policies for an AS

Sun Feb 22 23:58:41 UTC 2009

> nLayer's does look fairly comprehensive.
> 
> A few nitpick that lead me to hesitate to adopt it.
> 
> The informational tags comprised of
> 
> 4436:TCRPP
> 
> T   The type of relationship that the route was learned through
> C   The continent where the route was learned
> R   The region where the route was learned
> PP  The POP location (city code)
> 
> Type of routes have a maximum of 6 possible types. That could be 
> limiting. nLayer lists 1-5 types already, granted those are the 
> typical relationships and should cover most needs.

Designing a community system requires coming up with creative ways to
stuff as much data as possible into a fairly limited amount of space,
which obviously means you're going to have to make some compromises from
what might be ideal. I addressed a lot of these design considerations in
my NANOG presentation on the subject:

http://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf

Since the underlying field is only 16 bits, the maximum possible value
is 65535. If each character is going to be used as a "field", then
obviously you either have to limit the first digit to 6 and the second
digit to 5, or the first digit to 5 to allow a full range of values in
the second digit. Since there were really only 5 relationship types
which I ever need to express, but more than 5 potential continents to
cover, I decided to go with the system above. If you have different
considerations in your network, it only makes sense to design this
differently.

> Pop location code has a maximum of 99. nLayer is already up to 30.
> 
> What are they going to do when they reach 100? Suppose instead of 
> cities you wanted to number pops? Quite conceivable to have multiple 
> pops in the same city.

Again, this was part of the design consideration. Given the limited
amount of space and all the data we wanted to include, the decision was
made to limit city codes to 99. Given our plans for network expansion,
which don't involve becoming a telco and going into a massive number of 
cities, this was a reasonable compromise.

One possible way to encode more data is to split things into multiple
community tags, each one defining a specific type of information. The
reason we didn't go this route was that it makes it harder for end users
to match on combinations of information, since they would have to do AND
type matching with multiple regexp statements. If this is less of a
consideration for you than you can certainly fit more and bigger data
using multiple communities, but we decided we were happy enough with 
what we had and wanted it keep it user friendly.

> Using other ASN's as part of your communities policy raises two 
> issues:
> 
> - Is it a good idea without drawback (sprint does this also but only 
> with private ASNs)?
> 
> - How will this scale to 4byte ASN's?
> 
> Anyways, the point I am working from is that there are too many
> divergent approaches and all networks cant be that different and there
> should be one general approach that will work for all.

I also talked about this point in my presentation. Our motiviation for 
using the real target ASN in the first half of the community was to 
implement script-based automatic support for communities targetting all 
eBGP neighbors rather than just a limited handful. This causes several 
other areas of "increased difficulty" as well, but I personally think it 
is valuable enough to make it worth the effort.

Another way we considered but decided against was the use of private
ASNs on the left side to control actions, and the data side on the right
half to select a target, for example:

64512:1239 (apply some action 64512 to neighbors AS1239)

But we decided against this due to the extreme limitations this would
place on the action fields. The private ASN range of 64512-65535 only 
supports 2 characters with a full range, and just shifts the potential 
community conflicts into the private ASN space anyways.

As far as 4 byte ASN support goes, in order to provide any real support 
for them we're all going to have to switch to extended communities, 
which will probably be far trickier than the actual AS4 implementation 
itself. The format for 4 byte ASN support is:

http://tools.ietf.org/id/draft-rekhter-as4octet-ext-community-03.txt

Which defines:

16 bits of Type and Subtype values
32 bits of Global Administrator value (i.e. the ASN)
16 bits of actual user-defined data

One very nice thing this brings to the table is the addition of the type
and subtype fields. Just in the two basic type definitions which are a
part of the RFC we already have a very useful innovation, the use of
"origin" (i.e. informational communities set by the specified ASN) and
"target" (i.e. action communities to be applied to the specified ASN)
communities.

Unfortunately vendor support is very basic right now, and nobody seems
to have given much thought to how we're all going to successfully
transition to them. I personally think the only reasonable way to do it
is to add a policy mechanism for converting between types on network
borders, but nobody seems to have gone this route so far. I think people
are assuming vendors are more prepared than they actually are, not
understanding that most of the functionality and testing is for little
more than l3vpn support. Try rewriting your policies to support both 
regular and extended communities and see how easy it is. :)

-- 
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)