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

Jeffrey Haas <> Tue, 10 September 2019 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C75B6120074 for <>; Tue, 10 Sep 2019 10:38:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PdPSKkJQimtu for <>; Tue, 10 Sep 2019 10:38:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1CF5C120041 for <>; Tue, 10 Sep 2019 10:38:55 -0700 (PDT)
Received: by (Postfix, from userid 1001) id BA0561E2F3; Tue, 10 Sep 2019 13:41:35 -0400 (EDT)
Date: Tue, 10 Sep 2019 13:41:35 -0400
From: Jeffrey Haas <>
To: Robert Raszuk <>
Cc: "Mercia Zheng (merciaz)" <>, "" <>, Susan Hares <>
Message-ID: <>
References: <003701d561b8$84171680$8c454380$> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 17:38:58 -0000


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 TCP
> 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

-- Jeff