Subject: Re: comments on draft-ietf-disman-remops-mib-04.txt (part 1)

From: [email-masked]
Date: Sat, 22 May 1999 12:09:51 -0400

Randy,

Thanks for the detailed review. Any comment that you don't see in the response
please
assume that the change will be made as you suggested in the next draft.

>|o   Using the udp echo port (7), if supported.

>|o   Timing an SNMP query.

>references should be added for these

For the first I added a reference to RFC 862. For the second do you have
something in mind?

>Page 3:

>|ping capability to know which method is being used. Different methods
>|will yield different response times since the protocol and resulting
>|processing will be different.  It is RECOMMENDED that the ping
>|capability defined within this memo be implemented using the ICMP Echo
>|Facility.

>Suggestion:
>    1) at a minimum, add an object which reports the kind of ping
>       implemented.  Suggestion OBJECT IDENTIFIER syntax, with a
>       value carved out for ICMP Echo.
>    2) more elaborate (probably overkill) would be to have a
>       read-create object in the control table, so different
>       tests could employ different mechanisms

This has come up several times in the past so its time to get it over
with. What I have added is the following:

      pingImplementationTypeDomains      OBJECT IDENTIFIER ::= { pingMIB 3 }

      pingIcmpEcho OBJECT-IDENTITY
         STATUS      current
         DESCRIPTION
             "Indicates that an implementation is using the InterNet
             Control Message Protocol (ICMP) 'ECHO' facility."
         ::= { pingImplementationTypeDomains 1 }

      pingUdpEcho OBJECT-IDENTITY
         STATUS      current
         DESCRIPTION
             "Indicates that an implementation is using the udp echo
             port (7)."
         REFERENCE
             "RFC 862, 'Echo Protocol'."
         ::= { pingImplementationTypeDomains 2 }

      pingSnmpQuery OBJECT-IDENTITY
         STATUS      current
         DESCRIPTION
             "Indicates that an implementation is an SNMP query to
             calculate a round trip time."
         ::= { pingImplementationTypeDomains 3 }

      pingTcpConnectionAttempt OBJECT-IDENTITY
         STATUS      current
         DESCRIPTION
             "Indicates that an implementation is attempting to
             connect to a TCP port in order to calculate a round
             trip time."
         ::= { pingImplementationTypeDomains 4 }

I then added a read-create object, pingCtlType, of the OBJECT IDENTIFIER
TEXTUAL CONVENTION to administer reporting/usage. I then added:

        OBJECT pingCtlType
        MIN-ACCESS  read-only
        DESCRIPTION
            "Write access is not required.  In addition, the only
            value that MUST be enabled for this object is
            pingIcmpEcho."

Does this now mean I need to add an IANA section and pull the above setting
out into a proposed IANA administered MIB?

>|Traceroute is usually implemented by transmitting a series of probe
>|packets with increasing time-to-live values.  A probe packet is a UDP
>|datagram encapsulated into an IP packet.  Each hop in a path to the
>|target (destination) host rejects the probe packet (probe's TTL too
>|small) until its time-to-live value becomes large enough for the probe
>|to be forwarded.  Some systems use icmp probes instead of udp ones to
>|implement traceroute.  In both cases traceroute relies on the probes
>|being rejected via an ICMP message to discover the hops taken along a

>something is missing in this sentence - the probe's rejection is
>detected upon receipt of an ICMP message...

Text added.

>|traceroute capability as defined within this memo MUST be done using UDP
>|packets to a (hopefully) unused port.  ICMP Echo Request packets MUST
>|NOT be used.  Many 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.

>Can we nail down the port number, e.g., udp echo?

The BSD version of traceroute uses 4096. This is what the defval for
traceRouteCtlPort is set to. I checked the IANA port assignment page and
saw that 4096 isn't reserved for traceroute. It looks like 33434 is. Are
there any objects to using 33434?  Hope not since I've already changed
the MIB!

>Page 6:
>|The contents of the pingCtlTable is preserved across reIPLs (Initial
>|Program Loads) of its agent according the the values of each of the
>|pingCtlStorageType objects.

