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

Jeffrey Haas <> Thu, 19 September 2019 01:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D9E21200B2 for <>; Wed, 18 Sep 2019 18:58:41 -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 RhYklJWftiq1 for <>; Wed, 18 Sep 2019 18:58:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7F4EA12008A for <>; Wed, 18 Sep 2019 18:58:39 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 11C001E2F4; Wed, 18 Sep 2019 22:01:29 -0400 (EDT)
Date: Wed, 18 Sep 2019 22:01:28 -0400
From: Jeffrey Haas <>
To: "Les Ginsberg (ginsberg)" <>
Cc: "Ketan Talaulikar (ketant)" <>, "Reshad Rahman (rrahman)" <>, "" <>
Subject: Re: WGLC for draft-ietf-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: Thu, 19 Sep 2019 01:58:41 -0000


On Thu, Sep 19, 2019 at 12:06:13AM +0000, Les Ginsberg (ginsberg) wrote:
> > > If these protocol changes are to be made, shouldn't they be specified in
> > this document?? Otherwise the document would seem just informational.
> > 
> > No.  There's not really any room in BFD v1 for negotiation.  That would take
> > something like BFDv2, as we've started discussing in the working group.
> > 
> [Les:] I am not fully comfortable with the notion that it is OK to deploy this w/o regard for whether existing implementations can handle it. I think there is some risk here and I would like the WG to discuss this point and - if agreed to - have the draft explicitly state that the risks of deploying this w/o negotiation have been considered and deemed acceptable. The fact that one implementation had no issue with it isn't compelling.

FWIW, I'm not blowing off your considerations.  Mostly, I'm highlighting
that we get them regularly.  TSV review of BFD in every flavor over the
entire life of the protocol has been some variety of this conversation.  We
just get to replay the entire life of BFD RFCs within such considerations
with every new TSV area director. :-)

Obviously it's up to Reshad as the shepherding chair how this process plays
forward, but I suspect it'll resemble:
- Getting further consensus from the rest of the WG whether this
  consideration is a sticking point.
- If it is, do we force this to be deferred to BFD v2?
- Alternatively, can we cleverly figure out some way to wedge negotiation on
  top of the existing feature in a backward compatible way?  (My answer:
  possibly.  Whether it's worth the complexity bump is the arguable component
  since simplicity of the protocol has been a stronger driving factor for
  implementors than scaling considerations.)

I'd like to hear from other implementors whether they share your concerns.
But either way, this exact conversation will play out again with the TSV ADs
during IESG review.  This is expected.

> > However, this isn't particularly different from any other BFD considerations
> > we've had over the years across all uses of BFD.  Your scale for sessions
> > vs. timers will depend on transport, whether it's distributed to the line
> > card or not, hardware support vs. general purpose CPU, etc.  BFD
> > implementors and users expect to do some level of tuning.   This is normal.
> > 
> [Les:] The point I am highlighting is that we already have (at least for some deployments) a way to detect this within a scale of several seconds (or at least 10s of seconds).

You're over-simplifying your point slightly.  That's true for one protocol,
IS-IS, where the padding can be done.  For those that can benefit from that
scenario, great!  But I suspect you'd agree that not everyone is going to
enable IS-IS on a link just to test MTU liveness.

> If the argument is that this is not fast enough, what is fast enough?

Much as you aren't a fan of RFC 7419, that's exactly why that document
existed.  Some level of commonality was desired in order to develop more
uniform scaling comparisons.

It's entirely possible that some implementations will take zero hit to run
BFD at exactly the same wire rate.  A BFD PDU every 3.3ms is not that much
in the way of pps.  And, if your forwarding silicon does its job of
isolating IP validation in the pipeline before punting to the BFD code, BFD
itself may not take any hit in terms of cycles.  However, if you're software
only, you may now be congesting a host path.

We already run into flavors of these considerations for regular 5880 BFD
over various transports.  The timer and session granularities vary.  No one
freaks out at this.

>  The conclusion I drew from the earlier discussion was that existing detection times for BFD were what was wanted. But the text in the draft suggests that the addition of MTU checking might justify accepting a slower  detection time.

I'm going to simply point out that such considerations apply to built-in BFD
features such as authentication.  If you enable some classes of
authentication, you've impacted your detection interval.

I'd like to know why you think that this feature is any scarier than the
impact of authentication.

-- Jeff