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

[Ben Maddison <[e-mail]>]

Hi all,

On 03/22, Susan Hares wrote:
> This begins a 3-week WG LC for draft-ietf-idr-bgp-sendholdtimer (3/23/2024 to 4/12/2024).
>  https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-sendholdtimer/
> 
> The authors should reply to this message indicating if they know of any IPR relating to this draft.
> 
> This draft modifies RFC4271's finite state machine.  Please review it carefully.

I am pleased to see this document progressing, as it addresses an
important issue in real world routing operations.

I support the approach, and would like to see it published as an RFC,
modulo the following comments.

I have read the current draft, and had several suggestions, including
clarifying the relationship between the values of KeepaliveTime and
SendHoldTime, which I have provided to the authors in [0].

The only remaining issue, which I believe warrants further discussion in
the WG, is the guidance that BGP speakers should send a NOTIFICATION in
response to the SendHoldTimer_Expires event.

Although I appreciate that for the purposes of internal consistency it
is desirable that the FSM mandates a consistent set of steps to take
when tearing down a session, I think in this case it results in further
contradiction.

Consider the possible outcomes for an implementation responding to a
SendHoldTimer_Expires event by sending a NOTIFICATION to its peer, as
written currently. Either:

1. The local speaker waits indefinitely for confirmation that the
   message has been sent on the socket, delaying the closure of the TCP
   connection, and defeating the objective of the timer entirely; or

2. The local speaker successfully sends the message to its peer, and
   finds itself in the contradictory position of having successfully
   sent a message to the peer, whilst handling a condition that has
   arisen due to its supposed inability to do exactly that!

I believe that the intention here is that the local speaker performs its
internal bookkeeping and event logging using the "Send Hold Timer
Expired" error code, but only attempts to send the NOTIFICATION to its
peer if it can do so without blocking the remainder of the session
clean-up.

Similarly, it seems unnecessary and confusing to restart the timer when
a NOTIFICATION is sent.

I have attempted some wording changes to address this, and submitted
them for review in [1]. I would be glad to hear the thoughts of
participants that are more practised in FSM surgery on this.

Cheers,

Ben

[0]: https://github.com/bgp/draft-ietf-idr-bgp-sendholdtimer/pull/2
[1]: https://github.com/bgp/draft-ietf-idr-bgp-sendholdtimer/pull/4