Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Feb 2022 09:13:22 +0100

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.

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 3 Feb 2022 23:54:59 +0530

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 <[email-masked]> wrote:

> 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
> 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.
>
>