Subject: Re: BGP Base Draft - Issue List v2.1 (Draft-19)

From: "Tom Petch" <[email-masked]>
Date: Wed, 29 Jan 2003 17:41:56 -0000

Comments in line
Tom Petch
[email-masked]

-----Original Message-----
From: Jeffrey Haas <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: 28 January 2003 22:29
Subject: Re: BGP Base Draft - Issue List v2.1 (Draft-19)

>> -------------------------------------------------------------------
---------
>> 45) Event 17 in the Connect state
>> -------------------------------------------------------------------
---------
>> Tom then proposed this text:
>>
>>        If the TCP connection fails[Event 17] and the Open Delay
>>        timer is running, the local system:
>>            - restarts the connect retry timer,
>>            - clears the Open Delay timer
>>            - continues to listen for a connection that may be
>>               initiated by the remote BGP peer, and
>>            - changes its state to Active.
>>
>>         If the TCP connection fails [Event17] and the Open Delay
>>         timer is not running, the local system:
>>              - drops the TCP connection,
>>              - releases all BGP resources,
>
>There are no resources to release while in the connect state.
>(Unless we're using this as shorthand for something else - I forget.)

I was unsure about this action.  It is present for Active state event
17 which is why I put it in, it does include sub-actions such as clear
Open Delay timer (not running), clear Connect Retry timer (could be
running) so I think it right to play safe and include it.
>
>>              - sets ConnectRetryCnt (the connect retry count) to
zero
>
>I'm forgetting if this action is consistant with everything else.
>I don't have a current copy of the FSM and I don't trust -18 to be
>current enough. :-)
>
>This said, why do we go to zero?  I could see not incrementing it
>and letting the normal decay process deal with it.  The same would
>apply for the above.

Again, I was unsure about this so put it in and waited for comment.  I
have a chart of 27 events and 6 states in which I have colored in the
connect retry and peer oscillation damping actions and it looks like
measles; I could not divine the underlying logic.  Incrementing the
connect retry count would make as much if not more sense to me.  (It
is zeroed for Manual Stop).

But the action '[optionally] perform peer oscillation damping' is yet
more erratic (eg for
event 10 - Hold Timer expired - it is performed exiting Connect,
Active,
Established but not Open Confirm or Open Sent) so I left it out.
Again, it might make more sense put it in.

>>              - resets the connect retry timer (sets to zero), and
>>              - goes to Idle state.
>
>Sounds otherwise good.
>
>
>--
>Jeff Haas
>NextHop Technologies