Subject: Words - in ASCII text

From: Susan Hares <[email-masked]>
Date: Mon, 26 Aug 2002 14:13:14 -0400

Note: (this is version 5 of the changes to
        the text.)

8.0	BGP Finite State Machine

This section specifies the BGP operation in terms of a
Finite State Machine (FSM).  The section falls into 2
parts:

     1)	Description of Events for the State machine (section
         8.1
     2)	Description of the FSM (section 8.2)

Session Attributes required for each connection are;

    1)	state
    2)	Connect Retry timer
    3)	Hold timer
    4)	Hold time
    5)	Keepalive timer

8.1 Events for the BGP FSM

8.1.1   Administrative Events (events 1-5)

Please note that only Event 1 (manual start) and Event 2
(manual stop) are mandatory administrative events. All
other administrative events are optional.

  Event1: Manual start

	   Definition: Administrator manually starts peer
                        connection
	   Status: 	Mandatory

  Event2: Manual stop

	   Definition: Local system administrator manually
                        stops the peer connection.

	   Status: 	mandatory

  Event3: Automatic Start

  	   Definition: Local system automatically starts the
                        BGP peer session

	   Status:     Optional depending on local system

  Event4: Manual start with passive Transport Establishment

	   Definition: Administrator manually start the peer
                        Connection, but has the passive flag
                        enabled.  The passive flag indicates
                        that the peer will listen prior to
                        establishing the connection.

	   Status:     Optional depending on local system

  Event5: Automatic start with passive Transport establishment

	  Definition:  Local system automatically starts the
                        BGP session with the passive flag
                        enabled.  The passive flag indicates
                        that the peer will listen prior to
                        establishing a connection.

	  Status:      Optional depending on local system use
		       of a passive connection.

  Event6: Automatic start with bgp_stop_flap option set

	   Definition: Local system automatically starts the
                        BGP peer session with persistent peer
                        oscillation damping enabled.  The exact
                        method of damping persistent peer
                        oscillations is left up to the
                        implementation.   These methods of
                        damping persistent BGP adjacency
                        flapping are outside the scope of this
                        document.

            Status: 	Optional, used only if the bgp peer has
	  	        Enabled a method of damping persistent
		        BGP peer flapping.

  Event7: Auto stop

	   Definition: Local system automatically stops the
                        BGP peer session.
	
	   Status:     Optional depending on local system

8.1.2 Timer Events (events 8-11)

  Event8:  idle Hold timer expires

            Definition: Idle Hold timer expires.  The Idle
                        Hold Timer is only used when persistent
                        BGP oscillation damping functions are
                        enabled.

            Status: 	Optional.  Used when persistent
			BGP peer oscillation damping functions
			are enabled.

  Event9: connect retry timer expires

            Definition: An event triggered by the expiration of
                        the ConnectRetry timer.

	   Status:     Mandatory

  Event10: hold time expires

	   Definition: An event generated when the HoldTimer
                        expires.

	   Status:     Mandatory

  Event11: keepalive timer expires

	   Definition: A periodic event generated due to the
                        expiration of the KeepAlive Timer.

	   Status:     Mandatory

  Event12: DelayBGP Open timer expires [changed]
	
	   Definition: A timer that delays sending of the BGP
	               Open message for n seconds after the
                        Transport connection has been completed.

	   status:     Optional

