[db-wg] Cleanup of route(6) objects in the RIPE NONAUTH database using unregistered space

Hi Cynthia,

Thanks for your support, my proposal is to automatically delete route(6) objects using de-registered prefixes from the NONAUTH database.

For example, this would apply to the routes using the revoked 196.52.0.0/14 prefix which was discussed in January.

If there is no objection from the DB-WG, I'd like to turn this proposal into a Numbered Work Item.

Regards
Ed Shryane
RIPE NCC 





> On 31 Mar 2021, at 07:36, Cynthia Revström <me at cynthia.re> wrote:
> 
> Hi Ed,
> 
> I am not sure if this was something to discuss or just something you wanted to mention.
> 
> Anyways as I saw this while looking through older emails, this sounds like a good idea to me.
> 
> -Cynthia
> 
> On Thu, Mar 11, 2021, 15:07 Edward Shryane via db-wg <db-wg at ripe.net <mailto:db-wg at ripe.net>> wrote:
> Dear colleagues,
> 
> In response to the recent discussion on "196.52.0.0/14 <http://196.52.0.0/14> revoked, cleanup efforts needed", I'd like to propose a regular automated cleanup of route(6) objects in the RIPE-NONAUTH database using unregistered space.
> 
> Regards
> Ed Shryane
> RIPE NCC
> 
> 
> 
> Problem Definition
> ------------------
> When an RIR deregisters IPv4/IPv6 address space, any route(6) objects in the RIPE-NONAUTH database using that address space are not cleaned up (deleted).
> 
> 
> Solution Definition
> -------------------
> Once a day, compare route(6) IPv4/IPv6 prefixes in the RIPE-NONAUTH database against the combined delegated stats from all RIRs.
> 
> Only route(6) prefixes that are "allocated" or "assigned" in any RIRs delegated stats should remain in the RIPE NONAUTH database. If a prefix is "available" or "reserved" then it is considered to be unregistered, and any associated route(6) objects will be eligible for deletion.
> 
> If a prefix is partially "available" or "reserved" then it is also considered to be unregistered.
> 
> If a prefix is not listed in any RIRs delegated stats, that prefix is skipped.
> 
> The origin AS status is not considered, only the IPv4/IPv6 prefix.
> 
> If a newly unregistered prefix is discovered, first allow a grace period of 1 week. This allows time for mistakes in the delegated stats to be corrected.
> 
> After 1 week, contact the route(6) maintainer(s) to notify them that the route(6) object will be deleted.
> 
> After a further 2 weeks, delete the route(6) object.
> 
> A maintainer can request the RIPE NCC to exclude a route(6) prefix from deletion (for example, the deregistration of the prefix is being disputed). For any excluded prefixes, any associated route(6) objects will not be deleted.
> 
> 
> Impact Analysis
> ------------------
> There are approximately 738 routes (out of 56,230) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved" in an RIRs delegated stats, which will be eligible for deletion.
> 
> There are approximately 94 route6's (out of 1,564) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved", so also eligible for deletion.
> 
> There are approximately 64 routes and 37 route6's with a prefix not listed in any RIR's delegated stats. These will not be affected.
> 
> When this cleanup is implemented, the backlog of route(6) objects eligible for deletion will be processed at the same time, leading to a large amount of emails to affected maintainers. Once this backlog is processed, the number of route(6) objects affected is expected to be low.
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20210331/575f5978/attachment.html>