[c-nsp] how many IGP routes is too many?

[adamv0025 at netconsultings.com]

> Pierfrancesco Caci
> Sent: Thursday, April 2, 2020 8:46 AM
> 
> Hello,
> 
> is there any recent study about how many IGP (isis or ospf, I don't really
care
> right now) routes are "too many" with current generations of route
> processors? Think RSP880, NCS55xx and so on on the cisco side and PTX1000,
> PTX10002, etc on the juniper side.
> 
Guessing it was in ~2012 one of the Tier1s asked cisco for 1M IGP routes -so
guessing 1M was too much when they tested back then.
The fact you're asking here tells me you're not one of the big folks trying
to break a sweat on IGP,  so my guess is you'll be fine (assuming the usual
"don't redistribute DFZ to IGP"...).

But as Saku eluded to, there will be a threshold above which the SPF
calculation will take a significant time -which might negatively impact
convergence or CPU load especially in case of a flapping links (and no
dampening measures), back in the days this could have had effect on your
tuning of the IGP (or default settings if you didn't to any tuning) so
readjusting was needed to get optimal results.
Nowadays however, in times of FRR (-well that one has u-loops), but for
instance ti-LFA or classical RSVP-TE Bypass... and BGP PIC "Core", I'd say
the SPF calculation time is becoming less and less relevant. 
So in current designs I'm tuning IGPs for egress edge-node protection only,
i.e. for generating LSP/LSA ASAP and then propagating it to all other
ingress edge-nodes as fast as possible so that BGP PIC "Core" can react to
the missing loopback and switch to an alternate egress edge-node.(reactions
to core-node failures or link-failures are IGP agnostic and driven solely by
loss of light or BFD/LFM...).
*Even in the egress edge-node protection case there are now RSVP-TE and
SR-TE features addressing this.

So I guess only the mem and cpu load and ultimately stability of the RPD (or
IGP process) is the remaining concern in extreme load cases (not the
convergence though).     

 
adam