8.2.3) Tranport Message based (13-16)

  Event13: Transport Connection Indication & valid remote peer[changed]

	   Definition: Event indicating that transport
                        Request valid source IP address and TCP
                        port, and valid destination IP address
                        and TCP Port.  The definition of
                        invalid Source, and invalid Destination
                        IP address is left to the implementation.
                        BGP's destination port should be port
                        179 as defined by IANA.

	   Status:     Mandatory

  Event14: RCV Transport Connection Indication and Invalid Source or
           Destination [changed]

            Definition: Transport request received with either
  		       an invalid source address or port
		       number or an invalid destination
                        address or port number. BGP destination
                        port  number should be 179 as defined
                        by IANA.

	    Status: 	 Mandatory
	
  Event15: Transport Connection request sent received an ACK.

            Definition: Local system's request to establish a transport
		       Connection to the remote side received
		       an ACK.

	    Status:    Mandatory

  Event16: Transport Connection Confirmed [changed]

	   Definition: The local system has received a Confirmation that
                        the transport connection has been established by
		       the remote site.

	  Status:      Mandatory

  Event17: Transport connection fails [changed]

            Definition: This BGP peer receives a transport
		       connection failure notice.  This
		       connection notice could be caused by a
		       Transport disconnect message or a
		       Timeout in the transport session.

                        If this connection is using TCP, the
		       remote BGP peer's TCP machine could
		       have sent a FIN.  The local peer would
		       respond with a FIN-ACK. Another
		       alternative is that the local peer
		       indicated a timeout in the TCP session
		       and downed the connection.

	    Status:    Mandatory

8.1.4 BGP Messages (18-27)

  Event18: BGPOpen

            Definition:  An event indicating that a valid Open
			message has been received.

	   Status: 	Mandatory

  Event19: BGPOpen with BGP Delay Open Timer running [changed]

            Definition: An event indicating that a valid Open
                        Message has been successful
                        established for a peer that is
                        currently delaying the sending of an
                        BGP Open message.

	    Status:    Optional

  Event20: BGPHeaderErr

	   Definition: BGP message header is not valid.

	   Status:     Mandatory

  Event21: BGPOpenMsgErr
	   Definition: An BGP Open message has been received
                         with errors.

	   Status: 	Mandatory

  Event22: Open collision discard

            Definition: An event generated administratively
                        when a connection Collision has been
                        detected while processing an incoming
                        Open message. This connection has been
                        selected to disconnected.  See section
                        6.8 for more information on collision
	               detection.

                        Event 22 is an administrative could
                        occur if FSM is implemented as two
                        linked state machines.

	  Status:      Optional

  Event23: NotifMsgVerErr

	    Definition: An event is generated when a
                         NOTIFICIATION message with "version
                         error" is received.

	    Status:     Mandatory

  Event24: NotifMsg

	    Definition: An event is generated when a
                         NOTIFICATION messages is received and
                         the error code is anything but 	
			"version error".

	     Status:	Mandatory
		
  Event25: KeepAliveMsg

	    Definition: An event is generated when a KEEPALIVE
			Message is received.

		Status: Mandatory

  Event26: UpdateMsg

	    Definition: An event is generated when a valid
			Update Message is received.

		Status: Mandatory

  Event27: UpdateMsgErr

	    Definition: An event is generated when an invalid
			Update message is received.

		Status:	Mandatory

8.2) Description of FSM

Idle state

    Initially BGP is in the Idle state.

    In this state BGP refuses all incoming BGP connections.  No
    resources are allocated to the peer.    In response to a
    manual start event(Event1) or an automatic start
    event(Event3), the local system
       -	initializes all BGP resources,
       -	sets the Connect retry counter to zero
       -	starts the ConnectRetry timer with initial value,
       -	initiates a transport connection to the other BGP
         peer,
       -	listens for a connection that may be initiated by
         the remote BGP peer, and
         [Action A in the FSM table]
       -	changes its state to connect.

   An manual stop event (Event2) is ignored in the Idle state.

   In response to a manual start event with the passive Transport
   flag (Event 4) or automatic start with the passive Transport flag
   (Event 5), the local system:
       -	initializes all BGP resources,
       -	sets the connect retry count to zero,
       -	start the Connect Retry timer with initial value,
       -	listens for a connection that may be initiated by
         the remote peer
         [Action B in the FSM table]
       -	changes its state to Active.

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

   If a persistent BGP peer oscillation damping function is
   enabled, two additional events may occur within Idle state:
       -	Automatic start with bgp_stop_flap set [Event6],
       -	Idle Hold Timer expired [Event 8].

   The method of preventing persistent BGP peer oscillation is
   outside the scope of this document.

   Any other events [Events 9-27] received in the Idle state,
   are noted by the MIB processing as FSM Errors [action V]
   and the local peer stays in the Idle State.

