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

Hi Sascha, everyone,

On 7/1/13 2:14 PM, Sascha Luck wrote:
> Hi Andrea, group,
>
> On Mon, Jul 01, 2013 at 12:33:39PM +0200, Richard Hartmann wrote:
>> I don't think anything should be changed by RIPE NCC, objects need to
>> be updated by their respective maintainers. In the best case, objects
>> are recreated from scratch locally whenever an update occurs,
>> rendering this moot. In the worst case, automated systems that do
>> Weird Things (tm) will malfunction in interesting ways.
>
> Things need to be balanced here. A 'route:' object referencing a
> re-assigned ASN can cause problems for the new holder if their upstreams
> generate ACLs based on ripedb information. It's not feasible to leave
> these ASNs "blocked" forever.
> OTOH, gratuitiously deleting these objects can cause breakage for the
> holder of the referencing object (for the same reasons), possibly hops
> away and thus very hard to troubleshoot.

As far as I know, an AS Number can not be returned to the free 
pool/deleted from the RIPE Database unless all referencing route objects 
have been deleted. Any route object referencing a deleted AS Number is a 
broken object and should be deleted.

Therefore, the discussion here is not about references of returned AS 
Numbers in route objects but more about references in other types of 
objects (see below).

>
>> * When ASn is being deregistered, automatically email anyone who's
>> responsible for an object that references this ASn
>> * Once ASn is actually deregistered, send out automated email
>> * Once grace period is over, send out automated email
>> * Once ASn is reassigned, send final automated email
>
> +1 but:
>
> if no reaction to the final email, delete any 'route:' object
> referencing a returned ASN.
> There is a possible race condition here between "old/invalid" and
> "new/valid" 'route:' objects so the deletion should happen some time
> before the re-assignment.
>
> As for the issue of provisioning systems re-creating a removed 'route:'
> object, does the creation need to be authenticated by the ASN mntner? If
> not, could this be required to forestall such automatic re-creations?

Currently, creation of a route object requires the authentication of 
both the inet(6)num maintainer and the aut-num object's maintainer.

https://www.ripe.net/data-tools/db/faq/faq-route-object

So, a route object could not be re-created to reference an AS Number 
that does not exist.

>
> Finally, I'm not sure about treating policy statements in 'aut-num:'
> objects the same way. Is the presence of those actually an operational
> issue? I would certainly be opposed to simply deleting an aut-num object
> just because it contains an obsolete neighbour ASN.
>

Returned AS Numbers can still be referenced in other type of objects 
like aut-num, as-set, peering-set, route-set. To reference an ASN 
(returned or not) in these objects you are not required to authenticate 
with the maintainer of that ASN. Anyone can reference your AS Number in 
their objects.


I think that publishing a list of referenced AS Numbers would be a good 
first step in the clean-up. This way, any "concerned netcitizen could 
parse the list and fix their records".

Additionally, I think that contacting the maintainers that currently 
maintain the objects which reference the returned AS Numbers is a must. 
Give them some time to clean-up their objects and if they do not react, 
see the next paragraph.

After, let's say a month and a few reminders, if some returned AS 
Numbers are still referenced, additional to the list of referenced ASNs 
the RIPE NCC could publish an aggregated list of maintainers which are 
still maintaining objects that reference returned AS Numbers. This list 
could be updated automatically (daily/weekly) to show which maintainer 
still needs to update it's objects.

for example:
EXAMPLE-MNT is maintaining 'x' objects that reference 'y' returned AS 
Numbers.

Quite a few objects are being updated in the RIPE Database by scripts. 
If the RIPE NCC updates those objects, the changes made by the RIPE NCC 
will be reverted once the script is run again. On the other hand, if the 
maintainer is made aware that they need to update their script and 
remove those references, the process may be smoother.

my 2 cents,
elvis