Subject: Re: PerfHist-TC-MIB

From: Ken Chapman <[email-masked]>
Date: Wed, 27 May 1998 09:13:45 -0400

Kaj,
I have an issue with it.  I agree with the three TC, but there is one 
missing:  PerfDayCount.
It is quite different from PerfTotalCount; it starts at a specific time
each day an is the aggregate of the 96 15-minute interval in the subsequent
24-hour interval.
This is in support of the requirements specified in ANSI T1.231-1993,
clause 9.1.2.1 (Current day register and Recent day registers).
(I assume that the purpose of the MIB work is to support industry
standards!)
	Ken

At 06:55 PM 5/26/98 -0400, Kaj Tesink wrote:
>At 03:55 PM 5/26/98 -0400, Ken Chapman wrote:
>>Kaj,
>>What's the status of <draft-ietf-atommib-perfhistTC-01.txt>?
>>Is it dead?
>>	Ken
>
>has been quality reviewed which resulted in minor comments.
>i'm accommodating that now and will post in a few days
>
>kaj
>
>
>> 
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>_/                                                                      _/
>_/  Kaj Tesink                                                          _/
>_/  Bellcore                                                            _/
>_/  Business Internet Professional Services  vmail (732) 758-5254       _/
>_/  331 Newman Springs Rd.                   email [email-masked]  _/
>_/  Red Bank, NJ 07701                     faxmail (732) 758-2269       _/
>_/                                                                      _/
>_/  * NOTE AREA CODE CHANGE (908) --> (732) EFFECTIVE JUNE 1, 1997 *    _/
>_/                                                                      _/
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>
>

---

From: Rajesh Abbi <[email-masked]>
Date: Wed, 27 May 1998 11:23:28 -0400

Hi Kaj,

I agree with Ken about the need for a Day-Counter that is synchronized
with the time-of-day clock.  Also, there is presently no MIB object to
configure the start-of-day time (which is by default 00:00).

Also, it should be recommended that the 15-minute interval be aligned
to a 1/4 hour boundary wrt the time-of-day.

I am not sure I understand the concept of 'xyzValidIntervals' and
'xyzInvalidIntervals'.

I believe each interval MUST be marked Valid/Invalid.  Just specifying
total number of valid/invalid intervals will not do.  If an interface
has been UP and running over 24-hours but was placed out-of-service for
5-minutes in the last hour, what happens ?  The way I read the
description,
the 'xyzValidIntervals' will be reset to 0.

The present definition of 'xyzInvalidIntervals' identifies an 'invalid'
interval as one in which "no valid data is available".  What about
intervals
in which 'some' valid data is available ?

If the 'xyzValidIntervals' can potentially consist of 'valid' &
'invalid'
intervals, then it is named inappropriately.

I still believe that this problem should be addressed as follows:
o Have a 'xxxNumIntervals' for a table which indicates total number of
  intervals available.
o Have a 'xxxDataSuspect' flag in each interval to indicate if there was
a 
  problem with the data collection in that interval.  If 'no' data is
collected
  in an interval, it could return 'noSuchObject' error.

Rajesh
========================================================================
Rajesh Abbi
Alcatel Network Systems
2912 Wake Forest Road
Raleigh, NC 27609-7860
Phone: (919) 850-6194
Fax  : (919) 850-6670
Email: [email-masked]
========================================================================

---

From: Rajesh Abbi <[email-masked]>
Date: Wed, 27 May 1998 11:23:28 -0400

Hi Kaj,

Rajesh

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Wed, 27 May 1998 10:06:03 -0700 (PDT)

> (I assume that the purpose of the MIB work is to support industry

There are several things besides the Current day and Recent day registers
that are required by the ANSI performance monitoring standard T1.231 but
that are not in the IETF trunkmibs.  Some other notable ones are failure
counts, protection switching statictics, and (for SONET ADMs) pointer
justification statistics (this last was added in T1.231-1997).  Some or
all of these things would be good candidates for supplemental trunk MIBs,
which have in fact been proposed some time ago.  Why not put PerfDayCount
(and any other TCs needed to support the supplemental trunk MIBs) in a
Supplemental-PerfHist-TC-MIB?

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Wed, 27 May 1998 10:06:03 -0700 (PDT)

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: David Fowler <[email-masked]>
Date: Wed, 27 May 1998 17:36:06 -0400

> Why not put PerfDayCount

Exactly.  The trunk MIBs have taken forever to get out.  Let's get them done and
then add new things.

Regards,
David

--
-------------------------------
"I have nothing to declare --  but my genius"  -   Oscar Wilde

David Fowler
Newbridge Networks
613-591-3600

---

From: David Fowler <[email-masked]>
Date: Wed, 27 May 1998 17:36:06 -0400

Regards,
David

David Fowler
Newbridge Networks
613-591-3600

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 28 May 1998 09:11:51 -0400

>Exactly.  The trunk MIBs have taken forever to get out.  Let's get them done and

I agree with this. And one more point:

It would be questionable to define TCs that are not actually used in
any MIB module (to date). We can only stick in TCs in the current 
TC module that are used elsewhere or where we are very sure
that 
a) they will be used elsewhere within the foreseeable future
b) they are correct

