Re: FSM changes for the Draft-15
andrewl@exodus.net Thu, 08 November 2001 23:44 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 SAA04898 for <idr-archive@nic.merit.edu>; Thu, 8 Nov 2001 18:44:59 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 88F7691258; Thu, 8 Nov 2001 18:44:35 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CCB89125C; Thu, 8 Nov 2001 18:44: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 6F1EC91258 for <idr@trapdoor.merit.edu>; Thu, 8 Nov 2001 18:44:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 43EB25DDB9; Thu, 8 Nov 2001 18:44:34 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from demiurge.exodus.net (unknown [216.32.171.172]) by segue.merit.edu (Postfix) with ESMTP id B675D5DD98 for <idr@merit.edu>; Thu, 8 Nov 2001 18:44:33 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id PAA05891; Thu, 8 Nov 2001 15:41:50 -0800 (PST)
Date: Thu, 08 Nov 2001 15:41:50 -0800
From: andrewl@exodus.net
To: Susan Hares <skh@nexthop.com>
Cc: idr@merit.edu, jeffrey Haas <jhaas@nexthop.com>, Yakov Rekhter <yakov@juniper.net>
Subject: Re: FSM changes for the Draft-15
Message-ID: <20011108154150.K20838@demiurge.exodus.net>
References: <5.0.0.25.0.20011107162314.01d39868@mail.nexthop.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.0.0.25.0.20011107162314.01d39868@mail.nexthop.com>; from skh@nexthop.com on Wed, Nov 07, 2001 at 04:33:54PM -0500
Sender: owner-idr@merit.edu
Precedence: bulk
> At the last IDR meeting in London, John Scudder proposed that > we cut the State machine. I objected to this removal since "no state machine" > means interoperability problems between BGP implementations. > If router vendor A changes their implementation (or puts a bug) in the state > machine there is no "standard" to hold them to. > > I would like to first ask the working group if they want to remove the > state machine or take fixes to the State machine. I really think we > should take fixes so we do not have interoperability issues. I agree that having a decription of the state machine in the protocol spec is desireable. Thank you for comming up with a more detailed version than is currently in Section 8. The description in Section 8 is sufficent for those who have extensive BGP experience, but your verion will make it much easier for people with less BGP experience to implement BGP. > I'd like 2nd to ask that the working group accepts this FSM rewrite. > > I've re-written the state machine to be a bit cleaner in text. > The Idle state had two sub-states so I cleaned this up by making each > of these states a different text (Idle and Idle Hold) Comments on the FSM: IdleHold: This state seems implicit in section 8 the way it is currently written (defining the exponential backoff timer in the case of an automatic start event), so making it explicit is a good idea. Active: > The start events (initiated by the system or operator) are ignored in the Active state. > [Note: Jeff Haas thinks that operators would want manual start to do something different.] Currently, if an operator wants to restart the ConnectRetry timer in an attempt to bring up a BGP session now, they shutdown/clear the session which transitions things back to idle, clears all the counters, and restarts the process. There is some overhead associated with this, but I think it is an acceptable solution, so leaving Active defined as it is, with starts ignored is fine. -------- I would suggest an additon: - In line with the current spec which states: "An implementation MAY impose a configurable upper bound on that time [the IdleHoldtimer]. Once the upper bound is reached, the speaker shall no longer automatically generate the Start event for the peer." Add something mentioning this configurable maximum, for example: IdleHoldtimer = 2**(ConnectRetryCnt)*60 If IdleHoldtimer > IdleHoldTimerMax; generate a syslog event (vendor specifc) Set KeepIdle flag Transition to IdleHold state Andrew
- Re: BGP MIB work Susan Hares
- Re: BGP MIB work Enke Chen
- BGP MIB work Susan Hares
- Re: FSM changes for the Draft-15 Alex Zinin
- Re: FSM changes for the Draft-15 Jeffrey Haas
- Re: FSM changes for the Draft-15 Jeffrey Haas
- Re: FSM changes for the Draft-15 andrewl
- Re: FSM changes for the Draft-15 Susan Hares
- Re: FSM changes for the Draft-15 Susan Hares
- Re: FSM changes for the Draft-15 Susan Hares
- Re: FSM changes for the Draft-15 Susan Hares
- Re: FSM changes for the Draft-15 Susan Hares
- Re: FSM changes for the Draft-15 Alex Zinin
- Re: FSM changes for the Draft-15 Alex Zinin
- Re: FSM changes for the Draft-15 andrewl
- Re: FSM changes for the Draft-15 Edward Crabbe
- Re: FSM changes for the Draft-15 Antal Sasvari
- Re: FSM changes for the Draft-15 Eric Gray
- Re: FSM changes for the Draft-15 David Ball
- Re: FSM changes for the Draft-15 Enke Chen
- Re: FSM changes for the Draft-15 Ben Black
- Re: FSM changes for the Draft-15 Yakov Rekhter
- Re: FSM changes for the Draft-15 Randy Bush
- FSM changes for the Draft-15 Susan Hares
- Re: AS-wide Unique BGP Identifier Enke Chen
- Re: AS-wide Unique BGP Identifier Enke Chen
- Re: IDR WG Last Call Susan Hares
- Re: IDR WG Last Call Enke Chen
- Re: IDR WG Last Call Susan Hares
- Re: IDR WG Last Call Jeffrey Haas
- Re: IDR WG Last Call Russ White
- Re: IDR WG Last Call Enke Chen
- Re: IDR WG Last Call Jeffrey Haas
- Re: IDR WG Last Call Enke Chen
- Re: IDR WG Last Call Enke Chen
- Re: IDR WG Last Call Enke Chen