Re: bgp4-17 Cease subcode

[Enke Chen <[e-mail]>]

Yes, please do not introduce the IdleHold State at this stage of the
BGP deployment.  -- Enke

> Date: Wed, 16 Jan 2002 11:10:47 -0800
> From: Alex Zinin <[e-mail]>
> X-Mailer: The Bat! (v1.51) Personal
> Reply-To: Alex Zinin <[e-mail]>
> Organization: Nexsi Systems
> X-Priority: 3 (Normal)
> Message-ID: <[e-mail]>
> To: Susan Hares <[e-mail]>
> Cc: Kunihiro Ishiguro <[e-mail]>,
> 	Vincent Gillet <[e-mail]>, Yakov Rekhter <[e-mail]>,
> 	Jeffrey Haas <[e-mail]>, <[e-mail]>
> Subject: Re: bgp4-17 Cease subcode
> 
> 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.
> 
>