Re: bgp4-17 Cease subcode

Alex Zinin <azinin@nexsi.com> Tue, 15 January 2002 22:02 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA10559 for <idr-archive@nic.merit.edu>; Tue, 15 Jan 2002 17:02:01 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4DB7491279; Tue, 15 Jan 2002 17:00:54 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21A319127C; Tue, 15 Jan 2002 17:00:54 -0500 (EST)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 25AC991279 for <idr@trapdoor.merit.edu>; Tue, 15 Jan 2002 17:00:53 -0500 (EST)
Received: by segue.merit.edu (Postfix) id F17025DDB0; Tue, 15 Jan 2002 17:00:52 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id BEE615DDA5 for <idr@merit.edu>; Tue, 15 Jan 2002 17:00:52 -0500 (EST)
Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id 90BF93F6C; Tue, 15 Jan 2002 14:03:39 -0800 (PST)
Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (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 <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <85108959926.20020115140001@nexsi.com>
To: Susan Hares <skh@nexthop.com>
Cc: Russ White <riw@cisco.com>, Eric Gray <eric.gray@sandburst.com>, Inter-Domain Routing Mailing List <idr@merit.edu>
Subject: Re: bgp4-17 Cease subcode
In-Reply-To: <5.0.0.25.0.20020115155854.04a7cd68@mail.nexthop.com>
References: <5.0.0.25.0.20020115144930.04a32a00@mail.nexthop.com> <5.0.0.25.0.20020115155854.04a7cd68@mail.nexthop.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idr@merit.edu
Precedence: bulk

Sue:

> 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:

> IDLE
> =============

>  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?

Alex.

> 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