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. 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). Technically I don't see how RIPE NCC can possibly find all the ASes that are originated but invisible to the public route server. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net
-----Original Message----- From: Vladimir A. Jakovenko [mailto:vovik@lucky.net] Sent: Tuesday, July 09, 2002 3:26 PM To: Lu, Ping Cc: 'wtremmel@vianetworks.com'; 'Matthew Robinson'; Wilfried Woeber, UniVie/ACOnet; lir-wg@ripe.net Subject: Re: [lir-wg] AS Number Policy
On Tue, Jul 09, 2002 at 02:01:26PM -0400, Lu, Ping wrote:
This has nothing to do with the private AS-number.
If an AS number existed in our backbone (public to CW) but not to RIPE NCC's route server. Will that be considered NOT USED ?
Could you possibly provide us with more examples in which circumstances someone may need to use AS number from the PUBLIC range instead of using AS number from PRIVATE range in the case when there is no need to advertise any prefixes originated by such AS-number to the PUBLIC Internet (i.e. this AS number will never be visible outside of some private network)?
I can remind only one case - some kind of IX, are used by some ASes to exchange routing information localy. Generaly speaking IX-AS may not be visible from PUBLIC, but in the most cases, especialy if we are talking about enterprise networks, same results may be achieved by using AS-number from private range.
By way of proof - AS15645 is used for the public Ukrainian Internet-Exchange. Appearance of any prefixes originated by this AS outside of IX members networks violates IX rules and should be avoided.
Lets summarise - there ARE circumstances when AS number from PUBLIC range may be requested and used being invisible from the majority of the Internet.
It would be nice to mention that in policy and provide some examples.
-- Regards, Vladimir.
On Tue, Jul 09, 2002 at 03:57:49PM -0400, Lu, Ping 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.
What is the reason (or advantage) in using AS numbers from PUBLIC pool for confederate ASes, if they are not visible outside of confederation?
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).
Again - what is the reason in using AS numbers from PUBLIC pool for customer's ASes if this ASes will never appear outside of upstream ISP network? I may imagine only one case - customer's AS peering with public IX.
Technically I don't see how RIPE NCC can possibly find all the ASes that are originated but invisible to the public route server.
Agree. But there are also administrative possibilites. -- Regards, Vladimir.
On Tue, 9 Jul 2002, Lu, Ping 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. 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).
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 think if RIPE contacts an AS and says they are not multihomed and the AS can prove they are via some unknown LG or route server to some small local IXP that RIPE doesn't monitor - I say RIPE should record it as multihomed and close the ticket. -Hank
Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net
-----Original Message----- From: Vladimir A. Jakovenko [mailto:vovik@lucky.net] Sent: Tuesday, July 09, 2002 3:26 PM To: Lu, Ping Cc: 'wtremmel@vianetworks.com'; 'Matthew Robinson'; Wilfried Woeber, UniVie/ACOnet; lir-wg@ripe.net Subject: Re: [lir-wg] AS Number Policy
On Tue, Jul 09, 2002 at 02:01:26PM -0400, Lu, Ping wrote:
This has nothing to do with the private AS-number.
If an AS number existed in our backbone (public to CW) but not to RIPE NCC's route server. Will that be considered NOT USED ?
Could you possibly provide us with more examples in which circumstances someone may need to use AS number from the PUBLIC range instead of using AS number from PRIVATE range in the case when there is no need to advertise any prefixes originated by such AS-number to the PUBLIC Internet (i.e. this AS number will never be visible outside of some private network)?
I can remind only one case - some kind of IX, are used by some ASes to exchange routing information localy. Generaly speaking IX-AS may not be visible from PUBLIC, but in the most cases, especialy if we are talking about enterprise networks, same results may be achieved by using AS-number from private range.
By way of proof - AS15645 is used for the public Ukrainian Internet-Exchange. Appearance of any prefixes originated by this AS outside of IX members networks violates IX rules and should be avoided.
Lets summarise - there ARE circumstances when AS number from PUBLIC range may be requested and used being invisible from the majority of the Internet.
It would be nice to mention that in policy and provide some examples.
-- Regards, Vladimir.
Hank Nussbacher
--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).
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 -
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 -------------------------------------------------------
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.
Yes, but this still makes the AS publicly visible. Best regards, - kurtis -
On Thu, 11 Jul 2002, Kurt Erik Lindqvist wrote:
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.
Yes, but this still makes the AS publicly visible.
No, it does not, IF the transit decides to aggregate the larger block that the customer uses adresspace in, and just announce this larger block for the sake of not polluting the global routing-table, the customer-as will not be visible in the Internet, just in lookingglasses via the transit and the customers peeringpartners lookingglasses.
Best regards,
- kurtis -
-- Regards /Fredrik ------------------------------------------------------- KTHNOC, KTH, S-100 44 Stockholm, Sweden +46 8 790 65 17 -------------------------------------------------------
No, it does not, IF the transit decides to aggregate the larger block that the customer uses adresspace in, and just announce this larger block for the sake of not polluting the global routing-table, the customer-as will not be visible in the Internet, just in lookingglasses via the transit and the customers peeringpartners lookingglasses.
Which again brings us to what is considred public..:) - kurtis -
participants (5)
-
Fredrik Widell -
Hank Nussbacher -
Kurt Erik Lindqvist -
Lu, Ping -
Vladimir A. Jakovenko