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

[Robert Raszuk <[e-mail]>]

Hi Jeff,

I agree with you that if we look at the BGP level it does make sense to
consider starting such timer after initial dump (as I mentioned in the
other note after receiving EOR marker).

But aren't you a bit worried that now BGP would need to handle lot's of TCP
internal events (errors) on a per peer basis ? Assume we are talking scale
here 5K+ peers.

Take your favourite code base - what events/errors would you expect to get
from TCP to start the timer. Now how do you know that perhaps peer drained
from TCP buffer just a bit (say 19 octets Keepalive) which should
effectively stop/reset the timer.

Now taking it a bit further - consider your BGP code to run on a few
different Operating Systems each with different TCP implementation. Now the
real fun starts when you have to adjust your BGP code to custom TCP
errors/events optimistically assuming that all would be capable to act
properly in this regard.

So with that, detecting really stuck sessions for a reasonably long time at
the TCP level IMHO seems a much better option.

Thx,
Robert


On Wed, Aug 17, 2022 at 3:25 PM Jeffrey Haas <[e-mail]> wrote:

>
>
> > On Aug 17, 2022, at 6:48 AM, tom petch <[e-mail]> wrote:
> >
> > From: Idr <[e-mail]> on behalf of Robert Raszuk <
> [e-mail]>
> > Sent: 15 August 2022 22:18
> >
> > https://mailarchive.ietf.org/arch/msg/idr/McRvkJ6UiNwJSKvGs0GPaqDfovA/
> >
> > #1 - IMO it would be a pretty bad idea to apply Send_Hold_Timer to a
> booting node. If at all this timer should fire only after receiving the
> <EOR> marker on the session.
> >
> > #2 - Authors of this draft target cases where a peer is stuck for
> "days/weeks" ... I am yet to see a BGP node taking that much to boot.
> >
> > <tp>
> > At a slight tangent, the I-D fails to state when the timer should be
> running, in which of the FSM states, which leaves much to the imagination.
> Since this is a function of TCP and not BGP, then it could be applicable as
> soon as there is a TCP connection and so apply to most state.
>
> This detail is one of the things that has me uneasy about blanketly
> applying the example feature Enke Chen highlighted from the Linux option.
>
> The challenge being faced is when BGP decides that the remote side is
> "taking too long".  Initial startup scenarios where the firehose of a RIB
> exchange are one of the places where a little forgiveness in timers may be
> reasonable.  This is especially true if you're looking at some sort of
> larger outage where every single device in a "region" may be trying to
> restart simultaneously.
>
> Relevant to your point, Tom, figuring out the exact touch point in the FSM
> to hook this is challenging enough.  If we permit an implementation to turn
> it on "later" at a point subjective to the implementation, the FSM isn't
> exactly good about that right now.  It'd become an asynchronously started
> timer.
>
> -- Jeff (still cursing Alex for the FSM)