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

[Jeffrey Haas <[e-mail]>]

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.  

> 
> 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