Re:Rtg-bfd Digest, Vol 164, Issue 24

"Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net> Thu, 17 October 2019 16:20 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 A3A7A120A23 for <rtg-bfd@ietfa.amsl.com>; Thu, 17 Oct 2019 09:20:59 -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 DrzvUaAFNZcL for <rtg-bfd@ietfa.amsl.com>; Thu, 17 Oct 2019 09:20:57 -0700 (PDT)
Received: from mgnj1.bloomberg.net (mgnj1.bloomberg.net [69.191.244.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5907120A1A for <rtg-bfd@ietf.org>; Thu, 17 Oct 2019 09:20:54 -0700 (PDT)
X-BB-Reception-Complete: 17 Oct 2019 12:20:53 -0400
X-IP-Listener: Outgoing Mail
X-IP-MID: 1290623284
Received: from msllnjpmsgsv06.bloomberg.com (HELO msllnjpmsgsv06) ([10.126.134.166]) by mgnj1.bloomberg.net with SMTP; 17 Oct 2019 12:20:53 -0400
X-BLP-INETSVC: version=BLP_APP_S_INETSVC_1.0.1; host=mgnj1:25; conid=154
Date: Thu, 17 Oct 2019 16:20:53 -0000
From: "Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net>
Reply-To: "Albert Fu" <afu14@bloomberg.net>
To: rtg-bfd@ietf.org
MIME-Version: 1.0
Message-ID: <5DA894E5016C07A400390638_0_53266@msllnjpmsgsv06>
X-BLP-GUID: 5DA894E5016C07A4003906380000
Subject: =?UTF-8?B?UmU6UnRnLWJmZCBEaWdlc3QsIFZvbCAxNjQsIElzc3VlIDI0?=
Content-Type: multipart/alternative; boundary="BOUNDARY_5DA894E5016C07A400390638_0_71662_msllnjpmsgsv06"
Content-ID: <ID_5DA894E5016C07A400390638_0_53221@msllnjpmsgsv06>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/cZYRUbrF1Vq7GGyeda92DD5NLnY>
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: Thu, 17 Oct 2019 16:21:00 -0000

Hi Robert,


> Dear WG,
> 
> Thank you Gyan for your note.
>
> It very clearly highlights my primary concern expressed earlier of false
> assumptions on how engineers may try to (mis)use bfd-large in multihop
> cases.
>
> Below note is a brilliant example of how one may not realize that actual
> paths BFD packets take can be just a fraction of paths their data plane or
> even other control plane packets may traverse over a network or set of
> networks.
>
> I am always concerned when protocol extensions being standardized are known
> to only work in 1 out of 10 deployment scenarios and when chances of such
> opportunity of incorrect use are evident yet no safety inline fuse exist.
> 
> Many thx,
> Robert.

As mentioned previously, there are well known cases where BFD can not determine data plane error, and this is not unique to the BFD Large Packet Draft.


I do not know how other customers use BFD, but can say that in our network, almost all of our BFD use cases are P2P (IGP/eBGP) (and also Control-plane independent), where BFD Large Packet draft will be very useful and deterministic in identifying the issue as it happens.


Thanks

Albert