Dear RIPE DB WG,
E. Afrinic IRR homing project update (Piotr Strzyżewski) [~10 min]
Glad to see this is on the agenda. Myself and AFRINIC are eager to see this move forward. As far as I recall, the problem statement was roughly agreed on and we all (RIPE DB WG and AFRINIC) feel that ultimately having AFRINIC resources in the AFRINIC IRR is more manageable for all the members in both regions as well as both sets of RIR staff. Please correct me if I am wrong. I believe it’s also clear to everyone that when one or the other of the prefix or ASN is in a different region to the other, resolving where the ROUTE(6) object should live and how authorisation is done between two RIRs is complex and needs some further discussion. I believe it’s states as out of scope of NWI 3 anyway. This should not preclude or block the homing of the majority of ROUTE(6) objects currently in RIPE DB related to AFRINIC resources, where both the prefix and ASN are AFRINIC assigned or allocated. From the AFRINIC organisation point of view, at this stage there is no consideration to change route(6) objects in terms of aggregation or de-aggregation. Nor would we want to see any objects deleted from the RIPE DB that are not already duplicated in the AFRINIC IRR first. A goal here is to serve our members by having their valid route(6) objects managed from the same interfaces and tool as their actual resources, their sub-allocation, their reverse DNS delegations, RPKI ROAs, and so on. And under the same authorisation. As such, AFRINIC does already actively encourage members to migrate their route objects across. We even have some tooling and running code to assist members to do so. But uptake is slow. I believe due to primarily two factors: - General inertia: “If it’s working now, why change anything”. - Upstream carriers that still require RIPE DB IRR objects from downstream operators in the AFRINIC region. I believe (hope) that these two factors are where the RIPE NCC and the RIPE DB community can assist. Of course at the same time the message from AFRINIC *is* one of equal desire to have the objects more and support for the DB WG’s desire to not have out of region objects. No one wants this to be seen as the RIPE DB dictating the way forward, but a certain degree of firmness from both ends would, I believe, help as an incentive to the resource holders to take action for themselves. And AFRINIC is then ready to assist them in creating/copying the objects. To summarise: This is mostly to re-iterate that finding a way to complete this work is understood to be mutually beneficial to both RIPE and AFRINIC communities, membership and organisations in the long run. Without a doubt there will be some challenges with the technicalities of certain sub-groups of objects that are out of date or not perfectly duplicated, but we understand this is unavoidable and are ready to put in the effort to deal with them as the data are looked at more closely. I have a high level of confidence that these will not form the majority of objects to move anyway. Best regards, Daniel