Hi, Gert Doering asked: [...]
I'm sure I'm overlooking something, which would explain why it is the way it is...?
As far as I know current behaviour is the implementation of the RFC 2725 (Routing Policy System Security). According to it the order of checking the authorisation is as follows: exact match route less specific route exact match inetnum less specific inetnum In Winfried's case it fails on the exact match route and doesn't continue further. I am not sure why the checks are like this, may only note that the spec was developed ~8 years ago and reflects last century view on the routing system. And Wilfried Woeber commented:
While I do not at all object to revisit this problem (may I suggest to take it through Routing and/or Address-Policy firts?) my _feeling_ is that we won't see a much better machinery by bending the DB code left and right, but rather by trying to make progress in developing and properly deploying (some sort of) Routing Layer Security?
Some of the prerequisites are already being developed.
There was a second SIDR BOF at the IETF 65. One of the concepts that was presented there was a so-called ROA (Route Origination Authorisation ?) - a digitally signed data structure that allows an address space holder to authorise one or more ASes to originate [part of] the space. (Provided that the holdership of the address space can be validated through the certification chain up to an RIR or the IANA). This ROA is very much the same as the collection of the route objects with different origin AS'es for the same prefix, being only authorised by the maintainer of the address space. Regards, Andrei Robachevsky RIPE NCC