Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

[Job Snijders <[e-mail]>]

On Wed, Dec 16, 2020 at 08:53:25PM +0100, Robert Raszuk wrote:
> I think your observations may not always apply.
> 
> Imagine you are peering with a stub customer and he is only getting default
> route from you while advertising few routes to your ASN.

The stub customer still is not be receiving KEEPALIVEs, the stub has no
idea should you want to announce routes in addition to the default
route, or withdraw the default route (for some type of maintenance). All
these important BGP messages simply never make it to the stuck peer.

Flapping the session increases chances of recovery, or at least draws
operator attention.

> At min make before break (new session should be established - if
> possible) before killing the old one.

What if new session can't establish? The old session still is stuck and
most likely hurting the users of the network. As stated before in the
thread: this 'stuck' situation does *not* appear under normal
circumstances, many BGP sessions have been inspected. We now know of
multiple situations where automatic disconnection of 'stuck' peers would
have helped improve global routing.

A consession: vendors are free to make it possible to disable the new
improved behavior. If an operator knows of a deployment scenario where
after exchanging the OPEN & sending a single UPDATE (that default route)
no further bi-directional communication is required, sure. However, I'd
probably recommend considering RIP instead of BGP at that point ;-)

Kind regards,

Job

ps. No snark intended: I appreciate the working group looking at each
and every corner case. I understand it is quite unusual for someone to
point at the BGP-4 FSM and say 'I think we are hurting here', decades
into the deployment.