Re: [Idr] WG LC for draft-ietf-idr-bgp-sendholdtimer-03 (3/23 to 4/12/2024)

[Ben Maddison <[e-mail]>]

Hi Jeff,

On 03/25, Jeffrey Haas wrote:
> 
> > On Mar 25, 2024, at 1:36 PM, Ben Maddison <[e-mail]> wrote:
> > 
> > I think the fundamental issue with the text (and other similar parts or
> > RFC 4271) is that sending the NOTIFICATION is mandatory, and must
> > (obviously) happen before the socket is closed, leading to the naive
> > interpretation that the send must complete before the remainder of the
> > actions can proceed.
> > 
> > Expecting future readers to read this as "oh, I should enqueue this to
> > my write-thread, drop the handle (or future, or whatever), and proceed
> > to kill the socket" is asking too much.
> 
> And thus you come to the crux of the issue.
> 
> Anywhere we say "send a notification" would be vulnerable to stalling
> if we treated it as "... and wait until it's actually put at least
> into TCP locally before closing the connection".  

Yes, that's exactly the conclusion I came to when I was looking at prior
art yesterday.

More generally, that risk is present wherever the FSM's state
transitions are dependent on external factors. I wonder whether we would
find other examples of that if we looked a little harder!

> It might be worth writing this case up as an errata, especially since
> there's discussion about taking BGP forward in the standards track.
> 
> However, I wouldn't recommend trying to special case the correctness
> of this in the sendholdtimer.  That's more ocean than you want to boil
> here.

I find that suggestion surprising. I would think this is an ideal
opportunity to get the language we want for this right.

SendHoldTimer is a natural special case in this respect, since this is
exactly the state we expect to be in when SendHoldTimer_Expires is
fired.

In fact, one could argue that by getting it right here, we fix the issue
for the rest of the FSM, since blocking on sending a NOTIFICATION
elsewhere (for long enough) will cause SendHoldTimer_Expires to fire
eventually.

Cheers,

Ben