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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Jeff -

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.

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.

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.

Just my thoughts...

   Les


> -----Original Message-----
> From: Jeffrey Haas <[e-mail]>
> Sent: Wednesday, September 18, 2019 7:01 PM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: Ketan Talaulikar (ketant) <[e-mail]>; Reshad Rahman
> (rrahman) <[e-mail]>; [e-mail]
> Subject: Re: WGLC for draft-ietf-bfd-large-packets
> 
> 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