Subject: Comments on the Analysis of Alarm MIBs

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Tue, 27 Feb 2001 16:29:06 -0500

Hi.

Some general comments:

*	There is a need to identify and manage conditions in a network
device.  We need a mechanism
	to find out what conditions/alarms are still active, what
conditions/alarms are fixed (retired).
	A list of retired alarms is important.   For any reason that the
cleared alarm notification is not received,
	this is a place where you can get the record.
	The logTable is proposal#2 is an alternative, for it provides a
alarm history (active and retired).

*	For managing the conditions the following data is required, and they
are not necessary ITU-T specific:
	-- Location of condition:  physical or logical location of the
entity.
	   (Not the SNMPengineID, snmpContextName)
	   The goals is to be able to identify which node, which shelf,
which circuit pack and/or even which port.
	   We have our own format to identify the location, but it is
preferrable to have common format.

	-- Condition type:
         we use ITU-T x.733 probable cause as starting point.  As I pointed
out in the 	draft (Condition MIB),
        this is an open issue to be resolved.

*	The need to have a general alarm notification:
	 There are plenty of alarm types that has no notification defined.
That is why the general alarm
	notifications are proposed.  Then, we don't need to define a new
trap/notification for each new alarm
	type in the future.
	If a system choose to support the general alarm notification, I
would think the implementation should
	be able to ensure that no duplicated notifications are emitted.
e.g. the linkDownTrap can be mapped
	to the general alarm notification.

*	Alarm Suppression:   I should add the following clarifications in
the draft- ARC MIB:

      1. arc MIB requirement is based on the M.3100 Amendment 3.  But I have
not intention to
      translate directly from the CMIP model.  It will not scale.

      2.  Not all devices are mandatory to support ARC.  In that case,
arcTable is not required.

      3.  Even the device support ARC.  I assume that, in normal operations,
ARC is exerciced
          or applicable for all managed entities or alarm types.  Therefore,

      *** Not entry means no alarm suppression, i.e. alarm (1) is implied.
      *** To exercice ARC, one entry per resouce and per alarmtype.  I would
like to be able to
           specify a list of alarmtype, or all alarms, or all alarms except
a,b,c, etc...

      4.  ProbableCause as defined in X.733 is not the good choice for
arcAlarmtype.
           Need better definition of ProbableCause or AlarmType.
      Any suggestion?

*	I agree with David that proposal #2 and #3 are quite similar.  I am
opened to work toward a common
solution.  I need further clarification in some parts of the proposal #2,
I'll address it separately.

Also, see inline.

Regards,

Anni

