Re: bgp4-17 Cease subcode

[Kunihiro Ishiguro <[e-mail]>]

>Here's the state machine diagram and event plan that
>matches the state machine.   You could
>look at the state machine diagram to easily walk through
>the words.

Thanks Sue.  It's very helpful to understand the whole picture.  Here
is a draft of FSM section based upon bgp4-16 description and your FSM
chart.  I tried:

 o Create a new sub-section 8.1 for Exponential Back-off.
 o Do not add IdelHold status.
 o Use new bgp4-17 like action description format (I use bullet for
   each action).

Any comments are welcome.

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

8. BGP Finite State machine.

   This section specifies BGP operation in terms of a Finite State
   Machine (FSM). Following is a brief summary and overview of BGP
   operations by state as determined by this FSM.

      Initially BGP is in the Idle state.

      Idle state:

         In this state BGP refuses all incoming BGP connections. No
         resources are allocated to the peer. In response to the Start
         event initiated by either system or operator (see Section
         8.1) the local system:

            o Initializes all BGP resources.

            o Starts the ConnectRetry timer.

            o Initiates a transport connection to other BGP peer.

            o Changes its state to Connect.

         The exact value of the ConnectRetry timer is a local matter,
         but should be sufficiently large to allow TCP initialization.

         Any other event received in the Idle state is ignored.

      Connect state:

         In this state BGP is waiting for the transport protocol
         connection to be completed.

         If the transport protocol connection succeeds, the local
         system:

            o Clears the ConnectRetry timer.

            o Completes initialization.

	    o Sends an OPEN message to its peer.

	    o Changes its state to OpenSent.

         If the transport protocol connect fails (e.g., retransmission
         timeout), the local system:

            o Restarts the ConnectRetry timer.

            o Continues to listen for a connection that may be
              initiated by the remote BGP peer.

            o Changes its state to Active state.

         In response to the ConnectRetry timer expired event, the local
         system:

	    o Restarts the ConnectRetry timer.

            o Initiates a transport connection to other BGP peer.

            o Continues to listen for a connection that may be
              initiated by the remote BGP peer.

            o Stays in the Connect state.

         The Start event is ignored in the Connect state.

         In response to any other event (initiated by either system or
         operator), the local system releases all BGP resources
         associated with this connection and changes its state to Idle.

      Active state:

         In this state BGP is trying to acquire a peer by listening for
         and accepting a transport protocol connection.

         If the transport protocol connection succeeds, the local
         system:

            o Clears the ConnectRetry timer.

            o Completes initialization.

            o Sends an OPEN message to its peer.

            o Sets its Hold Timer to a large value.

            o Changes its state to OpenSent.

         A Hold Timer value of 4 minutes is suggested.

         In response to the ConnectRetry timer expired event, the local
         system:

	    o Restarts the ConnectRetry timer.

            o Initiates a transport connection to the other BGP peer.

	    o Continues to listen for a connection that may be
	      initiated by the remote BGP peer.

	    o Changes its state to Connect.

         If the local system does not allow BGP connections with
         unconfigured peers, then the local system:

	    o Rejects connections from IP addresses that are not
              configured peers.

	    o Remains in the Active state.

         The Start event is ignored in the Active state.

         In response to any other event (initiated by either system or
         operator), the local system releases all BGP resources
         associated with this connection and changes its state to Idle.

      OpenSent state:

         In this state BGP waits for an OPEN message from its peer.
         When an OPEN message is received, all fields are checked for
         correctness. If the BGP message header checking or OPEN message
         checking detects an error (see Section 6.2), or a connection
         collision (see Section 6.8) the local system sends a
         NOTIFICATION message and changes its state to Idle.

         If there are no errors in the OPEN message, the local system:

	    o Sends a KEEPALIVE message.

            o Sets a KeepAlive timer.

            o Sets a Hold timer according to the negotiated Hold time
              value (see section 4.2).

            o Changes its state to OpenConfirm.

         If the negotiated Hold time value is zero, then the Hold
         timer and KeepAlive timers are not started.  If the value of
         the Autonomous System field is the same as the local
         Autonomous System number, then the connection is an
         "internal" connection; otherwise, it is an "external"
         connection.  (This will impact UPDATE processing as described
         below.)

         If a disconnect notification is received from the underlying
         transport protocol, the local system:

	    o Closes the BGP connection.

            o Restarts the ConnectRetry timer.

            o Continue listening for connection that may be initiated
              by the remote BGP peer.

	    o Changes its state to Active.

         If the Hold Timer expires, the local system:

            o Sends NOTIFICATION message with error code Hold Timer
              Expired.

            o Changes its state to Idle.

         In response to the Stop event (initiated by either system or
         operator) the local system:

	    o Sends NOTIFICATION message with Error Code Cease.

            o Changes its state to Idle.

         The Start event is ignored in the OpenSent state.

         In response to any other event the local system:

	    o Sends NOTIFICATION message with Error Code Finite State
	      Machine Error

            o Changes its state to Idle.

         Whenever BGP changes its state from OpenSent to Idle, it closes
         the BGP (and transport-level) connection and releases all
         resources associated with that connection.

      OpenConfirm state:

         In this state BGP waits for a KEEPALIVE or NOTIFICATION
         message.

         If the local system receives a KEEPALIVE message, the local
         system:

            o Changes its state to Established.

         If the Hold Timer expires before a KEEPALIVE message is
         received, the local system:

	    o Sends NOTIFICATION message with error code Hold Timer
	      Expired.

            o Changes its state to Idle.

         If the local system receives a NOTIFICATION message, the
         local system:

            o Changes its state to Idle.

         If the KeepAlive timer expires, the local system:

	    o Sends a KEEPALIVE message.

	    o Restarts its KeepAlive timer.

         If a disconnect notification is received from the underlying
         transport protocol, the local system:

            o Changes its state to Idle.

         In response to the Stop event (initiated by either system or
         operator) the local system:

	    o Sends NOTIFICATION message with Error Code Cease.

	    o Changes its state to Idle.

         The Start event is ignored in the OpenConfirm state.

         In response to any other event the local system:

	    o Sends NOTIFICATION message with Error Code Finite State
	      Machine Error.

            o Changes its state to Idle.

         Whenever BGP changes its state from OpenConfirm to Idle, it
         closes the BGP (and transport-level) connection and releases
         all resources associated with that connection.

      Established state:

         In the Established state BGP can exchange UPDATE, NOTIFICATION,
         and KEEPALIVE messages with its peer.

         If the local system receives an UPDATE or KEEPALIVE message,
         the local system: 

            o Restarts its Hold Timer, if the negotiated Hold Time
              value is non-zero.

         If the local system receives a NOTIFICATION message, the
	 local system: 

	    o Changes its state to Idle.

         If the local system receives an UPDATE message and the UPDATE
         message error handling procedure (see Section 6.3) detects an
         error, the local system:

	    o Sends a NOTIFICATION message.

	    o Changes its state to Idle.

         If a disconnect notification is received from the underlying
         transport protocol, the local system:

	    o Changes its state to Idle.

         If the Hold Timer expires, the local system:

	    o Sends a NOTIFICATION message with Error Code Hold Timer
              Expired.

	    o Changes its state to Idle.

         If the KeepAlive timer expires, the local system:

	    o Sends a KEEPALIVE message.

	    o Restarts its KeepAlive timer. if the negotiated Hold
	      time value is non-zero.

         Each time the local system sends a KEEPALIVE or UPDATE
         message, it restarts its KeepAlive timer, if the negotiated
         Hold Time value is non-zero.

         In response to the Stop event (initiated by either system or
         operator), the local system sends a NOTIFICATION message with
         Error Code Cease and changes its state to Idle.

         The Start event is ignored in the Established state.

         In response to any other event, the local system:

	    o Sends NOTIFICATION message with Error Code Finite State
	      Machine Error.

            o Changes its state to Idle.

         Whenever BGP changes its state from Established to Idle, it
         closes the BGP (and transport-level) connection, releases all
         resources associated with that connection, and deletes all
         routes derived from that connection.

8.1 Exponential Back-off.

   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.  Suggested value
   for this timer is:

   2**(consecutive retry count)*60

   An implementation MAY impose a configurable upper bound on that
   timer value. Once the upper bound is reached, the speaker shall
   stop the timer then no longer automatically generate the Start
   event for the peer.