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: naim...@cisco.com At: 10/23/18 17:04:27To: a...@cisco.com
Cc: Albert Fu (BLOOMBERG/ 120 PARK ) , rtg-bfd@ietf.org, ginsb...@cisco.com
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) <a...@cisco.com> wrote:
Hi Albert,
From: "Albert Fu (BLOOMBERG/ 120 PARK)" <af...@bloomberg.net>
Reply-To: Albert Fu <af...@bloomberg.net>
Date: Tuesday, October 23, 2018 at 12:45 PM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Les Ginsberg (ginsberg)"
<ginsb...@cisco.com>, Acee Lindem <a...@cisco.com>
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
