[address-policy-wg] Cleaning up Unused AS Numbers

Moin,

am 23.03.2017 um 19:34 schrieb Martin Huněk:
> Let say that, end user (MNT) would be able to indicate that ASN should be hidden from the BGP and provide remarks for a reason (IXP or whatever) - mandatory.

Sorry, but as a public ASN is to serve public inter-AS-uses, why even think about private usage of a public resource? If you use a public AS internally only, you should switch to a private AS.


Am 23.03.2017 um 18:26 schrieb Hank Nussbacher:
> On 23/03/2017 14:18, Laurens Hoogendoorn wrote:
>> Our Proposal
>> […]
>>
> Very often, companies get bought or merge and then get bought out again.
> A company that received an ASN 15 years ago and hasn't updated their whois and isn't announcing the ASN will be difficult to track down.
Well, so what? If the ASN isn't used where it counts, why should it stay assigned to an organization that clearly doesn't care at all (or, for that matter, exists)?


Am 23.03.2017 um 13:18 schrieb Laurens Hoogendoorn:
> There are a number of legitimate reasons why an ASN might not be advertised in the routing system.

Care to list at least a few? https://www.ripe.net/publications/docs/ripe-679 looks rather straightforward — and against hidden usage of assigned ASNs?

>
>       2.0 Assignment Criteria
>
> In order to help decrease global routing complexity, a new AS Number should be used only if a new external routing policy is required, see RFC1930 <ftp://ftp.ripe.net/rfc/rfc1930.txt>.
>
> A network must be multihomed in order to qualify for an AS Number.
>
> When requesting an AS Number the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database.
>

So, you need a "new" *external* routing policy to receive a (public) ASN. If your ASN does not show up in the global routing anymore, you obviously lost the need for that '"new" *external* routing policy', no?

While I don't see any need to reclaim "virtually unused" ASNs since the protocol got extended to 32 bits, I don't see why there should be any fuzz about those ASNs not seen in the public routing tables either. Define January 1st and July 1st of each year as checkpoint dates, if an ASN isn't present in global routing of IPv4 and IPv6 on two consecutive checkpoint dates, it's scheduled for unassignment after the next checkpoint date. Send out appropriate information based on whois data *once*, put the AS on a red list on the RIPE website for these six months. No reaction: it's free to go, end of story.

Regards,
-kai

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20170324/673bbd5c/attachment.html>