Hi Tim Can we have some up to date numbers on how many (if any): -ROUTE(6) objects in the RIPE Database this affects -unique Afrinic ASNs copied in the RIPE Database that are referenced in these ROUTE(6) objects to be transferred -of these unique ASNs, that are referenced by other ROUTE(6) objects not in this set of ROUTE(6) objects to be transferred-of these ROUTE(6) and ASN objects, that have a version in both the RIPE and AFRINIC Databases-set objects that reference any of these ROUTE(6) or ASN objects-other ASN objects in the RIPE Database, not in the set of ASN copies to be transferred/deleted, that reference any of these unique ASNs or the ROUTE(6) objects to be transferred Assuming any exist: -How do you propose to handle any objects that have a version in both databases that are different?-What do you propose to do with set objects that reference any of these objects?-How do you propose to handle any routing policy statements in other ASN objects that refer to any objects from this set of affected ROUTE(6) or ASN objects? cheersdenis From: Tim Bruijnzeels <tim@ripe.net> To: Database WG <db-wg@ripe.net> Sent: Wednesday, 27 July 2016, 15:44 Subject: Re: [db-wg] NWI-3 - AFRINIC IRR Homing Dear working group, We propose the following phased implementation outline. This is very similar to proposals presented at RIPE 71 and 72, except that we are differentiating between the import done for remaining unmigrated route(6) objects by Afrinic and the clean up in the RIPE Database more explicitly. Phase 1: Communicate (3 months) In this phase there are no actual changes done in the RIPE Database. But operators are encouraged to add the Afrinic IRR to their tool chains. Afrinic continues aiding migration of objects into the Afrinic IRR. Details of a communication plan need to be worked out, but should be a joint effort of RIPE NCC, Afrinic and community members. For example RIPE NCC can do outreach through their announcement channels and meetings where we are present, but it would be good if operators also took an active role in communicating about this project once the plan is final - e.g. at *NOG meetings. Phase 2: Freeze in RIPE IRR We propose that this phase starts 3 months after step 1 The RIPE Database will get a new business rule that prevents the creation of new route(6) objects with both an Afrinic ASN and an Afrinic prefix. The error message will instruct users to create these objects in the Afrinic IRR instead. Modifying or deleting existing route(6) objects for Afrinic ASN & prefixes can still be done by their maintainers. Phase 3: Afrinic imports remaining object We propose that this phase starts 3 months after step 2 Afrinic will import route(6) objects for Afrinic ASN & prefixes that are not considered migrated yet, and provide a way for Afrinic resource holders to manage these objects later. The exact details of how this should work should be discussed with Afrinic and the Afrinic community. Phase 4: Delete remaining objects in RIPE Database We propose that this final phase is done 2 weeks after step 3. RIPE NCC will delete all remaining route(6) objects for Afrinic ASN & prefixes in the RIPE Database. We propose this outline as a starting point for discusion, and welcome any feedback from the community. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group
On 25 Jul 2016, at 22:15, Job Snijders <job@ntt.net> wrote:
Hi all,
There is enough support for the problem statement as written below, no objections were raised. As chair i'm declaring consensus on this problem statement.
This means that the work item can proceed to phase 2, for your convenience I've copy+pasted it here:
""" phase 2: solution definition solution finding: people can propose solutions to a work item's problem statement. Solutions can come from RIPE NCC staff, or any working group member. RIPE NCC may offer an implementation analysis on proposed solutions or aspects of solutions.
For the NWI to move to phase 3, RIPE NCC has to provide the group with a summary of their understanding of the solution, and the chairs declare consensus on the group's acceptance of this summary. """
As presented at past RIPE meetings, RIPE & AfriNIC already spend some cycles defining possible ways to address this problem statement, I suggest we recycle that work.
Kind regards,
Job
On Wed, May 25, 2016 at 03:11:38PM +0200, Job Snijders wrote:
Dear Working Group,
(You can review https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005190.html to ensure you have an overview of the next steps.)
NWI-3 - Afrinic IRR Homing --------
In recent years Afrinic set up an IRR instance that enforces authorisation for ROUTE(6) objects at rr.afrinic.net
And while the general problem of out-of-region ROUTE(6) and AUT-NUM objects in the RIPE Database IRR, and the problem where the prefix and the ASN belong to different regions is not trivial to resolve, there seems to be a general consensus that simple cases where ROUTE(6) objects have both an ASN and prefix in Afrinic (~34k objects), should appear in the Afrinic IRR where authorisation can be done and not in the RIPE DB.
Complicated cases where the prefix is in Afrinic, but the ASN is another region -or- where the ASN in Afrinic, but the prefix is out of region are out of scope for this NWI. --------
Some of you might wonder why this topic is back on the table. The chairs felt that it would be most appropiate to follow our new NWI formal process to help progress this work.
Working group participants, if you agree/disagree with the above problem statement please voice your opinion. If you have suggestions to refine the text that is welcome too.
Kind regards,
Job