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) < af...@bloomberg.net> 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 > > From: Robert Raszuk <rob...@raszuk.net> To: Les Ginsberg < > ginsb...@cisco.com> > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
