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.
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Susan Hares
- Re: Comments on FSM Susan Hares
- Re: bgp4-17 Cease subcode Vincent Gillet
- Re: bgp4-17 Cease subcode Vincent Gillet
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: Comments on FSM Jeffrey Haas
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Kunihiro Ishiguro
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode andrewl
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Randy Bush
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: Comments on FSM Alex Zinin
- Re: bgp4-17 Cease subcode Randy Bush
- Re: Comments on FSM Kunihiro Ishiguro
- Comments on FSM Alex Zinin
- Re: bgp4-17 Cease subcode Enke Chen
- Re: bgp4-17 Cease subcode Greg Hankins
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Kunihiro Ishiguro
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Kunihiro Ishiguro
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Jeffrey Haas
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Eric Gray
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Eric Gray
- Re: bgp4-17 Cease subcode Jeff Pickering
- Re: bgp4-17 Cease subcode Vincent Gillet
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Yakov Rekhter
- Re: bgp4-17 Cease subcode Jeffrey Haas
- Re: bgp4-17 Cease subcode Yakov Rekhter
- Re: bgp4-17 Cease subcode Tom Petch
- Re: bgp4-17 Cease subcode Yakov Rekhter
- bgp4-17 Cease subcode Tom Petch
- Re: processing order of reach/unreach in rfc2858b… Jeffrey Haas
- Re: processing order of reach/unreach in rfc2858b… Enke Chen