Re: BFD WG adoption for draft-haas-bfd-large-packets

Jeffrey Haas <> Mon, 29 October 2018 17:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26281131048 for <>; Mon, 29 Oct 2018 10:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: YES
X-Spam-Score: 18.2
X-Spam-Level: ******************
X-Spam-Status: Yes, score=18.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=20, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QrPuNAwMiTDp for <>; Mon, 29 Oct 2018 10:36:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 10398131023 for <>; Mon, 29 Oct 2018 10:36:46 -0700 (PDT)
Received: by (Postfix, from userid 1001) id DF8C21E44B; Mon, 29 Oct 2018 13:36:07 -0400 (EDT)
Date: Mon, 29 Oct 2018 13:36:07 -0400
From: Jeffrey Haas <>
To: "Les Ginsberg (ginsberg)" <>
Cc: "Reshad Rahman (rrahman)" <>, "Naiming Shen (naiming)" <>, "" <>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
X-Mailman-Approved-At: Mon, 29 Oct 2018 10:37:31 -0700
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: Mon, 29 Oct 2018 17:36:47 -0000


On Mon, Oct 29, 2018 at 04:55:05PM +0000, Les Ginsberg (ginsberg) wrote:
> I note that no one supports "large-packets" today.

A vapid phrase that I generally loathe hearing on IETF mailing lists.  We
need our own version of [1].  When meant pleasantly, sometimes implies, "no,
I'm not aware of the perhaps substantial background context".  I'll stick
with that one. :-)

> So is the gap between supporting echo mode for this purpose any larger than the gap for introducing large packet support?


Again, the majority of BFD implementations do not support Echo mode.  And
while I had intended to leave it as a unicast aside, I might as well simply
move it to public comment.  Echo was originally a hack to deal with
implementations that simply didn't have line card CPU to keep up with BFD
async sessions.  It still lets you leverage the control plane signaling so
you can indicate BFD session state.  My general discussion with implementors
usually indicates that there's not a lot of push to implement Echo if not
already motivated by existing portfolio.  [2]

>From a technical perspective, implementations that do not support Echo would
have substantial work to do in order to add a feature that's otherwise an
awkward fit into their detection machinery.  On the other hand, all BFD
implementations have to support the Async machinery, even if not at a speed
for their desired detection intervals. 

The general work to do large packets for async mode is:
- Call your flavor of write() with a fully framed BFD PDU and a buffer with
  whatever related filler you want to pad the frame.  (See prior discussion
  on the topic.)
- For reception, make sure you're willing to read() a frame that is bigger
  than the unpadded BFD PDU.

A trivial effort over adding a full feature.  I had discussed with Albert
whether it was worth bothering to standardize, but talked myself into it
being a thing good for IETF and interoperability.

Somewhat similarly, documenting the usefulness of larger MTU packets in Echo
is borderline worth standardizing, but is still useful.

-- Jeff

[2] My last survey was about 3 years ago.  It might be worth repeating.