Ken asked recently whether there is interest in a Supplemental
SONET/SDH MIB that would be a potential user of such TCs.
Is there any interest? Ken has some good stuff that can be leveraged.

And what about the Supplemental DS0/1/2/3 MIBs?

Kaj

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 28 May 1998 09:11:51 -0400

Kaj

---

From: Rajesh Abbi <[email-masked]>
Date: Wed, 27 May 1998 11:23:28 -0400

Hi Kaj,

Rajesh

---

From: Rajesh Abbi <[email-masked]>
Date: Wed, 27 May 1998 11:23:28 -0400

Hi Kaj,

Rajesh

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 28 May 1998 09:11:51 -0400

Kaj

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 28 May 1998 09:11:51 -0400

Kaj

---

From: Jeff Johnson <[email-masked]>
Date: Tue, 02 Jun 1998 16:15:55 -0700

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.

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?

thanks
/jeff

---

From: Jeff Johnson <[email-masked]>
Date: Tue, 02 Jun 1998 16:15:55 -0700

thanks
/jeff

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Tue, 2 Jun 1998 23:23:36 -0700 (PDT)

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

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

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Tue, 2 Jun 1998 23:23:36 -0700 (PDT)

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: Rajesh Abbi <[email-masked]>
Date: Wed, 03 Jun 1998 09:38:11 -0400

> 2^32 - 1 (i.e., would not roll over).  Isn't this what a Gauge32 object

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.

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

> Mike

Rajesh Abbi
Alcatel
[email-masked]

---

From: Rajesh Abbi <[email-masked]>
Date: Wed, 03 Jun 1998 09:38:11 -0400

Rajesh Abbi
Alcatel
[email-masked]

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 3 Jun 1998 09:14:01 -0700 (PDT)

> thus Counter32/Counter64 would have been a better representation. 

This is incorrect.  For each of these objects, its value in one interval 
can be smaller than its value in the preceeding interval.

Keith.

---

From: David Fowler <[email-masked]>
Date: Wed, 03 Jun 1998 13:05:47 -0400

> Jeff Johnson wrote:

