Re: hierarchical naming

[Andy Bierman <abierman@cisco.com>]

At 07:01 AM 3/18/2002, Frank Strauss wrote:
>Hi!
>
>
>>> 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,
>Andy>    then you can't represent embedded ARRAYs. [...]
>
>Please don't mix up the feature of hierarchical data structures, which
>Juergen and I do like and support in SMIng as well, with the question
>about the naming used to transport data via SNMP. With respect to these
>issues, the goal of SMIng is to
>
> (a) support a `rich' data model that complies to many user aspects much
>     better than the SMIv2 data model, and
> (b) support a protocol mapping to SNMP so that applications developed by
>     using SMIng MIBs are completely compatible with old SNMP applications.
>
>It's not our intention to care about (b) at the expense of (a).

I don't think we view (b) in the same way.
First of all, hierarchical OIDs are important to retain complex
data relationships, such as the N:1 relationship between attribute X 
and attribute Y for some arbitrary complex object. This N:1 existence
relationship shows up a lot in the data we try to model in MIBs.

The new features of SMI-DS will require new code for developers
to fully realize their potential, just as new code was needed
to take advantage of Counter64 when we went from SMIv1 to SMIv2.
I think SMI-DS to SMIv2 translation is possible, just as a
Counter64 can be translated to 2 Counter32s in SMIv1. It's
not transparent, but it is possible.

I think advancing the state of the art will require some
advancement in tools, but the pain is worth the gain.



>Maybe, we should take a step backwards and talk about what we mean by
>`naming'? My understanding of naming is to give data objects and
>instances thereof well defined `names' or `addresses' so that they can
>be referred within a specific environment, e.g. by OID in SNMP, or by the
>name of a variable or a typed pointer in a program fragment. The
>intuitive naming at the level of SMI definitions leads to expressions
>like `myCounter.c32pair.c32low' and `ifTable[17].ifIndex', which is
>fine with me. The naming in C or Java code generated by a MIB compiler
>would probably be quite similar (maybe translating `-' to `_' and
>using some prefixes or suffixes). The question is, what the naming on
>the level of SNMP (thus, the OID mapping) should look like. I think, it
>should be equal to the existing OID naming scheme for compatibility
>reasons. And I don't think that this affects the benefits we want to
>achieve at the level of SMI definitions of data structures.

The SMIng approach works reasonably well for unpacking a trivial struct
within another trivial struct. The SMI data model should support
more complex existence relationships than struct in struct.

The SMI-DS naming scheme is compatible with SMIv2. Identical
semantics are named exactly the same way. Even for multiple
levels of nesting, SMI-DS puts all the columns IDs on the left,
so the registration points are totally compatible with existing
SNMP engine technology.



>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
>Andy>    structure and create sequential OID assignments for them.
>
>Doing this flat OID assignment is very easy. However, mistakes can easily
>be detected by a MIB compiler. Compatibilty to existing SNMP applications
>is much more important.

I don't see the value of doing manual unfolding of hierarchical structures
into SMIv2 style rows. This is optimizing for a handful of MIB toolkit
developers at the expense of the massive number of MIB readers and writers.


>Andy> 3) It is difficult to analyze OIDs by inspection, but this has to be
>Andy>    done for debugging. A complex data structure which is flattened
>Andy>    out somewhat arbitrarily will be difficult to reconstruct by hand.
>
>Looking at the examples in the SMI-DS I-D I had much more problems to
>decode OIDs than with the old simple flat OID structure. I must admit
>that this is probably due to our habits of the past 10 years, but I
>don't think that this would change significantly. Anyway, I think this
>is just a minor criterion.

It's useful to maintain the OID structure for sub-aggregates without
any additional code footprint for OID translation rules.



>Andy> 4) Agent instrumentation and engine code will be able to dispatch
>Andy>    by subtree, allowing for more modularized implementation. Using
>Andy>    the ACL example, if the array of ACL rules if aclList.4, then
>Andy>    that subroot can be dispatched to a single modular handler that
>Andy>    processes the rules, even if the rule is made up of multiple
>Andy>    attributes. The handler for the ACL name (e.g. aclList.2)
>Andy>    does not need to know anything about the structure or indexing
>Andy>    of the ACL rules. This is one of the goals of data abstraction.
>
>But in practice, we do have things like VACM! And, e.g., there are VACM
>configurations giving access to a specific user on all objects of an
>array (table). This relies on a prefix which contains a fixed-length
>column identifier part that can be wildcarded at the VACM setup. With
>your naming scheme, VACM could no longer be used this way. 

Actually, VACM works much better in SMI-DS than SMIng. All the
object identifiers are on the left, consistent with SMIv2.
All instance components start in the same position, and are
common across all values. Some sub-aggregates will have additional
OIDCs to the right, and will be consistent no matter what aggregate
in which the sub-aggregate is embedded.



>Andy> The current SMIng drafts require manual and explicit unfolding,
>Andy> flattening, and mapping of the natural data structure into an
>Andy> SMIv2-style row.
>>> 
>>> Yes.
>>> 
>Andy> I don't see how SW will efficiently take advantage of the
>Andy> hierarchical nature of the data structures once this is
>Andy> done.
>
>Primarily, SMIng MIB compilers read SMIng class and type definitions,
>not just the protocol mapping stuff. They are completely aware of the
>hierarchical structure and other relationships.
>
>OID flatting is done as part of the SNMP mapping so that the data
>shipped via SNMP is compatible with existing SNMP applications.

I think the protocol mappings should be done entirely with
rules specified in the SMI document, and not at all in the MIBs.
Burdening all MIB readers and writers with this task is not an
improvement to our current situation.



>Andy> [...]  Both SMIng and SMI-DS agent code will easily co-exist
>Andy> with SMIv2 agent code, because the <oidBase> structure is
>Andy> identical, and SNMP engines dispatch by a longest <oidBase>
>Andy> match of the registered instrumentation handlers.
>
>Well, as far as I understand your naming scheme, they would co-exist,
>but they would not co-operate. ;-) See the VACM example above.

They do cooperate as much as needed in the agent. The instrumentation
code for the FOO-MIB doesn't know how to interpret the complete
OIDs for the BAR-MIB. That is true in SMIv2, SMIng, and SMI-DS.



> -frank

Andy