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

Jeff Tantsura <jefftant.ietf@gmail.com> Thu, 25 July 2019 20:33 UTC

Return-Path: <jefftant.ietf@gmail.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 C5DE21201EF; Thu, 25 Jul 2019 13:33:50 -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 ajWZDWk1xGYt; Thu, 25 Jul 2019 13:33:48 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 B880B1201DB; Thu, 25 Jul 2019 13:33:47 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id d15so37435732qkl.4; Thu, 25 Jul 2019 13:33:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=nPXD8rt1YwAqwL33aizXFprmte4IVUFvESsm6NLNXZs=; b=nEHo9AZZBq/FTCqbZZKK2rLxyLwJ1b/bgr9eDzG/FBDudHY/VUCCMqKCn473KFI0DV cJRB2+jDAq0NdLQg6G8VMi17WhKjrTrkROI5fbUgti9+hUMnIhhyMEeEPMRdn1DvUaNG pevn3bEr9/IFgOuuHSxY0pktHmywyMo4WMQ0wguA+rL+U8GFsvEWkLqf3kOniTRDmalL krc37fsKACNoQTtpW1DDruJojyMW5l2YjJVthtv2aVLXLuavEtywVHM9lJzRRLvnQIPd 6N6snPEDV5mOPbwFJNIC7yeuyH7xpKwHM2T96VMaGqW2tHfgZwGM1Kk4sYB4xlAtBRLD eeNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=nPXD8rt1YwAqwL33aizXFprmte4IVUFvESsm6NLNXZs=; b=CEFd/YS9J4qFnoLCMrygAqydLJ0+xiqM7EYEIAAL2VoC+D7RzbQTxEWVcaChwzGa02 ESkpKPf4dO8RILQ22bax1IjME6HOgVtWfoG7ajvz8qKEt2wZftjV8NGw4W69sejQ3MCK UQFIsNdRUu+sqjbyxPE13IM9rHlujtZTLzIteY3vq+jjsfg1/4fdPjX911+V79/qxx4S tAjO1Pev5L+aqw5PTWM893+IunqHxQTJs0X3CiLkHmmyhLsuk2iIRfCvScHzYgGNpP9z OfezKn1wDDLZ/XPsSsmdKFPk7LVHslvX2IZRvN8sCqMA4OnXibFJmVwljjnd2Ioq7C0x vayA==
X-Gm-Message-State: APjAAAWYBkeIUgValnoHo+xHYrQOeG8i9tXeAQvhVS4sR9Ay8RrRmU+G 7mY4vWamPZDhKIx6Id6Pfjs=
X-Google-Smtp-Source: APXvYqxCiRLVW87u7oVVmUGRtV2W077rT+X9Eti1v5DXVNGjuQqhg6onOfhdzYZtndUC9GSB1svErQ==
X-Received: by 2002:a37:a2cc:: with SMTP id l195mr57447072qke.362.1564086826833; Thu, 25 Jul 2019 13:33:46 -0700 (PDT)
Received: from [2001:67c:370:128:2083:8e8c:ff7f::] ([2001:67c:370:128:cc7f:9003:6f91:7ebf]) by smtp.gmail.com with ESMTPSA id z19sm23587256qtu.43.2019.07.25.13.33.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 13:33:46 -0700 (PDT)
Date: Thu, 25 Jul 2019 16:33:39 -0400
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Susan Hares <shares@ndzh.com>, Albert Fu <afu14@bloomberg.net>, "idr@ietf.org" <idr@ietf.org>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Message-ID: <45346fa5-13c2-4565-9795-a2e89d33fc6e@Spark>
In-Reply-To: <DM5PR11MB202727A18322CE10B30D93F2C1C10@DM5PR11MB2027.namprd11.prod.outlook.com>
References: <5D3A0EB4029103460087056A_0_2148724@msclnypmsgsv03> <01c901d54326$80a67af0$81f370d0$@ndzh.com> <DM5PR11MB202727A18322CE10B30D93F2C1C10@DM5PR11MB2027.namprd11.prod.outlook.com>
Subject: Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
X-Readdle-Message-ID: 45346fa5-13c2-4565-9795-a2e89d33fc6e@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5d3a1229_5451cf49_12dc6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/EZW7IGt_3HKT07WEPwCrqjJBsYs>
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: Thu, 25 Jul 2019 20:33:51 -0000

Sue,

I support progress of this draft, it addresses real problem.
On Redback side of things we have implemented this around 2013, logic (proprietary) kept in BFD indeed, so +1 Ketan. I’d document it as an informal feature, that is recommended (same for YANG)

Cheers,
Jeff
On Jul 25, 2019, 4:27 PM -0400, 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] 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
> >
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr