Re: MIB objects vs OPs

HI,

At the Salt Lake City IETF, the issue of using MIB definitions vs
new operations came up. The room was polled, and there were pluses
and minuses for each approach.

Here is a summary (and if I've forgotten any, let me know):

Problem:
Efficiently retrieval of a large quantity of regularly organized
data from an agent. We are not talking about a "one-time" walk
to "discover" existence and values attributes. This retrieval of
status and statistics at predetermined intervals. (Glenn added a
new twist in that he wanted a time series of values for a small
set of instances at a measurement rate that is not possible using
existing SNMP operations. But, it is really the same problem.)
Current SNMP operations either cannot retrieve all of the data
between desired measurement cycle, or create an unsupportable
load on the network.

Key Observation:
Since the data has a regular organization (that is, it is the
values of fixed columns of a table, with either all instances
or a predetermined set of instances), there is much redundancy
in the operands of existing SNMP operations. In particular, the
OIDs that identify instances have the same prefix value for all
instances of a column and have the same suffix value for all
columns of a row. And the OID values consume much more space
than the measured values.

Solutions
All solutions involve elimination of the redundant information.
When this is done, then for not available instances, there must
be a solution to keep the data regular. (This is called plugging
holes.)
An SNMP operation has the following benefits:
1) a management app that is already using SNMP request/response
   operations doesn't need to add support for another mechanism.
   The model is very simple. Request the data (chunks at a time)
   until all is retrieved, then "sleep" until the next poll cycle.
2) the existing SNMP security mechanisms can be used as is. Thus,
   no new work is needed to make different security mechanisms to
   work together. That is, a single set of rules via VACM need
   be set up to authorize access to the retrieved data.
3) most likely the existing routines that are used by the SNMP
   agent to access management can be used unmodified to support
   the new operation.
And the problems:
1) new operations mean that new agent and manager SNMP engines
   must be created. This requires that vendors of this technology
   update their code before it will be available to device
   vendors and management app developers.
2) the addition of operations is only "architecturally" supported
   in SNMPv3. Many devices currently only support SNMPv1. Requiring
   a move to SNMPv3 to add support for the new operation is a
   high price to pay for the functionality.
3) using a connectionless transport with a "small" maximum message
   size prohibits streaming back a large response (it is effectively
   TCP with a window size of 1). The result is less time to send the
   data, but it may not be short enough if the polling cycle is short
   or the ammount of data is large.

A MIB-based approach has the following benefits:
1) It can be done without modifying the SNMP engine of the agent
   or manager, and, thus, can be done independently of the SNMP
   technology vendor.
2) It is not restricted to using SNMP to retrieve the data, and thus
   a TCP connection can be used, which provides the best performance
   in returning a large amount of data.
3) It is independent of the version of SNMP, and, thus, can be used
   by agents that support only SNMPv1.
And the problems:
1) It requires another communication mechanism to be used by the
   management app to retrieve the data. This could be an existing
   one like FTP (or HTTP). But this involves coordination of the
   management app with this other service including setting up
   security. This typically has porting issues.
2) It requires another communication mechanism to be provided by
   the managed system. This may be extra code. Security needs to
   be worked out.
3) Details of the encodings of data through the other communication
   mechanism need to be worked out.
4) Details of the authorization for access to the returned data
   need to be worked out.
5) Details of management of the other communication mechanism needs
   to be worked out, such as is the connection long lived, or established
   and terminated for each retrieval operation.

That's about it.

Hope this helps...

Regards,
/david t. perkins