Hi Robert, Thanks for your review again and your comments/discussions.
This thread is about your second point "timer". I would like to point out that the draft discusses the BFD "dampening" or "hold-down" mechanism in Sec 5. We are aware of BFD implementations that include such mechanisms in a protocol-agnostic manner. This draft indicates that OSPF adjacency will "advance" in the neighbor FSM only after BFD reports UP. The BFD mechanisms/timers are outside the scope of this document. Please also see a further response on this point in your latest email on this thread. Thanks, Ketan On Sun, Jan 30, 2022 at 2:19 AM Robert Raszuk <[email protected]> wrote: > Hi Les, > > That timer and its consistency on both ends clearly belongs to OSPF not to >> BFD. >> > > >> *[LES:] I disagree. The definition of UP state belongs to the BFD >> protocol/implementation.* >> >> *If you don’t want BFD clients (like OSPF) to react “too quickly” then >> build additional config/logic into your BFD implementation so it does not >> signal UP state before additional criteria is met – do not make each BFD >> client (and there could be multiple for a given session) configure its own >> definition of BFD UP.* >> > > I think we are looking at this from different perspectives. > > I am saying bring BFD UP and allow X seconds/minutes/hours to run a > sequence of testing before bringing OSPF adj up. > > You are saying do not declare BFD as UP before all of those testing > passes. That test sequence could be just running vanilla normal BFD for X > seconds/minutes/hours. > > That would require introducing a completely new BFD state. Worse, that > timer may be very different on a per type of interface basis as each > interface type has completely different characteristics. Also such timer > would need to have a different value on a per BFD client basis. (For > example OSPF adj UP could be very different then PE-PE BFD for BGP as PULSE > alternative :) > > Sorry I really do not think this belongs to BFD at all. It is a local > client thing how long from t0 = BFD UP it will wait before proceeding > further. > > And last but not least - such extended testing does not need to kick in > every time interface flaps. Maybe the operator only wants to run it during > maintenance windows once per day ? Or once per week ? > > But I am not going to even remotely hope I can convince you :) So let's > forget it. > > Cheers, > R/ > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
