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 protected]> To: Les Ginsberg <[email protected]> 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.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
