On Thu, May 26, 2016 at 02:57:25PM +0200, Job Snijders wrote:

On Wed, May 25, 2016 at 04:44:03PM +0200, Gert Doering wrote:

...

On Wed, May 25, 2016 at 03:11:38PM +0200, Job Snijders wrote:

...

NWI-3 - Afrinic IRR Homing -------- [..] 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.

Support, as written.

I too agree with it.

+1 Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl

João Damas wrote:

support for both the positive (should appear in the Afrinic IRR) and the negative (not in the RIPE DB) statements in that text

me too. Nick

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

On Wed, Jul 27, 2016 at 07:32:48PM +0000, ripedenis@yahoo.co.uk wrote:

Hi Tim Can we have some up to date numbers on how many (if any):

<snip - leaving that for NCC/NIC staff>

Assuming any exist:

-How do you propose to handle any objects that have a version in both databases that are different?

Can't they just co-exist? And whoever can meet the authorisation requirements can delete either one of them. I think this is a question for AfriNIC to consider, not for the RIPE NCC staff.

-What do you propose to do with set objects that reference any of these objects?

What type of set objects are you specifically referring too? Generally operators use set expanders that span multiple databases. Speaking for myself in any of the networks I operate I don't see an issue whether the route objects are in RIPE or in AfriNIC's IRR. Just make sure your data source mirrors AfriNIC.

-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?

Can't those references remain? References don't need to terminate in the same database. Kind regards, Job

Hi (yet again) denis, WG,

...

...

Assuming any exist:

...

-How do you propose to handle any objects that have a version in both databases that are different?

Can't they just co-exist? And whoever can meet the authorisation requirements can delete either one of them.

Phase 4 in Tim's proposal is to delete these objects from the RIPE Database. I can see the benefit of deleting them as we don't want different or diverging data in these databases. But then you need to know which version is the most accurate to copy into Afrinic's database.

Based on my understanding of Tim’s proposed phases, this is exactly why we’ve separated out phase 4 (eventual deletion) from phase 3 (copying/migrating). So in theory, by the time deletion happens, the sorting out part has already been done. I know that doesn’t really answer the “how do you know which is which” part, but the deletion would have a dependency on getting that answer. Somehow. - Daniel

On 28 Jul 2016, at 04:19, Randy Bush <randy@psg.com> wrote:

...

...

-How do you propose to handle any objects that have a version in both databases that are different?

I think this is a question for AfriNIC to consider, not for the RIPE NCC staff.

you dump crap on them and tell them to clean it up. nice.

I can see how it can look that way, but that was not our intent. In short our intent was to 1) not risk interrupting routing, 2) give the real resource holder the ability to clean up (i.e. in the Afrinic IRR). 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. We believe that it's best that in these cases objects *are* copied over to the Afrinic IRR in phase 3 - so that the actual resource holders can choose to keep, or force delete these objects as needed. The simplest way to do this is by copying all objects. I can see possible smarter scenarios where duplicates are excluded on import, or where Afrinic resource holders can somehow mark their resources as already migrated. But to echo Job, I think this is for Afrinic and their community to consider. Tim

randy

Hi Denis, WG,

On 29 Jul 2016, at 03:28, denis <ripedenis@yahoo.co.uk> wrote:

Hi Tim

On 28/07/2016 11:35, Tim Bruijnzeels wrote:

...

...

On 28 Jul 2016, at 04:19, Randy Bush <randy@psg.com> wrote:

...

...

-How do you propose to handle any objects that have a version in both databases that are different?

I think this is a question for AfriNIC to consider, not for the RIPE NCC staff.

you dump crap on them and tell them to clean it up. nice.

I can see how it can look that way, but that was not our intent. In short our intent was to 1) not risk interrupting routing, 2) give the real resource holder the ability to clean up (i.e. in the Afrinic IRR).

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?

We believe that it's

...

best that in these cases objects *are* copied over to the Afrinic IRR in phase 3 - so that the actual resource holders can choose to keep, or force delete these objects as needed.

The simplest way to do this is by copying all objects. I can see possible smarter scenarios where duplicates are excluded on import, or where Afrinic resource holders can somehow mark their resources as already migrated. But to echo Job, I think this is for Afrinic and their community to consider.

This simple copy process does not work if there are duplicates with different content. If Afrinic are the ones who will decide on how to handle duplicates then they need to have considered this and come to a decision on how to handle them before the start of Phase 3 of your plan. Up until that point it is still possible a duplicate ROUTE(6) object in the RIPE Database could be modified to have different content to the one in AfriNIC Database.

I agree this needs to be resolved before this phase is started but I also believe it's not my place to suggest exactly how this should work. As I said "..I think this is for Afrinic and their community to consider". If you have specific suggestions I think you are free to voice them.

btw although you did not specify it I assume when Phase 3 is implemented you will also add a business rule to the RIPE Database to prevent any of the Afrinic ROUTE(6) objects from being modified in the RIPE Database.

correct, also the time to phase 4 was intended to be very short - we just want to be sure that remaining objects (for whatever definition in phase 3) are copied to the Afrinic IRR, before they are deleted in the RIPE Database 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. Cheers Tim

cheers denis

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

On 04 Aug 2016, at 23:21, Daniel Shaw <daniel@afrinic.net> wrote:

...

On 29 Jul 2016, at 5:28 AM, denis <ripedenis@yahoo.co.uk> wrote:

...

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’.

Well we can, and I believe likely will do just that. I am not making a commitment on behalf of my organisation here, but it makes sense to us too to get as many resource holders as possible to ‘do it themselves’. And I don’t see any reason why AFRINIC would not.

When the AFRINIC IRR was initially launched, we already did do some of that. But not enough resources holders saw enough of a motivation to make the effort. Hopefully this initiative will also help to motivate some number more. But it’s never going to be all.

I believe that what is needed here most of all is a clear message from both communities that it is desirable to have the ROUTE(6) objects for AFRINIC space in the AFRINIC IRR where the registered resource holders can properly authorise objects. In the meantime we can indeed give AFRINIC holders access to object through the maintainer reset process, but since the holders are not an integral part of the RIPE Database this process is both cumbersome and more error prone than we like - which is exactly why we are discussing this effort in the first place. I expect that it will actually be much easier for AFRINIC holders to see object for their space migrated into the AFRINIC IRR, so that they can use existing authorisations they have there to update (or delete/replace) these objects as needed. Tim

- Daniel

...

When the AFRINIC IRR was initially launched, we already did do some of that. But not enough resources holders saw enough of a motivation to make the effort. Hopefully this initiative will also help to motivate some number more. But it’s never going to be all.

In my opinion the route-objects should've been moved back in the day during the AfriTrans project when all the inet{,6}num's were moved by the RIRs. But alas, that didnt happen so now we need to deal with it.

I don't think it is wise to leave it up to thousands of resource holders to perform actions, maybe some of them don't even realise their objects are in the RIPE DB instead of AfriNIC.

I don't consider "let the resource holders do it" a viable solution to address the problem statement.

in the ripe address space, a lot of resource holders have not aggregated route: objects, though we have asked many times. the ncc should aggregate them. "let the resource holders do it" is clearly not a viable solution. the IRR is a service run FOR the resource holders, not AT the resource holders. randy

...

in the ripe address space, a lot of resource holders have not aggregated route: objects, though we have asked many times. the ncc should aggregate them.

Please don't. The IRR route objects are interpreted by some as a statement of what networks are announced.

i agree. my point was that the rir community serves the operators, not vice versa. we do not have the prerogative of forcing the african ops to do as we wish. otoh, we can make it as easy as possible to do the sensible (from our perspective) thing. randy

Asking either the NCC and/or the resource holders to clean up ancient objects one time isn't a problem imho.

asking the resource holders is perfectly reasonable and is what we have been doing for many things for many years. deleting others' objects because they are african and we think they are not obeying our orders is an entirely different matter. randy

Hi again,

On 27 Jul 2016, at 11:32 PM, ripedenis@yahoo.co.uk wrote:

Assuming any exist: -How do you propose to handle any objects that have a version in both databases that are different?

I also don’t have a definitive answer to this. Yet. But I will say that my assumption would be that likely very few exist, if any. If there are any, likely it’s a small enough number that they can be handled on a case by case basis. True, I don’t have the data which proves this either way, but I don’t believe it’s a show stopper, even at worst. That being said, certainly something to gather data on and plan for: So thank you for bringing up the possibility. Regards, Daniel