Note that there are also cases where the diag field is manipulated while remaining in UP state (so you can signal concatenated path failures upstream and downstream) so the current field description is a little sloppy. But a field description is not a normative requirement…
—Dave > On Feb 13, 2023, at 6:06 AM, John Scudder <[email protected]> wrote: > > I guess it hinges on whether the reinitialization happens when you transition > out of Down, or into Up. As the erratum is written now it’s when you > transition into Up, which appears to make sense, and applies whether the > transition is from Down or from Init. But I’ll wait a little longer for any > further discussion before verifying the erratum. > > —John > >> On Feb 13, 2023, at 4:37 AM, Gļebs Ivanovskis >> <[email protected]> wrote: >> >> >> Hi! >> >> Wouldn't it make sense to re-initialize bfd.LocalDiag when transitioning to >> Init state as well? >> >> Section 6.8.6 describes a case when bfd.SessionState goes from Down to Init: >> >> If bfd.SessionState is Down >> If received State is Down >> Set bfd.SessionState to Init >> >> Best regards, >> Glebs >> >> >> On 08.02.23 19:58, John Scudder wrote: >>> Hi Everyone, >>> >>> I plan to verify this in the near future (let’s say, Monday Feb 13) unless >>> anyone objects. >>> >>> Thanks, >>> >>> —John >>> >>> >>>> On Nov 6, 2022, at 4:27 AM, RFC Errata System <[email protected]> >>>> wrote: >>>> >>>> The following errata report has been submitted for RFC5880, >>>> "Bidirectional Forwarding Detection (BFD)". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7240__;!!NEt6yMaO-gk!DSW_aH2n7cYViXw08rr41mmdkcad5rzUky6aMWE1XW-uhZqqdIELlYuLQ20Sw8Z1cTiyiqHvd7VyqUJIsm_Lmg$ >>>> >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Jeffrey Haas >>>> <[email protected]> >>>> >>>> >>>> Section: 6.8.1 >>>> >>>> Original Text >>>> ------------- >>>> 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). >>>> >>>> Corrected Text >>>> -------------- >>>> [Proposed text] >>>> >>>> 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). It MUST also be re-initialized to zero >>>> (No Diagnostic) when the local session state transitions to Up. >>>> >>>> Notes >>>> ----- >>>> RFC 5880 at various points calls out setting the value of bfd.LocalDiag as >>>> part of state transitions. The text defining the feature calls for it to >>>> be initialized to zero. However, it doesn't define under what conditions >>>> it should be re-initialized to zero. >>>> >>>> One possible place where it may be reinitialized is when the session >>>> transitions back to Up, indicating that prior issues may have been cleared. >>>> >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC5880 (draft-ietf-bfd-base-11) >>>> -------------------------------------- >>>> Title : Bidirectional Forwarding Detection (BFD) >>>> Publication Date : June 2010 >>>> Author(s) : D. Katz, D. Ward >>>> Category : PROPOSED STANDARD >>>> Source : Bidirectional Forwarding Detection >>>> Area : Routing >>>> Stream : IETF >>>> Verifying Party : IESG >>>> >