> ----------
> From: 	David T. Perkins[SMTP:[email-masked]]
> Sent: 	Monday, February 26, 2001 3:51 AM
> To: 	Dan Romascanu; Sharon Chisholm; [email-masked]; [email-masked]
> Subject: 	Analysis of Alarm MIBs
>
> HI,
>
> Below is my analysis of the 3 proposals for an Alarm MIB.
> Please provide corrections and additions ASAP after which
> I'll forward to the DISMAN mailing list.
>
> ----------------------------------------------------------
> Quick Comparison of the Three Alarm Proposals
>
> The following alarm proposals have been submitted to
> the DISMAN WG for consideration:
>
> 1) draft-ietf-disman-alarm-mib-00.txt &
>    draft-ietf-disman-itualarm-mib-00.txt
>    from Chisholm & Romascanu
>
> 2) draft-ietf-disman-snmp-alarm-mib-00.txt
>    from Perkins
>
> 3) draft-lam-disman-arcmib-00.txt &
>    draft-huynh-disman-condmib-00.txt
>    from Lam & Huynh
>
> All three of the proposals address the addition of alarms to SNMP.
>
> A) Identification of alarms.
> The three proposals use different ways to identify (name)
> alarms. These are:
>
> Proposal #1 uses the name-space of notification types to
> identify (name) alarms. And it appears to double-up on the
> indentification. It assumes that alarms are raised (set) and
> cleared via a notification. The source of the alarm is
> specified by an SNMPengineID, SNMPcontextName, and varBind
> values. (Since an SNMPengineID is present, an alarm can be
> on a different system than the system making available the
> MIB objects to support alarms.)
>
> Proposal #2 uses OID values to identify (name) alarms. These OID
> values are in a different name-space than the OID values used
> to identify (name) notification-types. The proposal says that
> since the SNMP SMI is not extensible to add an "ALARM-TYPE"
> construct (macro), that the OBJECT-IDENTITY construct must
> be used to define alarm types. (The -00 version of proposal #2
> does not provide examples using the OBJECT-IDENTITY to define
> an alarm.) The source of the alarm is specified by a
> SNMPcontextname and varBind values. (Since SNMPengineID is
> not present, an alarm can be only on the system making
> available the MIB objects to support alarms.)
>
> Proposal #3 uses a 32-bit unsigned integer to identify (name)
> alarms, which are called "conditions". (Note: there is no
> information in the proposal as to how the values are assigned.
> However, assignment could be managed by IANA.) The source of
> the alarm is specified with a textual string. The proposal
> includes one example of format for the string, which is
>  <node>,<rack>,<shelf>,<slot>,<port>
> No guidance is given as to how to determine which format is
> to be used. One approach would be that as part of the alarm
> identity assignment, the format of the source would have to
> be specified. Thus, a management application would determine
> the alarm identity and use it to decode the encoding of the
> alarm source, which means that for an alarm identity unknown
> to the management app, there could be no decode of the
      alarm source.
[Anni]
      See comment above.

> Analysis: Since the SMI is not extensible, no new construct can
> be added to define new types of items. Each of the proposals
> choose a different way to overcome this obstacle. The first
> two use OID values, which seems to be choice used in most other
> MIB modules. Proposal #1 uses the name-space of notification-types.
> This appears to cause confusion because there is not a one-to-one
> mapping between notification types and alarm types. For example,
> a link down notification can be sent when the operational status
> of a network interface goes to "down". However, several other
> conditions must be true for an alarm to be raised, such as the
> admin status for the network interface having a value of up.
>
>
> B) Alarm Reporting
> The three proposals use different ways to report that an alarm
> has been raised (set) or cleared.
>
> Proposal #1 assumes that a notification with will sent that
> has has the same identification as an alarm to report that
> that an alarm has been raised. The same or another notification
> type will be sent when an alarm is cleared.
>
> Proposal #2 defines one new notification type that is sent
> when an alarm is raised (set) or cleared. The varBinds of
> the notification specify the identity of the alarm and
> specify whether the alarm is raised or cleared. The varBinds
> of the notification also include all of the relevant details
> of the alarm including the source.
>
> Proposal #3 defines two notification types. One is sent when
> an alarm is raised (set) and the other is sent when an alarm
> is cleared. The varBinds include all of the relevant details
> of the alarm including the source.
>
> Analysis: Proposal #2 and #3 are essentially identical. (That is,
> #2 can be changed to #3 by adding a new notification type and
> removing the type varBind, and #3 can be changed to #2 by removing
> a notification type and adding a varBind.) Since proposal #1
> uses existing notifications to report alarms, it will be
> difficult, if not impossible to determine by a notification
> receiver that a notification indicates an event or the set
> or clear of an alarm.
[Anni]  Let's discuss this.

