From nobody Thu Feb 23 06:15:38 2023 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E213EC151701 for ; Thu, 23 Feb 2023 06:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4ewauxHdE5V for ; Thu, 23 Feb 2023 06:15:34 -0800 (PST) Received: from sonic313-13.consmr.mail.bf2.yahoo.com (sonic313-13.consmr.mail.bf2.yahoo.com [74.6.133.123]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF01C1522AF for ; Thu, 23 Feb 2023 06:15:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677161727; bh=1D7mlTzZ6g3wlhy+24rr0kVDQfMhZxwNQ3Pxsf7rh98=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=emD3Sy+zC1xp78Ba5CnsQUj62dnFYbIZLUBEqS7paDjBRcLncJuONDtKhxwWMeWuoNrfMQeFOq+eU9Rr+Z25jXZus8pJUgm6EGg/qHZkvFXKwcdGEGi3oR0jUf5NSKPThyi8k7fLXQ9l1fE7HPkQw+UUtswJCilafIUdlVYOC6DOq/JLVA/VQcaiOE2DefCIiMP55r7yBbzulfnTBZ/+6w+ciqIh8QyH+vqwYCu+LuMNHkcWZxVKMqNjr4Twu6wDinR5vzYzsb5Wws9POaoBYQG6n8gYtqO+9aVz5H95d75suvfkE3cEQ08Ztxc8n3JNhSA9UGYM8Tx/6HtRM+yphg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677161727; bh=cOR4W44l3JHKbirxS1GcQJAiCNjDdc/LSDqcQYnulxa=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=hprSqoEYudCbdDwpmMyrRRsnwf+4s8z0VjVkmMfsIfyiGBAJdaAQQuW0TIjguZzFqaWPrqF5Xe3T/paP1DoPcsfMC0ecfzntaM1tP2b+lKIjRn65twvzrf8ENLH3TUgf3k2zUabFGq8n3AgV6A+dTd0LvVlsDb9jxK2oquVbs+aqFUamkgutocK9lQBXCuaaBaQb3PpfInzuwXyh/KyfmujOfdCTgH2JCWWmO5z66gN5WlJmsjx3z4DgPfJCp/022Xqb7eW9Yeywrt5RGYMdDOM1DBVIT10XhL1OvZHvZqkWF7Agg7dOMIKQrfByNThJtdJson7Ux2nff/6pj/Rtzw== X-YMail-OSG: U_DtvewVM1liE5Wf_yF9VGlwvTb2h9ao2mYFuSgrO_uwq1uMLQitfbUG6ckWnju rmzhAzkv6_BcAtHotpHE0BwUTP3ZV65EvVTEH6A4BSsWvABdSmMTbMDgBqrfbZI3VQPywryzIRPY XOZ00YId3E0KnP8559r_2t7SJFO.zgmqgx5l6.c_bePTGi0ZGYCYiIF3A30hvd_MP2WJRCZO.cqE z6S3oKeM7.hHBRE6VKOLSL9kzOHdPUWVF5C8PKGNJtO_oUIRoJlV1D25Lcl2xwgTMPCuNJeKlbSa veWLSRMIC59WOozIFxWK.ZfFiIaXCThSCpXZxkC.BZEvRMZMRABkykSAonlnDH4bLo.vdPujmTSC wJ_9GWUzIZp1MDOBvDEdfPusg24Q6bxmzzbs77WQSOimisBjVxwOZpXd.JP.FYN3eYunYeA0IWlA ARL2jwU2Y2ljj2bUUT58wrPpemwZL5P2e4xOM6yo7Z_zSDVPsAOs7eI3uBx8xxzpRCdVV0TvLgV8 10g4DeCkHVaGALzqqqcmrmW2Ji32WLadtPs7C9k81lqyQdLTctQLVpoPxAVdQqtoUpgu.t7M3s8Y xPdl6ZaDJ6rfUUvBXNoXjkceDlHxOr_DsR0nPovXynX58q9keKifs9tRZgplsHY0sJIy27xn5JHs MqnFAbD6akOPVqAga9pvYL3kE.pepHSBejI2vluGjMHFYPZFEbwZ2NtmoOAdQTQy4UMHmZM1BLm5 9YM14QZ_ojNbPuVtXG8L411HOPIt62D9sxWkUnfoYmZRRZN.W09uqJ7Q3xBa8VEA23CtL4pl.CKd Nnq2SJbJ8OZCOhs8yo8LJTNxVsYZPrURsZwQF2XWlhVrA9lLnKThdLjy6yeYfVFisf7SHcFahzUE F0f_IyovNCrBIy5r03rdts_VgKqn3wxJBSrnJyEZQc3woI0NY8QQfhbgrQJ.R1Pp.vsu0dls5hWh BiWPokm1lB76NGv1iXdo7OKmCwhEiKVoSDNDZNaFsQm5m.k9yRJRWg89aUiPceu1hTpzzfqaj8aD NfUr3eehF0tf1uFwuTQdjEWF2wcFV6bYf_2OjEp_91JBAs4phwMHQ5vxd_h1m.XplivA1ML4GYd1 t0BxQxN7XTaut_3ScUOwca_tnKzrnh9lMFeOP74DqLBSpuIyU7yG72mOIZ8.TwwU4xx.1PPWtVj8 9a8ipkF6excPhkdVpT8.7ITDWPoI8pWymYFmr6QyreNJDiSLEOBMEA5I_uk7BILqr2n7aYhjI5lS 9EnV7D5YU.v8LhCTr0Gqv3eZacGJNpc4VrBKj9B5PkeqF5Vsu9lN.P6wr_dxYckrFksjl1A9kG9I bqswz2XnYd39l10nNZueCzamxpGuiax4dri3xj3D0aiGGxZyr3OWA1hIvqncQlLonHYw7NeT1mR9 ErqkYwINZG40ll3diNKZhk46GdWiy_HsEeq3W7a6r5wwG6pOYlMTGt9n4FCoG336unMgkbxrsChb WcrzKe5gXdWeSUvJRS1STr2XXRP.keH_d4kesQYgxSxyOmv0oVe7bp8zon0LamNodkGYg0kf8xTI h8DwOkhegzcREoF3UeAQCTfBKNiWduQQBXpvJprXSSZNV73h9v0cCfyNN.YjzsxGeB7wjo8OZeFn JBeurq6NqOfib51j1ZA0BokEWPJan2lclDfYDrNmsJpA0P2QuD_Y9ysklZZ_awkzbQBTQxe64J00 HVL6WESK_iVdiZFjH8YJeM3w_zMcjhu4iKEzhIaIdfhXpkwuxdcOURT8VigyaUJG.Aa_ZEgvapnP L52DE60GSP5UV0.pu.9woKDddkPejkW9FH84H6wJCvOynFUq_srdcmaJCuZ_r.Ipy9eUH0mVmZ9. bYL30cxlOOm1yxsjXeHPMDUEIAyNMFlY7FCvyX_ky7AGIu4aze2jJygGZWfoNGnqMOjhoD6F.zEQ Z3P7XjqKYpQb2DkHNhtzOvLVXsIIgsTkvRPsgqRcxae2u2e5JzMnCa0VNZwKJyFh.k1wzjM32iCB UKxP87TNI6_5vh_rjYn39n6uSY7nJmK2dDKORvx.tyCmCGvNFIjW5AObxRsOKK.6Eaol4BuCoDyP Ua.ic7fGA1UF6HaMJ9.TREPBVsw_Mqac2VMioBLlhp996247t2u6rSzBoQJeRyWj6gG.1FFohWqV i04qJqsc8jmaXWjsC48mfbOoDQywywMXOYVlxf.dnyN7TZ4LC7ZCpH8MDdvi9ruKGPBSqQRoF2Tl MxM_Smb0vvjx0PVfb09I_wY4Fcs58f7STzgHlUa9WVHa3eb70bFpj2ULl0jsdwYrlSQfkeR8NA2N w3uCILjFKRFMiGw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Thu, 23 Feb 2023 14:15:27 +0000 Date: Thu, 23 Feb 2023 14:15:25 +0000 (UTC) From: Reshad Rahman Reply-To: Reshad Rahman To: Dave Katz , John Scudder Cc: Jeffrey Haas , Jeff Haas , James Guichard , Dave Ward , Andrew Alston , BFD WG , =?UTF-8?Q?G=C4=BCebs_Ivanovskis?= Message-ID: <4244983.3124699.1677161725414@mail.yahoo.com> In-Reply-To: <6DA3FC66-3EA4-499B-81EF-700EF97EE2F6@juniper.net> References: <20221106092717.8864310D74@rfcpa.amsl.com> <1724793752.1746968.1676652430474@mail.yahoo.com> <3397B7B2-7AD4-475F-90FA-03D8E882AE3C@juniper.net> <167960D8-14F3-4013-996D-68C6FA14325F@juniper.net> <6DA3FC66-3EA4-499B-81EF-700EF97EE2F6@juniper.net> Subject: Re: [Technical Errata Reported] RFC5880 (7240) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3124698_621623520.1677161725409" X-Mailer: WebService/1.1.21183 YMailNorrin Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2023 14:15:38 -0000 ------=_Part_3124698_621623520.1677161725409 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: =20 =20 Further to what I just sent, "is it possible to simply log a permanent erratum that explains the ambigui= ty and encourages people not to worry about it?=E2=80=9D Yep. That's basically what I had in mind with "note it in a =E2=80=98hold f= or document update=E2=80=99 erratum=E2=80=9D. I don=E2=80=99t really expect= anyone to write an Internet Draft to formally update RFC 5880, although I = wouldn=E2=80=99t object to someone doing so if they wanted to do the work, = the doc itself would probably just be a few pages (the email thread discuss= ing it would inevitably be longer). But an erratum to at least say =E2=80= =9Csome people do it one way, some do it another, that=E2=80=99s life=E2=80= =9D is worth having and I will gladly verify one. =E2=80=94John > On Feb 22, 2023, at 2:12 PM, Dave Katz wrote: >=20 > I guess the reality is that the diag field is a weak and ambiguous featur= e that I spent five minutes thinking about, and is ultimately (and happily)= not subject to normative verification because it is write-only. >=20 > The received value is edge-triggerable if you grab the value during the n= ext session establishment phase (you get at least one packet from the other= guy prior to the session coming Up), so I suppose one could change the lan= guage to zero the local value on the Up transition as suggested without los= ing the (mis)feature altogether.=C2=A0 If that=E2=80=99s the case, I would = add a sentence in the field description saying that the received diag value= refers to the previous session when received in a packet bearing a state o= ther than Up.=C2=A0 Of course this means that the value received with Up is= ambiguous, because it could be referring to the previous session or the cu= rrent one, depending on how it was implemented, but that=E2=80=99s already = the case. >=20 > Or is it possible to simply log a permanent erratum that explains the amb= iguity and encourages people not to worry about it?=C2=A0 It=E2=80=99s alre= ady taken up more time than it is worth, considering that it cannot affect = interoperability (and so I suppose never should have been normative, but we= =E2=80=99d probably still be discussing it anyhow). >=20 > Thanks, >=20 > =E2=80=94Dave >=20 >=20 >> On Feb 22, 2023, at 8:14 AM, Jeffrey Haas wrote: >>=20 >>=20 >> [External Email. Be cautious of content] >>=20 >>=20 >> Dave, >>=20 >> Just as a reminder, the context for why this errata is being discussed i= s this inquiry: >> https://mailarchive.ietf.org/arch/msg/rtg-bfd/YIeCo-nQicI_OIcVncYaJM5Zz6= c/ >>=20 >> More below: >>=20 >>=20 >>> On Feb 17, 2023, at 12:04 PM, Dave Katz wrote: >>>> On Feb 17, 2023, at 8:47 AM, Reshad Rahman wrote: >>>> 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 kee= p 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. >>>=20 >>> That property helped me when debugging my implementation, as it survive= s the restart/reboot of the far end. >>>=20 >>> There is also no timeout that would make sense;=C2=A0 =E2=80=9Cforever,= for small values of =E2=80=98forever'=E2=80=9D is semantically consistent = and the only thing that makes sense (to me, at least). >>>=20 >>> Resetting it to zero only deletes information (albeit a tiny amount of = it) and doesn=E2=80=99t help anything;=C2=A0 you know that the session is u= p, so the diagnostic for its most recent transition to non-upness is disamb= iguated. >>>=20 >>> Debugging broken things is a scramble for bits of data;=C2=A0 leaving a= breadcrumb is a polite gift. >>=20 >> From my perspective, the breadcrumb is useful to note during the transit= ions, and not simply the transitions for the state.=C2=A0 Examples have bee= n given where the diag is updated as part of a state transition (governed b= y normative text in 5880), or transitions that may happen while the session= remains up (e.g. concatenated path down, echo, etc.).=C2=A0 The RFC isn't = great about saying how you clear such things when the state is still Up; in= tuitively it's to return to "No Diagnostic". >>=20 >> However, your own leaning, Dave, is "leave it set forever".=C2=A0 Using = the above examples for diag signaling an event while leaving the state up, = I don't think you mean that. >>=20 >> So, again, the interesting breadcrumbs are when Things Change.=C2=A0 Eac= h of these items is an edge transition of note. If I care about the event, = I care about it when it happens and will remember it.=C2=A0 I'm not going t= o look at diag to reflect this forever. >>=20 >>>=20 >>>>=20 >>>> 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. >>>=20 >>> Thus the language that needs fixing (I know, I wrote it...) >>>=20 >>>>=20 >>>> AFAIK IOS-XR and JunOS reset LocalDiag. It'd be good to hear from othe= r implementations. >>>=20 >>> Probably.=C2=A0 I might have even coded it that way 20 years ago, or so= meone else did later, thus underscoring the largely-irrelevant nature of th= is discussion... >>=20 >> I did confirm with Juniper's BFD developers that it's reset to 0 when we= transition to Up.=C2=A0=20 >>=20 >> Given the maturity of the feature, I'd suggest sticking to the reality o= n the ground. >>=20 >> -- Jeff >>=20 >=20 =20 ------=_Part_3124698_621623520.1677161725409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great. I was worried the nex= t step was a document update for this.

I wish we'd hear f= rom more implementations how they ended up doing this.

Re= gards,
Reshad.

=20
=20
On Wednesday, February 22, 2023, 02:30:31 PM EST, John = Scudder <jgs@juniper.net> wrote:


Further to what I just sent,

"is it possible to simply log = a permanent erratum that explains the ambiguity and encourages people not t= o worry about it?=E2=80=9D

Yep. That's basically what I had in mind with "note it in a =E2=80=98h= old for document update=E2=80=99 erratum=E2=80=9D. I don=E2=80=99t really e= xpect anyone to write an Internet Draft to formally update RFC 5880, althou= gh I wouldn=E2=80=99t object to someone doing so if they wanted to do the w= ork, the doc itself would probably just be a few pages (the email thread di= scussing it would inevitably be longer). But an erratum to at least say =E2= =80=9Csome people do it one way, some do it another, that=E2=80=99s life=E2= =80=9D is worth having and I will gladly verify one.

=E2=80=94John

=
> On Feb 22, 2023, at 2:12 PM, Dave Katz <dkatz@j= uniper.net> wrote:
>
> I guess the reality is that the diag field is a weak and ambi= guous feature that I spent five minutes thinking about, and is ultimately (= and happily) not subject to normative verification because it is write-only= .
>
> The receiv= ed value is edge-triggerable if you grab the value during the next session = establishment phase (you get at least one packet from the other guy prior t= o the session coming Up), so I suppose one could change the language to zer= o the local value on the Up transition as suggested without losing the (mis= )feature altogether.  If that=E2=80=99s the case, I would add a senten= ce in the field description saying that the received diag value refers to t= he previous session when received in a packet bearing a state other than Up= .  Of course this means that the value received with Up is ambiguous,= because it could be referring to the previous session or the current one, = depending on how it was implemented, but that=E2=80=99s already the case.
>
> Or is it poss= ible to simply log a permanent erratum that explains the ambiguity and enco= urages people not to worry about it?  It=E2=80=99s already taken up mo= re time than it is worth, considering that it cannot affect interoperabilit= y (and so I suppose never should have been normative, but we=E2=80=99d prob= ably still be discussing it anyhow).
>
> Thanks,
>
<= div dir=3D"ltr">> =E2=80=94Dave
>
>
>> On Feb 22, 2023,= at 8:14 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>>
>>
>> [External Email. Be cautious of content]
>>
>>
= >> Dave,
>>
>> Just as a reminder, the context for why this errata is being dis= cussed is this inquiry:
>>
=
>> More below:
>&= gt;
>>
>>= > On Feb 17, 2023, at 12:04 PM, Dave Katz <dkatz=3D40juniper.= net@dmarc.ietf.org> wrote:
>>>>= ; On Feb 17, 2023, at 8:47 AM, Reshad Rahman <reshad@yahoo.com> wrote= :
>>>> Having the diag field as bread= crumb has been extremely useful indeed. But both ends can store last diag f= ield 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 implementat= ion, as it survives the restart/reboot of the far end.
>>>
>>> There is also no= timeout that would make sense;  =E2=80=9Cforever, for small values of= =E2=80=98forever'=E2=80=9D is semantically consistent and the only thing t= hat makes sense (to me, at least).
>>> <= br>
>>> Resetting it to zero only deletes in= formation (albeit a tiny amount of it) and doesn=E2=80=99t help anything;&n= bsp; you know that the session is up, so the diagnostic for its most recent= transition to non-upness is disambiguated.
>&= gt;>
>>> Debugging broken things is = a scramble for bits of data;  leaving a breadcrumb is a polite gift.
>>
>> From = my perspective, the breadcrumb is useful to note during the transitions, an= d not simply the transitions for the state.  Examples have been given = where the diag is updated as part of a state transition (governed by normat= ive text in 5880), or transitions that may happen while the session remains= up (e.g. concatenated path down, echo, etc.).  The RFC isn't great ab= out saying how you clear such things when the state is still Up; intuitivel= y it's to return to "No Diagnostic".
>>
>> However, your own leaning, Dave, is "leave= it set forever".  Using the above examples for diag signaling an even= t while leaving the state up, I don't think you mean that.
>>
>> So, again, the inter= esting breadcrumbs are when Things Change.  Each of these items is an = edge transition of note. If I care about the event, I care about it when it= happens and will remember it.  I'm not going to look at diag to refle= ct this forever.
>>
>>>
>>>>
>>>> Also the text in 6.8.1 says "The diagnostic c= ode specifying the reason for the most recent change in the local session s= tate.". To me that means resetting bfd.LocalDiag to 0 when the state change= s to Up.
>>>
= >>> Thus the language that needs fixing (I know, I wrote it...)
>>>
>>>= ;>
>>>> AFAIK IOS-XR and JunOS re= set LocalDiag. It'd be good to hear from other implementations.
>>>
>>> Probabl= y.  I might have even coded it that way 20 years ago, or someone else = did later, thus underscoring the largely-irrelevant nature of this discussi= on...
>>
>>= ; I did confirm with Juniper's BFD developers that it's reset to 0 when we = transition to Up. 
>>
>> Given the maturity of the feature, I'd suggest stickin= g to the reality on the ground.
>>
>> -- Jeff
>>
=
>

------=_Part_3124698_621623520.1677161725409--