[Idr] Re: Shepherd's review of draft-ietf-idr-bgp-bfd-strict-mode-13.txt

[Robert Raszuk <[e-mail]>]

Hi Jeff,

Thx for the half of the presentation but I really was not asking for it.
Nor I was questioning the usefulness of using BGP + BFD and attempting to
document the standard/expected behaviour in BGP FSM.

I was pointing out that deployments using static + BFD to BGP peers exist
as well as IX+RS. IMO it could be useful to comment on those in this draft
too.

/* On the last one maybe draft-ietf-idr-rs-bfd-00 could be an alternate
place, but it looks a bit shelved */

A bit of discussion of using BFD for IBGP would also not hurt the document
:)

Thx,
Robert


On Mon, Jul 15, 2024 at 5:22 PM Jeffrey Haas <[e-mail]> wrote:

>
>
> On Jul 15, 2024, at 9:38 AM, Robert Raszuk <[e-mail]> wrote:
>
> Hi,
>
> The draft seems to be agnostic to the type of BGP session (IBGP vs EBGP).
> Is this the real intention to allow this mode of BFD operation on BGP
> session to be applicable to both types of BGP session ?
>
>
> The draft is applicable to single hop and multi-hop BFD.
>
>
> For EBGP in a lot of cases reachability to a peer is enabled with static
> route (example single EBGP with disable-connected-check over multiple
> links). When this is used quite often BFD is also already enabled for
> static routes. Is the intention here to duplicate it and run yet one more
> layer of BFD session ?
>
>
> No.
>
> From the Introduction:
> "The BFD interaction with BGP is specified in Section 10.2 of [RFC5882
> <https://www.rfc-editor.org/info/rfc5882>]. When BFD is enabled for a BGP
> neighbor, faults in the bidirectional forwarding detected by BFD result in
> BGP session termination. It is possible in some failure scenarios for the
> network to be in a state such that a BGP session may be established but a
> BFD session cannot be established. In some other scenarios, it may be
> possible to establish a BGP session, but a degraded or poor-quality link
> may result in the corresponding BFD session going up and down frequently."
>
> Multiple implementations of BGP using BFD would rely on BFD being Up at
> different points of the BGP FSM.  In some cases, this would result in
> interop issues including deadlock (primarily in the "holddown" modes) where
> one side is waiting for BGP to go to Established before starting BFD and
> the other side is waiting for BFD to go to Up before starting the BGP
> session.  In other situations, such as noted above, you'd end up with
> immediate flaps because BFD itself wasn't stable before BGP got involved.
> And in yet others, BFD was allowed to go Up well after BGP was Established,
> BFD would go immediately down and then take out whatever work was done.
>
> The fix for all of these issues is to be mutually rigorous as to when BFD
> sessions must be established vs. the BGP FSM.
>
> Note: You've just gotten about half of the IDR 120 presentation. :-)
>
> -- Jeff
>
>