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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 19 September 2019 00:06 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 A5B9E120AED for <rtg-bfd@ietfa.amsl.com>; Wed, 18 Sep 2019 17:06:51 -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=JT2N6D8b; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lUmBnJOE
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 VRAAdgl_3yKn for <rtg-bfd@ietfa.amsl.com>; Wed, 18 Sep 2019 17:06:45 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441051200B3 for <rtg-bfd@ietf.org>; Wed, 18 Sep 2019 17:06:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6914; q=dns/txt; s=iport; t=1568851605; x=1570061205; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=T/cdksa8+YK0U+tGSQ+33zjPKBQZoJsLSqIdkiJOXDM=; b=JT2N6D8bfwThdwnvGhXx7Vyde6K1FG1RRqqReyKZsT1y3VzZk4ad4qpk uENNdxt2uL4rrt0Vkr2YPm5yopq2+HlJF70yXn6zughedyJh4tFvBHa2Z mihTh4os2IjxFSTgp+0QMBzTCyAyM4VFsHKlQCElptyg3gQKM06mGpAUa 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3AjiY6HhbOXY072OTDKzLwQ4H/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavlbiohFslYW3du/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAABdxoJd/4ENJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVQMBAQEBCwGBRFADgUMgBAsqhCKDRwOKeoJcl3OBLoEkA1Q?= =?us-ascii?q?JAQEBDAEBLQIBAYQ/AheCbCM2Bw4CAwkBAQQBAQECAQUEbYUtDIVKAQEBAQI?= =?us-ascii?q?BEhERDAEBNwEEBwQCAQYCDgMEAQEBAgImAgICMBUICAIEDgUIGoRrAw4PAQK?= =?us-ascii?q?TVpBhAoE4iGFzgTKCfQEBBYUMGIIXCYEMKAGMCBiBQD+BEAFGgkw+hEYkgmU?= =?us-ascii?q?ygiaMbyqCPYddlU4KgiKVH4I2h0uPIKcaAgQCBAUCDgEBBYFZByqBWHAVgyd?= =?us-ascii?q?QEBSBTgwXg0+KUgFzgSmMeyuCJwEB?=
X-IronPort-AV: E=Sophos;i="5.64,522,1559520000"; d="scan'208";a="633313261"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Sep 2019 00:06:17 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x8J06HXB024008 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Sep 2019 00:06:17 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 19:06:17 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 19:06:16 -0500
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 18 Sep 2019 20:06:16 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SVdvINdgUVSNY1vka31/E6YKBDhQmoYP5kXzGTHDqpp1RUowkHHiI5oXwUHg+Fz75exCsxnYVh9lcxIsXgCt9k1HetYYMQCt4oy2UoN95uGymtgatsRPnku6xrS7euy4w22O1QiLFK+on0CuuGFGzkY521lKYlD77bQMPbu7K6Vltx0rVWFPJLmw1eMOyvI7C55rmjCFyT8pg2jLCRkBk42egbFn6mVx9x46dU1cu7k0zE9tFM18M0hYeT7E4aLPecE8VAISbNeV4ka/qCdMVSDUFPmve5kJcm9r2VIChNfbOn8C/qJbwx6c5xLPj8yLTtkXfZ3YOyJPRnFDsX4MGw==
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=T/cdksa8+YK0U+tGSQ+33zjPKBQZoJsLSqIdkiJOXDM=; b=JEHfumKgrZnVDUo+4zceZt3VPu9jjUaX0IrToFToJePHg9oHcRvKJVUkNKZFOfnYYEtbL2d2ATuqOl2lHEU6D3DpPDLkLNNKXKlGHEhnb7O5IFnVUYaLQbEBRjTr9DB02gMu1BLZI5vrIAN5INEQLQkvYZO6yp3f1UTP6Usv7gipwxt0B3O4aZBhWjJOrtRPlcwiiW9Qvrfqqb1rn5+nTieBdg4oQxtAhdd/gn7E3makFvtiEGItvljgG0U+YcUCPt0EelJzDw9QEGUffGhkcmc/DGk/VJBPkWDf37mwE+wlXN/dx/1qeuZogVnZvLpeiofWo0W2NUmvu5SSa1tEpQ==
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=T/cdksa8+YK0U+tGSQ+33zjPKBQZoJsLSqIdkiJOXDM=; b=lUmBnJOERt0RNuaTt/j8QKUee+8XD83PY+nuwA+1iu5x8VkCyAa3zPbFjpy7np8pah9MrcwM9R41hx/hcDdTG/NKoV9IQA06N5rRIEGkVaGlawc0tRCb9egv+xfqVOjh1RxofoyUv0RkvGJ9NgQRIfU0yXxjQStA7mx1rvcvl9s=
Received: from MN2PR11MB3647.namprd11.prod.outlook.com (20.178.251.26) by MN2PR11MB4462.namprd11.prod.outlook.com (52.135.38.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.21; Thu, 19 Sep 2019 00:06:13 +0000
Received: from MN2PR11MB3647.namprd11.prod.outlook.com ([fe80::40dd:500b:cf13:ab54]) by MN2PR11MB3647.namprd11.prod.outlook.com ([fe80::40dd:500b:cf13:ab54%7]) with mapi id 15.20.2263.023; Thu, 19 Sep 2019 00:06:13 +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: AQHVXPUyTxWyJBtWsEOnJ4ETycFi16cjIc8AgAXoLNCAAJsYAIAHXvgQgACtbYCAAF1t0A==
Date: Thu, 19 Sep 2019 00:06:13 +0000
Message-ID: <MN2PR11MB3647316C13CAA5EBD4531B06C1890@MN2PR11MB3647.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>
In-Reply-To: <20190918152817.GA20672@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: 20e57e6a-5c07-424e-d3b9-08d73c952f3d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB4462;
x-ms-traffictypediagnostic: MN2PR11MB4462:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR11MB4462C276365E52FA40FF0642C1890@MN2PR11MB4462.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 016572D96D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(396003)(366004)(136003)(39860400002)(13464003)(189003)(199004)(6506007)(102836004)(256004)(14444005)(5660300002)(53546011)(76176011)(52536014)(2906002)(7696005)(46003)(99286004)(186003)(33656002)(476003)(446003)(11346002)(8676002)(81156014)(81166006)(8936002)(7736002)(4326008)(305945005)(74316002)(25786009)(6116002)(486006)(478600001)(316002)(6246003)(14454004)(66946007)(54906003)(66476007)(6436002)(66446008)(71200400001)(64756008)(71190400001)(55016002)(86362001)(9686003)(76116006)(66556008)(229853002)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4462; H:MN2PR11MB3647.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: x15ZvgoGocieg3zd2n5Tx5WkHDZphEqNb63wr4NuMnTCclpThtDhGvURh3sbqpOLFrcpEBgFjWvBEkV2JGYvzzhhmemtLTU4CxYjDeK/fjB/ucVc7jNbHdSVwAd65J3TOvqZ9RyDvM/gpd0CAOeQDC/+r3OFq2Px29jupetm0Rt2lO+P2WpzjOcuzr4tmsxZovrAe67KsCIiBwMUjBh2nBulhGvKBxetmsPaxU6AjtyXEsZ/l5W1hyuVhtEnEx+rF3FW89Hmz+ttXFxnEPtOVipbpJvJAFQkXmy4cjwuzEf3IOnxkza9pcZTIyIxj2x8UknCAahZ+njaSXIGI5veKJVEAHlZAqikzGHJ8WHiZC8Iu3rDvS5s7jBYIR544XPigwJguIoQwQPZyyKU0gugGUOfnWRkf+89Ss1l7x6Rf4Y=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 20e57e6a-5c07-424e-d3b9-08d73c952f3d
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2019 00:06:13.5379 (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: BOfWsG2b+lF+0LGYcDi4QlaA+QRmySlitr8m5zQceDE0Q7mmWJLXtH7id2oaXSLAdHDo7+62q92GF0AnbuFwDQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4462
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/0hB1pKfDOz55PA5mnbpnCBIX9ac>
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 00:06:57 -0000

Jeff -

> -----Original Message-----
> From: Jeffrey Haas <jhaas@pfrc.org>
> Sent: Wednesday, September 18, 2019 8:28 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 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