IETF Logo Mail Archive

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

"Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net> Thu, 25 July 2019 20:19 UTC

Return-Path: <afu14@bloomberg.net>
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 4C9E71201E3 for <idr@ietfa.amsl.com>; Thu, 25 Jul 2019 13:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ma-UDtUo4oYa for <idr@ietfa.amsl.com>; Thu, 25 Jul 2019 13:19:02 -0700 (PDT)
Received: from mgny13.bloomberg.net (mgny13.bloomberg.net [69.191.192.139]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FEEA1201DB for <idr@ietf.org>; Thu, 25 Jul 2019 13:19:01 -0700 (PDT)
X-BB-Reception-Complete: 25 Jul 2019 16:19:00 -0400
X-IP-Listener: Outgoing Mail
X-IP-MID: 410819138
Received: from msclnypmsgsv03.bloomberg.com (HELO msclnypmsgsv03) ([10.126.9.118]) by mgny13.bloomberg.net with SMTP; 25 Jul 2019 16:19:00 -0400
X-BLP-INETSVC: version=BLP_APP_S_INETSVC_1.0.1; host=mgny13:25; conid=63
Date: Thu, 25 Jul 2019 20:19:00 -0000
From: "Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net>
Reply-To: Albert Fu <afu14@bloomberg.net>
To: idr@ietf.org
MIME-Version: 1.0
Message-ID: <5D3A0EB4029103460087056A_0_2148724@msclnypmsgsv03>
X-BLP-GUID: 5D3A0EB4029103460087056A0000
Content-Type: multipart/alternative; boundary="BOUNDARY_5D3A0EB4029103460087056A_0_2731023_msclnypmsgsv03"
Content-ID: <ID_5D3A0EB4029103460087056A_0_1983414@msclnypmsgsv03>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/KrY55po2FojcKdKP6Zj1fxHz02E>
Subject: [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 20:19:04 -0000

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

v2.23.0 | Report a Bug | By Email