Re: Counter32 question

["C. M. Heard" <heard@pobox.com>]

On Mon, 8 Sep 2003, Tom Petch wrote:
Tom> Update messages are only valid in Established state which is
Tom> where the count is wanted (by a user like myself).  In any other
Tom> state except Idle, an Update message is an error and changes
Tom> state of a recipient to Idle.  In Idle state, Update messages
Tom> are ignored.

OK.

Tom> Established state can last a long time, like weeks or months but
Tom> can also last a very short time and get into oscillation, going
Tom> in and out rapidly, and this could be caused by excessive Update
Tom> messages, sent or received.  So a counter that is reset when
Tom> Established state is entered is exactly what I would like to
Tom> see.  Else the management station may have to poll the counter
Tom> rather often.

OK.

Tom> I appreciate counters are not reset; perhaps the 'right'
Tom> approach is to cache the current value in another object when
Tom> Established state was last entered.  Any other ideas?

Notice that a management application would still need a
discontinuity indicator in order to know whether to use the value
from its last poll or the cached value.

In view of this, a better long term fix would be to replace the
Counter32 objects with objects whose base type is Unsigned32.  The
objects would reset to zero on state transitions, but would behave
as counters at other times.  The discontinuity indicator would also
be needed here, but it would tell a management application to use
zero as the previous value instead of the value retrieved from the
previous poll.

On Mon, 8 Sep 2003, Jeffrey Haas replied:
Jeffrey> I think the "Right" idea in this case is simply to fix the
Jeffrey> text to get rid of the "set to zero" description (already
Jeffrey> done) and in the bgp mib v2 to put in the relevant
Jeffrey> discontinuity counter or one of the other options.
Jeffrey> 
Jeffrey> For now, document what is actually done.

I saw that in draft-ietf-idr-bgp4-mib-12.txt, and I agree, given
your previous comments

Jeffrey> Note that the counter essentially resets whenever we
Jeffrey> transition to the established state.
Jeffrey>
Jeffrey> Observation 1: Many implementations don't actually do this.
Jeffrey> Observation 2: Most people say they don't because counters
Jeffrey> are never supposed to reset.

and the fact that the objective of draft-ietf-idr-bgp4-mib-12.txt is
to capture the behaviour of deployed implementations.  Hence my use
of the phrase "long term fix" above.

Regards,

Mike Heard