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