[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Call for censensus on path forward
I like hearing the performance issues that you have raised.
I think that the Aggregate MIB proposals addresse the points that
you have mentioned in items 2 through 6 below. Namely, that of
retrieving valuse of any MOs (not necessarily in the same table)
There are actually two issues
1. specifying a group of objects and
2. fetching the values of a group of objects
In Aggregate MIB this is handled separately. One specifies (defines)
the Aggregate MO once and reuses it over and over again. That yields
Glenn M Keeni
Robert Moore wrote:
First the business part: I think the WG should focus on Wes's draft as the
base, and merge in any unique ideas (like logical filter expressions) from
Dave's draft. If we're going to muck with the PDU structure at all, then
we should try to do a reasonably complete job of it.
Regarding Wes's question about how rich to make filtering, I have what I
think is a logically prior question: can we do *any* filtering that will
really be useful? I'll construct a strawman argument that reaches the
conclusion that we can't, since I think it will be instructive for people
to say where they think the argument breaks down. Here it is:
1. Filtering is being introduced to solve the performance problem of having
to retrieve all the rows of a really big table (i.e., lots of rows, not
lots of columns), in order to get a relatively small number of rows that
we're really interested in. (My understanding of the requirement for
2. We want any filtering solution to work for tables in existing MIBs.
(Any eos solution that worked only for new MIBs wouldn't be very
3. Where filtering is really needed is when a management application needs
to poll the same table repeatedly, especially if the polling needs to be
4. Polling, especially if it's frequent, is interested in state data from a
table, not in configuration data that rarely changes.
5. A large percentage of the state data in existing MIBs is in the form of
counters. (Superficial examination - I haven't tried to compare with any
precision the mix of counters, gauges, and state enumerations in existing
6. A single value of a counter is meaningless - to derive any meaning from
a counter, you've got to take the delta of two values. (SNMP orthodoxy.)
7. A filter can only compare an asserted value to the single current value
of a MIB object. (Obvious.)
ERGO: A filtering solution cannot select table rows based on comparisons
with meaningful values of a large percentage of the state data in the rows.
If we want to achieve the effect of filtering on counter values, we need
some sort of Disman solution like the script MIB, rather than just a new
filter element in the SNMP PDU.
The discussion might proceed in either (or both!) of two directions here:
- Your argument is wrong, because one of the premises is wrong, or because
the logic itself is flawed.
- Your argument is correct, but it's still useful to pursue filtering
because even though they're rare, gauges and state enums are important
enough in existing MIBs to make it worthwhile to add a discrimination
capability that works only for them. If this is what we do, though, then
we'd better be very clear about what filtering can do, and what it can't
Glenn, I know this may be jumping the gun a bit, by diving down into a
technical discussion. But, hey, Wes did it first :-)
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group