Subject: IdleHold

From: Greg Hankins <[email-masked]>
Date: Thu, 12 Sep 2002 10:45:31 -0400

I am still not convinced that IdleHold should be in the new BGP
specification.

Given that the goal of the WG is to "revise and clarify the base BGP4
document" and to "document existing practice", I do not think that it
should be included because this doesn't seem to be an existing practice
(or at least one practiced by the majority of implementations).

I have two questions:

1. Which existing implementations support the IdleHold state, its timer
   and flag?

2. What existing documentation (books/courses/etc) lists IdleHold as a state
   in the FSM?

If the answers to these questions are not "the majority", then it isn't
an existing practice.  Any implementation that does not support this state
is now automatically non-standards compliant.

I suggest that this state be documented in a separate draft that addresses
stability.

Greg

-- 
Greg Hankins <[email-masked]> | Riverstone Networks, Inc.
Systems Engineering                       | 5200 Great America Parkway
http://www.riverstonenet.com/             | Santa Clara, CA 95054
+1 404 434 0355                           | +1 408 878 6500

---

From: Susan Hares <[email-masked]>
Date: Thu, 12 Sep 2002 15:29:31 -0400

Greg:

1st clarification - there is no IdleHold state in BGP.  There is
an IDLE state with sub-state like features.  Where do you find this
IdleHold state in the words I've attached?

Are we on the same document?

>1. Which existing implementations support the IdleHold state, its timer

***NO*** Implementation support Idle hold state.

Please refer to the hares-backoff draft for two know possibilities.
GateD by NextHop was the source of one method.  Another method is
attempting to describe cisco's back-off.   We will look to include others.
It's a "drafty" draft right now.  Please send me your favorite
persisent peer oscillation information.

>2. What existing documentation (books/courses/etc) lists IdleHold as a state

There is no IdleHold state.  There are Idle hold features (see the
bgp draft-15 for those sub-features described.)

>I suggest that this state be documented in a separate draft that addresses

The sub-state within Idle has been moved to the backoffdraft.
We are taking this approach.  Yakov and I agree that this is a good idea.

Hope this helps.   Do give me a call if this is unclear.  Let me know
if you need the phone number.

Sue

---

From: Greg Hankins <[email-masked]>
Date: Thu, 12 Sep 2002 12:09:23 -0400

>IdleHold state in the words I've attached?

draft-ietf-idr-bgp4-17 page 34.  It describes a new state, a new timer and
a new flag.  You imply that the state has already been moved to a separate
draft, if so then this is great.

Greg

>
>
>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: Susan Hares <[email-masked]>
Date: Thu, 12 Sep 2002 20:01:24 -0400

Greg and all members of IDR.

We are not reviewing draft-17.  Draft-17 is broken.
We are reviewing the text I sent to the list for inclusion.
I am attaching the text.

Please, please stop if you are reviewing draft-17.  The comments
you are raising have been raised before (sometimes by
co-workers in your same company).  And I fixed the text.

Greg - you are not the only one with this misconception.

Was there some way the last call was unclear about
what was being reviewed?

Sue

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 23 Sep 2002 13:53:52 -0400

Sue,

In addition to the comments about wording consistancy, capitalization
consistancy is also needed throughout the document.

>  Event6: Automatic start with bgp_stop_flap option set

For completeness, shouldn't there also be a 
"Automatic start with passive transport and bgp_stop_flap_on"?
If not, Event6 should also be flagged to be the event that takes
place with either passive enabled or disabled.

I would also suggest altering the wording from "The passive flag
indicates that the peer will lissten prior to establishing a
connection", which implies to me that we listen and *then*
establish the connection.  What is actually meant here is that
the FSM instance doesn't initiate a transport connection but
simply listens for an incoming one.

>  Event8:  idle Hold timer expires 

which still occurs in this document.

>      -	set the BGP Open Delay timer to the initial 

       - Stays in the connect state

This is a DFA, after all.

> Active State:
[...]

> 	- Sends a notification with a Cease,

We can't send a notification - there is no transport connection

> 	- If any BGP routes exist, delete the routes

There are no routes

> 	- drops the Transport connection, 

etc.

> 	- drops the transport connection, 

ditto.

>  BGP implementation determines my means outside the scope of 

by means

>   [Event 24], the local system: 

Something's not right about the English here - is this "or Notification
message without version number"?

> 	- if BGP routes exists, delete the routes,

We should have no routes in this state.

> 	- if any routes are associated with te BGP session,

ditto.

> 	- if any BGP routes, dete the routes

We have no routes to "dete". :-)

> 	- If any BGP routes exist, delete the routes,

No routes here either.

>  14], the local system will ignore the second connection 

Since we're talking about transport events at a deep level
(which I don't necessarily agree with in this case), the local
system needs to do the appropriate thing to reject the incoming
connection.

>  If an OPEN message is received, all fields are check for 

are checked

> 	- Drops the TCP connection (send TCP FIN),

Again, the dangers of talking about TCP events here.
You now have to worry about FIN+ACK, etc.  Lets not talk about this.

>  implementation determines my means outside the scope of 

by means

>  detects an error [Event27], the local system:

I'm somewhat concerned by the definition of "an error" in this
particular case.  There are several things that are considered
errors that may either be ignored or are recoverable.

We should probably say something along the lines of "detects an
error that must be reported via a NOTIFICATION message"

>  sends a KEEPALIVE message, it restarts its KeepAlive timer, 

and restarts
no comma

>  it sends an OPEN message.  

The language needs tightening here.  If you are tracking it
solely as an observer, thats fine.  If you have a single FSM
then the act of not tracking it is problematic - it may mean
that you've disconncted the session.

-- 
Jeff Haas 
NextHop Technologies