Hugo, I think those are all valid potential reasons to use BFD. I use it for some of the same reasons even on direct connect peers.
Only time I ever recall actively avoiding it if I had the capability was if I had NSF/SSO, since they didn't used to (still don't?) play very well together. On Tue, Nov 29, 2016 at 1:23 PM, Hugo Slabbert <h...@slabnet.com> wrote: > Good morning, nanog, > > Is there any/sufficient benefit in adding BFD onto BGP sessions between > directly-connected routers? If we have intermediate L2 devices such that > we can't reliably detect link failures BFD can help us quickly detect peers > going away even when link remains up, but what about sessions with: > > - eBGP with peering to interface addresses (not loopback) > - no multi-hop > - direct back-to-back connections (no intermediate devices except patch > panels) > > Possible failure scenarios where I could see this helping would be fat > fingering (filters implemented on one or the other side drops traffic from > the peer) or e.g. something catastrophic that causes the control plane to > go away without any last gasp to the peer. > > Or is adding BFD into the mix in this type of setup getting into > increasing effort/complexity (an additional protocol) for dimishing returns? > > -- > Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com > pgp key: B178313E | also on Signal > >
