Subject: Doubling notifications (was: RE: Comments on the Analysis of Alar m MIBs was: RE: Notifications != Alarms)

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 1 Mar 2001 13:04:45 -0600

<Dan->DaveP>
> I violently agree with everything that you wrote. However, you did not
> answer my question. Why not use existing notifications
> wherever they fit? I
> understand that linkDown may or may not mean an alarm condition, but
> doubling the number of traps for each case when it does mean
> alarm condition
> seems to me excessive.
</Dan->DaveP>

<MikeA>
	The point that we are trying to drill into you is that notifications
cannot in most cases simply be declared alarms, since there has been a
traditional assumption that the logic for determining alarm conditions would
be implemented largely by the manager.  This means that some intermediary
logic needs to exist between those notifications and an alarm, so that the
alarm condition can be verified.  If you wish to do this and generate alarms
based on existing notifications which can be propogated by notifications,
then you will need to design additional notifications which indicate the
alarm states - this is not notification duplication, it is the creation of
the notifications necessary for the alarm, since the alarm is a NEW thing
built on top of the old.  Do I make sense yet?
</MikeA>

<Sharon->MikeA>
What we seem to be saying here is that the existing
notifications are not necessarily well designed when
you start talking about using them as alarms.  One
proposed solution is to redefine them in a new naming
space.  These new alarms would all have a raise/clear
relationship and other things which makes then good
alarms.
</Sharon->MikeA>

<MikeA>
	I think you have the idea, but since you still seem to confuse
alarms and notifications, I'll state it outright:

	1.)  In a separate namespace, declare an OID for the alarm.
	2.)  Determine the alarm levels and state transitions.
	3.)  In a separate space, define the notifications needed to
indicate the desired state transitions.
	4.)  If necessary, create application to implement original
notification -> alarm mapping.

	Then we can deploy our new alarm system!
</MikeA>

<Dan->DaveP>
> The strategy that we propose is initiating a 'controlled
> poling' of the
> alarm tables each time when a notification that may mean an
> alarm is being
> sent. this seems preferable to sending two notifications for
> the same alarm
> - the 'existing' and your new alarm notification.
</Dan->DaveP>

<MikeA>
	Yes, but with what logic?  There are two paths that we can follow
here.  First, you can implement your own proprietary engine(s) for
converting existing notifications into alarms.  Second, we can define
standard mappings and translation logic for converting existing standard
notifications into alarms when possible.  I prefer the second, but feel
STRONGLY that we should not attempt such an effort until AFTER we have
finished the alarm MIB (and ARC, as needed) itself.

/|/|ike

</MikeA>

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 01 Mar 2001 12:09:08 -0800

HI,

I was starting to respond to Juergen's message where he shared some
of his experiences implementing a MIB level manager, and then Mike's
message (shown below) came in which really gets to the heart of the
issue. Let me try to add just a little more and not repeat the
very good descriptions that these two guys have done.

A notification an unsolicited message from an "agent", "observer",
"mid-level manager", or a "manager" to a "manager". The type of
message is identified by unique identifier (an OID value). The
message can be used for many things. In RFC 2573, section 1.3,
there is the following definition:
   A notification originator application conceptually monitors a
   system for particular events or conditions, and generates
   Notification-Class messages based on these events or conditions.

This working group has decided to define alarms as the following:

   An Alarm is a persistent indication of a fault.  An alarm is said
   to be 'set' when a fault is first detected and administratively
   enabled. An alarm is said to be 'cleared' when a fault is first
   noticed to have ceased or be administratively disabled.

Alarms can occur on a system without being reported. Defining faults
and the alarm conditions needs to be done without concern for how
alarms are reported to "managers". With existing MIB modules, a
management app designer must read and understand the MIB modules
and understand the technology being modeled. Then the designer must
write an application that polls one or more objects to determine
if an alarm condition exists. If notifications have been designed
and supported that cover the area of interest, these may be used
to reduce the polling latency. However, unless the notifications
have been explicitly designed for alarm reporting, they are not
generally sufficient for alarm management.

What the ITU-T model does is to require that alarm conditions be
"well defined" and associate attributes with each, such as severity,
and probably cause. Since the ITU-T model is written in the CMIP
framework, it uses CMIP mechanisms to define alarms and report
them to managers.

What we need to do is figure out a way to specify definitions
in the SNMP framework. This is not easy with the current SMI.
The next version of the SMI will hopefully make this task
easier. The specification for definitions of alarms must
tell the alarm designer what attributes must be included
in describing an alarm. What is required in specifying a
notification type is insufficient for defining alarms.

Deciding what is needed in describing alarms is the first step.
Lets do that first.

Regards,
/david t. perkins