>should the conformance material for this object permit implementations
>which only allow "volatile"?  (I think so, but don't have strong feelings
>on this.)

I agree that only "volatile" implementations should be allowed and have
change the MIB.

>Page 7:
>|An implementation of this MIB will remove the oldest entry in the
>|pingProbeHistoryTable to allow the addition of an new entry once the
>|number of rows in the pingProbeHistoryTable reaches the value specified
>|by pingCtlMaxRows.  Entries will be removed on the basis of oldest
>|pingProbeHistoryTime value first.

>How pingProbeHistoryIndex fits into this scheme needs to cleared up.
>As I read the current text, an implementation could assign values to
>pingProbeHistoryIndex more or less randomly and still conform to the
>specification.  This is probably not good.  The other thing that needs
>to be nailed down (with the current wording) is what happens when the
>clock runs backwards.  I suggest that both of these issues can be
>dealt with by saying that pingProbeHistoryIndex values for a given
>test are issued consecutively, starting at 1 and wrapping at 0xffffffff.

Agreed, text added.

>Presumably, when a test is started, any old entries for that test
>should be deleted first?

Don't think so.  I would prefer letting pingCtlMaxRows determine this.

>|A remote traceroute test is started by setting traceRouteCtlAdminStatus
>|to up(1).  The associating traceRouteCtlEntry MUST have been created and
>|its traceRouteCtlRowStatus set to active(1) prior to starting the test.

>Does this intend to say that the SET request for traceRoutCtlAdminStatus
>cannot be the same SET request as is used to set the RowStatus to active?

No.

>|An implementation of this MIB will remove the oldest entry in the
>|traceRouteProbeHistoryTable to allow the addition of an new entry once
>|the number of rows in the traceRouteProbeHistoryTable reaches the value
>|of traceRouteCtlMaxRows.  Entries will be removed on the basis of oldest
>|traceRouteProbeHistoryTime value first.

>  1) same issue regarding indexing as for ping history
>  2) especially for traceroute, it would be possible for multiple
>     entries' timestamps to have the same value, since this
>     data type's precision is one-tenth of a second.
>  3) this paragraph describes the behaviour of the table in terms
>     of an object which will not be present in systems that do
>     not support the traceRouteTimeStampGroup.  This is fishy.

Same fix as before.

>Page 9:
>|The index element lookupAddressType preceeds lookupAddress and specifies
>|the type of address for either performing a gethostbyname or a
>|gethostbyaddr call at a remote host.  The value of this index element
>|determines whether to invoke either the gethostbyname or the
>|gethostbyaddr operation.  Specification of a dnsName(2) implies that
>|gethostbyname should be called to return a numeric address.  Use of a
>|value of either ipv4(3) or ipv6(4) implies that a gethostbyaddr call
>|should occur to return the symbolic name of a remote host.

>Should explain what happens for
>    1) multi-homed hosts
>    2) hosts with multiple DNS names

For gethostbyaddr is pretty easy, just return the h_name ("official name of
the host") from the hostent struct that is returned.  For gethostbyname its
somewhat more complicated.  We could go with returning just the first
address pointed to by the h_addr_list in the hostent or I will have to created
a results table for addresses and have the whole list returned. If we did this
then for gethostbyaddr I would return the alias list as pointed to by h_aliases.
Suggestions?

>    3) DNS round-robin scenarios

Explain what you mean here.

>Page 12:
>|   pingMaxConcurrentRequests OBJECT-TYPE
>|      SYNTAX      Integer32 (1..100)
>|      MAX-ACCESS  read-write
>|      STATUS      current
>|      DESCRIPTION
>|         "The maximum number of concurrent active ping requests
>|         that are allowed within an agent implementation."
>|      DEFVAL { 10 }
>|      ::= { pingObjects 1 }

>I don't see any architectural reason to impose a limit of 100 in the
>MIB.  There may be reasonable implementation limits, but those are
>up to the implementations.

I have removed the range and changed the syntax to Unsigned32.

