Subject: Alarm MIB questions

From: David Partain <[email-masked]>
Date: Tue, 05 Mar 2002 17:49:07 +0100

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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 7 Mar 2002 14:38:36 +0200

This is the technical response to David's mail. I will include a
procedure comment in a separate mail.

Regards,

Dan

> -----Original Message-----
> From: David Partain [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 2:15 PM
> To: DISMAN Mailing List
> Subject: Re: Alarm MIB questions
> 
> 
> 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?
> 

Useful in certain cases? Maybe. 

Is the added complexity worth the benefit - I doubt very much. 

Indirect reference / "next" pointers methods were rejected as too
complex in other MIB designs (interfaces table extensions is the first
that comes to my mind). 

Regards,

Dan