Re: BFD WG adoption for draft-haas-bfd-large-packets

"Albert Fu (BLOOMBERG/ 120 PARK)" <> Tue, 23 October 2018 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DA04130E58 for <>; Tue, 23 Oct 2018 14:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 59QZ2iNfz_tT for <>; Tue, 23 Oct 2018 14:44:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B056F130DEC for <>; Tue, 23 Oct 2018 14:44:42 -0700 (PDT)
X-BB-Reception-Complete: 23 Oct 2018 17:44:41 -0400
X-IP-Listener: Outgoing Mail
X-IP-MID: 1037331242
Received: from (HELO msllnjpmsgsv06) ([]) by with SMTP; 23 Oct 2018 17:44:41 -0400
X-BLP-INETSVC: version=BLP_APP_S_INETSVC_1.0.1; host=mgnj1:25; conid=454
Date: Tue, 23 Oct 2018 21:44:41 -0000
From: "Albert Fu (BLOOMBERG/ 120 PARK)" <>
Reply-To: Albert Fu <>
MIME-Version: 1.0
Message-ID: <5BCF964902AB003C00390A34_0_90570@msllnjpmsgsv06>
X-BLP-GUID: 5BCF964902AB003C00390A340000
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Content-Type: multipart/alternative; boundary="BOUNDARY_5BCF964902AB003C00390A34_0_125868_msllnjpmsgsv06"
Content-ID: <ID_5BCF964902AB003C00390A34_0_88366@msllnjpmsgsv06>
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, 23 Oct 2018 21:44:45 -0000

Hi Naiming,

I agree with you that BFD padding should be an option, and on per neighbor/interface basis. 

For internal infrastructure consisting of mainly back-to-back links, network designers can choose to use default BFD behavior without padding (unless they want to guard against potential config error or data plane error due to HW issues). In our case, most of our links are on WAN circuits - we would like to use BFD padding to guard against Telco MTU issue.


From: At: 10/23/18 17:04:27To:
Cc:  Albert Fu (BLOOMBERG/ 120 PARK ) ,,
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets


 I understand in some networks (such as in the network Albert mentioned about) 
it may need sub-second detection if the MTU has been impacted on the path, 
but that should only be an implementation/operational option, I would think most 
of the networks will not use this way.  The draft should handle it in 
a general way, or are we saying other cases are not valid or we need a 
different draft to do the other ways? 

- Naiming 

On Oct 23, 2018, at 10:02 AM, Acee Lindem (acee) <> wrote: 
Hi Albert,  
From: "Albert Fu (BLOOMBERG/ 120 PARK)" <>
Reply-To: Albert Fu <>
Date: Tuesday, October 23, 2018 at 12:45 PM
To: "" <>,  "Les Ginsberg (ginsberg)" <>, Acee Lindem <>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets 
Hi Acee, 
You are right in that this issue does not happen frequently, but when it does, it is time consuming to troubleshoot and causes unnecessary network downtime to some applications (e.g. between  two end hosts, some applications worked fine, but others would intermittently fail when they tried to send large size packets over the failing ECMP path). 
So youā€™re saying there is a problem where the data plane interfaces do not support the configured MTU due to a SW bug? I hope these are not our routers šŸ˜‰ 
I believe the OSPF MTU detection is a control plane mechanism to check config, and may not necessary detect a data plane MTU issue (since OSPF does not support padding). Also, most of our issues  occurred after routing adjacency had been established, and without any network alarms. 
Right. However, if the interface is flapped when the MTU changes, OSPF would detect dynamic MTU changes (e.g., configuration), that the control plane is aware of.