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 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 I am not sure if BFD implementation is free to introduce any delay there yet still to claim full compliance to RFC5880 (even if technically it would make sense to have such delay). Quote: Up state means that the BFD session has successfully been established, and implies that connectivity between the systems is working. The session will remain in the Up state until either connectivity fails or the session is taken down administratively. Rgs, Robert.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
