Subject: Re: Proposed disman charter addition: alarm tracking

From: Reva Bailey <[email-masked]>
Date: Fri, 1 Dec 2000 12:25:35 -0800 (PST)

I am also interested in an Alarm Management MIB.  My work
requires mapping to the ITU alarm model, flawed or not.
I don't mind creating a better alarm model as long as the
mapping to the ITU alarm model is straight forward.

Reva Bailey
TiMetra, Inc.
[email-masked] 

> 
> Hi -
> 
> Several people have read Sharon's draft and made substantive
> comments to this list.  As working group chair, I'd like to
> determine whether we have a consensus to request of our ADs
> that this deliverable be added to our charter.  (The work
> falls squarely within the existing scope of the charter,
> in my opinion, so the only real question in my mind is
> whether we have sufficient commitment in the group to
> deliver a standards-track document.)
> 
> We should have one-or-two line description of the deliverables
> and dates.  Here's a strawman, pulled out of the air:
> 
>    April, 2001: WG last call on Alarm Management MIB
> 
>    May, 2001: Alarm Management MIB delivered to IESG for
>               consideration as proposed standard.
> 
> Sharon would be my choice as the document's editor.
> 
> Are these dates reasonable?  For example, should the scope
> be expanded to include interworking with some non-SNMP
> technologies?
> 
>  -------------------------------------------------------
>  Randy Presuhn           [email-masked]
>  Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
>  Fax:   +1 408 965-0359  2141 North First Street
>  http://www.bmc.com/     San José, California 95131  USA
>  -------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  -------------------------------------------------------
> 
> 
> 

----- End of forwarded message from Randy Presuhn -----

---

From: "Golovinsky, Eugene" <[email-masked]>
Date: Thu, 7 Dec 2000 19:55:38 -0600

Hi.

I support the proposal to add Active Alarm work to the charter.
I absolutely convinced that this work is crucial.
My only concern is that the delivery dates are a bit too aggressive.

Thanks.

Eugene Golovinsky
BMC Software, Inc.
SNMP Technology Group
 
[email-masked] <mailto:[email-masked]> 
Voice:  (713)-9181816
Mobile: (713)-8598281 

>-----Original Message-----
>From: Randy Presuhn [mailto:[email-masked]]
>Sent: Wednesday, November 29, 2000 12:05 PM
>To: [email-masked]
>Subject: Proposed disman charter addition: alarm tracking
>
>
>
>Hi -
>

---

From: "Ayers, Mike" <[email-masked]>
Date: Fri, 8 Dec 2000 17:23:04 -0600

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

> 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).

	To put it another way, the WG remains responsible for the vision
behind the RFC.

	Since noone else has jumped in yet, I'd like to take the first whack
at clarifying what alarms are and how they ought to be used.  Grab the ammo,
folks, it's open season!

	1.)  Alarms are a device's statement of its own current problems.

	2.)  Alarms are not traps.  Traps are not alarms.  The two may be
used in a  complementary fashion, but this is not required.

	3.)  The Alarm MIB should be maintained by the device posting the
alarms or by a device which directly or indirectly polls such devices for
information.  The Alarm MIB must not be maintained by gathering information
from notifications, since that is the function of the Notification Log MIB.

	4.)  The alarm model is best used for situations where many
uncoordinated monitors and/or managers are used upon a pool of devices,
since the managed device does not need to be configured for each node which
wants the information, only for the users or user groups that will have
access.

	I think that's enough to start.  You may notice (I did) that the
raise/clear mechanism doesn't fit very neatly into my vision.  In truth, I'm
not sure what the raise/clear is for.  Could someone be so kind as to
enlighten?

/|/|ike

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 10 Dec 2000 20:09:44 -0500

hi

Randy's algorithm sounds like it passes my "consistent and 
predictable" test, but I still say there is a lot of value 
in being consistent with the Notification Log MIB. As your
algorithm indicated, the Notification Log MIB structure can
be used quite efficiently and you don't have to go anywhere
near the non-existent objects.  The consistency between the
two MIBs doesn't just make my management software simpler,
but it also makes things easier for the agent people as well.

Sharon

-----Original Message-----
From: Ayers, Mike [mailto:[email-masked]]
Sent: Thursday, December 07, 2000 12:03 PM
To: 'David T. Perkins'; [email-masked]
Subject: RE: Proposed disman charter addition: alarm tracking

> 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: Dan Romascanu <[email-masked]>
Date: Mon, 11 Dec 2000 08:47:42 +0200

Mike,

> from notifications, since that is the function of the Notification Log
	[Dan]  I am not sure that I can agree with you on this - at least
not at this stage. I think we need to invest some more thinking in how
mechanism of gathering alarms are to be reflected in this MIB (or maybe
not). During this process we need to clarify relationship with Notification
Log MIB.

> not sure what the raise/clear is for.  Could someone be so kind as to
	[Dan]  The issue is of keeping states of alarms within the device.
The concepts of raise and clear are a very simple formalization of these
states, which in my opinion works in most of the cases. We need to consider
if this needs to be reflected in the MIB and where - especially if we
separate the model independent and model dependent alarm MIB modules.

	Note also some text in Sharon's draft about alarms management and
aging within the device. 

	Regards,

	Dan

---

From: "Golovinsky, Eugene" <[email-masked]>
Date: Mon, 11 Dec 2000 16:54:47 -0600

Dan, Mike.

Let me see if I understood this correctly.

The idea of active alarm table is to keep track of the sate of the device.

I agree with that approach and with you Dan where you define "alarm" state.
However, device could be not only in "Alarm", but also in "Warning" and "OK"
conditions. Sure, we could have more state definitions or we could introduce
the notion of severity to get more granularity within single state.

As far as relation to the Notification Log, I think the State or State
change
in particular may (or may not, it should be a property of the particular
state
entry) result in the record in the Notification table. That creates some
loose relationship,
which I think is sufficient.

One more thing, I do not think that we should be limiting ourselves by
speaking
only about "devices". Let's rather use "system", where system could be
hardware, software
or combination of the two entities. Any system has states.

Thanks,
--Eugene

Eugene Golovinsky
BMC Software, Inc.
SNMP Technology Group

>From: Dan Romascanu [mailto:[email-masked]]
>Sent: Monday, December 11, 2000 12:48 AM
>To: Ayers, Mike; 'David T. Perkins'; [email-masked]
>> from notifications, since that is the function of the
>Notification Log
>> MIB.
>>
>> raise/clear mechanism doesn't fit very neatly into my
>vision.  In truth,
>> I'm