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

[Jeffrey Haas <[e-mail]>]

Adam,

On Wed, Apr 28, 2021 at 01:01:34PM +0200, Adam Chappell wrote:
> It is significant to me that at least two production implementations
> I've seen offer visible CLI instrumentation when keepalives haven't
> been written on schedule, so it seems that implementors are definitely
> aware of the weakness, even if not acting on the situation today and
> could do.

For scaled systems, scheduler slips for timers can be a serious challenge.
This is even without the headache of whether your network stack will
actually manage to get the scheduled packet to the remote device on time.

> I read your compelling blog post[2] and investigations but I have
> missed the conclusive link between the phenomenon of zombies
> (undisputed) and TCP sessions regularly stalled in this way. I
> understand that you can synthesise the problem by creating a BGP
> speaker that starves his peer of the oxygen to talk thus polluting
> your own RIB; but I missed the pointer to evidence that it is indeed
> this that is generally occurring and causing zombies. Not disputing
> that it may be.

"Stuck route" or "missing route/withdraw" bugs of various sorts are an
indisputable fact of prior and sometimes current BGP implementations.

Some of the circumstances described in this thread are, as you had noted,
perhaps not the issue itself but a visible manifestation of the issue.  An
implementation can't tell when it sees zero-windowing whether there's a TCP
issue, a starving reader on the remote side, or related problems.  It simply
knows that it can't push routing state that it wants to.

Prior and ongoing discussions about BGP troubleshooting (see for example the
thread in grow about the BGP Looking Glass Capability) can be partially
informed by these discussions.  This form of congestion means that an
in-band solution to such troubleshooting is problematic for some scenarios.

-- Jeff