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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Fri, 27 September 2019 21:14 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 538211209A9 for <rtg-bfd@ietfa.amsl.com>; Fri, 27 Sep 2019 14:14:14 -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=ioozZXR0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gW/93kkN
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 QVZbWa6Uq0DU for <rtg-bfd@ietfa.amsl.com>; Fri, 27 Sep 2019 14:14:12 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1455912098F for <rtg-bfd@ietf.org>; Fri, 27 Sep 2019 14:14:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5685; q=dns/txt; s=iport; t=1569618852; x=1570828452; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GISNlvN065wIVwAJD6xzdTgPvVul8WsCTTeGr1tZZAY=; b=ioozZXR0hqjSXKVdFZAY1QXusivsEayve38I8/Q9J4GSd0plBEuuM9RQ zx1YkogTKJDyQVSpOsnptrESOCqO5J1WyJ/Y/MXF3VmEOvJM3noAqZykf eHmmwUIX2k5wPQXGY9iRkFrkl+BaGhEEG/3OoIanfHdwCGfJqfGclY8t2 s=;
IronPort-PHdr: =?us-ascii?q?9a23=3AO2+dgxKBvlxpGB8qdtmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEL6KuXgYjY1NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AACzeo5d/4wNJK1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQwBAQEBAQGBZ4FLUAOBQyAECyqHaQOKWIJcfpZ4glIDVAkBAQEMAQE?= =?us-ascii?q?tAgEBhEACgzcjOBMCAwkBAQQBAQECAQUEbYUtDIVLAQEBAQIBEigGAQE3AQs?= =?us-ascii?q?EAgEIDgMEAQEBHhAyHQgCBA4FCBqEawMODwECox8CgTiIYYIngn0BAQWFFBi?= =?us-ascii?q?CFwmBNIwOGIFAP4ERRoIXNT6ERoM7giaMdJE+jmkKgiKVJpk0pz8CBAIEBQI?= =?us-ascii?q?OAQEFgWkhgVhwFYMnUBAUgU4JAxeDT4pTdIEpjhwBAQ?=
X-IronPort-AV: E=Sophos;i="5.64,557,1559520000"; d="scan'208";a="334081218"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Sep 2019 21:14:11 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x8RLEBLa004687 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Sep 2019 21:14:11 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 27 Sep 2019 16:14:10 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 27 Sep 2019 16:14:10 -0500
Received: from NAM01-SN1-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; Fri, 27 Sep 2019 17:14:09 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S+O1xKgRqOfQSisiRwBRdYIzZgFsLG6j/M1Z+FGja9mfML2RlNvpaov6VKJ747tcXmiHRB39j0HFVin7bRLRtKZJY0THDX6xAEL5bUN60Nu42ugmAv28w2MjZCmg8Xi+lNQkS1hU7GXYv94SA15mp5w0AcCIJMJ7ouFalfpGaidJZPjpIk9kZy64IIvjyxsoRqsdp0Ei52CMlfLZNDL+d/bf4tkHuLikCr17Ki7unGdAaGLorXiGkG9GruleSWiX9B/GvMPSAmGZu0C8Zv1suR+dz/D0W2VZaI9Y+dWsADqefv8MJjm23gluqUr80OMo41R1HOR53DYOhX5sP6uXcQ==
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=72ymMWC40px0yCk8OdOG4q6H5JZRN+SdG/FGUN0FORM=; b=gxtVcp5WjopBaa1QIsD6KIZRfTDCbSEj3D5v3bRzW0xujM/x1rB2itiOUgxKgoSjCFa3BxnLF/GjsDYsiseNPR2H5JzxheGkXKRJdBctK7rgoq2azX0R50kwPyHTrmNbvVHzfLWdNbGmlm/D88vtamb2dS6QL/H1RkVMNGETNk1+FhdEp8jyVJJwRK4NJNmq1U/a9j+dnAxro8GvgCnAq6JtaFhCNfluP78LFDDWk9iNOxumaIhBl9PXcMedhaCLWQ7p8aIPH+j9FZDOR2WPep+v7BthclaZfLo/VMH8FVDZI5dgL7exNPn/Vw9qWMlBr82b80qu+7JuJJPh8o0KkA==
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=72ymMWC40px0yCk8OdOG4q6H5JZRN+SdG/FGUN0FORM=; b=gW/93kkN/eOLq9beQt5IWwUyYjYcD0O2sLytQ87X4iL9lz8y0odEd3VevpG51aSt4yiN9XU8PYEinnD1jEvMJoMqjYogslAL6bfQCsC80xdVaAmOzeZ5jAPjgz+JI4AcCWEJJLCIjgGOGwkgpp0i8W2kc2GA89Hi7d6VFDmJYDc=
Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB3272.namprd11.prod.outlook.com (20.177.186.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Fri, 27 Sep 2019 21:14:08 +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; Fri, 27 Sep 2019 21:14:08 +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: AQHVXPUyTxWyJBtWsEOnJ4ETycFi16cjIc8AgAXoLNCAAJsYAIAHXvgQgACtbYCAAF1t0IAAU3wAgAAHCHCAAKTcgIAIh9iwgAL3EwCAAaVO0A==
Date: Fri, 27 Sep 2019 21:14:08 +0000
Message-ID: <BYAPR11MB36386BB42047D9FD46F17E9BC1810@BYAPR11MB3638.namprd11.prod.outlook.com>
References: <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> <BYAPR11MB36383D1DF70CFA399BFF6E59C1840@BYAPR11MB3638.namprd11.prod.outlook.com> <20190926194948.GA22700@pfrc.org>
In-Reply-To: <20190926194948.GA22700@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:1005::65e]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 99bb6a27-5324-47b6-df38-08d7438fa2ed
x-ms-traffictypediagnostic: BYAPR11MB3272:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB3272DF1815B62D9E5E83C8A2C1810@BYAPR11MB3272.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0173C6D4D5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(346002)(136003)(376002)(396003)(13464003)(199004)(189003)(2906002)(25786009)(76176011)(6246003)(53546011)(6506007)(11346002)(66476007)(66946007)(52536014)(66556008)(5660300002)(64756008)(9686003)(66446008)(316002)(99286004)(7736002)(76116006)(55016002)(4326008)(8936002)(478600001)(6916009)(33656002)(86362001)(74316002)(54906003)(14454004)(305945005)(81156014)(8676002)(81166006)(486006)(71190400001)(102836004)(7696005)(6436002)(229853002)(46003)(186003)(71200400001)(14444005)(476003)(256004)(446003)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3272; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zyUNu7o6cwTCrr6zMPGsvKmcK0nTtkg+pIfu4lEVYWbfQPqxBJtZb3XikoNV92/I7mSgctjSt5TOyb5jZqAHP/A9OjusvOFEZHmzMi4RTKdZAohhT8uoKIeI2XDDdIW9lZhAenCyHLo8dN9MzQJcQMyE93GkjpCpAA4Ou43yQyu+AriuY48cmVfxmx1eaPJ3+VjF1a+AMcEM0+Y2fH1QyqE8AS7iJ0UU7hRuQUs19vDGn8+63LtNJTp6Mick1zak4YjxZuzhGTv5uVpZk7CY9Bjqz4DEyxjyb8gLKO0RgUuqDn/DdHNjaK3Hf7gTPWvhCGonkyt4tGstGFdYamco3lU1OOKTORXBGfgbeW3rmQO9u92er6i8QLvXRhCLHFNqcGc388KJkd3rx5n+wEITm1JYQ0T14D48iafx7kc9bk4=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 99bb6a27-5324-47b6-df38-08d7438fa2ed
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2019 21:14:08.7797 (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: 2qRKYHvKaXMfo7zdBm+8yDiUqDj38TG0fATroyBfCBYkcoXakCKSHx24yUkGy+vwtd3GKhwvoPCTEXhnIxwCSg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3272
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/LxsCRtQCWeWim1Hu2NAnIz-TqzQ>
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: Fri, 27 Sep 2019 21:14:14 -0000

Jeff -

Inline.

> -----Original Message-----
> From: Jeffrey Haas <jhaas@pfrc.org>
> Sent: Thursday, September 26, 2019 12:50 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 Tue, Sep 24, 2019 at 10:48:51PM +0000, Les Ginsberg (ginsberg) wrote:
> > 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.
> 
> My experience is largely identical to yours.
> 
> The motivation for mentioning anything at all here is TANSTAAFL[1], and
> we've already had people ask about possible impacts.  And, as we discussed
> previously in the thread we shall inevitably get asked about it during TSV
> review in IESG.
> 
> The primary reason this is a "may" in the non-RFC 2119 sense is that our
> experience also suggests that when the scaling impacts are primarily pps
> rather than bps that this feature will likely have no major impact on
> implementations beyond your valid concerns about exercising bugs.
> 
> I suspect had this not been mentioned at all, you would have been happier.
> But you're not the target audience for this weak caveat.
> 

[Les:] I am not opposed to a discussion of potential issues in the draft - rather I am encouraging it. But the current text isn't really on the mark as far as potential issues - and we seem to agree on that. It also suggests lengthening detection time to compensate - which I think is not at all what you want to suggest as it diminishes the value of the extension. It also isn't likely to address a real problem.


For me, the potential issues are:

a)Some BFD implementations might not be able to handle MTU sized BFD packets - not because of performance - but because they did not expect BFD packets to be full size and therefore might have issues passing a large packet through the local processing engine.