>Page 14:
>|   pingCtlHostAddress OBJECT-TYPE
>|      SYNTAX      HostAddress
>|      MAX-ACCESS  read-create
>|      STATUS      current
>|      DESCRIPTION
>|          "Specifies the host address to be used at a remote host for
>|          performing a ping operation.  The host address type is
>|          determined by its octet string length.  Refer to the
>|          definition of the TEXTUAL-CONVENTION HostAddress."
>|      ::= { pingCtlEntry 4 }

>Defval?  Must this be present for row activation?  What if it resolves
>to a broadcast or multicast address?

Yes. I've added the following:

     A value for this object MUST be set prior to transitioning
     its corresponding pingCtlEntry to active(1) via
     pingCtlRowStatus.

I have added invalidHostAddress(11) to the OperationResponseStatus TC.
Broadcast and multicast addresses are not supported.

>Page 15:
>|   pingCtlAdminStatus OBJECT-TYPE
>|      SYNTAX      INTEGER {
>|                            up(1),    -- test should be started
>|                            down(2)   -- test should be stop
>|                          }
>|      MAX-ACCESS  read-create
>|      STATUS      current
>|      DESCRIPTION
>|          "Reflects the desired state that a pingCtlEntry should be
>|          in:
>|
>|             up(1)    - Attempt to active the test as defined by
>|                        this pingCtlEntry.
>|             down(1)  - Deactivate the test as defined by this
>|                        pingCtlEntry.
>|
>|          Refer to the corresponding pingResultsOperStatus to
>|          determine the operational state of the test defined by
>|          this entry."
>|       DEFVAL { down }
>|      ::= { pingCtlEntry 8 }

>It sounds like "up" and "down" are really not the right labels for
>these values.

OK. I've change them to enabled and disabled.

>Page 16:
>|   pingCtlMaxRows OBJECT-TYPE
>|      SYNTAX      Integer32 (0..1500)
>|      MAX-ACCESS  read-create
>|      STATUS      current
>|      DESCRIPTION
>|          "The maximum number of entries allowed in the
>|          pingProbeHistoryTable.  An implementation of this
>|          MIB will remove the oldest entry in the
>|          pingProbeHistoryTable to allow the addition of an
>|          new entry once the number of rows in the
>|          pingProbeHistoryTable reaches this value.
>|          Entries will be removed on the basis of oldest
>|          pingProbeHistoryTime value first.
>|
>|          A value of 0 for this object disables creation of
>|          pingProbeHistoryTable entries."
>|      DEFVAL      { 50 }
>|      ::= { pingCtlEntry 11 }

>Since implementations are not required to have pingProbeHistoryTime,
>this DESCRIPTION needs to be fixed to only refer to the age of the
>rows.

OK.

>Page 18:
>|   pingCtlRowStatus OBJECT-TYPE

>What objects in row must have values for transition to active?

Just pingCtlHostAddress. Text added.

>Page 19:
>|   pingResultsOperStatus OBJECT-TYPE
>...
>|      SYNTAX      INTEGER {
>|                            up(1),    -- test is in progress
>|                            down(2)   -- test has stopped
>|                          }
>|      MAX-ACCESS  read-only
>|      STATUS      current
>|      DESCRIPTION
>|          "Reflects the operational state of an pingCtlEntry:
>|
>|             up(1)    - Test is active.
>|             down(1)  - Test has stopped."
>|      ::= { pingResultsEntry 1 }

>What good is this object?

In what way is activation of a test here different than starting or
stopping an interface?

>|   pingResultsMinRtt OBJECT-TYPE
>|   pingResultsMaxRtt OBJECT-TYPE
>|   pingResultsAverageRtt OBJECT-TYPE

>units?

Added a UNITS  clause specifying milliseconds.

>|    pingResultsProbeResponses OBJECT-TYPE
>units?

Added.

>Page 20:
>|    pingResultsSentProbes OBJECT-TYPE
>|      SYNTAX      Counter32
>|      MAX-ACCESS  read-only
>|      STATUS      current
>|      DESCRIPTION
>|          "The value of this object reflects the number of probes sent
>|          for the corresponding pingCtlEntry and pingResultsEntry."
>|      ::= { pingResultsEntry 7 }

