[address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management

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 <arturolev at google.com> 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 <arash_mpc at parsun.com>
> 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 <address-policy-wg-bounces at ripe.net> 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://mailman.ripe.net/
>>> --
>>>
>>> To unsubscribe from this mailing list, get a password reminder, or
>>> change your subscription options, please visit:
>>> https://mailman.ripe.net/
>>>
>> --
>>
>> To unsubscribe from this mailing list, get a password reminder, or change
>> your subscription options, please visit:
>> https://mailman.ripe.net/
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20230622/1d336d18/attachment.html>