Let me see if I can refine a sentence or two, since the whole kerfuffle is largely my fault anyhow (and I managed to reverse my position in public within about 48 hours). If someone wants to run with those I’d be honored…
—Dave > On Feb 17, 2023, at 8:08 AM, John Scudder <[email protected]> wrote: > > 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 >>>>>> >>> >> >
