FWIW, my own reading through the text comes to similar conclusion. The transition for the state machine would be an appropriate place to reset the LocalDiag back to No Diagnostic.
Glancing at part of Juniper's implementation, it seems we'll reset the Diag when the session returns to Up. It might be good if the RFC was clearer about when this happens. I have filed an errata on the issue. -- Jeff On Fri, Sep 30, 2022 at 06:55:12PM +0000, Reshad Rahman wrote: > Hi Glebs, > I don't know for sure what the authors intended, but in the implementations I > was involved with (albeit many years ago), the Diag field got reset to "No > Diagnostic" when a session goes back up. > Also, "The diagnostic code specifying the reason for the most recent change > in the local session state" implies that the diag should be reset to No Diag > when the session goes up (last state change)? > I need to check RFC5880 but it'd be good to hear from various vendors on > this. Regards,Reshad (no hat). > On Friday, September 23, 2022, 10:07:36 AM EDT, Gļebs Ivanovskis > <gl...@mikrotik.com> wrote: > > > Hi, > > I have a question regarding bfd.LocalDiag State Variable. In section 6.8.1. > State Variables it says: > bfd.LocalDiag > > The diagnostic code specifying the reason for the most recent > change in the local session state. This MUST be initialized to > zero (No Diagnostic). > > Then in many places throughout the text it is said that bfd.LocalDiag needs > to be set to other values in response to different failures. But nowhere it > is said that bfd.LocalDiag needs to be reset to "No Diagnostic". Only the > text I quoted above mentions bfd.LocalDiag together with "No Diagnostic", but > it talks only about BFD session initialization. > > So, if implementation rigorously follows the letter of RFC, then it leads to > a peculiar situation when a session goes back Up after, say, "Control > Detection Time Expired", but the Diag field of the packet keep holding the > diagnostic from the time session was Down. Or am I missing something? > > Best regards, > Glebs > > > >
