Subject: Re: Open FSM issues

From: "Tom Petch" <[email-masked]>
Date: Wed, 26 Feb 2003 09:47:15 -0000

I still have open issues with next states.

Connect state event 14 has no next state; the discussion became one of
what action to take (issue13.2) with proposals for going to Active or
staying in Connect and I am not clear from the issue list what the
answer is.

Likewise Active state events 13 and14, the discussion became (Issue
13.4) should the events be optional?  Don't care but whether they are
or are not optional, the fsm needs a next state and I do not see it in
the issue list.

Tom Petch
[email-masked]

-----Original Message-----
From: [email-masked] <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: 26 February 2003 05:44
Subject: Re: Open FSM issues

>Sue,
>
>I've updated the issues' list and what is below generally jives with
what
>I have, exceptions are noted below:
>
>> Here's the current open issues (please check Andrew):
>>
>> - 24 - consensus, no change (Siva agrees)
>> - 26 - consensus, I added a new event per Siva request, see text
below
>> - 33 - Yakov and Sue declare consensus, stay with current text
>> - 41 - Old event 14 is now optional based on the Track TCP flag
>> - 42 - I accept Tom's text with the additions to make
>>      send the Notification based on a new optional attribute
>>      in Connect and Open Sent
>>
>> -  44 - Now event 24 (due to issue 26) I accept Tom's solution and
>>          I'll put the text in Connect and Open Sent
>
>I assume, you mean Siva's solution?  I didn't see Tom's comments in
the
>issue log, although I could have missed something.  The issue has
been updated
>as at consensus, with the text you've supplied below.
>
>> - 45 - Event 18 (due to issue 26) in Connect State - I accept Tom's
solution and
>>         I'll put the text below in connect state.
>>
>> - 52 - Yakov and Sue declare consensus, no changes
>
>I added the text you have below, section 8.2.1.3 to the issues list.
I'm
>not sure that this completely resolves the original issue, which
focused
>on when we need to start the Keepalive timer, however, since there
have been
>a lot of changes to the FSM, let's call it at consensus, and we if a
problem
>remains we can address it then.
>
>Also, with this issue, am I correct to assume that the text that
issue 12
>produced with regard to keepalive timers, which is also quoted here
will
>remain in the document?  Specifically this text is:
>
> Change 1:  new text
>
> Active state - event 19
>
>    If an Open is received with the Open Delay timer is
>    running [Event 19], the local system
>        - clears the connect retry timer (cleared to zero),
>        - stops and clears the Open Delay timer
>        - completes the BGP initialization,
>        - stops and clears the Open Delay timer
>        - sends an OPEN message,
>        - send a Keepalive message,
>        - if the hold timer value is non-zero,
>                - starts the keepalive timer to initial value,
>                - resets the hold timer to the negotiated value,
>          else if the hold timer is zero
>                - resets the keepalive timer (set to zero),
>                - resets the hold timer to zero.
>
>        - changes its state to OpenConfirm.
>
>    If the value of the autonomous system field is the same as the
local
>    Autonomous System number, set the connection status to an
internal
>    connection; otherwise it is "external".
>
>> - 54 - consensus, I'll accept Tom's comments and put in comment
below
>>         in section 8.1.3
>
>Also, here I don't have Tom's comments in the log.  Do we have text
for this?
>
>> Please consider these items closed.
>>
>
><< snipped >>
>
>> issue 52
>> --------
>>
>> 8.2.1.3  FSM and Optional Attributes
>> .sp
>> .in4
>> Optional Attributes specify either flags that augment the normal
>> processing of the BGP FSM, or optional timers.  If a Optional
>> attribute can be set on a system, the Events and the BGP FSM
actions
>> must be support.  For example, if the following options can
>> be set in a BGP implementation: AutoStart and Passive TCP
connection
>> Establishment flag, then the events 3, 4 and 5 must be supported.
>> .sp
>> .in 4
>> If an Optional attribute is cannot be set (that is declared always
off
>                           ^^ --> typo??
>
>Updated the issue, without the "is" above.
>
>> logically), the events supporting that set of options do not
>> have to be supported.
>
>Andrew

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 26 Feb 2003 08:15:46 -0500

Andrew:

Please note that issue 54 was included below, but
mis-numbered as 52.  I will be sending the draft
FSM text to Yakov once I get your final list.

Sue Hares

