Re: Aggregate Attributes

[Jon Saperia <saperia@jdscons.com>]

One comment on Fred's point which is my way to make sure I understood
him. With regard to the ospfLsdbEntry, I think the problem is a bit more
broad. Specifically, I might want to create aggregates across tables. An
example would be for BGP Path Attributes. There is work currently
underway on a revision of that module and it sure would be handy to have
potentially several tables (some of the attributes can be pretty big)
used for various types of attributes, some of which may be optional. A
single aggregate/handle for the whole thing would be more efficient and
very nice.

Fred, did I understand your point in this regard?

/jon
> 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. 
> 
> 
> 

Thanks,
/jon
--

Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/