Re: hierarchical naming

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Andy Bierman writes:

>> What do you think are the advantages? How does hierarchical naming
>> in the OIDs reduce the costs of implementing agents with current
>> protocol operations?

Andy> 1) Hierarchical naming allows more powerful and comprehensive
Andy> data structures to exist. If the OIDs are flattened out, then
Andy> you can't represent embedded ARRAYs.

Yes, arrays have to be flattened out into separate tables - something
all existing SNMP tools and applications understand. You have to do
the same to remain backwards compatibility with installed SNMP tools
and applications.

Andy> Simple data structures,
Andy> such as an array of port stats within an array of interface
Andy> stats, the RMON2 usrHistoryControlTable/ObjectTable or an access
Andy> control list that contains some base types plus an ordered list
Andy> of access control rules cannot be represented as a single data
Andy> structure.  With SMIng, any data relationship in which not all
Andy> members have a 1:1 existence relationship to each other have to
Andy> be separated into multiple structures. This leads to more
Andy> complex instrumentation code.  Flattening out the attributes
Andy> only works reasonably well for simple structs in structs.

True. We could add arrays to the SMIng data type language - but that
would make the flattening a bit more difficult (which we dislike) and
it causes the question when you use relationships between "tables" and
"arrays". And at the end, you end up with the same variables and the
same instance identifiers - just that the OIDs in SMI-DS contain more
containment information.

Andy> 2) Manual flattening of complex data structures will likely be
Andy> labor-intensive and error-prone. A MIB writer will have to
Andy> recursively iterate through all the levels of the data structure
Andy> and create sequential OID assignments for them.

Algorithmic flattening can be surprising. Manual flattening at least
clearly says the MIB readers what you get and allows easy transition
to and from SMIv2. Flattening is work authors have to do to be
backward compatible. And as you said earlier, there are much more MIB
readers than MIB authors. The good news is that compilers can easily
assist the human MIB author by checking that the flattening is
complete or by providing templates which can be fine tuned.

I do not know how you generate an SMIv2 module from an SMI-DS module
algorithmically and whether that leads to good results and works
better than manual flattening. 

Andy> 3) It is difficult to analyze OIDs by inspection, but this has
Andy> to be done for debugging. A complex data structure which is
Andy> flattened out somewhat arbitrarily will be difficult to
Andy> reconstruct by hand.

I generally agree that turning OIDs back into complex data structures
by hand is ugly. However, I personally doubt that hierarchical OIDs
will make such a big difference in comparison with current OIDs. If
you are really concerned about simplifying debugging, then change the
protocol to ship objects rather than list of variables and use names
rather than OIDs in the protocol. Or you use packet sniffer that do
the name demangling for you and which you trust. ;-)
   
Andy> 4) Agent instrumentation and engine code will be able to
Andy> dispatch by subtree, allowing for more modularized
Andy> implementation. Using the ACL example, if the array of ACL rules
Andy> if aclList.4, then that subroot can be dispatched to a single
Andy> modular handler that processes the rules, even if the rule is
Andy> made up of multiple attributes. The handler for the ACL name
Andy> (e.g. aclList.2) does not need to know anything about the
Andy> structure or indexing of the ACL rules. This is one of the goals
Andy> of data abstraction.

I think this really depends to a great extend on how your SNMP toolkit
implementation works.

>> My assumption is that a reasonable SNMP toolkit converts received
>> varbind lists into implementation language data structures derived
>> from MIB modules before any callbacks are invoked. Right now, all
>> such a tool can generate (without additional hints) are simple
>> structures.  With SMIng and SMI-DS, we can define in the MIB module
>> more complex data types and thus a smart toolkit will take
>> advantage of this and generate code to convert received varbind
>> lists to more complex implementation language data structures. And
>> since SMIng and SMI-DS allow to reuse (complex) data types, chances
>> are good that smart toolkits can produce more compact
>> implementation code. With current SNMP operations, all this happens
>> at compile-time and at run-time, all you need are unique OIDs - I
>> think it does not really matter much whether whether they contain
>> some information about the nesting or not.

Andy> I am concerned about the complexity of this engine code, and
Andy> even more concerned about the increase in codesize that will
Andy> occur if lots of 'OID rearrangement rules' are stored on the
Andy> agent.

Toolkits that provide methods routines specific data structures have
to analyze the whole varbind list in order to pick out those pieces
that together form an instance of the data structure. This
de-serialization of the varbind list into an "object" can be done by
either relying on some help between the base OID and the instance
identifier portion or by encoding this information in varying OID
bases. I do not think that one needs "lots of 'OID rearrangement
rules'" - but you mileage may vary. It probably requires more concrete
code / algorithm snippets to analyze what the true answer here is.  If
you are concerned about this deserialization complexity, then change
the protocol to ship objects rather than arbitrarily ordered lists of
variables.

/js