Re: MIB objects vs OPs

Dave,
     That is a very good summary. Thank you. Among the MIB-based
retrieval mechanisms there was the initial Aggregate-MIB proposal
too. While the BulkData proposal does provide a solution for large
chunks of data in a rather offline manner, the Aggregate-MIB
attemts to address the problems of a (potentially large) number
of MO-instances in an online manner.
     The essence is that we do need to have better data retrieval
mechanisms. I am not sure that there is one solution that solves
all the problems.

Glenn


David T. Perkins wrote:
> 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
> 
>