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 11:26 AM Jakob Heitz (jheitz) <[e-mail]>
wrote:

> Brian,
>
>
>
> We went through this discussion when developing RFC 7606
> <https://tools.ietf.org/html/rfc7606>.
>
> What errors deserve what consequences?
>
> In implementations, we ended up making them all configurable.
>
> We can certainly make this one optional too.
>
>
>
The main thing is, even if it is configurable, it needs to have a sane
default. This is analogous to the requirement to have a configured routing
policy (any policy at all).
It should be, IMNSHO, extremely rare that anyone should want to do that
(make that override) given the global consequences of a stuck ASN.

Pretty much by definition, this is the stuff that normal control plane
stuff (including RFC 7606) could never handle per se.

A router which is slow handling updates would not trigger this issue.
It would only occur if it completely stopped working for UPDATE timer
duration.
At which point, it is arguable as to whether the routes it has are still
reasonable and legitimate.

It may be forwarding packets, but there is zero ability to guarantee it
isn't causing a routing loop.
It is quite likely that it would/could, which would further exacerbate any
problems the router is experiencing.

In which case, the result is likely better in 99.99% of potential
scenarios, to tear down the session.
I'd say 100% but someone may have a counter-example...

Brian


> Regards,
>
> Jakob.
>
>
>
> *From:* Brian Dickson <[e-mail]>
> *Sent:* Wednesday, December 16, 2020 11:18 AM
> *To:* Jakob Heitz (jheitz) <[e-mail]>
> *Cc:* Claudio Jeker <[e-mail]>; [e-mail]
> *Subject:* Re: [Idr] TCP & BGP: Some don't send terminate BGP when
> holdtimer expired, because TCP recv window is 0
>
>
>
>
>
>
>
> 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
>