Re: FSM changes for the Draft-15

Antal Sasvari <Antal.Sasvari@eth.ericsson.se> Thu, 08 November 2001 15:50 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 KAA23464 for <idr-archive@nic.merit.edu>; Thu, 8 Nov 2001 10:50:50 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6BA4D91243; Thu, 8 Nov 2001 10:50:12 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 355A191249; Thu, 8 Nov 2001 10:50:12 -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 55D7991243 for <idr@trapdoor.merit.edu>; Thu, 8 Nov 2001 10:50:11 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 399FF5DD9E; Thu, 8 Nov 2001 10:50:11 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id ADE475DD97 for <idr@merit.edu>; Thu, 8 Nov 2001 10:50:05 -0500 (EST)
Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fA8Fo4C08304; Thu, 8 Nov 2001 16:50:04 +0100 (MET)
Received: from eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA28726; Thu, 8 Nov 2001 16:50:02 +0100 (MET)
Message-ID: <3BEAA99E.D225E145@eth.ericsson.se>
Date: Thu, 08 Nov 2001 16:49:50 +0100
From: Antal Sasvari <Antal.Sasvari@eth.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Gray <eric.gray@sandburst.com>
Cc: idr@merit.edu
Subject: Re: FSM changes for the Draft-15
References: <200111080348.fA83mD051359@merlot.juniper.net> <3BEAA487.7E90B139@sandburst.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-idr@merit.edu
Precedence: bulk

Eric,

I fully agree with you. I began to study BGP this summer, and I was a bit surprised,
how unclear the Decision Process, and some other parts are given in RFC 1771. Perhabs
people, who implemented BGP during the last years, know, what the text wants to say,
but I think the RFC should DEFINE the protocol, as clear as it is possible, so that
anyone will be able to create an implementation which interoperates with the others.

Antal


Eric Gray wrote:

> 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