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

From: [email-masked]
Date: Tue, 1 Jun 1999 10:36:33 -0400

Randy,

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

>No, but there are some subtleties to using SNMP for response time
>calculations.

Much simpler then TCP connections attempts. Why is sending a SNMP get
request for sysObjectID complicated? The real problem would be timeouts
since an agent at the receiving end might not be started. Other then that
its most likely going APPL-UDP-IP- network - IP-UDP-APPL. The layers are
somewhat simplified. In some cases it would yield a more accurate
reflection of response time then a PING echo response flow.

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

>that's enough to make me happy

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

>instead of "enabled", I'd suggest "supported by an implementation".

OK.

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

>We need to say whether we're expecting IANA to handle future registrations
>beneath the pingImplementationTypeDomains arc, and, if so, what kind
>of approval process we envision.  I don't think that there's much value
>in setting up a registration authority for this; if folks need new ping
>types, they can always do so in their enterprise space.

I agree that IANA registration control is not needed. I will add some text
to the draft to this effect.

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

>Perhaps a couple words to this effect in the document?

OK. I have done this also for traceRouteCtlMaxRows.

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

>Then we need to clarify.

OK. How about:

   A single SNMP PDU can be used to create and start a remote traceroute test.
   Within the PDU traceRouteCtlHostAddress should be set to the target host's
   address (traceRouteCtlHostAddressType will default to ipv4(3)),
   traceRouteCtlAdminStatus to enabled(1), and traceRouteCtlRowStatus to
   createAndGo(4).

I will add the text for the ping MIB as well.

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

>I think Karl's comments addressed this.

OK.

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

>Does "prior to" include the case of "in the same SetRequest"?  We need
>to be really clear on this.

It doesn't have to be in the same set request (it can be). A value must
be set before a transition to activate(1) status is allowed.

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

>My point was that we should probably explain why a management system
>would take this object's value into account in evaluating data from the
>other columns of this row in this table.

I'm not sure how complicated the text needs to be. The thought was that
a single status object might not be enough. It might take time for
an implementation to stop a test after receiving the set request
for the adminStatus object. I have gotten into the practice of defining
status in this fashion.  In the case of the ping and traceroute MIBs
I think the practice of splitting the setting versus reporting the
status of would be useful but not critical.

>> > ...is this zero-based, or is it an ordinary counter?
>>
>> What do you mean by zero-based?

>Is the value of this counter meaningful on its own, or are only the
>differences between samples of interest?  I think the intent was that
>a single Get of this data would yield useful information.  That is not
>true of ordinary counters.

The Counter32 objects pingResultsSentProbes and pingResultsProbeResponses
complement each other. They can be sampled to determine for a particular
period how many probes where sent versus responses received. I am still
unsure what you are asking me to do here.

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

>possible, though I prefer '0000000000000000'H

I don't particular care so I will go with what you prefer.

Ken

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 3 Jun 1999 17:12:46 -0700 (PDT)

Hi -

> From: [email-masked]
> To: Randy Presuhn <[email-masked]>
> cc: [email-masked]
> Date: Tue, 1 Jun 1999 10:36:33 -0400
> Subject: Re: comments on draft-ietf-disman-remops-mib-04.txt (part 1)
...
> reflection of response time then a PING echo response flow.

Possibly.  What MIB objects are requested can affect the processing time.
Accounting for ARP, accounting for clock sync (if protocol is V3), and
request retransmissions by SNMP infrastructure (some manager-role APIs
do this) can all affect results.  Agent blocking due to a concurrent,
time-costly SET request from another manager can distort results.

I agree that one can use SNMP to make such measurements.  However,
just as the ping approach has its caveats, using SNMP to make the
measurements brings its own potential error sources.  I don't think
this is the place to document how to use SNMP for doing pings, but
a pointer to something covering the subtleties (Karl?) might be
useful.

...
> status of would be useful but not critical.

I understand your explanation.  That that was the intent of this object
was not evident to me from the text of the i-d.  This goes had-in-hand
with my other question about when these entries come into being.  The
answer to that question in part answers the question of what value there
might be in this object.

...

If the test is complete, and NO responses were received, will the value
of pingResultsProbeResponses be ZERO, or does the MIB merely require
that its value be UNCHANGED (that is d(x) == 0) from when that entry
was created?  This is the difference between a zero-based counter and
an ordinary counter.

It sounds like these are most useful if they are specified to start
counting at zero.  If this is the intent, the specification should
say so.

 -----------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 Any relationship between my opinions and BMC's is coincidental.
 -----------------------------------------------------------------------