Hi, Requiring an ASN to be visible on the public Internet is a non-starter IMHO.
There are many instances of inter-provider EBGP that are non-public, where private ASNs are not appropriate. For example, more than one of the providers uses one or more private ASNs internally that clash with each other. Global identifiers are the usual approach for this situation, and I see no reason to change that. The same situation applies to the use of public IP address resources in inter-provider scenarios, such as L3VPNs, and has had no problem with justification to acquire or retain those resources – ASNs should be no different. Fundamentally, please don’t mix up lack of public visibility meaning either lack of need or purely internal use, because it’s an overreach. Ian From: address-policy-wg [mailto:[email protected]] On Behalf Of Kai 'wusel' Siering Sent: 24 March 2017 01:33 To: [email protected] Subject: Re: [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. 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 Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
