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

[Jeffrey Haas <[e-mail]>]

Jakob,

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.

This tickles a related point:

If a peer has zero-windowed you, you are unable to send any ACK
frames to that peer.  This means that we're potentially in a very slow race
for the remote peer to eventually send enough data that it similarly zero-
windows.

At that point, the remote peer should eventually give up trying to transmit
as well. Locally, the hold timer would expire.

> Therefore, I would propose that the response of the local speaker
> should be to retain the routes of the stuck peer when it resets the
> session, GR style.

Having GR is a reasonable mitigation when you're not concerned about the
routes the local router having already been stuck for a very long time.

In some circumstances it may make better sense to get the router with the
misbehaving TCP session out of the forwarding path as possible.

-- Jeff