> C) MIB objects in each Proposal
>
> Proposal #1 contains five tables and a few scalars. The tables are:
>   AlarmDetailsTable - has information about each possible
>        alarm that is supported on a system. It is indexed
>        by a string and arbitrary index. The string is a
>        a "list name" that comes from the MIB design pattern
>        found in RFC 3014. Note that there is concern that
>        this design pattern is broken. This table allows
>        rows to be created and deleted, and thus "new"
>        alarms to be configured.
>   ItuAlarmTable - augments alarm details table with additional
>        info as specified in ITU documents X.733 and X.736.
>   AlarmActiveTable - has information about active alarms.
>        It is indexed by a string, a TimeFilter(an RMON MIB
>        design pattern), and unique unsigned integer.
>   AlarmActiveVariableTable - has varBinds, if any, that
>        are associated with each alarm in the active table.
>   AlarmActiveStatsTable - has one gauge that is the number
>        of active alarms for each "alarm list".
>
> Proposal #2 contains 6 tables and a few scalars. The tables are:
>   SnmpAlarmCurrTable - has information about current (active)
>         alarms. It is indexed by an unsigned integer.
>   SnmpItuAlarmCurrTable - augments current alarm table with
>         additional info as specified in ITU documents X.733 and X.736.
>   SnmpAlarmCurrVarBindTable - has varBinds, if any, that
>         are associated with each alarm in the current alarm table.
>   SnmpAlarmLogTable - a log that contains set and cleared
>         alarms. Indexed by a time ordered unsigned integer.
>   SnmpItuAlarmLogTable - augments alarm log table with additional
>         info as specified in ITU documents X.733 and X.736.
>   SnmpAlarmLogVarBindTable - has varBinds, if any, that are
>         associated with each alarm in the alarm log table.
[Anni]  Need more explanation of the usage of the xxVarBindTable.  What are
the details?

> Proposal #3 contains four tables and a few scalars. The tables are:
>   CondActiveTable - has information about active conditions (alarms).
>         It is indexed by an arbitrary unsigned integer. It contains
>         attributes as specified in ITU document X.733.
>   CondRetiredTable - a log of conditions (alarms) that have been
>         cleared. Indexed by a time ordered unsigned integer.
>   CondTransientTable - a log of conditions (alarms) that were
>         not lasting (that is, they were transient). Indexed by
>         a time ordered unsigned integer.
>   ArcTable - a control table for each possible alarm table and
>         source. The table allows alarm reporting to be turned
>         off or time delayed. Indexed by source and alarm type.
>
> Analysis: even though all three proposals are influenced by X.733,
>    the tables and the organization of the table are quite different.
>    Proposal #2 and #3 are quite similar (after normalizing for
>    the difference in how alarms are identified).
>
> D) Manager - Agent interations (The SNMP message flow between a manager
>    and agent to monitor alarms on the system containing the agent.)
>
> Proposal #1 - somehow table alarmDetailstable is populated. How
>    this is done and the meaning of entries in the table are not
>    sufficiently described. Assume that this is a one time set of
>    messages. Additionally, the complete contents of table
>    alarmActiveTable and table alarmActiveVariableTable must
>    be read to get the alarms that are active on the system
>    before the manager started.
>    Now, assume a fault occurs, which results in an alarm condition.
>    One or more entries would be added to table alarmActiveTable,
>    and possibly a notification sent. A manager would poll the value
>    of object alarmActiveLastChanged to see if table alarmActiveTable
>    had changed. If so, then GETNEXTs would be used for each
>    named log to determine the added entries.
>    Now, assume a fault is cleared, which results in clearing an
>    alarm condition. One or more entries would be removed from
>    table alarmActiveTable, and possibliy a notification sent. A
>    manager would poll the value of object alarmActiveLastChanged
>    to see if table alarmActiveTable had changed. When an alarm
>    is cleared, it is removed from the table. Since there is no
>    alarm log, the manager must read all entries in the active
>    alarm table and compare the retrieved entries with the previously
>    retrived entries. Any alarms that were previous present, but
>    not not currently present, were cleared. (This points out that
>    the time filter is totally useless, since object
>    alarmActiveLastChanged is modified for both additions and
>    deletions and all entries must be retrieved to determine
>    deletions.) For each added alarm, the variables must be
>    retrieved. Since the number is not known, a GETNEXT must
>    performed per varBind (plus one), to get the data type
>    of the varbind, and then one GET can be performed to
>    get all of the values.
>
>
> Proposal #2 - The complete contents of table SnmpAlarmCurrTable and
>    table SnmpAlarmCurrVarBindTable must be read to get the alarms
>    that are current (active) on the system before the manager started.
>
>    Now, assume a fault occurs, which results in an alarm condition,
>    or a fault has been cleared, which results in clearning an
>    alarm condition. For either, one entry would be added to table
>    SnmpAlarmCurrTable, and possibly notification snmpAlarmStatusChange
>    sent. A manager would poll the value of objects snmpAlarmLastChange,
>    snmpAlarmLogFirstIndex, and snmpAlarmLogLastIndex to determine
>    if any alarms have been set or cleared. If a change, then the
>    manager knows exactly the sum of set and cleared alarms, and
>    can use one GET to retrieve all (if they can be fitted in
>    one SNMP message) from the log. For each, the number of variables
>    is provided, and no more than one GET per set or cleared
>    alarm can be used to retrieve all varBinds. (Note: if space
>    allows, a GET can be used to retrieve varBinds for several
>    set or cleared alarms.)
>
> Proposal #3 - The complete contents of tables condActiveTable,
>    condRetiredTable, and condTransientTable must be read to get
>    the conditions (alarms) that are active on the system before
>    the manager started, and to determine the ends of the tables.
>
>    Now, assume a fault occurs, which results in an alarm condition,
>    or a fault has been cleared, which results in clearning an
>    alarm condition. If a lasting condition ocurrs (an alarm set),
>    one entry will be added to table condActiveTable. If a lasting
>    condition is cleared (an alarm cleared), an entry will be
>    removed from table condActiveTable, and an entry added to table
>    condRetiredTable. If a transient condition occurs, an entry
>    will be added to table condTransientTable. To determine if
>    any table add additions, the manager would need to perform
>    GETNEXTs using the last known table index.
>    (NOTE: the semantics of the index values for table condActiveTable
>    are not clear. Are index values reused? If so, then all
>    entries must be read each poll. If incremented, each time
>    an entry is added, then what happens for index wrap?)
	[Anni]  I realized that I left out the object
