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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61248120103; Thu, 21 Nov 2019 20:49:36 -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 pLqy9VKMqld0; Thu, 21 Nov 2019 20:49:34 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF0AF12002F; Thu, 21 Nov 2019 20:49:33 -0800 (PST)
Received: by with SMTP id r15so1527025lff.2; Thu, 21 Nov 2019 20:49:33 -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=Brie0+wSIUm/zmZQialELETkmf0R/Hl5KmtfxxDZHt0=; b=hbVjDfTKcCSuHguGrPgOFC+EhaRoiYZcKZMGWGNzdw05fKKW+Y/++vCZJCrC2EclX7 Mnp6UrW2Kv9LGC2Zc2E9BRvnxmCT2Zxuy8NGVq+RQxHqwdfWnua500aVDvQb1T7KK3Ux FzICmUXTFModQ7lnHxfW+WIFF0zoOvXodtDuh+JRHb/ZTAmDG2KbcNbqMlaA7Ch1/yHh CcdIth3slUe+e3PkFJIXv0XL5IX1Jn5VgAI9KSapQ8wjHgRaiEnfArxC3CLaNBMP73wf qRdF1TC/KjeePmlI6uBWyLgJQSWKSztrsAkOZ/azUrm8VG1MRg6l97ZLcQUOQegRP3p8 YaYw==
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=Brie0+wSIUm/zmZQialELETkmf0R/Hl5KmtfxxDZHt0=; b=IMUBB4jOamRvSh2ij2y9P/IdB31DqbrWZtAzcCJx80zMZR963B5sZCFIUmn/BAtR8b gltUU7G9Y7M1c/XwWJz0orGwGtYxGTHT+9Ue3dRsUHRjfcuVQuoTy5DsTAkwymUo3Smz ug4zoPA1wMsO7800Ha7RGN2u9/ZomIpWccll+6R3fGxd/PtJq/o1ElS7MpFgvrhfNtCV TYk3bGJFPliwUj3PIUXNhuqM9Grs3re2dio2cUVZ9RuZcRLslceLbRQX2DwCKApP8T1a HRktOzvCY9CbpYDnq3F6R+ovoN3UdjEPSm2MNx0hIWaDyTU31mmq9vC6Aa0XUpRWZVia 2gww==
X-Gm-Message-State: APjAAAVqmmTEebE6N4+EzCr2rj1vA6J8VB9erAUZTQikPu21l/Y3bTOx owlUoNt82wlGZaVus6V2os4nWVQEsw0w9vzZw/DTlKhe
X-Google-Smtp-Source: APXvYqy6M6Q9RIR2nn51Xs8VfJtpbNX3mcWoHeQqBg5IM3AtSbZcKTL2rTMrYYzKMErd3nZmGRws/uNnJYjqE+Q2WtM=
X-Received: by 2002:a19:8a46:: with SMTP id m67mr10448292lfd.73.1574398171940; Thu, 21 Nov 2019 20:49:31 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Fri, 22 Nov 2019 12:49:20 +0800
Message-ID: <>
Subject: Re: BFD chair response to presentation on draft-mirmin-bfd-extended
To: Jeffrey Haas <>
Cc: RTGWG <>, rtg-bfd WG <>
Content-Type: multipart/alternative; boundary="000000000000c60bdb0597e8238f"
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:49:36 -0000

Hi Jeff,
thank you for sharing the history of discussions at BFD WG related to this
work. There have been many exciting and inspiring discussions, and I've
tried to give credit to everyone who has influenced this work.
It was not our intention to seek a place for this work outside the BFD WG
but to share information, invite comments, and encourage discussion. With
the comments about u-BFD, I think, we've received a helpful and important
case to work on.
If by making this presentation, I've left the impression that authors are
trying to bypass the BFD WG, then I apologize as that has never been our


On Fri, Nov 22, 2019 at 10:49 AM Jeffrey Haas <> 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 IPPM
> 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