Re: BFD chair response to presentation on draft-mirmin-bfd-extended

Greg Mirsky <> Fri, 22 November 2019 04:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E82161200B2; Thu, 21 Nov 2019 20:40:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v5k6hnN3Ol7Q; Thu, 21 Nov 2019 20:40:54 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E868B12006E; Thu, 21 Nov 2019 20:40:53 -0800 (PST)
Received: by with SMTP id p18so5778607ljc.6; Thu, 21 Nov 2019 20:40:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PSWNbP3uuVVKFrme0t1iicq9q/YXwN4faSDI7Y/9aCc=; b=eVPsTtOTwIUTUaB5BFo9ZbwGdAe4Arj5Od5Rpq44ZmbSVc2ooqJwmLQ4fGIj86AmkH qSC0OElJXZC2m6pdvTFQLkpqSYcAGuqs7NpY51XTNt4WVufrsm2mUn694lAReswJh2pG 6jaUCnJndaSdSZqgdskQ5dPifTZQA6dAaGh9wgRmBfGhiOCV1nC0u7AJD2usLzKgR2MQ sVis5lXh2rnWYqASfOUi5g6ugKZRx5ZK680w8pz6IdnGbeyXPlVt7BrW9OmOkZv7/LGz pTCRSBClva8x+U0rAO3HI0poAhKafmsAn5eQ/dESF+SxqH/79pOxYonE6zAhfK+hq8N5 EFPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PSWNbP3uuVVKFrme0t1iicq9q/YXwN4faSDI7Y/9aCc=; b=m7xR+bWacyfuGn9nIx9tKb0faCo50ipTIsRo+NF4lSOhuygxKDOU63E9H7CCnwPFHT Pr3EPq/3Kra5I1gvtJg0eCuXl9WuDILATJU0xhfe8jCVEmlw3WH57F9cZr7XFtJQDyCP tUtDhEeQkoblvcXqUJiq8KpKY8aPxA9BJLNY/ba6vAmtcKWqKwAu5kNVvkO95KEuEpQM Uhz0F6R2+weM/7X8K0ICz4hhKAzjyGypjxPfdm5K1FxDhztX+O8yIuTkL3zvT+tCN7Rv Mtdw5B7BEgntf45yIIOstNyULgEBb3KINtEmTvMBgFR8hIZEzG4sYrJl+MrWLxbO0MbZ 6FlA==
X-Gm-Message-State: APjAAAWWrRl6iPJ2i+u5nojSCUKkD8KKhtpmKgAPWcqo59V5Nv0Iy3uP XcQydbsvV0uF8UFZZC7ogdSyYXyf6VPbbLTa9Ug=
X-Google-Smtp-Source: APXvYqxYDWm5CaSRrSI7qabuaLyRyP6THwqL209z8ZKfPwHu2yvOzLf6Q6sYePWaTXYzD60T/ZbFQmE5fSXSqq9lx50=
X-Received: by 2002:a2e:7013:: with SMTP id l19mr10378631ljc.201.1574397651838; Thu, 21 Nov 2019 20:40:51 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Fri, 22 Nov 2019 12:40:40 +0800
Message-ID: <>
Subject: Re: BFD chair response to presentation on draft-mirmin-bfd-extended
To: "Rakesh Gandhi (rgandhi)" <>
Cc: Jeffrey Haas <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000c5eced0597e804a8"
Archived-At: <>
X-Mailman-Version: 2.1.29
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, 22 Nov 2019 04:40:57 -0000

Hi Rakesh,
thank you for sharing your thoughts about this work. Please find my notes
in-line tagged GIM>>.


On Fri, Nov 22, 2019 at 11:28 AM Rakesh Gandhi (rgandhi) <>

> Hi WGs,
> This was greatly discussed in the BFD WG meeting in Montreal, and that
> there was NO support to complicate the BFD for IPPM use-cases.

GIM>> The draft was presented to RIFT WG some number of meetings ago. The
feedback received was that the ability to use a single OAM protocol for the
failure detection and loss measurement is of interest.

> There are number of existing protocols (OWAMP, TWAMP, RFC6374, STAMP,
> IOAM, etc.) designed, implemented and deployed for IPPM use-cases already.
> I am surprised that the text is still present in the latest version (02) of
> the draft (Section 3.4) and presented in another WG.
GIM>> I will remind that this is the individual draft. If you feel strongly
that some content should be removed, please ask WG Chairs for WG Adoption
Poll. Once the draft is adopted, hen, by all means, the WG will define the
scope, add/remove sections.

