[j-nsp] Summarize Global Table

[Shane Amante]

Hi Mark,

On Oct 25, 2011, at 8:09 PM, Mark Tinka wrote:
> On Wednesday, October 26, 2011 05:12:09 AM Richard A 
> Steenbergen wrote:
> 
>> c) Vendors would much rather sell you new cards wih more
>> FIB capacity than find a way to implement a "free"
>> solution in software (big shocker, I know). :)
> 
> I've been chatting with a major vendor about their interest 
> in implementing S-VA:
> 
> http://tools.ietf.org/html/draft-ietf-grow-simple-va-04
> 
> 
> There may be hope yet.

IMHO, the following draft is much more beneficial:
http://tools.ietf.org/html/draft-uzmi-smalta-01

SMALTA can be implemented completely local to a one router, several routers or all routers -- the whole point is that:
   i)  the SMALTA algorithm is supposed to be designed to ensure FIB correctness, at all times, without any neighbors knowing.
   i)  to say it again: there are no protocol changes or configuration changes to existing protocols -- although, arguably, you may want knobs from your vendor(s) to tweak the interval at which the "one-shot aggregation" occurs.  Most of the time, SMALTA attempts to use the least CPU time in order to calculate an 'optimal' version of the FIB every time it sees UPDATE's & WITHDRAW's in the RIB.  Over time, this results in a FIB that deviates anywhere from a few % to, perhaps, 20% of what you could optimally achieve (based on theoretical modeling by the draft's authors), which is why you want it to periodically run "one-shot aggregation", to get back to the most optimal version of the FIB.  IMO, it sure would be nice to have a prototype implementation of SMALTA to stick in an actual network and see how well theory holds up to practice.  :-)

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

-shane