[db-wg] Route objects for space administered by other RIRs
- Previous message (by thread): [db-wg] Route objects for space administered by other RIRs
- Next message (by thread): [db-wg] Agenda RIPE82 - Database Working Group
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Edward Shryane
eshryane at ripe.net
Thu May 13 11:10:09 CEST 2021
Hi Ronald, > On 12 May 2021, at 21:59, Ronald F. Guilmette via db-wg <db-wg at ripe.net> wrote: > > ... > I'd like to ask a more general question anyway, which is just this: > When the authority for some IP number resource is transferred from, > say, RIPE, to some other RIR, is there any good reason why any > associated route objects should not likewise travel to the new RIR > along with the IP block allocation itself? During an inter-RIR transfer in the RIPE region, any associated routes are updated according to the user's wishes, in coordination with the RIPE NCC, to minimise any potential for disrupting networks. > And if there is no such > good reason, then could we please have a rule that says that a > transfer of an IP address block out of the RIPE region will be > followed also by a deletion, in short order, from the RIPE data base > of any directly relevant route object(s)? > Deleting the route objects are done manually, we are investigating how to automate this (or at least email reminders so they are not left behind). In April I found 2 routes in the RIPE database with an out-of-region prefix, and 33 routes in the RIPE-NONAUTH database with an in-region prefix. These were left over from Inter-RIR transfers since 2018. I notified the maintainers and moved the routes to the correct database. > More broadly, it is parhaps a result of my overly-fastidious nature, > but I personally would be in favor of simply deleting all of the > remaining RIPE-NONAUTH route objects from the RIPE data base. The NONAUTH routes date back to the time when the RIPE database served as a global IRR, and at the time it was decided to move them to a separate database rather than delete them altogether and risk disruption for users that depend on them. There is some more detail in the impact analysis for the original change: https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation <https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation> And extensive discussion in the DB-WG archives from 2017 - 2018: https://www.ripe.net/ripe/mail/archives/db-wg/ <https://www.ripe.net/ripe/mail/archives/db-wg/> > ... > It seems that we are now in the era of RPKI and that everyone is being > generally encouraged to take routing security rather more seriously > these days, which is a profoundly Good Thing. Yet it appears that > when it comes to these RIPE-NONAUTH route records, RIPE is still, in > effect catering not just to the last generation of route registration > protocols, but also and even to the generation before that. At what > point in time does will all of this stuff be seen to be what it is, > i.e. antiquated and counterproductive? > The intent of the 2018-06 policy proposal (now RIPE-731) was to clean up route(6) objects in RIPE-NONAUTH where they conflict with an RPKI ROA: https://www.ripe.net/participate/policies/proposals/2018-06 <https://www.ripe.net/participate/policies/proposals/2018-06> Regards Ed Shryane RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/db-wg/attachments/20210513/93f5cf41/attachment.html>
- Previous message (by thread): [db-wg] Route objects for space administered by other RIRs
- Next message (by thread): [db-wg] Agenda RIPE82 - Database Working Group
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]