Re: Rtg-bfd Digest, Vol 163, Issue 25

"Albert Fu (BLOOMBERG/ 120 PARK)" <> Tue, 01 October 2019 23:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8D38120100 for <>; Tue, 1 Oct 2019 16:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iSgTf6_BVtrp for <>; Tue, 1 Oct 2019 16:11:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 972071200D5 for <>; Tue, 1 Oct 2019 16:11:16 -0700 (PDT)
X-BB-Reception-Complete: 01 Oct 2019 19:11:12 -0400
X-IP-Listener: Outgoing Mail
X-IP-MID: 1140646980
Received: from (HELO msclnypmsgsv04) ([]) by with SMTP; 01 Oct 2019 19:11:12 -0400
X-BLP-INETSVC: version=BLP_APP_S_INETSVC_1.0.1; host=mgny4:25; conid=165
Date: Tue, 1 Oct 2019 23:11:13 -0000
From: "Albert Fu (BLOOMBERG/ 120 PARK)" <>
Reply-To: "Albert Fu" <>
MIME-Version: 1.0
Message-ID: <5D93DD11010004620119029E_0_2183410@msclnypmsgsv04>
X-BLP-GUID: 5D93DD11010004620119029E0000
Subject: =?UTF-8?B?UmU6IFJ0Zy1iZmQgRGlnZXN0LCBWb2wgMTYzLCBJc3N1ZSAyNQ==?=
Content-Type: multipart/alternative; boundary="BOUNDARY_5D93DD11010004620119029E_0_2658444_msclnypmsgsv04"
Content-ID: <ID_5D93DD11010004620119029E_0_2018583@msclnypmsgsv04>
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Oct 2019 23:11:19 -0000

Hi Robert,

> Thank you for sharing the experience and your use case. 

> However when we make any protocol extension we need to make sure all possible deployment cases are covered
> and it must be well understood how the proposed extension will operate in basic deployment scenarios I 
> enumerated. I really do not think we should be standardizing extension for single use case based on the behavior 
> someone is reporting as "likely to occur".

> We all agree that if you have a p2p fiber link between routers there is no issue. 

> The issue surface when you are using emulated circuits as your p2p links. So the solution should allow to detect
> the problem in all cases it can happen. Perhaps BFD is not the right tool for this. Perhaps we need to go back to 
> BESS WG and report that VPWS or EVPN based p2p emulated circuits were not design right as they exhibit observed
> issues. 

There are well known cases, including those you mentioned, where BFD has limitations in deterministically detecting data plane issue, and not specific with the BFD Large Packet Draft. I am a novice to the IETF process, and not sure if we need to mention them here, but shall discuss with Jeff if it is worth highlighting them.

> We won't have control over how the Provider maps our traffic (BFD/data).  

> Well of course you do :)  Just imagine if your BFD packets (in set equal to configured multiplier) would start 
> using random UDP source port which then would be mapped to different ECMP buckets along the way in provider's
> underlay ? 

We have not encountered the issue that you are highlighting. I feel it is a theoretical issue in regards to the problems we have seen, and would rather focus on the real issue. If what you are saying does prove to be true, we can start investing energy on it. 

The thing I like about the BFD Large Packet draft (apart from addressing a known issue we have been facing), is that it does not make any assumption about the underlying network. It could be used to detect hardware issue, device MTU being changed due to power outage, or MTU configuration error. 

> Kind regards,
> Robert.