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

Albert F <albert.f168@gmail.com> Thu, 25 July 2019 21:13 UTC

Return-Path: <albert.f168@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 8DD5A1201F1; Thu, 25 Jul 2019 14:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Level:
X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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=no 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 RlnAIqh5j--Y; Thu, 25 Jul 2019 14:13:39 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 B1D0E1201DB; Thu, 25 Jul 2019 14:13:39 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id m23so34699198vso.1; Thu, 25 Jul 2019 14:13:39 -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=XOMDS7MH03legfjAn3UrK2CZXjfWfSJ7fghg9ao3d/Q=; b=QWRVnq84T6pQ/lJ0Mq6gGwM8rd73sQZrTiD8B9cS4IesCLT2iajKM6Mv/TN3bToKTr S0D5xq9M4zQNN1Kg8+ax5jUKP2cBLPBq8XYi5L3VL1nv65TaQgqu6h68mAsEkGEjAMeP z+2yTTfhreFLGbbA/75gEFY+imk9Bl6xSySvr/hAhWd0t25jGnE1XodlBmwZeczDtMkG N+8AP4lHsY004FemtX34+KfiHHba21EXUc6v/LdhGVDBxIeJlgdEUM82Xo8KwxoRcxty 1c59MKC4moU7tkbxMkDLSIWBwzUOgo8XCOqyKmJd+G+Y/2U2X/SYZF5jKTuXthypwmEX iucw==
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=XOMDS7MH03legfjAn3UrK2CZXjfWfSJ7fghg9ao3d/Q=; b=GL5Z3iZ4vK5rJ3to+KMLmjCypBX0GH0GqBvIucsH5wngxk0ldnt+nDBgruT/cZlT/E /Def+Njjwv2SJZnhIHG/B+fyTajsSvijRy1BqxD9lfQPrDckniXb3jai5vWRIDogkv15 5aVFzYsCJ1KaO2Sy84uyk6/3+WNM25xAaaSErABvVnF2vh/Nu+/IzTp264VmNZJXFHle wRc6BQbvP3LVIhTJobZNisI52RGs6Bj/IsDhdlinQo6AZ0EhqUxqkgWfD4IYVYPWA8uK 91uGy0dcLeNCb42+0asL9iTHJ44AQO8lJpb54aWycikugTSTPhAEJ+iMzumskHGrWhi1 9vQg==
X-Gm-Message-State: APjAAAVK/gHfnZ2HCJjNT6Zt8wvAkNCdX6dFel1x9tfmRqC4EY4R6a9g 9NM7WGg0lXcvD6Kz+9AI03zhnE9il+k8u7cksg==
X-Google-Smtp-Source: APXvYqwKCJM09W4c7kHaMqsC3J+eqFVSpodwYRobOahB2eGVKrsSVDDfQkNuYcWwXiOOTzr15lxkgwXCTk0b+Ip4S8A=
X-Received: by 2002:a67:f281:: with SMTP id m1mr10877224vsk.184.1564089218593; Thu, 25 Jul 2019 14:13:38 -0700 (PDT)
MIME-Version: 1.0
References: <5D3A0EB4029103460087056A_0_2148724@msclnypmsgsv03> <01c901d54326$80a67af0$81f370d0$@ndzh.com> <DM5PR11MB202727A18322CE10B30D93F2C1C10@DM5PR11MB2027.namprd11.prod.outlook.com>
In-Reply-To: <DM5PR11MB202727A18322CE10B30D93F2C1C10@DM5PR11MB2027.namprd11.prod.outlook.com>
From: Albert F <albert.f168@gmail.com>
Date: Thu, 25 Jul 2019 17:13:25 -0400
Message-ID: <CAEaWqmokZiFUVYr2Wcnk8hK38xZyL918RnBmrKaiPjh213hS=A@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: Susan Hares <shares@ndzh.com>, Albert Bloomberg <afu14@bloomberg.net>, "idr@ietf.org" <idr@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004578cc058e87e62c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ahScPb6-WEbApafPPBlaVVxU_Kc>
Subject: Re: [Idr] 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 21:13:42 -0000

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>et>; 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
>