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

[Jeffrey Haas <[e-mail]>]

Les,

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