[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Counter32 question



>>>>> 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