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

From: [email-masked]
Date: Wed, 13 Jan 1999 10:55:25 -0500

I received some good comments and suggestions from Karl Auerbach that
I want to bring to the attention of the working group prior to making any
MIB changes:

>>The ping responses information should be split so that there is a time
>>value and a "what happened" value.

>>That way one can express the fact that one got something like a host
>>unreachable at 34 milliseconds.

>>The way it is now you the time gets lost if the response is anything
other
>>than an ICMP Echo response.

>>I also note that there are many other responses you can get and which one
>>wants to differentiate:  One should be able to distinguish all the
various
>>kinds of ICMP xxx unreachable should.  TTL exceeded is also extremely
>>important to help notice routing loops.  In other words, all possible
ICMP
>>responses should be in the enumeration.

>Not sure if this is that simple. I was planning to add an entry to the
>pingResultsTable after determining the result: elapsed time on
>receiving the ICMP_ECHOREPLY or timing out.

>I could create a new object, pingResultsStatus, that basically provides
>a enumeration of the various states that the minus values (plus success
>of course) of the current pingResultsResponse. Add an object,
>pingResultsLastReplyCode, that could be used to contain the reply
icmp_type
>value. Then pingResultsResponse would be elapsed time for receiving
>last reply. Comments?

What I propose doing is add the following object:

      pingResultsStatus OBJECT-TYPE
         SYNTAX          INTEGER {
                                   responseReceived(1),
                                   unknown(2),
                                   internalError(3),
                                   requestTimedOut(4),
                                   unknownDestinationAddress(5),
                                   noRouteToTarget(6),
                                   interfaceInactiveToTarget(7),
                                   arpFailure(8)
                                 }
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
            "The result of the ping operation made by a remote host
            for a particular probe."
         ::= { pingResultsEntry 3 }

 pingResultsResponse would then be defined to contain response time in
milliseconds
 or 0. Then add:

      pingResultsLastReplyCode OBJECT-TYPE
         SYNTAX          Integer32
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
            "The last implementation method specific reply code received.
If the
            ICMP Echo capability is being used then a successful probe ends
when
            an ICMP response is received that contains the code
ICMP_ECHOREPLY (0)."
         ::= { pingResultsEntry 4 }

>>Also "no route" isn't completely sufficient to indicate failures that
>>could cause the packet to leave the initial box.  Things like "arp
>>failure" (or equivalent) can also occur.

I added arpFailure(7) to pingResultsStatus for this.

>>On the traceroute, I suggest adding two more parameter variables that I
>>have found useful in my own code:

>>   - A boolean to coerce the "Don't fragment bit" in the outgoing header.

>>   - A integer to set the initial TTL.

>>The first of these allows one to do a manual PATH MTU test.  (Assuming
>>that the response information is made more useful, more on that below.)

>>The second of these allows one to bypass tracing through the initial part
>>of the path -- which is often well known.

I think these would be useful so I would like to add the following objects:

       traceRouteDontFragment OBJECT-TYPE
          SYNTAX         TruthValue"
          MAX-ACCESS     read-create
          STATUS         current
          DESCRIPTION
             "This object enables setting of the don't fragment flag (DF)
             in the IP header for a probe."
          DEFVAL  { false }
          ::= { traceRouteEntry 17 }

        traceRouteInitialTtl OBJECT-TYPE
          SYNTAX         Integer32 (0..255)
          MAX-ACCESS     read-create
          STATUS         current
          DESCRIPTION
             "The value of this object specifies the initial TTL value to
use."
          ::= { traceRouteEntry 18 }

>>The traceroute responses, like those of PING need substantially more
>>information.  All possible ICMP responses (including the round-trip time
>>time) need to be noted.

I would like to change traceRouteResultsResponse to be just a time value
and
add traceRouteResultsStatus and traceRouteResultsReplyCode objects.

>>Also, the TTL of the incoming ICMP TTL exceeded packet needs to be
>>recorded somewhere as it indicates certain kinds of implementation
errors.

Any objections to adding a traceRouteResultsTtlExceeded object?

>>Going back to my prior note in which I mentioned that a number of people
>>have mis-implemented traceroute using ICMP Echo requests rather than UDP
>>packets: it might be useful to have a parameter which the agent can
>>implement which flavor it is using.  That way a manager can at least
learn
>>whether the agent does traceroute the right way or wrong way and can
>>interpret the results accordingly.

I don't think that adding an object or objects to the MIB(s) can handle
this
since I don't know how to develop a list of bad implementations.

>>As for the Ping part -- you should consider that there are also other
>>forms of "ping", such as UDP echo (port 7), and simple transactions (such
>>as doing an SNMP query), or a TCP connect attempt.  These latter forms
are
>>often much more useful than ICMP Echo Request/Reply because the ICMP
>>packets are often not answered (many routers don't honor Echo Requests)
or
>>they are handled at lower priority, hence possibly giving false
>>indications of round trip times.

I will add this to the text in section 1.

>>Also having a choice of data fill for the packet can be useful when links
>>are compressed or have data pattern sensitivities.

>>(I've found it a useful technique to run a spectrum of packet sizes
across
>>links in order to help determine what is an optimal packet size based on
>>the background error rate for the link.)

I would like to add the following object to address fill pattern, there
already is
an object for packet size:

        pingDataFill  OBJECT-TYPE
        SYNTAX      OCTET STRING(0..1024)
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
           "The content of this object is used together with the correspond
           pingPacketSize value to determine how to fill the data portion
           of a probe packet."
        DEFVAL { 0 }
        ::= { pingEntry 7 }.

>>As for traceroute -- you may want to mention that proper traceroute is
>>done using UDP packets to a (hopefully) unused port.  ICMP Echo
>>Request packets should *NOT* be used.  A lot of PC implementations do it
>>incorrectly, which, in turn, causes intermediate hops to be invisible
when
>>the router either refuses to send an ICMP TTL expired in response to an
>>incoming ICMP packet or simply tosses ICMP echo requests altogether.

I agreed to add this to the text in section 1. The description of
traceRoutePort does indicate that the port shouldn't be in use but I will
make this more explicit.

If there are no comments I plan to make these changes in a few days and
resubmit
the draft.

Ken