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,

> But that said, protecting iBGP when it's not directly connected also
> happens.  It has a range of caveats.
>
> IMO, it's unwise to unnecessarily restrict when strict mode gets used.  If
> you're choosing to use BFD, you'll need this mechanism for interop.

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.

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.

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.

Many thx,
R.









On Tue, Sep 10, 2019 at 6:57 PM Jeffrey Haas <[e-mail]> wrote:

> Robert,
>
> On Mon, Sep 09, 2019 at 11:43:34PM +0200, Robert Raszuk wrote:
> > While someone could run iBGP in a p2p mode as DC reachability protocol
> that
> > is rather an exception then a rule.
>
> Directly connected iBGP happens.
>
> > Concluding - I think it would be pretty safe to state that draft applies
> > only to point-to-point BGP sessions.
>
> But that said, protecting iBGP when it's not directly connected also
> happens.  It has a range of caveats.
>
> IMO, it's unwise to unnecessarily restrict when strict mode gets used.  If
> you're choosing to use BFD, you'll need this mechanism for interop.
>
> -- Jeff
>