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

From: [email-masked]
Date: Tue, 8 Jun 1999 04:00:28 -0400

Hi,

>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

Updated.

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

Fixed.

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

Fixed.

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

Changed as indicated in my response to a similar suggestion with respect
to the ping MIB.

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

Same answer as before.

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

Agreed. Added as per my response to adding a pingCtlDescr object.

>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

Changed. I also changed traceRouteCtlPort, traceRouteCtlFrequency

>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

Removed as per Randy's comment.

>     traceRouteCtlTimeOut

The range is current 1 to 60 (seconds). Clearly there needs to be a timeout
value. I close seconds as the unit of measurement and think a minimum timeout
of 1 second is sufficient. The max timeout limit is more subjective. 60 seconds
seems a very very long time to me for waiting for a traceroute probe. I think
the current range for this object is correct.

>     traceRouteCtlProbesPerHop

The current range is 1 to 10. I would prefer leaving the range in but can be
convinced otherwise. I think its reasonable to limit the number of probes per
TTL value but won't argue to the death. Why would you want more than 10?
Less than 1 doesn't make sense.

>     traceRouteCtlMiscOptions

OK. It will take the SnmpAdminString default range of 0 to 255.

>     traceRouteCtlMaxFailures

The text for this object reads:

        "The value of this object indicates the maximum number
        of consecutive timeouts allowed before terminating
        a remote traceroute request.  A value of either 255 (maximum
        hop count/possible TTL value) or a 0 indicates that the
        function of terminating a remote traceroute request when a
        specific number of successive timeouts are detected is
        disabled."

A value greater than 255 is not legal. A value of 0 disables function,
hence the range of 0 to 255.

>     traceRouteCtlMaxRows

Removed.

>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?

Its the period between separate traceroute operations, not probe timeout.
I added a few sentences to the text to clarify.

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

OK.

>I believe the traceRouteProbeHistoryIndex in the
>traceRouteProbeHistoryTable could be eliminated.

I disagree. The indexes are currently:

             traceRouteCtlOwnerIndex,
             traceRouteCtlTestName,
             traceRouteProbeHistoryIndex,
             traceRouteProbeHistoryHopIndex,
             traceRouteProbeHistoryProbeIndex

Since the table can store the results of multiple traceroute tests the
historyIndex is required.

>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 changed the compliance statements so that all notifications are
optional.  For the rest how about:

        OBJECT traceRouteCtlIfIndex
        MIN-ACCESS  read-only
        DESCRIPTION
            "This object is not required by implementations that are not
            capable of selecting an interface to send IP packets over.
            When not supported disallow write access and return a 0 as
            the value of this object."

        OBJECT traceRouteCtlMiscOptions
        MIN-ACCESS  read-only
        DESCRIPTION
            "Support of this object is optional. When not supporting
            do not allow write access and return a zero length octet
            string as the value of the object."

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

I agree with your statements concerning what information would have to be
kept at the agent with respect to the traceRoutePathChange notification.
The usefulness of the table is proportional to how static the path is. My
guess would be that in most environments the path would not change that
frequently.  Unfortunately, I think this would reflect a major enhancement
to the MIB.  At the last working group meeting we where told by our area
director to finish the MIBs and stop making major changes. I can add the
table some what quickly but before doing so would like to see what Randy
says.

Regards, Ken