[address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs

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 at 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