Thanks Warren.
On Thu, Oct 6, 2022 at 8:33 PM Warren Kumari <[email protected]> wrote: > > > > > On Thu, Oct 06, 2022 at 3:37 AM, Ketan Talaulikar <[email protected]> > wrote: > >> 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 < >> [email protected]> 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. >> > > > Okey dokey, and thank you. > Personally I would have preferred some guidance in the doc, but I > understand (and am OK) with the above reasoning. > > Thanks again, > W > > > >> >>> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
