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

Greg Mirsky <gregimirsky@gmail.com> Thu, 25 July 2019 22:41 UTC

Return-Path: <gregimirsky@gmail.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 533BC120226; Thu, 25 Jul 2019 15:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 goEhyZjlbuAR; Thu, 25 Jul 2019 15:41:29 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C941201D1; Thu, 25 Jul 2019 15:41:28 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id v85so35657618lfa.6; Thu, 25 Jul 2019 15:41:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q+WmU2t0musgf2Z9C1vkYfLh/Ni9Z9a2uyX2pOERIDQ=; b=RQ3xSTIgKJXBAiqhJXh1a31dPMNGyt3gj2oRgWDFeUpeora4V1WXx8qC279p+78P5u PQcFc9NkUE3IxCkDa0nSYpQpzc8gIv6338Ist01F+AwprUht7RXaRZY/1sS7u6nrE9eP X3qOKK6N7SPFYfut+foRkgGA+5P+zIyZE6eQGY+/Wd8A7wlvD0rm3ns8YsDsBGeZg0rQ 5+j+0l8xhMk5mYzXX1+oBZHEJy+8CPdeUIGjNxzL3pW7ViLkXpDJdctgsfl6sLnEF08y ldiBzvN+cpT299x9VcNYBz14sEeYfnxCHSimduXUIOZ4W1zGaYMMY+W5trwI2CHmshDx +z1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q+WmU2t0musgf2Z9C1vkYfLh/Ni9Z9a2uyX2pOERIDQ=; b=pnRk/2Qs/U3R41N02uXUWjwrSjnZ0L85TuFPLhBaS07O+kvUNGcKA2UjyEXmfEgW4n hOM2EJRrIIOxagq4GoAylc8FRdc2MVo5qiLJMR08mb7+cDA1tSeiRYBQliKAoxrApWZs D2AKiKeqG6k1KZZCtrcrUUT1yrOQRwP+XpBeVeZGl0m9tgkH3lZYi+OHnTuV1wJHgU6i B5tsBtK8ihc5QcaJKkS/jIKTajwZPMvyezdWEZDidQKtUkWOU6KHU3OUpk5s/7R4b/oN 51JTEId/V9fQI6RHi9P6pM8bcxeoM4UeP3DvzTHoli9po1kyuyvec5wlSJtpw0ZAodPe ywjw==
X-Gm-Message-State: APjAAAV2/d0jVTppWx1XeHX3UU5cdusVRC1ICooqaHz5Unzy8r7k2o7D rbMIq4R73w7qKXz5NgHNl+JYg/SJl4uw9s+UaGg=
X-Google-Smtp-Source: APXvYqytmpD4sYhZ8nQGi53aAPYl1YLESvAbx5/diNiu3nF8dra40vTly8rz7ozHkhrQAQDmL5sNR4LX6gpga6LhE7Q=
X-Received: by 2002:a05:6512:48f:: with SMTP id v15mr11694691lfq.37.1564094486421; Thu, 25 Jul 2019 15:41:26 -0700 (PDT)
MIME-Version: 1.0
References: <5D3A0EB4029103460087056A_0_2148724@msclnypmsgsv03> <01c901d54326$80a67af0$81f370d0$@ndzh.com> <DM5PR11MB202727A18322CE10B30D93F2C1C10@DM5PR11MB2027.namprd11.prod.outlook.com> <CAEaWqmokZiFUVYr2Wcnk8hK38xZyL918RnBmrKaiPjh213hS=A@mail.gmail.com> <82732FCE-F604-4501-AED0-EE35E86A72B8@cisco.com>
In-Reply-To: <82732FCE-F604-4501-AED0-EE35E86A72B8@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 25 Jul 2019 18:41:14 -0400
Message-ID: <CA+RyBmW4ArDmej-U0Mad+qmawx-D8wcvv836Xjjo6PB8tNLEkg@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: Albert F <albert.f168@gmail.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "idr@ietf.org" <idr@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Susan Hares <shares@ndzh.com>, Albert Bloomberg <afu14@bloomberg.net>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000042259f058e8920a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/37KlIq_aDACTUuB0lR-JgpzCgKg>
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:41:32 -0000

Hi Acee,
I imagine that there could be multiple clients of the same BFD session with
different requirements in regard to dampening behavior. For example, the
delay each client desires to use may be different for each client of the
BFD session. If that is a plausible use case, I think that placing
dampening to a client may be a better choice.

Regards,
Greg

On Thu, Jul 25, 2019 at 6:23 PM Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Albert, Ketan,
>
> The authors will document dampening in the operational considerations. I’m
> also of the mind that the dampening should be done in BFD rather than the
> BFD clients (e.g., BGP).
>
> Thanks,
> Acee
>
>
>
> *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 List <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>
> *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>
> 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> *On Behalf Of *Susan Hares
> *Sent:* 25 July 2019 16:21
> *To:* 'Albert Fu' <afu14@bloomberg.net>; 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 <idr-bounces@ietf.org>] *On
> Behalf Of *Albert Fu (BLOOMBERG/ 120 PARK)
> *Sent:* Thursday, July 25, 2019 4:19 PM
> *To:* 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
> https://www.ietf.org/mailman/listinfo/idr
>
>