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