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

On Sun, Mar 26, 2017 at 6:46 PM, Kai 'wusel' Siering <wusel+ml at uu.org>
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:farmer at umn.edu
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
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20170326/0d395b5c/attachment.html>