Hi Warren, You have just asked a very valid question.
I have brought this to the attention of LSR WG here: https://mailarchive.ietf.org/arch/msg/lsr/LaXtqHuoZ6FCeOuvZ9sUXxZ_Z20/ But after 10s of emails on and off line apparently you observing the issue again at this stage is proof that no real improvement went into the document. Sad but I have no more cycles to continue banging the closed doors. The answer I got is that such a timer may exist but as private vendor enhancement not clearly part of the spec. Cheers, R. On Thu, Oct 6, 2022 at 12:40 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... unless it is expected that the OSPF exchange is > sufficiently slow that BFD would detect it before OSPF is actually working? > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
