Comprehensive community Guideline and Policies for an AS
jmaimon at ttec.com
Sun Feb 22 15:34:08 CST 2009
Kevin Blackham wrote:
> See nLayer. That should be the gold standard. :)
A gold standard is precisely what I am looking for.
nLayer's does look fairly comprehensive.
A few nitpick that lead me to hesitate to adopt it.
The informational tags comprised of
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.
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.
Import/Export Action Communities
These communities define specific import/export behaviors, and contain
location codes to specify which BGP sessions the actions should be applied
to. The second half of the Community will always be 4 digits long, and
will have the following structure:
ASN The Autonomous System Number to affect
A The export action to perform
C Continental code (or 0 for all continents)
R Regional code (or 0 for all regions)
PP POP Location code (city code)
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.
More information about the NANOG