IETF Logo Mail Archive

Re: FSM changes for the Draft-15

Eric Gray <eric.gray@sandburst.com> Thu, 08 November 2001 15:28 UTC

Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA22861 for <idr-archive@nic.merit.edu>; Thu, 8 Nov 2001 10:28:57 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 0037B912E3; Thu, 8 Nov 2001 10:28:11 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3C84912E4; Thu, 8 Nov 2001 10:28:10 -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 D2628912E3 for <idr@trapdoor.merit.edu>; Thu, 8 Nov 2001 10:28:09 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B15E45DDBD; Thu, 8 Nov 2001 10:28:09 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42]) by segue.merit.edu (Postfix) with ESMTP id 40B755DD9E for <idr@merit.edu>; Thu, 8 Nov 2001 10:28:09 -0500 (EST)
Message-ID: <3BEAA487.7E90B139@sandburst.com>
Date: Thu, 08 Nov 2001 10:28:07 -0500
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Yakov Rekhter <yakov@juniper.net>
Cc: Susan Hares <skh@nexthop.com>, idr@merit.edu
Subject: Re: FSM changes for the Draft-15
References: <200111080348.fA83mD051359@merlot.juniper.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-idr@merit.edu
Precedence: bulk

Yakov,

    I would MUCH rather hear them comment on the accuracy of the state
machine, than whether or not they need it in the specification.  As has been
established previously, many of those who are "BGP implementors" tend
to be satisfied with what is already in the specification while those who
would like to become "BGP implementors" are of a different mind.

You wrote:

> Sue,
>
> > 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 would especially encourage folks who are * BGP implementors* to comment
> on whether they feel they really need the state machine in the spec.
>
> Yakov.

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray

v2.23.0 | Report a Bug | By Email