Subject: Re: <draft-ietf-disman-remops-mib-03.txt> comments

From: [email-masked]
Date: Tue, 9 Feb 1999 21:58:28 -0500

Bob,

>>Scanning
>>pingResultsTable entries allows a management application to figure out
all
>>of what you mentioned. Aggregate information could be kept by adding some
>>pingEntry objects if that is the consensus. I think this would be a good
>>idea
>>if we expect that management appls would more likely never retrieve
>>pingResultsTable entries but would be satisfied with the aggregate
>>information
>>kept in an pingEntry.

>I'm confused.  I wasn't suggesting adding anything to pingEntry.  Are the
>entries in pingResultsTable one per message exchange?  I thought they were
>one per overall ping request.  The MIB definition isn't clear.

>It didn't occur to me that they'd be one per message exchange.  That seems
>to me it would create far, far too many entries.

First, if you look at the tables and read the descriptions:

 pingTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF PingEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Defines the Ping Table for provide, via SNMP,
        the capability of performing a ping operaton at
        a remote host.  The results of a ping operation
        are stored in the pingResultsTable."
   ::= { pingObjects 4 }

 pingEntry OBJECT-TYPE
    SYNTAX      PingEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Defines an entry in the pingTable."
    INDEX {
             pingOwnerIndex,
             pingHostAddress
           }
    ::= { pingTable 1 }

and then:

pingResultsTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF PingResultsEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Defines the Ping Results Table for
        storing the results of a ping operation."
   ::= { pingObjects 5 }

 pingResultsEntry OBJECT-TYPE
    SYNTAX      PingResultsEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Defines an entry in the pingResultsTable."
    INDEX {
             pingOwnerIndex,
             pingHostAddress,
             pingResultsProbeIndex
           }
    ::= { pingResultsTable 1 }

 PingResultsEntry ::=
    SEQUENCE {
        pingResultsProbeIndex    Integer32,
        pingResultsResponse      Integer32,
        pingResultsStatus        OperationResponseStatus,
        pingResultsLastReplyCode Integer32
    }

 pingResultsProbeIndex OBJECT-TYPE
    SYNTAX      Integer32 (1..15)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "An entry in this table is created when the results of
        a ping probe is determined.  The initial instance
        identifier value identifies the pingEntry
        that a probe result (pingResultsEntry) belongs
        to."
    ::= { pingResultsEntry 1 }

I think it is clear that one entry is keep per probe per ping operation.

I agree with Carl's later note that you need to see what the probes are
doing.

>>In general I have a problem with keeping aggregate information that can
be
>>replicated
>>by scanning subbordinate entries. The current MIB provides remote cmd
>>capabilities and
>>is not a general purpose availability tool. To do a true availability
tools
>>requires
>>much more that a few aggregate counters.

>I seem to be missing something.  This implies that the pingResultsTable is
>indeed one entry per message.  If I set up a ping of 1000 messages that's
>going to waste a lot of MIB space.

Take another look at the MIB. pingResultsProbeIndex has the range of from 1
to 15. The
actual range is based on pingProbeCount. Thus, unless we change the limits
there
can be a maximum of 15 probes per operation, not 1000.

Regards, Ken

---

From: Bob Stewart <[email-masked]>
Date: Wed, 10 Feb 1999 11:01:07 -0500

>First, if you look at the tables and read the descriptions:

I did that.  Again.

>I think it is clear that one entry is keep per probe per ping operation.

Clear to you, but it sure wasn't to me.  What I missed was the idea of
"probe" meaning a single message exchange.  I'm not familiar with that
terminology.  Is "probe" widely used in that way?  Am I the only one that
misunderstood this?

I was taking "probe" to mean a ping test, perhaps of multiple exchanges.
It simply did not occur to me at all that this would keep details of every
exchange.

>can be a maximum of 15 probes per operation, not 1000.

I guess I rushed my review a bit too much.  I didn't catch that, either.
Again, my preconceived notions were getting in the way.  In my limited
experience actually managing a network and looking for problems I'd often
to large quantity loop tests so as to get statistics over more than a few
messages.  Again I have to ask if I'm unusual in that regard.  Is the ping
test approach that's pretty strictly enforced by this MIB widely typical?

If I'm the odd man out, I'll back off.  If I'm not, the MIB needs to be
clarified and generalized for different styles of ping testing.

	Bob