Re: FSM changes for the Draft-15

[Susan Hares <[e-mail]>]

Eric:


>Why do you distinguish manual and automatic start?  I do not believe
>that the BGP implementation will be able to distinguish the two types,
>so why assert an artificial distinction?  Or, are you referring to expiry
>of the IdleHoldTimer as an automatic start?

The original text below distinguishes between these two types.
The automatic restart is set in many implementations to keep trying to
connect to the remote user.   A CLI command or an SNMP mib variable
could also do this action.

Idle Hold timer is the time indicated in the *** section.  An automatic
start is also described below.


Text start:
============
          If a BGP speaker detects an error, it shuts down the connection
          and changes its state to Idle. Getting out of the Idle state
          requires generation of the Start event.  If such an event is
          generated automatically, then persistent BGP errors may result
          in persistent flapping of the speaker.
*****
         To avoid such a
          condition it is recommended that Start events should not be
          generated immediately for a peer that was previously
          transitioned to Idle due to an error. For a peer that was
          previously transitioned to Idle due to an error, the time
          between consecutive generation of Start events, if such events
          are generated automatically, shall exponentially increase. The
          value of the initial timer shall be 60 seconds.
***
         The time shall
          be doubled for each consecutive retry. An implementation MAY
          impose a configurable upper bound on that time. Once the upper
          bound is reached, the speaker shall no longer automatically
          generate the Start event for the peer.

------------------

>The Active and Connect states seem to be begging for a connection
>collision.  There is no arbitration process described below in handling
>an Open message when in Open sent - it just drops the connection.  I
>think it might be reasonable for the implementation to determine at
>that point which peer should be establishing the connection and drop
>it only if the local peer is not the one that should be making it.
>
>Additional comments in-line with abridged text below...


Can you give an example for each state: Active and Connect on how connection
collission could occur?


> >
> >
> > ----------------------
> > Idle state:
> >
> > Initially BGP is in the Idle state.
> >
> > A manual start event is a start event initiated by an operator.  An
> > automatic start event is a start event generated by the system.
>
>A possibly irrelevant observation.  :-)
>
> >
> >
> > [...]
> >
> > Upon entering the Idle Hold state, if the IdleHoldTimer exceeds the local
> > limit the "Keep Idle" flag is set.
>
>When you say 'IdleHoldTimer exceeds the local limit' do you mean
>the elapsed time, or the timeout value of the IdleHoldTimer?

See the earlier text.   The Local limit is a configuration variable set by the
local system (aka the user).


> >
> >
> > Upon receiving a Manual start, the local system:
> > -       clears the IdleHoldtimer,
>
>Do you mean 'resets the IdleHoldTimer', or 'stops the IdleHoldTimer'?

clears - sets to zero and stops.

> >
> > -       clears "keep Idle" flag
> > -       initializes all BGP resources,
> > -       starts the ConnectRetry timer,
> > -       initiates a transport connection to the other BGP peer,
> > -       listens for a connection that may be initiated by the remote
> > BGPPeer, and
> > -       changes its state to connect.
> >
> > Upon receiving a IdleHoldtimer expired event, the local system checks to
> > see that the Keep Idle flag is set.  If the Keep Idle flag is set, the
> > system stays in the "Idle Hold" state.
> > If the Keep Idle flag is not set, the local system:
> > -       clears the IdleHoldtimer,
> > -       and transitions the state to Idle.
> >
> > Getting out of the IdleHoldstate requires either operator intervention via
> > a manual start or the IdleHoldtimer to expire with the "Keep Idle" flag to
> > be clear.
>
>Is this what you mean by an automatic start?  If so, what constitutes
>generating a 'Start event'?


Code in BGP automatically tries to reconnect every "n" seconds.   This is an
automatic start event.   A manual start event is when the operator goes to
the terminal and says "connect now"!!!

> >
> >
> > [...]
> >
> > Active State:
> >
> > In this state BGP is trying to acquire a peer by listening for and
> > accepting a transport protocol connection.
> >
> > If the transport connection succeeds, the local system:
> > -       clears the ConnectRetry timer,
>
>'Stops the ConnectRetry timer'?

Stops and sets to zero.   (We can go to stops and sets to zero.)

> >
> > [...]
> >
> > Open Sent:
> >
> > In this state BGP waits for an Open Message from its peer.  When an OPEN
> > message is received, all fields are check for correctness.  If the BGP
> > message header checking or OPEN message check detects an error (see Section
> > 6.2), or a connection collision (see Section 6.8) the local system:
> > -       sends a NOTIFICATION message
> > -       IdleHoldtimer = 2**(ConnectRetryCnt)*60
> > -       Increment ConnectRetryCnt by 1,
> > -       Set connect retry timer to zero, and
> > -       Drops TCP connection,
> > -       Releases all BGP resources,
> > -       Goes to IdleHold state.
>
>I think it might be reasonable for the implementation to determine at
>this point which peer should be establishing the connection and drop
>it only if the local peer is not the one that should be making it.

This may be reasonable, but I tried to stay with the original text.
How about if we do this in two stages: fix the current state machine.
Do the things which are reasonable = 2nd version.


> >
> >
> > [...]
> >
> > If a NOTIFICATION message is received with a version error, the local
> > system:
> > -       Closes the transport connection
> > -       Releases BGP resources,
> > -       ConnectRetryCnt = 0,
> > -       Connect retry timer = 0, and
> > -       transition to Idle state.
>
>This makes the most sense if the local implementation is not able to
>regress to an earlier version.  I don't know about BGP implementations
>in general, but in using versioning with other protocols, the most likely
>cause of a version error is when a forward version tries to communicate
>with a backward version.  However, it is often the case that a forward
>version has some ability to regress.

My understanding is this text will aid in the version negotiation.   I welcome
other comments.   I must admit it is both a clarification and an addition.
I included it because most FSM are currently handling version negotiation
a little different.

Any comments on version negotiation would be helpful from the idr list here.
=
> >
> >
> > [...]
> >
> >
> > Each time time the local system sends a KEEPALIVE or UPDATE message, it
> > restarts its KeepAlive timer, unless the negotiated Hold Time value is 
> zero.
> >
> > In response to the Stop event initiated by the system (automatic), the
> > local system:
> > -       sends a NOTIFICATION with Cease,
> > -       sets IdleHoldtimer = 2**(ConnectRetryCnt)*60
> > -       increments ConnectRetryCnt by 1,
> > -       sets the connect retry timer to zero,
> > -       drops the TCP connection,
> > -       releases all BGP resources,
> > -       goes to IdleHold state, and
> > -       deletes all routes.
>
>Deletes routes learned from this peer?  Why was this step not included
>with all the other events that cause the peer to leave the Established state?

In all other states except Established, no routes should exist.

This is the base text and the graceful restart.   As soon as we get the 
base text
done, we would have to modify it for graceful restart.


> >
> >
> > [...]
> >
> > In response to any other event, the local system:
> > -       sends a NOTIFICATION message with Error Code Finite State Machine
> > Error,
> > -       sets IdleHoldtimer = 2**(ConnectRetryCnt)*60
> > -       increments ConnectRetryCnt by 1,
> > -       sets the connect retry timer to zero,
> > -       drops the TCP connection,
> > -       releases all BGP resources
> > -       goes to IdleHoldstate, and
> > -       deletes all routes.
>
>Same question here...

See above.


Great questions.    You're on my review list!!

Sue