Subject: Re: 15 Minute Counts and Continuous Counts

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Sun, 7 Feb 1999 15:10:58 -0800 (PST)

Kaj Tesink <[email-masked]> wrote:

> During the Last Call process on the DS1/E1, DS3/E3 and SONET/SDH MIB I-Ds
> a comment was reiterated on whether the statistics in these MIBs can be
> represented through Counter32s (continuous counts).
> They are now all Gauge32s based on 15 minute measurements.
> While recognizing that these MIBs have historically used the
> 15 minute bucket approach the question was asked whether additional work
> on supplemental MIB(s) would be merited  that would use Counter32s.
>
> The purpose of this message is to sollicit views on this issue.
> In particular:
> a) whether Supplemental MIB modules should support Counter32 statistics
> b) if the answer to a) would be yes, whether the conformance statement
>    should mandate
>    i) both approaches
>    ii) either one of the approaches

Ken Chapman <[email-masked]> spoke up in favor of (a) and (ii),
and added:

> One further thought:  We should define a "generic" MIB for interval "gauges"
> that allows different intervals (e.g. 24 hours).  It would then be able to
> provide interval histories for ANY well defined counter.
> Perhaps someone has already done some work on such a MIB?

to which Keith McCloghrie <[email-masked]> replied:

> See the usrHistoryGroup in RFC 2021.

From time to time there has been discussion of a supplemental MIB to
support at least the required parts of ANSI T1.231 that are absent from
the current DS1, DS3, and SONET MIBs (herinafter collectively referred
to as trunk MIBs).

I agree with the idea that _if_ such a supplemental MIB is developed, it
should be based Counter32 statistics and should provide interval histories
via a mechanism similar to the RMON2 usrHistoryGroup in RFC 2021.  Deferring
for the moment the question of conformance statements, I would like to make
a couple of points about what this would require.

First of all, allow me to remind everyone that many of the quantities
which the current trunk MIBs count -- e.g., coding violations, errored
seconds, and severely errored seconds -- are subject to _inhibiting_.  In
particular, if an unavailable seconds count exists at a given layer, then
none of the other counts at that layer are incremented during unavailable
time (well, technically, failure counts and protection switching counts do
get incremented during unavailable time, but the trunk MIBs do not implement
those parameters).  Because of the peculiar way in which unavailable time
is defined, the time of entry into or exit from unavailable time is not
known for sure until 10 seconds after the fact.  Implementations are allowed
to increment the objects in the current trunk MIBs in real time and
retroactively adjust them downward when entry into/exit from unavailable
time becomes apparent.  This is fine for Gauge32 objects but _not_ for
Counter32 objects.  So an approach based on Counter32 objects would
_require_ an implementation to delay updates for 10 seconds (e.g. by using
the delay line approach described in the trunk MIB appendices).

Second, as Ken has pointed out to me in an earlier off-line discussion, the
RMON2 usrHistoryGroup can support recent and past interval registers, but
not current interval registers.  So to provide all of the missing parts
of T1.231 it would be necessary to devise an extension to the usrHistory
framework to provide current intervals.

As for conformance statements, I do not think it's a good idea to mandate
different ways to do the same thing and allow the implementation to choose
which.  That defeats the goal of interoperability.  There should be some
minimal common part that all implementations should be required to support.
It might, in fact, make sense to require only the Counter32 objects from
which the current and recent 15-minute and 1-day Gauge32 objects could be
derived, and make all the rest optional.  I could also live with making
the current objects and the new Counter32s mandatory (i.e. (b) (ii) above),
and all other history objects optional.

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

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 18 Feb 1999 15:57:35 +0000

OK, so let me summarize:

1.From previous atommib/trunk discussion we already concluded that
- there is a desire to create supplemental trunk mibs to cover 
  additional T1.231 functions

2.From the 15minCount/Continuous Count discussion the conclusion appears to be:
- we want Counter32 Statistics in addition to the completed 15min
  specs (several folks in favor)
- there are some serious issues as per Mike's comments given peculiar
  15min boundary behavior and object relationships
- we should benefit from RFC2021 as per Keith's comment; however
  as per Mike/Ken's points additions will be needed

3.On conformance there is not yet much clarity to me; I agree it is desirable
  to hae only one method of keeping statistics, but it is not clar to me
  how you can migrate cleanly from what we have now to some new situation.

Do I summarize this correctly?

Kaj

>and all other history objects optional.

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Bellcore
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
       Red Bank, NJ 07701
       USA

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Sun, 21 Feb 1999 11:36:10 -0800 (PST)

>   additional T1.231 functions

Agreed.

>   as per Mike/Ken's points additions will be needed

Agreed.

>   how you can migrate cleanly from what we have now to some new situation.

How well the recently approved trunk MIBs work out in the field should be
a prime consideration in how to deal with the conformance issue.  If folks
are happy with them, then there may not be a need to require anything else.
Perhaps the proper time to address that issue is when those MIBs come up for
advancement.

> Do I summarize this correctly?

I think so.

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