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