Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check Fri, 14 April 2023 03:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDEAEC13AE37; Thu, 13 Apr 2023 20:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3lNXocoZkTkV; Thu, 13 Apr 2023 20:20:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5720C1524C8; Thu, 13 Apr 2023 20:20:00 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4PyMBj45hsz8RTWg; Fri, 14 Apr 2023 11:19:57 +0800 (CST)
Received: from ([]) by with SMTP id 33E3JoRP080125; Fri, 14 Apr 2023 11:19:50 +0800 (+08) (envelope-from
Received: from mapi (njy2app08[null]) by mapi (Zmail) with MAPI id mid201; Fri, 14 Apr 2023 11:19:51 +0800 (CST)
Date: Fri, 14 Apr 2023 11:19:51 +0800
X-Zmail-TransId: 2b006438c657ffffffffee6-614bc
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 33E3JoRP080125
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6438C65D.001/4PyMBj45hsz8RTWg
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: Fri, 14 Apr 2023 03:20:08 -0000

Jeff, Greg,

Please see inline...


From: JeffreyHaas <>
To: Greg Mirsky <>;
Cc: <>;rtg-bfd WG <>;
Date: 2023年04月14日 04:10
Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

> 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.
 [XM]>>> My expectation is the same to Jeff. Besides, ZTE's implementation allows for multiple BFD Unaffiliated sessions off Interface 1, differentiated by IP addresses (both DA and SA), so the answer to Greg's question is Yes, although there is no real use till now.

Best Regards,

Xiao Min

> 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