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

[Job Snijders <[e-mail]>]

Hi all,

I’ve added some bits where to restart the Send Hold Timer:
https://www.ietf.org/rfcdiff?url2=draft-spaghetti-idr-bgp-sendholdtimer-08.txt

I believe the suggested FSM update and the three known implementations are
in line with each other.

Further tuning (such as the notion of asynchronously started timers) can
happen as a Working Group document, including writing out a full copy of
the FSM description in an Appendix (as the “update this update that add
this” style of writing quickly becomes unwieldy).

Kind regards,

Job

On Wed, 17 Aug 2022 at 15:26, 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)
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>