Subject: [ifmib] Seperation of counters

From: "Irfan Lateef" <[email-masked]>
Date: Mon, 30 Jul 2001 13:25:17 -0400

Keith,

I am using RFC-2863 to collecting interface statistics and I
have to put them in 15-min bins.

I was wondering if you considered seperation of all counters
into a separate table and having 96 entries for this new table.

This would allow to have a better picture of the traffic over
the period of the day and not have duplicate entries for interface
characteristics.

There are a few advantages to this.

a. Correlation of the collected statistics with the lower level
performance counters which are in 15-min bins.
b. A PM strategy aligned with other transport mechanism like SONET etc.

I would appreciate your comments on this.

Thanks and Regards,

Irfan Lateef

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

_______________________________________________
ifmib mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/ifmib

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 30 Jul 2001 10:48:28 -0700 (PDT)

> into a separate table and having 96 entries for this new table.

That is an interesting request.

I am aware of at least one vendor of SONET transport gear who
was asked by a data customer to provide traditional SNMP
wrap-around counters for SONET PM data in lieu of the
15-minute interval counts specified in RFC 2558.  It would have
been relatively easy to do the interval counts (they were
supported for the traditional SONET TL1 management interface),
but the customer wanted the ability to customize the polling
schedules and interval durations.  Also much of their deployed
base of routers and such used traditional wraparound counters.

I guess you can't please all of the people all of the time no
matter what you do.

Mike

---

From: "Hanson, Gary" <[email-masked]>
Date: Mon, 30 Jul 2001 12:18:15 -0700 (PDT)

Mike,

In retrospect, (and with all due respect afforded those who struggled to
define what has already been defined) I believe the early SNMP community
was somewhat short-sighted in NOT anticipating the desire to have
arbitrary event counting statistics in BOTH running-statistics objects
(i.e., Counters) and intervaled-statistics objects (i.e., Gauges).  It
is now very apparent (painfully so) that some users want the former,
some want the latter, and some actually want both.

Had this realization been made early enough, the SNMP community could
have: (1) standardized on ALWAYS requiring arbitrary event counting
statistics to be defined using Counter-based objects; and (2) defined a 
generic MIB module (e.g., an "INTERVAL-STATS-MIB"), which would have
allowed intervaled-statistics objects to be "created" either dynamically
(by a manager) or statically (by the agent's vendor) for any arbitrary
running-statistics object or collection thereof.

[As an interesting historical note, the original MIB modules for DS1 and
DS3 lines defined the intervaled-statistics objects as Counters instead
of Gauges.  These Counter objects all had to be obsoleted (they had
actually been carefully expunged from later publications of the MIB
modules) and new Gauge objects had to be defined to replace them, so as
to avoid having discontinuities in Counter values every 15 minutes.  
Now THAT would have been a perfect time for the trunkmib WG to have made
this realization and to have sought a generic solution.]

This generic MIB module could have provided a table which related a
given Counter to a set of one or more intervaled-statistics objects, for
any arbitrary set of time durations (e.g., 1 second, 15-minutes, 24
hours, 7 days, 12 months, etc.), and provided all of the related
information necessary to fully instrument the intervals (e.g., time
elapsed within an interval, valid vs. invalid intervals, selection of
whether intervals are related to wall clock time or not, etc., etc.).

The generic table could have used simple cross-referencing techniques
comparable to those used in the alarmTable in the RMON-MIB in RFC 1757.
Details could have been developed by anyone skilled in the art.

The table could have thus provided a comprehensive and unified approach
to what has, instead, become a proliferation of different and often
inconsistent approaches to solving the problem of supporting intervaled-
statistics information in MIB modules.  I cite, as one example, the
differences between the approaches used by the trunkmib WG and the
atommib WG for the definition of MIBs for DS1 and DS3 on the one hand
and SONET on the other.  The two approaches deviate in several respects,
including: whether TimeElapsed objects are defined as 0..899 vs. 1..900;
whether a Totals table is defined or not; etc.

Unfortunately, many of the standard MIBs have long since been defined
with intervaled-statistics objects, and so the advantage to be gained
at present by defining a generic MIB as described above would be
significantly less than if it had been done at the outset.

However, it may STILL be worthwhile to define such a generic MIB, in
order to provide a generic way to solve this problem for future MIBs
(assuming more MIBs are still to be defined).  It might even allow us to
retrofit existing MIBs to use a generic approach by enhancing them with
running-statistics objects that could in turn make use of a standardized
generic MIB for representing the corresponding intervaled-statistics.

Regards,
Gary

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 30 Jul 2001 13:09:50 -0700 (PDT)

> running-statistics object or collection thereof.

I agree with this completely.  At one time Ken Chapman was working on a
proposal along these lines for a set of supplemental trunk MIBs;  the
motivation was to provide the 1-day counts which are in ANSI, Telcordia,
and ITU standards but are not supported by the trunk mibs.  I don't know
what became of that work.

Mike

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 30 Jul 2001 14:30:36 -0700

HI,

I'm not convinced that the interval storage is actually used in any
useful and powerful management applications. Does anyone have some
powerful examples of programs that depend on this approach to collecting
counts? The only example that I've seen where it is useful at the
CLI, where you would have no history if the storage intervals
didn't exist. But on a management platform, in the code that I've
designed, it is way easier to use straight counters instead of
the intervals.

Regards,
/david t. perkins