Subject: RE: Requirement for an Alarm

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 1 Mar 2001 17:07:03 -0600

We used to call these "alarm floods" or "trap storms" (we were using
SNMPv1).  My experience there indicated that a highly sophisticated model is
needed to interpolate many alarms down to a root cause.  I think that such
an effort would be too ambitious for us at this time.

/|/|ike

> From: David T. Perkins [mailto:[email-masked]]
>
>
> 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
>
> At 03:52 PM 3/1/2001 -0500, Sharon Chisholm wrote:
> >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: Lauren Heintz <[email-masked]>
Date: Thu, 01 Mar 2001 15:45:59 -0800

It may also be possible (and desirable) to
leave this as an implementation decision.
I.e., a system is free (based upon its inate
smartness, or even depending on how it is
provisioned) to choose which alarm(s) is(are)
raised.

To do otherwise may open cans or large worms
because, using David's example, when the alarm
subsystem recieves a "port" alarm indication,
there's no guarantee it will immediately be
followed (or not) by a line card level alarm,
which thereby quenches the previous port level alarm.
Thus, a system would have to delay issuing alarms
for some small window to make sure it's sending the
right one if it were to enforce dependencies, and even
then it might not be able to.

I.e. the device being managed has to make sure
it raises the correct alarm(s) in the first place.

Thanks,
Lauren