Re: FSM changes for the Draft-15

Susan Hares <skh@nexthop.com> Mon, 12 November 2001 16:23 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 LAA03980 for <idr-archive@nic.merit.edu>; Mon, 12 Nov 2001 11:23:59 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4780291263; Mon, 12 Nov 2001 11:23:37 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0890591277; Mon, 12 Nov 2001 11:23:36 -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 3B67091263 for <idr@trapdoor.merit.edu>; Mon, 12 Nov 2001 11:23:33 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 156AB5DDD8; Mon, 12 Nov 2001 11:23:33 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id C37685DD8F for <idr@merit.edu>; Mon, 12 Nov 2001 11:23:32 -0500 (EST)
Received: from skh.nexthop.com (gateway3bo.networktwo.net [206.88.0.53]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id fACG5ME13222; Mon, 12 Nov 2001 11:05:23 -0500 (EST) (envelope-from skh@nexthop.com)
Message-Id: <5.0.0.25.0.20011112105259.01dc1c90@mail.nexthop.com>
X-Sender: skh@mail.nexthop.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 12 Nov 2001 10:58:30 -0500
To: andrewl@exodus.net
From: Susan Hares <skh@nexthop.com>
Subject: Re: FSM changes for the Draft-15
Cc: Susan Hares <skh@nexthop.com>, idr@merit.edu, jeffrey Haas <jhaas@nexthop.com>, Yakov Rekhter <yakov@juniper.net>
In-Reply-To: <20011108154150.K20838@demiurge.exodus.net>
References: <5.0.0.25.0.20011107162314.01d39868@mail.nexthop.com> <5.0.0.25.0.20011107162314.01d39868@mail.nexthop.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-ECS-MailScanner: Found to be clean
Sender: owner-idr@merit.edu
Precedence: bulk

Andrew:

Thanks for your comments.



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

Thank you.   I suspect given the implementations I've seen some
implementors do needs this help.


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

glad you like it.




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

thanks for the input.

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


You are suggesting modifying this text:

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


         Upon entering the Idle Hold state, if  IdleHoldtimer > 
IdleHoldTimerMax, the local system
         should:
                 - generate a syslog event and
                 - set the "Keep Idle" flag.

Please confirm.

Sue