From mschmidt at ripe.net Thu Jun 8 15:30:52 2023 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 8 Jun 2023 15:30:52 +0200 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management Message-ID: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> 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-from-RS-reviewed.pdf [2] https://www.ripe.net/manage-ips-and-asns/as-numbers/as-number-clean-up From ripe-ml-2023 at ssd.axu.tm Thu Jun 8 16:11:01 2023 From: ripe-ml-2023 at ssd.axu.tm (Aleksi Suhonen) Date: Thu, 8 Jun 2023 17:11:01 +0300 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> Message-ID: 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. > 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 From leo at vegoda.org Thu Jun 8 16:15:55 2023 From: leo at vegoda.org (Leo Vegoda) Date: Thu, 8 Jun 2023 07:15:55 -0700 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> Message-ID: Hi, On Thu, 8 Jun 2023 at 07:11, Aleksi Suhonen 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) From nick at foobar.org Thu Jun 8 16:55:12 2023 From: nick at foobar.org (Nick Hilliard) Date: Thu, 8 Jun 2023 15:55:12 +0100 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> Message-ID: 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 From kajtzu at a51.org Thu Jun 8 17:14:14 2023 From: kajtzu at a51.org (Kaj Niemi) Date: Thu, 8 Jun 2023 15:14:14 +0000 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> Message-ID: 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 on behalf of Nick Hilliard Sent: Thursday, June 8, 2023 5:55 PM To: Marco Schmidt Cc: address-policy-wg at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Fri Jun 9 10:24:54 2023 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 9 Jun 2023 10:24:54 +0200 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> Message-ID: <6e50e208-dc92-97b2-d1e4-f4d4ff4a8165@ripe.net> 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 From elvis at v4escrow.net Sun Jun 11 11:06:34 2023 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Sat, 10 Jun 2023 23:06:34 -1000 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: <6e50e208-dc92-97b2-d1e4-f4d4ff4a8165@ripe.net> References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> <6e50e208-dc92-97b2-d1e4-f4d4ff4a8165@ripe.net> Message-ID: 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Mon Jun 12 12:25:16 2023 From: nick at foobar.org (Nick Hilliard) Date: Mon, 12 Jun 2023 11:25:16 +0100 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> <6e50e208-dc92-97b2-d1e4-f4d4ff4a8165@ripe.net> Message-ID: <38d5a8a8-1679-f781-e412-6a756aacbe8c@foobar.org> 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 From gert at space.net Mon Jun 12 12:34:26 2023 From: gert at space.net (Gert Doering) Date: Mon, 12 Jun 2023 12:34:26 +0200 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: <38d5a8a8-1679-f781-e412-6a756aacbe8c@foobar.org> References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> <6e50e208-dc92-97b2-d1e4-f4d4ff4a8165@ripe.net> <38d5a8a8-1679-f781-e412-6a756aacbe8c@foobar.org> Message-ID: 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: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nick at foobar.org Mon Jun 12 12:41:06 2023 From: nick at foobar.org (Nick Hilliard) Date: Mon, 12 Jun 2023 11:41:06 +0100 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> <6e50e208-dc92-97b2-d1e4-f4d4ff4a8165@ripe.net> <38d5a8a8-1679-f781-e412-6a756aacbe8c@foobar.org> Message-ID: 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 From elvis at v4escrow.net Mon Jun 12 12:46:30 2023 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 12 Jun 2023 00:46:30 -1000 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: <38d5a8a8-1679-f781-e412-6a756aacbe8c@foobar.org> References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> <6e50e208-dc92-97b2-d1e4-f4d4ff4a8165@ripe.net> <38d5a8a8-1679-f781-e412-6a756aacbe8c@foobar.org> Message-ID: Hi Nick, On Mon, Jun 12, 2023 at 00:25 Nick Hilliard 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Jun 12 13:22:40 2023 From: gert at space.net (Gert Doering) Date: Mon, 12 Jun 2023 13:22:40 +0200 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> <6e50e208-dc92-97b2-d1e4-f4d4ff4a8165@ripe.net> <38d5a8a8-1679-f781-e412-6a756aacbe8c@foobar.org> Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From elvis at v4escrow.net Mon Jun 12 13:38:58 2023 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 12 Jun 2023 01:38:58 -1000 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> <6e50e208-dc92-97b2-d1e4-f4d4ff4a8165@ripe.net> <38d5a8a8-1679-f781-e412-6a756aacbe8c@foobar.org> Message-ID: 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Jun 12 13:46:53 2023 From: gert at space.net (Gert Doering) Date: Mon, 12 Jun 2023 13:46:53 +0200 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> <6e50e208-dc92-97b2-d1e4-f4d4ff4a8165@ripe.net> <38d5a8a8-1679-f781-e412-6a756aacbe8c@foobar.org> Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From elvis at v4escrow.net Mon Jun 12 13:55:51 2023 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 12 Jun 2023 01:55:51 -1000 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> <6e50e208-dc92-97b2-d1e4-f4d4ff4a8165@ripe.net> <38d5a8a8-1679-f781-e412-6a756aacbe8c@foobar.org> Message-ID: 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Mon Jun 12 14:13:19 2023 From: sander at steffann.nl (Sander Steffann) Date: Mon, 12 Jun 2023 14:13:19 +0200 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> Message-ID: <9B074262-F47A-477E-AEB7-64891DA94D36@steffann.nl> 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 From lists at velder.li Mon Jun 12 14:29:45 2023 From: lists at velder.li (Patrick Velder) Date: Mon, 12 Jun 2023 14:29:45 +0200 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> <6e50e208-dc92-97b2-d1e4-f4d4ff4a8165@ripe.net> <38d5a8a8-1679-f781-e412-6a756aacbe8c@foobar.org> Message-ID: <8343e3a1-b09b-9b31-eb41-68dbff596475@velder.li> 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 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at cynthia.re Mon Jun 12 15:07:21 2023 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Mon, 12 Jun 2023 15:07:21 +0200 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: <9B074262-F47A-477E-AEB7-64891DA94D36@steffann.nl> References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> <9B074262-F47A-477E-AEB7-64891DA94D36@steffann.nl> Message-ID: 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, 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Mon Jun 12 15:10:45 2023 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 12 Jun 2023 15:10:45 +0200 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> <6e50e208-dc92-97b2-d1e4-f4d4ff4a8165@ripe.net> <38d5a8a8-1679-f781-e412-6a756aacbe8c@foobar.org> Message-ID: 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/004977.html On 12/06/2023 12:46, Elvis Daniel Velea wrote: > Hi Nick, > > On Mon, Jun 12, 2023 at 00:25 Nick Hilliard 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at vegoda.org Tue Jun 13 15:36:39 2023 From: leo at vegoda.org (Leo Vegoda) Date: Tue, 13 Jun 2023 06:36:39 -0700 Subject: [address-policy-wg] 2023-01 (Reducing IXP IPv4 assignment default size to a /26) Message-ID: Dear WG, The Discussion Phase of policy proposal 2023-01 "Reducing IXP IPv4 assignment default size to a /26" has now ended. Many thanks to all for your comments. The proposal will now move forward to the Review Phase. The RIPE NCC will prepare an impact analysis and a draft RIPE Document. More details about the phases of the Policy development Process are published here: https://www.ripe.net/publications/docs/ripe-781 You'll also see an announcement from the RIPE NCC soon. Kind regards, Leo Vegoda for the co-chairs From leo at vegoda.org Tue Jun 13 15:36:40 2023 From: leo at vegoda.org (Leo Vegoda) Date: Tue, 13 Jun 2023 06:36:40 -0700 Subject: [address-policy-wg] 2023-02 (Minimum Size for IPv4 Temporary Assignments) Message-ID: Dear WG, The Review Phase of policy proposal 2023-02 "Minimum Size for IPv4 Temporary Assignments" has now ended. Many thanks to all for your comments. The proposal will now move forward to the Last Call for Comments Phase. More details about the phases of the Policy development Process are published here: https://www.ripe.net/publications/docs/ripe-781 You'll also see an announcement from the RIPE NCC soon. Kind regards, Leo Vegoda for the co-chairs From khung at ripe.net Wed Jun 14 10:06:51 2023 From: khung at ripe.net (Karen Hung) Date: Wed, 14 Jun 2023 10:06:51 +0200 Subject: [address-policy-wg] 2023-02 Last Call for Comments (Minimum Size for IPv4 Temporary Assignments) Message-ID: Dear colleagues, Proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments" is now in Concluding Phase. This policy proposal recommends setting the minimum assignment size to a /24 while still allowing for a smaller assignment if requested by the End User. This policy proposal also allows routing requirements to justify the request for more than a /24 for research purposes. The WG co-chairs have declared that rough consensus has been reached and the proposal will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of this four week Concluding Phase is to give an opportunity to present well-justified objections for those who missed the previous two phases and wish to oppose the proposal. Any objection must be made by 13 July 2023 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the WG co-chairs for final consensus. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-02 Please e-mail any final comments about this proposal to > before 13 July 2023. Kind regards, Karen Hung On behalf of Policy Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at vegoda.org Tue Jun 20 13:55:54 2023 From: leo at vegoda.org (Leo Vegoda) Date: Tue, 20 Jun 2023 04:55:54 -0700 Subject: [address-policy-wg] Draft Address Policy WG Minutes from RIPE 86 Message-ID: Dear WG, The RIPE NCC has now prepared draft minutes of our session at RIPE 86. You can find them on the website here: https://www.ripe.net/participate/ripe/wg/active-wg/ap/minutes/ripe-86-address-policy-working-group-minutes Please write to this list or inform the co-chairs of any issues or corrections. Kind regards, Leo Vegoda for the Address Policy WG co-chairs From mike.bromwich at stacuity.com Thu Jun 22 12:12:58 2023 From: mike.bromwich at stacuity.com (Mike Bromwich) Date: Thu, 22 Jun 2023 10:12:58 +0000 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> Message-ID: 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 On Behalf Of Marco Schmidt Sent: Thursday, June 8, 2023 2:31 PM To: address-policy-wg at 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-from-RS-reviewed.pdf [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 From arash_mpc at parsun.com Thu Jun 22 13:21:01 2023 From: arash_mpc at parsun.com (Arash Naderpour) Date: Thu, 22 Jun 2023 13:21:01 +0200 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> Message-ID: Hi Mike, Are these setups still multihome? Regardsm Arash Naderpour On Thu, Jun 22, 2023 at 12:12?PM Mike Bromwich 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 On Behalf Of > Marco Schmidt > Sent: Thursday, June 8, 2023 2:31 PM > To: address-policy-wg at 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-from-RS-reviewed.pdf > > [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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arturo.servin at google.com Thu Jun 22 13:33:20 2023 From: arturo.servin at google.com (Arturo Servin) Date: Thu, 22 Jun 2023 13:33:20 +0200 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> Message-ID: I cannot answer for Mike, but for those that I know, yes, those are multihomed. So there is a legitimate use of an ASN that there isn't in the Internet (you need a public one to guarantee uniqueness) Regarding the topic, I do not think that RIPE NCC needs to spend time trying to recover unseen (but not for sure unused) ASNs. Regards as On Thu, Jun 22, 2023 at 1:27?PM Arturo Servin wrote: > > I cannot answer for Mike, but for those that I know, yes, those are > multihomed. > > So there is a legitimate use of an ASN that there isn't in the Internet > (you need a public one to guarantee uniqueness) > > Regarding the topic, I do not think that RIPE NCC needs to spend time > trying to recover unseen (but not for sure unused) ASNs. > > Regards > as > > > On Thu, Jun 22, 2023 at 1:21?PM Arash Naderpour > wrote: > >> Hi Mike, >> >> Are these setups still multihome? >> >> Regardsm >> >> Arash Naderpour >> >> On Thu, Jun 22, 2023 at 12:12?PM Mike Bromwich < >> mike.bromwich at 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 On Behalf >>> Of Marco Schmidt >>> Sent: Thursday, June 8, 2023 2:31 PM >>> To: address-policy-wg at 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-from-RS-reviewed.pdf >>> >>> [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 >>> >> -- >> >> 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arash_mpc at parsun.com Thu Jun 22 16:07:52 2023 From: arash_mpc at parsun.com (Arash Naderpour) Date: Thu, 22 Jun 2023 16:07:52 +0200 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> Message-ID: It appears that we have two distinct types of ASN allocation: those that are publicly visible and those that remain unseen even when in use. To address this, I propose that the NCC introduces a new practice during ASN allocation. This practice would involve inquiring about the intended visibility of the allocated ASN. If a user claims that the ASN will be publicly visible but no visible activity is observed within a designated period (eg. 1 year), the NCC should initiate multiple reminders asking for confirmation of their plans to utilize the ASN in the future. In the event of no reply or confirmation, the process of deregistering the ASN can be initiated. This approach would help ensure that ASNs are allocated appropriately and promote responsible usage within the community. Regards, Arash On Thu, Jun 22, 2023 at 1:33?PM Arturo Servin via address-policy-wg < address-policy-wg at ripe.net> wrote: > I cannot answer for Mike, but for those that I know, yes, those are > multihomed. > > So there is a legitimate use of an ASN that there isn't in the Internet > (you need a public one to guarantee uniqueness) > > Regarding the topic, I do not think that RIPE NCC needs to spend time > trying to recover unseen (but not for sure unused) ASNs. > > Regards > as > > On Thu, Jun 22, 2023 at 1:27?PM Arturo Servin > wrote: > >> >> I cannot answer for Mike, but for those that I know, yes, those are >> multihomed. >> >> So there is a legitimate use of an ASN that there isn't in the Internet >> (you need a public one to guarantee uniqueness) >> >> Regarding the topic, I do not think that RIPE NCC needs to spend time >> trying to recover unseen (but not for sure unused) ASNs. >> >> Regards >> as >> >> >> On Thu, Jun 22, 2023 at 1:21?PM Arash Naderpour >> wrote: >> >>> Hi Mike, >>> >>> Are these setups still multihome? >>> >>> Regardsm >>> >>> Arash Naderpour >>> >>> On Thu, Jun 22, 2023 at 12:12?PM Mike Bromwich < >>> mike.bromwich at 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 On Behalf >>>> Of Marco Schmidt >>>> Sent: Thursday, June 8, 2023 2:31 PM >>>> To: address-policy-wg at 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-from-RS-reviewed.pdf >>>> >>>> [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 >>>> >>> -- >>> >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.bromwich at stacuity.com Thu Jun 22 19:18:08 2023 From: mike.bromwich at stacuity.com (Mike Bromwich) Date: Thu, 22 Jun 2023 17:18:08 +0000 Subject: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management In-Reply-To: References: <9e1b8f40-097b-29a9-1bde-e60de0aafd2f@ripe.net> Message-ID: Hi Arash, Yes, mobile operators will typically be multi-homed and use a number of IPX providers. Mike From: Arash Naderpour Sent: Thursday, June 22, 2023 12:21 PM To: Mike Bromwich Cc: Marco Schmidt ; address-policy-wg at 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 > 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 > On Behalf Of Marco Schmidt Sent: Thursday, June 8, 2023 2:31 PM To: address-policy-wg at 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-from-RS-reviewed.pdf [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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adallara at ripe.net Thu Jun 29 16:19:07 2023 From: adallara at ripe.net (Angela Dall'Ara) Date: Thu, 29 Jun 2023 16:19:07 +0200 Subject: [address-policy-wg] 2023-01 Review Phase (Reducing IXP IPv4 assignment default size to a /26) Message-ID: <68428441-8bd4-5fe8-496f-12755af4ad71@ripe.net> Dear colleagues, Policy proposal 2023-01, " Reducing IXP IPv4 assignment default size to a /26", is now in the Review Phase. This proposal modifies the default size of IPv4 assignments for IXPs from a /24 to /26 and clarifies the return of the assignments previously issued for their IXP peering LAN. The RIPE NCC has prepared an impact analysis on this proposal to support the community?s discussion. You can find the proposal and impact analysis at: _https://www.ripe.net/participate/policies/proposals/2023-01_ _https://www.ripe.net/participate/policies/proposals/2023-01#impact-analysis_ And the draft documents at: _https://www.ripe.net/participate/policies/proposals/2023-01/draft_ As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg at ripe.net before 28 July2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Thu Jun 29 22:54:42 2023 From: nick at foobar.org (Nick Hilliard) Date: Thu, 29 Jun 2023 21:54:42 +0100 Subject: [address-policy-wg] 2023-01 Review Phase (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <68428441-8bd4-5fe8-496f-12755af4ad71@ripe.net> References: <68428441-8bd4-5fe8-496f-12755af4ad71@ripe.net> Message-ID: <57f471ab-df73-a545-8005-5b7426fe22a3@foobar.org> Angela Dall'Ara wrote on 29/06/2023 15:19: > It is therefore important to provide your opinion, even if it is > simply a restatement of your input from the previous phase. this version of the document hasn't addressed the problems I raised on April 26. The authors need to give some consideration about what might be the best approach to fixing them: 1. problematic edge cases in section 5 due to the magic figure of 50% utilisation 2. what is a "special circumstance"? I don't believe that the document should progress until these issues are addressed. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Jun 29 23:20:35 2023 From: randy at psg.com (Randy Bush) Date: Thu, 29 Jun 2023 14:20:35 -0700 Subject: [address-policy-wg] 2023-01 Review Phase (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <57f471ab-df73-a545-8005-5b7426fe22a3@foobar.org> References: <68428441-8bd4-5fe8-496f-12755af4ad71@ripe.net> <57f471ab-df73-a545-8005-5b7426fe22a3@foobar.org> Message-ID: nick, > 2. what is a "special circumstance"? maybe "unforseen" would be better? from an old CII preso If it was part of the ?plan? it?s an event, if it is not then it?s a ?disaster? randy From me at cynthia.re Fri Jun 30 00:55:35 2023 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Fri, 30 Jun 2023 00:55:35 +0200 Subject: [address-policy-wg] 2023-01 Review Phase (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <57f471ab-df73-a545-8005-5b7426fe22a3@foobar.org> References: <68428441-8bd4-5fe8-496f-12755af4ad71@ripe.net> <57f471ab-df73-a545-8005-5b7426fe22a3@foobar.org> Message-ID: I agree with Nick here regarding 1. These magic numbers should really be fixed. -Cynthia On Thu, Jun 29, 2023 at 10:55?PM Nick Hilliard wrote: > > Angela Dall'Ara wrote on 29/06/2023 15:19: > > It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. > > > this version of the document hasn't addressed the problems I raised on April 26. The authors need to give some consideration about what might be the best approach to fixing them: > > 1. problematic edge cases in section 5 due to the magic figure of 50% utilisation > 2. what is a "special circumstance"? > > I don't believe that the document should progress until these issues are addressed. > > 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 From matthias.wichtlhuber at de-cix.net Fri Jun 30 11:58:12 2023 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Fri, 30 Jun 2023 09:58:12 +0000 Subject: [address-policy-wg] 2023-01 Review Phase (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <68428441-8bd4-5fe8-496f-12755af4ad71@ripe.net> <57f471ab-df73-a545-8005-5b7426fe22a3@foobar.org>, Message-ID: <59f1f1b386924ed6a1e43a698cad00c8@de-cix.net> Hi Nick, all, > 1. problematic edge cases in section 5 due to the magic figure of 50% utilisation > 2. what is a "special circumstance"? The proposal does not modify existing numbers (50%) or the "special circumstances". Both are in the current policy already (see old policy text 6.1 .4). I think the changes you propose should be done in a separate policy proposal as they are an addition to this policy proposal rather than a change. Nevertheless RIPE has clarified how they handle the 50% issue currently (see Marco Schmidt's mail from mid May): > When receiving requests for more than a /24, the RIPE NCC checks that > the IXP will need more than 50% of the assignment within one year. If > their growth rate is too slow and we expect that it will take more than > a year to exceed that utilisation threshold, we suggest that they > postpone their request. Thus, this issue is not urgent and can be discussed separately. I hope that answers open questions. Regards, Matthias -- Dr.-Ing. Matthias Wichtlhuber Team Lead Research and Development ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 141 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber at de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne ________________________________________ Von: address-policy-wg im Auftrag von Cynthia Revstr?m via address-policy-wg Gesendet: Freitag, 30. Juni 2023 00:55:35 An: Nick Hilliard Cc: RIPE Address Policy Working Group Betreff: Re: [address-policy-wg] 2023-01 Review Phase (Reducing IXP IPv4 assignment default size to a /26) I agree with Nick here regarding 1. These magic numbers should really be fixed. -Cynthia On Thu, Jun 29, 2023 at 10:55?PM Nick Hilliard wrote: > > Angela Dall'Ara wrote on 29/06/2023 15:19: > > It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. > > > this version of the document hasn't addressed the problems I raised on April 26. The authors need to give some consideration about what might be the best approach to fixing them: > > 1. problematic edge cases in section 5 due to the magic figure of 50% utilisation > 2. what is a "special circumstance"? > > I don't believe that the document should progress until these issues are addressed. > > 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 -- 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 From tore at fud.no Fri Jun 30 17:16:18 2023 From: tore at fud.no (Tore Anderson) Date: Fri, 30 Jun 2023 17:16:18 +0200 Subject: [address-policy-wg] 2023-01 Review Phase (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <59f1f1b386924ed6a1e43a698cad00c8@de-cix.net> References: <68428441-8bd4-5fe8-496f-12755af4ad71@ripe.net> <57f471ab-df73-a545-8005-5b7426fe22a3@foobar.org> , <59f1f1b386924ed6a1e43a698cad00c8@de-cix.net> Message-ID: * Matthias Wichtlhuber > Hi Nick, all, > > > 1. problematic edge cases in section 5 due to the magic figure of 50% utilisation > > 2. what is a "special circumstance"? > > The proposal does not modify existing numbers (50%) or the "special circumstances". Both are in the current policy already (see old policy text 6.1 .4). I think the changes you propose should be done in a separate policy proposal as they are an addition to this policy proposal rather than a change. > > Nevertheless RIPE has clarified how they handle the 50% issue currently (see Marco Schmidt's mail from mid May): > > > When receiving requests for more than a /24, the RIPE NCC checks that > > the IXP will need more than 50% of the assignment within one year. If > > their growth rate is too slow and we expect that it will take more than > > a year to exceed that utilisation threshold, we suggest that they > > postpone their request. > > Thus, this issue is not urgent and can be discussed separately. I hope that answers open questions. I agree with Matthias here. Since 2023-01 does not introduce the language Nick points to I find it unreasonable to demand that this proposal should also fix any issues in that language (if they are indeed in need of fixing). This proposal aims to solve a different problem, after all, so fixing other issues is not in scope. I see no surprises in the Impact Analysis, so I reiterate my support for moving 2023-01 forward. Tore