Subject: <draft-ietf-disman-remops-mib-04.txt>

From: [email-masked]
Date: Wed, 2 Jun 1999 11:15:18 -0400 (EDT)

Hello again,

After reading <draft-ietf-disman-remops-mib-04.txt> at least twice,
here are my comments about the DISMAN-TRACEROUTE-MIB.

Section 3.2.1, Page 7
---------------------

before>  maximum number of concurrent requests that an agent
after>   maximum number of concurrent active requests that an agent

Section 3.2.2
-------------

third paragraph of this section (on page 7)

after>  delete the third paragraph, which discusses the third and fourth
        indices in the traceRouteCtlTable.  The traceRouteCtlTable does
        not appear to have 3 or 4 indices.

last paragraph of this section (on page 8)

before>   according the the values of each of the pingCtlStorageType objects.
after>    according to the values of each of the traceRouteCtlStorageType
          objects.

In the DISMAN-TRACEROUTE-MIB itself:
-----------------------------------

Renaming:

      traceRouteCtlHostAddressType  --->  traceRouteCtlTargetAddressType
      traceRouteCtlHostAddress      --->  traceRouteCtlTargetAddress

might clarify these slightly given the block diagram shown at the
top of page 4 in the draft.

Again, it's unclear to me why the second index in the traceRouteCtlTable
is an SnmpAdminString, instead of something that's easier to implement
and use or something more meaningful to the user like an IP address.

Would it make sense to add a traceRouteCtlDescr octet-string MIB object
to the traceRouteCtlTable simply to provide a user-documentation field?
I don't really care, but these documentation strings often are handy to
have.

As I mentioned in my comments about the DISMAN-PING-MIB, a number of
MIB objects that will only ever have 0 or positive values are of type 
Integer32, when Unsigned32 would be more semantically correct.  These 
object include:

     traceRouteMaxConcurrentRequests
     traceRouteCtlDataSize
     traceRouteCtlTimeOut
     traceRouteCtlProbesPerHop
     traceRouteCtlMaxTtl
     traceRouteCtlMaxTos
     traceRouteCtlMaxFailures
     traceRouteCtlInitialTtl
     traceRouteCtlMaxRows

As I mentioned in my comments about the DISMAN-PING-MIB, a number of
the integer values in the traceRouteCtlTable have subranges where the
justification for the subranges is unclear.  These include:

     traceRouteMaxConcurrentRequests
     traceRouteCtlTimeOut
     traceRouteCtlProbesPerHop
     traceRouteCtlMiscOptions
     traceRouteCtlMaxFailures
     traceRouteCtlMaxRows

Would it make sense to eliminate the subranges?

The function of the traceRouteCtlFrequency MIB object is a little unclear
to me.  Does this specify a "poll interval" at which the test is repeated
or the period between probe retries?

I believe that changing the traceRouteCtlTrapGeneration object from 
an INTEGER type to a BITS type would make it more versatile.

I believe the traceRouteProbeHistoryIndex in the 
traceRouteProbeHistoryTable could be eliminated.

I would suggest changing the compliance statements so the 
traceRoutePathChange notification is optional.  I would also suggest
making the traceRouteCtlIfIndex and traceRouteCtlMiscOptions objects
optional.

I would suggest the addition of another table to the DISMAN-TRACEROUTE-MIB.
Minimally, this table should maintain a list of IP addresses for the hops
discovered during a traceroute test.  It should maintain such a list for
at least two activations of the same traceRouteCtrEntry.

The justification of this is simple.  To implement the traceRoutePathChange
notification, the agent must keep a list of the IP addresses of all hops 
discovered by the previous (and current) traceroute tests.  When the current
traceroute test has finished, the agent must compare the total number of
hops, or must compare the IP addresses of each hop discovered by the current
and previous test, to determine whether or not the path has changed.   The 
agent must maintain this information to implement the notification.   Adding 
this suggested table will simply make the information that the agent requires 
to implement the traceRoutePathChange notification visible to the management 
station.

In this suggested table, I would further suggest that per-hop statistics
be kept like min/max/avg/sum-of-squares, etc.  This would be minimally
more difficult to implement but would allow the management station to
find the slow or problem links by scanning a table rather than having
to retrieve the traceRouteProbeHistoryTable and digest the information.
I believe this would add utility.

