On Wed, Aug 12, 2009 at 10:03:23PM -0500, Richard A Steenbergen wrote:
On Wed, Aug 12, 2009 at 10:06:49PM -0400, Joe Provo wrote:
On Wed, Aug 12, 2009 at 08:16:38PM -0500, Richard A Steenbergen wrote: [snip]
Unfortunately the distributed nature of the databases is one of the biggest problems with the IRR system. Anyone can run an irrd, there is
You misspelled "largest strength". FOlks get to choose which registries to believe in what order, not required to have a single [politicized] entity.
Well, actually, no. I'm not aware of any mechanism under which you can effectively choose who to believe and in what order, nor do I think that it would make any real difference in the long run even if you could.
Experience proves otherwise. L3's filtergen is a great counter-example, where the customer-specific import policy dictates sources to believe regardless of what other stuff is in their local mirror. It happily drops prefixes not matching, so it does "make a real difference" WRT customer filtering. I'm not familiar with DTAG's tools, but would be shocked if they were less featureful. For querying other databases, see IRRd's !s syntax, which specifies sources in order. Also see Net:IRR's $whois->sources() method. For tools based on these, I would presume it be up to your implementation or policy expression as to how you decide the handling on multiple matches. When mentioned, usually the first which matches is specified as 'the one', which is why search order matters. What other purpose does specifying a search order serve?
IRR database mirroring is like being a tier 1, you have to peer with every other database out there in order to obtain a full view. That
Funny, subject of the thread is filtering customers. I don't need to take the same point of view of the RADB ("RADB's mission is to mirror all component databases so as to provide the most complete view possible of the entire IRR.") to do that, just a set of databases in which my customers can be/must be registered. Once upon a time, 3561 had a highly automated and effective way of doing this based in part upon running their own DB and that being the default/requirement for "non-advanced" customers. [snip]
Basically the only thing you have control over are the list of IRR databases which are searched, but the results which are returned are a superset of all databases which you selected to search. You don't get to say "only listen to results from LEVEL3's db for this object unless they don't have results there, in which case you listen to SAVVIS" or anything like that.
If I am running a tool to generate filter lists for my customers, I want to believe my RR, the local RIR, some other RIR that is well run, and then maybe my upstream. Specify that search order and believe the first match. Job done. If you have highly clued downstreams, go the filtergen route and tune source-believability based on customer, or cook up another avenue. There is nothing inherent in the system to prevent this. [snip]
from all the sources is always importing correctly, etc. And even after you do all this, what does being able to pick a data source order buy you anyways? Do you think you win something by preferring say RADB over LEVEL3 over SAVVIS over ARIN over RIPE over...?
Yes, reduced queries and the ability to ignore Bob's Bait and Tackle DB if I know it is part of the "piles of junk databases" you posit will exist. See above.
Where do you draw the line on who's data you look at, and why do we need yet another system where people are left to make a judgement call over who's data they should trust?
I'm not sure who has a better viewpoint on what my customers can/should emit cross my network than me, so yeah I should make the call regarding what databases my customers need to be in for my business. Obviously for multihomed or well-meshed customers you have to approach that sanely or you'll get serious pushback from folks registered elsewhere. In the earlier 3561 days, I had to get them to eat non-MCI sources for us so I wouldn't be doubly & trebly registered. Assuming a perfect global datastore will fail. It doesn't exist now, and migrating there to such a mythical beast is impossible. Run your corner as cleanly as you can and apply as much error correction as possible to the outside world. Since this topic is about running one's corner cleanly, taking the input from known-garbage is a bad plan.
Personally I'm of the belief that every ISP running their own IRR db is a very bad idea, which is why I have chosen not to run one myself. To quote Vijay, it doesn't scale. The last thing the already very broken IRR system needs is more crap data by more random people spread out over more databases, and the majority of the current db's probably need to be shut down too.
Centralized scales better than distributed? Quick, call the 80s - we need HOSTS.TXT back. Of course it isn't applicable for every 10-prefix shop that happens to run BGP because they have multiple 0/0s, but that is merely due to the effort not being worth the return for those people, not anything to do with scaling of the IRR system. If small fries did run their own nodes, they would need to get their providers to slurp the data, or be an LIR or.... I don't see a massive clamor for small fries though. The existing open-door IRR policy has only grown slowly over the years, not exploded. Heck, some older ones [cf this thread's subject, BELL, et al] seem to no longer be used by their owners and just might not be worth querying. So yeah, I think a level of reasonable discrimination based on existing data quality encourages increased data quality.
There is no reason that this process needs to be politicized, or cost anyone any money to use.
Anytime you go down the road of advocating authority centralization, you'll start getting people politicizing the process [cf icann, alternate roots, all the random frothing-at-the-mouth-until-they-fall-over types]. I rather think that can be avoided by properly embracing the distributed databases that do indeed function. Some can be side-stepped with RIR- based IRRs, and decently distributed down to LIRs, but we all know ARIN is still playing catchup here so it doesn't help our sphere in the near term. Money? Assuming a registry-based or provider-customer based DBs then it would be part of the existing relationship, no? Fees were being used at RADB in part as an incentive to get folks to clean up dead records. In Oct of 2002 Larry Blunk reported that they trimmed from 3150 maintainers down to 1972, though I'm not finding any numbers on non-maintainer objects purged ... I'm sure some were just M&A detritus that moved from one maintainer to another.
Again, we've made a horrible system here.
I think you've misspelled 'front end'. The system certainly seems to function, and the entire intent was that SPs would build their own customer-facing tools as well as internal tools. Seems we've fallen down in that regard, but irrpt [even if in php :-P] and the revival of IRRtoolset are indications that folks are still interested in building the internal widgets. In general I think you'd agree that the 'back end' of most all service providers did not keep pace with the growth of commoditization of service.
One reasonable solution is to have the server side run the complete query off its local database, and pass the complete results for a prefix-list back to the querier in a single transaction. [snip]
Again, your complaint isn't against "the IRR", but regarding an implementation specific ... which aligns with what 3561 used to do. We are straying dangerously close back to the thread topic. [snip]
Lots of folks set up systems for provisioning without deprovisioning. This is not an IRR problem, but a sloppy-human problem. Folks that get stuck with provisioning generally aren't incented to remove billable resources. CF good processes and management with backbone.
There is plenty of motivation to add data to IRR to make your announcements work, but no motivation at all to remove data when it is no longer needed. Nobody sees a problem with this until you step back and realize that a lot of networks have IRR records so sloppy that they list nearly every route on the Internet.
See what I wrote above; that is a provisioning/deprovisioning problem, not an IRR problem, and you know that. I know plenty of ISPs that don't perceive their lousy half-hearted attempts at deprovisioning *any* part of service to be a big deal, since improvements there doesn't make them money. As long as physical ports and circuits go back into inventory to sell to someone else, they could care less what data is left dangling. Sad but true. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE