--- Begin Message ---
Hi Daniel and others
Just for the record I have followed all previous discussions on this issue over
many years within the RIPE community. There have been many (opposing) views
expressed. I don't recall any consensus within the RIPE community to expel all,
or even just Afrinic, (foreign) ROUTE objects from the RIPE Database. If I did
miss that, maybe someone can point me to the message on this or the ROUTING WG
mailing lists where that consensus was drawn.
Does Afrinic have a mandate, with a clear consensus, from the Afrinic community
for the migration of all Afrinic ROUTE objects from the RIPE Database to the
Afrinic Database? Has either community agreed anything on the (re)creation of
Afrinic ROUTE objects in the RIPE Database?
I have no personal interest in this either way. I just want to be clear what
the current position is so we can move forward.
cheersdenisco-chair DB-WG
From: Daniel Shaw via db-wg <db-wg@ripe.net>
To: Database WG <db-wg@ripe.net>
Sent: Tuesday, 18 July 2017, 16:39
Subject: Re: [db-wg] out of region routing in the RIPE Database
On 18/07/2017, 15:26, Nick Hilliard via db-wg typed:
>
>
> There are two main ways to fix this problem:
>
> 1. change all non-RIPE address space to have a different source: tag
>
> 2. remove all non-RIPE address space completely
>
> There is some previous discussion about this issue on db-wg, and IIRC,
> the WG suggestion was to go for option #2.
>
> On that basis, again IIRC, there was a suggestion to handle this in a
> phased way, starting off with the lowest hanging fruit first. As
> Afrinic objects formed the largest share of all out-of-region objects in
> the ripedb, they were targeted first.
Hello WG,
That matches my recollection too.
And so I'll re-iterate that, as previously mentioned on this list, this neatly
matches up with some parallel goals within AFRINIC. Which is that regardless,
we see an advantage in having our membership manage their IRR along with RDNS
and RPKI and other registry interactions in one place under one authentication.
Simpler. And we also see an advantage in general growth in usage of the AFRINIC
IRR by our membership, as it's a service we already provide and will maintain
and scale as needed in any case.
And so, we do already provide tooling to our membership to assist them moving
objects into the AFRINIC DB easily. We do liaise with upstream operators of our
members when they have in the past implied a requirement for RIPE DB IRR
objects. And our hostmasters also do run bootcamp tutorials at nog and other
events to encourage migration of objects.
In summary there is ongoing work that matches with migrating non-RIPE, AFRINIC
route(6) objects underway. I will add that this is a long and slow process
however. The work is done as convenient. And for now, only applies where both
the IPv{4,6} an AS resources are within the AFRINIC region.
The movement is slow. But in the direction of moving AFRINIC resources away
from RIPE DB.
Regards,
Daniel
--- End Message ---
