Subject: Re: [Lsr] Lsr Digest, Vol 49, Issue 24

From: "Albert Fu (BLOOMBERG/ 120 PARK)" <[email-masked]>
Date: Mon, 7 Feb 2022 14:51:09 -0000

Hi Robert,

This is precisely the issue that this draft intends to address, making sure that OSPF is not established, until BFD is UP. 

This ensures that there is a mechanism to quickly detect BFD failures, and avoid having to rely on lengthy OSPF protocol timer for failure detection (where OSPF is UP without BFD). 

If there's an issue where BFD packets can not get through after OSPF is UP, the fast detect mechanism will kick in as per the configured timer/multiplier, and bring OSPF down, diverting traffic away from the link.

We know that BFD UP, as it stands today, does not mean that the link is 100% good (e.g. MTU-sized packets might not get through). IMO, link quality issue is outside the scope of this draft. 

Thanks
Albert

From: Robert Raszuk <[email-masked]> To: Les Ginsberg <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
Date: Mon, 7 Feb 2022 00:31:04 +0100

..

When the interface goes UP OSPF will not bring adj UP till BFD comes UP. But then we are back in square one as OSPF adj comes UP and BFD after a full cycle of testing brings it back down. So what have we accomplished with this draft/RFC - nothing.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Feb 2022 16:17:04 +0100

HI Albert,

> This is precisely the issue that this draft intends to address,
> making sure that OSPF is not established, until BFD is UP.

What this draft tries to address is obvious. The real issue is however in
the true meaning of what "BFD UP" trigger means.

Some folks, perhaps including yourself, naturally and intuitively think
that BFD UP means that BFD session has been established and data plane has
been confirmed to work between local and remote node over the subject link.

That is unfortunate not the case modulo local implementation hacks. BFD
RFC5880 says that BFD UP only means that BFD session signaling completed.
It says nothing about the actual data plane being tested at least once
between two peers on the very link you are going to bring OSPF adj UP.

RFC5882 recommends implementation of BFD dampening but as we established
this does not cover the point of the discussion. It also discusses
interaction between BFD and client(s) when a session goes DOWN. It is
pretty silent on the session UP event leaving this pretty open to the
implementations.

*Proposal: *

If you do not want to add any text describing any recommended behavior on
the client why just not add instead a single sentence defining that in the
context of this draft "BFD UP" trigger as received by the client means not
only BFD session UP but at least one full test cycle to pass successfully ?
Is there any harm associated with adding such statement ?

Regards,
R.

PS,

> We know that BFD UP, as it stands today, does not mean that the link is
100% good
> (e.g. MTU-sized packets might not get through). IMO, link quality issue
is
> outside the scope of this draft.

That is not the point. The point it to make link really works in the data
plane. The extra testing is indeed out of scope and as I mentioned it was
just an example.

On Mon, Feb 7, 2022 at 3:51 PM Albert Fu (BLOOMBERG/ 120 PARK) <
[email-masked]> wrote:

> Hi Robert,
>
> This is precisely the issue that this draft intends to address, making
> sure that OSPF is not established, until BFD is UP.
>
> This ensures that there is a mechanism to quickly detect BFD failures, and
> avoid having to rely on lengthy OSPF protocol timer for failure detection
> (where OSPF is UP without BFD).
>
> If there's an issue where BFD packets can not get through after OSPF is
> UP, the fast detect mechanism will kick in as per the configured
> timer/multiplier, and bring OSPF down, diverting traffic away from the link.
>
> We know that BFD UP, as it stands today, does not mean that the link is
> 100% good (e.g. MTU-sized packets might not get through). IMO, link quality
> issue is outside the scope of this draft.
>
> Thanks
> Albert
>
> When the interface goes UP OSPF will not bring adj UP till BFD comes UP.
> But then we are back in square one as OSPF adj comes UP and BFD after a
> full cycle of testing brings it back down. So what have we accomplished
> with this draft/RFC - nothing.
>
>
>