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

Gyan Mishra <> Fri, 18 October 2019 04:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CAF1C1201CE for <>; Thu, 17 Oct 2019 21:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gk6rjCnGdbjY for <>; Thu, 17 Oct 2019 21:12:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF1E4120044 for <>; Thu, 17 Oct 2019 21:12:11 -0700 (PDT)
Received: by with SMTP id c21so7158545qtj.12 for <>; Thu, 17 Oct 2019 21:12:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h9JuepvQK8AZuPEKo0T1SAAO+0WIt4+cW/vBX+IDVpA=; b=bZfN732vwveWe61LZFdCT/RoEBF382ABpuF4iUuwkmXdgY8dE7ZQSAPBIMK9i0P3ge +d7NaVd77/kd1IJ8BqLha/ZBIvtTg/1C/GqX4lNyJMMcTR/pxIE9u4ZU4Bx9xeaAHr/A wf8YsD5R+TMcm8g9bbJvgVs1V14WoJbhZ45UZ3m5+Q9Pc+0gJDP+nNyenQK66GFtQD7X VbbJDYN7TNQIPAOlCCj7Tvmgkjtdbi/OXKabrtJM6zdhNRZhXmVgUwPetePzshIAMDJc RaAhqWiGU+YWzrNFX1dWOuLS9L61RjHxIAAIq/ottyXJyIQZfh2y9wrwhbg3XcXPvW/r IwLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h9JuepvQK8AZuPEKo0T1SAAO+0WIt4+cW/vBX+IDVpA=; b=gA8U5yLMm7BtnaGdOw+c6UkOPC1uIzsGSqBMUHkuwnZejeSxXXg89pXfEmZd5KMzwf mVfwmigyyMIwJnZDJUUKKaGtM4QVzP84OpSNNGUnxyIfOb9U7mE9GKNTRskvnsSma3JA 58F5RCvx2Z1gvy0MYzgj5jsyUiXMgnJrb/ktnUXB5N4XBf4wTd77dDmeB+uUd3qmcTFx 1vKVnDBZHFzj501I87uARqEcmYpxIhXRvkmrZU8zblhDp+E+w+EeSSanAHHAFD1MENUu mYh6J8YLYJX2tXs3IWYuKAtI7NBnfbfWDSQ3rSRjesLShu1Gw3YyzqxxLowK9o7165Zp p1Pg==
X-Gm-Message-State: APjAAAUTQuroMmDlbO+O0xF87UNzGB5rkuf2jMh14KakfNSWAp5/YbGO 1Jj5B3cDqAsWal371YgybAU=
X-Google-Smtp-Source: APXvYqxeNW6rO11Le7PBaiL5fStLFNsw+oFg5FktTsJGJHyNMQntlhJfW7jBuyuv7w0/IFnOTOiqlg==
X-Received: by 2002:ac8:2e0d:: with SMTP id r13mr7680117qta.54.1571371930557; Thu, 17 Oct 2019 21:12:10 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id p56sm3347174qtp.81.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Oct 2019 21:12:09 -0700 (PDT)
From: Gyan Mishra <>
X-Google-Original-From: Gyan Mishra <>
Content-Type: multipart/alternative; boundary=Apple-Mail-EFF0251B-DEC5-4F32-B5EA-1D4F83F0D8B6
Mime-Version: 1.0 (1.0)
Subject: Re: Rtg-bfd Digest, Vol 164, Issue 24
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <5DA894E5016C07A400390638_0_53266@msllnjpmsgsv06>
Date: Fri, 18 Oct 2019 00:12:09 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <5DA894E5016C07A400390638_0_53266@msllnjpmsgsv06>
To: Albert Fu <>
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, 18 Oct 2019 04:12:14 -0000

Sent from my iPhone

> On Oct 17, 2019, at 12:20 PM, Albert Fu (BLOOMBERG/ 120 PARK) <> wrote:
> 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
[Gyan] In all the use cases to date working with customer networks my experience has always been for single hop BFD using echo or asynchronous mode used for direct eBGP or ospf or isis p2p links.  I agree my thoughts were that this would be a good tool to help where traditional pmtud may have failed but for the network planner have an idea if IPv6 or any other technology that had a lot of overhead or is built on overlay /underlay technologies.  The only use case for multi hop BFD demand mode is for MVPN P2MP LSP LMDT which is a different animal all together.