<div dir="ltr"> </div><div class="gmail_extra"> <div class="gmail_quote">On Sun, Mar 26, 2017 at 6:46 PM, Kai 'wusel' Siering <<a href="mailto:wusel+ml@uu.org" target="_blank">wusel+ml@uu.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 26.03.2017 um 22:20 schrieb Daniel Roesen: > On Fri, Mar 24, 2017 at 02:32:35AM +0100, Kai 'wusel' Siering wrote: > >> Sorry, but as a public ASN is to serve public inter-AS-uses, > Can you cite the policy requiring that? RFC 1930, referenced by ripe-679, states: "10. The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): 64512 through 65535". Together with "9. AS Space exhaustion" it disencourages the use of public AS numbers for non-public use. And there is ripe-679' requirement of multihoming. >> So, you need a "new" *external* routing policy to receive a (public) ASN. > Yes. You seem to mistake "external" with "on the public Internet". "External" in BGP context is "with other ASN", that's it - not more, not less. Maybe I do, if so, most likely because of the connection initially drawn, "There are currently around 6,600 ASNs in our service region (held or sponsored by 2,682 LIRs) that are not being advertised in the routing system. This represents around 22% of the ~30,000 ASNs assigned by the RIPE NCC" as well as due to the reference to RFC 1930 in ripe-679. >> If your ASN does not show up in the global routing anymore, you obviously lost the need for that '"new" *external* routing policy', no? > No. Best regards, Daniel So, if a connection between "ASN received" and "ASN visible" does not exist, where's the case for this wg? RIPE NCC can carry out a db-based clean up on their own: keeping registration data up-to-date is already a requirement for resource holders (ripe-637). To be more elaborate (quoting the initial mail): > Our Proposal > > We plan to email the LIR or sponsoring LIR for each unannounced ASN and ask if the resource is still needed. […] > > We will ask if the ASN is currently being used or if there are plans to start using the ASN in the coming three months. […] Answer a: "um, yes?". Answer b: "definitely no". As investigating to answer b in good faith is always more expensive than to just state a, and since without the need for public visibility there's no means to control the usage: what's the point? > If we do not receive a reply or if the ASN will not be used within three months, we will start the process of returning the ASN to the free pool. The deregistration process will take three months, during which time the LIR can still indicate that the ASN is needed. If the ASN is still needed, the validity of the assignment (such as the multihoming requirement) will not be re-evaluated. What's the calculated gain, what's the overall benefit, given the limited control (see above)? It's fine that the process is automated on RIPE NCC's end, but LIRs will face additional work. With now 32 bits at hand for AS numbers, what's the operational benefit for the RIPE community as a whole if all "invisible" 6,6k ASNs would be returned after this effort? Especially as RFC 4893 is celebrating it's 10th birthday in a few weeks? Regards, -kai </blockquote></div> <div> </div>-- <div class="gmail_signature" data-smartmail="gmail_signature">=============================================== David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== </div> </div>