Re: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested

[Jeffrey Haas <[e-mail]>]

On Sun, Apr 25, 2021 at 06:01:06AM +0000, Jakob Heitz (jheitz) wrote:
> A long time of TCP zero window does not indicate a data plane
> problem, nor a problem with routes received from the stuck peer.
> The blockage is in one direction only. The local speaker is unable
> to end routes to the stuck peer, but is able to receive routes
> from the stuck peer just fine.

A further bit of thinking for the problem:

While it's true that the blockage is one way, it's not necessarily
guaranteed that you're getting routes from the peer.  This is true even if
you might be receiving keepalives.

The example case would be a BGP that had a decoupled keepalive mechanism for
its FSM.  The implementation may not be draining its incoming rib-in from a
socket, and similarly may be stuck in publishing its rib-out.

Of course, there's no way to tell if this is happening.

This isn't a strong argument that Graceful Restart proecures may not still
be appropriate.  After all, we have some portion of a rib that may be
correct.  However, there's perhaps an argument that that it might be less in
sync in some circumstances than others.

-- Jeff