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

Re: Counter32 question



Well, no (to the state diagram).

Update messages are only valid in Established state which is where the
count is wanted (by a user like myself).  In any other state except
Idle, an Update message is an error and changes state of a recipient
to Idle.  In Idle state, Update messages are ignored.

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

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

Tom Petch

-----Original Message-----
From: David T. Perkins <dperkins@dsperkins.com>
To: C. M. Heard <heard@pobox.com>
Cc: Jeffrey Haas <jhaas@nexthop.com>; MIBs Mailing List
<mibs@ops.ietf.org>
Date: 08 September 2003 09:05
Subject: 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
>
>