Connect State:

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

   If the transport connection succeeds [Event 15 or
   Event 16], the local system checks the "Delay Open
   Flag".  If the Delay Open flag is set, the local system:
      -	clears the ConnectRetry timer,
      -	set the BGP Open Delay timer to the initial
         value.
         [Action ZZ in FSM table]

   If the Delay Open flag is not set, the local system:
      - clears the ConnectRetry timer,
      - completes BGP initialization
      - send an Open message to its peer,
      - sets Hold timer to a large value,
      - Change the state to Open Sent
    [Action H in the FSM table]

   A hold timer value of 4 minutes is suggested.

   If the Open Delay timer expires [Event 12] in the connect
   state,
      - send an Open message to its peer,
      - set the Hold timer to a large value,
	[Action H in the FSM Table], and
      - change the state to Open Sent.

   If the BGP port receives a Transport connection indication
   [Event 13], the Transport connection is processed (actions AA or
   AB in the FSM table) and the connection remains
   in the connected state.

   If the transport connection receives an Transport indication
   that is invalid or unconfigured. [Event 14]:
      - the transport connection is rejected.
	[Action L in the FSM table]

   If the transport connection fails (timeout or transport
   disconnect) [Event17], the local system:
       - restarts the ConnectRetry timer,
       - continues to listen for a connection that may be
         initiated by the remote BGP peer, and
      [Action G in the FSM table]
       - changes its state to Active.

   If an Open is received with the BGP Delay Open timer is
   running [Event 19], the local system:
	- clears the connect retry timer (cleared to zero),
	- completes the BGP initialization,
	- Stops and clears the BGP Open Delay timer
	- Sends an Open message

	[Action H in the FSM table], and
	- changes its state to Open Confirm.

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

  A manual stop event[Event2], the local system:
        - drops the transport connection,
        - releases all BGP resources,
        - sets connect retry count to zero
        - resets the connect retry timer (sets to zero)
       [Action Z in the FSM table]
        - goes to Idle state.

   In response to the ConnectRetry timer expired event(Event
   9), the local system:
       - Sets the MIB FSM error information with ConnectRetry
         expired,
       - drops the transport connection
       - restarts the ConnectRetry timer
       - initiates a transport connection to the other BGP
         peer,
       - continues to listen for a connection that may be
         initiated by the remote BGP peer, and
       [Action O in the FSM table]
       - stays in Connect state.

  In response to any other events [Events 7-8, 10-11, 18, 20-
  27] the local system:
      - resets the connect retry timer (sets to zero),
      - 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],
      - goes to Idle state.

