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
