Subject: RE: [ifmib] Re: Seperation of counters

From: "Chapman, Ken" <[email-masked]>
Date: Mon, 30 Jul 2001 16:32:06 -0400

There never seemed to be a lot of interest, so I never completed the work.
I still think that it is a good idea.  Any round toits out there?
	Ken

++++++++++++++++++++++++++++++++++++++++++++++
Ken Chapman           Unisphere Networks, Inc.
Tel: +1 978 589 0288  M/S 2056
Fax: +1 978 589 0800  10 Technology Park Drive
Email: KChapman       Westford, MA 01886
       @UnisphereNetworks.com
++++++++++++++++++++++++++++++++++++++++++++++

> -----Original Message-----
> From: C. M. Heard [mailto:[email-masked]]
> Sent: Monday, July 30, 2001 4:10 PM
> To: [email-masked]
> Subject: [ifmib] Re: Seperation of counters
> 
> 
> On Mon, 30 Jul 2001, Hanson, Gary wrote:
> > 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.
> 
> 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
> 
> 
> _______________________________________________
> ifmib mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/ifmib
> 

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

---

From: "Yongseok Park" <[email-masked]>
Date: Mon, 30 Jul 2001 18:05:33 -0400

Hi, 

I think we had better have an SNMP agent collect statistics regularly
from thousands of counters, make a file, compress it, and send it to
management applications later. This way, we don't have to depend on the
exhaustive and bursty SNMP GET polling, and achieve much less deviation
in collection times for a set of statistics. The interval size and
objects to be collected should be flexible for different sets of
statistics, e.g., 2 or 5 minutes for IP/MPLS related counters.

Thanks.

yongseok

> From: David T. Perkins [mailto:[email-masked]]
> Sent: Monday, July 30, 2001 5:31 PM
> To: [email-masked]
> Subject: Re: [ifmib] Re: Seperation of counters
> 
> 
> 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
> 
>

---

From: Michael MacFaden <[email-masked]>
Date: Tue, 31 Jul 2001 17:11:56 -0700

>From: "Irfan Lateef" <[email-masked]>
>
>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.

I would suggest you use RMON2 usrHistory (or possibly etherHist
from RMON I) for this.

It will be a vendor extension as to whether  this information is:

0) automatically configured 
1)  saved across reboots 
2) has enough capacity to statically store for all interfaces
to be monitored two ore more days worth of info which the RBOCs
typically request.

For those with sub-interfaces such as ATM and Frame Relay or 
whatever else that does not show up in ifTable, 
a new draft is making its way to draft status - CIRCUIT-IF-MIB:
  http://www.ietf.org/internet-drafts/draft-ietf-frnetmib-frsi-03.txt

Regards,
Mike MacFaden