Re: BFD WG adoption for draft-haas-bfd-large-packets
"Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net> Mon, 29 October 2018 17:38 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 05AD5131048 for <rtg-bfd@ietfa.amsl.com>; Mon, 29 Oct 2018 10:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 Tv6E8WawTh0D for <rtg-bfd@ietfa.amsl.com>; Mon, 29 Oct 2018 10:38:33 -0700 (PDT)
Received: from mgnj2.bloomberg.net (mgnj2.bloomberg.net [69.191.244.20]) (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 56EAC131023 for <rtg-bfd@ietf.org>; Mon, 29 Oct 2018 10:38:33 -0700 (PDT)
X-BB-Reception-Complete: 29 Oct 2018 13:38:32 -0400
X-IP-Listener: Outgoing Mail
X-IP-MID: 1028854298
Received: from msllnjpmsgsv06.bloomberg.com (HELO msllnjpmsgsv06) ([10.126.134.166]) by mgnj2.bloomberg.net with SMTP; 29 Oct 2018 13:38:32 -0400
X-BLP-INETSVC: version=BLP_APP_S_INETSVC_1.0.1; host=mgnj2:25; conid=191
Date: Mon, 29 Oct 2018 17:38:32 -0000
From: "Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net>
Reply-To: Albert Fu <afu14@bloomberg.net>
To: ginsberg@cisco.com, jhaas@juniper.net, rtg-bfd@ietf.org
MIME-Version: 1.0
Message-ID: <5BD74598029D054400390770_0_68291@msllnjpmsgsv06>
X-BLP-GUID: 5BD74598029D0544003907700000
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Content-Type: multipart/alternative; boundary="BOUNDARY_5BD74598029D054400390770_0_86712_msllnjpmsgsv06"
Content-ID: <ID_5BD74598029D054400390770_0_67285@msllnjpmsgsv06>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/KMpjLpZVMs6SctdmnrvlXZJ6eeM>
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: Mon, 29 Oct 2018 17:38:35 -0000
Hi Les, > Jeff/Albert - > > Given the MTU issue is associated with a link coming up - and the use of Echo would allow the problem to be detected and prevent the BFD session from coming up - > and you are acknowledging that the protocol allows padded Echo packets today ... > > is there really a need to do anything more? > > Les > Actually, all the issues we have observed were not associated with link going up. The MTU issues occurred after OSPF/BGP had established adjacency without any events on the routers. ospf/BGP hellos/keepalives continued to be transmitted fine (small packet size), but applications sending max size packets over the link would time out and fail. Hence, I mentioned several times that this issue is rather time consuming to troubleshoot, as the cause is with the Telco network and outside of our control and we do not see any alarms. I did also look at BFD echo mode. As Jeff indicated, this is not widely deployed (among the vendors we use, only one supports it). Thanks Albert
- Re: BFD WG adoption for draft-haas-bfd-large-pack… Albert Fu (BLOOMBERG/ 120 PARK)
- RE: Re: BFD WG adoption for draft-haas-bfd-large-… Les Ginsberg (ginsberg)
- Re: Re: BFD WG adoption for draft-haas-bfd-large-… Jeffrey Haas