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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 24 September 2019 22:48 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 B45DF12085E for <rtg-bfd@ietfa.amsl.com>; Tue, 24 Sep 2019 15:48:58 -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=MPSsrfwh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ogA/RLsY
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 mZSKGQzdgjfr for <rtg-bfd@ietfa.amsl.com>; Tue, 24 Sep 2019 15:48:56 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A1D120033 for <rtg-bfd@ietf.org>; Tue, 24 Sep 2019 15:48:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4876; q=dns/txt; s=iport; t=1569365335; x=1570574935; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3Sz44tmz8zOLj5yErRZv5/2KUc+4wF2pf1eOI3Woyfk=; b=MPSsrfwhME2IxoY6BGuhzgu10Pc04qOWcI27B5seRy8RJ6KQecatzlfu XkBqr05IkWXUp8y0tElc0a7GDGLH7CZQ9i/A9j9D1uP/VhvBkoVp0pFb2 3ggverUNWxIMBCvGwJANxLzTKOOcuSqJBdujQDBKFz7F6b5oNwthWPB+y w=;
IronPort-PHdr: =?us-ascii?q?9a23=3AOsdw/hzZwjg9B1PXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuKCEvgJvPwYAQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAADlnIpd/4cNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQwBAQEBAQGBVQIBAQEBAQsBgUpQA4FDIAQLKgqHXwOKeIJcl3SBLoE?= =?us-ascii?q?kA1QJAQEBDAEBLQIBAYFLgnQCgyEjNgcOAgMJAQEEAQEBAgEFBG2FLQyFSgE?= =?us-ascii?q?BAQQSKAYBATcBCwQCAQgOAwQBAQEeEDIdCAIEDgUIGoRrAx0BAqMUAoE4iGG?= =?us-ascii?q?CJYJ9AQEFhQ0YghcJgTQBjAkYgUA/gRFGgU5+PoRGgzuCJo0VEp9pCoIilSW?= =?us-ascii?q?ZJacvAgQCBAUCDgEBBYFZBC2BWHAVgydQEBRXdwkDF4NPilNzgSmKVwGBIgE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.64,545,1559520000"; d="scan'208";a="623367137"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Sep 2019 22:48:54 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x8OMmstb001862 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Sep 2019 22:48:54 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 17:48:53 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 18:48:52 -0400
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 24 Sep 2019 17:48:52 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QjP3Al8ebLvgRlDFvMEf6jXtIpKJuCs6Q4VnRmhYFFIS1X/yxN8ZGIt5kJvuW6X5PSpuswSMMuM3q0YsomkG300QBy5rf4THM5bPqRs8hFOnoQW/Z3q2MVsbi8RGWUOosmIlXpKq7PEc991Rp5a1x775P2uNbdhT+cFW/cwjsD5gjpmM8x+KuDORqatgZFE7YhvWO54Z5CFeSRR0gik3mJc5CE3Hnj7XVZU21bQMSIOdTID7FRktiOgaUTSq7/OoAMAEtMWVkBU6/lMFsV8xAlNreWMptAXoCbSUTMSvqgqcg14tMDRIYIZxy1MHXCwXCO5G24uUUhwFnmOpedTM0A==
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=NTdtS81MppqjZdmG4nu6ltth1782kez2uYPNJEcNisc=; b=YIE6XmKk12rCEDnMVnnTyJOoEvaF3VCJpk2rpdrkXZDHXn+9kxKdVs9SJEK2dZml9RN9N8ZkUD6tXLtAK6Atlsfjn47vnXcSz1CCzMLkCscFQh3VPUfupqmN32PI8TBpk/bFXOdQ08bIIvEPfnh10cHTYiEU4wFjL/DDcQPpFte99qfhubltsahGD49sNuMSLBhcO1siqtmjoZGrFIj+wFPsHcHMnGq2py1OpvLNSWGpqiDkil0gXNXdjamjxn9NhRmLOHGwrpWXVz9/iDjia53Ieggr6TnaK34ssFzrnoTL0acgFnTgqwZm5+9LtxXNH2O6iaHRl4spj3YE2XEBcw==
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=NTdtS81MppqjZdmG4nu6ltth1782kez2uYPNJEcNisc=; b=ogA/RLsYxsKF/4xEuVC6jiDIXMhZN3/rVX8ImoJC7Oep2LeQA13uhKkWHPa3KiDU/ZteqlLzVibYmbRpXMntv3mpFExzSTkQjoX+mMEpahL21Xe5ad55zF2OBXQTfvkdjpxwg5fzgpVdwwE9ozmkHxizFcC/yDX9Sg+1LV2TfhI=
Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB3718.namprd11.prod.outlook.com (20.178.238.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.20; Tue, 24 Sep 2019 22:48:51 +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.2284.023; Tue, 24 Sep 2019 22:48:51 +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: AQHVXPUyTxWyJBtWsEOnJ4ETycFi16cjIc8AgAXoLNCAAJsYAIAHXvgQgACtbYCAAF1t0IAAU3wAgAAHCHCAAKTcgIAIh9iw
Date: Tue, 24 Sep 2019 22:48:51 +0000
Message-ID: <BYAPR11MB36383D1DF70CFA399BFF6E59C1840@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> <BYAPR11MB3638E358EF9CE34818ECD010C1890@BYAPR11MB3638.namprd11.prod.outlook.com> <D95235B0-9917-4C06-97E6-1181BFF6F7CC@pfrc.org>
In-Reply-To: <D95235B0-9917-4C06-97E6-1181BFF6F7CC@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: [128.107.241.175]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a0ffe1bf-d3b6-419f-d236-08d741415ed4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3718;
x-ms-traffictypediagnostic: BYAPR11MB3718:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB37186439D6A89D4A43783680C1840@BYAPR11MB3718.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0170DAF08C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(376002)(366004)(346002)(396003)(189003)(199004)(13464003)(4326008)(33656002)(478600001)(476003)(81166006)(55016002)(229853002)(446003)(66446008)(66476007)(66556008)(305945005)(54906003)(64756008)(7736002)(316002)(6246003)(66946007)(81156014)(86362001)(8676002)(5660300002)(6436002)(14444005)(6916009)(74316002)(76116006)(102836004)(3846002)(256004)(2906002)(186003)(52536014)(6116002)(14454004)(8936002)(486006)(11346002)(66066001)(71190400001)(99286004)(26005)(7696005)(9686003)(76176011)(71200400001)(53546011)(6506007)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3718; 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: betyiHQt6cdSzKJuqvYtezjvuv2A/eoXH3Hx9gJIkzNAVVuUC+9lFWOImJtP8dom+/YpO+7pkWV7Vh8ZxmyGGitjr42bzTtoXA6IyymX+Lh5zRgoHB4cNSbH75+64wwRZg5nXIZPDyxsDPAIQ1rKxxqCxVlbRzUrktlDMxH5YVDgkjuj1ClQebb6fFNwn0MEwfOqcqBmMShoaQzVREoPG2iRhlifT6kanTrEL6/7kk5y2JmxuUd1J4NIMlkH/5Bxy5F4aWfkzm+RQepiIJpiGAIt0/rZ+YWbdtfUjP8DN3y4mFeHkhyEwu+cVywxtpduUZunq5ZqySpywqhtwUnUdlcgj+TX/Du22wHyKctHHVCSpFfn1XRgVhh4H9zFYzLe/Ns29Gemqru9hXbWh7uxLCy7hO7AGZFT9KAtyx+DVJg=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a0ffe1bf-d3b6-419f-d236-08d741415ed4
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2019 22:48:51.4750 (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: vXkznW1TLLwpNslTMahh8yhk3fxKU+HVFOcJa2IVBEkQAOB/lduEu8ZEF2vHcpioiIvQV7ZSkbzIh48vIzKzxQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3718
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/aRVl4jS3wcZGdArI12oVeL-JYUY>
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: Tue, 24 Sep 2019 22:48:59 -0000

Jeff -

A few more thoughts - maybe these are more helpful than my previous comments - maybe not. I am sure you will let me know.

Protocol extensions allowing negotiation and/or advertisement of support for larger PDUs may well be useful - but let's agree that it is desirable to deploy this without protocol extensions just to keep the interoperability bar low.

My primary angst is with the following paragraph in Section 3:

"It is also worthy of note that even if an implementation can function
   with larger transport PDUs, that additional packet size may have
   impact on BFD scaling.  Such systems may support a lower transmission
   interval (bfd.DesiredMinTxInterval) when operating in large packet
   mode.  This interval may depend on the size of the transport PDU."

Given long experience that CPU use correlates more highly with number of packets than with number of bytes, the first sentence would seem to be weakly supported.
Given the previously mentioned concerns about detection time, the second sentence seems to compromise the value of the extension.

What might be better?

1)Some statement that MTU isn't necessarily a consistent value for all systems connected to an interface - which can impact the results when large BFD packets are used. Implementations might then want to consider supporting "bfd-mtu" configuration and/or iterating across a range of packet sizes to determine what works and what doesn't.

2)Use of both padded and unpadded packets in combination with draft-ietf-bfd-stability to determine whether a BFD failure is due to padding or a generic forwarding failure.

Either of these suggestions are really "diagnostic modes" which may help diagnose a problem but aren't meant to be used continuously as part of fast failure detection.

   Les


> -----Original Message-----
> From: Jeffrey Haas <jhaas@pfrc.org>
> Sent: Thursday, September 19, 2019 5:17 AM
> 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 Sep 18, 2019, at 10:37 PM, Les Ginsberg (ginsberg)
> <ginsberg@cisco.com> 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