Guidance Requested: Reassigning Referenced ASNs
Hi all Based on Randy's proposal:
inform owner of dangling reference. wait a week. inform again. wait a month. inform again. wait a week. remove dangling reference. wait a month to see if anything has broken enough to get the attention of folk who do not respond to email. reassign AS number.
In my point of view, it is enough to inform once. Members have to update their information, members have to be contactable by e-mail. So: 1. Inform owner about its wrong objects (only once). 2. If an owner doesn't clean up its objects, RIPE NCC should be able to clean up by itself after a month. 3. Re-assign AS numbers after two month. Best regards, Olaf Sonderegger
Based on Randy's proposal:
inform owner of dangling reference. wait a week. inform again. wait a month. inform again. wait a week. remove dangling reference. wait a month to see if anything has broken enough to get the attention of folk who do not respond to email. reassign AS number.
In my point of view, it is enough to inform once. Members have to update their information, members have to be contactable by e-mail.
So: 1. Inform owner about its wrong objects (only once). 2. If an owner doesn't clean up its objects, RIPE NCC should be able to clean up by itself after a month. 3. Re-assign AS numbers after two month.
I agree vith Olaf : - inform once - clean up after a month - re-assign after two months. WBR, Dmitry Menzulskiy OJSC "VimpelCom" Moscwo, Russia
Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
Hi all
In general I support the recycling of AS #s, but for operational and consistency reasons I'd be a bit more careful...
Based on Randy's proposal:
inform owner of dangling reference. wait a week. inform again. wait a month. inform again. wait a week. remove dangling reference. wait a month to see if anything has broken enough to get the attention of folk who do not respond to email. reassign AS number.
In my point of view, it is enough to inform once. Members have to update their information, members have to be contactable by e-mail.
So: 1. Inform owner about its wrong objects (only once).
ACK, although we may want to do a little bit more than just once, depending on the "failure mode" of the communication attempt. In particular, if the notification by email cannot be delivered, I'd suggest that the "member relations role" should follow up immediately. Depending on the outcome, we may try the alert again or take other, more serious steps as foreseen when a member[1] cannot be contacted.
2. If an owner doesn't clean up its objects, RIPE NCC should be able to clean up by itself after a month.
While I do see the beauty of this approach, we may actually add to the inconsistencies between assignment reality, documentation and operational reality. Note that over the last few years we made changes to the behaviour of the DB, aka Registry, which make it more and more likely that the "authoritative copy" of an object is kept locally. So, even if the NCC modifies an object, it may easily be recreated/updated to the old "wrong" state.
3. Re-assign AS numbers after two month.
Relative to the completion of the alerting exercise. With the caveat that those AS#s should be recycled first which are "clean", assuming that the stockpile is big enough to satisfy the requests.
Best regards, Olaf Sonderegger
Wilfried [1] "members" to be interpreted as the tree of members/LIRs own resources, as well as sponsored end user assignments
On Jun 26, 2013 11:25 AM, "Wilfried Woeber" <Woeber@cc.univie.ac.at> wrote:
In general I support the recycling of AS #s, but for operational and consistency reasons I'd be a bit more careful...
There is no shortage of ASn so we have the luxury of being able to be _very_ careful. Even after an ASn had been reclaimed we can easily wait a significant period of time before recycling them. Richard
On 26 Jun 2013, at 11:06, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
Even after an ASn had been reclaimed we can easily wait a significant period of time before recycling them.
+1.
On 26 Jun 2013, at 11:06, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
Even after an ASn had been reclaimed we can easily wait a significant period of time before recycling them.
+1.
Waiting itself isn't going to fix the 'problem' ... I've removed a certain AS from an Internet Exchange about 18 months ago. And we still get occasional email stating that the peering session is down ... while it was clearly communicated that we wanted to change certain sessions to another AS number and after several tries, we shut the connection and clearly communicated that the AS was removed from the Internet Exchange. Sad story but true ... Erik Bais
On 26 Jun 2013, at 11:06, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
Even after an ASn had been reclaimed we can easily wait a significant period of time before recycling them.
+1.
+1 I'm a little baffled as to why anyone would choose to hasten this at the cost of giving adequate notice? If we followed Randy's proposal to the letter we are still talking about being able to reuse AS# in roughly three months after policy is agreed. That seems fast enough to me, if not a little too fast :) John Sent from my iPad On Jun 26, 2013, at 3:07 AM, "Richard Hartmann" <richih.mailinglist@gmail.com<mailto:richih.mailinglist@gmail.com>> wrote: On Jun 26, 2013 11:25 AM, "Wilfried Woeber" <Woeber@cc.univie.ac.at<mailto:Woeber@cc.univie.ac.at>> wrote:
In general I support the recycling of AS #s, but for operational and consistency reasons I'd be a bit more careful...
There is no shortage of ASn so we have the luxury of being able to be _very_ careful. Even after an ASn had been reclaimed we can easily wait a significant period of time before recycling them. Richard
On Wed, Jun 26, 2013 at 12:06 PM, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
There is no shortage of ASn so we have the luxury of being able to be _very_ careful.
I now realized that this is mainly about 16 bit ASn.
Even after an ASn had been reclaimed we can easily wait a significant period of time before recycling them.
And thus, this opinion changes. 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. Thus, I would think something along the lines of: * 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 This means no effort on RIPE NCC's side, constant reminders to operators who may either need time to find out what those emails mean or under day-to-day stress (those exist, let's account for them), and overall reasonable effort to clean something up that may never be fully clean. As to what time is appropriate, I am still unsure, but "short-ish". Richard
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.
* 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? 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. rgds, Sascha Luck
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
On Mon, Jul 01, 2013 at 02:55:44PM +0200, Elvis Velea <elvis@velea.eu> wrote:
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).
Thanks for helping bring some clarity to this thread.
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".
Great idea. +1 C. -- 0x8486EDA8 http://spodder.com/
inform owner of dangling reference. wait a week. inform again. wait a month. inform again. wait a week. remove dangling reference. wait a month to see if anything has broken enough to get the attention of folk who do not respond to email. reassign AS number.
In my point of view, it is enough to inform once. Members have to update their information, members have to be contactable by e-mail. So: 1. Inform owner about its wrong objects (only once). 2. If an owner doesn't clean up its objects, RIPE NCC should be able to clean up by itself after a month. 3. Re-assign AS numbers after two month.
do we want to teach adults a lesson in proper behavior, or do we want to prudently run an operational internet? randy
participants (11)
-
Charlie Allom -
Dmitriy V Menzulskiy -
Elvis Velea -
Erik Bais -
Jim Reid -
John L. Crain -
Randy Bush -
Richard Hartmann -
Sascha Luck -
Sonderegger Olaf ABRAXAS INFORMATIK AG -
Wilfried Woeber