Hi Robert, We were comparing OSPF and BGP and so it was the protocol FSMs. So we are in sync on that part.
Thanks, Ketan On Tue, Feb 1, 2022 at 1:43 PM Robert Raszuk <rob...@raszuk.net> wrote: > Ketan, > > >> What the OSPF draft discusses in Sec 5 is a "hold-down" wait period where >> even though the BFD session is established the protocol FSM does not >> proceed further until a period of time has passed to ensure the stability >> of the BFD session. >> > > Which protocol FSM ? BFD FSM or OSPF FSM ? > > If BFD FSM then I think this is a false assumption or perhaps based on > specific implementation. If OSPF FSM then we are all in sync. > > See the point being is that the BFD session UP the draft is referring to > as a trigger for OSPF adj to come UP does not mean anything yet about > path liveness (except proving that BFD control packets made it to a peer - > depending on BFD mode of operation). So reacting on it immediately by any > client would be a wrong thing to do. I see nothing in section 6.2 of > RFC5880 which would indicate any hold time or which would block BFD state > transition to UP waiting for even single BFD Echo packet to be exchanged. > > BFD probing interval can be set to 2 sec and multiplier set to 3 which > would mean that only after 6 sec from BFD UP state you would get some > meaningful data about the link letting BFD Echo packets to get exchanged. > If you bring OSPF adj. UP immediately after seeing BFD session UP you have > not accomplished anything what wait-for-bfd is trying to do. With that I > actually think the draft in the current form as stated in section 4 is > harmful - it only mentions to wait for BFD session to get established. > > All along I was trying to highlight that point. And let me self correct > one thing I said earlier ... In one of the emails to Albert I mentioned > that such timer could be 0. Well not really - the min amount of time > between BFD UP and OSPF adj. UP should be: (BFD probing interval x > multiplier) + time it takes on a given platform to sent messages between > LCs and RE/RP. > > Regards, > Robert. > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
