On Thu, Oct 06, 2022 at 3:37 AM, Ketan Talaulikar <ketant.i...@gmail.com> 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 <noreply@ > 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. > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
