Follow up to previous post regarding SAAVIS

Christopher Morrow morrowc.lists at gmail.com
Thu Aug 13 02:04:51 UTC 2009


On Wed, Aug 12, 2009 at 9:16 PM, Richard A Steenbergen<ras at e-gerbil.net> wrote:
> On Wed, Aug 12, 2009 at 07:37:00PM -0500, Frank Bulk wrote:
>> Perhaps this is a stupid question, but does each SP need to run their own
>> physical RR?  Isn't this something that could be hosted?
>
> The data itself is stored on a distributed network of databases, so
> there is technically no reason any SP needs to run their own. However,
> they often do, because when a customer can't figure something out it
> gives them access to go in and tweak the customers' records for them.

Another reason one might choose to run their own is you never want to
answer a customer with: "Well, we query the remote systems when we
need to build prefix lists and apparently the remote system
blacklisted us because we queried too many times this
hour/minute/day/week.. sorry 'bout that!"

It gives you control over the data format, availability, freshness
(sorta) and 'security' of the data you'd update your network with. Not
everyone has that set of requirements, but if you ask L3  or other
folks that do IRR based 'auto filtering' I bet they have an answer
along these lines.

> Unfortunately the distributed nature of the databases is one of the
> biggest problems with the IRR system. Anyone can run an irrd, there is
> no inherient authentication of the data. In order to get your irrd
> "recognized" all you have to do is get mirrored by a database that other
> people query and boom you're in the system. What tends to happen is
> someone puts a route into a database and then completely forgets about
> it, so there are a huge number of completely bogus routes out there
> which are never going to get cleaned up.

drum, drum, drum.. rpki! (and hopefully having that tied back to a
bill you pay... see sidr at ietf.org or wherever that list emanates from
these days)

> The other problem is that when a SP has a customer who "can't figure it
> out", a typical course of action is to just "register the route for
> them" rather than try to explain it to them. Unfortunately, the same
> thing as above happens here, you end up with a big pile of people who
> register a big pile of routes in a big pile of random databases, often
> times completely unnecessarily, and they'll never be removed either.
>
> The biggest problem with the entire system is the way that data gets
> into it, and the lack of incentive for people to ever remove data from
> it. But as a mechanism to allow the routes which need to be allowed, and
> mostly prevent accidental leaks, it works.

The above 2 paragraphs I think encapsulate what happened to ConEd in
~2005? (or someone-or-other-edison in newyork) Old/stale data which
cropped up in an unusual manner :(

> For more information, take a look at:
>
> http://www.nanog.org/meetings/nanog44/presentations/Tuesday/RAS_irrdata_N44.pdf

btw, +1 on irrtoolset.. good stuff.

-Chris




More information about the NANOG mailing list