Subject: bgp-18 FSM OpenDelay

From: "Tom Petch" <[email-masked]>
Date: Wed, 13 Nov 2002 17:48:39 -0000

I (still) do find the Active and Connect states complicated, made so
by the fact that they are each two states, with the second of each
relating to open delay and its timer, entered once the transport
connection is complete.  The FSM will be simpler if that OpenDelay
state is made explicit since this will eliminate the current
duplication between Active and Connect states and tie up some loose
ends in those states that will otherwise need fixing.  This proposal
does not make any semantic change.

OPENDELAY State:

In this state, BGP has completed a transport connection,
the DelayOpen flag is set,
no Open message has been sent or received and
the OpenDelay timer is running.
The KeepAlive and Hold timers should not be running.

If the OpenDelay timer expires [Event 12] in the OpenDelay state,
the local system
     - completes the BGP initialization,
     - sends an Open message to its peer,
     - starts the Hold timer with a large value,
     - changes the state to OpenSent

     A hold timer value of 4 minutes is suggested.

If a Transport Failure [Event17] is received from the
underlying transport protocol, the local system:
       - closes the BGP connection,
       - starts the Connect Retry timer with initial value,
       - listens for a connection that may be
         initiated by the remote BGP peer,
       - stops the OpenDelay timer
       - changes the state to Active

If an Open message is received [Event 19], the local system:
- completes the BGP initialization,
- stops the OpenDelay timer
- sends an Open message
- sends KeepAlive message
      - starts KeepAlive timer
      - changes the state to OpenConfirm

The start events [Event 1, 3-6] are ignored in OpenDelay
state.

For a manual stop event[Event2], the local system:
       - drops the transport connection,
       - releases all BGP resources,
       - sets ConnectRetryCnt to zero
       - stops OpenDelay timer
       - goes to Idle state.

In response to any other events [Events 7-9, 10-11, 13-16, 18, 20-
27] the local system:

     - drops the Transport connection,
     - release all BGP resources,
     - increments the ConnectRetryCnt by 1,
     - [optionally] performs bgp peer oscillation damping, and
     [Action D in the FSM table],
     - stops the OpenDelay timer
     - goes to Idle state.

I can give you the simplifications to the Active and Connect states if
required.

Tom Petch
[email-masked]