Re: [Idr] WG Adoption call for draft-spaghetti-idr-bgp-sendholdtimer-09 (2/28/2023 to 3/14/2023)

[tom petch <[e-mail]>]

Top posting to re-iterate two queries  I have about this I-D.

When is the timer set running? 3.4 mentions UPDATE and KEEPALIVE; 3.2 implies it is for OPEN as well.  Is it for all occurrences of those three transmissions and no other?

What is the benefit of  Event XX2: MsgSent (which excludes OPEN)?
 It seems to me that it will happen in every state where a message is sent and causes no change of state so it is the equivalent of setting the timer running where a message is sent which I would find simpler and clearer if stated explicitly in the FSM.

Tom Petch

________________________________________
From: Idr <[e-mail]> on behalf of tom petch <[e-mail]>
Sent: 09 March 2023 12:10
To: Jeffrey Haas
Cc: Sue Hares; [e-mail]
Subject: Re: [Idr] WG Adoption call for draft-spaghetti-idr-bgp-sendholdtimer-09 (2/28/2023 to 3/14/2023)

From: Jeffrey Haas <[e-mail]>
Sent: 07 March 2023 22:36

Tom,

> On Mar 6, 2023, at 11:58 AM, tom petch <[e-mail]> wrote:
> <tp>
> I think that the authors of this I-D underestimate the work involved in updating the BGP FSM, probably by an order of magnitude.
>
> They specify a new event and give a list of actions to be performed when it happens.  This is inadequate.  As the present FSM shows, such a list is required for each and every state that the FSM can be in, so multiply that by at least six, In practice, several states have in effect substates depending on the configuration so it is more than just the six defined states.
>
> Further, the timer will be running or not running in every state transition  so that for every state transition in any state, it must be specified what happens to the timer, started, stopped and so on,  Given the number of state transitions, multiply that by fifty, or more.

I think I'm somewhat more optimistic than you are about the magnitude of surgery needed on the FSM.

For comparison purposes, I think the majority of the surgery will occur around the similar touch points for the HoldTimer.

<tp>
Well or ConnectRetryTimer; that gets reset when going to Idle state and I suspect that this timer will need similar resets at similar places if the FSM is going to be coherent. ConnectRetryTImer is an example as to how timers should be specified in an FSM, the number of places that an actin needs to be specified.

I went through the FSM in detail and got to 41 updates at which point I realised that the I-D is  unclear to me.  S.3.2 talks of updates to s.8.1.3 which is ok for the first five lines thereafter but then has text which has no place in that section.  Rather it is an incomplete update to s.8.2.2

The (SendHold)timer is described as applying to UPDATE and KEEPALIVE in s,3,3 and s.3.4 but the text in s.3.2 has the timer started after an OPEN, Connect state, event 12, which suggests that it is intended to apply to OPEN messages as well so why does this I-D specify it for some OPEN and not others?

I wonder if Event XX2 is an attempt to avoid some 20 updates to the FSM at the risk of confusing implementers.  That is, if the timer is started at an OPEN, then it should be started after a KEEPALIVE or UPDATE as well.  Event XX2 seems to be trying to avoid saying this, by creating an event which is then six updates to the FSM, instead of the timer being started in any state when a message is sent which is rather more updates to the FSM.

Event XX2 does seem a bit odd, not like any other event in this or other FSM  It  will happen in Connect state Event 20  DelayOpenTimer running with the transition to OpenConfirm state and logically Event XX2 will occur immediately in OpenConfirm.  Like I say this seems like a shortcut.  What the FSM should specify is to (re-)start the timer as part of any action when a message is sent regardless of the new state. which I think eliminates the need for Event XX2 and simplifies the FSM if not the updates thereto.

Those are my main two points of confusion but there are others.

Tom Petch
>
> As written, I think that this I-D will seriously damage RFC4271 rendering the FSM of limited value.

We're unfortunately rather aware that the FSM text, as written, doesn't tolerate surgery very well.  But similarly, we know that high level intent is fairly easy to specify and implementations largely do fine without every single corner case covered.

-- Jeff


_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr