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

"Acee Lindem (acee)" <> Tue, 23 October 2018 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B85A128C65 for <>; Tue, 23 Oct 2018 10:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.969
X-Spam-Status: No, score=-14.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U8kEKV-8Q5Gz for <>; Tue, 23 Oct 2018 10:51:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C50901274D0 for <>; Tue, 23 Oct 2018 10:51:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=33994; q=dns/txt; s=iport; t=1540317113; x=1541526713; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Gft3N8zKguDUdVEWitVDcJoUyald0B784H+iufacqjA=; b=EhJp1eVab7usbyDVWIBBUxkgdfkUdRIhslUXdLPnxLC8RqmLg2PCGax9 Mn4XK1AuNmBgNrMfF3eSlvgzlzqjyifrEgwxf5nckv3VOIU/owewyjZhL 6DbvQUdx/MjhI3u4DQJXXpYKQC2D7NB/X5qDDsYg/fg79u0n5fqshMpBu o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.54,417,1534809600"; d="scan'208,217";a="189886148"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 17:51:52 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w9NHpqP3029292 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2018 17:51:52 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Oct 2018 13:51:51 -0400
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Tue, 23 Oct 2018 13:51:51 -0400
From: "Acee Lindem (acee)" <>
To: Albert Fu <>, "Les Ginsberg (ginsberg)" <>, "" <>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Thread-Topic: BFD WG adoption for draft-haas-bfd-large-packets
Thread-Index: AQHUavUM2obCS5tWFUCJRL2ls+mZdKUtHDwA
Date: Tue, 23 Oct 2018 17:51:51 +0000
Message-ID: <>
References: <5BCF58F5029804A2003907DE_0_60079@msllnjpmsgsv06>
In-Reply-To: <5BCF58F5029804A2003907DE_0_60079@msllnjpmsgsv06>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_5679BA3B2BBD46698906CCC26D6EA481ciscocom_"
MIME-Version: 1.0
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 17:51:57 -0000

From: "Albert Fu (BLOOMBERG/ 120 PARK)" <>
Reply-To: Albert Fu <>
Date: Tuesday, October 23, 2018 at 1:23 PM
To: "Les Ginsberg (ginsberg)" <>, Acee Lindem <>, "" <>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets

(* Resending smaller message *)

Hi Acee,

Please see comments in-line.



From: At: 10/23/18 13:02:49
To: Albert Fu (BLOOMBERG/ 120 PARK ) <> ,<>,<>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
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 šŸ˜‰

AF> There's no bug.

1)  The issue we have seen is with the Telco network. The router can happily transmit and receive up to configured interface MTU, but the Telco circuit fails to support it. One example is when Telco uses L2VPN to deliver the P2P service to us, but due to some faults, traffic was re-routed to a mis-configured path that did not support our MTU size (e.g. MTU on Telco PE router was not increased to account for MPLS headers for the L2VPN service).
Ok ā€“ in this case, youā€™d need to exercise the data plane with maximum size packets. And make the MTU part of the SLA you secure from the provider.
Thanks, Acee

2) AFAIK, the OSPF MTU detection is based on checking MTU value in the DBD packet, The actual OSPF packet size may be smaller and may not detect data plane issue in Telco network during OSPF session establishment.

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.

AF> We have encountered the MTU issue without any interface flaps on our routers (no config change on our routers). The MTU issue occurred within the Telco network. Note also some Telco providers that provide WAN circuit spanning several countries may make use of smaller local providers to provide the last mile.  We have seen issues with the smaller providers.