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).
...
Regards,
-kai