Here would be my suggestion about such a table (yes, I shamelessly cut-
and-pasted from the good work done on the DISMAN-PING-MIB):

   -- Traceroute Hop Results Table

   traceRouteHopsTable OBJECT-TYPE
      SYNTAX      SEQUENCE OF TraceRouteHopsEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Defines the Remote Operations Traceroute Hop Table for
           keeping track of the results from testing an individual
           path hop."
     ::= { traceRouteObjects 5 }

   traceRouteHopsEntry OBJECT-TYPE
      SYNTAX      TraceRouteHopsEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Defines an entry in the traceRouteHopsTable."
      INDEX {
              traceRouteCtlOwnerIndex,
              traceRouteCtlTestName
              traceRouteHopsTestNumber
              traceRouteHopsHopIndex
            }
      ::= { traceRouteHopsTable 1 }

   TraceRouteHopsEntry ::=
      SEQUENCE {
        traceRouteHopsTestNumber       Unsigned32,
        traceRouteHopsHopIndex         Unsigned32,
        traceRouteHopsIpHostAddress    IpHostAddress,
        traceRouteHopsMinRtt           Unsigned32,
        traceRouteHopsMaxRtt           Unsigned32,
        traceRouteHopsAverageRtt       Unsigned32,
        traceRouteHopsRttSumOfSquares  Unsigned32,
        traceRouteHopsProbesSent       Counter32,
        traceRouteHopsProbesResponses  Counter32,
        traceRouteHopsLastGoodProbe    DateAndTime
      }

   traceRouteHopsTestNumber OBJECT-TYPE
      SYNTAX      Unsigned32
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Specifies the number of this traceroute test.

           The next sequential number, starting with 1, is assigned to
           the traceRouteHopsTestNumber automatically by the agent 
           each time the corresponding traceRouteCtlEntry is activated."
      ::= { traceRouteHopsEntry 1 }

   traceRouteHopsHopIndex OBJECT-TYPE
      SYNTAX      Unsigned32 (1..255)
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Specifies the hop number to which this traceRouteHopsEntry
           applies."
      ::= { traceRouteHopsEntry 2 }

   traceRouteHopsIpHostAddress OBJECT-TYPE
      SYNTAX      IpHostAddress
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "This objects reports the IP address associated with the hop."
      ::= { traceRouteHopsEntry 3 }

   traceRouteHopsMinRtt OBJECT-TYPE
      SYNTAX      Unsigned32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The minimum traceroute round-trip-time (RTT) received for this
           hop.  A value of 0 for this object implies that no RTT has been 
           received."
      ::= { traceRouteHopsEntry 4 }

   traceRouteHopsMaxRtt OBJECT-TYPE
      SYNTAX      Unsigned32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The maximum traceroute round-trip-time (RTT) received for this
           hop.  A value of 0 for this object implies that no RTT has been 
           received."
      ::= { pingHopsEntry 5 }

    traceRouteHopsAverageRtt OBJECT-TYPE
      SYNTAX      Unsigned32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The current average traceroute round-trip-time (RTT) for this hop."
      ::= { traceRouteHopsEntry 6 }

    traceRouteHopsRttSumOfSquares OBJECT-TYPE
      SYNTAX      Unsigned32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "This object contains the sum of all traceroute responses received
           for this hop.  Its purpose is to enable standard deviation 
           calculation."
      ::= { traceRouteHopsEntry 7 }

    traceRouteHopsSentProbes OBJECT-TYPE
      SYNTAX      Counter32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The value of this object reflects the number of probes sent
           for this hop during this traceroute test."
      ::= { traceRouteHopsEntry 8 }

    traceRouteHopsProbeResponses OBJECT-TYPE
      SYNTAX      Counter32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "Number of responses received for this hop during this
           traceroute test."
      ::= { traceRouteHopsEntry 9 }

    traceRouteHopsLastGoodProbe OBJECT-TYPE
      SYNTAX      DateAndTime
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "Date and time was the last response was received for a probe
           for this hop during thhis traceroute test."
      ::= { pingHopsEntry 10 }

Adding this table to the DISMAN-TRACEROUTE-MIB would probably imply
that other objects should be added to the traceRouteCtlTable.  The
additions to the traceRouteCtlTable perhaps should specify how many
sets of test results should be kept in the hops table, and/or what
the current test number was.

What I'd really like to see is thresholding (or, even better, auto-
thresholding) so that when traceroute response during a periodic poll 
gets sluggish, a notification will be sent that pinpoints the hops at 
each end of the sluggish link.  Then I could (manually) do a DNS lookup 
on these IP addresses and call my ISP and tell them where to look for 
the problem.  But the thresholding and notification is probably better
implemented with the expression MIB.

Regards,
--Alan
 
 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 423 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 423 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.int.snmp.com/
 -----------------------------------------------------------------------------