On Fri, Mar 24, 2017, at 03:32, Kai 'wusel' Siering wrote:
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.
What do you call "public". There are a number of cases where inter-AS interconnection is required and still it's not visible to the outside world:
- Virtual mobile operators (Full-MVNO) : you usually have to interconnect (IP-wise) with one or several "home radio networks", one or more "roaming brokers" and eventually with some other entities of the eco-system
- "PPP Collect" : for operators that do not have an full national deployment, it is possible to purchase wholesale DSL links delivered "over L2TP over IP". In this case you have an e-BGP connection with the local-loop operator : you announce your LNS(-es) and RADIUS server(s) and tey announce thei LAC(s) and RADIUS proxy(es). Who we even have the same story for plain IPoE.
- Some private cloud interconnections are not publically visible and do not follow the rules for "regular interconnections" (may accept private IP space and max prefix length may go up to /32 in v4)
Some other cases exist as well.
In all the above cases you have eBGP sessions that exchange prefixes that in IPv4 may go up to /32 ("PPP Collect" and "IPoE Collect" we receive and have to announce almost exclusively /32 - yes that's each v4 address individually announced).
Useless to say that when you have several such interconnections using private ASNs things become a mess quite quickly.
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?