[db-wg] source: field for non RIPE address space

On Fri, Nov 14, 2014 at 11:06:59AM -1000, Kaveh Ranjbar wrote:
> On 14 Nov 2014, at 10:26, Nigel Titley <nigel at titley.com> wrote:
> >> I'm sorry, I don't understand what you mean with less "secure" routing
> >> table in this context. Can you elaborate? Or maybe give an
> >> (hypothetical) example?
> >> 
> > I'm not sure but this sounds like Kaveh thinks that ISPs perform
> > negative filtering whereas, at least in my experience they perform
> > positive filtering, which will be made *more* secure.
> 
> To my understanding, these are the three scenarios where most
> operators make their routing decision:
> 
> 1- Route is seen and is in the IRR: Provider accepts it.
> 
> 2- Route is seen but differs from IRR: Except if the received route is
> a subset of IRR object, it is rejected.
> 
> 3- Route is seen and is absent in IRR: Provider rejects if the route
> is coming from a downstream provider, accepts it otherwise.
> 
> So, if we change the RIPE Database default behaviour to return
> "%ERROR:101: no entries found” when they run their trustworthy
> scripts, they will get less route objects, which will in practice
> downgrade some of the cases which would have caught by strategy (2)
> and rejected to the category (3) and accepted. This is where if we
> only make this change on the server side, we have made the system less
> useful.

Yes, the purpose of this proposal is that with "-s RIPE" added to
queries, _less_ route objects are returned, as foreign objects are
excluded.

Autopilot scripts most likely will not query with "-s RIPE", I don't
worry about those, for autopilot networks the behaviour of the database
will not change.

People that explicitly seek certain sources of information (like some
IXP operators for their route servers) will benefit from the change.

Looking at tooling: bgpq3's default behaviour will not change.

> As I have written to routing-wg, I just wanted to point out that these
> kinds of changes should accompany provider behaviour and toolset
> changes as well.  Without them, they will have no effect, if not
> negative. If we have the commitment in the operator space and toolset
> provider space, this can be a very positive change towards better data
> quality.

Can RIPE NCC provide more information on how many route objects have
been created that do not belong to RIPE NCC administrated space or ERX
space?

I did find ~ 12.000, but that was only because of that specific
"mnt-by:" attribute. If people remove that attribute, as an external
observer I cannot find the foreign route objects easily.

Kind regards,

Job