> powered up.  (If I got this wrong, I'd sure like to know.)

When an agent starts up, it has no valid intervals.  It also has no invalid
intervals. The definition for valid intervals is the latest ds1 draft is:

"The number of previous near end intervals for which valid data was collected.
The value will be 96 unless the interface was brought online within the last 24
hours, in which case the value will be the number of complete 15 minute near end
intervals since the interface has been brought online.  In the case where the
agent is a proxy, it is possible that some intervals are unavailable.  In this
case, this interval is the maximum interval number for which valid data is
available."

The definition for invalid intervals from the same draft is "the number of
intervals for which no valid data is availab"

My intention in the creation of this object was to allow for the proxy case
discussed above.  That is, the number of invalid intervals would be the count of
"missing" intervals on a proxy.  Missing intervals occur when the proxy is out
of touch with the actual interface and is unable to collect some intervals.
With that meaning, my intention was that the number of invalid intervals could
never be equal to or greater than the number of valid intervals since the number
of valid intervals holds the maximum interval number for which there is valid
data.

For example, if the agent has been running for 12 hours, the number of valid
intervals would be 48.  If there was a communication disruption for one hour
during that time, then the number of invalid intervals would be 4.

All we really need to do is clarify that the number of invalid intervals must be
less than the number of valid intervals and that it is intended for the proxy
situation.

Regards,
David

--

David Fowler
Newbridge Networks
613-591-3600

---

From: Rajesh Abbi <[email-masked]>
Date: Wed, 03 Jun 1998 13:46:00 -0400

> can be smaller than its value in the preceeding interval.

These objects have a lifetime of 15-minutes.  During their lifetime
their
value is certainly 'monotonically increasing' !  After the interval is
over,
the current counter starts again - ie: a new instance is created.

Regarding Interval Counters - each interval is a 'separate instance' of
the
object.  The value in all 'historic' intervals (except the current one)
is
fixed - neither increasing nor decreasing.

Rajesh

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 3 Jun 1998 09:14:01 -0700 (PDT)

Keith.

---

From: David Fowler <[email-masked]>
Date: Wed, 03 Jun 1998 13:05:47 -0400

Regards,
David

--

David Fowler
Newbridge Networks
613-591-3600

---

From: Rajesh Abbi <[email-masked]>
Date: Wed, 03 Jun 1998 13:46:00 -0400

Rajesh

---

From: Jeff Johnson <[email-masked]>
Date: Wed, 03 Jun 1998 12:06:26 -0700

>2^32 - 1 (i.e., would not roll over).  Isn't this what a Gauge32 object

I think this is a moot point since if you're monitoring something that can
wrap in 15 minutes, your histogram will be skewed regardless of whether you
peg or wrap the count.  But I've received enough e-mail to convince me that
we should leave the syntax as Gauge32.  Do we need explicit text in the
description to say that means the PerfCurrentCount should not wrap if more
than 2^32-1 events occur during a 15 minute interval?

>powered up.  (If I got this wrong, I'd sure like to know.)

xyzValidIntervals + xyzInvalidIntervals may not equal the number of
intervals, mainly because xyzValidIntervals is a misnomer.  It is really
the index of the oldest valid interval.  Consider a box that has been
running for a long time, but where many intervals are invalid for whatever
reason.  If interval 1 and 96 is valid and intervals 2-95 are invalid,
xyzValidCount will be *96* and xyzInvalidCount will be 94.

/jeff

---

From: Jeff Johnson <[email-masked]>
Date: Wed, 03 Jun 1998 12:15:09 -0700

>The 'Perf***Count' objects are supposed to be 'monotonically increasing'

They are only monotonicially increasing during a 15 minute interval, at
which time they reset to zero.  This prevents a Counter* type from being used.

>'draft-ietf-atommib-atmhist-00.txt' MIB.

Keep in mind that the origin of the Perf Hist TC MIB is the three trunk
mibs (SONET, DS1, and DS3).  These definitions were factored out since they
were common to all three mibs, and so that others could use them as well.
I would love to make changes to the valid/invalid stuff, but it is
impossible to do so without affecting implementations of the trunk mibs.
In other words, there isn't a whole lot of modification that can be made to
this mib.

/jeff

---

From: Jeff Johnson <[email-masked]>
Date: Wed, 03 Jun 1998 12:15:09 -0700

/jeff

---

From: Jeff Johnson <[email-masked]>
Date: Wed, 03 Jun 1998 12:06:26 -0700

/jeff

---

From: [email-masked]
Date: Wed, 3 Jun 1998 14:40:46 -0700 (PDT)

> less than the number of valid intervals and that it is intended for the proxy

Let's go back to the example I gave earlier where the device has been
running more than 24 hours, but there was a communication disruption
whereby only intervals 1 and 96 were valid.  I think we can all agree
that according to the object description clauses that xyzValidIntervals
should be 96 and xyzInvalidIntervals should be 94.  Assuming the current
interval is "good", what should be the values of xyzValidIntervals and
xyzInvalidIntervals when the next 15 minute threshold is crossed (i.e.
intervals 1 and 2 are valid, intervals 3 through 96 are invalid).

/jeff

---

From: [email-masked]
Date: Wed, 3 Jun 1998 14:40:46 -0700 (PDT)

/jeff

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Thu, 4 Jun 1998 13:21:48 -0700 (PDT)

On Wed, 3 Jun 1998, Jeff Johnson wrote:
[ ... ]
> xyzValidCount will be *96* and xyzInvalidCount will be 94.

After carefully re-reading the description clauses for the various
xyzValidIntervals I see that this is the case.   However, the original

> are all invalid, or are there zero intervals?

The description of sonetMediumInvalidIntervals in the most recent SONET-MIB
(see <draft-ietf-atommib-sonetng-02.txt>) is

 "The number of intervals for which no valid data is available.
  This includes intervals of which valid data has been lost,
  e.g., due to restart of the agent."

It seems that the correct answer to this question is that there are zero
intervals, but based on this description I had concluded that the amswer
should be that there are 96 intervals, all invalid owing to the restart
of the agent.  So I think that a clarification is needed.  I would agree
with David Fowler's statement that

> All we really need to do is clarify that the number of invalid intervals must
> be less than the number of valid intervals and that it is intended for the
> proxy situation.

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Thu, 4 Jun 1998 13:21:48 -0700 (PDT)

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]