Hm, OK. So this is now sounding more like a “hold for document update” erratum which is our vehicle for saying “the spec could have been clearer, here is some improved text, maybe use this if you do a bis”.
I can verify it as HFDU with an updated description — if we have some agreed-upon text. —John > On Feb 13, 2023, at 4:52 PM, Dave Katz <[email protected]> wrote: > > The intent of the diag field is to leave a breadcrumb behind about what > caused the last session failure, so that humans and/or fault analysis can try > to guess what happened. If the session comes back quickly, overwriting the > diag on the transition to UP will wipe out that information. > > So I actually am changing my mind on this and would oppose the change. The > erratum, to the extent that it exists is actually in the description of the > field, which should say (in effect) “the reason for the most recent change in > the local session state except for going Up because we know why we did that”, > or something. But the normative text is sprinkled throughout where the spec > calls out when to set the local diag value (which is always copied to the > protocol packet) and that does not need to change. > > Thanks for making me think twice, er three times, or something. > > —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 >>>>> >> >
