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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
