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

[Adam Chappell <[e-mail]>]

Hi Ben, I think you have a good draft here, but personally I think
this probably should be a simple advisory to implementors, eg. an
implementation MAY want to consider terminating sessions to peers with
whom they've been unable to write() to for a configurable amount of
time, maybe similar to Job's original change of wording[1] to sec6.5.
Leaves the door open for "profiles" as some have said eg.
"timeliness", "longevity" etc...

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. Same viz a viz so-called update-groups and dynamic
definition of same.

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. I realise it may be bad form to associate names of
operators and vendors with bad events, but I think it is important
that we investigate exceptional events so that policy and protocol
changes like this have a sound basis.

[1] https://mailarchive.ietf.org/arch/msg/idr/L9nWFBpW0Tci0c9DGfMoqC1j_sA/
[2] https://blog.benjojo.co.uk/post/bgp-stuck-routes-tcp-zero-window

On Tue, 20 Apr 2021 at 15:53, Ben Cox
<ben=[e-mail]> wrote:
>
> Hi IDR folk,
>
> In response to previous discussion over BGP protocol interactions with
> TCP Zero Windows
> (https://mailarchive.ietf.org/arch/msg/idr/L9nWFBpW0Tci0c9DGfMoqC1j_sA/)
> me (who is new to the IETF, so please forgive me for my inevitable
> errors) and Job Snijders have decided to attempt to address this and
> focus discussion on handling this case with a internet draft, the gist
> of it in the abstract of the draft so I won't re-word it here :)
>
> --
>    This document defines the SendHoldTimer session attribute for the
>    Border Gateway Protocol (BGP) Finite State Machine (FSM).  A session
>    should be terminated if the TCP receive window is zero for the
>    duration of the Send Hold Timer, in this situation the peer is
>    expected to terminate the connection.  For robustness, this document
>    specifies that the local system should also close the connection.
>    This document updates RFC4271.
> --
>
> We submitted our first draft today (
> https://datatracker.ietf.org/doc/draft-spaghetti-idr-bgp-sendholdtimer/
> ) and we are looking for feedback knowing that it is not complete but
> is likely in a state for some discussion.
>
> Since this draft tweaks the BGP FSM, we would like to make sure that
> it's done correctly and so we are soliciting help from this working
> group.
>
> We already have a test BGP speaker that triggers some of these zero
> window edge cases. If that helps, please get in touch with us for the
> peering information.
>
> Looking forward to feedback!
> Ben
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr



-- 

-- Adam.