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

[Jeffrey Haas <[e-mail]>]

Les,


> On Sep 18, 2019, at 10:37 PM, Les Ginsberg (ginsberg) <[e-mail]> 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