Re: bgp4-17 Cease subcode

[[e-mail]]

> 3)bgp exponential back-off

One operator's view:

The vendor we use for our peering and backbone boxes doesn't implement this 
feature.  However, we would like it.  What usually happens when we have a 
flapping BGP session, due to say, a bad circuit, is someone is forced to come in
and shut it down manually, then bring it back up at some point when the
circuit is stable again.  With exponential backoff the lengths of the 
retrys would rapidly get to the point where human intervention to shut
the session down manually would not be required.  And the box would still try to
bring up the session occasionally, eliminating the "Oops, I forgot to bring
that back up" problem.

As for the FSM, were we to have this feature we would demand a command from 
the vendor that would indicate what the status of the backoff is.  So when
we did a "sh ip bgp summ" we could see either that it was transitioned to
idle for x reason and it had y seconds/minutes/hours remaining.  The 
proposal to call that state "IdleHold" is a sound one.  Although if
it were called ("Idle - Hold Flag Set" or something that would be fine too.)
And yes, we would want both the state and the time remaining in the MIB.
Preferably, if the state were IdleHold, we would have a "try #, # of seconds
remaining, # of seconds in this retry interval.  Eg: BackoffAttemptNumber: 5
BackoffSecondsRemaining: 38 BackoffSecondsTotalThisAttempt: 960

And being the generally knob-happy types we operators are :), a max-backoff
value or the like would be good as an enhancement.

Andrew