[j-nsp] Summarize Global Table

[Shane Amante]

Chris,

On Oct 26, 2011, at 7:21 AM, Chris Morrow wrote:
> On 10/26/2011 12:10 AM, Shane Amante wrote:
>> With respect to S-VA, it appears you would need to play games with
>> carrying either a default route or less specifics (aggregates) with
>> NO_EXPORT, etc. around your network and having the potential to
>> accidentally leak them beyond your network.  However, what's more
>> concerning is clearly some prefixes (more specifics) are going to be
>> responsible for carrying *a lot* of traffic, (think: popular CDN's,
>> portals, etc.), which you want to ensure are optimally routed.  The
> 
> in any case that you remove some of 'all the data' the routing table,
> more stretch for some prefixes is introduced, right? So this isn't
> particularly unexpected.

All depends on how aggressive one gets in terms of calculating an optimal FIB, namely if/when you introduce artificial, covering aggregates, then yes you would end-up introducing stretch.  If you go to the extreme end of "Hey, just announce default to my Edge router" approach, then clearly you need to bounce through a full-FIB box to get anywhere, including just to get from one PE to a 2nd PE in the same POP.  OTOH, if you're just compressing the RIB and, in doing so, ensuring existing natural or even artifical covering aggregates share the same next-hop as the contributing more-specifics, (or you leak those exceptional more specifics into the FIB), then you're not introducing stretch.


>> problem is, AFAICT, S-VA makes you identify _and_ maintain those
>> 'popular prefixes' on your own to ensure that you optimally route
>> them.  In theory, one might use Netflow to periodically determine and
> 
> sure, same for all instances of the 'remove some routing data' solutions.

Again, not necessarily.  See above.


>> adjust the list of "popular prefixes", but what happens when you
>> experience a sudden influx of traffic?  How fast are you going to be
>> able to react?
> 
> the real trick, as you highlight, is to figure out a method to identify
> and maintain and TE (properly) prefixes which are hot at some point in time.

Sure, but this only comes into play when you want to go beyond "natural" aggregation/compression.


> One argument is that sloshing some traffic on less optimal paths which
> are not overloaded isn't really bad, it may even be less costly to
> upgrade the links than to run around upgrading fib/rib/cpus on aging
> hardware, right?

Potentially, yes.

-shane