Re: How are you configuring BFD timers?

[Jason Lixfeld <jason+nanog () lixfeld ca>]

Thanks to everyone who has responded so far.  Enlightening!

My understanding around the origins of BFD is that it was developed in part to try and bring SONET like switchover 
times to an Ethernet world.  What I’m reading is for those who do run BFD, no one seems to be dialing it down to try 
and achieve those times.  Some folks explained why they chose the values they did, but others didn’t.  So my follow up 
question is “Why don’t you dial them down?”.  Are achieving those switchover times not important for your use case?  Do 
you not trust that it won’t be reliable based on the gear you’re using, or the quality/reliability of the underlying 
circuit you’re trying to protect?  Something else?

Also, interesting to read about why some folks don’t care much about BFD at all.

> On Mar 21, 2018, at 9:10 AM, Jason Lixfeld <jason+nanog () lixfeld ca> wrote:
>
> Hey,
>
> For those running BFD on your land-based point-to-point links, I’m interested in hearing about what factors you 
> consider when deciding how to configure your timers and multiplier.
>
> On paper, BFD between two devices over a local or metro dark fibre or wave seems pretty trivial:  Assuming your gear 
> can a) support echo mode b) hardware offloads echo processing c) automatically treats echos as vital and puts them 
> into the appropriate high priority queue, then setting the timers down to their lowest possible values (3ms on some 
> of the gear that I’ve seen) and some low multiplier seems more than reasonable.  But?
>
> From another angle, your link isn’t dark fibre or a wave but, for example, ethernet over some sort of IP based L2 
> Transport, and is still a low (sub 1ms) one-way latency local or metro link.  How do you set your timers, and what do 
> you base that on?
>
> From yet another angle, what if your link is a long-haul wave, or for that matter a wave of any distance that imposes 
> a one-way latency that is higher than the minimum tx and rx timers that are supported by your gear?  We’ll assume an 
> unprotected wave, because I’m sure if it’s protected, you have no choice but to consider the one-way latency of the 
> longest of the two segments.
>
> I made some assumptions above about support for echo mode and hardware offload, but what if (some of) your gear 
> doesn’t support some or all of that stuff?  How do you factor your configuration decisions?
>
> Thanks!