condActiveNextTableIndex. This object
	give the index number to be used by a new entry.  It provide the
manage the mean
	to parse the table.

> Analysis: Proposal #1 appears to be broken. Proposal #2 gives
> the best performance (the lowest number of SNMP messages between
> a manager and agent).
>
>
> E) Alarm Suppression
>
> Only proposal #3 has specified a mechanism to suppress alarms.
> However, as specified, it does not scale well. That is, it has
> an entry for each supported alarm probably cause for each resource
> that supports alarms. Since in most cases, alarms will be enabled,
> I suggest that it only have a row when the value is other 'alm(1)'.
> Note, that the suppression is not based on severity or whether
> the condition reported by the alarm is service affecting. This
> could be useful, but would add complexity to the MIB module.
> The alarm suppression from proposal #3 could be easily added
> to proposal #2, but probably not be easily added to proposal #1.
>
[Anni] See comment above regarding ARC

> Summation
>
> Proposals #2 and #3 are similar and could be easily combined.
> Their primary difference is in how alarms are identified.
> Proposal #1 appears to have several problems.
>
> ----------------------------------------------------------
>
> Regards,
> /david t. perkins
>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 28 Feb 2001 08:57:39 -0500

hi

I think what we are starting to talk about here is both
real-time fault and historical fault.  A cleared alarm
log can easily be added to any of the proposed solutions,
but we likely want to
	1) Make sure we agree historical fault is a requirement
	2) We consider the overlap with the Notification log MIB

Sharon

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Wednesday, February 28, 2001 8:26 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Comments on the Analysis of Alarm MIBs

>>>>> Dan Romascanu writes:

>> device.  We need a mechanism to find out what conditions/alarms are
>> still active, what conditions/alarms are fixed (retired).  A list
>> of retired alarms is important.

Dan> 	[Dan] Why? You are making assumptions and assertions, with
Dan> little argumentation. The main problem that I have with many
Dan> elements in your proposal is that you have chosen a new set of
Dan> requirements, without a full argumentation about what is the
Dan> problem and if it needs a solution in the standards space.

For what it is worth: I tend to agree with Dave Perkins that a history
of recent alarms is important.

