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

[adamv0025 at netconsultings.com]

> Mark Tinka
> Sent: Wednesday, April 8, 2020 12:55 PM
> 
> 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.
> 
Right, but there are bunch of techniques to address the FIB scaling problem
of MPLS all the way to access layer (cell tower) deployments. 

adam