Input Requested: How to Ensure Responsible ASN Resource Management
Dear colleagues, At RIPE 86, we shared some observations regarding Autonomous System Number (ASN) requests and usage [1]. We see an increasing number of ASN requests coming from both inside and outside of our service region. This seems to be driven primarily by the low cost and ease of receiving an ASN from the RIPE NCC. The downside is that we also see a significant decrease in responsible resource management by these resource holders. A large number of ASNs are never used or become abandoned after a short period. Some data: in the last two years, we have provided 4,186 ASNs (between March 2021 and February 2023). Of this amount, we can see that 1,478 ASNs (more than 35%) do not appear to be in use, as they are not visible in the routing system. Looking at total numbers, we have issued almost 38,000 ASNs, of which more than 8,000 (~20%) are not visible. This growing trend not only creates avoidable work for Registration Services and added costs for the membership, we believe it also undermines the goal of responsible management of Internet number resources within our service region. As the membership voted against an annual service fee for ASNs at the recent RIPE NCC General Meeting, I would like to ask the working group for guidance on how resource holders can be motivated to manage their ASNs responsibly and how the RIPE NCC can provide support for this. We also plan to intensify our ongoing project to clean up unused Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have been recovered as part of this work so far. Do you support our approach here? And are there other ways we could improve the situation? Perhaps you could add clarification on requesting and returning ASNs in the relevant RIPE policy, or maybe we could give a stronger mandate and responsibility to the sponsoring LIRs. If you have an ASN registered to you that you don’t need anymore, you can always contact us through the LIR Portal or via your sponsoring LIR and we will arrange for the return of this resource. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] https://ripe86.ripe.net/wp-content/uploads/presentations/82-RIPE86-Feeback-f... [2] https://www.ripe.net/manage-ips-and-asns/as-numbers/as-number-clean-up
Hello, A couple of my cents, below. On 08/06/2023 16:30, Marco Schmidt wrote:
At RIPE 86, we shared some observations regarding Autonomous System Number (ASN) requests and usage [1].
We see an increasing number of ASN requests coming from both inside and outside of our service region. This seems to be driven primarily by the low cost and ease of receiving an ASN from the RIPE NCC. The downside is that we also see a significant decrease in responsible resource management by these resource holders. A large number of ASNs are never used or become abandoned after a short period. <snip> As the membership voted against an annual service fee for ASNs at the recent RIPE NCC General Meeting, I would like to ask the working group for guidance on how resource holders can be motivated to manage their ASNs responsibly and how the RIPE NCC can provide support for this.
Perhaps if the first ASN (per LIR) was free, and additional ASNs would incur an annual fee? This way "a typical small LIR" would still pay the minimal annual fee, and such a proposal would get more votes. Thinking a bit further, since 16-bit ASNs are slightly more precious due to compatibility issues, perhaps only 32-bit ASNs should be eligible to be free?
We also plan to intensify our ongoing project to clean up unused Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have been recovered as part of this work so far. Do you support our approach here? And are there other ways we could improve the situation? Perhaps you could add clarification on requesting and returning ASNs in the relevant RIPE policy, or maybe we could give a stronger mandate and responsibility to the sponsoring LIRs.
Uh oh, there are also valid reasons for ASNs to appear to be unused, while being very much in use. For example, a pure transit provider will not originate routes, altho such an ASN will still appear in AS Paths. A route server at an IXP on the other hand won't even appear in AS Paths. You should try to analyse the ASNs a bit more before trying to recover them. Best Regards, -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail
Hi, On Thu, 8 Jun 2023 at 07:11, Aleksi Suhonen <ripe-ml-2023@ssd.axu.tm> wrote: [...]
As the membership voted against an annual service fee for ASNs at the recent RIPE NCC General Meeting, I would like to ask the working group for guidance on how resource holders can be motivated to manage their ASNs responsibly and how the RIPE NCC can provide support for this.
Perhaps if the first ASN (per LIR) was free, and additional ASNs would incur an annual fee? This way "a typical small LIR" would still pay the minimal annual fee, and such a proposal would get more votes.
The RIPE NCC's charging scheme is not managed through this working group. Suggestions for changes to the RIPE NCC's charges should be raised on the RIPE NCC's membership discussion list: https://www.ripe.net/ripe/mail/archives/members-discuss/ Kind regards, Leo (for the WG chairs)
Marco Schmidt wrote on 08/06/2023 14:30:
We also plan to intensify our ongoing project to clean up unused Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have been recovered as part of this work so far. Do you support our approach here? And are there other ways we could improve the situation? Perhaps you could add clarification on requesting and returning ASNs in the relevant RIPE policy, or maybe we could give a stronger mandate and responsibility to the sponsoring LIRs.
Hi Marco, There are good reasons to clean up unused ASN16s, as they are categorised by policy as scarce resources. There isn't a compelling reason to get as excited about ASN32s, other than to say that normal good stewardship practices should apply. Unfortunately there is a disconnect between RIPE policy and RIPE NCC practice in regard to charges for ASNs. This is a real shame because paying for resources is one of the simpler ways of creating positive pressure to return them if they're unused. The community would benefit from the board re-thinking this. Nick
In the GM a few weeks ago, resolution 4 or the proposal for charging 50 eur/ASN, which was presented by NCC management and supported by the board, I believe, was not adopted. The 67% of the membership votes cast or approximately 1500 votes were against. Kaj Sent from my iPad ________________________________ From: address-policy-wg <address-policy-wg-bounces@ripe.net> on behalf of Nick Hilliard <nick@foobar.org> Sent: Thursday, June 8, 2023 5:55 PM To: Marco Schmidt <mschmidt@ripe.net> Cc: address-policy-wg@ripe.net <address-policy-wg@ripe.net> Subject: Re: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management Marco Schmidt wrote on 08/06/2023 14:30:
We also plan to intensify our ongoing project to clean up unused Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have been recovered as part of this work so far. Do you support our approach here? And are there other ways we could improve the situation? Perhaps you could add clarification on requesting and returning ASNs in the relevant RIPE policy, or maybe we could give a stronger mandate and responsibility to the sponsoring LIRs.
Hi Marco, There are good reasons to clean up unused ASN16s, as they are categorised by policy as scarce resources. There isn't a compelling reason to get as excited about ASN32s, other than to say that normal good stewardship practices should apply. Unfortunately there is a disconnect between RIPE policy and RIPE NCC practice in regard to charges for ASNs. This is a real shame because paying for resources is one of the simpler ways of creating positive pressure to return them if they're unused. The community would benefit from the board re-thinking this. Nick -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
Dear colleagues, Thank you for the feedback received so far. As Aleksi noted, there are indeed valid reasons why ASNs seem to be unused. We have some data on this from our AS Number Clean up project. When asked if the resource is being used, about 2/3 of ASNs have been returned, about 1/3 are expected to be used soon, and only a very small number have been used by transit providers or IXPs. Of the more than 8,000 ASNs not visible in the routing system, about 52% are 16-bit ASNs. As mentioned by Kaj, the members of RIPE NCC clearly voted against charging for ASNs. So we wanted to ask this working group if there are other ways to improve the situation? Something that falls under the authority of the RIPE community, such as developing RIPE policies or guidelines for Registration Services. For example, are you in favour of us being more active in trying to clarify the status of ASNs that seem to have been unused for a long period of time? Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 08/06/2023 16:55, Nick Hilliard wrote:
Marco Schmidt wrote on 08/06/2023 14:30:
We also plan to intensify our ongoing project to clean up unused Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have been recovered as part of this work so far. Do you support our approach here? And are there other ways we could improve the situation? Perhaps you could add clarification on requesting and returning ASNs in the relevant RIPE policy, or maybe we could give a stronger mandate and responsibility to the sponsoring LIRs.
Hi Marco,
There are good reasons to clean up unused ASN16s, as they are categorised by policy as scarce resources. There isn't a compelling reason to get as excited about ASN32s, other than to say that normal good stewardship practices should apply.
Unfortunately there is a disconnect between RIPE policy and RIPE NCC practice in regard to charges for ASNs. This is a real shame because paying for resources is one of the simpler ways of creating positive pressure to return them if they're unused. The community would benefit from the board re-thinking this.
Nick
Hi Marco, everyone, my take would be as follows: The RIPE NCC could just send automated monthly/quarterly messages to ASN holders if the ASN has not been seen in the global routing table for more than 3/6/12 months. We could agree to this on the mailing list and this could be a process and not necessarily a new policy proposal, this process could also be adjusted every few years if needed. Just notifications, no other follow-up or requests for return. I’d see the message say something like: “ you received an ASN x months ago, this ASN has not been seen in use in the global routing table for at least 3/6/12 months. You can return it if you do not have any plans to use it. Just reply to this message and we’ll return it to the free pool. You can always come back and request an ASN from the RIPE NCC, should you have plans to use one.” The message would also include how it is good stewardship both by the RIPE NCC and the ASN holder to keep a clean registry by returning an unused ASN to the free pool. To be honest, in today’s environment, I don’t see why a differentiation between 16bit and 32bit ASNs still exist. If someone could tell me why a 32bit ASN can not be used today (even with 10 years old equipment), I’d appreciate it. Also, I do agree that a clean registry is a priority for the NCC and the community but I think work (FTEs) should be invested in this project only for the part where the holder wants to return it and some work needs to be done. In the number transfer world, low number ASNs are worth ‘more’ due to them being considered vanity numbers. However, I find it silly today to have different policies, restrictions or processes for 16bit vs 32bit ASNs. my 0.2c Elvis On Thu, Jun 8, 2023 at 22:25 Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
Thank you for the feedback received so far.
As Aleksi noted, there are indeed valid reasons why ASNs seem to be unused. We have some data on this from our AS Number Clean up project. When asked if the resource is being used, about 2/3 of ASNs have been returned, about 1/3 are expected to be used soon, and only a very small number have been used by transit providers or IXPs.
Of the more than 8,000 ASNs not visible in the routing system, about 52% are 16-bit ASNs.
As mentioned by Kaj, the members of RIPE NCC clearly voted against charging for ASNs. So we wanted to ask this working group if there are other ways to improve the situation? Something that falls under the authority of the RIPE community, such as developing RIPE policies or guidelines for Registration Services. For example, are you in favour of us being more active in trying to clarify the status of ASNs that seem to have been unused for a long period of time?
Kind regards,
Marco Schmidt Manager Registration Services RIPE NCC
On 08/06/2023 16:55, Nick Hilliard wrote:
Marco Schmidt wrote on 08/06/2023 14:30:
We also plan to intensify our ongoing project to clean up unused Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have been recovered as part of this work so far. Do you support our approach here? And are there other ways we could improve the situation? Perhaps you could add clarification on requesting and returning ASNs in the relevant RIPE policy, or maybe we could give a stronger mandate and responsibility to the sponsoring LIRs.
Hi Marco,
There are good reasons to clean up unused ASN16s, as they are categorised by policy as scarce resources. There isn't a compelling reason to get as excited about ASN32s, other than to say that normal good stewardship practices should apply.
Unfortunately there is a disconnect between RIPE policy and RIPE NCC practice in regard to charges for ASNs. This is a real shame because paying for resources is one of the simpler ways of creating positive pressure to return them if they're unused. The community would benefit from the board re-thinking this.
Nick
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
-- This message was sent from a mobile device. Some typos may be possible.
Elvis Daniel Velea wrote on 11/06/2023 10:06:
If someone could tell me why a 32bit ASN can not be used today (even with 10 years old equipment), I’d appreciate it.
there's plenty of kit out there which still doesn't support BGP Large Communities, particularly mikrotik routeros which only released an initial production implementation at around the beginning of 2022. Nick
Hi, On Mon, Jun 12, 2023 at 11:25:16AM +0100, Nick Hilliard wrote:
there's plenty of kit out there which still doesn't support BGP Large Communities, particularly mikrotik routeros which only released an initial production implementation at around the beginning of 2022.
How would you translate this into "generic 32bit AS number usability"? I do understand how folks like IXPs use 32bit ASNs, but the consequence of your statement would be "no IXP can have any 32bit participant, because someone with a Mikrotik router might not be able to set proper communities", which is not what happens in reality. So for the IXP ASN itself, I can see some stronger arguments for a 16bit ASN (because fallback to 16bit IXP:<thing> community values wouldn't work either, then) - but for everything else? More curious than trying to argue any particular point, Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert Doering wrote on 12/06/2023 11:34:
How would you translate this into "generic 32bit AS number usability"?
this wasn't a comment about IXPs: many smaller organisations have mikrotiks running with bgp on service provider networks, but are unable to run BGP LC because of lack of support. If you run a Mikrotik at an IXP, there are a number of important caveats to be aware of, BGP LC being one. Nick
Hi, On Mon, Jun 12, 2023 at 11:41:06AM +0100, Nick Hilliard wrote:
Gert Doering wrote on 12/06/2023 11:34:
How would you translate this into "generic 32bit AS number usability"?
this wasn't a comment about IXPs: many smaller organisations have mikrotiks running with bgp on service provider networks, but are unable to run BGP LC because of lack of support.
Yes. But what are - or should be - the consequences of this? Add a note to the long list of "Mikrotik leaves to be improved" and go on? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
could this community convince Mikrotik to develop firmware to support all the internet numbers (and not just the convenient ones) ? do we have anyone from Mikrotik in this mailing list to explain what is stopping them from developing software that supports BGP LC? I mean, 32bit ASNs have been around since 2007, do they need 25 years or maybe 100 to code software/firmware that supports all numbers? /rant elvis On Mon, Jun 12, 2023 at 1:22 AM Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Jun 12, 2023 at 11:41:06AM +0100, Nick Hilliard wrote:
Gert Doering wrote on 12/06/2023 11:34:
How would you translate this into "generic 32bit AS number usability"?
this wasn't a comment about IXPs: many smaller organisations have mikrotiks running with bgp on service provider networks, but are unable to run BGP LC because of lack of support.
Yes. But what are - or should be - the consequences of this?
Add a note to the long list of "Mikrotik leaves to be improved" and go on?
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
-- This message was sent from a mobile device. Some typos may be possible.
Hi, On Mon, Jun 12, 2023 at 01:38:58AM -1000, Elvis Daniel Velea wrote:
I mean, 32bit ASNs have been around since 2007, do they need 25 years or maybe 100 to code software/firmware that supports all numbers?
/rant
I welcome you to read up on "BGP camel"... (Note that this is not about "32 bit ASN" but about "large communities", which were only standardized a few years ago) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, I remember talks about large communities in the late 2000s, I see that they have only been standardized in 2017, a mere 6 years ago.. so the question stands, although the exageration can be reduced to.. how many decades does Mikrotik need to support it? :) I’ve gone off rails, let’s see what Marco says and if it makes sense to actively chase returns of unused 16bit ASNs. elvis On Mon, Jun 12, 2023 at 1:46 AM Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Jun 12, 2023 at 01:38:58AM -1000, Elvis Daniel Velea wrote:
I mean, 32bit ASNs have been around since 2007, do they need 25 years or maybe 100 to code software/firmware that supports all numbers?
/rant
I welcome you to read up on "BGP camel"...
(Note that this is not about "32 bit ASN" but about "large communities", which were only standardized a few years ago)
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
-- This message was sent from a mobile device. Some typos may be possible.
Hi, MikroTik has large community support since RouterOS v7. So that's no longer an excuse for 16 bit AS numbers. Best regards On 6/12/23 13:38, Elvis Daniel Velea wrote:
could this community convince Mikrotik to develop firmware to support all the internet numbers (and not just the convenient ones) ? do we have anyone from Mikrotik in this mailing list to explain what is stopping them from developing software that supports BGP LC?
I mean, 32bit ASNs have been around since 2007, do they need 25 years or maybe 100 to code software/firmware that supports all numbers?
/rant
elvis
On Mon, Jun 12, 2023 at 1:22 AM Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Jun 12, 2023 at 11:41:06AM +0100, Nick Hilliard wrote: > Gert Doering wrote on 12/06/2023 11:34: > > How would you translate this into "generic 32bit AS number usability"? > > this wasn't a comment about IXPs: many smaller organisations have > mikrotiks running with bgp on service provider networks, but are unable > to run BGP LC because of lack of support.
Yes. But what are - or should be - the consequences of this?
Add a note to the long list of "Mikrotik leaves to be improved" and go on?
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
-- This message was sent from a mobile device. Some typos may be possible.
Hi Nick, On Mon, Jun 12, 2023 at 00:25 Nick Hilliard <nick@foobar.org> wrote:
Elvis Daniel Velea wrote on 11/06/2023 10:06:
If someone could tell me why a 32bit ASN can not be used today (even with 10 years old equipment), I’d appreciate it.
there's plenty of kit out there which still doesn't support BGP Large Communities, particularly mikrotik routeros which only released an initial production implementation at around the beginning of 2022.
Nick
thanks for that. I’m surprised to hear this, but heh, manufacturers can be slow sometimes… very slow :( It may, then, matter to some if an ASN is 16bit or not. I know that the NCC had at some point (maybe still do) assigned 16bit ASNs upon request. Curious to see some stats, if possible: - how many requests come in for 16bit a year? how many are those of the total ASN requests? - how many 16bit ASNs are still in the pool and how many come back to the free pool every year? Just trying to see how many years until 16bit ASNs could only be issued by the NCC only if returned. On another note, I believe that there were a lot of 16bit ASNs in quarantine because of references in various objects (mostly as-sets if I recall correctly). Can you tell us, Marco, how many of those ASNs are quarantined and why aren’t these removed out of quarantine and assigned? elvis -- This message was sent from a mobile device. Some typos may be possible.
Dear Elvis, dear colleagues, We are happy to provide you with the data you requested. In the last 12 months, about 18% (414 out of 2291) of the requests were for 16-bit ASNs. Currently we have enough 16-bit ASNs in our free pool, but it should be noted that the return of unused ASNs is the only source to add such ASNs to our pool. Once an ASN has been returned to RIPE NCC, the only reason to keep it in our quarantine pool for longer than 6 months is that the ASN is still visible in the routing system. We currently have just over 200 16-bit ASNs in regular quarantine, mainly thanks to our project to clean up unused ASNs. It is correct that we still assign 16-bit ASNs when they are specifically requested. Although the ASN policy states that since "2010 the RIPE NCC will cease to make any distinction", it was decided in 2010 to keep the option to request for 16-bit ASNs [1][2] Neither IANA nor other RIRs make this distinction between 16-bit and 32-bit ASNs any more. I hope you found this information useful, especially in terms of how to achieve more responsible ASN management. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] https://www.ripe.net/publications/docs/ripe-679#ASnumbers [2] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2010-January/00497... On 12/06/2023 12:46, Elvis Daniel Velea wrote:
Hi Nick,
On Mon, Jun 12, 2023 at 00:25 Nick Hilliard <nick@foobar.org> wrote:
Elvis Daniel Velea wrote on 11/06/2023 10:06: > If someone could tell me why a 32bit ASN can not be used today (even > with 10 years old equipment), I’d appreciate it.
there's plenty of kit out there which still doesn't support BGP Large Communities, particularly mikrotik routeros which only released an initial production implementation at around the beginning of 2022.
Nick
thanks for that. I’m surprised to hear this, but heh, manufacturers can be slow sometimes… very slow :(
It may, then, matter to some if an ASN is 16bit or not. I know that the NCC had at some point (maybe still do) assigned 16bit ASNs upon request. Curious to see some stats, if possible: - how many requests come in for 16bit a year? how many are those of the total ASN requests? - how many 16bit ASNs are still in the pool and how many come back to the free pool every year?
Just trying to see how many years until 16bit ASNs could only be issued by the NCC only if returned.
On another note, I believe that there were a lot of 16bit ASNs in quarantine because of references in various objects (mostly as-sets if I recall correctly). Can you tell us, Marco, how many of those ASNs are quarantined and why aren’t these removed out of quarantine and assigned?
elvis
-- This message was sent from a mobile device. Some typos may be possible.
Hi WG, At some point in the past we had a discussion about making it easier to request ASNs, basically removing the multihoming requirement. This working group at the time decided to not do this because it *might* cause someone to ask for an insane number of ASNs and overload the RIPE NCC. A recurring (or even a one-time) cost for ASNs would automatically solve this issue, because going insane would become financially unfeasible :) Now that the RIPE NCC’s membership has decided that they don’t care about this, I think it’s time to reopen this discussion on our side. There are many reasons someone might want to have an (extra) ASN: lab use, education (I’d love to set up BGP training course where students can actually announce a real IPv6 prefix to the world with a real ASN and see the results), internal use (while still needing a globally unique one), not YET being multi homed but going to in the future etc. I’d like to propose to remove the multi homing requirement from our ASN policy, as the main reason why we decided not to last time doesn’t seem to hold anymore. Cheers, Sander
Hi Sander, I'm not very familiar with the history but if it is like you are describing it then I agree with you. Although we should maybe split this into a different thread because this is getting a bit confusing. -Cynthia On Mon, 12 Jun 2023, 14:13 Sander Steffann, <sander@steffann.nl> wrote:
Hi WG,
At some point in the past we had a discussion about making it easier to request ASNs, basically removing the multihoming requirement. This working group at the time decided to not do this because it *might* cause someone to ask for an insane number of ASNs and overload the RIPE NCC. A recurring (or even a one-time) cost for ASNs would automatically solve this issue, because going insane would become financially unfeasible :)
Now that the RIPE NCC’s membership has decided that they don’t care about this, I think it’s time to reopen this discussion on our side. There are many reasons someone might want to have an (extra) ASN: lab use, education (I’d love to set up BGP training course where students can actually announce a real IPv6 prefix to the world with a real ASN and see the results), internal use (while still needing a globally unique one), not YET being multi homed but going to in the future etc.
I’d like to propose to remove the multi homing requirement from our ASN policy, as the main reason why we decided not to last time doesn’t seem to hold anymore.
Cheers, Sander
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
Hi, One other aspect to consider - there are situations where public ASNs (and addresses) are required - but not directly connected to the Internet. Therefore, they do not appear in the Internet routing tables but are legitimately used elsewhere. For example, in our field (mobile cellular networks) mobile operators are connected using the IPX network as managed by the GSMA. This is distinct from the Internet but public ASNs and addresses are required. The relevant guidelines from the GSMA: https://www.gsma.com/newsroom/wp-content/uploads/IR.40-v8.0.pdf 'The GSMA worked closely with the all the RIR communities (RIPE NCC, ARIN and APNIC) to develop and produce the early versions of this document. This was essential to ensure that the proposed guidelines to the Service Providers associated with requesting and implementing Public addresses are aligned with the existing policies and procedures of the RIR community.' 'New Public address space assignment must be requested by Service Providers and IPX Providers from the appropriate LIR/NIR/DR using existing procedures supported by its respective serving RIR. This document can be used as part of the request submitted by the Service Provider as a source of reference to help explain the requirement for Public address space.' Perhaps there are other such networks which work in the same way? Perhaps there should be a mechanism to record or report that resources are in use elsewhere and so should not be recovered? Mike -----Original Message----- From: address-policy-wg <address-policy-wg-bounces@ripe.net> On Behalf Of Marco Schmidt Sent: Thursday, June 8, 2023 2:31 PM To: address-policy-wg@ripe.net Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management Dear colleagues, At RIPE 86, we shared some observations regarding Autonomous System Number (ASN) requests and usage [1]. We see an increasing number of ASN requests coming from both inside and outside of our service region. This seems to be driven primarily by the low cost and ease of receiving an ASN from the RIPE NCC. The downside is that we also see a significant decrease in responsible resource management by these resource holders. A large number of ASNs are never used or become abandoned after a short period. Some data: in the last two years, we have provided 4,186 ASNs (between March 2021 and February 2023). Of this amount, we can see that 1,478 ASNs (more than 35%) do not appear to be in use, as they are not visible in the routing system. Looking at total numbers, we have issued almost 38,000 ASNs, of which more than 8,000 (~20%) are not visible. This growing trend not only creates avoidable work for Registration Services and added costs for the membership, we believe it also undermines the goal of responsible management of Internet number resources within our service region. As the membership voted against an annual service fee for ASNs at the recent RIPE NCC General Meeting, I would like to ask the working group for guidance on how resource holders can be motivated to manage their ASNs responsibly and how the RIPE NCC can provide support for this. We also plan to intensify our ongoing project to clean up unused Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have been recovered as part of this work so far. Do you support our approach here? And are there other ways we could improve the situation? Perhaps you could add clarification on requesting and returning ASNs in the relevant RIPE policy, or maybe we could give a stronger mandate and responsibility to the sponsoring LIRs. If you have an ASN registered to you that you don’t need anymore, you can always contact us through the LIR Portal or via your sponsoring LIR and we will arrange for the return of this resource. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] https://ripe86.ripe.net/wp-content/uploads/presentations/82-RIPE86-Feeback-f... [2] https://www.ripe.net/manage-ips-and-asns/as-numbers/as-number-clean-up -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
Hi Mike, Are these setups still multihome? Regardsm Arash Naderpour On Thu, Jun 22, 2023 at 12:12 PM Mike Bromwich <mike.bromwich@stacuity.com> wrote:
Hi,
One other aspect to consider - there are situations where public ASNs (and addresses) are required - but not directly connected to the Internet. Therefore, they do not appear in the Internet routing tables but are legitimately used elsewhere.
For example, in our field (mobile cellular networks) mobile operators are connected using the IPX network as managed by the GSMA. This is distinct from the Internet but public ASNs and addresses are required.
The relevant guidelines from the GSMA: https://www.gsma.com/newsroom/wp-content/uploads/IR.40-v8.0.pdf
'The GSMA worked closely with the all the RIR communities (RIPE NCC, ARIN and APNIC) to develop and produce the early versions of this document. This was essential to ensure that the proposed guidelines to the Service Providers associated with requesting and implementing Public addresses are aligned with the existing policies and procedures of the RIR community.'
'New Public address space assignment must be requested by Service Providers and IPX Providers from the appropriate LIR/NIR/DR using existing procedures supported by its respective serving RIR.
This document can be used as part of the request submitted by the Service Provider as a source of reference to help explain the requirement for Public address space.'
Perhaps there are other such networks which work in the same way? Perhaps there should be a mechanism to record or report that resources are in use elsewhere and so should not be recovered?
Mike
-----Original Message----- From: address-policy-wg <address-policy-wg-bounces@ripe.net> On Behalf Of Marco Schmidt Sent: Thursday, June 8, 2023 2:31 PM To: address-policy-wg@ripe.net Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management
Dear colleagues,
At RIPE 86, we shared some observations regarding Autonomous System Number (ASN) requests and usage [1].
We see an increasing number of ASN requests coming from both inside and outside of our service region. This seems to be driven primarily by the low cost and ease of receiving an ASN from the RIPE NCC. The downside is that we also see a significant decrease in responsible resource management by these resource holders. A large number of ASNs are never used or become abandoned after a short period.
Some data: in the last two years, we have provided 4,186 ASNs (between March 2021 and February 2023). Of this amount, we can see that 1,478 ASNs (more than 35%) do not appear to be in use, as they are not visible in the routing system.
Looking at total numbers, we have issued almost 38,000 ASNs, of which more than 8,000 (~20%) are not visible.
This growing trend not only creates avoidable work for Registration Services and added costs for the membership, we believe it also undermines the goal of responsible management of Internet number resources within our service region.
As the membership voted against an annual service fee for ASNs at the recent RIPE NCC General Meeting, I would like to ask the working group for guidance on how resource holders can be motivated to manage their ASNs responsibly and how the RIPE NCC can provide support for this.
We also plan to intensify our ongoing project to clean up unused Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have been recovered as part of this work so far. Do you support our approach here? And are there other ways we could improve the situation? Perhaps you could add clarification on requesting and returning ASNs in the relevant RIPE policy, or maybe we could give a stronger mandate and responsibility to the sponsoring LIRs.
If you have an ASN registered to you that you don’t need anymore, you can always contact us through the LIR Portal or via your sponsoring LIR and we will arrange for the return of this resource.
Kind regards,
Marco Schmidt Manager Registration Services RIPE NCC
[1]
https://ripe86.ripe.net/wp-content/uploads/presentations/82-RIPE86-Feeback-f...
[2] https://www.ripe.net/manage-ips-and-asns/as-numbers/as-number-clean-up
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg --
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
Hi Arash, Yes, mobile operators will typically be multi-homed and use a number of IPX providers. Mike From: Arash Naderpour <arash_mpc@parsun.com> Sent: Thursday, June 22, 2023 12:21 PM To: Mike Bromwich <mike.bromwich@stacuity.com> Cc: Marco Schmidt <mschmidt@ripe.net>; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management Hi Mike, Are these setups still multihome? Regardsm Arash Naderpour On Thu, Jun 22, 2023 at 12:12 PM Mike Bromwich <mike.bromwich@stacuity.com<mailto:mike.bromwich@stacuity.com>> wrote: Hi, One other aspect to consider - there are situations where public ASNs (and addresses) are required - but not directly connected to the Internet. Therefore, they do not appear in the Internet routing tables but are legitimately used elsewhere. For example, in our field (mobile cellular networks) mobile operators are connected using the IPX network as managed by the GSMA. This is distinct from the Internet but public ASNs and addresses are required. The relevant guidelines from the GSMA: https://www.gsma.com/newsroom/wp-content/uploads/IR.40-v8.0.pdf 'The GSMA worked closely with the all the RIR communities (RIPE NCC, ARIN and APNIC) to develop and produce the early versions of this document. This was essential to ensure that the proposed guidelines to the Service Providers associated with requesting and implementing Public addresses are aligned with the existing policies and procedures of the RIR community.' 'New Public address space assignment must be requested by Service Providers and IPX Providers from the appropriate LIR/NIR/DR using existing procedures supported by its respective serving RIR. This document can be used as part of the request submitted by the Service Provider as a source of reference to help explain the requirement for Public address space.' Perhaps there are other such networks which work in the same way? Perhaps there should be a mechanism to record or report that resources are in use elsewhere and so should not be recovered? Mike -----Original Message----- From: address-policy-wg <address-policy-wg-bounces@ripe.net<mailto:address-policy-wg-bounces@ripe.net>> On Behalf Of Marco Schmidt Sent: Thursday, June 8, 2023 2:31 PM To: address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net> Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management Dear colleagues, At RIPE 86, we shared some observations regarding Autonomous System Number (ASN) requests and usage [1]. We see an increasing number of ASN requests coming from both inside and outside of our service region. This seems to be driven primarily by the low cost and ease of receiving an ASN from the RIPE NCC. The downside is that we also see a significant decrease in responsible resource management by these resource holders. A large number of ASNs are never used or become abandoned after a short period. Some data: in the last two years, we have provided 4,186 ASNs (between March 2021 and February 2023). Of this amount, we can see that 1,478 ASNs (more than 35%) do not appear to be in use, as they are not visible in the routing system. Looking at total numbers, we have issued almost 38,000 ASNs, of which more than 8,000 (~20%) are not visible. This growing trend not only creates avoidable work for Registration Services and added costs for the membership, we believe it also undermines the goal of responsible management of Internet number resources within our service region. As the membership voted against an annual service fee for ASNs at the recent RIPE NCC General Meeting, I would like to ask the working group for guidance on how resource holders can be motivated to manage their ASNs responsibly and how the RIPE NCC can provide support for this. We also plan to intensify our ongoing project to clean up unused Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have been recovered as part of this work so far. Do you support our approach here? And are there other ways we could improve the situation? Perhaps you could add clarification on requesting and returning ASNs in the relevant RIPE policy, or maybe we could give a stronger mandate and responsibility to the sponsoring LIRs. If you have an ASN registered to you that you don’t need anymore, you can always contact us through the LIR Portal or via your sponsoring LIR and we will arrange for the return of this resource. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] https://ripe86.ripe.net/wp-content/uploads/presentations/82-RIPE86-Feeback-f... [2] https://www.ripe.net/manage-ips-and-asns/as-numbers/as-number-clean-up -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
participants (12)
-
Aleksi Suhonen -
Arash Naderpour -
Cynthia Revström -
Elvis Daniel Velea -
Gert Doering -
Kaj Niemi -
Leo Vegoda -
Marco Schmidt -
Mike Bromwich -
Nick Hilliard -
Patrick Velder -
Sander Steffann