I would like to be able to check which alarms occured while I was
sleeping or while something strange went on in my network. I prefer to
be able to do this without having to collect this data constantly from
all devices in my network just in case I need it.

I think we are getting closer to actually figure out what the
(differences in the) requirements are. I think that is progress and I
thank Dave Perkins for his comparison and for starting this thread.

/js

--
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 28 Feb 2001 11:04:03 -0800

HI,

on the below...

At 02:58 PM 2/28/2001 +0200, Dan Romascanu wrote:
<stuff cut>
>        [Dan]  There are always notifications in place wherever the MIB
>authors considered necessary that they are needed. Why not relate the alarms
>to the existing notifications, as in our proposal? The general alarm
>notification either risks to duplicate the number of traps, or requires a
>parallel number of objects to turn the notifications off.
>
>        [Dan]  Regards,

It would be great if this approach could be used, but it cannot. There are
many counter examples to show that it WIL NOT WORK. One that we have
discussed several times is the linkUp and linkDown notifications.

These notifications may be sent (but of course, may be filtered and
not sent by the notification filtering mechanism defined in RFC 2573).

Sending a linkDown notification DOES NOT by itself indication
that there is an alarm condition. A linkDown only means that ifOperStatus
transitioned to 'down' or 'lowerLayerDown'. This may occur due to
a fault (which is results in an alarm condition), or may occur
because ifAdminStatus was set to down (which is not a fault and not
an alarm condition).

Regards,
/david t. perkins

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 28 Feb 2001 16:12:07 -0500

hi

Assuming this is true, then it would seem that the correct
approach would be to go back and address any known problems
with the Notification Log MIB.  Throwing it all out seems
rather extreme, especially since we may just end up trading
one set of problems for another with a new Log MIB.

Sharon

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]]
Sent: Wednesday, February 28, 2001 2:12 PM
To: [email-masked]
Cc: Chisholm, Sharon [CAR:5K32:EXCH]
Subject: RE: Comments on the Analysis of Alarm MIBs

HI,

Please note that the Notification LOG MIB defined in RFC 3014
has many problems. Assuming that it is correct and basing
work on it, I believe, is a mistake.

Regards,
/david t. perkins

---

From: "Ayers, Mike" <[email-masked]>
Date: Wed, 28 Feb 2001 16:05:35 -0600

There are indeed some serious problems with the Notification Log MIB
as it now stands, but I don't think they are unfixable.  However, what we
should be doing now is trying to craft the best alarm MIB, after which we
can take our lessons learned and apply them to the Notification Log MIB.

	This means that compatibility with the Notification Log MIB should
not be an issue when considering any modifications to any alarm MIB (gazing
pointedly at Sharon), since the Notification Log MIB can be made compatible
after the alarm MIB is considered workable.

/|/|ike

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 28 Feb 2001 20:00:02 -0500

hi

Who me? :-)

Alright, if I were to reword my notification log MIB compatibility
mantra into actual requirements it would look something like this:
	1. Reuse and be consistent with existing SNMP management
	   infrastructure as much as possible.
      2. Store alarms in a format as close to native Notifications
	   as possible.

The Reasoning
-------------
1. It's nice when the various individual management solutions fit
   together to form a cohesive whole. If a management solution
   is using data from more than one MIB, or rather from more than
   one MIB author, it can spend a lot of its time just normalizing
   the data to a common form.  This can overshadow any benefits
   the various solutions got from doing things their own way.

2. It makes the cost of entry for supporting active alarm lists quite
   cheap.  It also does not limit the sort of applications which can
   consume the information.  It's also flexible enough to be able to
   store any alarm.

That having been said, if we do what Mike said, come up with a better
alarm storage mechanism with the intention of going back and fixing
the notification log MIB to be consistent, I can live with that. (Can
I get it in writing? ;-))

Sharon

-----Original Message-----
From: Ayers, Mike [mailto:[email-masked]]
Sent: Wednesday, February 28, 2001 5:06 PM
To: Chisholm, Sharon [CAR:5K32:EXCH]; David T. Perkins;
[email-masked]

/|/|ike