Re: bgp4-17 Cease subcode

[Susan Hares <[e-mail]>]

Alex and Randy:

Let's go back to first principles here on the FSM?

1st)  The original text is below from draft-12.

    This explanation gives "flag" that has implications
    for the full state machine.   The definition of
    state machines that Alex proposes, is all inputs
    and all actions are determined by state machine in
    clear text.

2nd) Is the bug real?

    The text was fixing a " persistent bgp flapping"
    bug.  According to the text there is a
    state within a state with fairly vague
    descriptions.

The second question belongs to Randy, since he wears 2 hats (Operations
and Routing temp AD), was this a real problem?  Has it gone away?

1) At least one routing vendor doesn't implement it [cisco]
    and I know this vendor is utilized in BGP peering sessions
    in the network.

2) What was the operational concern this text implies?

If there is no operational issue and no operational usage,
return to the original FSM text and out the comments on
"hold down."

So, Randy and all other operators - Is the problem it describes real?
Does anyone need it?   Let's answer that question first.




Sue Hares

----------------------


           If a BGP speaker detects an error, it shuts down the connection
          and changes its state to Idle. Getting out of the Idle state
          requires generation of the Start event.  If such an event is
          generated automatically, then persistent BGP errors may result
          in persistent flapping of the speaker.  To avoid such a
          condition it is recommended that Start events should not be
          generated immediately for a peer that was previously
          transitioned to Idle due to an error. For a peer that was
          previously transitioned to Idle due to an error, the time



Expiration Date July 2001                                      [Page 31]





RFC DRAFT                                                   January 2001


          between consecutive generation of Start events, if such events
          are generated automatically, shall exponentially increase. The
          value of the initial timer shall be 60 seconds. The time shall
          be doubled for each consecutive retry.

          Any other event received in the Idle state is ignored.



At 11:10 AM 1/16/2002 -0800, you 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.