Re: [Technical Errata Reported] RFC5880 (7240)

Gļebs Ivanovskis <glebs@mikrotik.com> Mon, 13 February 2023 09:37 UTC

Return-Path: <glebs@mikrotik.com>
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 22957C157902 for <rtg-bfd@ietfa.amsl.com>; Mon, 13 Feb 2023 01:37:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=mikrotik.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 bKCvrIkRbtdD for <rtg-bfd@ietfa.amsl.com>; Mon, 13 Feb 2023 01:37:46 -0800 (PST)
Received: from smtp.mt.lv (smtp.mt.lv [IPv6:2a02:610:7501:2000::195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 9458CC153CA0 for <rtg-bfd@ietf.org>; Mon, 13 Feb 2023 01:37:45 -0800 (PST)
Received: from [IPV6:2a02:610:7501:ffff:27db:d9f1:da1:b49e] (unknown [IPv6:2a02:610:7501:ffff:27db:d9f1:da1:b49e]) by smtp.mt.lv (Postfix) with ESMTPSA id 33AD91510F; Mon, 13 Feb 2023 11:37:41 +0200 (EET)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.mt.lv 33AD91510F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mikrotik.com; s=20221206; t=1676281063; bh=Cj/gHb51CsihoF8knnHw65ExyPbPRi/3Gu8gidUKIKE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Zi+YMcB9Rqm608gduu4d1BkOgi88arkPeeWNlLLKkU3TLYDA0lUWwnqSk8iOxpdIK BSlUodQKUr7swyfc9emckm6OkmNC2rlRmBhvYoKnZcOy+/NUczV6hMSUSGpiQAxXDv wHIehxD6wuhmXnDClMtbjb+kC6pyIwQFE4/u7UteYREkqwYTxuaQc9ytwzs9pNxK9C WNTSRxtKoancYhQr66Dp9XJq6TT2tyFiWW9S5TyMBTsuknN++1KS/x0RBTbV8FoVpx d2jNwYbdNsaJijbHZ7dLQdaNCBZiEPv+IzRsu8GIrnbDZQbAk1VL19LzgwVl9edb24 NeXUn3ycDBYSg==
Content-Type: multipart/alternative; boundary="------------c328bnzhabGNVOR0qO3IKHVa"
Message-ID: <e0b5cdbb-ae89-36d2-773e-313c8ca78d3d@mikrotik.com>
Date: Mon, 13 Feb 2023 11:37:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1
Subject: Re: [Technical Errata Reported] RFC5880 (7240)
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>, BFD WG <rtg-bfd@ietf.org>
Cc: Jeff Haas <jhaas@juniper.net>, Dave Katz <dkatz@juniper.net>, James Guichard <james.n.guichard@futurewei.com>, Dave Ward <dward@packetfabric.com>, Reshad Rahman <reshad@yahoo.com>, Andrew Alston <andrew-ietf@liquid.tech>
References: <20221106092717.8864310D74@rfcpa.amsl.com> <A89A4B51-3E68-436C-A2B0-03A030608CB9@juniper.net>
Content-Language: en-US
From: Gļebs Ivanovskis <glebs@mikrotik.com>
In-Reply-To: <A89A4B51-3E68-436C-A2B0-03A030608CB9@juniper.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/33t8gbzsJLC9BNerfS71c_sFSjs>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2023 09:37:53 -0000

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<rfc-editor@rfc-editor.org>  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<jhaas@juniper.net>
>>
>> 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