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

Hi Job,

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

So motivated by you bringing the implementation topic I took a look at the
FRR diff David committed  ..

https://github.com/FRRouting/frr/commit/bd9fb6f368049bd5f1f6a2b7bc97fbd51c9300cc

The first problem is that it does not have much to do with either this
discussion or your draft.

What is implemented is timeout from the moment of full buffer not when peer
stopped receiving any TCP data from us (and stopped sending acks for the
data).

As I already provided evidence to fill the buffer with keepalives may take
hours.

Moreover when the buffer is actually getting drained with peer
accepting keepalives, but we have large UPDATE which still for a long time
do not fit the remaining space of the buffer the session will be
unnecessarily dropped. That's actually pretty harmful.

The timeout of 2 * holdtime is way too aggressive too - some folks set
holdtime to 9 sec if there is no BFD running.

Now if you are saying other implementations are "in-line with each other"
then this is worrying.

Thx,
R.

On Fri, Aug 19, 2022 at 11:24 AM Job Snijders <job=
40fastly.com@dmarc.ietf.org> wrote:

> 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 <jhaas@pfrc.org> wrote:
>
>>
>>
>> > On Aug 17, 2022, at 6:48 AM, tom petch <ietfc@btconnect.com> wrote:
>> >
>> > From: Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk <
>> robert@raszuk.net>
>> > 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
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>