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

Jeffrey Haas <jhaas@pfrc.org> Wed, 18 September 2019 15:25 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E0A1208AE for <rtg-bfd@ietfa.amsl.com>; Wed, 18 Sep 2019 08:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrEIaRBxaxMI for <rtg-bfd@ietfa.amsl.com>; Wed, 18 Sep 2019 08:25:34 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9B83F120881 for <rtg-bfd@ietf.org>; Wed, 18 Sep 2019 08:25:29 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 415CA1E2F4; Wed, 18 Sep 2019 11:28:18 -0400 (EDT)
Date: Wed, 18 Sep 2019 11:28:17 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for draft-ietf-bfd-large-packets
Message-ID: <20190918152817.GA20672@pfrc.org>
References: <9ECC2E5C-E87E-4859-9DA8-E8E9403DF759@cisco.com> <C44550AC-F6E0-4351-9958-CB9144C9F23A@cisco.com> <CY4PR11MB1541F9CEEA547F1D962D79B5C1B30@CY4PR11MB1541.namprd11.prod.outlook.com> <29C6F22D-AC57-446C-8013-408C4E28A94A@pfrc.org> <BYAPR11MB36384BA8A940618DA9FC3F76C18E0@BYAPR11MB3638.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BYAPR11MB36384BA8A940618DA9FC3F76C18E0@BYAPR11MB3638.namprd11.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/o4aXguUWXIELnx3vLahwnFoifNw>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Sep 2019 15:25:36 -0000

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. :-)

> 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.

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.

> 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.

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.

> (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