Re: PerfHist-TC-MIB

[Rajesh Abbi <[e-mail]>]

C. M. Heard/VVNET, Inc. wrote:
> 
> On Tue, 2 Jun 1998, Jeff Johnson wrote:
> 
> > I've been doing the IESG quality review on this document.  There are two
> > issues which I would like to get the list(s) feedback on.
> >
> > 1) Currently all three TCs have a syntax of Gauge32.  IMO this implies
> > certain semantics which the TCs and the underlying MIB objects do not
> > possess.  I'd prefer to see these all changed to Unsigned32.  Note that
> > Gauge32 and Unsigned32 are encoded identicially, so there would be no
> > change to the data on the wire.
> 
> I don't understand this.  I always thought that if more that 2^32 - 1 of
> the type of events counted by a PerfCurrentCount object occurred within
> a 15 minute interval, then that PerfCurrentCount would be "pegged" at
> 2^32 - 1 (i.e., would not roll over).  Isn't this what a Gauge32 object
> is supposed to do?
> 

The 'Perf***Count' objects are supposed to be 'monotonically increasing'
-
thus Counter32/Counter64 would have been a better representation. 
However,
Counters roll-over while Gauges do not, thus Gauge32 was adopted.  But
this
leads to the other problem now - Gauges may increase/decrease at will,
while 'Perf***Count' may not.

Since a new behavior must be defined, 'Perf***Count' may be defined in
one
of three ways:
o As a Counter32/Counter64 with the added restriction that the value
starts
  with 0 AND does NOT roll-over (ie: it gets pegged to the MAX).
o As a Gauge32 with the added restriction that the value starts from 0
AND
  is monotonically increasing.
o As an Unsigned32 which starts with 0 AND is monotonically increasing
AND
  which does not roll-over.  (NOTE that Unsigned32 definition is a
  raw integer with no behavior associated unlike Counters and Gauges)

I would prefer a definition based on Counters since it is more
intuitive.
But that may be too late now.

> >
> > 2) The xyzInvalidIntervals DESCRIPTION states simply "The number of
> > intervals for which no valid data is available."  When an agent which
> > supports 96 intervals is initially powered up, should the invalid interval
> > counter be 0 or 96?  In other words, are there initially 96 intervals which
> > are all invalid, or are there zero intervals?
> 
> My interpretation is that xyzValidIntervals + xyzInvalidIntervals always
> sums to the number of intervals which the agent supports.  This implies
> that an agent which supports 96 intervals should report a value of 0 for
> xyzValidIntervals and and a value of 96 for xyzInvalidIntervals when first
> powered up.  (If I got this wrong, I'd sure like to know.)
> 

The 'xyzValidIntervals' & 'xyzInvalidIntervals' are confusing and do not 
provide sufficient information.  In my earlier posting to the
mailing-list
(May 27) I had propsed using 'xyzNumIntervals' to reflect number of
entries
in the table, and each entry having a 'xyzDataSuspect' flag to indicate
if
data is 'valid' or 'invalid'.  This approach is also used in the
'draft-ietf-atommib-atmhist-00.txt' MIB.

> >
> > thanks
> > /jeff
> >
> 
> Mike
> --
> C. M. Heard/VVNET, Inc.
> [e-mail]

Rajesh Abbi
Alcatel
[e-mail]