Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

Jeffrey Haas <> Wed, 12 April 2023 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E64EC14CE40; Wed, 12 Apr 2023 08:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yiw2hb-ehtZH; Wed, 12 Apr 2023 08:00:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 995F4C14CE45; Wed, 12 Apr 2023 08:00:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 7D3091E037; Wed, 12 Apr 2023 11:00:25 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_096DFDCB-4189-4793-991F-07950FB45AD6"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check
From: Jeffrey Haas <>
In-Reply-To: <>
Date: Wed, 12 Apr 2023 11:00:25 -0400
Cc:, rtg-bfd WG <>
Message-Id: <>
References: <> <>
To: Greg Mirsky <>
X-Mailer: Apple Mail (2.3696.
Archived-At: <>
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: Wed, 12 Apr 2023 15:00:30 -0000


Flipping the question around somewhat: 

These portions of the PDU will be serialized onto the wire.
An implementation could choose values locally to help its own procedures.  Perhaps for heuristic tuning of the session.  So, there's argument for "these values are left to the implementation" - or as you note "this value is ignored".  

What text would YOU want to see present in this draft?

In the absence of an implementation having an opinion about the behavior for its own purposes, I believe we want some boring "expected" value minimally as implementation advice.  IMO, that's one step nicer than whatever memory noise is left from your allocated buffer that might disclose something unexpected from your implementation internals.  (See various virtualized host environment bugs relating to memory ownership.)

-- Jeff

> On Apr 12, 2023, at 10:22 AM, Greg Mirsky <> wrote:
> Dear, Authors and all,
> my apologies for the belated comments. I greatly appreciate your consideration of the notes below:
> Given that it is stated that the values of "Desired Min TX Interval" and "Required Min RX Interval" in an Unaffiliated BFD Echo message are ignored, what do you see as the value of using the normative language in:
>    Within the BFD Unaffiliated Echo packet, the "Desired Min TX
>    Interval" and "Required Min RX Interval" defined in [RFC5880] SHOULD
>    be populated with a value of 1 second (1,000,000 microseconds).
> As I understand it, the "Required Min Echo RX Interval" value is not used in the Unaffiliated BFD Echo. If that is the case, what do you see as the value of requiring it to be zeroed:
>    The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set
>    to zero.  
> Perhaps stating that the "Required Min Echo RX Interval" value is ignored in the Unaffiliated BFD Echo is sufficient. WDYT?
> Regards,
> Greg
> On Mon, Apr 10, 2023 at 8:27 AM Jeffrey Haas < <>> wrote:
> <>
> Working Group,
> The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has completed.  My judgment is that it has weak, but positive support to proceed to publication.  This isn't atypical of BFD work at this point in the BFD Working Group's life.  
> The next steps for the document:
> 1. Please continue to iterate through the issues raised during last call.  I will be summarizing them in the original WGLC thread.  I suspect we can reach conclusion for them shortly.
> 2. Each of the authors needs to make an attestation as to whether they're aware of any additional IPR applicable to this document.  The rest of the Working Group, as per BCP 78/79[1] should also disclose of any applicable IPR if they're aware of it.
> One thing that makes this document particularly interesting is that this work is covered partially under work done in BBF in TR-146.  This will be noted in the shepherd writeup.
> -- Jeff
> [1] <>