Hi Warren, Thanks for your review and comments. Please check inline below for response.
On Thu, Oct 6, 2022 at 4:10 AM Warren Kumari via Datatracker < nore...@ietf.org> wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-lsr-ospf-bfd-strict-mode-09: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for this document. > > When I started reading this document / read the Abstract, I must admit I > thought "This is a silly idea, and smacks of creeping featuritis and > premature > optimization. This is an already solved problem - you bring up OSPF and > *then* > use that to signal that you want BFD...." and then I actually read the > Introduction section and the use-case / utility became clear... > > My only question (and I'm suspecting it has already been discussed) if is > there > should actually be some (small) delay after the BFD session establishment > to > allow the interface to "settle" / give BFD a second or two to figure out > if the > link is actually "stable" - having BFD come up and then immediately > bringing up > the adjacency, only to have BFD pull it down 10ms later doesn't seem to > solve > the issue really... KT> Agree. This was brought up during the WG discussions (as indicated by Robert). As a result of that discussion, the document was updated. More specifically to your point, please refer to https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-09#section-5 and the text below: The use of OSPF BFD strict- mode along with mechanisms such as hold-down (a delay in the initial OSPF adjacency bringup following BFD session establishment) and/or dampening (a delay in the OSPF adjacency bringup following failure detected by BFD) may help reduce the frequency of adjacency flaps and therefore reduce the associated routing churn. The details of these mechanisms are outside the scope of this document. The reason for these mechanisms being discussed but not standardized in this draft is that there are different approaches (some already in implementations for a long time). Things like the "hold-down" timer, that you refer to, can be made per-protocol (clients of BFD) or can be done by BFD (called BFD dampening by some implementations) on behalf of these clients. For a per-protocol approach, a follow-on question is if this can be simply a local configuration (also something provided by some implementations) or if it needs to be signaled/negotiated - here we would likely need similar work in multiple protocols. For the BFD approach, it would be anyway outside the scope of this document. > unless it is expected that the OSPF exchange is > sufficiently slow that BFD would detect it before OSPF is actually working? > KT> This is clearly not the expectation and we cannot make any such assumptions. Thanks, Ketan
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
