Re: FSM changes for the Draft-15

[Alex Zinin <[e-mail]>]

Jeff,

> Traditionally (and my biggest argument to do it this way), we
> should document the states (noting the start state),
> the transition function and make sure that its deterministic.
> By that I mean that "do nothing/ignore" is simply a transition to
> the same state.

Agree with the last statement about "ignore" (I hope my suggestion
did not sound contrary). Regarding the rest of the para above, it wasn't
clear to me whether you were against documenting the events.

> Additionally, I don't think anything as documented have any "in actions".
> Do you disagree?

Depends on how you look at it. The idea behind in-actionc is to
identify those performed regardless of the prev state, event
and other conditions. For example, (reading Sue's new version
of the text), we always do the following when going to Connect:

 - start ConnectRetry timer
 - initiate transport connection to the peer
 - listen for an incoming one
 
I think I could identify similar sets for Idle and IdleHold.

> Documenting "state actions" would be a nice thing, but potentially
> dangerous.  For example, it would be nice to document what happens
> in the magic box marked "Established" but that goes beyond what
> most people want to see - i.e. events on the wire.

It is dangerous if we try to document everything (e.g., update
processing), which is not necessary. Only things related to
the FSM operation should be mentioned, for example, generation
of the timer expiration events. Another approach would be
to describe the timer itself and say it generates event Foo.
FSM action description would give a clue on how Foo is processed
in different states.

> A good argument to avoid documenting the black boxes is the
> extension mess we'd get into by trying to extend the contents of
> those boxes for all BGP extensions such as route refresh, graceful
> restart, etc.  By focusing on some basic internal events that are
> required to get a pair of bgp speakers peering and then focusing
> on events to keep that peering up we avoid limiting implementations
> by over-specifying the internals.

Don't get me wrong. I'm not suggesting to transform the whole
BGP spec to an FSM description (which would be unrealistic, btw).
My point is---since we're touching the FSM part, let's
try to improve the description to be more FSM-like.

Alex.