Hi Les On Sun, Feb 6, 2022 at 5:05 PM Les Ginsberg (ginsberg) <ginsberg= 40cisco....@dmarc.ietf.org> 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.* > Gyan> Agreed > *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.”* > > * Gyan> Agreed that Interaction between BFD and local client is an > implementation issue. Section 3.3 Hitless establishment and > reestablishment of BFD state in cases where BFD state changes should not be > signaled to the clients such as process restart -GR. That is one of the > reasons why the BFD to local client signaling is an implementation issue > due to these types of caveats and thus devoid of the 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.* > > * Gyan> Agreed. Makes sense.* > > * 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr