Re: Nesting levels in existing mibs

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

>> I believe it is important for existing applications to be able to
>> continue to work with the existing mibs. As a goal, the members of
>> the meeting seemed happy with the approach that existing mibs do
>> not get extended with the new functionality.
>> 
>> If you add SMIv2-incompatible extensions to existing mibs, then
>> they may not work properly unless the applications are modified; if
>> they require modification to understand when n>1 then they are no
>> longer the existing applications.
>> 
>> Andy's proposal for OID indexing to n>1 levels was also found to be
>> a reasonable approach by the members of the meeting. I don't know
>> what you have in mind.
>> 
>> I don't mind supporting such a thing if it would be not delay the
>> development of SMIv3, and would be easy to understand for human mib
>> readers and mib writers.
>> 
>> I certainly see that mib-writers working on existing SMIv2 mibs
>> could easily make a mistake of adding an SMIv3 feature to an SMIv2
>> mib and cause problems for existing applications. A solution as
>> simple as "an SNMPv1 agent doesn't recognize Counter64 typed
>> objects for an SNMPv1 request" would suit me.

Andy> It shouldn't be that hard. First of all, SMIv3 would not prohibit
Andy> a MIB designer from adding more nesting to the converted version
Andy> of an SMIv2 table.  This would be a policy decision to minimize
Andy> the impact on existing tools and applications, during a transition
Andy> period from SMIv2 to SMIv3.  We used the same sort of policy 
Andy> during the transition period from SMIv1 to SMIv2, if you remember.
Andy> The simple rule for SMIv3 would be "Only SCALAR data types can
Andy> be added to an ARRAY which represents a converted SMIv2 table."

Andy> The new SMI features have to be defined before they are deployed
Andy> in tools and applications.  We should define features that actually
Andy> advance the state of the art. We don't have to use them on Day One.

Andy> I don't believe the manual unfolding of nested constructs
Andy> advances the state of the art.  It only works for the simplest
Andy> of examples, like unfolding a small struct of scalars
Andy> (InetAddress,Type) within another struct or a simple SMIv2
Andy> table.  It falls apart quickly if the nesting gets more complex.
Andy> More importantly, it is impossible to unfold a nested array
Andy> because the SMIv2 style table requires that all objects exist at
Andy> the same nest level. (You can't have foo.I and bar.I.J in the
Andy> same table.)


Yes. I think that's what we should preserve in a way so that a
`SMIv3-based-entity to SMIv2-based-entity' communication is possible
without restricting the SMIv3-based side to n<=1.

   entity based on              entity based on        entity based on
  SMIv3-N-level-spec           SMIv3-N-level-spec    SMIv2-converted-spec

         | mapping to                 ^ mapping             ^ mapping to
         | traditional                | to n-level          | table based
         V SNMP tables                | data structures     | data structures
       ------------------- SNMP -------------------------------

Nesting of structs and unions can be flattened automatically. As you
mention, the flattening of arrays is not that trivial. An example:

struct Route {
  InetSubnet              subnet;
  InetNetworkEndpoint     gateway;
  Unsigned32              metric[];
}

struct InetSubnet {
  InetNetworkEndpoint     endpoint;
  InetNetworkPrefixLength prefix;
}

struct InetNetworkEndpoint {
  InetAddressType         type;
  InetAddress             address {
    typemap type { // so this is a discriminated union.
      map ipv4 InetAddressIPv4;
      map ipv6 InetAddressIPv6;
    }
  }
}

typedef InetAddressType {
  type Enumeration (unknown(0), ipv4(1), ipv6(2), ...);
  descr...
}

typedef InetAddress {
  type OctetString;
  descr...
}

typedef InetAddressPrefixLength {
  type Unsigned32;
  descr...
}

table RouteTable {
  oid somenode.2;
  index (subnet.endpoint.type, subnet.endpoint.address,
         subnet.prefix);
  implements Route; // here optional(!) stuff might follow
                    // to to supply SMIv2 compatible identifiers
  descr...
}

This leads to a this sequence of leaf objects that could automatically
be flattened to column identifiers of a traditional table:

route.subnet.endpoint.type        -> RouteTable.1.1
route.subnet.endpoint.address     -> RouteTable.1.2
route.subnet.prefix               -> RouteTable.1.3
route.gw.type                     -> RouteTable.1.4
route.gw.address                  -> RouteTable.1.5

So this is easy for nested structs and unions. What is missing is the
Route's metric[] array attribute. I regard compatibility with and
convertablity to SMIv2 as a very important aspect. This is one reason,
why in the past I claimed that we can probably not support arrays, and
hence we have classified it as a nice-to-have instead of a must-have
objective (4.2.6 in RFC 3216). If we would now think, we must have
support for arrays, than it has to be mapped to a separate table. To
some degree this can be done automatically, but probably not
completely automatically.  Especially the new table's OID should be
specified explicitly.  Furthermore, we should make clear that an array
cannot be accessed atomically this way, e.g. inconsistencies can occur
while retrieving an array from the first to the last element.


 -frank