Re: [Idr] [Lsr] draft-merciaz-idr-bgp-bfd-strict-mode

"Mercia Zheng (merciaz)" <merciaz@cisco.com> Thu, 25 July 2019 22:35 UTC

Return-Path: <merciaz@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B858D12023B; Thu, 25 Jul 2019 15:35:50 -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=GR1TV/Ot; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=oTMFzA+9
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 Igyp2UKjlZnL; Thu, 25 Jul 2019 15:35:48 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0CDF1202B7; Thu, 25 Jul 2019 15:35:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22617; q=dns/txt; s=iport; t=1564094147; x=1565303747; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iSbLhneny0Jx0qlYe5wzTPEV7964v5AcBznBlobW6ZE=; b=GR1TV/Ot/oFJ0AqMikd6rPT49dk2X6IsGyJTlWPzWLHeXNR6ghnwojKa FxxCdMffk8JKVszupZkQ2UR323NRaHnaCs0y+GWK1QsLpPaY5qVhMUBdf OeAqGjyhExz8zdUywHaoiREGkpmh7WiDWrB4dbw5PYxAWFZIIWCsPEFea M=;
IronPort-PHdr: =?us-ascii?q?9a23=3AG6MawxI4YsYXc5+kVNmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEj2NvXrZj4SF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAACtLTpd/49dJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBFC9QA21VIAQLKoQdg0cDjH6CW36IVoknhFe?= =?us-ascii?q?CUgNUCQEBAQwBARgBCgoCAQGEQAIXgkcjNwYOAQMBAQQBAQIBBm2FHgyFSgE?= =?us-ascii?q?BAQEDAQEQER0BASwLAQ8CAQgRAwEBASgDAgICHwYLFAkIAgQBDQUigwABgR1?= =?us-ascii?q?NAx0BAgyiIAKBOIhgcYEygnoBAQWFCw0LghMDBoE0AYteF4FAP4ERJx+BTkk?= =?us-ascii?q?1PoIaRwEBggENCYJVMoImjCU1gXIxhH+WDC1ACQKCGpAZg3cbmAyNOok/jhY?= =?us-ascii?q?CBAIEBQIOAQEFgWYigVhwFTsqAYJBgkIMF4NOhRSFP3KBKY0tAQE?=
X-IronPort-AV: E=Sophos;i="5.64,308,1559520000"; d="scan'208,217";a="604585839"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jul 2019 22:35:46 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x6PMZkL5026311 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Jul 2019 22:35:46 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 25 Jul 2019 17:35:45 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 25 Jul 2019 17:35:45 -0500
Received: from NAM04-BN3-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, 25 Jul 2019 18:35:45 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JQUZPjU+wnTqxWfgX7clGZpxVomBGyWRDZoOc+y8XBHE+0FNb9SOcgXw1qlGzVc5iI+83GaPcLwmGpuuCmbLeaEw174qNj5EFhPDsiszN7mpfw6DQ0LWU5o6MKRyiGBRg3FFBkNjUNTtpvoVlx8cHVUfK+Ix5EvgROriCF62KtirmI9lG21UrLY5YzcL41odOF6mcmAlT+k06CvDr8dvmJyBez2DHrqBIUhPpi85Any4Fx7H5mExr2j5xzHG4GauTAlU8MqevER+O7dg2/2WQCyjqhJnUP7eS4oeppuj3Btnc06wM479v9ZqGykRkGAc7ub80iaIg9Q0H/4sTvp2kw==
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=iSbLhneny0Jx0qlYe5wzTPEV7964v5AcBznBlobW6ZE=; b=TZnK8wgPHopHTRujif6osUiwHMPSfSaOQ6gmIuxLhAg2zr8rXjrk72C95gosqnzGxZVrtpPJCILgptdO6bQkGqMBFbb9bbwr3zP76TaKZpoelYB+kMaEgohuuBpi9fQIx7COXEy4/1MRv+bxixoVt5YXIi/AsC4s+qmzufpSQM3wkkD0PotAAJk65e67lkI/MLZE5PYK2I5JrBeREZtPHQ7RJsJxa0y7ZnSsWVVp4Q+ghgF1mg5P388ppxfPbB+H5d/qFdFRvVlewVA/U2WOeZokErGy3g8uEyRWZn4KB+PAoKFZb2osXjpjB2CZA27GdEKij2xVPRyMAgQsD171hw==
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=iSbLhneny0Jx0qlYe5wzTPEV7964v5AcBznBlobW6ZE=; b=oTMFzA+9kb8D4dYsyRH0PHDCL9iDfePp8tv1X4xLnZwL1R1lrgaUg6eAaeEhARU6vU2lUfomy3tAHDMkub3DtNV56tAwQ/vso8RBofHa6BpFB3rLbh3Bk3WiRZka2hFXFzE/GoNjrhH0Lf1xzoKx2VN13ZDIeccr+LI/WjVyCJw=
Received: from BYAPR11MB3174.namprd11.prod.outlook.com (20.177.127.27) by BYAPR11MB2693.namprd11.prod.outlook.com (52.135.227.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Thu, 25 Jul 2019 22:35:44 +0000
Received: from BYAPR11MB3174.namprd11.prod.outlook.com ([fe80::38e1:a172:b56d:eac8]) by BYAPR11MB3174.namprd11.prod.outlook.com ([fe80::38e1:a172:b56d:eac8%6]) with mapi id 15.20.2115.005; Thu, 25 Jul 2019 22:35:44 +0000
From: "Mercia Zheng (merciaz)" <merciaz@cisco.com>
To: Albert F <albert.f168@gmail.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>
CC: "idr@ietf.org" <idr@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Albert Bloomberg <afu14@bloomberg.net>, Susan Hares <shares@ndzh.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
Thread-Index: AQHVQyZEuBuXjfKpfUSGrUV39m+3lKbbxrOAgAABiACAAA0QgP//0+8A
Date: Thu, 25 Jul 2019 22:35:44 +0000
Message-ID: <7C337506-FEC8-4E8F-94A6-7566111F9019@cisco.com>
References: <5D3A0EB4029103460087056A_0_2148724@msclnypmsgsv03> <01c901d54326$80a67af0$81f370d0$@ndzh.com> <DM5PR11MB202727A18322CE10B30D93F2C1C10@DM5PR11MB2027.namprd11.prod.outlook.com> <CAEaWqmokZiFUVYr2Wcnk8hK38xZyL918RnBmrKaiPjh213hS=A@mail.gmail.com>
In-Reply-To: <CAEaWqmokZiFUVYr2Wcnk8hK38xZyL918RnBmrKaiPjh213hS=A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.c.190715
authentication-results: spf=none (sender IP is ) smtp.mailfrom=merciaz@cisco.com;
x-originating-ip: [2001:420:c0c4:1007::202]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3188a83a-1082-4547-168e-08d711506e5d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2693;
x-ms-traffictypediagnostic: BYAPR11MB2693:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR11MB2693D25A9EFBBFAC2F39E047ABC10@BYAPR11MB2693.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0109D382B0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(346002)(376002)(39860400002)(189003)(199004)(51444003)(51914003)(66556008)(5660300002)(66946007)(2906002)(7736002)(6246003)(64756008)(53546011)(66476007)(102836004)(14454004)(66446008)(91956017)(71200400001)(81166006)(25786009)(99286004)(486006)(76116006)(256004)(14444005)(6116002)(86362001)(316002)(8936002)(6486002)(606006)(58126008)(53936002)(54896002)(9326002)(33656002)(186003)(6436002)(478600001)(8676002)(71190400001)(966005)(76176011)(229853002)(6636002)(4326008)(476003)(54906003)(446003)(36756003)(11346002)(46003)(2616005)(6506007)(68736007)(81156014)(6512007)(236005)(6306002)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2693; H:BYAPR11MB3174.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: Jcnk4ttUs8ujDaDjJ69Jk6fS4gPFGvP9P8vm53zNYhVTwb9Flvl6VlKlRNbL7THDytyR89s3tJDkdH7nAMo/9zgLs72I22cYtfmmKX8lhaxBFIjnpBjG6JgR+/+9zhbvIEZskewD4VYaTXHF0a3RNVotU2tNSCXvNbxVobfioiJ5AD48AqjZZsxEu8ABIKeX/9XMtIM7xW4LPtkzeBHV+F7Lh8T87zFDwiZlyYxYhXw0P5BQXguChd3+Z8cnNdoNddrld5hE4YT6/n3SAdAvfUTYaLMoiCp98wpFONsvTME1oZWfxlF244v6gFcdrxbXMOi3/IwAS3hM690xRo/E29Z9yKRhn3Fr7A6/JehZ4nwPki5cTtAPMkNFwNLGDOKJHtZrq6X67fjZQVopJ2BZDMhXTajcWy3WjUNM+OMScLM=
Content-Type: multipart/alternative; boundary="_000_7C337506FEC84E8F94A67566111F9019ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3188a83a-1082-4547-168e-08d711506e5d
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2019 22:35:44.0656 (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: merciaz@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2693
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nBbCkwMB1oU6vgRtTdjslaBJAOk>
Subject: Re: [Idr] [Lsr] draft-merciaz-idr-bgp-bfd-strict-mode
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 22:35:51 -0000

Hi Albert,

Thanks for the support and valuable comments from a customer’s perspective.

This BFD ‘hold-up’ request actually applies to all BFD clients (e.g. control protocols).
I think that BFD would be a better component to apple this BFD hold-up as Ketan also mentioned.
However, some specification will be included in the next revision of the doc.

Thanks,
-Mercia

From: Lsr <lsr-bounces@ietf.org> on behalf of Albert F <albert.f168@gmail.com>
Date: Thursday, July 25, 2019 at 5:14 PM
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: "idr@ietf.org" <idr@ietf.org>rg>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>rg>, Albert Bloomberg <afu14@bloomberg.net>et>, Susan Hares <shares@ndzh.com>om>, "lsr@ietf.org" <lsr@ietf.org>
Subject: Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Hi Ketan,

I think it will be good to mention this in the doc, as I expect most large networks concerned with network stability impacted by link flaps to enable the BFD hold-up feature.

For example, if one side has BFD hold-up enabled (> BGP hold time) and the other side does not, the BGP keepalive message from one side may be delayed even if BFD is up. This may have implication on the BGP session transitiining to established phase.

Thanks
Albert



On Thu, Jul 25, 2019, 4:27 PM Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> wrote:
Hi Albert,

Thanks for your feedback from an operator perspective – it is valuable. This “BFD hold up” behaviour that you desire is best handled by BFD since I would expect that similar behaviour would be desired across routing protocols (OSPF, ISIS, BGP) and perhaps other clients.

IMHO this is not something that we should be tackling within the scope of this BGP draft. Would you agree?

That said, this seems like a local implementation aspect to me. We should however discuss within the BFD WG if there is value in documenting this.

Thanks,
Ketan

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Susan Hares
Sent: 25 July 2019 16:21
To: 'Albert Fu' <afu14@bloomberg.net<mailto:afu14@bloomberg.net>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Albert:

To clarify, do you support WG adoption with the draft as is.

As a WG chair, I have to trust that all  drafts are improved during the WG process.  Can this small change be made after adoption or should it be made before the draft is considered for adoption.

Sue Hares

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Albert Fu (BLOOMBERG/ 120 PARK)
Sent: Thursday, July 25, 2019 4:19 PM
To: idr@ietf.org<mailto:idr@ietf.org>
Subject: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

I am in support of this draft, and would like to request a small change to make this draft more operationally useful.

We have encountered several traffic blackhole problems in our production network without this feature. As such, we have deployed BGP with strict BFD mode on a proprietary vendor implementation for a while.

Since a lot of MetroE circuit failures occur with interfaces still up, ie. break in the middle issues, the traditional knobs like interface hold-time/debounce timer can not be used to dampen interface flaps.

We have observed that interface issues tend to occur in bursts and would like to request that an option be added in "Section 4 Operation:" to delay BGP from coming up until BFD is proven stable continuously for a period of time (i.e. BFD hold up feature).

This is a feature that we are currently using in the proprietary vendor deployment. In our case, since we have multiple redundant paths, we have some links where we delay BGP from coming up until BFD has been stable continuously for 60 seconds.

Thanks
Albert Fu
Bloomberg

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr