Subject: RE: Alarm MIB questions

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 5 Mar 2002 13:32:18 -0500

hi

The first issue is actually closed Alarm#8

Alarm#8 Matching Notifications (closed)
  The question was raised in London as to whether using notification OID
  plus one offset and value pair was sufficient for modelling alarm
  states. Sharon sent an email on Sept 10th summarizing her analysis
  concluding that it provided pretty good modelling.

I don't have an immediate answer for the second question, but we can
call it alarm #24. (Note my last email had two #22s.)

Sharon

-----Original Message-----
From: David Partain [mailto:[email-masked]]
Sent: Tuesday, March 05, 2002 11:49 AM
To: DISMAN Mailing List
Subject: Alarm MIB questions

Hi all,

I'm back to looking at the current Alarm MIB and have another
issue that I must bring up.  I know the last call's over, but...
Dan and Sharon, please don't shoot me in Minneapolis :-)

There are two questions on which I would like to have comments
on how you think they can be handled by the Alarm MIB:

Question 1:

The concern I have is the simplistic mapping we have in the
Alarm MIB, where we have only a notification OID and one
VarBind to distinguish alarms and alarm states.

What do we do if the different alarm states cannot be
distinguished by the current setup of the pair notificationID/
one integer-based VarBind?  That is, if I have multiple alarm
states that can exist on my system, where the individual
alarm states -- each one of which should be a row in the
AlarmModelTable -- can only be distinguished from one another
using a combination of several of the varbinds carried in the
trap/inform, how can I represent this with the Alarm MIB?

Question 2:

The current mapping to ITU alarm information is based on entries
in the ituAlarmEntry.  This means that:
[alarmModelNotificationId, alarmModelVarbindIndex/value] 
 -> entry in alarmModelTable, ituAlarmTable
 -> ituAlarmAdditionalText(*)

Telco devices often carry a textual VarBind for human
consumption (here we go again :-)).  This means that
ituAlarmAdditionalText must be able to refer to a notification
VarBind and not just a piece of text in the ituAlarmModelTable.
That is, the same alarmModelState can have different
ituAlarmAdditionalTexts.

Any thoughts on how to deal with this?

Cheers,

dlp

---

From: David Partain <[email-masked]>
Date: Thu, 07 Mar 2002 13:14:43 +0100

Hi all,

I'm following up Sharon's response regarding my two questions.
Thanks for the mail, Sharon.

dlp> Question 1:
dlp>
dlp> The concern I have is the simplistic mapping we have in the
dlp> Alarm MIB, where we have only a notification OID and one
dlp> VarBind to distinguish alarms and alarm states.
dlp>
dlp> What do we do if the different alarm states cannot be
dlp> distinguished by the current setup of the pair notificationID/
dlp> one integer-based VarBind?  That is, if I have multiple alarm
dlp> states that can exist on my system, where the individual
dlp> alarm states -- each one of which should be a row in the
dlp> AlarmModelTable -- can only be distinguished from one another
dlp> using a combination of several of the varbinds carried in the
dlp> trap/inform, how can I represent this with the Alarm MIB?

sc> The first issue is actually closed Alarm#8
sc>
sc> Alarm#8 Matching Notifications (closed)
sc>   The question was raised in London as to whether using notification OID
sc>   plus one offset and value pair was sufficient for modelling alarm
sc>   states. Sharon sent an email on Sept 10th summarizing her analysis
sc>   concluding that it provided pretty good modelling.

Okay, so it's closed, but I'm going to ask about that decision
nonetheless :-).  Feel free to ignore me if that seems the
right thing to do.

Sharon's mail (assuming it's the one you meant) had the following:

sc> I've just completed an examination of 122 or so
sc> notifications in standard MIBs.
sc>
sc> This is what I found:
sc> 
sc> 1. The method in the draft - offset + integer value -
sc>    provides pretty good modelling.
sc> 
sc> 2. There were a few cases where richer modelling would
sc>    have added more value. This could have been accomplished
sc>    by a second offset and integer pair.
sc> 
sc> What you propose is interesting, but I think it might
sc> be more than we need:
sc> 
sc> 1) It makes the solution more expensive. The agent now needs
sc>    to support the expression MIB in order to do alarm management.
sc> 
sc> 2) Allowing for the inclusion of non-varbound variables is
sc>    certainly neat, but I wonder if it goes beyond "basic fault"
sc>    and starts entering into the area of alarm correlation and
sc>    other aspects which are traditionally done in the upper
sc>    layers of the manager. Do we actually want to do this?

I realize that standard MIBs are what we really can look at
easily, but in my world (and I suspect most of the readers
of this list), a significant portion of the work we do is
with enterprise-specific MIBs.  I'm very worried that the
limited mapping capability (only one VarBind and only integer
varbinds) is going to make use of the Alarm MIB either limited.

A "relatively straightforward" way to get a little
farther down the road would be to do something like the
alarmActiveVariableTable for the model table and that would
_at least_ allow us to have varbinds that aren't integers.
This would admittedly make things a bit more complicated, but
I suspect that the bang for the buck is worth it.

One _could_ take it a step further and have "next" pointers
in the new variable table that would allow you to have a linked
list of varbinds to look at.

I agree that we don't want to make the expr MIB a requirement
for implementing the Alarm MIB.  Perhaps doing something like
I've outlined would be something between?  Is there anyone
else who thinks this would be useful?

Cheers,

dlp