On Sun, Mar 26, 2017 at 6:46 PM, Kai 'wusel' Siering <[email protected]> wrote:
> 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 > > > > -- =============================================== David Farmer Email:[email protected] 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 ===============================================
