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
