RE: Aggregate Attributes

[Fred Baker <fred@cisco.com>]

At 04:17 PM 9/20/2001, rpresuhn-lists@dorothy.bmc.com wrote:
>If C is non-divisible, that would imply (to me at least) that
>one would no longer be able to meaningfully access just a or b.

I suppose I'm a little dense, but I find it useful to take general 
statements and try various instantiations of them to make sure I understand 
them.

I propose that there are two obvious cases for aggregation of attributes. 
One, exemplified by the {InetAddressType, InetAddress, 
InetAddressPrefixLength} "tuple" in the INET-ADDRESS-MIB, is a set of 
attributes which together describe a single thing - in this case, an 
internet address or prefix. Another is something much like an SNMP Row or 
Entry: when I want to know what a specific OSPF LSA contains, for example, 
I need to obtain all of the attributes in a given ospfLsdbEntry.

The first example can be argued as indivisible, but I think that falls 
apart pretty quickly. That may be due to "creeping featurism" in its 
design. As the INET-ADDRESS-MIB started out, there was a desire to be able 
to represent IPv4 or IPv6 addresses in the same TC, so that one could 
usefully use the same MIBs for either IPv4 or IPv6. This is essentially 
what was published as RFC 2851. Further work, in 
draft-ietf-ops-rfc2851-update-nn.txt, has expanded that to include

  - the prefix length, so that we can usefully talk about an "IP prefix",
  - zoned addresses, so that a NAT device can talk about which interface
    a given address properly lives on, and
  - DNS names (overlooking the fact that a name and an address are wildly
    different things, a distinction which has made the enum debate with the
    ITU very difficult, as although they have very clear definitions here
    they have a hard time distinguishing between +1-805-964-8007, which is
    a single telephone, and +1-800-484-3667, which is a logical name for the
    same telephone)

I'd happily say that an IP prefix has a type, a length, and a value; I'd 
even say that for zoned addresses, and omit the zone from the length. I'd 
happily say that an IPv4 Address is an instance of an IPv4 Prefix in which 
the Prefix Length is 32 bits; that would get some resistance from folks who 
went on to try to interpret certain MIBs in cases where the Prefix Length 
might be set to something else. When RMON, for example, reports that it 
received a packet from address <foo>, what does it mean for the prefix 
length to be 27 bits?

I'm not at all certain what the prefix length of a DNS name is, especially 
given that it might have both IPv4 and IPv6 instantiations.

Hence, when I look at the InetAddress tuple, I find it hard to say that it 
is indivisible. Its type and value are certainly indivisible. However, the 
prefix length is sometimes indivisible from it, when I am really talking 
about an IP Prefix, and at other times it is nonsensical.

Going on to what SNMP calls "rows", and which are in fact sets of 
attributes describing something bigger, the concept of indivisibility is 
further bothersome. An OSPF LSA is at least partly indivisible, in the 
sense that you really don't know much about any of the parts unless you can 
grasp the whole. The "whole", however, may be a generic link state database 
entry (a generic entry in a database), or a specific link state 
advertisement (something specific that the router advertised). In many 
cases, the single OCTET STRING which contains the content of the LSA is 
unimportant - if you want to know whether everyone has the same LSA and if 
not who has a different one, this is obtainable from the common subset, and 
the content portion doesn't need to be accessed. OSPF itself uses that 
fact, in that when routers are synchronizing databases they send the LSA 
headers to each other and when necessary request transmission of the entire 
LSA. So at least part of the entry, the content-specific part, is indeed 
"divisible" from the rest.

However, when sending the things around, the fact that we might use the 
attributes in different collections is not a particularly good argument for 
making the protocol fully name each individual attribute, as is done in 
SNMP. It is perfectly reasonable to send an aggregate object (such as an 
OSPF LSDB Entry, or an Interface Entry) and itemize the attributes the 
transmission carries using short form names, of the form

         { ospfLsdbEntry
                 { ospfLsdbAreaId, value }
                 { ospfLsdbType, value }
                 { ospfLsdbLsid, value }
                 { ospfLsdbRouterId, value }
                 { ospfLsdbSequence, value }
                 { ospfLsdbAge, value }
                 { ospfLsdbChecksum, value }
                 { ospfLsdbAdvertisement, really large value }
         }

where each of the attribute names is a single integer and the associated 
value is whatever it needs to be. This gets dicey when attributes from 
other tables (ifIndex being a very common example) are pulled in as index 
variables, and argues for the inclusion of an attribute which is "the value 
of ifIndex [or whatever] for this entry"; it could also argue that the 
attribute names need to have the option of being a full OID.

So I think the concept of "indivisibility" isn't all that useful here. The 
obvious examples are indeed divisible, and we have been accessing them 
individually as a standard practice for some time. The thing that is 
important about them is not that, but that we want to be able to 
efficiently move them around, and that we can in fact usefully talk about 
them as separable attributes of a larger object rather than as individual 
items of information.