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

[Jeffrey Haas <[e-mail]>]

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 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
interoperable.

-- Jeff