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

"Albert Fu (BLOOMBERG/ 120 PARK)" <> Fri, 26 October 2018 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EECE212F1AB for <>; Fri, 26 Oct 2018 10:52:43 -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 VFhmTrJPpkWG for <>; Fri, 26 Oct 2018 10:52:42 -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 1B534128BCC for <>; Fri, 26 Oct 2018 10:52:41 -0700 (PDT)
X-BB-Reception-Complete: 26 Oct 2018 13:52:40 -0400
X-IP-Listener: Outgoing Mail
X-IP-MID: 206391973
Received: from (HELO msclnypmsgsv04) ([]) by with SMTP; 26 Oct 2018 13:52:40 -0400
X-BLP-INETSVC: version=BLP_APP_S_INETSVC_1.0.1; host=mgny13:25; conid=107
Date: Fri, 26 Oct 2018 17:52:40 -0000
From: "Albert Fu (BLOOMBERG/ 120 PARK)" <>
Reply-To: Albert Fu <>
MIME-Version: 1.0
Message-ID: <5BD3546802D303F600F50660_0_1567795@msclnypmsgsv04>
X-BLP-GUID: 5BD3546802D303F600F506600000
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Content-Type: multipart/alternative; boundary="BOUNDARY_5BD3546802D303F600F50660_0_1818880_msclnypmsgsv04"
Content-ID: <ID_5BD3546802D303F600F50660_0_1295707@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: Fri, 26 Oct 2018 17:52:44 -0000

(* sorry, resend ING with updated subject *) 

Hi Les,

> [Les:] I have read this draft - not sure how relevant it is.
> Naiming had suggested that MTU sized packets need not be sent all the time but only occasionally - 
> and that a failure might not be used to take the BFD session down - 
> rather it would be seen as a "soft-failure" and reported separately from the BFD session state.
> My response was in that context - which it seems was also in your mind in your BFD Echo proposal.
> This, however, seems not to be what Albert has in mind - as he has since commented that he really wants to have sub-second detection of MTU issues and 
> he wants traffic rerouted "immediately".
>  Les

The MTU issue is a "hard" failure - e.g. any TCP application that's 
trying to send traffic with the MTU sized payload over that link 
will time out, and fail. Applications (between the same end stations)
that send small packets over that link will continue to work fine. 
Hence, this makes troubleshooting that much harder especially in 
network with lots of ECMP paths.