Re: FSM changes for the Draft-15

[Jeffrey Haas <[e-mail]>]

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.

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

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.

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.

On Fri, Nov 09, 2001 at 01:56:29PM -0800, Alex Zinin wrote:
> 8.2 BGP Session States
> 
> For each state, give a generic description, something like
> the following:
> 
>  State       : <state-name>
>  Description : <short description>
>  Valid events: <list of events expected and processed in this state,
>                 others should be ignored>
>  In actions  : <list of actions _always_ performed when
>                 transitioning to the state>
>  Out actions : <list of actions _always_ performed when
>                 transitioning from the state>
>  State actions: <list of actions performed (e.g. periodically) while
>                 in this state>
>                 
> 8.3 BGP FSM Definition
> 
>  FSM State : <one or many states>
>  FSM Event : <one or many events>
>  Next state: <new state if always the same>
>  Actions   : <list of state/event-specific actions and state
>               transitions if condition-dependent>
> 
> I'll take a look at the files you sent as well.
> 
> Alex.
> 
> 
> 

-- 
Jeff Haas 
NextHop Technologies