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

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Fri, 13 September 2019 04:10 UTC

Return-Path: <ketant@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 5CFDB120098 for <rtg-bfd@ietfa.amsl.com>; Thu, 12 Sep 2019 21:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=iHiLVzH8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LmoVXJLr
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 n2nbUwJJZqTd for <rtg-bfd@ietfa.amsl.com>; Thu, 12 Sep 2019 21:10:27 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94873120088 for <rtg-bfd@ietf.org>; Thu, 12 Sep 2019 21:10:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21914; q=dns/txt; s=iport; t=1568347827; x=1569557427; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=HtqmQjcXTRo7G5d0AuMYzfeRiBChX+iaknGiRaj8Hxs=; b=iHiLVzH8wPV3uzgfcXiGn4ezcTA+QfmybsQ6qBhsT6D8E25V4wZtKbSI jDzAuz6ACIYlW6eDiFfzy4qDo1yZ+Ij9uqallXXwvbffF407qir34I/8E rnhNKaR4pQo9m6XTNTI3FPpc9/VSUMA49U2i3OluwnL4aSNOK39p6yMcM Y=;
IronPort-PHdr: 9a23:EMGMMx9NYcX+Cf9uRHGN82YQeigqvan1NQcJ650hzqhDabmn44+/bR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUERoMiMEYhQslVc2IFUT9MNbhbjcxG4JJU1o2t3w=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A6AAA+Fntd/4wNJK1mGwEBAQEDAQEBBwMBAQGBVQQBAQELAYEVL1ADbVYgBAsqhCGDRwOKak2CD5MUhFyBLoEkA1QJAQEBDAEBLQIBAYQ/AheCRiM2Bw4CAwkBAQQBAQECAQYEbYUuDIVKAQEBAQMSEQoTAQE4DwIBCBEDAQEBHgoDAgICMBQJCAIEARIIGoMBgR1NAx0Bn2wCgTiIYXOBMoJ9AQEFhQoYghYJgTQBi3cYgUA/gRFGgkw+hEYeFoJVMoImjFyCZIUhiRiOUgqCIZUSgjSHQI8WjX+YbgIEAgQFAg4BAQWBWQMugVhwFTuCbIFKeINyilNzgSmMLSuCJwEB
X-IronPort-AV: E=Sophos;i="5.64,499,1559520000"; d="scan'208,217";a="409831321"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Sep 2019 04:10:26 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x8D4AQoo023249 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <rtg-bfd@ietf.org>; Fri, 13 Sep 2019 04:10:26 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Sep 2019 23:10:25 -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; Thu, 12 Sep 2019 22:55:24 -0500
Received: from NAM05-BY2-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, 12 Sep 2019 23:55:24 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EbUrt9CALaag0o2KiWETAfDVW9FZs2LkapvvfJ6d6ynVT5CRIniWBNeqwBa5Jc8g8SW8ek+EtVySgJbc3KCaRX/1jHKXj/kSjWpFmF3uwCPTCHFsUQEDKSWpHEQ3eL3r52z2AksI1J6XdiSm8/thIUuqqM0Cnz4SmP3GuDS3oyqTXE5+cDzEdnG3pHftPmPP2GsX+e0zHoCN0sEncQvARzM56aPLv2u+3faAJ3/AtzTF5fPycqTDfZuZmPdhFOTmhEUyDU07QJM+Y3R0VZ2NVr8XC2Wg3yj3w/6vjs9AAG+r8FYcwsb025PdaWQrYQdNG5KKsp+5Ek2TuVYpVbswHg==
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=HtqmQjcXTRo7G5d0AuMYzfeRiBChX+iaknGiRaj8Hxs=; b=OgRpuEvJJuTwynJ9M6G52gS5j+2pLx9AxcK4KvIiUGdNLuEqs4su/pPxXK8je4n2FnwcGDwj7JE5bwGPEjdRz7cizmzG9/rWTeSAdu2TP5xaZdBUYplR7Ihto3UmgoWhXelEY+PEDjKUfME/X8Jj/NF0y3cJdEfTLEfmIdpwz5PB0q1Klg6Ut8yoaRCJKdMBvnb463XY8T58Rb1DrEuxJEiSUcvRfjc6a4gjhXL1emn9Ht/P110IJjQk/54/6eaPmhhPj9HRm96i4HGx9YOm59uFdzN+dNSQhvRtnu55vjByC5d5XkQ28+Y4Ufv4Enx4qXlRQ63iz57uEYRdy2NEkg==
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=HtqmQjcXTRo7G5d0AuMYzfeRiBChX+iaknGiRaj8Hxs=; b=LmoVXJLrQxRa+Hn1n484qWHQkjtYvAr/jGXxCFqV+OWm/9lDunvImX4N0L3QyoG9eksW8ZDQY2I6AJBrXTDO2Hmp++ZELuf9KsYQuFliY26XFu+k0SiRVgNVRpgOvkp4h6Cltg42l5smPcnZGYY8MBlXF2h6XL5MkJqAMXEkyxc=
Received: from CY4PR11MB1541.namprd11.prod.outlook.com (10.172.68.150) by CY4PR11MB1495.namprd11.prod.outlook.com (10.172.70.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.13; Fri, 13 Sep 2019 03:55:22 +0000
Received: from CY4PR11MB1541.namprd11.prod.outlook.com ([fe80::297e:b901:3eca:88af]) by CY4PR11MB1541.namprd11.prod.outlook.com ([fe80::297e:b901:3eca:88af%12]) with mapi id 15.20.2241.022; Fri, 13 Sep 2019 03:55:22 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "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: AQHVXPUyTxWyJBtWsEOnJ4ETycFi16cjIc8AgAXoLNA=
Date: Fri, 13 Sep 2019 03:55:22 +0000
Message-ID: <CY4PR11MB1541F9CEEA547F1D962D79B5C1B30@CY4PR11MB1541.namprd11.prod.outlook.com>
References: <9ECC2E5C-E87E-4859-9DA8-E8E9403DF759@cisco.com> <C44550AC-F6E0-4351-9958-CB9144C9F23A@cisco.com>
In-Reply-To: <C44550AC-F6E0-4351-9958-CB9144C9F23A@cisco.com>
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=ketant@cisco.com;
x-originating-ip: [2001:420:c0e0:1008::2ae]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5b83f28f-091e-4d14-9a9a-08d737fe3390
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR11MB1495;
x-ms-traffictypediagnostic: CY4PR11MB1495:
x-ms-exchange-purlcount: 2
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <CY4PR11MB14958391BF123879F994F473C1B30@CY4PR11MB1495.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0159AC2B97
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(39860400002)(366004)(376002)(346002)(53754006)(199004)(189003)(85664002)(7696005)(64756008)(316002)(66446008)(110136005)(66556008)(66476007)(66946007)(74316002)(2501003)(2906002)(446003)(256004)(14444005)(11346002)(6116002)(790700001)(476003)(5660300002)(229853002)(6436002)(99286004)(7736002)(86362001)(52536014)(6306002)(54896002)(9686003)(8676002)(236005)(53936002)(71200400001)(71190400001)(102836004)(55016002)(8936002)(186003)(76116006)(76176011)(9326002)(81166006)(478600001)(81156014)(6506007)(46003)(53546011)(6246003)(25786009)(33656002)(14454004)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1495; H:CY4PR11MB1541.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-message-info: B9vl9u8oEmkDnSXZX0ixNcNRKIzDltj+wSZhCa3NdVmwDdDV7daeGT2ztDDs1pdk7I+dXleKn75j7/jip1t+YXqzgqulnT6kzR6AsD7j5ODBEUy0SzGVNdynesYqu/fcm51aXME7a0KADGAJDzndTdmSx8zB614vbU3Qo4Lh3Zef+kmIzoyaIxUs0KzItpl8gt7EXoHgw1C2zKAn9QA7z+K35Ccx5kBrEPAVTKWX68OZDKvg/o6awvJHAbO+nI+rCL0wsFeuW72eDFX3mDGGJQE98Xo6Jk0hD65DLsErk/dPXqj9bXpA1WB7J12CJdwaxkdbdU7I64FJSPUrGuIklLyBk/2OJS/yYetuqnb722FXHcRwXvK3/uIXKt+zhNcpwAjDCrBkjP/V7f6t6F67BXTBFrJSCrFWu11HAxzb/SE=
Content-Type: multipart/alternative; boundary="_000_CY4PR11MB1541F9CEEA547F1D962D79B5C1B30CY4PR11MB1541namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b83f28f-091e-4d14-9a9a-08d737fe3390
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2019 03:55:22.1230 (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: vbtA5i2vYxKcYJDZm9jkwFAd4yu+hbLRy+hznPV0y/it+HExwShY9Ke/+iUkYy9fdC2oflGK1r2WSrs9b1WHtg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1495
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/0C5SBmGr7foLs6qT2ztY1ihvUu0>
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, 13 Sep 2019 04:10:30 -0000

Hi All,

I would like to ask some questions and seek clarifications on this draft.


  1.  I am aware that this draft originates from practical pain points at a specific operator. During the adoption calls, the scenarios were debated in detail. It was basically a L2 WAN circuit service over a provider network and the challenge was that the PMTU of the underlying path in the SP network changes dynamically. However, from the Enterprise POV, the L2 circuit is seen as a single link and the BFD runs in directly connected mode. The draft however, discusses BFD multi-hop which is an entirely different use-case. When doing multi-hop, the BFD packet could go over entirely different paths in the network with different PMTUs (especially different from the application sending large packets) – this makes things flaky? So shouldn’t this mechanism be actually focussed on the single hop/directly connected mode instead?


  1.  There are implementations with BFD offload to H/W out there. What happens when a particular implementation cannot handle such large packet sizes (and I am not specifically aware of one such)? Like other aspects of monitoring like the intervals, would there be a value in indicating a support for large packets during the signalling? The draft does raise the need for it but doesn’t seem to do anything about it – why? Either we need it and this draft should define it. Or we don’t need it and it would placing the onus on the operator to enable this when they know both ends support it. Then it is something for operational consideration section perhaps?



  1.  There was a discussion on the list about whether this needs to be done for every packet or not. I don’t find that discussion or the result captured in the draft. The draft just says that perhaps longer intervals should be applied to BFD when doing large packets – but this will defeat the purpose of fast-detection. What would be good is we have both fast-detection and slow PMTU validation? Perhaps we need some analysis of whether large packets should be used always or intermittently and the pros/cons or guidelines for the same?



  1.  The draft is missing an operational considerations and manageability considerations sections. Some of this info is placed in sec 3, but would help if things were elaborated in their individual sections. It would provide more insight into how exactly this mechanism in BFD is envisaged to be actually deployed and used. More importantly, perhaps how it should NOT be used?

Can the authors and WG discuss the above? I think it seems too rushed to go for WGLC just as yet?

Thanks,
Ketan

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> On Behalf Of Reshad Rahman (rrahman)
Sent: 09 September 2019 20:26
To: rtg-bfd@ietf.org
Subject: Re: WGLC for draft-ietf-bfd-large-packets

BFD WG, reminder that WGLC is ongoing for this document.

Regards,
Reshad.

From: Rtg-bfd <rtg-bfd-bounces@ietf.org<mailto:rtg-bfd-bounces@ietf.org>> on behalf of "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Date: Tuesday, August 27, 2019 at 12:34 PM
To: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: WGLC for draft-ietf-bfd-large-packets

BFD WG,

As was mentioned at IETF105, this document is stable and there was an interop test done between FRR and Junos VMX.

Please provide comments/feedback on the document. The deadline for last call is September 13th.

Regards,
Reshad & Jeff.