why not AS number based prefixes aggregation

Dave Israel davei at otd.com
Mon Sep 8 16:20:58 UTC 2008


If I understand you right, what you're suggesting is that, in place of a
MED or a localpref, I deploy a layer 2 filter on all of my devices for
every prefix I want to touch the policy for at a level more granular
than AS.  This does not improve the scalability of BGP, it destroys that
scalability and merely trades hardware capacity used for routing updates
for capacity used for manual filters.

At any rate, you cannot aggregate somebody else's announcements.  Doing
so destroys policy information (like more specific announcements, MEDs,
and communities) and creates implementation nightmares (like handling
route withdrawls.) 

yangyang. wang wrote:
> Thank you, Scott.
> TE is a key reason for using specific prefixes. I think that most TEs are
> deployed in intra-domain, and the inter-domain TEs applied to downstream AS
> multihomed to many different upstream ASes could be made thru AS number
> based aggregation. The TE between two ASes with many links (for load
> balance) may be implemented by layer-2 filter list staticly configured.
>
> 2008/9/8 Scott Brim <swb at employees.org>
>
>   
>> Excerpts from yangyang. wang on Mon, Sep 08, 2008 09:20:38PM +0800:
>>     
>>> Hi, everyone:
>>>
>>>      For routing scalability issues, I have a question: why not deploy AS
>>> number based routing scheme?  BGP is path vector protocol and the
>>>       
>> shortest
>>     
>>> paths are calculated based on traversed AS numbers. The prefixes in the
>>>       
>> same
>>     
>>> AS almost have the same AS_PATH associated, and aggregating prefixes
>>> according to AS will shrink BGP routing table significantly. I don't know
>>> what comments the ISPs make on this kind of routing scheme.
>>>
>>>
>>> -yang
>>>       
>> It might be the right level of granularity for policy but is too
>> coarse for routing.  You want to be able to route on prefixes (even if
>> not everyone does it) for flexibility/TE.  Also, ASNs are not
>> aggregatable so we can't use them to represent a large number of
>> independently routed networks.
>>
>>
>>     




More information about the NANOG mailing list