> From: 	Susan Hares  
> Sent:	Tuesday, February 25, 2003 5:59 PM
> To:	[email-masked]'
> Cc:	[email-masked]'
> Subject:	Open FSM issues
> 
> 
> 	- 26 - consensus, I added a new event per Siva request, see text below
> 	- 45 - Event 18 (due to issue 26) in Connect State - I accept Tom's solution and
> 	- 54 - consensus, I'll accept Tom's comments and put in comment below
> 	        in section 8.1.3
> 
> Sue Hares
> ===============
> Event 26
> 	 Event 7: Automatic start with bgp_stop flap option set and passive
>              TCP establishment option set
> 
> 	   Definition: Local system automatically starts the 
> 		       BGP peer connection with peer oscillation
> 		       damping enabled and passive TCP establishment 
> 		       enabled.  The exact method of damping
> 		       persistent peer oscillations is left up to the
> 		       implementation, and is outside the scope of
> 		       this document.
>    
>               Status:     Optional, used only if the bgp peer has enabled 
> 		       bgp peer oscillation damping with following optional flags 
> 		       settings below.
> 
> 	   Optional 
> 	   attributes: 1) Perform automatic start flag SHOULD be set 
> 		       2) BGP stop_peer_flap flag SHOULD be set 
> 	
> 	I've re-ordered the Timer events to keep the text changes down
> 	to a minimum.
> 
> 	action 9 - connect retry timer
> 	action 10 - Hold Timer expires
> 	action 11 - Keepalive timer expires
> 	action 13 - Open Delay timer expires
> 	action 14 - Idle Hold timer expires     
> 
> 	All other events are incremented by 1
> 
> ==================
> 
> Issue 42
> 
> New text in optional section:
> 
> Next text in 
> 
>      If BGP message header checking detects an error [Event 21] or Open message
>      checking detects an error [Event 22] (see section 6.2), the
>      local system:
> 	- (optionally) If the Notification without OPen  flag is set
> 	   and sends a NOTIFICATION message with the appropriate error code,
> 	- resets the connect retry timer (sets to zero),
> 	- releases all BGP resources,
> 	- drops the TCP connection,
> 	- increments the ConnectRetryCnt (connect retry count) by 1,
> 	- [optionally] performs peer oscillation damping,
> 	- and goes to Idle.
> 
> ===========
> Issue 44
> 
>      If a NOTIFICATION message is received with a version 
>      error[Event24], the local system checks the Open Delay timer.
>      If the Open Delay timer is running, the local system: 
>         - resets the connect retry timer (sets to zero), 
> 	- stops and reset the Open Delay timer (sets to zero, 
>         - releases all BGP resources, 
>         - drops the TCP connection,
>         - changes its state to Idle.
>      If the Open Delay timer is not running, the local system:
> 	- resets the connect retry timer (sets to zero),
>         - releases all BGP resources, 
>         - drops the TCP connection,
>         - increments the ConnectRetryCnt (connect retry count) by 1,
>         - optionally performs peer oscillation damping, and
>         - changes its state to Idle.> 
>  
> ------------
> issue 45 text
>  
>      If the TCP connection fails [Event18], the local system checks
>      the Open Delay Timer.  If the Open Delay timer is running,
>      the local system: 
>          - restarts the connect retry timer, 
> 	 - stops the Open Delay timer and resets value to zero,
>          - continues to listen for a connection that may be 
>            initiated by the remote BGP peer, and
>          - changes its state to Active. 
>      If the open Delay timer is not running, the locla system:
> 	- resets the connect retry timer (sets to zero), and 
> 	- Drops the TCP connection,
> 	- Releases all BGP resources,
> 	- and goes to Idle State. 
> 
> 
> issue  [Susan Hares]  54 
> --------
> 
> attribute can be set on a system, the Events and the BGP FSM actions
> be set in a BGP implementation: AutoStart and Passive TCP connection
> If an Optional attribute is cannot be set (that is declared always off

---

From: "Sivananda Ramnath - CTD, Chennai." <[email-masked]>
Date: Wed, 26 Feb 2003 23:22:32 +0530

Hello,

> 		 send the Notification based on a new 

     I don't think this should be optional. When we are in the Connect/Open
Sent state with OpenDelay timer running and we identify problems with the
OPEN message tat is received, a NOTIFICATION must be sent to the peer to
indicate the problem. Failing this may cause connect loops in some
circumstances such as version errors.

Siva
([email-masked])