Re: Resolving lingering issues with BFD authentication drafts

[Jeffrey Haas <[e-mail]>]

Reshad,


> On Feb 29, 2024, at 2:36 PM, Reshad Rahman <[e-mail]> wrote:
> 
> Jeff, 
> 
> The only thing I am still a bit hesitant about is delaying the notification to the BFD clients (that the session is up) until we've successfully moved to the optimized mode. It's not the actual delay, which should be short, but the fact that it's changing the BFD state machine a bit. But I don't see any other way to do this without the risk of bouncing the BFD session. 

It's worth pointing out that the "bfd holddown" features implemented by multiple vendors ALREADY does this.  And, when it's in use, the client will wait for stuff on the order of seconds to minutes for some providers.

So, while I agree that it's a change, and theoretically a scary one, it's well deployed already in some form.

In the interest of honesty, such holddown features didn't interoperate in their use terribly well and was the reason for the PROTOCOLS / clients to refine how they used BFD - hence the "strict" features.  Again, not a problem with the idea of holddown, but rather than RFC 5882 was a bit too general in its advice.


> Regarding "until we've successfully switched over to the optimized mechanism", what does a successful switch mean? Does it mean sending detect mult packets with optimized auth?

I believe it means that both sides are using the optimized mode.  It can't be only one side since the potential session drop will only happen when each side turns on optimization.

-- Jeff