> Thanks,
> Rakesh
> On 2019-11-22, 10:49 AM, "Rtg-bfd on behalf of Jeffrey Haas" <
> on behalf of> wrote:
>     In the interest of permitting the presentations to move smoothly at
> this
>     Friday's rtgwg session, I withheld my comments from microphone.
> However,
>     please consider these comments for the record for IETF-106.
>     Firstly, I'm surprised the chairs had a BFD presentation at rtgwg.
> rtgwg is
>     indeed intended to be a general purpose dispatch group for work
> without a
>     home, but that's not the case for BFD.
>     Secondly, Reshad and I intentionally did not schedule work on BFD
> extension
>     work, including Greg's presentation, for this IETF.  This is because
> there
>     is open charter discussions we're starting with the IESG on this space.
>     -----
>     Specific comments on BFD extension work and the charter discussions:
>     During prior IETFs, and culminating at IETF-105, we've seen regular
> work to
>     try to stuff BFD with additional features of various forms.  The
> litmus test
>     generally used for BFD's core use case over the years has been "what
> do you
>     want to hear every 3.3ms?"  To that end, things that enhance BFD's core
>     continuity verification uses cases have ended up in the protocol.
>     Somewhat similar to other popular protocols such as DNS and BGP, BFD
> has
>     nice properties that make it an appealing place to try to extend.  In
>     particular, it's a continuing conversation between two systems.
>     During IETF-105, the IPPM group members attending explicitly noted
> that they
>     did not want to see their mechanisms present in BFD and did not
> consider it
>     a good fit.
>     As part of that discussion, the chairs noted that one option
> potentially
>     open is that we permit the "BFDv2" option we have discussed at
> IETF-105 and
>     previous to permit an option where we do not use the core BFDv1
> session used
>     for continuity for these extensions, and use a different protocol
> version
>     and port set to enable the other use cases.
>     Thus, the discussion with the IESG is whether BFD hands over the
> "gift" of a
>     general and mature mechanism for a conversation between two systems
> that may
>     be generally extended to carry "interesting" information.
>     This addresses Tony Li's point about "please don't make BFD difficult
> to
>     implement in hardware".
>     -----
>     Specific comments on draft-mirmin-bfd-extended:
>     The somewhat peculiar extension mechanism shown in Greg's draft was
>     originally seeded by work I started in BFD for
> draft-ietf-bfd-large-packets.
>     In fairness to history, this was similar to work that was done in OSPF
> years
>     back for how the authentication mechanism was spliced onto the
> protocol.
>     The one sentence description of that use case is "make the packet
> padded to
>     test MTU".  It's a hack, but one that does a reasonable job of its use
> case.
>     However, with regard to leveraging this hack for a general purpose
> extension
>     mechanism, I don't find it a good fit.  BFDv1 does not expect to find
>     information regarding the packet or state machine outside of the main
> PDU.
>     It is likely a new version number will need to be used to establish
> future
>     semantics.  (Per prior discussion in the working group.)
>     The capabilities mechanism will likely require either integration into
> some
>     form of an updated state machine for the new version header, or a
> different
>     form.  IMO, I find it likely that a "capability advertisement"
> mechanism
>     would be necessary rather than negotiation to avoid a wholesale
> replacement
>     of the BFD state machinery.  And if we replace that much of the
> machinery,
>     let's just stop calling this BFD at all and move on.
>     With regard to IPPM style content for the draft, I refer you to the
>     members comments above from IETF-105.
>     With regard to authentication, there are two possibilities here:
>     - Faster authentication of BFD style packets is covered by work
> completing
>       BFD WGLC draft-ietf-bfd-optimitizing-authentication.  I'd encourage
> other
>       working groups in need of a faster per-packet authentication
> mechanism to
>       consider whether it's an appropriate fit.
>     - In the case that such a future BFD, or mechanism built on similar
>       machinery, want a way to autenticate the payload different from the
>       headers, there will likely need to be discussion about not only what
>       envelope is used, but also strength vs. periodicity.  (And if you
> don't need
>       this stuff periodically, why use something like BFD?)
>     -- Jeff