Re: bgp4-17 Cease subcode

[Susan Hares <[e-mail]>]

Alex:

Thanks for the comments on the draft.  I think
I've got the fix for this in my current version.
I'm sending it off the list so we can talk.

Sue

At 11:34 AM 1/17/2002 -0800, Alex Zinin wrote:

>Sue,
>
> > 1) Thanks for your note.
>
> >    Glad you think the bgp exponential back off is good.
>
> >    We should get operator input to answer questions in #3.
> >    I want to go with whatever the operator community has
> >    deployed for this draft.
>
>OK.
>
> > 2) State machine text clean up was more than
> >     the Idle Hold state
>
> >   Just to let you know the FSM text was tighted up based on the
> >   word document with the diagram I sent out.  There were other
> >   inconsistencies in the FSM that I fixed based on the states
> >   not being consistent with this diagram.
>
>I understand, I meant the text about exp. back-off specifically
>should be all right.
>
> >   I will generate the state machine table without
> >   the idle hold state to indicate those differences first.
> >   [Warning - this plus the 2 other state machines you
> >   sent me to review will take me a while.  Warning -- day turnaround
> >   most likely]
>
>All right, thanks. I think I'll send my version out to the list
>today to get the feeling of what people think.
>
> > 3)bgp exponential back-off
>
>[stuff for SPs ;) ]
>
> > 4) comparing all your input --- still processing
>
> > I am plugging through the 2 versions of state
> > machine you sent.   Did you send me a review
> > of the diagram (word document) I'm attaching again.
>
> > I didn't find that even though you mentioned
> > you had done it.   Did I miss it?  That would
> > speed up this process since a 5 page form is quicker to
> > review and glance over.
>
>Sue, I've briefly gone through several states in
>the table and had some questions and bugs:
>
>Event 3 (IdleHold expired, value under ceiling): I think this
>         event should be ignored in Idle and higher
>
>Idle x 3: "FSM Error" is not an action, is it?
>
>Event 4: This event should be ignored in Idle and higher as well
>
>Connect x 7: There's no associated transport session yet,
>         the event should be ignored
>
>OpenSent x 8: Ignore here?
>
>Event 9: Should be Rcv TCP Connect & peer accepted
>
>Connect x 9: Why incoming connection resets the FSM here?
>
>OpenSent x 9: Ignore here?
>
>Event 10: Should be Rcv TCP Connect & peer rejected
>
>Connect x 10: Why incoming connection resets the FSM here?
>
>OpenSent x 10: Ignore here?
>
>Connect x 11: Hold timer is not running here, ignore?
>
>Idle x 12: Idle here?
>
>Connect x 12: Events from here down should be ignored?
>
>IdleHold x 22: Should it be ignored and stay in IdleHold?
>
>Idle x 23: Idle/Ignore here?
>
>And probably the major one: there's no event that causes
>OpenSent->OpenConfirmed transition... Here I stopped.
>You should probably take another look and see if the
>table is generated correctly.
>
>Thanks.
>
>Alex.