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

[Brian Dickson <[e-mail]>]

On Wed, Dec 16, 2020 at 10:51 AM Jakob Heitz (jheitz) <jheitz=
[e-mail]> wrote:

> The restarting speaker in this case did not actually restart.
> It just restarted this one session. There is no reason for it
> to delete any forwarding state. There is no evidence of any
> problem with its received routes, only with the routes it sent
> to the stuck peer. It may still set the (F) bit to force the
> stuck peer to WITHDRAW.
>

The transitive nature of bgp pretty much requires the safest choice should
be taken.

Which is to say, there is EVERY reason to delete forwarding state.
If a peer's router is so messed up that it is not accepting any TCP
packets, the only safe assumption is that the problem is AS-wide for that
peer.
In which case, the only data point available (the TCP session) indicates
the problem is very likely affecting other routing announcements towards
that ASN.
And the only SAFE behavior is to tear down the session completely,
including removing received routes from the IN-RIB, update the RIB and FIB,
and go on with life.

The incident that I believe lead to this proposal was super nasty, and only
a fix like this could handle that.
There is no reason to believe this can't/won't happen again in future.
As Jared notes, there are likely other implementations that would fare as
poorly if they encountered the triggering situation.

While this is my opinion on the best way to handle it, the underlying facts
aren't arguable.
An AS-wide situation (stuck receivers with no TCP progress) would never
result in the AS sending withdrawals.
The current handling of that is demonstrably broken.
The assumption that the BGP state machine can be fully relied upon is no
longer sound.

It probably never was a completely safe assumption.
IFF the state machine is working correctly, this corner case would never
occur.
It has occured and can occur, ergo it needs to be handled outside of the
state machine proper.

Brian