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

[Robert Raszuk <[e-mail]>]

Jeff,

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.

Example:

   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,
R.


On Tue, Sep 10, 2019 at 7:38 PM Jeffrey Haas <[e-mail]> 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
> 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
>