Active State:

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

  A transport connection succeeds [Event 15 or Event 16], the
  local system: process the transport connection flags
	- If the BGP delay open flag is set:
           o clears the ConnectRetry timer,
           o completes the BGP initialization,
           o sets the BGP delay Open timer
          [Action ZZ]

         - If the BGP delay open flag is not set:
           o clears the ConnectRetry timer,
           o completes the BGP initialization,
           o sends the Open message to it's peer,
           o sets its Hold timer to a large value,
          [Action H in the FSM table]
           and changes its state to OpenSent.

  A Hold timer value of 4 minutes is suggested.

  If the local system receives a valid Transport Indication
  [Event 13], the local system processes the Transport flags
   (actions aa or ab in FSM section 2.3.4).

  If the local system receives a Transport indication
  that is invalid for this connection [Event 14]:
       - the transport connection is rejected
         [Action L in the FSM table]

  If the local system receives a Transport connection
  failed [Event 17] (timeout or receives Transport
  disconnect), the local system will:
	- set Transport disconnect in the MIB reason code,
	- restart ConnectRetry timer (with initial value)
	- release all BGP resources
	- Acknowledge the drop of Transport connection if
           transport disconnect (If TCP, send a FIN ACK),
	- Increment ConnectRetryCnt by 1,
	- perform the BGP peer oscillation damping process [2]
	[Action Y in the FSM table]

  If the local system has the Delay Open timer expired [event
  12] local system:
         - clears the Connect Retry timer (set to zero),
	- stops and clears the Delay Open timer (set to zero)
         - completes the BGP initialization,
         - sends the Open message to it's remote peer,
         - sets it's Hold timer to a large value,
         [Action H in the FSM table]
         - and set the state to Open Confirm.

  A Hold timer value of 4 minutes is also suggested for this
  state transition.

  If an Open is received with the BGP Delay Open timer is
  running [Event 19], the local system
	- clears the connect retry timer (cleared to zero),
	- Stops and clears the BGP Open Delay timer
	- completes the BGP initialization,
	- Stops and clears the BGP Open Delay timer
	- Sends an Open message
	- Set the Hold timer to a large value (4 minutes),
	[Action H in the FSM table], and
	- changes its state to Open Confirm.

  In response the ConnectRetry timer expired event[Event9],
  the local system:
         - restarts the ConnectRetry timer (with initial value),
         - initiates a transport connection to the other BGP
           peer,
         - Continues to listen for transport connection that may be
           initiated by remote BGP peer,
         [Action F in the FSM table]
	- and changes its state to Connect.

  The start events [Event1, 3-6] are ignored in the Active
  state.

  A manual stop event[Event2], the local system:
         - Sets the administrative down in the MIB reason code,
	- Sends a notification with a Cease,
	- If any BGP routes exist, delete the routes
	- release all BGP resources,
	- drops the Transport connection,
         - sets connect retry count to zero
         - resets the connect retry timer (sets to zero)
         [Action S in the FSM table]
         - goes to Idle state.

  In response to any other event (Events 7-8, 10-11,18, 20-
  27), the local system:
         - stores the MIB information to indicate appropriate
           error [FSM for Events 7-8, 10-11, 18, 20-27]
         - reset the connect retry timer (sets to zero),
         - release all BGP resources,
	- drops the transport connection,
         - increments the ConnectRetryCnt by one,
         - optionally performs BGP peer oscillation damping,
   	  [Action D in FSM table],
	- and goes to the idle state

