[j-nsp] Summarize Global Table

[Richard A Steenbergen]

On Tue, Oct 25, 2011 at 06:45:27PM +0100, Phil Mayers wrote:
> 
> This (aggregate routes on next-hop) comes up now and again, and the 
> idea seems to be controversial for some people. Various criticisms are 
> cited - unpredictability (a single route change could result in a 
> large jump in FIB use), performance implications, and fairly limited 
> improvement (the thread cited below reckons 30% mean, 10% worst case, 
> 45% best case, depending on connectivity topology)

Foundry did dynamic FIB aggregation using a covering default route to 
remove more specifics 10-some years ago, back when they had "routers" 
with only enough CAM for 8k or 16k FIB entries (ye olde Ironcore days). 
It actually worked pretty darn well, and the improvement IS significant 
in my experience (anyone who claims otherwise is full of shit or not 
being realistic in their modeling). It's also pretty straightforward to 
implement, I could prototype the code for it in a few minutes.

The only REAL objections seem to be:

a) The benefits are very non-deterministic, and customers may/will be 
confused if they make one covering route change and it causes thousands 
of FIB entries to be created or destroyed as a result. Nobody likes 
confusing customers more than is necessary, especially when your support 
organization is as disasterously broken as JTAC.

b) It's not entirely impossible that doing this won't cause breakage in 
some unanticipated way. For example, say someone rapidly flaps a 
covering route, which causes a lot of FIB churn. There are a lot of 
potential implementations for performance, interaction with the krt, 
etc. Somebody has to actually take the time to model and test this to 
make sure it doesn't cause something to break/crash/blackhole/etc in 
practice. I'm personally not sure it would actually be any worse than 
the hour+ times to install a full FIB that some of these boxes are 
suffering from already, but I can understand why nobody is particularly 
eager to jump in and "own" this issue if they don't have to do so.

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). :)

Of course given the EX8200 situation, where they've knowingly sold a 
bunch of cards that can't possibly do what they claimed they could do, 
maybe a horde of pissed off customers will motivate some renewed 
interest in providing some software "assistance".

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)