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

["Albert Fu (BLOOMBERG/ 120 PARK)" <[e-mail]>]

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.

Thanks
Albert

From: [e-mail] At: 10/23/18 17:04:27To:  [e-mail]
Cc:  Albert Fu (BLOOMBERG/ 120 PARK ) ,  [e-mail],  [e-mail]
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? 

 
Regards, 
- Naiming 


On Oct 23, 2018, at 10:02 AM, Acee Lindem (acee) <[e-mail]> wrote: 
Hi Albert,  
  
From: "Albert Fu (BLOOMBERG/ 120 PARK)" <[e-mail]>
Reply-To: Albert Fu <[e-mail]>
Date: Tuesday, October 23, 2018 at 12:45 PM
To: "[e-mail]" <[e-mail]>,  "Les Ginsberg (ginsberg)" <[e-mail]>, Acee Lindem <[e-mail]>
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. 
  
Thanks, 
Acee  
  
Thanks 
Albert