Re: bgp4-17 Cease subcode
Susan Hares <skh@nexthop.com> Thu, 17 January 2002 14:03 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 JAA10130 for <idr-archive@nic.merit.edu>; Thu, 17 Jan 2002 09:03:35 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 41D28912D5; Thu, 17 Jan 2002 09:03:06 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D458912D6; Thu, 17 Jan 2002 09:03:05 -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 C8E88912D5 for <idr@trapdoor.merit.edu>; Thu, 17 Jan 2002 09:03:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id ABF095DDDA; Thu, 17 Jan 2002 09:03:04 -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 91B1D5DD9E for <idr@merit.edu>; Thu, 17 Jan 2002 09:03:04 -0500 (EST)
Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0HE2b365387; Thu, 17 Jan 2002 09:02:37 -0500 (EST) (envelope-from skh@nexthop.com)
Message-Id: <5.0.0.25.0.20020117085203.0448ce08@mail.nexthop.com>
X-Sender: skh@mail.nexthop.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 17 Jan 2002 09:02:36 -0500
To: Alex Zinin <azinin@nexsi.com>
From: Susan Hares <skh@nexthop.com>
Subject: Re: bgp4-17 Cease subcode
Cc: Susan Hares <skh@nexthop.com>, Kunihiro Ishiguro <kunihiro@zebra.org>, Vincent Gillet <vgi@zoreil.com>, Yakov Rekhter <yakov@juniper.net>, Jeffrey Haas <jhaas@nexthop.com>, idr@merit.edu
In-Reply-To: <114185201786.20020116111047@nexsi.com>
References: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.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>
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
Alex: I think we need to query the people who operate the network about the problem this text was trying to solve. If the problem is still important, the problem will guide us in determining how this should be solved. The problem definition that the specification hints at is: a) automatic restarts of bgp sessions were being enabled on certain routers, b) the repeated OPENs were causing problems, c) People wanted to "recommend" (a strong word, but not as strong as must), it must have been important. If it is important, then is it important that all routers back off in the same way. The earlier specification wording would suggest that to be true. If not, it is not an inter-operability issue. If it is important, then it is important to know when your routers are in "back-off" state to operate the network. At this time, I'd like to hear from anyone who uses this function or had this problem. Sue At 11:10 AM 1/16/2002 -0800, Alex Zinin wrote: >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.
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Susan Hares
- Re: Comments on FSM Susan Hares
- Re: bgp4-17 Cease subcode Vincent Gillet
- Re: bgp4-17 Cease subcode Vincent Gillet
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: Comments on FSM Jeffrey Haas
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Kunihiro Ishiguro
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode andrewl
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Randy Bush
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: Comments on FSM Alex Zinin
- Re: bgp4-17 Cease subcode Randy Bush
- Re: Comments on FSM Kunihiro Ishiguro
- Comments on FSM Alex Zinin
- Re: bgp4-17 Cease subcode Enke Chen
- Re: bgp4-17 Cease subcode Greg Hankins
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Kunihiro Ishiguro
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Kunihiro Ishiguro
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Jeffrey Haas
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Alex Zinin
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Eric Gray
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Eric Gray
- Re: bgp4-17 Cease subcode Jeff Pickering
- Re: bgp4-17 Cease subcode Vincent Gillet
- Re: bgp4-17 Cease subcode Russ White
- Re: bgp4-17 Cease subcode Susan Hares
- Re: bgp4-17 Cease subcode Yakov Rekhter
- Re: bgp4-17 Cease subcode Jeffrey Haas
- Re: bgp4-17 Cease subcode Yakov Rekhter
- Re: bgp4-17 Cease subcode Tom Petch
- Re: bgp4-17 Cease subcode Yakov Rekhter
- bgp4-17 Cease subcode Tom Petch
- Re: processing order of reach/unreach in rfc2858b… Jeffrey Haas
- Re: processing order of reach/unreach in rfc2858b… Enke Chen