Re: [Technical Errata Reported] RFC5880 (7240)

Hi John, I agree with Jeff's comments. Regards,Reshad. On Tuesday, March 7, 2023, 12:57:28 PM EST, Jeffrey Haas wrote: John, The text below covers what I'd hoped to accomplish with the errata.  Thanks. At some point BFD should consider if we feel like doing the work to move the base

Re: [Technical Errata Reported] RFC5880 (7240)

John, The text below covers what I'd hoped to accomplish with the errata. Thanks. At some point BFD should consider if we feel like doing the work to move the base documents to Internet Standard. -- Jeff > On Mar 6, 2023, at 9:42 AM, John Scudder wrote: > > Once again, we seem to have

Re: [Technical Errata Reported] RFC5880 (7240)

lston ;BFD WG ; > *Date: *2023年02月23日 22:15 > *Subject: **Re: [Technical Errata Reported] RFC5880 (7240)* > Great. I was worried the next step was a document update for this. > > I wish we'd hear from more implementations how they ended up doing this. > > Regards, > Reshad

Re: [Technical Errata Reported] RFC5880 (7240)

Once again, we seem to have come close to something resembling a consensus on this point, other than needing some new text to agree on. To spur discussion, I’ve updated the erratum, but not verified it, pending discussion of my suggested text. I’d verify it as “hold for document update”.

Re: [Technical Errata Reported] RFC5880 (7240)

that helps. Best Regards, Xiao Min Original From: ReshadRahman To: Dave Katz ;John Scudder ; Cc: Jeff Haas ;James Guichard ;Dave Ward ;Andrew Alston ;BFD WG ; Date: 2023年02月23日 22:15 Subject: Re: [Technical Errata Reported] RFC5880 (7240) Great. I was worried the next step

Re: [Technical Errata Reported] RFC5880 (7240)

Great. I was worried the next step was a document update for this. I wish we'd hear from more implementations how they ended up doing this. Regards,Reshad. On Wednesday, February 22, 2023, 02:30:31 PM EST, John Scudder wrote: Further to what I just sent, "is it possible to simply log

Re: [Technical Errata Reported] RFC5880 (7240)

Hi Jeff, I've looked through several active BFD-related drafts and the only one that might be relevant to the discussion is draft-mirsky-bfd-mpls-demand . Although, updating bfd.LocalDiag is not explicitly discussed there. Regards,

Re: [Technical Errata Reported] RFC5880 (7240)

Cool. And I refer once again to the paragraph in the spec about pedantic coders. If the WG actually approves anything that reads the value of the diag field, I guess they can address all of the anomalies and hope for the best… —Dave On Feb 22, 2023, at 2:30 PM, Jeffrey Haas

Re: [Technical Errata Reported] RFC5880 (7240)

"Hold for update" was the expected outcome for my filing of the errata. At best, we're telling new implementors that there's an issue here of note in the protocol. The mail discussion will note that there are multiple existing implementations that have historically set the value to 0 when

Re: [Technical Errata Reported] RFC5880 (7240)

Thanks for the background. I guess the fact of the matter is that, since the issue cannot affect interoperability, it’s hard to imagine getting the WG to go through a bunch of machinations to go out of its way to fix something that is entirely pedantic. In that case I think holding the

Re: [Technical Errata Reported] RFC5880 (7240)

Further to what I just sent, "is it possible to simply log a permanent erratum that explains the ambiguity and encourages people not to worry about it?” Yep. That's basically what I had in mind with "note it in a ‘hold for document update’ erratum”. I don’t really expect anyone to write an

Re: [Technical Errata Reported] RFC5880 (7240)

Hi All, Regarding Jeff’s "Given the maturity of the feature, I'd suggest sticking to the reality on the ground”, I want to step in and remind folks about what our guidelines are for processing errata [1]. They are fairly narrow, by design. One of the high-order bits of the guidelines is,

Re: [Technical Errata Reported] RFC5880 (7240)

I guess the reality is that the diag field is a weak and ambiguous feature that I spent five minutes thinking about, and is ultimately (and happily) not subject to normative verification because it is write-only. The received value is edge-triggerable if you grab the value during the next

Re: [Technical Errata Reported] RFC5880 (7240)

Dave, Just as a reminder, the context for why this errata is being discussed is this inquiry: https://mailarchive.ietf.org/arch/msg/rtg-bfd/YIeCo-nQicI_OIcVncYaJM5Zz6c/ More below: > On Feb 17, 2023, at 12:04 PM, Dave Katz > wrote: >> On Feb 17, 2023, at 8:47 AM, Reshad Rahman >

Re: [Technical Errata Reported] RFC5880 (7240)

How about the following text to replace the description of bfd.LocalDiag (page 27): The diagnostic code specifying the reason for the most recent change in the local session state. This MUST be initialized to zero (No Diagnostic). The intention is to preserve indefinitely the last nonzero

Re: [Technical Errata Reported] RFC5880 (7240)

The spec also includes this: This section discusses the normative requirements of the protocol in order to achieve interoperability. It is important for implementors to enforce only the requirements specified in this section, as misguided pedantry has been proven by experience to

Re: [Technical Errata Reported] RFC5880 (7240)

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 wrote: > > Hm, OK.

Re: [Technical Errata Reported] RFC5880 (7240)

On Feb 17, 2023, at 8:47 AM, Reshad Rahman mailto:res...@yahoo.com>> 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

Re: [Technical Errata Reported] RFC5880 (7240)

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. Also the text in

Re: [Technical Errata Reported] RFC5880 (7240)

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.

Re: [Technical Errata Reported] RFC5880 (7240)

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

Re: [Technical Errata Reported] RFC5880 (7240)

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

Re: [Technical Errata Reported] RFC5880 (7240)

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

Re: [Technical Errata Reported] RFC5880 (7240)

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

Re: [Technical Errata Reported] RFC5880 (7240)

Looks fine. Probably should have stayed in the pool designing a little longer that day. ;-) —Dave On Feb 8, 2023, at 10:00 AM, Dave Ward mailto:dw...@packetfabric.com>> wrote: [External Email. Be cautious of content] No objection On Feb 8, 2023, at 9:58 AM, John Scudder

Re: [Technical Errata Reported] RFC5880 (7240)

SGTM. On Wednesday, February 8, 2023, 12:59:13 PM EST, 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 > wrote: > > The following errata

Re: [Technical Errata Reported] RFC5880 (7240)

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 > wrote: > > The following errata report has been submitted for RFC5880, > "Bidirectional Forwarding Detection (BFD)". > >

[Technical Errata Reported] RFC5880 (7240)

The following errata report has been submitted for RFC5880, "Bidirectional Forwarding Detection (BFD)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7240 -- Type: Technical Reported by: