[c-nsp] BFD alternative

[Jason Lixfeld]

On 2011-01-09, at 1:11 PM, Oliver Boehmer (oboehmer) wrote:

> 
>> We're in the the process of turning up an MPLS network using ASR9ks
> and
>> ME3600s.  We're looking to get away from L2 and interconnect all the
> devices
>> at L3.  To facilitate this, we were originally going to use unnumbered
> on
>> all the PE-PE, P-P, P-PE links but we just recently discovered that
> BFD
>> isn't supported on unnumbered Gig/TenGig interfaces.
>> 
>> We're just doing L2/L3VPN here.  No VPLS, TE, etc at this point.  That
> said,
>> if we tune down our SPF timers (ISIS) and enable LDP IGP Sync and LDP
>> session protection, is that a pretty good compromise?
> 
> well, I wouldn't call it a compromise.. BFD addresses failure detection,
> and tuning down timers speeds up reaction to failures (once detected).
> If it takes 30 sec to detect a failed neighbor (without BFD and using
> default hello timers), I would argue that it doesn't matter if ISIS
> takes another 5 secs (default timers) or < 1 sec (tuned timers) to
> update routing table. So tuning down hello timers would be an
> "alternative", albeit not a good one.

Fair statement, Oli.  We interconnect all our devices over our own dark fibre and use BiDi, single strand optics (no UDLD issues), so I think failure detection would be almost instant in 99.9% of the cases.

> If you want to be serious with fast convergence, I would not run it
> without BFD, and hence would not use unnumbered links..

Another fair statement.  We're trying to decide what the better trade off is for us.  Lower administrative overhead adding nodes (which we do at the very least on a weekly basis) but users may see 5 seconds of packet loss once a week (which is still 99.999% availability over a 7 day period) when we add a node vs. higher administrative overhead, higher risk of extended outage due to misconfiguration/more hands in the pot/more devices needing to be touched to add another node but with lightning speed failure detection to mitigate the 5 seconds of packet loss once a week.