>units?

Added

> ...is this zero-based, or is it an ordinary counter?

What do you mean by zero-based?

>|    pingResultsRttSumOfSquares OBJECT-TYPE
>|      SYNTAX      Unsigned32
>|      MAX-ACCESS  read-only
>|      STATUS      current
>|      DESCRIPTION
>|          "This object contains the sum of all ping responses received.
>|          Its purpose is to enable standard deviation calculation."
>|      ::= { pingResultsEntry 8 }

>units?

Added

> ...the description doesn't match the name

Fixed.

>|   pingResultsLastGoodProbe OBJECT-TYPE
>|      SYNTAX      DateAndTime
>|      MAX-ACCESS  read-only
>|      STATUS      current
>|      DESCRIPTION
>|          "Date and time was the last response was received for a probe."
>|      ::= { pingResultsEntry 9 }

>value if none?

How about NO SUCH OBJECT?

>|   pingProbeHistoryTable OBJECT-TYPE
>|      SYNTAX      SEQUENCE OF PingProbeHistoryEntry
>|      MAX-ACCESS  not-accessible
>|      STATUS      current
>|      DESCRIPTION
>|          "Defines a table for storing the results of a ping
>|          operation.  Entries in this table is limited by

>"Entries" -> "The number of entries for a given <owner,test> pair"

Ok. Does sound better.

>|   pingProbeHistoryIndex OBJECT-TYPE
>|      SYNTAX      Unsigned32 (1..'ffffffff'h)
>|      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 2 instance

>"is" -> "are"

Actually I changed results to result since its one entry per probe
result.

>|          identifier index values identifies the pingCtlEntry

>"identifies" -> "identify"

OK.

>|          that a probe result (pingProbeHistoryEntry) belongs
>|          to."
>|      ::= { pingProbeHistoryEntry 1 }

>are these index values carved out in any particular order?
>do they wrap?

As with a previous comment. Starts at 1 and increase in
order wrapping after exceeding max value.

>Page 22:

>|   pingProbeHistoryLastReplyCode 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)."

>Otherwise, what value will this have?

As defined in ip_icmp.h. I will add text.

---

From: Karl Auerbach <[email-masked]>
Date: Sat, 22 May 1999 09:49:19 -0700 (PDT)

> there any objects to using 33434?  Hope not since I've already changed

It is fairly important to be able to adjust the destination port -- nobody
can guarantee that 33434 will not be in use by some application on the
target host.  And if it is, the last hop won't necessarily be visible as
the packet would be gobbled up by the application rather than rejected
with the ICMP port unreachable as is typical when doing tracerouts.  (All
intermediate hops should get ICMP Time-Exceeded messages, but the last
typically gets an ICMP port unreachable, unless the port is actually
reachable because it is in use.)

Also, given some newer "caching" and L4 routing/switching devices, the
path taken by various packets will depend on the destination port number
(as well as on the TOS bits in the IP header.)  So having the ability to
look at per-port (and per-TOS setting) routing is something that is
becomming increasingly useful.

> >|gethostbyaddr call at a remote host.

I haven't been following the discussion on this, but I do hope that one
can control whether one is fetching an A record, an MX record, or
whatever.

And when one is trying to diagnose DNS problems, one typically wants to
know things like whether one passed through a CNAME record.

Also, is the gethostbyaddr() function stop when it hits the PTR record or
does it continue the resolution to make sure that it maps back to an set
of A records, at least one of which contains the initial IP address?

(Of course how DNS looks at any point is typically dependent on what
server one is pointing to for any particular query.  That's why it is
often interesting to do a query using a local resolver and then do it by
brute force by tracking down, non-recursivly, from the roots.)

> Explain what you mean here.

A lot of "caching" stuff in the net plays with DNS to distribute traffic
among a number of servers.  This can actually get pretty complicated when
we talk about some of boxes that revector traffic off to different DNS
servers depending on the IP source address.  (And the different DNS
servers would, in turn return results which are presumably topolologically
proximate to the querier.)

		--karl--