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

"Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net> Fri, 26 October 2018 17:06 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 A8A611277CC for <rtg-bfd@ietfa.amsl.com>; Fri, 26 Oct 2018 10:06:31 -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 da9L7uTUZAzO for <rtg-bfd@ietfa.amsl.com>; Fri, 26 Oct 2018 10:06:30 -0700 (PDT)
Received: from mgnj13.bloomberg.net (mgnj13.bloomberg.net [69.191.244.234]) (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 B64EA1252B7 for <rtg-bfd@ietf.org>; Fri, 26 Oct 2018 10:06:29 -0700 (PDT)
X-BB-Reception-Complete: 26 Oct 2018 13:06:27 -0400
X-IP-Listener: Outgoing Mail
X-IP-MID: 207866003
Received: from msllnjpmsgsv06.bloomberg.com (HELO msllnjpmsgsv06) ([10.126.134.166]) by mgnj13.bloomberg.net with SMTP; 26 Oct 2018 13:06:27 -0400
X-BLP-INETSVC: version=BLP_APP_S_INETSVC_1.0.1; host=mgnj13:25; conid=472
Date: Fri, 26 Oct 2018 17:06:27 -0000
From: "Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net>
Reply-To: Albert Fu <afu14@bloomberg.net>
To: jhaas@pfrc.org, acee@cisco.com
Cc: rtg-bfd@ietf.org, ginsberg@cisco.com
MIME-Version: 1.0
Message-ID: <5BD349930083010800390677_0_50013@msllnjpmsgsv06>
X-BLP-GUID: 5BD3499300830108003906770000
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Content-Type: multipart/alternative; boundary="BOUNDARY_5BD349930083010800390677_0_66020_msllnjpmsgsv06"
Content-ID: <ID_5BD349930083010800390677_0_48660@msllnjpmsgsv06>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/qCfMJHCW9ceagtCYiJ1mRNZvr1s>
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:06:32 -0000

Hi Acee,

>> Commenting specifically on the OSPF case, when you have such misconfigured
>> MTUs, this manifests as weird protocol hiccups.B  You don't so much detect
>> that there's an MTU issue - you just see OSPF failing to make progress.
>
> However, when implementations start supporting ietf-ospf.yang, there?ll be an
> if-config-err notification specifically indicating an MTU-mismatch. ;^) 

As mentioned previously, the issue that we are trying to address is where there's
no issue with OSPF MTU config, but the WAN circuit fails to carry traffic up to
the configured MTU. 

For example, in last 2 weeks, we have 2 such issues, one with major Tier 1
provider in US and another one with Tier 1 provider in Europe, where OSPF was humming 
along fine, the circuits could carry 1500 byte payload but not 1512 byte payload.
This caused intermittent issue to our end user traffic that traversed these links and
not desirable. This is a fault situation - the circuit should not be put
in production. We have redundant circuits and would want to divert traffic from 
these links automatically (hence this draft).

Thanks
Albert.