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

["Jakob Heitz (jheitz)" <[e-mail]>]

   This phenomena is
   theorised to have contributed to IP traffic backholing events in
   global Internet routing system [l3outage]

Please remove the above statement.
Baseless accusations are not appropriate in a standards track RFC.

I propose to add this text:

It is possible that a BGP speaker presents a TCP zero receive window
after receiving a large batch of updates. Resetting the session to
such a speaker may just repeat the large batch, whereas waiting a little
longer may have given it a chance to recover. The possibility of this
occurrence makes it difficult to determine a good value for the
timer. The default value of the timer is therefore recommended
to be 15 minutes.


Regards,
Jakob.

-----Original Message-----
From: Idr <[e-mail]> On Behalf Of Ben Cox
Sent: Tuesday, April 20, 2021 6:48 AM
To: [e-mail]
Subject: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested

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