Dear working groups,
At RIPE 70 the RIPE Database Working group asked the RIPE NCC to work together
with Afrinic on an implementation proposal to migrate Afrinic route(6) objects
to the new Afrinic IRR as part of the IRR Homing project. We are planning to
present a proposal at the Database Working Group session at RIPE 71.
Initially we will focus on the clear cases where Afrinic is the RIR for both
the inet(6)num and aut-num (roughly 34k object). In the meantime we are also
seeking technical alignment with Afrinic and the other RIRs on how cross-RIR
authorisation for route(6) objects can be improved, so that we can also put
forward an implementation plan for the remaining objects (e.g. roughly 6k
objects with an Afrinic inetnum and RIPE aut-num).
Experience with the migration of Afrinic route objects can serve as a basis to
similar migrations in the future. And while the RIPE NCC and RIPE working
groups cannot set the priorities for other RIRs, they are following these
developments with interest.
All that said it is clear that the current situation is problematic and an
intermediate solution may be desired. In general the RIPE NCC also likes the
proposal for this put forward by Denis. But we have some comments, much in line
with comments made by Job. We would propose the following:
> STEP 1: reject creation of route-objects if they cover foreign non-allocated
> / non-assigned space
This should be doable. The past few years the RIRs have been working hard on
cleaning up overlaps, and therefore we can now be certain which RIR is
authoritative for which resources and check this programatically.
> STEP 2: email confirmation link to admin-c/tech-c equivalent as listed in the
> foreign RIR database to confirm creation of the route-object in RIPE's IRR
> database.
Indeed as Job pointed out we may have to make a special arrangement with other
RIRs, but we are confident that we can work with them on this.
> STEP 3: continiously check if the block is allocated in the foreign RIR
> database, if no longer, delete the route-object from RIPE's IRR db.
We share concerns raised by Job. We believe this adds a lot of complexity to
the implementation, and introduces an unacceptable risk of deleting the wrong
objects. Furthermore we believe that this step is not necessary if we implement
step 5 (below).
> STEP 4: one-off cleanup: confirm with all out-of-region objects whether the
> object belongs in RIPE IRR db or not, if no confirmation is received: delete
> the object.
We would also echo the concerns raised by Job. And similar concerns with
complexity and risk apply as with step 3. Furthermore we believe that this step
is not necessary if we implement step 5 (below).
> (Possible) STEP 5: confirm with admin-c/tech-c equivalent as listed in the
> foreign database when a 'delete' request is received.
If we implement this, step 3 and 4 are not needed. Rather than trying to
determine automatically if an object is still valid - and risking getting it
wrong, this leaves both the empowerment and responsibility to maintain this
data with the current resource holders.
We would propose that out-of-region resource holders can delete route(6)
objects in the RIPE Database in a two step process:
1) try to delete the object without authorisation
- We can detect that it's an out-of-region object and send a link to the
holder similar to step 2
2) the holder can click the confirmation link
> AUT-NUM copies: delete foreign autnum copies
From our perspective we agree that we do not technically need foreign aut-num
objects if we have a different authorisation model, and it would be better if
such duplicates did not exist.
As for the clean-up we could:
= disallow new out-of-region aut-num objects
= warn (email) respective holders in the authoritative database
= and delete them as a later step
So, with the caveat about automated deletion of objects that we do have
concerns with, we think we could implement the above as an intermediate
solution. We would also like to point out that we can build on this step by
step. E.g. we can start disallowing route objects for Afrinic resources and
direct people to the Afrinic IRR, while still applying the above strategy for
resources from other regions.
It will obviously require work. Very rough initial estimates indicate it can
take up to a few months. We can refine these estimates if and when we have a
clear consensus on a go-ahead.
Kind regards,
Tim Bruijnzeels
Assistant Manager Software Engineering
RIPE NCC Database Group
