Re: [Technical Errata Reported] RFC5880 (7240)

[Dave Katz <[e-mail]>]

On Feb 17, 2023, at 8:47 AM, Reshad Rahman <[e-mail]<mailto:[e-mail]>> wrote:


[External Email. Be cautious of content]


Having the diag field as breadcrumb has been extremely useful indeed. But both ends can store last diag field sent/received, we don't have to keep sending the diag field after the failure has cleared. It seems odd to be sending a diag field which happened e.g. a year ago.

That property helped me when debugging my implementation, as it survives the restart/reboot of the far end.

There is also no timeout that would make sense;  “forever, for small values of ‘forever'” is semantically consistent and the only thing that makes sense (to me, at least).

Resetting it to zero only deletes information (albeit a tiny amount of it) and doesn’t help anything;  you know that the session is up, so the diagnostic for its most recent transition to non-upness is disambiguated.

Debugging broken things is a scramble for bits of data;  leaving a breadcrumb is a polite gift.


Also the text in 6.8.1 says "The diagnostic code specifying the reason for the most recent change in the local session state.". To me that means resetting bfd.LocalDiag to 0 when the state changes to Up.

Thus the language that needs fixing (I know, I wrote it...)


AFAIK IOS-XR and JunOS reset LocalDiag. It'd be good to hear from other implementations.

Probably.  I might have even coded it that way 20 years ago, or someone else did later, thus underscoring the largely-irrelevant nature of this discussion...


Disclaimer: I have no idea what the intention was when the document was written.

I do.

—Dave


Regards,
Reshad (no hat).

On Friday, February 17, 2023, 11:08:43 AM EST, John Scudder <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <glebs=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
>>>>> 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
>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>
>>>>>
>>>>> 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
>>>>>
>>
>