Subject: Requirement for an Alarm

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 1 Mar 2001 15:52:29 -0500

hi

Ok.  If we steal from Mike's email, add a few things, and step
back and define our requirements for a perfect alarm:

1. Indicative of an actual problem that needs to be fixed
2. Has a clearly defined state and transition method (raise, clear, etc)
3. Unambiguously tells you what the problem is
4. Unambiguously tells you were the problem is (machine, port, etc)
5. Has a means of alerting interested management stations of a state
   transition.

I don't think any of this necessitates a separate name space.

Sharon

---

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 1 Mar 2001 15:58:05 -0600

> From: Sharon Chisholm [mailto:[email-masked]]
>
> hi
>

	No need to steal - it's a donation.  ;-)

> 1. Indicative of an actual problem that needs to be fixed

	"Indicates a condition which needs attention" would better support
the practices of warnings and informational alarms.  It is my understanding
that both practices are rather widespread.

> 5. Has a means of alerting interested management stations of a state

	6. Unambiguously tells you who detected the problem.

> I don't think any of this necessitates a separate name space.

	Absolutely - although it may necessitate a few new objects.

/|/|ike

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 01 Mar 2001 14:58:17 -0800

HI,

There is a big item that needs to be included when an
alarm condition is defined, and that is the dependencies
between alarms. Here are a couple of quick examples:
1) Consider a line card that contains 4 DS1 ports. The line
   card fails. Do you get one alarm (the line card failed),
   and do you get additional alarms for each DS1 port,
   and if the DS1 is channelized, do you also get alarms
   for each channel on the DS1?
2) You use up all the space in your persistent storage.
   This results in failure of software subsystems, such as
   logger. How many alarms exist?

On alarm description, one needs to specify at least:
1) an identity for the alarm
2) what set of conditions or events cause the alarm to be raised (set)
3) what set of conditions or events cause the alarm to be cleared
4) how are multiple instances of the alarm distinguished
5) how are the sources of the alarm identified (a source can be
   physical (such as port), or logical, such as a session)
6) how is the severity of the alarm determined (it may be
   statically specified or dynamically determined)
7) how is it determined if it is service affecting (it may
   be statically specified or dynamically determined)
8) what information is associated, if any, with the alarm
9) what is the category of the alarm (use ITU-T terminology?)

Regards,
/david t. perkins

---

From: Dan Romascanu <[email-masked]>
Date: Fri, 2 Mar 2001 17:11:05 +0200

[Dan]  David,

	I think that many of the functions that you describe belong to the
management application that is using the alarms and not necessarily to the
managed entity that runs the Alarm MIB. Looking at your list, I would agree
that 1,2,3, and 5 are part of the informational model that the Alarm MIB
implements. Items 4, 6 and 7 may be derived from the Alarm MIB and other
MIBs or management interfaces of the system. I do not understand very well
what you mean by 8, and I think that 9 is a model specific issue, that does
not belong to  [Dan]  the neutral Alarm MIB, but to specific model Alarm
MIBs that may be attached in a modular manner.

	Regards,

	Dan

---

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Fri, 2 Mar 2001 11:41:25 -0500

Hi, David.

Items 2, 3:  Are you proposing that we define a set of rules for
alarm correlation?
A device may have some intelligence to correlation some failure conditions
and do the best to report the root cause and suppress the bogus alarms.
I see that it is device implementation specific.
Alarm correlation is more suitable for EMS.

Anni

> ----------
> From: 	David T. Perkins[SMTP:[email-masked]]
> Sent: 	Thursday, March 01, 2001 5:58 PM
> To: 	[email-masked]
> Subject: 	Re: Requirement for an Alarm
>
>
> HI,
>
       1) an identity for the alarm
	 2) what set of conditions or events cause the alarm to be raised
(set).
> 3) what set of conditions or events cause the alarm to be cleared.
>    physical (such as port), or logical, such as a session) - agree
>    statically specified or dynamically determined) -- see #2
>    be statically specified or dynamically determined) --#2
> 8) what information is associated, if any, with the alarm -- agree
> 9) what is the category of the alarm (use ITU-T terminology?) -- agree
>
> Regards,
> /david t. perkins
>