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

[heasley <[e-mail]>]

Mon, Aug 15, 2022 at 06:03:21PM +0200, Robert Raszuk:
> > 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.

Robert, man, it has already been described that how you are trying to
characterize the stuck peer's handling of received keepalives is simply
not the case.

> > 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.

submit your draft.

if you want to measure timliness of processing updates, that has to be
done in bgp with some kind of acknowledgement (of actual processing, not
dequeuing from the socket) message type that does not exist today.