Open Sent:

  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 there are no errors in the OPEN message
  [Event 18] the local system:
        - resets the BGP Delay timer to zero,
        - reset BGP Connect Timer to zero,
        - sends a KEEPALIVE message and
        - sets a KeepAlive timer (via the text below)
        - sets the Hold timer according to the negotiated value
          (see section 4.2), and
          [Action N in the FSM table]
        - sets the state to Open Confirm.

  If the negotiated Hold time value is zero, then the Hold
  Time 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 the BGP message header checking [Event20] or OPEN message
  check detects an error (see Section 6.2)[Event21], the local system:
        - sends a NOTIFICATION message with appropriate error
          code,
        - reset the connect retry timer (sets to zero),
        - if there are any routes associated with the BGP session,
	 delete these routes
        - release all BGP resources,
        - drop the transport session
        - increments the ConnectRetryCnt by 1,
        - bgp peer oscillation damping process,
        [Actions I, J in FSM table, depending on error],
        - and goes to the Idle state.

  Collision detection mechanisms (section 6.8) need to be
  applied when a valid BGP Open is received [Event 18 or
  Event 19].  Please refer to section 6.8 for the details of
  the comparison. An administrative collision detect is when
  BGP implementation determines my means outside the scope of
  this document that a connection collision has occurred.

  If a connection in Open Sent is determined to be the
  connection that must be closed, an administrative collision
  detect [Event 22] is signaled to the state machine. If such
  an administrative collision detect dump [Event 22] is
  received in Open Sent, the local system:
        - sets MIB state information to
          collision detect closure,
        - send a NOTIFICATION with a CEASE
        - resets the connect retry timer,
        - release all BGP resources,
        - drop the transport connection,
        - increments ConnectRetryCnt by 1,
        - performs any BGP peer oscillation damp process, and
        [Action R in the FSM],
        - enters Idle state.

   If a NOTIFICATION message is received with a version
   error[Event23], Notification message without version number
   [Event 24], the local system:
        - resets the connect retry timer (sets to zero)
        - drops the Transport connection,
        - releases all BGP resources,
        - increments the ConnectRetryCnt by 1
        - process any BGP peer oscillation damping,
	[Action Y]
        - and sets the state to Idle.

  The Start events [Event1, 3-6] are ignored in the OpenSent
  state.

   If a manual stop event [Event 2] is issued in Open sent
  state, the local system:
	- Sets administrative down reason in MIB reason,
	- sends the Notification with a cease,
	- if BGP routes exists, delete the routes,
	- Release all BGP resources,
	- Drops the Transport connection,
	- set ConnectRetryCnt to zero,
	- resets the Connect Retry timer (set to zero),
	[Action S in the FSM table], and
	- transitions to the Idle state.

   If an automatic stop event [Event 7] is issued in Open sent
   state, the local system:
	- Sets administrative down reason in MIB reason,
	- sends the Notification with a cease,
	- if any routes are associated with te BGP session,
	  delete the routes,
	- release all the BGP resources
	- Drops the Transport connection,
	- increments the ConnectRetryCnt by 1,
	- BGP peer oscillation process [2]
	[Action C in the FSM table], and
	- transitions to the Idle state.

  If the Hold Timer expires[Event 10], the local system:
        - set Hold timer expired in MIB Error reason code,
        - send a NOTIFICATION message with error code Hold
          Timer Expired,
        - reset the connect retry timer (sets to zero),
        - releases all BGP resources,
        - drops the Transport connection,
        - increments the ConnectRetryCnt by 1
          [Action K in the FSM table], and
	- transitions to the Idle state.

  If a transport indication is received for valid connection
  [Event 13] or transport Request Acknowledgement [Event 15]
  is received, or a transport connect confirm [Event 16] is
  received a second TCP session may be in progress.  This
  second TCP session is tracked per the Call Collision
  processing (section 6.8) until an OPEN message is received.

  A TCP connection for an invalid port [Event 14] is ignored.

  If a Transport Failure [Event17], is received from the
  underlying transport protocol, the local system:
        - closes the BGP connection,
        - restarts the Connect Retry timer,
        - and continues to listen for a connection that may be
          initiated by the remote BGP peer,
        [Action O in the FSM table]
        - and goes into Active state.

  In response to any other event [Events 8-9, 11-12, 19, 25-27],
   the local system:
	- sends the NOTIFICATION with the Error Code Finite
           state machine error,
         - resets the connect retry timer (sets to zero),
	- releases all BGP resources
         - drops the Transport connection,
         - increments the ConnectRetryCnt by 1,
         - process any bgp peer oscillation damping[2]
         [Action E in the FSM table],
         - and sets the state to idle.

