Re: bgp4-17 Cease subcode

Russ White <ruwhite@cisco.com> Fri, 18 January 2002 12:38 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 HAA18507 for <idr-archive@nic.merit.edu>; Fri, 18 Jan 2002 07:38:48 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A6ACF9130D; Fri, 18 Jan 2002 07:38:23 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63BBC9130E; Fri, 18 Jan 2002 07:38:23 -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 0CF449130D for <idr@trapdoor.merit.edu>; Fri, 18 Jan 2002 07:38:21 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D37DF5DE08; Fri, 18 Jan 2002 07:38:21 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 97FF45DDA3 for <idr@merit.edu>; Fri, 18 Jan 2002 07:38:21 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA24040; Fri, 18 Jan 2002 07:38:18 -0500 (EST)
Date: Fri, 18 Jan 2002 07:38:18 -0500
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Alex Zinin <azinin@nexsi.com>
Cc: Susan Hares <skh@nexthop.com>, randy Bush <randy@psg.com>, idr@merit.edu
Subject: Re: bgp4-17 Cease subcode
In-Reply-To: <40302627945.20020117194800@nexsi.com>
Message-ID: <Pine.GSO.4.21.0201180737010.23343-100000@ruwhite-u10.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-idr@merit.edu
Precedence: bulk

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

This would work (as I said before)....

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

But I prefer this, even if there isn't a commitment for a doc
(yet).

:-)

Russ

_____________________________
riw@cisco.com <>< Grace Alone