Re: [Idr] WG adoption call for draft-merciaz-idr-bgp-bfd-strict-mode-02.txt (9/2 to 9/17/2019)

Robert Raszuk <> Tue, 10 September 2019 18:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1C801201EA for <>; Tue, 10 Sep 2019 11:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 U61vk3-VyeCS for <>; Tue, 10 Sep 2019 11:46:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 086D41201B7 for <>; Tue, 10 Sep 2019 11:46:33 -0700 (PDT)
Received: by with SMTP id v11so21935945qto.13 for <>; Tue, 10 Sep 2019 11:46:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hkPGD8V8SBejSYa6BiU7b2dpiPmWMLz5WbtgyAuZTFU=; b=X3wkstUbVuolkxYnZxS/KDnebkypFMz+1EHpnjSt7H83FssAKpgK/YbPag1Eng4x7Y uZoRm7aHgoMaGmQZntzHsoH+glbIT+LxzPj0U4fZZTVD/R4GFjAqiOYMApZ5YO9jSX9t /hM3wdk94j7PEk8Qc7ekEcujm6cal+7/WQAUoNU96Z0Oywa56rKmnQNvKafIwBF/J83U ya1DYDEqfcJFKbfAgZvYQ87LeAp7Q0dAbzaMMOZqcu7v5rRq+g3hBUTPq1QHqoWr3cWE 4X8u72jZXZa49nHQs2v4HfNPmGv3/RCtHidOGeznNob8N0Gl9XBawQka7efYP5IsUn/R PBDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hkPGD8V8SBejSYa6BiU7b2dpiPmWMLz5WbtgyAuZTFU=; b=SBNyOOFNg6wmYPQVa8gJJ4epMzn8SLQyWBxyYCltLqL5IM6h1+K/lC5JZslslNt3y+ HijiPtISAyTpx7FrPkmZVgGFa3HgkDQ1/sGOnJ0mY0FDyc8Bn8jblOcEmC7aDwFbat0Q HThgi6OMAVABw2itDMd7+cu0yAJQkFTL5bhR1UUxM/DpCHNsPenOsFCVCEjTcveCsDE5 wPkzLKZ9sAcUWlucI2ayDedvgvpcIE67WqVWDno5n8LiqNq38kgnwKity2dMuMoRfjAh eYX0KLfdvT99Bjos9lMtVNsBxQCtuBJX+Lu36Zxj3REEpOoviqx8lq3tJjHceHhexg79 wtfA==
X-Gm-Message-State: APjAAAUcDzSaSfw8Nm0FUPKe6bnZh96VJ3/zTRykNl5qQEENrFbQLEce rYMOEVIVSWDqs26VN/lhPAYJ9p4ESDgHfklt52uXlQ==
X-Google-Smtp-Source: APXvYqylKFQ0DvFi6jzbdNgMq8NuoiHtkL3yRMgIVwrU5PamD1n/rai/P6wfrZTd9m0oOL3rHzVIanJsZrmo3gL2oCw=
X-Received: by 2002:ac8:7959:: with SMTP id r25mr30911703qtt.208.1568141191987; Tue, 10 Sep 2019 11:46:31 -0700 (PDT)
MIME-Version: 1.0
References: <003701d561b8$84171680$8c454380$> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Tue, 10 Sep 2019 20:46:22 +0200
Message-ID: <>
To: Jeffrey Haas <>
Cc: "Mercia Zheng (merciaz)" <>, "" <>, Susan Hares <>
Content-Type: multipart/alternative; boundary="000000000000b4e505059237526d"
Archived-At: <>
Subject: Re: [Idr] WG adoption call for draft-merciaz-idr-bgp-bfd-strict-mode-02.txt (9/2 to 9/17/2019)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Sep 2019 18:46:35 -0000


The draft makes it very clear in number of sentences that BGP session state
now will depend on BFD. In case of multihop (typical case for say IBGP to
RRs) this can not be accomplished by two different independent flows.


   To avoid situations which result in routing churn and to minimize the
   impact of network interruptions, it will be beneficial to disallow
   BGP to establish a session until BFD session is successfully
   established and has stabilized.

If you really want to make it work for IBGP (other then corner p2p use
cases) you need to encap both BFD and BGP into UDP/IP header and treat as
one flow. I don't see any issue with that. Otherwise it will likely only
create either false positives or false alarms.

And last bringing down the BGP session to RRs just because BFD in strict
mode on that session got a hiccup serves no good. The 180 sec long
keepalives are there for good reasons especially when RRs are not in the
data plane path. The paths they advertised may be completely healthy and
clients may reach each other just fine when say control plane of x86 where
you had your virtual RR reloads and to bring it up takes say 60 sec.

To detect remote next hop liveness you have different mechanisms in place.

Many thx,

On Tue, Sep 10, 2019 at 7:38 PM Jeffrey Haas <> wrote:

> Robert,
> On Tue, Sep 10, 2019 at 07:13:44PM +0200, Robert Raszuk wrote:
> > The fact that someone may enable BFD on IBGP how unwise it can be we can
> > not help.
> >
> > But see this solution one of the main benefits is to give green light to
> > BGP OPEN when BFD between said multihop endpoints get's established.
> Not in the current definition of the feature.  The only thing signaled is
> where in the BGP state machine the BFD session needs to be established
> before the FSM may advance.
> In the absence of the capability, or the S-bit set to zero (I recognize
> Enke's point that the bit is redundant), sessions will fall back to prior
> BFD behaviors.
> > But just please imagine that we are talking about WAN where there is a
> lot
> > of ECMP paths (across nodes or across links). What makes you even
> remotely
> > think that the actual path BFD packet take will be the same as the path
> > OPEN to 179 is going to take ? Last time I checked hashes are very random
> > for a good reasons.
> Or even over external paths.  It may be a LAG, e.g.
> > So I am not talking about some fancy purity ... I am talking about basic
> > functionality which this draft is stating to provide and which can not be
> > met over other then p2p links/sessions.
> I recognize the point you're trying to make.  This draft does not address
> when BFD may or may not be used - only how to make BFD coming up
> interoperable.
> -- Jeff