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?
>
As explained above, all thoses cases involves routing policy "external"
to the organisation using the AS using the "hidden" ASn.
--
Radu-Adrian FEURDEAN
