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

[Mark Tinka]

On 5/Apr/20 12:25, adamv0025 at netconsultings.com wrote:

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

For me, I'd say small FIB's in a network that runs MPLS all the way into
the Access (where the small FIB's reside) is the biggest risk to scaling
out the IGP. On those boxes, CPU and memory aren't the issue (and they
are nowhere near as powerful as the chassis' in the data centre), it's
the FIB slots.

I have zero worry about IS-IS blowing out all the Intel-based control
planes currently ruling our big a** routers. Wouldn't have been able to
say the same thing 15 years ago, though.

Mark.