Re: bgp4-17 Cease subcode

Alex Zinin <azinin@nexsi.com> Fri, 18 January 2002 05:52 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 AAA06412 for <idr-archive@nic.merit.edu>; Fri, 18 Jan 2002 00:52:03 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E07FC91306; Fri, 18 Jan 2002 00:51:42 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9DB291307; Fri, 18 Jan 2002 00:51:42 -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 BA79391306 for <idr@trapdoor.merit.edu>; Fri, 18 Jan 2002 00:51:41 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 932655DE19; Fri, 18 Jan 2002 00:51:41 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from mail.nexsi.com (unknown [66.35.212.41]) by segue.merit.edu (Postfix) with ESMTP id 33BEA5DDF4 for <idr@merit.edu>; Fri, 18 Jan 2002 00:51:41 -0500 (EST)
Received: from khonsu.sw.nexsi.com (cscovpn3.nexsi.com [172.16.213.3]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id VAA26514; Thu, 17 Jan 2002 21:50:22 -0800
Date: Thu, 17 Jan 2002 19:48:00 -0800
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <40302627945.20020117194800@nexsi.com>
To: Russ White <ruwhite@cisco.com>
Cc: Russ White <riw@cisco.com>, Susan Hares <skh@nexthop.com>, randy Bush <randy@psg.com>, idr@merit.edu
Subject: Re: bgp4-17 Cease subcode
In-Reply-To: <Pine.GSO.4.21.0201172220230.23005-100000@ruwhite-u10.cisco.com>
References: <Pine.GSO.4.21.0201172220230.23005-100000@ruwhite-u10.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-idr@merit.edu
Precedence: bulk

Russ:

> My primary question at this point isn't over leaving in text
> about somehow controlling flapping sessions, but whether or not
> we should say that exponential backup is the right way to do
> this. There might be more interesting ways that crop up in the
> future, so we should leave this open for thought, I think.

I thought about this as well, and it seemed to me that if
this feature was documented as optional, that would leave enough
flexibility for the implementers to either not use it at all
(this would also solve the question of whether the current
implementations that do not do so are RFC-compliant) or come up
with a different scheme that would solve the problem in another
way, and, at the same time, give some clue on one way of doing
this thing.

On the other hand, I think it would be equally good if the spec did
not spell out the details and we had another document discussing
the topic in detail... if we have such a commitment, of course ;-)

Alex.