Re: Reverse lookup tables

[Randy Presuhn <rpresuhn@dorothy.bmc.com>]

Hi -

> From: "Shawn A. Routhier" <shawn.routhier@windriver.com>
> To: mibs@ops.ietf.org
> Subject: Reverse lookup tables
> Message-Id: <20020326231717Z7850-195+8033@stovokor.epilogue.com>
> Date: 	Tue, 26 Mar 2002 18:17:07 -0500
> 
> In the SCTP MIB that I've been reviewing they include
> a series of tables that they plan to use for looking up
> an entry in the main table via a different key.  To me
> this seems like an ugly solution, however I don't see
> a better way to do it or any violation of the specifications.
> 
> Does anybody have any comments on this style of lookup table?
...

We've had to do similar things in other mibs, such as the
applications MIB.  Hopefully the WG has gotten past the
point of agreeing that there are important use cases for
each of these, and that the number of entries in the table
is likely to be too large to make brute-force retrieval
of the whole table a viable alternative.

With GetNext/GetBulk as our only way of doing selective queries
on potentially large tables, I don't see many alternatives
without going outside SNMP protocol.  If we were using SQL,
this would just be a "SELECT ... WHERE ..."; if we were using
CMIP, scoping and filtering would do the job.  The CIM folks
also have hooks for a query language, though they hadn't decided
which one the last time I looked.

>From an implementation perspective, depending on the code
generation tools, these alternate lookup tables can be
relatively cheap in both space and execution time, but it does
require that the developer understand what the lifecycle of the
instances looks like, as well as how numerous they are likely
to be.  The implementation techniques that are appropriate for
ensuring proper lexi-next behaviour for short-lived objects
aren't necessarily the right thing for long-lived ones.
(And we've all heard developers make silly claims like
"you have to sort the table to get the right answer for a
GetNext request". (Why use an O(N) or better algorithm when
you can do something that'll be O(N*log2(N)) or worse? :-))

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 randy_presuhn@bmc.com  2141 North First Street
 Tel: +1 408 546-1006   San Jose, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------