On Thu, 11 Jul 2002, Kurt Erik Lindqvist wrote:
--On Tuesday, July 09, 2002 15:57:49 -0400 "Lu, Ping" <PLu@cw.net> wrote:
Several examples:
1. Confederate AS : only the top level AS number is announced by design, all member ASes should not be visible outside the confederate.
Which by desing should be done with private as:es. It's more or less in the instruction book.
2. CIDR aggregate : If customer's address got aggregated by upstream ISP, usually you won't see their AS numbers from the upstream ISP's CIDR (especially for those people like to filter on allocation boundary).
I am lost. If customer routes are aggregated by upstream, I assume the customer don't have an AS? If the customer have an AS and is multihomed you might aggregate his addresses, but you will still see the originating AS in the AS-path (or through the other path - as the customer won't get an AS unless he is multihomed).
A customer can have a peer with the default transit, which aggregates the adresspace from the customer, and the customer can have other peerings via some ix:es, and the customer could perform transit to/from the ix:es to the default transit, in this scenario the customer MUST have a public AS, which you will not see in the public space, since removing private AS in the AS-path will result in somewhat unpredictable behaviour if there are several private AS involved at the customer premises.
Technically I don't see how RIPE NCC can possibly find all the ASes that are originated but invisible to the public route server.
I can't see how people should/could/would need AS:es from the public space that is not visible in the public space.
- kurtis -
-- Mvh /Fredrik ------------------------------------------------------- KTHNOC, KTH, S-100 44 Stockholm, Sweden +46 8 790 65 17 -------------------------------------------------------