[lir-wg] AS Number Policy

See the inline comment.

Ping Lu
Cable & Wireless USA
Network Tools and Analysis Group
W: +1-703-292-2359
E: plu at cw.net



> -----Original Message-----
> From: Vladimir A. Jakovenko [mailto:vovik at lucky.net]
> Sent: Tuesday, July 09, 2002 4:16 PM
> To: Lu, Ping
> Cc: 'wtremmel at vianetworks.com'; 'Matthew Robinson'; Wilfried 
> Woeber, UniVie/ACOnet; lir-wg at ripe.net
> Subject: Re: [lir-wg] AS Number Policy
> 
> 
> 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? 
> 

Why do you think confederate AS should belong to the same company ?
And you can force one of them to use private AS ?

> >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?
> 

Huh ? RIPE NCC always recommends that the end user should use PA address
from the upstream ISP so only
the less specific CIDR (with ISP's AS number) will appear in the GLOBAL
routing table and the more specific prefixes
(with end user's AS number) WON'T POLLUTE the GLOBAL routing table.Now in
order to show their assigned AS 
numbers, end user will have to POLLUTE the GLOBAL routing table with their
more specific prefixes. 

> I may imagine only one case - customer's AS peering with public IX.
> 

Yes, IX is another example that AS is originated but not visible in the
GLOBAL routing table.


> >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.
>