|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: why not AS number based prefixes aggregation
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 <[email protected]> > > >> 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. >> >> >>
|