Follow up to previous post regarding SAAVIS
nick at foobar.org
Thu Aug 13 06:09:10 CDT 2009
On 13/08/2009 04:03, Richard A Steenbergen wrote:
> In fact this is one of
> the reasons why querying data from RIPE is such a pain, their query
> language lacks a recursive service side expansion mechanism so the
> transaction latency turns querying a large AS-SET into a multi-hour or
> day long operation.
I've brought this to RIPE's attention before, but the suggestion was met
with a sharp inhalation of breath and a discussion about exactly how
difficult that might be. The ripe whoisd code-base is too complicated.
[Server side UTF8 support would be nice too, but for entirely different
reasons - apparently there are some people in the world who need character
sets outside ascii7. Who knew?]
> Do you think you win something by preferring say RADB over
> LEVEL3 over SAVVIS over ARIN over RIPE over...? You have no real idea
> where your customer's are keeping their records, or their customers,
> etc. 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?
Yes, this is a bit of a mess alright.
> 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. Why bother filtering at all
Data with "source: RIPE" is quite good from this point of view, as the
mnt-lower: and mnt-routes: fields are delegated by the RIR function in
RIPE. There's no doubt that you can get all sorts of crap from non-RIR
> I think if it was as simple as seeing a list of your routes (or
> customers in your as-set, etc) and having a checkbox to delete old data,
> people would be more reasonable about maintaining it. RPSL is scary and
> confusing to a lot of people (and it should probably be scary to
> everyone at any rate :P), there is no reason it needs to be like this.
RPSL is scary both from an end-user and a developer point of view. From
the developer point of view, if the requirement to support AS path regular
expressions were removed, that would remove lots of scary code from
irrtoolset. The grammar is also very rich, which is just another word for
From the user point of view, as a means of maintaining full policy routing
configuration information (which seemed to be its original goal), it fails
quite badly: too complicated to be understood easily; to limited to fulfil
Like lots of technologies which didn't take off as intended (x.500,
multicast, etc), it's found a stable niche, although there is no doubt that
its prefix filtering capability is very undervalued.
More information about the NANOG