BFD – Understanding BFD Echo Packets

It won't interfere per se, but question is - what you're trying to achieve?

First of all, it's hardware dependent - you may be silently ignored using this command on software platforms. Essentially, you should drill down to supported/unsupported notes for your gear to check if it's available and working. Some platforms can tune up/down delays separately.

If you're trying to achieve fast convergence, use one protocol - by approaching the problem with the KISS principle. BFD seems to be best fit in case multiple protocols are used and they need information about the neighbor loss ASAP.

BTW, carrier-delay will only work on interfaces, that will signal up/down situation properly. Connections to shared media (like Ethernet switch) or to media that doesn't properly propagate up/down signal (some SDH/SONET/ATM gear) will cause problems anyway, so you should fall back to something that YOU control.

Well, actually BGP NHT can use BFD to speed up neighbor problems detection, and it's usually the best scaling mechanism, because BFD is often offloaded in hardware.

Running BFD for both IGP and BGP may be good idea, depending on the scaling capabilities of your gear and hardware acceleration/offload. It's the configuration that has to make sense from logical standpoint.

So, your decision boils down to this: if you wish to tune both IGP and EGP protocols to try tu run at the same time (bgp nexthop trigger delay 0 and BGP BFD NHT), which may lead to problems, oscillations and so on, or you'd like to focus on achieving fast IGP convergence and with presence of multiple forwarding paths, let BGP linger a moment longer just to make sure your IGP converges (bgp nexthop trigger delay 1 with or without BGP BFD NHT).

That last approach usually makes more sense, and that's why NHT delay by default is set to 5 seconds. If your IGP converges in 200ms (or generally, under second) tuning BGP NHT to 1 second may make sense.