Subject: fsm missing next state - Events 13 - 17 and the TCP connection

From: "Susan Hares" <[email-masked]>
Date: Wed, 4 Dec 2002 21:18:30 -0500

Implementers of the BGP FSM we need your help! 
Tom Petch has raised a concern about events 13-17
on the mail list in thread:

	RE: bgp18 WG Last Call fsm missing next state

I welcome any comments public (or to me or Yakov privately)
on this topic.  I will utilize private comments to answer
some of the questions below. 

============================

These events are described in section 8.1.3.

In our discussion in January through May of 2002, many
implementers mapped their implementation onto the
following TCP events  list in 8.1.3. 

Events 13 - 17 

	Event 13 - TCP connection indication & valid
		   remote peer

	Event 14 - TCP connection indication with invalid
		   source or destination
	
	Event 15 - TCP connection request sent (by this
		   peer) received an Acknowledgement
		
		[ local system sent a TCP SYN, Received a
		  TCP SYN, ACK pair back, and Sent a TCP ACK]

	Event 16 - TCP connection confirmed 

		[local system received a TCP SYN, sent
		 a TCP SYN, ACK back, and received a TCP ACK]

	Event 17 - TCP connections

Should we have all of these states?  Which implementations
support all of these Events?   

The FSM State machine for this group is

           Idle   Connect Active Open-Sent Open-Confirm Establish
Event-13:  [TCP connection request from valid remote peer] 
           =======================================================
 Nxt state Idle  |Connect|Active|Open-Sent|Open-Confirm|Establish |  
	     ========================================================
 action       V  | *1    | *2   |Track 2nd | Track 2nd  | Track 2nd |
                 |       |      |connection| connection | connection
	     =========================================================
  V - Process FSM Error.

 * 1 We sent TCP SYN.  Is this TCP connection in response or 
     a new connection to port 179?  

     The FSM state machine in the hares-bgp4-statemt-02 draft
     uses this event to track the TCP connection messages.
     The sub-state machine uses flags
	 1) Await TCP SYN
	 2) Sent TCP SYN
	 3) Await TCP ACK 
       4) Null - no flags

     These state is being used to track the TCP connection state.  

    recommendation: Make this Event optional.
    Open questions: 
     Do we believe the Two TCP SYN cross for the same
     connection?  Does this TCP related portion of the state
     machine handle this? 

 * 2 - local system received a TCP SYN from the remote port. All the same
       comments from *1 apply. 

Event 14  TCP REQ request received from an invalid peer
	     =======================================================
Current            Idle   Connect Active Open-Sent Open-Confirm Establish
           =======================================================
 Nxt state Idle  |Connect|Active|Open-Sent|Open-Confirm|Establish|  
	     =======================================================
 action       V  | L    | L     | Ignore  | Ignore     | Ignore  |
	     =======================================================

Event 15    - TCP connection request sent received an ACK
                      =======================================================
Current            Idle   Connect Active Open-Sent Open-Confirm Establish
           =======================================================
Next state Idle  |Connect|Active  |Open-Sent|Open-Confirm|Establish|  
	           |or Open|or Open |         |            |         |
                 | Sent  | Sent   |         |            |         |
	     =========================================================
 action       V  | *3    | *4     | Ignore  | Ignore     | Ignore  |
	     =========================================================

  *3/*4 - The actions taken in *3/*4 differ only in the next state
	    if the Delay Open flag is set.  

     - If Delay Open flag is set, the local system will:
		do (ZZ): - Clear the connection retry timer, and 
			   - Set Open Delay timer to initial value, and
			   - [*3]stay in the Connect state 
			     [*4]stay in the Active state 
			      
    	 - If Delay Open flag is not set, the local system will:
		do (H)
			- clears the connect retry timer,
			- completes the BGP initialization,
			- clears the Open Delay timer (sets to zero), 
			- send an Open message to its peer,
			- sets hold timer to a large value, and
			- change the state to Open Sent.

Event 16   - TCP connection confirmed (Received TCP Req, Sent TCP SYN, ACK),
Current            Idle   Connect Active Open-Sent Open-Confirm Establish
           =========================================================
Next state Idle  |Connect|Active  |Open-Sent|Open-Confirm|Establish|  
	           |or Open|or Open |         |            |         |
                 | Sent  | Sent   |         |            |         |
	     =========================================================
 action       V  | *3    | *4     | Ignore  | Ignore     | Ignore  |
		========================================================

Event 17  - TCP Connection Fails 
           ======================================================== 
 Current   Idle   Connect Active Open-Sent Open-Confirm Establish
           =========================================================
 Nxt state Idle  |Active |Idle    |Active | Idle       |Idle       |  
	     =========================================================
 action       V  | G     | Y2     | Ignore| Track 2nd  | Track 2nd |
                 |       |        |       | connection | connection|
	     =========================================================

    G: the local system will:
		- restart the connect retry timer (with initial value),
		- continue to listen for a connection that may be initiated
		  by remote peer, and
		- change its state to active. 

	Y2 - is:
	The local system: 
		1) increments the ConnectRetryCnt (connect retry count) by 1,
		2) Releases all BGP resources associated with this connection, and
		3) performs the BGP peer oscillation damping process.

	If the damping process allows for a new connection, the local system
		- restarts the connect retry timer (with initial value), and 
		- goes to Idle

	If the damping process does not allow for a new connection, the local
	system
		- releases the BGP resources, and goes to 
		- Idle.

	Please note: the proposal for event 17, has Connect and Active doing the same thing.
		       Please comment on how your state machine works.