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

[Robert Raszuk <[e-mail]>]

Ben at all,

So we are trying to drop a session towards the BGP peer who does not
respect basic RFC4271 obligation to drop the session when HOLD TIMER
expires. That to me is already marginal (read noise corner case).

Then we worry that LINUX TCP stack may have buggy implementation of
TCP_USER_TIMEOUT and instead of fixing it locally we dismiss this option.

Isn't this going a bit too far ? If the problem is real why don't we solve
it in a more elegant and broader way (broader in a sense to detect more
issues) by defining a new BGP Message - BGP PING Message. Sort of BGP level
heartbeat.

Difference from KEEPALIVE messages would be that apparently implementations
and RFC4271 decouple completely KEEPALIVE receiving from KEEPALIVE MSG and
tightening them may be a bad idea.

Long run we could use BGP PING and BFD and retire KEEPALIVEs.

So here it would allow us to go up to the BGP stack to make sure both sides
process BGP messages and respond to them. Would it solve all problems with
BGP consistency - no. But it does allow us to discover more issues between
point to point peers.

It could run slow enough ... say every 60 sec, negotiated by capability.
PING HoldTime of 180 sec could trigger session RST.

I shared this offline with some IDR WG members .. now just sharing with you
all ... It is still different from BGP OPERATIONAL MESSAGE that if we think
the issue of a stuck/buggy BGP peer is real perhaps could deserve a small
draft to document it.

Just a thought ...

Many thx,
Robert

On Thu, Aug 4, 2022 at 4:07 PM Ben Cox <ben=[e-mail]>
wrote:

> One question with TCP_USER_TIMEOUT (I've yet to test it) but if we
> want to emit syslog/SNMP messages when it triggers, is there a way to
> get out of the kernel that the reason for a socket closing was
> TCP_USER_TIMEOUT and not something else?
>
> Someone also mentioned in passing that TCP_USER_TIMEOUT in Linux was
> buggy/broken until relatively recently, assuming that is the case,
> that might be a good argument alone against going that route since the
> a number of vendors using older kernels could risk someone thinking they
> have implemented the feature but instead their kernel has
> silently/loudly broken it.
>
> On Wed, Aug 3, 2022 at 8:29 PM Enke Chen <[e-mail]>
> wrote:
> >
> > > if this is just queued keepalives (no BGP churn) then depending on the
> buffer size it may take ages to fill ..
> >
> > Indeed, in that case the local BGP speaker may not know about the
> > condition (mis-behaving remote speaker / 0-window) for a long time,
> > and that's not covered by the current draft, nor the FRR BGP patch
> > based on my reading.
> >
> > To make it complete, I believe that the detection and handling of a
> > stuck peer (i.e., "data not being transmitted") should be at the
> > transport layer.  The TCP_USER_TIMEOUT option is readily available for
> > that purpose:
> >
> > https://man7.org/linux/man-pages/man7/tcp.7.html
> >
> > TCP_USER_TIMEOUT (since Linux 2.6.37)
> >               This option takes an unsigned int as an argument.  When
> >               the value is greater than 0, it specifies the maximum
> >               amount of time in milliseconds that transmitted data may
> >               remain unacknowledged, or bufferred data may remain
> >               untransmitted (due to zero window size) before TCP will
> >               forcibly close the corresponding connection and return
> >               ETIMEDOUT to the application.  If the option value is
> >               specified as 0, TCP will use the system default.
> >
> > Thanks.  -- Enke
> >
> > On Wed, Aug 3, 2022 at 2:43 AM Robert Raszuk <[e-mail]> wrote:
> > >>
> > >> Even if the remote (stuck) peer does not process the FIN, the local
> > >> end will close the session and stop forwarding traffic that direction.
> > >> That is an improvement, from an operator's PoV, both for forwarding
> > >> errors and local resources.
> > >
> > >
> > > Would not the same happen when you will send keepalives *ONLY* upon
> receiving them from a peer.
> > >
> > > If both sides support it there should be no issue of stuck sessions.
> Also no new timer needed and could be knob to enable/disable it.
> > >
> > > This draft assumes that one peer is bad and the other should time out
> when it can not send. So I am asking what exactly is the trigger to fire
> that timer when BGP can not write to a TCP socket ? Is it Error 105: No
> buffer space available ? Something else ?
> > >
> > > If this is just queued keepalives (no BGP churn) then depending on the
> buffer size it may take ages to fill ...
> > >
> > > Best,
> > > R.
> > >
> > > _______________________________________________
> > > Idr mailing list
> > > [e-mail]
> > >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!Mt_FR42WkD9csi9Y!a0z_mWIoJi3AkiI16RqyCvoRCWwEOL3bWCHM4NpDMSNuDupNtnpKp-7CS11XhqcJqXRdfdf7CvdIHDMJt49KTA$
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>