Subject: RE: Proposed disman charter addition: alarm tracking

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 7 Dec 2000 11:03:29 -0600

> From: David T. Perkins [mailto:[email-masked]]

> On the other hand, I believe the
> ITU-T documents on which the Sharon's MIB is a based are
> "fatally flawed",

	Really?  How many telco workers have we lost so far?

> and these flaws are carried forward in Sharon's document.
> Additionally, the approach that is used to implement a union,
> which is a reuse of a design pattern used in other disman MIB
> modules, has very bad performance characteristics for bulk
> retrieval.

	The problem of storing typed data of arbitrary type is not new, and
so far, no elegant solution has emerged.  There are two general solutions to
the problem.  Either one can create a union by using the OPAQUE primitive,
or one can create a list of all possible types and a type discriminator for
that list, as has been done in the Alarm and Notification Log MIBs.  I have
not seen the former employed, which is probably good, since it merely dumps
the type problem on the manager.  The latter solution is not quite as
inefficient as it first appears, at least with respect to network bandwidth.
Consider the following algorithm.

	First, using getbulk, walk alarmActiveVariableID.  Copy the IDs
into the name fields of two varbindlist structures, result and
valueRetrieval.  In the valueRetrieval structure, change 2 to 3 in the last
field before the index so that alarmActiveVariableID.index becomes
alarmActiveVariableType.index.  Perform a get with this structure, but don't
dispose of it.  When the response comes back, copy the value for each
varbind plus 3 into the last field before the index (e.g. if the
alarmActiveVariableValueType is counter32(1), then change 3 to 4 (1+3) in
the last field before the index to make alarmActiveVariableValueType.index
into alarmActiveVariableCounter32Val.index).  Perform another get.  Copy the
values into the corresponding value fields of the result structure.  Delete
the valueRetrieval structure.  The result structure now contains the
complete varbind list of the alarm.

	This method would be only 50% slower than an implementation that
used OPAQUE.  While it requires three requests to complete, it retrieves
only required variables, and the multiple requests should be negligible
overhead once the number of variables involved gets significant.

	There is another alternative that I have seen, but I do not consider
it to be a good idea, therefore I hesitate to mention it.  The SNMPconf
Policy Management MIB contains a pmTrackingElementToPolicyTable whose
objects don't appear unless they have a nonzero value.  I consider such
"magic MIBs" to be bad SNMP.

	Finally, Randy Presuhn showed me a way to retrieve N stored
arbitrary varbinds in 2N varbind fetches, but it would require significant
modifications to the existing MIB.  In brief, tables would exist for each
supported variable type, and there would be a table for retrieving the name
(ID) of the each varbind, indexed by {alarmListName, alarmActiveIndex,
alarmActiveVariableIndex, alarmActiveVariableValueType}.  This way, when
retrieving the ID of the varbind, you get the type number as bonus!  Now,
just look in the table for storing the given data type, also indexed by
{alarmListName, alarmActiveIndex, alarmActiveVariableIndex}, and there is
your varbind's value.  This method has the added bonus of requiring storage
for only those variables actually stored.  If it is believed that large
alarm tables will be maintained, then I would recommend this method.

> Before the MIB module
> should be written, the model needs to be described, which
> has not been done in the contribution. This is really needed
> due to differing uses of the "alarm" (and associated) terminology
> and differing alarm models by vendors.

	Absolutely.  A thread should be started for this.  Sharon?

/|/|ike

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 07 Dec 2000 10:05:00 -0800

HI,

Mike, thanks for looking into the performance issues. Given that
I believe that an Alarm MIB module will be used more than all
others, performance is important. 

Many years ago, some of the network operators that were attending
working group meetings asked for information to be included
in the RFCs that showed how the objects and notifications defined
in MIB modules were to be used to solve problems. The WG said that
this was too much work, and today, few RFCs contain implementation hints.

How to use MIB objects and notifications was to be covered by
book authors. So far, little has been published. Should this
burden be pushed back to RFC authors? Well, not completely, but
there needs to be a more than just the object and notification
definitions except for really simple MIB modules. Since performance
is important with this MIB module, some ammount of implementation
strategy needs to be covered in the RFC (and alot more on the
WG mailing list).

Regards,
/david t. perkins