Re:Rtg-bfd Digest, Vol 152, Issue 36

"Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net> Fri, 26 October 2018 17:22 UTC

Return-Path: <afu14@bloomberg.net>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F0E130E94 for <rtg-bfd@ietfa.amsl.com>; Fri, 26 Oct 2018 10:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Au9wKOMtAacn for <rtg-bfd@ietfa.amsl.com>; Fri, 26 Oct 2018 10:22:41 -0700 (PDT)
Received: from mgnj5.bloomberg.net (mgnj5.bloomberg.net [69.191.244.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A708130E63 for <rtg-bfd@ietf.org>; Fri, 26 Oct 2018 10:22:41 -0700 (PDT)
X-BB-Reception-Complete: 26 Oct 2018 13:22:39 -0400
X-IP-Listener: Outgoing Mail
X-IP-MID: 840591434
Received: from msllnjpmsgsv06.bloomberg.com (HELO msllnjpmsgsv06) ([10.126.134.166]) by mgnj5.bloomberg.net with SMTP; 26 Oct 2018 13:22:39 -0400
X-BLP-INETSVC: version=BLP_APP_S_INETSVC_1.0.1; host=mgnj5:25; conid=339
Date: Fri, 26 Oct 2018 17:22:40 -0000
From: "Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net>
Reply-To: "Albert Fu" <afu14@bloomberg.net>
To: ginsberg@cisco.com, rtg-bfd@ietf.org
Cc: jhaas@juniper.net
MIME-Version: 1.0
Message-ID: <5BD34D60028404700039072F_0_51962@msllnjpmsgsv06>
X-BLP-GUID: 5BD34D60028404700039072F0000
Subject: =?UTF-8?B?UmU6UnRnLWJmZCBEaWdlc3QsIFZvbCAxNTIsIElzc3VlIDM2?=
Content-Type: multipart/alternative; boundary="BOUNDARY_5BD34D60028404700039072F_0_68231_msllnjpmsgsv06"
Content-ID: <ID_5BD34D60028404700039072F_0_50597@msllnjpmsgsv06>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/SjHKggfKzXhWwrDdbaXzJFiTyLE>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Oct 2018 17:22:49 -0000

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.

Thanks
Albert