[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Counter32 question
HI,
I'm not so sure that the below is wrong or bad.
If the state diagram is something like:
--------- -------------
| states |--->established--->|more states|
--------- -------------
I'd say the below is OK. And I would also say that it would
be better to initialize the value to zero on instantation of the
instance, and not just on transition to the established state.
Why on instantation? Because it will not increment until after
the established state!
But if the semantics are different, then I "take back" the above.
Of course, I totally agree with Mike Heard below on the semantics
of counters. Of course there are subtlties. For example, consider
interface counters. If I pull out an interface card, then if
my implementation can keep all the counter values the same, and
continue where they left off when I insert the interface card
back into the system, then I say "no counter discontinuities".
The counter values just didn't increase while the interface
was removed.
On Thu, 4 Sep 2003, C. M. Heard wrote:
> >>>>> Jeffrey Haas wrote:
> JH> In the bgp MIB (which is past last call except for this one
> JH> point), we have a few objects like this:
> JH>
> JH> bgpPeerOutUpdates OBJECT-TYPE
> JH> SYNTAX Counter32
> JH> MAX-ACCESS read-only
> JH> STATUS current
> JH> DESCRIPTION
> JH> "The number of BGP UPDATE messages
> JH> transmitted on this connection. This
> JH> object should be initialized to zero (0)
> JH> when the connection is established. The
> JH> value of this object, when not in the
> JH> established state, is undefined."
> JH> ::= { bgpPeerEntry 11 }
> JH>
> JH> Note that the counter essentially resets whenever we transition
> JH> to the established state.
> JH>
> JH> Observation 1: Many implementations don't actually do this.
> JH> Observation 2: Most people say they don't because counters are
> JH> never supposed to reset.
> JH>
> JH> What's the veracity of 2? Do you have any suggestions?
>
> Indeed, counters are not supposed to reset, and our MIB review
> guidelines forbid DESCRIPTION clauses that are written like this.
> See <draft-ietf-ops-mib-review-guidelines-02.txt> sec. 4.6.1.2,
> and pay particular attention to this:
>
> - It is NOT OK to put in the DESCRIPTION clause of a Counter32/64
> that there is a requirement that on a discontinuity the counter
> MUST reset to zero or to any other specific value.
>
> and also to this:
>
> - It is OK to use Counter32/64 for counters that may/will be reset
> when the management subsystem is re-initialized or when other
> unusual/irregular events occur (e.g., counters maintained on a line
> card may be reset when the line card is reset). However, if it is
> possible for such other unusual/irregular events to occur, the
> DESCRIPTION clause MUST state that this is so and MUST describe
> those other unusual/irregular events in sufficient detail that it
> is possible for a management application to determine whether a
> reset has occurred since the last time the counter was polled. The
> RECOMMENDED way to do this is to provide a discontinuity indicator
> as described in RFC 2578 Sections 7.1.6 and 7.1.10. For an example
> of such a discontinuity indicator see the
> ifCounterDiscontinuityTime object in the IF-MIB [RFC2863].
>
> Now, if I guessed correctly, the document where these errant
> DESCRIPTION clauses appear is <draft-ietf-idr-bgp4-mib-11.txt> and
> the object whose definition is quoted above appears in the
> bgpPeerEntry conceptual row. If that's the case, then one possible
> solution (and probably the one I'd recommend if I were doing a MIB
> doctor review) would be to add a discontinuity time column to that
> conceptual row, e.g., bgpPeerCounterDiscontinuityTime. It could
> be of type TimeStamp and its description could say that the value of
> sysUptime is copied into it whenever the row is created or whenever
> there is a BGP state transition that might cause a counter
> discontinuity. The counter DESCRIPTON clauses could then state that
> the counters may suffer discontinuities at times indicated by this
> object. Look in RFC 2863 for appropriate language.
>
> In connection with this query Bert Wijnen said:
> BW> [added mibs mailing list for additional comments or input]
> BW>
> BW> Counters are NOT supposed to be reset. If/when they do get
> BW> reset, then we speak of a discontinuity. The idea is that these
> BW> counters do not have meaningfull information if you do a GET
> BW> once, You need to do two GETs with some interval, and then
> BW> the difference means something. If there is a discontinuity,
> BW> during the interval, then you know that you need to discard the
> BW> measurement during that interval.
>
> And the purpose of the discontinuity time object is to tell you if
> that happened. You poll the discontinuity time object along with
> the counters and if its value has changed since the previous poll,
> the counters may have suffered a discontinuity and any deltas are
> probably invalid.
>
> BW> We have so called ZeroBasedCounter32, but again, it is also
> BW> assumed to only start with zero only once. It is not supposed
> BW> to be reset to zero with every the connection gets
> BW> (re-)established.
> BW>
> BW> So if your connection gets established only once, then a
> BW> ZeroBasedCounter32 might be what you are looking for.
>
> ZeroBasedCounter32 was designed for the case when the conceptual row
> is created when a BGP connection is established and destroyed when
> the connection is cleared. It doesn't help much in other cases.
> In any case it seems to me that you would still need a TimeStamp
> object to tell you when a row was created.
>
> //cmh
Regards,
/david t. perkins