Jeff -
> -----Original Message-----
> From: Jeffrey Haas <jh...@pfrc.org>
> Sent: Wednesday, September 18, 2019 8:28 AM
> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> Cc: Ketan Talaulikar (ketant) <ket...@cisco.com>; Reshad Rahman
> (rrahman) <rrah...@cisco.com>; rtg-bfd@ietf.org
> Subject: Re: WGLC for draft-ietf-bfd-large-packets
>
> Les,
>
> On Wed, Sep 18, 2019 at 05:24:17AM +0000, Les Ginsberg (ginsberg) wrote:
> > 1)Sorry to be late in responding - but just back from vacation.
>
> I wouldn't know anything about that sort of problem. :-)
[Les:] Sounds like something for you to discuss with HR. 😊
>
> > There are very legitimate concerns about the impact supporting padded
> BFD PDUs may have on existing hardware implementations - both
> functionally and in terms of scalability.
> > As a standards track document I think more needs to be said about
> operational considerations - and I think there may be legitimate reasons to
> consider negotiation of the capability.
> > In particular the statement in Section 3:
> >
> > "Additional changes to the base BFD protocol may be required to permit
> negotiation of this functionality
> > and the padding value."
> >
> > 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.
> Your point about the document being potentially informational is certainly
> possible, albeit probably not what you're really intending. As
> implementation has already shown us, one side can simply start using this
> procedure without any support required on the other side. I.e. there's no
> protocol changes we're doing.
[Les:] Understood - but I am still concerned.
>
> > Section 3 also suggests
> >
> > "support[ing] a lower transmission interval
> > (bfd.DesiredMinTxInterval)"
> >
> > as a means of minimizing scalability impacts. But in early discussions of
> > this
> draft it had been suggested that rather than use BFD for PathMTU validation
> we could use another protocol (e.g., IS-IS hellos) to do this. But that was
> rejected because it was stated that the deployment requirement required
> much faster detection. If that argument holds, then the suggestion in the
> draft to use longer timers seems inappropriate - or at least without
> sufficient
> context.
>
> More context could be added, if there's appropriate text to add.
> Suggestions are welcome.
>
> 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).
If the argument is that this is not fast enough, what is fast enough? 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
don’t think this point has been explicitly discussed in the WG. For me, if
slower detection is acceptable then I would like to reopen the discussion as to
why other detection mechanisms are not acceptable. What is the real requirement
here?
> What you otherwise seem to be implying is that some operational forum
> should
> mandate a profile for number of sessions vs. timers vs. MTU size vs.
> transport on a particular set of hardware. And even then, that's not
> impacting on this document's procedures.
>
[Les:] Absolutely not!! For the record, I am not a fan of RFC 7419 - please do
not put me in that camp.
But I do think we need to clearly understand the desired behavior for this
extension. Based on WG discussion I did not think that slower detection time
was a goal.
Les
> > (BTW, by "lower transmission interval" I assume you mean a longer interval
> (i.e., a larger value for bfd.DesiredMinTxInterval)??)
>
> Yes.
>
> > I think these points need to be addressed in the draft before it is can be
> considered complete.
>
> -- Jeff
