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@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)