[db-wg] NWI reviews: NWI-3 - Afrinic IRR Homing

Dear Nick,

On Wed, Sep 30, 2020 at 09:15:11PM +0100, Nick Hilliard wrote:
> Job Snijders via db-wg wrote on 30/09/2020 21:07:
> > I agree. The combination of NWI-5 and RIPE-731 obsoleted NWI-3.
> > 
> > There is nothing left for RIPE to further improve here.  RIPE-NONAUTH is
> > slowly and steadily decreasing in size. AFRINIC resource holders have
> > all the tools available to publish their routing intentions in either
> > the AFRINIC IRR or under the AFRINIC RPKI TAL.
> > 
> > NWI-3 can be closed.
> 
> do we want to change the scope of the NWI?

A change of scope probably warrants a new NWI, as NWI-3 was (at the
time, in that context) specificly targetted to help mop up after the
transfer of inetnum/inetnum6s when AFRINIC was instantiated. 

> E.g. if there is a route(6): object in Afrinic which conflicts with an
> existing entry in the ripedb, should the RIPE version be deleted?
> Could this also apply to APNIC objects?
> 
> If the network block is split into multiple blocks by the allocating
> RIR, should the route(6): object be deleted?  What if it's deallocated
> or transferred to a new party.

The thinking in developing RIPE-731 was that RPKI information supersedes
IRR information as following: RPKI information (when applying the RFC
6811 procedure with EBGP 'invalid == reject' import policies) result in
a state of the network where what conflicting RIPE-NONAUTH route/route6
objects document would be rejected because of RPKI ROV. As such
automated deletion of the objects is warranted. In this regard RPKI data
exists on a different (higher?) 'plane' than the data in the unvalidated
IRR 'plane'. Building city upon city so to speak.

The same cannot trivially be said for IRR objects superseding other IRR
objects, I've never seen documentation from standards bodies describes
how one IRR route object could warrant the removal of an IRR object in
another IRR database under different administration.

Of course, in practise such removals happens from time to time as
operators send complaints to IRR database operators 'look, in the
authoritative APNIC database we documented XYZ, the objects in
NTTCOM/RADB/RIPE-NONAUTH are not what we want'. All such instances
require manual research, as there are also plenty of examples where a
supernet is registered in IRR database X, suballocations/subassignments
happen and those are documented in database IRR Y. Also in practise the
recommendation towards the complaint issuer would be to ask them to
create RPKI ROAs as that provides unambigious verifiable attestation on
what the routing intentions are.

Given that RIPE-731 came to be through a run of the PDP process and not
as a NWI, I suspect that further enhancements to the RIPE-NONAUTH
cleanup algorithm should be handled through a similar process.

> The idea here is to create a process which will, over time, eliminate
> fossils.

I personally believe RIPE-731 is sufficient of a cleanup process to
eventually eliminate all problematic fossils... but it is a multi-year
process.

Kind regards,

Job