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

Jeffrey Haas <> Thu, 13 April 2023 20:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1900C1522DB; Thu, 13 Apr 2023 13:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uDJ4ZuBKMyjg; Thu, 13 Apr 2023 13:10:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 56452C1524DB; Thu, 13 Apr 2023 13:10:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id B0F901E037; Thu, 13 Apr 2023 16:10:02 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
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: Thu, 13 Apr 2023 16:10:02 -0400
Cc:, rtg-bfd WG <>
Content-Transfer-Encoding: quoted-printable
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: Thu, 13 Apr 2023 20:10:07 -0000


> On Apr 12, 2023, at 1:09 PM, Greg Mirsky <> wrote:
> Dear All,
> after reading the document once more, I've realized that I need help with a paragraph in Section 3. Please find my notes in-lined in the original text below under the GIM>> tag:
>    Once a BFD Unaffiliated Echo session is created on device A, it
>    starts sending BFD Unaffiliated Echo packets, which MUST include BFD
>    Unaffiliated Echo session demultiplexing fields, such as BFD "Your
>    Discriminator" and/or "My Discriminator" defined in [RFC5880].
> GIM>> It seems like the requirement is not clear on which fields must be initialized by the device A - Your Discriminator, My  Discriminator, or both. Furthermore, these fields are characterized as demultiplexing, although the next sentence states that demultiplexing is based on the source IP address or UDP source port number. If that is the case, what is the role of discriminators in demultiplexing BFD Unaffiliated Echo sessions?

The intent here is that this part of the BFD Async machinery is preserved.  My Discriminator is set to the known value, Your Discriminator is zero, and the session proceeds with the device talking to itself and resulting in My Discriminator and Your Discriminator getting the identical value.

We want to avoid re-stating RFC 5880 procedures on this point.  I realize one of your considerations here is likely that some BFD technologies begin by having out of band discriminator advertisement.

Would you find it helpful in illustrating the setup in bullet-point fashion as Aijun mentioned in prior threads?

>    Device A performs its initial demultiplexing of a BFD Unaffiliated
>    Echo session using the source IP address or UDP source port.  
> GIM>> Does the source IP address sufficient to demultiplex BFD Unaffiliated Echo sessions? Consider the case that Interface 1 is connected to a broadcast link. Can there be multiple BFD Unaffiliated sessions off Interface 1?
>    Device
>    A would send BFD Unaffiliated Echo packets with IP destination
>    address destined for itself, such as the IP address of interface 1 of
>    device A.

My expectation is that there would be a single such session to a given destination endpoint simlar to what we see out of the usual BFD 1-hop cases.  It'd be good to see if this matches the expectations of the authors.

> GIM>> Is "such as" in the sentence above used as "for example" or "that is"?
> GIM>> And a general observation on the terminology. It seems like "device A" is used as a short version of "BFD system hosted on device A". If that is correct, perhaps that can be explained in the Terminology section (although it is missing in the current version of the draft).

Reviewing RFC 5880, that RFC tends to use "the system".  While I find "device A/B" to be clear, is it your desire to see "system" to be used for consistency with other RFCs?

-- Jeff