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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp