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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BF5612D4F0 for <>; Mon, 29 Oct 2018 08:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aOt7ccdEETF2 for <>; Mon, 29 Oct 2018 08:36:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3EC94130DF9 for <>; Mon, 29 Oct 2018 08:36:17 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 5225E1E44B; Mon, 29 Oct 2018 11:35:35 -0400 (EDT)
Date: Mon, 29 Oct 2018 11:35:34 -0400
From: Jeffrey Haas <>
To: "Reshad Rahman (rrahman)" <>
Cc: "Les Ginsberg (ginsberg)" <>, "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-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 15:36:19 -0000


On Fri, Oct 26, 2018 at 06:32:26PM +0000, Reshad Rahman (rrahman) wrote:
>On 2018-10-25, 11:38 AM, "Jeffrey Haas" <> wrote:
> >     The draft I had previously worked on with Xiao Min discussing probing using
> >     BFD Echo had the concept of probes that would happen wherein the session is
> >     not torn down.  The example carries similarly with the "send occasional".
> <RR> We discussed use of echo at IETF102. The large-packets draft mentions
> that echo can only be used for single-hop, hence the need for padding the
> control packets. But isn't single-hop Albert's main use-case? 

It's Albert's primary use case.  And, I think a common related one is
protecting tunnels of various flavors; e.g. GRE or IPsec.

> I believe we
> should add the echo option in the large-packets draft, it has the benefit
> that you get the desired functionality even if only 1 side of the WAN link
> supports echo. I realize not all implementations support echo so they
> might have to do pad control packets instead.

While I don't think Albert or I would have any objections to adding Echo
discussion in the existing document, we perhaps risk running into one of the
issues Xiao and I had briefly discussed.  Echo is intentionally
under-specified in RFC 5880 et seq.  While it's possible that we can simply
put in a discussion section that says "if you use Echo mode with similar
padding, you can get similar benefit", I think that may be as far as we want
to go.

The related observation is that nothing stops an Echo implementation from
doing this with no changes to the protocol. :-)

-- Jeff