[db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
- Previous message (by thread): [db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
- Next message (by thread): [db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sander Steffann
sander at steffann.nl
Wed Nov 11 18:34:56 CET 2015
Hi Tim, >> STEP 3: continiously check if the block is allocated in the foreign RIR database, if no longer, delete the route-object from RIPE's IRR db. > > We share concerns raised by Job. We believe this adds a lot of complexity to the implementation, and introduces an unacceptable risk of deleting the wrong objects. Furthermore we believe that this step is not necessary if we implement step 5 (below). So what happens to route objects referring to de-registered stuff in other databases? If nobody cleans it up manually we keep objects with dangling pointers in our database? I understand that automatically deleting them would be risky as e.g. an unexpected change in a remote database might cause us to think the object has been deleted there etc. Maybe a nice idea if all RIRs publish a timestamped list of de-registered/reclaimed resources in a common format? :) Anyway: maybe something to look into to prevent garbage from accumulating in our own database. > It will obviously require work. Very rough initial estimates indicate it can take up to a few months. We can refine these estimates if and when we have a clear consensus on a go-ahead. Thanks, always good to get an estimate from the authoritative source ;) Cheers! Sander
- Previous message (by thread): [db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
- Next message (by thread): [db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]