[ARIN-consult] Consultation Now Open on the Future of ARIN’s IRR

[Job Snijders]

Dear John,

On Mon, Mar 01, 2021 at 05:43:36PM +0000, John Curran wrote:
> That’s certainly one approach - taking that which is known invalid and
> removing it, and continuing that process until there is a small amount
> of relevant data left.  
> 
> There is also the approach of focusing on what is relevant and
> operational today and working to migrate those entries elsewhere. 
> 
> It is not inevitable that one approach must be done before the other,
> but rather the priority should depend to a great extent on how much is
> known relevant, known invalid, and those ratios to the entire corpus. 

Right, I would caution against 'running all these mechanisms in
parallel'. I recommend to start with RPKI RIPE-731 mechanism as that is
the most obvious (and modest sized) 'invalid' pruning mechanism. Then
based on the RPKI pruning experience, deploy the other pruning
mechanisms.

Trying one method before trying all methods has as advantage that ARIN
learns about how to inform stakeholders, what questions come back,
how/where to provide documentation, how to 'notify' -> 'wait' ->
'delete' and roll back when needed, etc. The suggestion to break it up
into discrete steps really is to pave the way to make the subsequent
pruning operations (in parallel) more efficient.
 
Pruning method #1: RPKI based

    The hope is that as more and more INR holders create RPKI ROAs, less and
    less data exists in ARIN-NONAUTH, as more and more gets removed
    (following the RIPE-731 process).

    If the RIPE-731 process is applied today, it would prune ~ 2,000
    objects, but with each and every community outreach campaign (under
    any Trust Anchor) to get RPKI ROAs created, chances are a few more
    objects in ARIN-NONAUTH become invalid and can be automatically
    deleted.

Pruning method #2: 'not seen in BGP MRT routeviews data in X years'

    An argument can be made that any IRR object referencing IP address
    destinations (as route/route6 object), which have never or X number
    of years not been observed in the BGP DFZ / routeviews, they were
    created in error and should be deleted.

    I didn't calculate how many objects would be effected by this
    method.

Pruning method #3: 'an exact matching copy exists in another IRRdb'

    An argument can be made that if a functionally equivalent copy
    exists in another IRR database, the copy in ARIN-NONAUTH does not
    need to exist.

    Any objects that has an equivalent exact matching object in another
    IRRdb (exact matching primary keys, I don't care about
    remarks/descr) can be deleted.

Pruning method #4: '.....????'

I'm happy to participate in meetings where we come up with more
'pruning' mechanisms to reduce the size of ARIN-NONAUTH.

> > That is not what is being suggested. Waiting a full year still is an
> > incredibly aggressive timeline which to me doesn't seem warranted.
> > 
> > I would appreciate if ARIN takes their feet off the gaspedal on this
> > project. ARIN would do well to perform an 'impact analysis' and share
> > their conclusions with the community before proceeding. Use Routeviews,
> > use IRR data from other registries, intersect those with each other...
> > this is the same work I've been doing.
> 
> An excellent suggestion - well worth considering, particularly given
> the relatively modest amount on ARIN-NONAUTH entries germane to the
> DFZ. 

Doing this type of legwork 'this is what we took as inputs, our
cross-referencing procedures were like so and so, and this therefor we
think we can safely delete all objects matching XYZ in ARIN-NONAUTH'
will go a long way to demonstrate to the community a deep understanding
on how to responsibily prune IRR data at scale.

Since method #1 is applied in RIPE-NONAUTH already today (with success),
I imagine that ARIN can quite easily get to that level as well. From
there ARIN could be first to explore method #2 and method #3, which in
turn might inspire the RIPE community to also apply those pruning
mechanisms to RIPE-NONAUTH.

Kind regards,

Job