Re: bgp4-17 Cease subcode

Alex Zinin <azinin@nexsi.com> Wed, 16 January 2002 19:12 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 OAA12579 for <idr-archive@nic.merit.edu>; Wed, 16 Jan 2002 14:12:23 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 70CF49128E; Wed, 16 Jan 2002 14:11:43 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 407EA9128F; Wed, 16 Jan 2002 14:11:43 -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 4AC859128E for <idr@trapdoor.merit.edu>; Wed, 16 Jan 2002 14:11:42 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1D7CF5DDD9; Wed, 16 Jan 2002 14:11:42 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id DEABB5DDCA for <idr@merit.edu>; Wed, 16 Jan 2002 14:11:41 -0500 (EST)
Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id 2FF0C3F6C; Wed, 16 Jan 2002 11:14:29 -0800 (PST)
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 LAA07487; Wed, 16 Jan 2002 11:10:51 -0800
Date: Wed, 16 Jan 2002 11:10:47 -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: <114185201786.20020116111047@nexsi.com>
To: Susan Hares <skh@nexthop.com>
Cc: Kunihiro Ishiguro <kunihiro@zebra.org>, Vincent Gillet <vgi@zoreil.com>, Yakov Rekhter <yakov@juniper.net>, Jeffrey Haas <jhaas@nexthop.com>, idr@merit.edu
Subject: Re: bgp4-17 Cease subcode
In-Reply-To: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-idr@merit.edu
Precedence: bulk

Sue,

 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.
 
 I agree with Russ and Ishi---the new state does not
 seem to be necessary, instead it could be as easy
 as holding the session in Idle and giving clue on
 how to make the delay exponential. I don't think
 there's an interoperability issue if people decide
 to keep the session in Idle using different internal
 mechanisms.

 Regards,
 
-- 
Alex Zinin

Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote:

> Kunihiro:

> We are not changing the FSM so I would be surprised if the change
> was anything but modest. Usually specifications with "no big" deal get 
> interpreted differently.  Inter-operable code means you tie down the details.

> The comment was on the clarity of the specification.

> If you have a specific comment on the text of the state machine,
> can you propose the concerns you have as a revision to the text.

> Sue

> PS -- I just love last call on a draft...  It's when
>        everyone finally reads a new section  ;-)...


> At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote:
>> >> > Is the expoential backoff in the FSM in current implementations?
>> >>
>> >> I guess we are going to find this out as part of the implementation
>> >> report. And if it is not in (at least two) current implementations,
>> >> we'll take it out of the text.
>> >
>> >I implemented Cease subcode in zebra-0.92a but not exponential backoff.
>> >I checked that new subcode does not put other BGP stack in trouble
>> >(checked Cisco and Juniper).
>>
>>First of all, sorry for talking about specific implementation.  In
>>Zebra implementation we've implemented Cease subcode.  The code is in
>>CVS repository.  I'll prepare a release version for that.
>>
>>And also we've implemented exponetial backoff.  It is done without
>>introducing new FSM status.  It is not a big deal.  Just check a flag
>>in a few functions.


>>Exponential backoff is a good feature.  I can't understand why it
>>require change to FSM.