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

[Robert Raszuk <[e-mail]>]

Gyan,


> As draft-spaghetti-idr-bgp-sendholdtimer is queued for adoption call, I
> don’t think we are all in consensus the TCP_USER_TIMEOUT as the best
> solution.
>

Let me ask if there is anything missing from the perspective of the
reported issue in its detection and bringing a stuck TCP session down by
using standard TCP mechanisms like TCP_USER_TIMEOUT ?

Note that TCP folks also agree that use of it is preferred and recommended.
Reason being that TCP layer can detect in a much better way such issues as
it does consider number of other TCP state data.

https://mailarchive.ietf.org/arch/msg/tcpm/8fMn-d3U8SfLJBmi4mn-X4lUu7Q/

Has the TCP_USER_TIMEOUT been tested with any implementations including any
> open BGP implementations.
>

I am not sure how to read this.

Are you questioning TCP specification and common implementations here ?

RFC 793 section 3.8
or
RFC5482 https://www.rfc-editor.org/rfc/rfc5482.html

Last - what role in the decision plays the presence or absence of any
feature in "*open* BGP implementations"?

Please also observe that testing this is not that easy. It first requires
broken BGP implementation and either instrumented BGP I/O to stop accepting
arriving messages or forced by TCP peer's zero-window. We are dancing here
around a very unlikely/marginal event to occur in practice.

Thx,
Robert.