Re: [Idr] Fwd: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt

[Robert Raszuk <[e-mail]>]

Hi Thomas,

> I am sure it is useful in some cases and can prevent devices from missing
keep-alive timers

Well let's keep in mind that we are talking about the peer which careless
about our keepalives to start with. In spite of not getting neither UPDATE
MESSAGES nor KEEPALIVE MESSAGES it keeps the session.

> I would rather have a way to get my router configured to detect a peer
not processing updates
> in a timely removed from the path than leaving them in, potentially
keeping stale routes longer
> than required (or worse, causing loops).

By all means I think we all agree with that.

The only topic of the discussion is if this should be done at TCP vs BGP
level.

IMHO TCP can detect much better stuck peers (both if TCP probes are still
flowing or not flowing). Naturally TCP should inform BGP about such peers
and drop the stuck sessions. This is exactly what we are suggesting in
respect to adding user timeout when you are OPEN socket as a param.

Thx a lot,
R.



On Mon, Aug 15, 2022 at 5:54 PM Thomas Mangin <
[e-mail]> wrote:

> Hi,
>
>
>> Zero windows is a way for TCP to apply back pressure to a peer.
>>
>
> Correct. It puts the pressure on memory (and CPU) to the sender which
> needs to keep its outgoing update queue larger than it should as
> the receiver can not process them fast enough.
>
> I am sure it is useful in some cases and can prevent devices from missing
> keep-alive timers but when it is used to keep undersized routers in
> production at the cost of propagation delays, it is really a nasty trick.
>
> It allows a router upgrade cost problem to be passed to an EBGP peer, so I
> can see why some may like the feature 😜 (even more so if the feature can
> be set up on a per peer basis).
>
> I would rather have a way to get my router configured to detect a peer not
> processing updates in a timely removed from the path than leaving them in,
> potentially keeping stale routes longer than required (or worse, causing
> loops).
>
> Therefore I see any work toward the detection of a router unable to
> process updates in a timely manner is a step in the right direction.
>
> Thomas
>
>