Re: Aggregate Attributes

[Jon Saperia <saperia@jdscons.com>]

> At 12:54 PM 9/26/2001, Jon Saperia wrote:
> >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?
> 
> I don't think so, as I was talking about the organization and transmission 
> of attributes in logical groupings (all of the information in a single LSA 
> being an example, or a single IP Prefix being an example), rather than a 
> handle with which to identify them across multiple logical records.
> 
> However, I can imagine that the handle might be useful. In the BGP case, it 
> sounds like you might want a table of RowPointers indexed by the handle and 
> an element-that-has-that-handle number. You could download that, for some 
> value of the handle, and then download the indicated records.
> 
> 
A table of row pointers as you suggest could work. At this point, what was more
important to me was making sure we worked across table boundaries and
could represent very complex structures that are not always easily
represented in a single table. We could do much of what you suggest now
with row pointers - good approach, but perhaps we can think of something
better that represents aggregates - the handle and formalizing it in our
new work. 

> 

Thanks,
/jon
- - --

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