Follow up to previous post regarding SAAVIS

Thu Aug 13 11:09:10 UTC 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
> then?

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 
irrdbs, though.

> 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 
complicated.

 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 
its objective.

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.

Nick