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

Jeffrey Haas <> Sat, 22 April 2023 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF341C1516EB; Sat, 22 Apr 2023 08:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 bZRBHcSiaLae; Sat, 22 Apr 2023 08:57:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B8504C152DA3; Sat, 22 Apr 2023 08:57:45 -0700 (PDT)
Received: by (Postfix, from userid 1001) id DFB3E1E039; Sat, 22 Apr 2023 11:57:44 -0400 (EDT)
Date: Sat, 22 Apr 2023 11:57:44 -0400
From: Jeffrey Haas <>
To: Greg Mirsky <>
Cc:, rtg-bfd WG <>
Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check
Message-ID: <>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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: Sat, 22 Apr 2023 15:57:46 -0000


On Fri, Apr 14, 2023 at 04:05:14PM -0700, Greg Mirsky wrote:
> I am not trying to stop this work but understand what is being standardized
> by this document. So far, I don't see that there's anything that goes
> outside of the BFD system that transmits self-addressed IP/UDP packets. The
> fact that there are implementations using self-addressed IP/UDP packets
> seems like a weak argument for standardization, especially since there's no
> interoperability among network systems to be defined. Of course, that is my
> personal opinion.

At this point I must come to the conclusion that you understand exactly what
is in this document.  You are, of course, welcome to not like it.

If you'd prefer to take your preferences on this as a point of objection to
this being Standard Track rather than Informational, that's a reasonable
point to raise for IESG review.  I'm happy to make note of that in the
shepherd's writeup, if you like.

> On Fri, Apr 14, 2023 at 3:31 PM Jeffrey Haas <> wrote:
> > The Discriminator field is used for demux.  Authentication is utilized, if
> > present.
> >
> GIM>> My understanding of the draft in regard to the use of the
> Discriminator (I assume My Discriminator) field is different. Although the
> draft refers to the Discriminators as "demultiplexing fields":
>    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].
> it later states that demultiplexing is done based on IP and UDP
> encapsulation:
>    Device A performs its initial demultiplexing of a BFD Unaffiliated
>    Echo session using the source IP address or UDP source port.
> Am I missing something?

You are likely not paying sufficient attention to the "initial" word in this

The procedures in this document run the state machine in a way similar to
other BFD mechanisms that haven't replaced that state machine, such as

Thus, as per RFC 5880, §6.3:
:    The method of demultiplexing the initial packets (in which Your
:    Discriminator is zero) is application dependent, and is thus outside
:    the scope of this specification.

and the immediately preceding paragraph:

:    Once the remote end echoes back the local discriminator, all further
:    received packets are demultiplexed based on the Your Discriminator
:    field only (which means that, among other things, the source address
:    field can change or the interface over which the packets are received
:    can change, but the packets will still be associated with the proper
:    session).

If you believe a reminder of this detail is appropriate in the document,
consider sending text covering the point.  That said, I'd suggest delaying
until the authors have integrated the prior comments, which also include
more clearly labeling the contents of the packets in their text.

-- Jeff