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

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