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

Jeffrey Haas <> Thu, 25 October 2018 15:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED915130E73 for <>; Thu, 25 Oct 2018 08:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s56QZXnyQQTh for <>; Thu, 25 Oct 2018 08:12:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B774B127133 for <>; Thu, 25 Oct 2018 08:12:28 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 848A91E44B; Thu, 25 Oct 2018 11:11:51 -0400 (EDT)
Date: Thu, 25 Oct 2018 11:11:51 -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="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.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: Thu, 25 Oct 2018 15:12:30 -0000


A brief note, and one worn as a chair:
Despite having strong personal preferences about mail quoting, I realize
that not everyone gets a chance to choose a client of their own choice.
But that said, your responses in this thread have been impossible to parse
out from the surrounding reply in text-plain readers.  This includes the
IETF mailarchive.

Please make adjustments to your mail reply styling so as to be more
readable.  Thanks. :-) 

And now on to non-chair commentary:

On Tue, Oct 23, 2018 at 02:57:17PM +0000, Les Ginsberg (ginsberg) wrote:
> Reshad –
> I think there are two cases:
> 1)A client who uses encapsulation (MPLS is an easy example) and really needs to know if an MTU sized packet plus the encapsulation can be delivered vs a client who does NOT use encap and only cares about Layer 3 sized MTU packets
> 2)A client which has deliberately limited the max-sized packet they will ever send and really only cares about (MTU –X)

While I agree with your sentiment from the perspective of BFD clients, I
think the use case goes slightly bigger than this.

In the cases driving Albert's original scenario, we're not protecting BGP,
IGPs or other control plane protocols for large packets.  What's really
being protected is user payload.

So, to some extent, the use case piggy-backs on existing protection of a
client to guarantee the path has a sufficient MTU.

-- Jeff