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

[Jeffrey Haas <[e-mail]>]

> 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)