NWI reviews: NWI-3 - Afrinic IRR Homing
Dear Colleagues This is another 4 year old task about 'encouraging' the transfer of ROUTE(6) objects for Afrinic resources from the RIPE Database to the Afrinic Database.https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005241.html Is this still an ongoing task? Is there anything more that needs to be done from the RIPE region to complete this Task? Or can we consider this task as completed now? My feeling is that it was superceeded by 'NWI-5 Out of region ROUTE(6) / AUT-NUM objects', which is marked as 'Finished'https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005245.html As always, your comments are appreciated... cheersdenis co-chair DB-WG
Hi Denis and DB-WG, I very much agree, NWI-5 supersedes NWI-3 and NWI-3 should be considered complete now (in my opinion). - Cynthia On Wed, Sep 30, 2020 at 4:32 PM ripedenis--- via db-wg <db-wg@ripe.net> wrote:
Dear Colleagues
This is another 4 year old task about 'encouraging' the transfer of ROUTE(6) objects for Afrinic resources from the RIPE Database to the Afrinic Database. https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005241.html
Is this still an ongoing task? Is there anything more that needs to be done from the RIPE region to complete this Task? Or can we consider this task as completed now?
My feeling is that it was superceeded by 'NWI-5 Out of region ROUTE(6) / AUT-NUM objects', which is marked as 'Finished' https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005245.html
As always, your comments are appreciated...
cheers denis
co-chair DB-WG
Dear colleagues, 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. Kind regards, Job On Wed, Sep 30, 2020 at 02:32:18PM +0000, ripedenis--- via db-wg wrote:
Dear Colleagues This is another 4 year old task about 'encouraging' the transfer of ROUTE(6) objects for Afrinic resources from the RIPE Database to the Afrinic Database.https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005241.html
Is this still an ongoing task? Is there anything more that needs to be done from the RIPE region to complete this Task? Or can we consider this task as completed now? My feeling is that it was superceeded by 'NWI-5 Out of region ROUTE(6) / AUT-NUM objects', which is marked as 'Finished'https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005245.html
As always, your comments are appreciated... cheersdenis co-chair DB-WG
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? 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 idea here is to create a process which will, over time, eliminate fossils. Nick
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
Job Snijders wrote on 30/09/2020 21:38:
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.
you're probably right here.
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.
Where's the documentation from an SDO which says that RPKI should invalidate a RIPE IRRDB entry? DB-WG is not an SDO :-)
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'.
There needs to be more than this. If there's a material change in an address allocation in another registry, then this may invalidate the basis for the route(6): entry in the ripe irrdb. We should probably have a think about what sort of actions could invalidate the routing situation, e.g. - deletions - transfers, whole or partial - new creations This doesn't need to be an immediate hard delete process. Something like the ripe-731 process would work well, but possibly with an option to allow people to halt the deletion either temporarily or permanently, or to refer it for manual review?
I personally believe RIPE-731 is sufficient of a cleanup process to eventually eliminate all problematic fossils... but it is a multi-year process.
It won't eliminate everything - there will be irrdb fossils until the heat death of the universe. But the fossil elimination process can be sped up by having more inputs into it. NIck
Hi, On 30/09/2020 23:07, Job Snijders via db-wg wrote:
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.
Yes. but slightly different topic: if an inetnum from AfriNIC gets reclaimed by AfriNIC (with consent of the holder, not that it matters), can the route object from RIPE-NONAUTH get deleted? assuming maintainer access is lost - person left company, for years no RIPE DB activity..... In fact: I (upstream) asked NCC to delete, and got a "no". (understandable) In the meantime the inetnum got deleted in AfriNIC. Should I try again? For the possible benefit of one single prefix getting out of IRRs and not getting added into lots of filters all over the world? real case: 196.10.147.0/24 http://irrexplorer.nlnog.net/search/196.10.147.0/24 I feel without some help RIPE-NONAUTH will not drain enough. Frank Habicht Tanzania PS: sorry for thread hijacking feel free to change subject:
Frank Habicht via db-wg wrote on 30/09/2020 22:15:
Yes.
but slightly different topic: if an inetnum from AfriNIC gets reclaimed by AfriNIC (with consent of the holder, not that it matters), can the route object from RIPE-NONAUTH get deleted? assuming maintainer access is lost - person left company, for years no RIPE DB activity..... In fact: I (upstream) asked NCC to delete, and got a "no". (understandable)
this is completely on-topic. If a routing object is invalidated by a second / third party action, then it has no reason to continue to exist in the ripe irrdb. Nick
participants (5)
-
Cynthia Revström -
Frank Habicht -
Job Snijders -
Nick Hilliard -
ripedenis＠yahoo.co.uk