jhaas-pfrc
commented
2 weeks ago A little further audit is showing that current use of BfdEnabled as being needed for distinguishing that it is configured and the BFD session state may not be up. So, overloading the strict configuration adds branch case text for each time this value is referred to in the FSM. However, if the updated text results in always pairing the strict check as well, it still motivates the merge.
Note that there's no YANG module extension in this draft and this issue overlaps what configuration of BFD and configuration of strict look like. The BFD YANG module provides a generic grouping that is leveraged in the IETF BGP module. The strict mode behavior would be an augmentation in the BGP YANG module as part of using that grouping.
merciaz
As part of Ketan's review, he's asking whether the BfdEnabled session attribute should, instead of being boolean, be a choice of enabled/disabled/bfd-strict-enabled.
There's a desire to include "bfd strict enable". Review in the upcoming FSM work whether we squish this into the current BfdEnabled or whether there's motivation to have a separable BfdStrictEnabled.
My impression prior to full analysis is we need carefully only refer to the negotiated results in the FSM for the BGP capability, and the BFD session state. The current text does have bfdenabled and bfd session state evaluated together. Re-evaluate.