Subject: RE: Examples and Potential Delta for Alarm & ITU Alarm MIBs

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 12 Mar 2001 12:49:04 -0500

hi

Juergen> I think you either have (a) enough details in the alarm
representation
Juergen> itself so that a manager can find out what it is or you have (b) a
Juergen> formal definition what the semantics of an alarm are and you just
Juergen> refer to it. Option (b) requires extensions to the SMI since there
is
Juergen> no concept of an alarm in the SMI. Option (a) is hard to get right.

Juergen> The current AlarmDetailsEntry uses notification OIDs to identify
Juergen> alarms, which I have serious problems with since until now,
Juergen> notifications just serve a different purpose.

Well, if you look at example 3) and 4), you can see how the MIB can
be used without existing notifications.  You can consider the alarm 
indicated by the alarmDetailsIndex and the notification is used to 
transition into a particular alarm state.  Optionally gives us the 
option of mapping our existing notifications into alarms.

An example I've been working on:

5) Mixed Example

    This example demonstrates an interface based alarm which 
    goes into a state of "warning" when a linkDown notification
    is received.  The system then does further checking, like
    to see if ifAdminStatus is "up" and if it is convinced there
    is a problem, it changes the state of the alarm to be
    critical.  A linkUp alarm clears the alarm.

    alarmDetailsIndex                  7
    alarmDetailsState                  warning (6)
    alarmDetailsNotificationId         1.3.6.1.6.3.1.1.5.3
    alarmDetailsModelPointer           ituAlarmEntry.3
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  communicationsAlarm (2)
    ituAlarmProbableCause              other (1)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  7
    alarmDetailsState                  cleared (1)
    alarmDetailsNotificationId         1.3.6.1.6.3.1.1.5.4
    alarmDetailsModelPointer           ituAlarmEntry.4
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  communicationsAlarm (2)
    ituAlarmProbableCause              cableTamper(61)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

    alarmDetailsIndex                  7
    alarmDetailsState                  critical (3)
    alarmDetailsNotificationId         alarmNotifications.0.1
    alarmDetailsModelPointer           ituAlarmEntry.7
    alarmDetailsRowStatus              active (1)
    ituAlarmEventType                  communicationsAlarm (2)
    ituAlarmProbableCause              cableTamper(61)
    ituAlarmAdditionalText             ""
    ituAlarmDetector                   0.0
    ituAlarmServiceProvider            0.0
    ituAlarmServiceUser                0.0

Juergen> The idea of just sending notifications which are then turned into
Juergen> alarms is not what I want to do (because I believe the concept is
Juergen> broken and I do not want to formally define lots of new
notifications
Juergen> to report some alarms). All I need is a sub-agent which
instantiates
Juergen> some alarm records when needed. This requires in your proposal that
Juergen> the sub-agent knows the alarmDetailTable so that it can get the
Juergen> pointers right. I would prefer if I would not have to go through
this,
Juergen> even if this means some redundant MIB variables when you have lots
of
Juergen> identical alarms (which IMHO should only happen on broken or
Juergen> mis-configured systems).

My question was more "how does it do it today?", then trying to
force the use of notifications.  But, I think I get the problem.
Since the alarmDetailsIndex is a dynamic entity, the subagent
has difficulty determining what it is.  Some possible solutions:

1) Define the alarms ID as a static ID/OID

   Pros
	- The subagent knows exactly what the alarm ID is
   Cons
	- Someone has to manage this space
	- The manager needs an external file to get the IDs from,
	  making the support of alarms rather manual and
 	  time consuming.  Also need to upgrade manager for each
	  new alarm the device supports (even if its just a
	  configuration file, its still needs to be distributed)  
	- New alarms can't be added as needed.

2) Keep them dynamic and keep an internal look-up table.
   (Or, have alarmDetailsTable read-only.  Then it is a
    static space)

   Pros
	- Manager can read the MIB and know everything it
	needs to know to manage to defined alarms
	- Naming space does not need to be managed
   Cons
	- System has to keep this lookup file
	- Does not really address new alarms being added 
        dynamically

Sharon