Hi Les, BFD dampening as per some documentation is applicable or is triggered by flapping BFD session(s). And indeed it has its own very valid use case. But IMHO it is only partially a solution for what we need in the light of this thread.
Here in this context assume I am looking at a new interface being provisioned. So DOWN transitions happened infinitely long before to first UP and stays UP. I see nowhere in BFD Dampening description that it will also suppress for time T even first UP notification after a long enough DOWN event. In bringing the new interface UP all dampening parameters have expired. To me dampening may kick in when you go DOWN and suppress excessive UP events before presumed link stability is achieved as expressed in dampening [ half-life-period reuse-threshold suppress-threshold max-suppress-time] cli. But I see nowhere in the docs any indication that BFD Dampening can be used as an unconditional UP transition suppression buffer. The same applies to interfaces which went down and came UP after max-suppress-time had already expired. Thx, R. On Sun, Feb 6, 2022 at 11:05 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Robert – > > > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Sunday, February 6, 2022 10:42 AM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* lsr@ietf.org > *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for > BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 > > > > Hi Les, > > > > There is nothing in RFC 5880 (nor in, what I consider to be even more > relevant, RFC 5882) that requires a BFD implementation to signal UP state > to a BFD client within a specific time following transition of the BFD > state machine to UP . An implementation is free to introduce a delay (as > you suggest) before such signaling. > > > > My reading of section 6.2 of RFC5880 clearly indicates that BFD is > signalling UP state when BFD session has been established without any > delay. > > *[LES:] This is specifying the BFD State Machine and signaling between BFD > peers – not signaling between BFD and its local clients.* > > *RFC 5882 has some discussion of the latter – particularly > https://www.rfc-editor.org/rfc/rfc5882.html#section-3 > <https://www.rfc-editor.org/rfc/rfc5882.html#section-3> * > > > > *It is worth quoting this sentence:* > > > > *“The interaction between a BFD session and its associated client* > > * applications is, for the most part, an implementation issue that is* > > * outside the scope of this specification.”* > > > > *Indeed, one way of implementing “BFD Dampening” (as some vendors have > done) is to delay notification of BFD UP state to BFD clients.* > > > > *The obvious benefits of implementing such a delay (if desired) before BFD > signals UP to clients are that it is client agnostic and does not require > any knowledge on the part of the clients as to when BFD has completed any > additional procedures. The client simply operates as if BFD session is DOWN > until it gets an UP indication from BFD.* > > > > * Les* >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
