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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Fri, 04 October 2019 00:02 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 42A5F120289 for <rtg-bfd@ietfa.amsl.com>; Thu, 3 Oct 2019 17:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, 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=FfXilLPS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qheGMr1R
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 Yvkae9Eya04k for <rtg-bfd@ietfa.amsl.com>; Thu, 3 Oct 2019 17:02:09 -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 3C54712006E for <rtg-bfd@ietf.org>; Thu, 3 Oct 2019 17:02:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7519; q=dns/txt; s=iport; t=1570147329; x=1571356929; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bcVr+J8bXg2eVIDB5RG4YoTanMIH0EzcZ3bxDXMV26s=; b=FfXilLPSYP6hGSkR7Y4sIWpf33+7LIgA2x9MczayguXh9krthG2rkRrC RWhmBQuIy7Is/j810iOBdBYcU7Lo4ZBApuYCMwfXa0+19vgRNMQtDLnDx DSMkBSfvCCT7qGhZL2YUBZAM1enuAaf51ieEZmzpVggtJUtA1FE6O55ZL w=;
IronPort-PHdr: 9a23:miGU1xERanbNjh6IhSvgMp1GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNVcejNkO2QkpAcqLE0r+efHraTcwEd5NfFRk5Hq8d0NSHZW2ag==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AJAACYipZd/4oNJK1mGQEBAQEBAQEBAQEBAQwBAQEBAQGBVAMBAQEBAQsBgUpQA4FDIAQLKgqHXwOKSIJcfpZ6gS6BJANUCQEBAQwBAS0CAQGEQAKCRSM1CA4CAwkBAQQBAQECAQUEbYUtDIVLAQEBAwESKAYBATcBBAcEAgEIDgMEAQEBHhAyHQgCBA4FCBqEawMODwECpAMCgTiIYYIngn0BAQWFCxiCFwmBNAGMDRiBQD+BEUaBTkk1PoRGgz2CJo0BiEKXeQqCI5UzmUCnXAIEAgQFAg4BAQWBVAE2gVhwFYMnUBAUgU8JAxeDUIpSAXSBKY1QK4EEAYEiAQE
X-IronPort-AV: E=Sophos;i="5.67,254,1566864000"; d="scan'208";a="641553330"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Oct 2019 00:02:07 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x94027j4028490 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Oct 2019 00:02:07 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 3 Oct 2019 19:02:07 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 3 Oct 2019 19:02:06 -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; Thu, 3 Oct 2019 20:02:06 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MW98+xzRFoKwfhfx7y6Xc2epntst16s2SymUWA1bIGpL4aUD91o1xKtcSI/0XwJ3ABXKOpzOK0LV1AkIeSAnQshtuZJW2FmcXCP5EsMc0LlU6Cvhbcz9Lc8woxPe52OJux5DWhl0xH3sewVhki6JwrZJ+IHc0sPjZortXdgR5gLDGvirW/G+tBzK06rloa0ZUWknNZcW/mfnSCq9b5AI4vAKefJPuVPFVD3APhAtkrAV+b5QCPA21eRxSn3GlCH6+RFsgcqloDHyJeOcNnTISP+POxrHj6CJ3VM/Chrm1v+XKWT2iTo0tbDu7vs5oOzcx/hFmXsqbJb91sq5WW0kjg==
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=WMXvdU4sNfVozVMi9LGV1WZ/x5wqNvGIDZS9Pd6K2Vw=; b=Kz7WzRvl6Wn3ceCOUG88xTvC2W7qNCUzztxe9XnHbbS2Z1CdMRT44vev3KWy1mdtBo52UMpwnQ0RWC2lVLMU4rP4Af+H0N3xJBnxb/+EtaTixBv6E9ygUOPhsc9C5fRn8ZP+9FgvMvNh4EbcpzYKGQwxfMI6n4X6SLkPdCFYFyCJ6o3IbeqLNkM9XNEMdjYemafDlfCGeF7/7Skw1FIsTFzDTQZCVRl8DjJyJ62UOR9SevglXk/mlkZIU3mNNGWOWR63Yj5K0yFrojSAn8WIVF/dY56MTQWtqvloAo1Iw0rKOn2OjEOwy+cNq4jEjhcgJbuNgRZyeVtA+rAitniLCw==
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=WMXvdU4sNfVozVMi9LGV1WZ/x5wqNvGIDZS9Pd6K2Vw=; b=qheGMr1Rb25u9b0Np4ZwMjC1aG1Wh74mTWuer2+Psa6EZx3IKrWP6jvqfSNYJoEBVkFzMWUg4TvkNi2ZU29yY9QiXo4RqwyMVE/FSzAPYvDRdsU+hZX704r2ifrJLvssJVgdYwVOai6FpvpzdWeXpCIaLZepcYElEV+zkvUnui0=
Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB3176.namprd11.prod.outlook.com (20.177.127.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.22; Fri, 4 Oct 2019 00:02:04 +0000
Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::8042:c109:5baa:69f1]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::8042:c109:5baa:69f1%7]) with mapi id 15.20.2305.023; Fri, 4 Oct 2019 00:02:04 +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: AQHVXPUyTxWyJBtWsEOnJ4ETycFi16cjIc8AgAXoLNCAAJsYAIAHXvgQgACtbYCAAF1t0IAAU3wAgAAHCHCAAKTcgIAIh9iwgAL3EwCAAaVO0IAJYXeAgAADHMA=
Date: Fri, 04 Oct 2019 00:02:04 +0000
Message-ID: <BYAPR11MB3638ED339AE8B1D29A84D773C19E0@BYAPR11MB3638.namprd11.prod.outlook.com>
References: <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> <BYAPR11MB36386BB42047D9FD46F17E9BC1810@BYAPR11MB3638.namprd11.prod.outlook.com> <20191003201253.GB28365@pfrc.org>
In-Reply-To: <20191003201253.GB28365@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.166]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d9998c3d-5b77-46f4-466c-08d7485e1715
x-ms-traffictypediagnostic: BYAPR11MB3176:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB3176001942F65D6F95FE6852C19E0@BYAPR11MB3176.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 018093A9B5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(376002)(136003)(366004)(396003)(13464003)(189003)(199004)(486006)(5660300002)(446003)(4326008)(52536014)(14454004)(76176011)(25786009)(316002)(6436002)(2906002)(55016002)(6246003)(229853002)(256004)(478600001)(14444005)(86362001)(71200400001)(305945005)(26005)(81166006)(186003)(7736002)(81156014)(11346002)(71190400001)(8676002)(33656002)(8936002)(74316002)(476003)(76116006)(64756008)(66556008)(66476007)(53546011)(6506007)(66446008)(102836004)(66946007)(54906003)(6916009)(7696005)(6116002)(3846002)(99286004)(66066001)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3176; 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: BCL:0;
x-microsoft-antispam-message-info: Q4fevU2mt1r8bPP5n9rFaTDzi0YAXkwZMy5ry7//d3ID5HGlTO5OJJCE9lKKKi3NskZoyx6+fvY18PblrQ93vlroQVFRAiHPXy0f04DPS2ZAb58jgUovuPqAsazP2dZEBxc+1NNMwZYdDrqmxnzBDNvFMCONQIwmgqJhYXMXloQGap33E7U/RMa9R3O5v6Mp6y7AhclpaBS3GpDlBj28VgO6yBzoMmRBYegrRw87vQfP/lwjhvhYhGMBJVyJ6DfvQCN4fREmG05ue86Yd1gWRFa5zSdgRM5U62SHKUnVN5ZRW0cXDhLkZTp3cC+VJggR7qyOO7TQoFdu3ym2DN2OlwNSpT6U1Av8xXJR4kOuz8x4YCkpwihfrE6DBcYVT7jZ8uLQmBoipTtRISgqXFGGYF01okIpPA4a7kgMWjCFZx8=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d9998c3d-5b77-46f4-466c-08d7485e1715
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2019 00:02:04.5211 (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: CYWfFina1rKzouw4p/WT7yf3SYD0J/GfoVYInTfqNRkD/+d1ig0T99veXEKFwGlqx9Nttg1Fkg1quzRi0Ki/HQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3176
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.22, xch-rcd-012.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/hvaGort3kpTA-h_MJ-68IlwEws0>
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, 04 Oct 2019 00:02:12 -0000

Jeff -

For some reason this is proving to be harder than I think it should be.

I keep thinking I am being transparent - yet you keep reading "ulterior motives" into what I say.
There are no ulterior motives.

Let me try again...inline...

> -----Original Message-----
> From: Jeffrey Haas <jhaas@pfrc.org>
> Sent: Thursday, October 03, 2019 1:13 PM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> Cc: Ketan Talaulikar (ketant) <ketant@cisco.com>; Reshad Rahman
> (rrahman) <rrahman@cisco.com>; rtg-bfd@ietf.org
> Subject: Re: WGLC for draft-ietf-bfd-large-packets
> 
> Les,
> 
> On Fri, Sep 27, 2019 at 09:14:08PM +0000, Les Ginsberg (ginsberg) wrote:
> > > 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.
> 
> I think what I'm seeing from you is roughly:
> - Note that larger MTUs may have impact on some implementations for BFD
>   throughput.
> - And simply stop there.
> 
[Les:] What I would like to see discussed are points "a" and "b" below.
This is a section on deployment issues - not a normative part of the spec.

> > 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.
> 
> In such cases, the BFD session wouldn't be able to come up.  Are you
> picturing a problem more dire than that?
> 

[Les:] No. Again, as this is a discussion of deployment considerations I see this as an aid to indicate what problems may be seen.
I am not asking you to "fix" the extension to overcome this.

> > 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.
> 
> Did you mean for BFD or more in the general sense?

[Les:] It is a problem in the general sense, but it is relevant here because the extension proposes to send large packets. Absent that, MTU mismatches would be very unlikely to affect BFD since the BFD packet size is small.

> 
> For BFD, if you have one side testing for large MTU but not the other, we
> can still have a Up BFD session with possible packet drop for large packets
> on the opposite side.  But there's the chance in some paths that MTU may be
> unidirectionally different - e.g. satellite down vs. land up.[1]
> 
In such cases, configuring BFD large on both sides would be the right
> answer.  But it's also possible that large packets may only need to be
> unidirectionally delivered.
> 

[Les:] I agree - and I think it is valid to use the extension unidirectionally in such cases.

>
> > 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.
> 
> We're happy to have that in the document.
> 

[Les:] Great!!

> > > > 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.
> 
> BFD conversations happen between pairs of devices.  In the case that you
> have multiple devices connected to a network segment, each conversation
> could (and may intentionally) have different properties.
> 
> An easy example of this is two devices running an IGP may want fast failure
> and two other devices running BGP may be happy with just under second-
> level
> failure.
>  So too could some device decide that it cares about bi-directional
> path MTU while the others may not.
> 

[Les:] I agree. My point was BFD sessions are requested by clients (such as a routing protocol). That client may/may not care about MTU e.g., a routing protocol may not use MTU sized packets.
But if the goal is to validate that MTU sized data traffic can successfully be sent then "someone" has to enable that. And I would argue that the most logical place to enable the feature is under BFD itself since a routing protocol (BGP/OSPF) won't necessarily care about MTU.
Since you are speaking at the "device" level (not BFD client level) I think we are in agreement.

> Given prior BFD documents' lack of discussion about such multi-access
> network considerations, I'm not sure it's in character to have it just for
> such a case, if that's what you're concerned with.
> 
> > 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.
> 
> In this case we have actual existence proof of desired behavior.  The links
> may be 9k but the user cares only about 1500 bytes end to end. If 1500 bytes
> for BFD large works but 9k doesn't, we've not tested what the user actually
> desired.

[Les:] This is fine. This is consistent with my suggestion that an implementation supports a "bfd-mtu" knob. This value can be <= link_mtu.

    Les

> 
> -- Jeff