Re: bgp4-17 Cease subcode

[Alex Zinin <[e-mail]>]

Sue:

> Alex:

> I know you have been active on the mailing list.
> And you didn't read it before the last call on the FSM.

Well, I skimmed :)

> And this question was asked on the list because I
> wondered about it.

> ;-)... <giggle on>  --- I guess not even great people are
> perfect.  <giggle off>

> OK, now I've got 2 more against (4 total).  And 15-20 votes
> for it inside the draft.

> I'm sure your vote is a bit more specific.  :-)...

> Is the issue you want to pull exponential out of the draft?
> This is a change to the BGP specification.  This draft
> is about corrections not changes in functionality.

When I was writing the message below, I was hesitating between
leaving the FSM the way it is in -17 and saying any functionally
equivalent implementation is all right, and removing the new state
and encouraging people to "play" with the Idle state.

I inclined towards the second because the new state in the spec
would probably still raise the issue of whether current
implementations comply ("Hey, I never saw "IdleHold" when I
did "sho ip bgp", you guys are not RFC compliant!!!", blah, blah...)

> What do we do?

See my reply to your other message.

Alex.

> Sue Hares



> At 10:30 AM 1/15/2002 -0800, Alex Zinin wrote:

>>Russ, Eric,
>>
>>  I tend to agree here...
>>  I'm currently reviewing the FSM and the impression I'm
>>  getting is that we can go without the IdleHold state
>>  and say that implementations may/should use some local mechanisms
>>  to hold BGP sessions in the *Idle* state to avoid excessive
>>  session flapping. I think this will be simpler and will
>>  match current implementations better...
>>
>>--
>>Alex Zinin
>>