b)Accepted MTU is impacted by encapsulations and what layer is being considered (L2 or L3). And oftentimes link MTUs do not match on both ends ("shudder"), so you might end up with unidirectional connectivity. I appreciate that this is exactly the problem that the extensions are designed to detect. I am just asking that these issues be discussed more explicitly as an aid to the implementor. If that also makes Transports ADs happier that is a side benefit - but that's not my motivation.

> > 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.
> 
> I'm not clear what you intend by this statement.
> 
> Are you asking that we emphasize the use case in a different way?  The
> Introduction currently states:
>   "However,
>    some applications may require that the Path MTU [RFC1191] between
>    those two systems meets a certain minimum criteria.  When the Path
>    MTU decreases below the minimum threshold, those applications may
>    wish to consider the path unusable."
> 
> I'm also unclear what "Implementations" may refer to here.  BFD?  An
> arbitrary user application?  If the latter, the application may not have
> strict control over the generation of a given PDU size; e.g. TCP
> applications.
> 

[Les:] I am talking about BFD implementations.
I suppose one can imagine each BFD client requesting a certain MTU value - but that wouldn't be my choice.
I would think the value we want is really the maximum L3 payload that the link is intended to support - which should be independent of the BFD client. This might be larger than any client actually uses - but that seems like a good thing.

   Les

> > 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.
> 
> We could certainly add a paragraph or two as an application note about using
> this for BFD stability purposes as well.
> 
> -- Jeff