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
