I think “dynamic” here is kind of FRR abstraction, not protocol part.
BFD always negotiates timers for example (in ranges configured on peers).
So in FRR lingo “static” is something explicitly configured, like in protocol bfd in VyOS. As oppsosed to that “dynamic” is something implicitly derived from other parts of config, like in protocol bgp with bfd profile attached for example.
All this is very vendor specific In Cisco for example bfd timers are configured on interface, and then neighbor A.B.C.D fall-over bfd in BGP process.
I am perplexed now. Tonight I was doing some work on this router, VyOS peering with EdgeOS, so I took the time to play around with the config.
Both the #1protocol bfd
and #2protocol bgp ... ... bfd
settings work together. Configuring #1 alone works and keeps a bfd peering session up, but if #2 is configured it demands that #1 is configured as well. So I guess my question is what does the #2 config do actually?
I did a test tonight. Made sure BFD session was up, across the RF link, setup a ping at 0.5 second interval to the remote router, so 2 per second, and hit the firmware update button on the RF link. This is BFD running on eBGP, and I was pinging the local address on the remote router which is reachable over multiple links. We only lost 2 packets, so 1 full second, before BFD triggered a route drop and BGP rewrote the routing table. I’m super happy with that.
In Cisco for example bfd timers are configured on interface, and then neighbor A.B.C.D fall-over bfd in BGP process.