On Fri, Jul 29, 2016 at 12:42:36PM +0200, denis wrote:
On 29/07/2016 11:34, Tim Bruijnzeels wrote:
On 29 Jul 2016, at 03:28, denis <ripedenis@yahoo.co.uk> wrote: On 28/07/2016 11:35, Tim Bruijnzeels wrote:
If the Afrinic resource holder does have access to their object in the RIPE DB today, then they can delete the object before this migration. But, unfortunately, in case they don't we (RIPE NCC) do not have a reliable way to determine claims.
Yes you do. ROUTE(6) objects are the responsibility of the address space resource holder. This is irrespective of which RIR region they are in. Working 'with' AfriNIC it is quite easy to identify who has claim over these objects in the RIPE Database.
As you know we don't have these resource holders in the RIPE NCC registry, and the maintainers were set up with the RPSL password. That's why we have this NWI and NWI-5 (Out of region ROUTE(6) / AUT-NUM objects) in the first place.
Could you elaborate on how this is supposed to work exactly?
You are talking about a situation where an AfriNIC resource holder wants to delete a ROUTE(6) object in the RIPE Database but no longer has the (password) authority to do so. If it was a RIPE resource holder they could use the reclaim functionality and just delete it. For this special case situation if the resource holder, who is known to AfriNIC, requests to AfriNIC to delete a ROUTE(6) object then the RIPE NCC can accept the trusted authority from AfriNIC if they ask you to delete it and you just delete it.
Wouldn't it be simpler to do a one-time handover of all route-objects covering afrinic resources to afrinic? Then AfriNIC resources holders don't have to deal with RIPE. Whether there are multiple versions in AfriNICs IRR or not (after the data has been copied over), the existing authorisation methods in AfriNIC will allow deletion of undesirable objects. RIPE NCC and AfriNIC could even agree that if a 'formerly in RIPE DB' object is deleted in the AfriNIC IRR, RIPE mirrors that deletion. (This is assuming there is a period of overlap where data exists in both AfriNIC and RIPE IRR).
As long as these points are addressed, your plan will work. But I still don't see why AfriNIC can't simply put pressure on their resource holders to 'do it themselves'.
They are. But, the reality today is that the Afrinic resource holders are still required by their peers to put ROUTE(6) objects in the RIPE Database IRR. And there is a need for phased migration.
perhaps we should address this 'requirement' which is a RIPE issue.
The two largest IRR aggregators (NTTCOM & RADB) mirror AfriNIC. This means that if you query either of those (bgpq3, irrtoolset and irrpt talk to RADB by default) an operator automatically, today, has access to AfriNIC route-objects. I think this is a non-existing issue. Can someone provide me with HARD data who these 'peers' are that 'require afrinic resource holders to put their data in RIPE IRR'? It would be helpful if company names are provided, I can reach out to them and probably help them set their filtering in a way to respect AfriNIC's IRR authority. Maybe Emile Aben can assist in doing a study about the impact of using the AfriNIC IRR vs the RIPE IRR on reachability. Kind regards, Job