Re: bgp4-17 Cease subcode

Susan Hares <skh@nexthop.com> Thu, 17 January 2002 15:27 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 KAA12650 for <idr-archive@nic.merit.edu>; Thu, 17 Jan 2002 10:27:59 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 51E26912E1; Thu, 17 Jan 2002 10:27:38 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D411912E2; Thu, 17 Jan 2002 10:27:38 -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 EF4C5912E1 for <idr@trapdoor.merit.edu>; Thu, 17 Jan 2002 10:27:36 -0500 (EST)
Received: by segue.merit.edu (Postfix) id BD99A5DDDA; Thu, 17 Jan 2002 10:27:36 -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 A6A3C5DD9E for <idr@merit.edu>; Thu, 17 Jan 2002 10:27:36 -0500 (EST)
Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0HFRD368104; Thu, 17 Jan 2002 10:27:13 -0500 (EST) (envelope-from skh@nexthop.com)
Message-Id: <5.0.0.25.0.20020117090856.025073e8@mail.nexthop.com>
X-Sender: skh@mail.nexthop.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 17 Jan 2002 10:27:12 -0500
To: ghankins@riverstonenet.com
From: Susan Hares <skh@nexthop.com>
Subject: Re: bgp4-17 Cease subcode
Cc: idr@merit.edu
In-Reply-To: <20020116190851.C6038@riverstonenet.com>
References: <114185201786.20020116111047@nexsi.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <114185201786.20020116111047@nexsi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-NextHop-MailScanner: Found to be clean
Sender: owner-idr@merit.edu
Precedence: bulk

Greg:

The real question is:

         1) Was persistent BGP peer flapping a problem?
         2) Do ISPs need to track why their peers are flapping?
         3) How is it really used?

If the feature is:

         - not needed - stay with 1st state machine
         - if needed, we'll find out why it is needed.

Sue


At 07:08 PM 1/16/2002 -0500, Greg Hankins wrote:
>On Wed, Jan 16, 2002 at 11:10:47AM -0800, Alex Zinin wrote:
> > Introduction of the IdleHold does change the FSM,
> > and I thought we wanted the spec to reflect the current
> > running code as much as possible.
>
>Agreed.  Changing the FSM at this point doesn't seem like it is worth the
>impact that this change would have on existing implementations, given that
>there are other implementation-dependant ways of doing the same thing.
>
>A change in the FSM would make every BGP implementation and every piece of
>documentation written on BGP outdated.  I'm not saying that this shouldn't
>be done if, there is a valid technical reason.
>
>Maybe the exponential backoff parts could be published as a separate draft
>instead of including it in the base specification?
>
>Greg
>
>--
>Greg Hankins <ghankins@riverstonenet.com> | Riverstone Networks, Inc.
>Corporate Systems Engineering             | 5200 Great America Parkway
>http://www.riverstonenet.com/             | Santa Clara, CA 95054
>+1 404 434 0355                           | +1 408 878 6500