[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Call for censensus on path forward



                                                                                                               
                                                                                                               
                                                                                                               


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

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

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

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

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

Glenn, I know this may be jumping the gun a bit, by diving down into a
technical discussion.  But, hey, Wes did it first :-)

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com



                                                                                                                                       
                      Wes Hardaker                                                                                                     
                      <wes@hardakers.ne        To:       "Glenn Waters" <gww@nortelnetworks.com>                                       
                      t>                       cc:       eos@ops.ietf.org                                                              
                      Sent by:                 Subject:  Re: Call for censensus on path forward                                        
                      owner-eos@ops.iet                                                                                                
                      f.org                                                                                                            
                                                                                                                                       
                                                                                                                                       
                      09/20/2002 11:10                                                                                                 
                      AM                                                                                                               
                                                                                                                                       
                                                                                                                                       



>>>>> On Mon, 16 Sep 2002 10:51:32 -0400, "Glenn Waters"
<gww@nortelnetworks.com> said:

Glenn> The working group needs to come to consensus around which
Glenn> problems that should be solved and which of the solutions below
Glenn> best addresses those problems.
...
Glenn> I will announce the summary of the consensus call one week from
Glenn> today (Monday, September 23) *unless* there is still active
Glenn> discussion which would preclude being able to make a reasonable
Glenn> decision at that time.

The deadline is coming up rather fast, and I think we should be
hearing more voices of people that have read the drafts (authors
excluded, we know what you'd (we'd) vote for).  This WG greatly needs
to hear the opinions of interested parties if any work is to go
forward.

Personally, I've read all the drafts and there is good merit in all of
them.  Obviously, I'm biased toward the solution which I think is
right (mine, of course ;-) but all the drafts are well worth reading.

I decided personally to leave out logic expressions from the filtering
in my draft solely because I didn't want to complicate the agent
processing any further.  David Perkin's has logical expressions in his
draft (&& || ...) and I'm very interested in hearing whether people
think this is a good thing or a bad thing, as it's a question I've
been meaning to ask the WG but was waiting until after a direction was
picked.  (I'd add logical expressions in a different manner than David
did, but it's the concept I'm curious if people want or not.
Currently, my draft has an implicit AND operation on all filtering
components).

--
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry
Pratchett