Sanity checking upon submitting to the DB could prevent this. My 2c, Andreas Schachtner Send via mobile device. Please excuse brevity, typos and the funny spelling checker in particular. Gert Doering <gert@space.net> schrieb:
Hi,
On Wed, Jun 26, 2013 at 06:40:21PM +0200, Opteamax GmbH - RIPE-Team wrote:
Actually I don't really understand the problem. If the ASN is back in the pool, this reads for me "it shall no longer appear in the routing table". This includes for me that any object referencing this ASN is illegal by definition. So these illegal objects may not exist and *must* be removed asap from the DB. After removing all illegal objects, they should stay in some "grace-period" - let's say 3 month - and then there should be no problem reallocating the asn.
The database currently has no mechanics to prevent someone from entering an import/export line that says:
aut-num: AS100000 remarks: have fun with Jens export: to AS5539 announce AS48200
which is exactly that sort of reference that would currently keep the NCC from reallocating AS48200 (assuming that one were free).
Auto-cleaning the route: objects still referencing AS48200 is fairly easy, but auto-cleaning export/import policies and AS-SET objects is harder, especially as people might have the aut-num: object in question on file, just change stuff locally, and then re-send it when they have changes, overriding the cleaned-up object in the database...
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279