Open Confirm State

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

  If the local system receives a KEEPALIVE message[Event 25],
         - restarts the Hold timer,
           [Action P in the FSM table], and
         - changes its state to Established.

  If the local system receives a NOTIFICATION message [event
  23-24] or receives a TCP Disconnect [event 17] from the
  underlying transport protocol, the local system:
         - sets the appropriate MIB information for FSM error,
         - resets the connect retry timer (sets the timer to
           zero),
	- releases all BGP resources,
         - drops the TCP connection,
         - increments the ConnectRetryCnt by 1,
         [Action Y in the FSM table],
         - and sets the state to idle.

  Any start event [Event1, 3-6] is ignored in the OpenConfirm
  state.

  In response to a manual stop event[Event 2] initiated by
  the operator, the local system:
	- set Administrative down in MIB Reason code,
         - sends the NOTIFICATION message with Cease,
	- if any BGP routes, dete the routes
         - releases all BGP resources,
	- drop the transport connection,
         - sets the ConnectRetryCnt to zero
         - sets the connect retry timer to zero
         [Action S in the FSM table]
         - transitions to Idle state.

  In response to the Automatic stop event initiated by the
  system[event 7], the local system:
         - sets the MIB entry for this peer to administratively
           down,
         - sends the NOTIFICATION message with Cease,
	- connect retry timer reset (set to zero)
	- If any BGP routes exist, delete the routes,
	- release all BGP resources,
         - drops the transport connection,
         - increments the ConnectRetryCnt by 1,
         [Action C in the FSM table], and
         - transitions to the Idle State.

  If the Hold Timer expires before a KEEPALIVE message is
  received [event10], the local system:
         - set the MIB reason to Hold time expired,
         - send the NOTIFICATION message with the error code
           set to Hold Time Expired,
         - resets the connect retry timer (sets the timer to to
           zero),
	- releases all BGP resources,
         - drops the transport connection,
         - increments the ConnectRetryCnt by 1
           [Action K in the FSM table],
         - and sets the state to Idle.

  If the local system receives a KEEPALIVE timer expires
  event [Event 11], the system:
         - sends a KEEPALIVE message,
         - restarts the Keepalive timer
         [Action Q the in FSM table],and
         - remains in Open Confirmed state.

  In the event of TCP establishment [Event 13], or TCP
  connection succeeding [Event 15 or Event 16] while in Open
  Confirm, the local system needs to track the 2nd
  connection.

  If a TCP connection is attempted to an invalid port [Event
  14], the local system will ignore the second connection
  attempt.

  If an OPEN message is received, all fields are check for
  correctness.  If the BGP message header checking [Event20]
  or OPEN message check detects an error (see Section
  6.2)[Event21], [the local system:
         - sends a NOTIFICATION message with appropriate error
           code,
         - resets the connect retry timer (sets the timer to
           zero),
         - releases all BGP resources,
         - drops the TCP connection,
         - increments the ConnectRetryCnt by 1,
         - runs the BGP peer oscillation damping process [2]
        [Actions I, J, in the FSM table depending on the error]
         - and goes to the Idle state.

  If the Open messages is valid [Event 18], the collision
  detect function is processed per section 6.8.  If this
  connection is to be dropped due to call collision, the
  local system:
         - sets the Call Collision cease in the MIB reason
          code,
         - sends a Notification with a Cease
         - resets the Connect timer (set to zero),
	- releases all BGP resources,
	- Drops the TCP connection (send TCP FIN),
	- increments the ConnectRetryCnt by 1, and
	- performs any BGP peer oscillation damping process [2].
	[action

  If during the processing of another Open message, the BGP
  implementation determines my means outside the scope of
  this document that a connection collision has occurred and
  this connection is to be closed, the local system will
  issue a call collision dump [Event 22].  When the local
  system receives a call collision dump event [Event 22], the
  local system:
         - Sets the MIB FSM variable to indicate collision
           detected and dump connection.
         - send a NOTIFICATION with a CEASE
         - deletes all routes associated with connection,
         - resets the connect retry timer,
         - releases all BGP resources
         - drops all TCP connection,
         - increments the ConnectRetryCnt by 1,
         - and performs any BGP peer oscillation damping,
         [Action R in the FSM table],
         - enters Idle state.

  In response to any other event [Events 8-9, 12, 19, 26-27],
  the local system:
         - sends a NOTIFICATION with a code of Finite State
           Machine Error,
         - resets the connect retry timer (sets to zero)
         - drops the TCP connection,
         - releases all BGP resources,
         - increments the ConnectRetryCnt by 1,
         - performs any BGP peer oscillation damping,
         [Action E in the FSM table], and
         - transitions to Idle state.

Established State:

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

  If the local system receives an UPDATE message [Event26],
  the local system will:
	- process the update packet
	- restarts its Hold timer, if the negotiated Hold Time
           value is non-zero.
	[Action W in the FSM table], and
	- remain in the Established state.

  If the local system receives a NOTIFICATION message
  [Event23 or Event24] or a disconnect [Event17] from the
  underlying transport protocol, it:
	- sets the appropriate error code in MIB reason code,
	- if any BGP routes exist, delete all BGP routes,
         - resets the connect retry timer (sets to zero),
         - releases all the BGP resources,
	- drops the TCP connection,
	- increments the ConnectRetryCnt by 1, and
        [Action T in the FSM table]
	- Goes to the Idle state.

  If the local system receives a Keepalive message
  [Event 25], the local system will:
         - restarts its Hold Timer, if the negotiated Hold Time
           value is non-zero.
        [Action P in the FSM table], and
	- remain in the Established state.

  If the local system receives an UPDATE message, and the
  Update message error handling procedure (see Section 6.3)
  detects an error [Event27], the local system:
        - sends a NOTIFICATION message with Update error,
        - resets the connect retry timer (sets to zero),
        - drops the TCP connection,
        - releases all BGP resources,
        - increments the ConnectRetryCnt by 1
        - performs any BGP peer oscillation damping
       [Action U in FSM table],
        - and goes to Idle state.

  Any start event (Event 1, 3-6) is ignored in the
  Established state.

  In response to a manual stop event (initiated by an
  operator)[Event2]:
         - sets the Administrative stop in MIB reason code,
	- sends the NOTIFICATION message with Cease,
         - if BGP routes exist, delete the BGP routes,
         - release BGP resources,
	- drop TCP connection,
         - set ConnectRetryCnt to zero (0),
         - reset connect retry timer to zero (0), and
         [Action S in FSM table]
         - transition to the Idle.

  In response to an automatic stop event initiated by the
  system (automatic) [Event7], the local system:
      - sets Administrative Stop in MIB Reason code,
      - sends a NOTIFICATION with Cease,
      - resets the connect retry timer (sets to zero)
      - deletes all routes associated with bgp peer session,
      - releases all BGP resources,
      - drops the transport connection,
      - increments the ConnectRetryCnt by 1,
      - performs any BGP peer oscillation damping, and
      [Action C in FSM table]
      - transitions to the idle state.

  An example automatic stop event is exceeding the number of
  prefixes for a given peer and the local system
  automatically disconnecting the peer.

  If the Hold timer expires [Event10], the local system:
       - sends a NOTIFICATION message with Error Code Hold
         Timer Expired,
       - resets the connect retry timer (sets to zero),
       - releases all BGP resources,
       - drops the TCP connection,
       - increments the ConnectRetryCnt by 1,
       -	performs any BGP peer oscillation damping,
       [Action M in FSM table]
       - and goes to Idle state.

  If the KeepAlive timer expires [Event11], the local system
  sends a KEEPALIVE message, it restarts its KeepAlive timer,
  unless the negotiated Hold Time value is zero [Action Q].

  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.

  A transport connection indication [Event 13] received
  for a valid port will cause the 2nd connection to be
  tracked.  A transport connection indications for
  invalid port [Event 14], will be ignored.

  In response to a Transport connection succeeds [Event 15
  or Event 16], the 2nd connection shall be tracked until
  it sends an OPEN message.

  If a valid Open message [Event 18] is received, it will be
  checked to see if it collides (section 6.8) with any other
  session. If the BGP implementation determines that this
  connection needs to be terminated, it will process an Call
  Collision dump event[Event 22].  If this session needs to be
  terminated, the connection will be terminated by:

      - send a NOTIFICATION with a CEASE
      - deletes all routes associated with connection,
      - resets the connect retry timer,
      - if any BGP routes, delete the routes,
      - release all BGP resources,
      - drops the transport connection,
      - increments ConnectRetryCnt by 1,
      - and performs any BGP peer oscillation damping,
     [Action R in the FSM table],
      - and enters the Idle state

  In response to any other event [Events 8-9,12, 19-21] the
  local system:
      - sends a NOTIFICATION message with Error Code Finite
        State Machine Error,
      - deletes all routes associated with BGP peer session,
      - resets the connect retry timer (sets to zero)
      - releases all BGP resources,
      - drops the TCP connection,
      - increments the ConnectRetryCnt by 1,
      - performs any BGP peer oscillation damping, and
      [Action E in FSM table],
      - transitions to Idle.

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 29 Aug 2002 22:01:04 +0100

I like the idea of writing this in terms of an abstract transport with
the TCP specific mapping specified separately in which case I suggest
amending the remaining 11 references to 'drop the TCP connection' to
'drop the transport connection' (or perhaps disconnect rather than
drop).  I believe strongly that consistent use of language is crucial
to make a document as abstract as this as easy to assimilate as
possible - it is for me - so every reference to eg event 14 should be
precisely the
same; using slightly different terminology in different places may
convey a lack of clarity in the underlying thinking when that is not
at all the case.

And perhaps

>  Event13: Transport Connection Indication & valid remote
peer[changed]

(do we need valid remote peer?)
Definition: A transport Connection request with a valid transport
address has been received.

For TCP, the destination port should be port 179 as defined by IANA.
The definition of valid Source and Destination  IP address is left to
the implementation.
Event14: Transport Connection Indication and Invalid transport address
[changed]
Definition: A Transport connection request with an invalid transport
address has been received .

For TCP, the destination port  number should be 179 as defined  by
IANA.
The definition of valid Source and Destination  IP address is left to
the implementation.
Event15/Event16:
I have problems here; the idea of the two half-duplex connections
being established by a SYN and an ACK is peculiar to TCP and I do not
have an abstract term for it :-(
>        Timeout in the transport session.

In the abstract, disconnect is all is needed as that covers a TCP
timeout.  I would prefer terminates to fails since fails has overtones
that may not be apppropriate.

>   matter, but it should be sufficiently large to allow

the initialisation of a transport connection
>  received

a second transport conneciton may be in progress.  This second
connection

> is tracked per the Call Collision

A transport connection indication with an invalid transport
address[Event 14] is ignored.
>  In the event of

a transport connection indication[Event 13]  or transport

>  If a transport connection is attempted with an invalid transport
address [Event

---

From: "Natale, Jonathan" <[email-masked]>
Date: Thu, 29 Aug 2002 17:34:49 -0400

I agree.  To make things understandable, the terms should be exactly
consistent, and as specific as required, but not any more specific (except
for [typical] examples) than that.  If multiple terms for the same item are
already in common use (as is unfortunately the case sometimes), then this
should be explained in a definitions section, but otherwise the document
should still be consistent.

-$0.01

-----Original Message-----
From: Tom Petch [mailto:[email-masked]] 
Sent: Thursday, August 29, 2002 5:01 PM
To: idr; Susan Hares
Cc: yakov Rekhter; [email-masked]; [email-masked]; randy Bush
Subject: Re: Words - in ASCII text

And perhaps

Event15/Event16:

address [Event

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 30 Aug 2002 10:25:49 +0100

Thinking some more, TCP SYN, SYN-ACK, SYN packets can carry data such
as an OPEN message ie events 13, 15, 16 can also be events 18, 19 etc;
should we cater for this?

If not, I think we should include a note to the effect that we are
not.