Re: Comments on FSM

Alex Zinin <azinin@nexsi.com> Thu, 17 January 2002 02:46 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 VAA24655 for <idr-archive@nic.merit.edu>; Wed, 16 Jan 2002 21:46:42 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B1078912C4; Wed, 16 Jan 2002 21:45:35 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82838912C5; Wed, 16 Jan 2002 21:45:35 -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 78C36912C4 for <idr@trapdoor.merit.edu>; Wed, 16 Jan 2002 21:45:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 4BDF25DDB9; Wed, 16 Jan 2002 21:45:34 -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 1B7835DD8E for <idr@merit.edu>; Wed, 16 Jan 2002 21:45:34 -0500 (EST)
Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id 316FA3F6D; Wed, 16 Jan 2002 18:48:21 -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 SAA13301; Wed, 16 Jan 2002 18:44:44 -0800
Date: Wed, 16 Jan 2002 18:44:44 -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: <145212436838.20020116184444@nexsi.com>
To: Kunihiro Ishiguro <kunihiro@zebra.org>
Cc: idr@merit.edu, Susan Hares <skh@nexthop.com>
Subject: Re: Comments on FSM
In-Reply-To: <m2wuyhbxvd.wl@titanium.zebra.org>
References: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <87advfjcqi.wl@vaio.zebra.org> <5.0.0.25.0.20020116181115.03ea46f8@mail.nexthop.com> <195204309992.20020116162916@nexsi.com> <m2wuyhbxvd.wl@titanium.zebra.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-idr@merit.edu
Precedence: bulk

Kunihiro,

> Instead of IdleHold timer we should explicitly mention about Start
> timer.  It is already implicitly used in RFC1771.  It is almost same
> as IdleHold timer but hopefully does not have impact on current
> implementation.

Or just say that implementations may use internal mechanisms
to generate the Start event and encourage people to implement
exponential holddown.

> We don't need Keep Idle flag.  Instead of that just stop Start timer.
> This mechanism can be used not only exponential backoff but also
> administratively shutdown or maximum prefix overflow.  So let's keep
> it simple.

Agreed.

> In IdleHold state there is a description for local limit of
> IdleHoldTimer.

>>         Upon entering the Idle Hold state, if the IdleHoldTimer exceeds
>>         the local limit the "Keep Idle" flag is set.

> This should be clearly defined.  For example StartTimer Ceiling.

Not sure if we even need this. See above.

> Difference between manual start and auto start is small.  I'm not sure
> separating Start event into Manual start event and Auto start event is
> good idea or not.

Yes, looks like it is the same event for FSM.
If so, it should be one event with two ways of generation.

> So my proposal is liek this.

> Status  : No new status
> Timer   : Start timer
> Variable: StartTimer
>           StartTimer Ceiling
>           Connect Retry Count

> (Possible addition
> Event   : Manual start
>           Auto start)

> IMHO, this topic needs more discussion and clarification.

>>Maybe the exponential backoff parts could be published as a separate draft
>>instead of including it in the base specification?

> I agrree with Greg.  A separate draft for exponential back off make
> sense.  I think even we have a separate draft for exponential back
> off, previous draft bgp4-16 FSM description still work fine with that.

No strong opinion on this.
If exponential back-off is optional and has been implemented
in some implementations, I think it can stay in the main spec.

Alex.