On May 10, 2010, at 12:48 PM, Nick Hilliard wrote:
On 10/05/2010 17:00, Aaron Glenn wrote:
my gut says things would do well to begin with simply making an effort at maintaining usable irr data and automagically generating sane filters. why don't people do that again? I hope I'm not naively misunderstanding a primary use of irr data in front of 10,000 of my closest friends...
There are a lot of problems associated with using IRRDB filters for inbound prefix filtering.
- some clients announce lots of prefixes. This can make inbound prefix filtering difficult in some situations.
pixiedust:/home/nick> grep '>' pakistani-telecom.bgpdump.txt | wc -l 967
There are certainly issues around what a customer may have as their primary path and what they are backup for. These issues make for very long prefix-lists.
- there are some endemic data reliability problems with the IRRDBs, exacerbated by the fact that on most of the widely-used IRRDBs, there is no link between the RIR and the IRRDB, which means that anyone can register any address space. whois.ripe.net doesn't allow this, but lots of other IRRDBs do.
Certainly this is a function that you can petition your local RIR to do, have you made a proposal to them?
- the ripe whois server software does not support server-side as-set expansion. This is a really serious problem if you're expanding large ASNs.
Have you asked them to include this?
- there is very little client software. At least irrtoolset compiles these days, but its front-end is very primitive. rpsltool provides some really nice templating functionality, but doesn't implement large sections of the rpsl standards.
I certainly agree the tools here are suboptimal, but is that the the reason to throw the baby out with the bathwater? We're faced with a challenge here, where I surely agree with Peters argument that things won't get better here in the next ~7 years. Who is going to be the provider that turns away business because their customer is unwilling to register their routes in a klunky-toolset? What improvements to the toolset should go back to the community to improve filtering? If there is no RIR <-> IRR link, will people be willing/able to get a certificate when RPKI becomes more readily available? Will you accept a network outage because your certificate expires (vs a warning, ala SSL certs expired)? There are many questions here that require engagement by community members to provide viable solutions. Challenges certainly arise when you have nation-state telecom operators/incumbents involved as well that are unaccustomed to being told they MUST do something they may be unwilling to. - Jared