Re: WGLC for draft-ietf-bfd-large-packets

Jeffrey Haas <> Thu, 19 September 2019 12:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 120D01201A3 for <>; Thu, 19 Sep 2019 05:16:45 -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 lk-_Die-aVqv for <>; Thu, 19 Sep 2019 05:16:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D93C3120024 for <>; Thu, 19 Sep 2019 05:16:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 096861E2D2; Thu, 19 Sep 2019 08:19:32 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: WGLC for draft-ietf-bfd-large-packets
From: Jeffrey Haas <>
In-Reply-To: <>
Date: Thu, 19 Sep 2019 08:16:41 -0400
Cc: "Ketan Talaulikar (ketant)" <>, Reshad Rahman <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: "Les Ginsberg (ginsberg)" <>
X-Mailer: Apple Mail (2.3445.104.11)
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, 19 Sep 2019 12:16:45 -0000


> On Sep 18, 2019, at 10:37 PM, Les Ginsberg (ginsberg) <> wrote:
> First I would like to reemphasize that I support the draft - so we aren't on opposite sides here. It is just that Last Call seems premature.

The purpose of WGLC is to shake out final comments when things have otherwise stalled.  If it's not ready, we're not bothered by that. :-)

That said, we need to match concerns with something actionable.  That's what I'm hunting for.

> As for the comparison with authentication...
> Authentication added new functionality which cost CPU time. The tradeoff there was clear - performance/scale vs security. But there was no concern that the addition of the authentication bytes in and of itself might introduce a problem.

Most of your commentary was focused around the impact on detection time, hence the response you got regarding other features that have similar impact.

So, if we've moved on from detection time impact of features to other issues, that's fine.

> Large packets introduces MTU sized packets - which in and of itself is unlikely to cause a performance issue. But, having spent a fair number of hours debugging MTU related issues of various flavors, I do think it is likely to expose bugs in packet processing related to size. It shouldn't - in a perfect world - but what chips/software does with sub-MTU sized packets doesn't always translate to MTU size packets. And since the definition of what MTU is isn't consistent across vendors (let alone even within a single vendor's products) there are many ways to screw up configuration here. Throw in all the various flavors of encaps...I think we can expect deployment issues - and maybe bugs as well.

I think Albert is happy to see this text. :-)

The primary purpose of this feature is to shake loose issues related to MTU sized packets and try to remove such paths from service when we can't forward through them.  The path detection at speed is a general good fit for BFD.

What I'm concerned about is you're trying to point out "when there are issues, this doesn't help - and at best exacerbates them".  If so... well, this feature isn't intended to be a debugging layer for those sort of issues.  However, since BFD is riding on top of various transports to do this job, if the encapsulation can carry additional information that permits such debugging information, we're amenable to discussing what to do with it.

-- Jeff