Hi All,

The authors will work on and share the updated text to review with the WG.

Quickly want to point out that the draft does not bring any new
requirements in BFD for link quality monitoring; the stability issues that
we are discussing are related to BFD sessions going down due to
intermittent packet loss. If/when BFD WG brings any new enhancements,
protocols like OSPF will obviously leverage the same.

Thanks,
Ketan


On Tue, Feb 1, 2022 at 1:59 AM Jeffrey Haas <[email protected]> wrote:

> Les,
>
>
> On Jan 31, 2022, at 2:47 PM, Les Ginsberg (ginsberg) <[email protected]>
> wrote:
> I have not asked for BFD extensions.
> I have stated that “IF” additional functionality is required from BFD that
> the proper place to discuss that is in the BFD WG – and such discussions
> are definitely not in scope of this draft.
>
>
> Agreed.
>
>
> The main content of this lengthy thread is Robert asking for additional
> specification in this draft and other folks (myself, Albert, Ketan) saying
> it doesn’t belong in this draft. Which is why I agree with everything you
> say below except for your perception that you are agreeing with Robert. You
> are actually agreeing with myself, Albert, Ketan. 😊
>
>
> I was largely agreeing with Robert about the state of BFD and how it
> likely impacts the OSPF feature.  BFD isn't helpful beyond the Up/Down
> signaling, how it handles too much noise, etc.  So, I think we're all in
> agreement about these things.
>
> What the protocol chooses to do about the signaling BFD provides is up to
> the protocol. I think we're all agreeing that the strict mode helps with
> making sure implementations use the inputs to their state machines
> consistently.
>
> Whether there's any sort of "pause button" used by the implementation once
> the ordering is agreed upon seems to be where the disagreements have been.
> Such a pause button isn't appropriate for BFD.
>
> And now we're fully in sync. :-)
>
> -- Jeff
>
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to