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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 19 September 2019 02:37 UTC

Return-Path: <ginsberg@cisco.com>
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 4EF3F1200D6 for <rtg-bfd@ietfa.amsl.com>; Wed, 18 Sep 2019 19:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=E7v+7kY+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jtsbqAuz
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 IJmx6wSeMPoc for <rtg-bfd@ietfa.amsl.com>; Wed, 18 Sep 2019 19:37:16 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63A212008A for <rtg-bfd@ietf.org>; Wed, 18 Sep 2019 19:37:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6144; q=dns/txt; s=iport; t=1568860635; x=1570070235; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=K9KUTfNPnNXbrn5lEPLe6GKNrYvp2dBwR6rmjnfurrU=; b=E7v+7kY+M2TeDaraNxlwzs39jQPFEads4GOEEImC1/0SVgJK3K02NlQz HsDOHH3EHFcdmPTTjirgChfVxKDBrRzls28lZQDX2j4DJkFyUnbrnyt93 WJ7xWOISJH8UlPj9LK+cEhh3BRQLs3cCDp3plI4XVpFaJEm3UvJH8GiEZ k=;
IronPort-PHdr: =?us-ascii?q?9a23=3AceKZHheojywo0I1SXiXgD7PDlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/YC08B85PTlBN9HCgOk8TE8H7NBXf?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAADw6IJd/4oNJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4FFUAOBQyAECyqHaQOKe4Jcl3OCUgNUCQEBAQwBAS0CAQG?= =?us-ascii?q?BS4J0AoMDIzgTAgMJAQEEAQEBAgEFBG2FLQyFSgEBAQMBEigGAQE3AQQHBAI?= =?us-ascii?q?BCA4DBAEBAR0BEDIdCAIEDgUIEQmEawMODwECo2wCgTiIYYIlgn0BAQWFDBi?= =?us-ascii?q?CFwmBNIwJGIFAP4EQAUaBTn4+hEYkgxeCJoxwCxkSn14KgiKMGIkImSGnHQI?= =?us-ascii?q?EAgQFAg4BAQWBaSGBWHAVgydQEBRXdwkag0+KUgFzgSmMeyuCJwEB?=
X-IronPort-AV: E=Sophos;i="5.64,522,1559520000"; d="scan'208";a="328731528"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Sep 2019 02:37:14 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x8J2bEjs006267 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Sep 2019 02:37:14 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 21:37:14 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 21:37:13 -0500
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 18 Sep 2019 22:37:13 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A6n3aj5VtsDVGcSHWn2a0w4rmIRZra0C8rUDYVsnVYq+eHcJfYt7nfay2ryvLKY2ZUA73fhaiWjLzQe14Sd8smtxNYMYDGs0Iv44z7QKxIHYL5cpabPfSy3pHPwAKks5cXWcWBjIalW3lFbZTfgiqvW+/mFDpbBDEIRjRUfm+6nzVI/AIMmqpKL3LSluwIoPYVeI/u8BkGC+Rmk8wpszXMxgvNrCPVzq5YQzzcyvzRtF8tZLa9wF4A7FJnyxMm+zfZiAUACbglekAWBTzE5v0eyh4lXeRVhm7mheGN4c7jcvR2jePr8zQJSUDYTeJK5x+M+nw5MTiXQi8/DdpgDNmQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d0pqlnhGHPlr+LSqZH237+j1uRDcip8dvS89iv/bFGo=; b=Ec4PVuSe2NWrsujJJxTGWKP0qPXy2d3Kc+SzfKf+AaKeryD+Pbsj7aEt/WDh+Arud65R/D9dyhapu2ZYCZquBc5l4faL3FO9lbPpZX3Z6/e/9sf+IC1Xey3P/QZHvTshm1YH3SuuWXOQYdSfAQ4XCsElYprEalAvxAMWWJwm98CdPo8+69VvqomHQ51KQWQsWp/79FbJCUU4FmyCj/G4wa5rGNkrzxM9dGJ7gk4+MF0tFQhbCnSCqXnoVgceiGgoteWA/Aqv2a8Dfxb/iS03IQEaGPig2WrK8v5kcNcheD83JRImuAj8UEKolBveLigJJlSzEEiwEFFn1Gw5pcPwfA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d0pqlnhGHPlr+LSqZH237+j1uRDcip8dvS89iv/bFGo=; b=jtsbqAuzD51PjSCI2rwC8AN7lLUUN0zQ80RPg0yoWFByb+H1J/nhSwpR/sR4ND51hbfHXMOQzTDFIRAJ/M5n+9XGxmAuLecMaVjIp5e3BdGCSObNBQQdE7s6qx3X/9xi2XM05UMsxGVitJu36vFyqs173lw93GJ5QKw2YCM62e0=
Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB2726.namprd11.prod.outlook.com (52.135.227.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.26; Thu, 19 Sep 2019 02:37:11 +0000
Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::f4d7:dd49:e1da:4474]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::f4d7:dd49:e1da:4474%5]) with mapi id 15.20.2263.023; Thu, 19 Sep 2019 02:37:11 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>
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
Thread-Topic: WGLC for draft-ietf-bfd-large-packets
Thread-Index: AQHVXPUyTxWyJBtWsEOnJ4ETycFi16cjIc8AgAXoLNCAAJsYAIAHXvgQgACtbYCAAF1t0IAAU3wAgAAHCHA=
Date: Thu, 19 Sep 2019 02:37:10 +0000
Message-ID: <BYAPR11MB3638E358EF9CE34818ECD010C1890@BYAPR11MB3638.namprd11.prod.outlook.com>
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> <20190918152817.GA20672@pfrc.org> <MN2PR11MB3647316C13CAA5EBD4531B06C1890@MN2PR11MB3647.namprd11.prod.outlook.com> <20190919020128.GB20672@pfrc.org>
In-Reply-To: <20190919020128.GB20672@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com;
x-originating-ip: [2001:420:c0c8:1008::20d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f55eb3ca-dbf6-485d-72be-08d73caa462f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR11MB2726;
x-ms-traffictypediagnostic: BYAPR11MB2726:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB272661230D8EA0C180F07052C1890@BYAPR11MB2726.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 016572D96D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(39860400002)(366004)(136003)(189003)(13464003)(199004)(305945005)(6916009)(316002)(66446008)(64756008)(446003)(86362001)(8936002)(55016002)(33656002)(52536014)(229853002)(11346002)(76116006)(7696005)(99286004)(76176011)(186003)(74316002)(66556008)(6436002)(46003)(9686003)(81156014)(6506007)(102836004)(66476007)(66946007)(7736002)(53546011)(478600001)(486006)(54906003)(6246003)(6116002)(8676002)(476003)(71190400001)(14444005)(81166006)(14454004)(25786009)(5660300002)(256004)(71200400001)(4326008)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2726; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: EnuhYQ6RCnUhRsz1sy6Hx51AtHH1M59kFq16oy7t1TphEdE4BEB44W9ZtT5O1MJXS7Vc0JhbgMfyRUhOy6NOpr2IN/2A5eLuaC0Ai3k008hyk+w/YUB0ZXknO3DyF9As/svUqeYGk2+W5VVKWxIK3KVJy/oNRTXlbCs+bYXEo2+FSCkd25jvyZTQY4a8M9ZxQa6B2AYPZDln56sQKsNSFgHtNTVO1a5accrfZ1VAaBS40F2jy/Kj8HlqrJK/nNwfkZ9PjvDQKmkqhmHbK/ZCDicuhxFw74FaJVK0tlWOuHQxgr2UxrMUl4vUaYtWF32HM/gYgcjQiVHsF10C9JQJJCl/CvRq++WaI85vnWoJd+SF7L8JI3GfpYXv2/+nAzI3HSONfs0K2gPyfr14KwiI4JOUhNZCHCcNxvGVOtq6Dj8=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f55eb3ca-dbf6-485d-72be-08d73caa462f
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2019 02:37:10.9309 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vpM3gGwgWv3TH3/j44H0rtsyGwcaCW9aU02nZpjLVSOzEbPZzt1LJltSlCRxRWsfEvOjXHsAbCdsMB1e2ElqPg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2726
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/sa9j0Vtc21xGA7tBkmN3MQmnTVw>
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: Thu, 19 Sep 2019 02:37:18 -0000

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 <jhaas@pfrc.org>
> Sent: Wednesday, September 18, 2019 7:01 PM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> Cc: Ketan Talaulikar (ketant) <ketant@cisco.com>om>; Reshad Rahman
> (rrahman) <rrahman@cisco.com>om>; rtg-bfd@ietf.org
> 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