Follow up to previous post regarding SAAVIS
nanog-post at rsuc.gweep.net
Thu Aug 13 11:03:24 CDT 2009
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
> 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
> 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
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.
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.
> > 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
More information about the NANOG