>
> SPF timers is generally a design decision, so the values above are just
> reflecting different design approaches: Choosing an initial wait of 1ms
(the
> latter settings, i.e. spf-interval 5 1 50) tunes the network for optimal
reaction
> for link failures, so routers will immediately start to re-route, with
the risk of
> a subsequent SPF required if the failure was a node failure and
additional LSP
> updates from other nodes are required to judge this.
> Hence a little more conservative setting uses 50msec initial wait,
allowing
> more LSP updates to come in before the new SPF is calculated..
>
> With LFA-FRR, core failures can be handled differently, so a little less
> aggressive initial-wait makes a lot of sense in this case..
>
> Either way: even without LFA-FRR, difference between 1 and 50 msec is
> marginal and not noticeable in practice, so why bother much __
>
Agree with Oliver.
With any FRR mechanism in place there's absolutely no point in tuning any
SPF timers (lowering the timers will just put unnecessary strain on RE CPU)
Just would like to point out that in case of iBGP FRR it might be desirable
to tune LSP generation and propagation (depending on your SLAs).
This is because the "PIC Core" can do its magic only once the ingress
router is informed about the failure of the primary egress PE.
oli: This is actually PIC-Edge, so even with (LFA-)FRR you want to tune your
SPF and LSP timers for PIC-Edge or any other service restoration mechanism to
kick in, but 50msec is generally good enough..
oli
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
