Re: bgp4-17 Cease subcode

Alex Zinin <> Tue, 15 January 2002 22:02 UTC

Received: from ( []) by (8.9.3/8.9.1) with ESMTP id RAA10559 for <>; Tue, 15 Jan 2002 17:02:01 -0500 (EST)
Received: by (Postfix) id 4DB7491279; Tue, 15 Jan 2002 17:00:54 -0500 (EST)
Received: by (Postfix, from userid 56) id 21A319127C; Tue, 15 Jan 2002 17:00:54 -0500 (EST)
Received: from ( []) by (Postfix) with ESMTP id 25AC991279 for <>; Tue, 15 Jan 2002 17:00:53 -0500 (EST)
Received: by (Postfix) id F17025DDB0; Tue, 15 Jan 2002 17:00:52 -0500 (EST)
Received: from ( []) by (Postfix) with ESMTP id BEE615DDA5 for <>; Tue, 15 Jan 2002 17:00:52 -0500 (EST)
Received: from (unknown []) by (Postfix) with ESMTP id 90BF93F6C; Tue, 15 Jan 2002 14:03:39 -0800 (PST)
Received: from ([]) by (8.9.3/8.9.3) with ESMTP id OAA14243; Tue, 15 Jan 2002 14:00:03 -0800
Date: Tue, 15 Jan 2002 14:00:01 -0800
From: Alex Zinin <>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <>
To: Susan Hares <>
Cc: Russ White <>, Eric Gray <>, Inter-Domain Routing Mailing List <>
Subject: Re: bgp4-17 Cease subcode
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk


> Now to the text:

> Fix to problem 1 -  FSM does not require you to implemented
> the hold off.

Does this mean IdleHold is removed?

> How about replacing this  following text at the IDLE State:

> =============

>  From this text:
>  >A manual start event is a start event initiated
>  >by an operator. An automatic start event is
>  >a start event generated by the system.

> The text can be: a manual event is intended to be
> a start event generated by "manual" intervention.  If the
> presistent flapping suppression option is not set,
> all start events will be manual start events.

The last sentence is too much, I guess.
Can we say that automatic Start event is generated
by the system to initiate the BGP connection procedure
and that it is recommended that persistent flapping
is accounted for and/or the text you give below?

FSM-wise, not describing the behavior when transitioning
from every state is not a problem if we specify actions
performed when FSM reaches a specific state (Idle in our
case). I'm working on such a version, will send out soon.

> How about re-adding this section at the bottom
> of the state machine?

> Manual versus Automatic start in the FSM

> If a BGP speaker detects an error, it shuts down the
> connection and changes its state to Idle-hold. Getting out

Shouldn't this be "Idle"?

BTW, regarding the collision detection, shouldn't the
session that lost the tie-breaker be destroyed rather
than being put in Idle/IdleHold?


> of the Idle state requires generation of the Start event.
> Such a start event can either be manual or automatic.

> If this start event is generated automatically, then
> persistent BGP errors may result in persistent flapping
> of the speaker.  To avoid such a condition it is
> recommended that the Start events should not be generated
> immediately for a peer that was previously transitioned
> to Idle due to an error.   For a peer that was previously
> transitioned to Idle due to an error, the time between
> consecutive generation of Start events, if such events are
> generated automatically, shall exponentially increase. The
> value of the initial timer shall be 60 seconds. The time shall
> be doubled for each consecutive retry.The formula for this
> expotential backoff is expressed in the formula:

>          IDLE hold time = 2**(connectRetryCnt)*60

> ----------------

> What do you think?

> Sue Hares