Subject: IdleHoldtimer = 2**(ConnectRetryCnt)*60

From: "Natale, Jonathan" <[email-masked]>
Date: Thu, 12 Sep 2002 11:39:30 -0400

In reference to:

"Upon entering the Idle Hold state, if the IdleHoldTimer exceeds
         the local limit the "Keep Idle" flag is set."

Need to add:
"The "Keep Idle" local limit MAY be configurable", the suggested default
value is 0."

And change:

"IdleHoldtimer = 2**(ConnectRetryCnt)*60"

TO

"IdleHoldtimer = (2**(ConnectRetryCnt) - 1)*60"

Since:
1) Currently, the "Keep Idle" local is not mentioned anywhere else.

2) The current "IdleHoldtimer = 2**(ConnectRetryCnt)*60" formula makes
automated testing difficult, and may lead to some delay in correcting
configuration errors if the remote side can not be reset ("Stop event
initiated by the operator").

3) ***Current implementations accept connections right away*** (this may be
due to a "bug" in which connections are accepted in Idle (???), but this may
be another discussion).

4) Another way of achieving this, instead of defaulting the "Keep Idle"
local limit to zero (but something else about "Keep Idle" local limit needs
to be added no matter what), is to set the ConnectRetryCnt to zero when a
CEASE NOTIFICATION message is received.  But if this is done, the
IdleHoldtimer = 2**(ConnectRetryCnt)*60 should still be changed to
IdleHoldtimer = (2**(ConnectRetryCnt) - 1)*60 .

5) Also, maybe the ConnectRetryCnt should be set to zero upon becoming
established???  This eliminates the need for 4) above.

---

From: Susan Hares <[email-masked]>
Date: Thu, 12 Sep 2002 19:55:07 -0400

Jonathan:

Thank-you for trying to review the right text.  But...
.. what version of the FSM words are you working on?
I have **no*** Idle Hold state in the text.   I have
no Idle Hold state.  I enclosed the words for you to review.

>"The "Keep Idle" local limit MAY be configurable", the suggested default

No text with this in it.

>1) Currently, the "Keep Idle" local is not mentioned anywhere else.

This text has been removed to the backoff draft or the state machine
draft.

>initiated by the operator").

Please send more details but reference the backoff-draft not the
main words.   I'm really interested in why you think this?  I may
be assuming something in my test cases.

>due to a "bug" in which connections are accepted in Idle (???), but this may

See the fact that implementations do accept connections right away
because they have the feature turned off.

>IdleHoldtimer = (2**(ConnectRetryCnt) - 1)*60 .

zero - meaning infinite time-out is a semantic that is worth
discussion in terms of the backoff draft.

I'd love to discuss zero versus infinite, but could you look at the
hares-backoff and hares-statemt draft.  We could get on the same
page with these new BGP specs.

Since this is not on the charter, we should ask if we should
take this discussion on-list or off-list.

>established???  This eliminates the need for 4) above.

I don't think so, because it doesn't prevent the original problem.

         step 1) get bad prefix
         step 2) dump the connection
         step 3) automatic restart the connection
         step 4) get established
         step 5) cycle back to step 5

Peers going up and down with 150K routes does not help router
performance.

Thanks again for taking the time to review the words.  But,
could you look at the words we are suggesting.

Sue