On 10/05/2006, at 10:57 PM, Jamie Baddeley wrote:
Another thing I've also been thinking about is community attributes. Using it to turn on remote blackholing with upstreams is useful, and we saw at NZNOG the approach to communicate enhancements or variations of that. But lowest common denominator suggests that using an agreed set of community attributes (which works for everyone) to convey stuff is something that should be worked on first.
You can most likely advertise blackhole routes to your transit provider(s) today.
So, combining an agreed set of local_pref's and some community attributes might be the basis of building a broader, and faster exchange between participants.
You mean, a 'standard' for use by NZ operators when peering? Would many operators be open to such things? With providers trying to route hot-potato as much as possible, I can see this causing a few.. problems. I'm not a fan of applying local-pref to networks advertised by customers/peers, unless there are knobs (ie. community tags) in place to remove/modify what that local-pref is. Otherwise problems arise when trying to run backup-only links, etc. Some standard filtering templates for 'less clueful' operators would probably be useful here. <..>
Is a really scary example of how carried away one could get, but some of the ideas are interesting.. Especially the geographic stuff.
Most of the large transit providers have similar geographical tags. It's really useful, because it allows them to sell transit to certain locations. Though, has anyone seen that as a product? Note that some of providers don't publish this information, ie. you have to do the NDA dance to get hold of it. None of them (AFAIK) guarantee it. `whois -h whois.radb.net AS3356' tells you what Level3 do. Kudos to them for publishing that info, note that others publish it also. Also note that if your transit providers will re-advertise your prefixes with communities intact, you can take advantage of the Level3 communities even if you're not a direct customer/peer.
anyway...There's probably a gazillion variations that one could adopt, but one question I have is how much pain would it be for other operators to implement a common convention? I can't recall this sort of thing being discussed on the NOG.
Probably not a huge pain, but I'm not sure it adds huge value. It's definitely 'cool', but how often would it actually be used? Definite value (perceived vs. realistic is debatable) for your customers if you are a transit provider, but I'm not sure that it would be used a huge amount for generic peering. Hmm.. I suspect you're probably not the first person to suggest something like this, though. Other than the 'Well-known' attributes defined in RFC1997, has anyone seen a 'standard' or similar that covers some of this stuff that providers could be encouraged to implement? Another note.. how many providers filter communities from incoming advertisements? Do you filter all communities, or just communities that start with your ASN (in ASN:X format, for you pedants out there)? Did you just start filtering since you got this email? :-) Also, do you advertise communities to your peers/transit providers? </ramble> -- Nathan Ward