Guidance Requested: Reassigning Referenced ASNs
[Apologies for duplicates] Dear colleagues, At the Address Policy WG session during RIPE 66, the RIPE NCC requested guidance from the RIPE community on reassigning referenced 16-bit ASNs. Together with the Address Policy WG Chairs, we have decided to seek additional input from the WG mailing list. Background: the RIPE NCC has around 1,400 returned 16-bit ASNs that are currently referenced in route objects, and "import" and "export" lines in aut-num objects. Problem: there is a need for 16-bit ASNs by operators. However, because these ASNs are referenced, they are not being reassigned. At RIPE 66, the RIPE NCC suggested the following potential solutions: A. Not reassign referenced AS numbers B. Reassign AS numbers even if referenced C. Clean up the RIPE Database from references and then reassign the AS numbers C.1. "Silent" update; or C.2. Informing the object holder of the update Please find the RIPE Meeting slides at the following url: https://ripe66.ripe.net/presentations/176-Address_Policy_WG_RIPE_66.pdf This email has been sent to both the Address Policy WG and RIPE Database WG mailing lists, due to the impact the proposals would have on the RIPE Database. However, we would ask to keep the discussion on the Address Policy WG mailing list to facilitate participation and the channeling of feedback. Thank you in advance for your input and best regards, Andrea Cima RIPE NCC
On 25 June 2013 14:02, Andrea Cima <andrea@ripe.net> wrote:
C. Clean up the RIPE Database from references and then reassign the AS numbers C.1. "Silent" update; or C.2. Informing the object holder of the update
Okay couple of questions... 1. Have people with these objects been notified yet (might be a good place to start)? As a matter of course are returns actually announced/published anywhere? 2. Is there a single list of returned and referenced ASNs that a concerned netcitizen could parse and then fix their records from? I think cart and horse spring to mind J -- James Blessing 07989 039 476
On 25/06/2013 14:02, Andrea Cima wrote:
A. Not reassign referenced AS numbers B. Reassign AS numbers even if referenced C. Clean up the RIPE Database from references and then reassign the AS numbers C.1. "Silent" update; or C.2. Informing the object holder of the update
My preference would be for C.1, and that the process of reassignment should not be delayed by replies or a lack of replies from object holders who are referencing the ASNs. As this is an operational issue, is there a need for a policy proposal? Nick
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. randy
On 25 jun 2013, at 17:51, Randy Bush <randy@psg.com> wrote:
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.
Seems like a reasonable approach to me. Best regards, - kurtis -
Hi, Op 28 jun. 2013, om 11:38 heeft Lindqvist Kurt Erik <kurtis@kurtis.pp.se> het volgende geschreven:
On 25 jun 2013, at 17:51, Randy Bush <randy@psg.com> wrote:
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.
Seems like a reasonable approach to me.
+1 Sander
On 06/25/13 18:47, Nick Hilliard wrote:
On 25/06/2013 14:02, Andrea Cima wrote:
A. Not reassign referenced AS numbers B. Reassign AS numbers even if referenced C. Clean up the RIPE Database from references and then reassign the AS numbers C.1. "Silent" update; or C.2. Informing the object holder of the update My preference would be for C.1, and that the process of reassignment should not be delayed by replies or a lack of replies from object holders who are referencing the ASNs.
As this is an operational issue, is there a need for a policy proposal?
Nick
Fully agree with Nick Communication with resource holders that referenced to unused ASN is the way to waste time. If the ASN is already returned to the pool, it means that the RIPE had tried to communicate with the resource holder at least three times during at least 3 month. So, there's no necessity to provide additional time to communicate with someone. Moreover: the ASN assigned to no one, so clearing the database from the erroneous reference will not affect to any resource holder (it's because there's no the ASN holder any more) and all references may be cleared as soon the ASN is returned to the pool. All the RIPE may to do - is to notify a holder of the resource that was silently cleared (but after the object was cleared) So, C.1 - is the good choice -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
If the ASN is already returned to the pool, it means that the RIPE had tried to communicate with the resource holder at least three times during at least 3 month.
the resource holder of a route: object owns the ip space, not necessarily the asn. randy
Randy Bush <randy@psg.com> schrieb:
If the ASN is already returned to the pool, it means that the RIPE had tried to communicate with the resource holder at least three times during at least 3 month.
the resource holder of a route: object owns the ip space, not necessarily the asn.
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. I mean, IPv4 is also reallocated pretty quickly, as my last /22 existed in my routing table announced from a London based ASN less than two months before it was allocated to my LIR. BTW: IMHO the database shall also be cleaned from route6 objects with invalid netmasks ... but that's a different topic ;) BR Jens
randy
!DSPAM:637,51cb0c70196951779145505!
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
Hi, Gert Doering wrote: [...]
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).
Also, as was mentioned when this was discussed at RIPE 52, there may well be references in other - popular - routing registries. Regards, Leo Vegoda
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 Got the point, thanks for making it clearer to me (and maybe some others) So this might also be a task for the database working group then ;) Jens
On 26/06/2013 19:11, Gert Doering wrote:
which is exactly that sort of reference that would currently keep the NCC from reallocating AS48200 (assuming that one were free).
... which is why I suggested that inaction shouldn't negatively affect timelines. People never clean up after themselves, so the RIPE NCC will either need to edit the affected objects themselves (which will work fine until someone's provisioning database respams the DB with out-of-date information) or else notify + wait, but then ultimately ignore if there's a problem. Other IRRDBs are other peoples' problems. A recycling period of a couple of months would seem sensible, as there will be a resource shortage for asn16s. There's no reason for the RIPE NCC not to notify references immediately. Nick
Randy Bush wrote:
If the ASN is already returned to the pool, it means that the RIPE had tried to communicate with the resource holder at least three times during at least 3 month.
the resource holder of a route: object owns the ip space, not necessarily the asn.
Actually, he owns nothing. He holds. Nevertheless, how does it correlates with reassigning of ASNs and removing references to it? If the resource holder doesn't hold AS number - he shouldn't use it. If he shouldn't use it - any reference to object that doesn't hold by any End User may be (and should be) deleted for the future reassigning. I saw no information inside proposal to remove the objects that referenced to deleted ASN - it's just removing a broken references inside those objects. So, deleting of the broken references is the way to provide integrity to RIPE's database - nothing additional. -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
Hi, On Wed, Jun 26, 2013 at 08:50:29PM +0300, Andrey Semenchuk wrote:
I saw no information inside proposal to remove the objects that referenced to deleted ASN - it's just removing a broken references inside those objects. So, deleting of the broken references is the way to provide integrity to RIPE's database - nothing additional.
You can't remove the reference to an ASN from a route:/route6: object - you have to remove the whole object. Gert Doering -- Operator -- 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
On 06/27/13 13:42, Gert Doering wrote: > On Wed, Jun 26, 2013 at 08:50:29PM +0300, Andrey Semenchuk wrote: >> I saw no information inside proposal to remove the objects that >> referenced to deleted ASN - it's just removing a broken references >> inside those objects. So, deleting of the broken references is the way >> to provide integrity to RIPE's database - nothing additional. > You can't remove the reference to an ASN from a route:/route6: object - you > have to remove the whole object. let me to correct myself: "I saw no information inside proposal to remove the *resource* objects that referenced to deleted ASN". Any route object is illegal since the ASN does not exists. As it seems to me, there're two solutions: - to delete illegal resource; - to replace reference inside those objects to the placeholder ASN The first solution is more correct RFC1786: ========= The value of the origin attribute will be an AS reference of the form AS1234 referring to an aut-num object. It represents the AS injecting this route into the routing mesh. ========= RIPE-252: ========= 1.2.16 route ... The "route:" attribute is the address prefix of the route and the "origin:" attribute is the AS number of the AS that originates the route into the interAS routing system. ... ========= No ASN - no route object. -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
let me to correct myself: "I saw no information inside proposal to remove the *resource* objects that referenced to deleted ASN". Any route object is illegal since the ASN does not exists. As it seems to me, there're two solutions: - to delete illegal resource; Sorry, my fault: to delete illegal object (route, route6, as-set etc). All resourse objects should not be deleted. But may be cleared of references to non-existent ASNs (import/export policy for example)
-- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
Hi Andrey, You stated (if I may quote you freely) ... that if an AS number is returned, it might / should not impact routing ... And you are probably right for 99.8% .. However ... there might be situations where someone would be using a certain BGP community in RPLS for internal reference still while the actual AS number isn't used anymore. Think about a similar way as how certain routeserver filtering is implemented. import: from AS6777 action pref=85; accept ANY AND NOT <^[ASAAAA ASXXXX ASYYYYY ASZZZZZ ASWWWW]> AND NOT {0.0.0.0/0} export: to AS6777 action community .= {6777:6777, 6777:AAAAA, 6777:XXXX, 6777:YYYYY, 6777:ZZZZ, 6777:WWWW}; announce AS-<as-number> Erik Bais
Hi, Erik On 06/26/13 23:16, Erik Bais wrote:
However ... there might be situations where someone would be using a certain BGP community in RPLS for internal reference still while the actual AS number isn't used anymore.
Any reference to the returned ASN that do not affect to the routing by itself should not prevent RIPE from reassigning this ASN. No one will prevent End User from placing some references inside his objects to ASNs that wasn't assigned ever. It's not the reason to not assign these ASNs. I think that some validation should be used even for import/export entries and RIPE's database should prevent End User from updating objects with erroneous information. In this case any existing reference inside object to the ASNs that are not assigned (or ASN that were returned to the pool) will make object that is referenced to them non up-to-date and notification may be sent to the resource holder. But my opinion that all references to unassigned objects should be removed by RIPE's software with notification message to the resource holder's contacts. We shouldn't wait any actions from anybody to reassign the resources. As long we talking about RIPE database all similar references may be found by the RIPE's software. Those references may be removed and the resource holders may be notified about this situations. I don't think that it's the problem - multiple regular expressions will do this work for us. -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
Hi Andrea, In general I agree to the idea of recycling the returned AS numbers. I also think that the contacts of referenced AS numbers in the database, should be contacted (probably multiple times as Randy suggested) and in the end, fix it in the database if nothing is fixed. The idea of cleaning the RIPE db is noble and we should do that, however there are also other locations where those AS numbers are referenced.. ( PeeringDB or RADB comes to mind..) Are we going to provide them with the list of current returned AS numbers to make sure they can also do their housekeeping ? Regards, Erik Bais -----Original Message----- From: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Andrea Cima Sent: dinsdag 25 juni 2013 15:02 To: address-policy-wg@ripe.net Cc: db-wg@ripe.net Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs [Apologies for duplicates] Dear colleagues, At the Address Policy WG session during RIPE 66, the RIPE NCC requested guidance from the RIPE community on reassigning referenced 16-bit ASNs. Together with the Address Policy WG Chairs, we have decided to seek additional input from the WG mailing list. Background: the RIPE NCC has around 1,400 returned 16-bit ASNs that are currently referenced in route objects, and "import" and "export" lines in aut-num objects. Problem: there is a need for 16-bit ASNs by operators. However, because these ASNs are referenced, they are not being reassigned. At RIPE 66, the RIPE NCC suggested the following potential solutions: A. Not reassign referenced AS numbers B. Reassign AS numbers even if referenced C. Clean up the RIPE Database from references and then reassign the AS numbers C.1. "Silent" update; or C.2. Informing the object holder of the update Please find the RIPE Meeting slides at the following url: https://ripe66.ripe.net/presentations/176-Address_Policy_WG_RIPE_66.pdf This email has been sent to both the Address Policy WG and RIPE Database WG mailing lists, due to the impact the proposals would have on the RIPE Database. However, we would ask to keep the discussion on the Address Policy WG mailing list to facilitate participation and the channeling of feedback. Thank you in advance for your input and best regards, Andrea Cima RIPE NCC
On 26 jun 2013, at 21:48, Erik Bais <ebais@a2b-internet.com> wrote:
The idea of cleaning the RIPE db is noble and we should do that, however there are also other locations where those AS numbers are referenced.. ( PeeringDB or RADB comes to mind..)
RADB contains so much garbage that I think best would be for people to stop using it....YMMV
Are we going to provide them with the list of current returned AS numbers to make sure they can also do their housekeeping ?
I think that publishing lists on ASNs in each stage in Randy's proposal for example would be prudent... Best regards, - kurtis -
Hi, Op 28 jun. 2013, om 11:40 heeft Lindqvist Kurt Erik <kurtis@kurtis.pp.se> het volgende geschreven:
On 26 jun 2013, at 21:48, Erik Bais <ebais@a2b-internet.com> wrote:
Are we going to provide them with the list of current returned AS numbers to make sure they can also do their housekeeping ?
I think that publishing lists on ASNs in each stage in Randy's proposal for example would be prudent...
+1 on this as well Sander
participants (12)
-
Andrea Cima -
Andrey Semenchuk -
Erik Bais -
Erik Bais -
Gert Doering -
James Blessing -
Leo Vegoda -
Lindqvist Kurt Erik -
Nick Hilliard -
Opteamax GmbH - RIPE-Team -
Randy Bush -
Sander Steffann