Subject: Fwd: Analysis of Alarm MIBs

From: Randy Presuhn <[email-masked]>
Date: Mon, 26 Feb 2001 11:38:32 -0800 (PST)

Hi -

forwarded from Dave Perkins.

|From [email-masked] Mon Feb 26 09:03:26 PST 2001
|Message-Id: <[email-masked]>
|Date: Mon, 26 Feb 2001 00:53:31 -0800
|To: [email-masked]
|From: "David T. Perkins" <[email-masked]>
|Subject: Fwd: Analysis of Alarm MIBs
|
|HI,
|
|I meant to include you on this.
|
|Regards,
|/david t. perkins
|
|>Date: Mon, 26 Feb 2001 00:51:58 -0800
|>To: Dan Romascanu <[email-masked]>, Sharon Chisholm <[email-masked]>, [email-masked], [email-masked]
|>From: "David T. Perkins" <[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.
|>
|>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.
|>
|>
|>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.
|>
|>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?)
|>
|>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.
|>
|>
|>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
|

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 26 Feb 2001 11:40:07 -0800 (PST)

Hi -

Forwarding a message from Dan Romascanu.

|From [email-masked] Mon Feb 26 09:10:46 PST 2001
|Message-ID: <[email-masked]>
|From: Dan Romascanu <[email-masked]>
|To: "'David T. Perkins'" <[email-masked]>,
|        Dan Romascanu
|	 <[email-masked]>,
|        Sharon Chisholm <[email-masked]>, [email-masked],
|        [email-masked]
|Cc: "[email-masked]'" <[email-masked]>,
|        Dan Romascanu
|	 <[email-masked]>
|Subject: RE: Analysis of Alarm MIBs
|Date: Mon, 26 Feb 2001 16:34:10 +0200
|
|Hi Dave,
|
|I will first start with some comments concerning your proposal #2.
|
|1. Name of the document - I think that the appropriate name should have been
|draft-perkins-disman-snmp-alarm-mib-00.txt, unless this was a decision of
|the WG Chair to run two parallel editorial tracks on the same subject.
|2. I consider confusing the mix of the generic and ITU specific alarms in
|one single MIB module. There is no one model that fits all types of alarms,
|and imposing the ITU model is at the same time too much and too little for
|many applications. This is the reason for which in proposal #1 there is a
|separation between the generic alarm MIB and the ITU Alarms MIB.
|3. How will your proposed snmpAlarmType space be administered?
|4. snmpAlarmCurrvarBindtable is a nice optimization that can be used, but
|how does SnmpvalUnion work? Until you detail this, the proposal cannot be
|used as defined.
|
|
|Please see further in-text comments.
|
|
|> -----Original Message-----
|> From:	David T. Perkins [SMTP:[email-masked]]
|> Sent:	Mon February 26 2001 10:52
|> 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.
|>
|> 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.
|>
|	[Dan]  [Dan]  You seem to assume that there is a goal to create an
|universal space and method for identifying alarms. I am not sure that this
|is an agreed goal. Our proposal does not assume a one-to-one linkage with
|the notification OID space. The type of the alarm is determined by reference
|to the model, which may detail the alarms according to the application space
|of the model.
|
|
|	 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.
|>
|	[Dan]  ...or maybe no notification will be sent. There is no
|assumption that there always be a notification sent, though we believe that
|it will happen in most of the cases. We should probably explain this better
|in the description.
|
|> 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.
|>
|	[Dan]  In do not find the utility of this proposal/ Notifications
|were already sent before we started this work. Many of them meant
|transmitting alarms information, other were just informing about events. The
|fact that we do standard alarm management should not lead to doubling the
|number of traps, this will not help and will cause concern for many
|customers. Taking your linkDown trap example - the users and applications
|know that linkDown is an indication of an alarm without the need of
|receiving a second type of notification that says - this is an alarm.
|
|
|> 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.
|>
|> 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).
|>
|	[Dan]  I do not understand what this paragraph is meant to say,
|neither its conclusion.
|>
|> 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?)
|>
|> Analysis: Proposal #1 appears to be broken. Proposal #2 gives
|> the best performance (the lowest number of SNMP messages between
|> a manager and agent).
|>
|	[Dan]
|	I think that you are missing the goal of the user of Alarm MIB. We
|assume that the user of the Alarm MIB is first of all interested in seeing
|the active alarm list, in order to do know what measure to take to
|troubleshoot the system - and not to record in a log all alarm-related
|transitions. this is why your analysis regarding the cleared alarms in our
|proposal is not relevant.
|	Taking this into account, I do not think that you demonstrated in
|any way that proposal #1 is broken.
|
|
|> 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.
|>
|	[Dan]   We decided in discussions and e-mail threads that you were
|part of that we will leave the issue of alarm suppression, as well as alarm
|aging out of the scope of the work. I do not understand and agree with your
|last phrase, because it seems to me that if we decide that we want to deal
|with this, the mechanism defined in #3 can be added without difference to
|both #1 and #2.
|
|>
|> 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.
|>
|	[Dan]  I do not agree with your conclusions and I do not think that
|you have succeeded to substantiate them in your argumentation. Proposal #2
|seems to add some requirements that were not defined within the goal of the
|work, or were left intentionally out. There are some good optimization
|elements in #2, but they are not clear because they are based upon new
|constructs which are not clearly and completely defined.
|
|	Proposal #3 is orthogonal, and deals mostly with issues that are out
|of the scope of the Charter, at least in what the editors understand it. If
|we agree that we need to add this work, we it can be combined both with #1
|and #2.
|
|	Regards,
|
|	Dan
|>
|

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 26 Feb 2001 11:48:25 -0800 (PST)

Hi -

> Message-ID: <[email-masked]>
> From: Dan Romascanu <[email-masked]>
> To: "'David T. Perkins'" <[email-masked]>,
>         Dan Romascanu
> 	 <[email-masked]>,
>         Sharon Chisholm <[email-masked]>, [email-masked],
>         [email-masked]
> Cc: "[email-masked]'" <[email-masked]>,
>         Dan Romascanu
> 	 <[email-masked]>
> Subject: RE: Analysis of Alarm MIBs
> Date: Mon, 26 Feb 2001 16:34:10 +0200
...
> 1. Name of the document - I think that the appropriate name should have been
> draft-perkins-disman-snmp-alarm-mib-00.txt, unless this was a decision of
> the WG Chair to run two parallel editorial tracks on the same subject.
...

I'm happy that we're getting substantive input looking
at different aspects of the problem space.  This can only
improve the quality of our final output.

The documents (this, Anni's and the two older I-Ds) are going
into a conceptual blender.  The WG needs to determine what
the correct number of documents should be for this work item.
We recognized the need for this determination in our charter
proposal.

I prefer that the number be VERY small.  The WG chair has NO
intention of running parallel tracks on the same subject.

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 26 Feb 2001 11:50:20 -0800 (PST)

Hi -

Forwarded from Dave Perkins.

|From [email-masked] Mon Feb 26 09:15:15 PST 2001
|Message-Id: <[email-masked]>
|Date: Mon, 26 Feb 2001 08:49:10 -0800
|To: Dan Romascanu <[email-masked]>,
|        "'Sharon Chisholm'" <[email-masked]>, [email-masked],
|        [email-masked]
|From: "David T. Perkins" <[email-masked]>
|Subject: RE: Analysis of Alarm MIBs
|Cc: [email-masked]
|In-Reply-To: <[email-masked]
| >
|
|HI,
|
|Consider the LinkDown notification. It can be sent when an interface enters
|the down or lowerLayerDown state. This can occur when there is a fault,
|or when the value of ifAdminStatus is set to down. However, an alarm
|should not be generated, since there is not a fault.
|
|Many factors are needed in deciding if an alarm should be generated,
|as well as what severity, probable cause, etc. The current
|NOTIFICATION-TYPE construct was not designed for this purpose.
|Please consider this fully.
|
|Regards,
|/david t. perkins
|

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 26 Feb 2001 11:51:01 -0800 (PST)

Hi -

Forwarded from Dan Romascanu.

|From [email-masked] Mon Feb 26 09:18:04 PST 2001
|Message-ID: <[email-masked]>
|From: Dan Romascanu <[email-masked]>
|To: "'David T. Perkins'" <[email-masked]>,
|        Dan Romascanu
|	 <[email-masked]>,
|        "'Sharon Chisholm'" <[email-masked]>, [email-masked],
|        [email-masked]
|Cc: [email-masked]
|Subject: RE: Analysis of Alarm MIBs
|Date: Mon, 26 Feb 2001 18:58:33 +0200
|
|	 HI,
|
|> Consider the LinkDown notification. It can be sent when an interface
|> enters
|> the down or lowerLayerDown state. This can occur when there is a fault,
|> or when the value of ifAdminStatus is set to down. However, an alarm
|> should not be generated, since there is not a fault.
|>
|> Many factors are needed in deciding if an alarm should be generated,
|> as well as what severity, probable cause, etc. The current
|> NOTIFICATION-TYPE construct was not designed for this purpose.
|> Please consider this fully.
|[Dan]  Hi David,
|
|We agree and understand this. We never said that there is a one-to-one
|relationship between alarms and notifications. If there is no alarm for a
|certain notification, you just do not define it in the alarmDetailsTable.
|Definition of severity is part of the model specific part, and not linked to
|notifications.
|
|Regards,
|
|Dan
|>
|

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 26 Feb 2001 11:51:42 -0800 (PST)

Hi -

|From [email-masked] Mon Feb 26 09:18:40 PST 2001
|Message-Id: <[email-masked]>
|Date: Mon, 26 Feb 2001 09:07:29 -0800
|To: Dan Romascanu <[email-masked]>, Dan Romascanu <[email-masked]>,
|        "'Sharon Chisholm'" <[email-masked]>, [email-masked],
|        [email-masked]
|From: "David T. Perkins" <[email-masked]>
|Subject: RE: Analysis of Alarm MIBs
|Cc: [email-masked]
|In-Reply-To: <[email-masked]
| >
|
|HI,
|
|How do you determine that an alarm is active for an interface, and
|how do you report it? If you use a linkDown notification, then
|how do you determine the difference between a linkDown notification
|that is sent when there is no alarm and one that is sent when there
|is an alarm?
|
|Regards,
|/david t. perkins
|At 06:58 PM 2/26/2001 +0200, Dan Romascanu wrote:
|>        HI,
|>
|>> Consider the LinkDown notification. It can be sent when an interface
|>> enters
|>> the down or lowerLayerDown state. This can occur when there is a fault,
|>> or when the value of ifAdminStatus is set to down. However, an alarm
|>> should not be generated, since there is not a fault.
|>>
|>> Many factors are needed in deciding if an alarm should be generated,
|>> as well as what severity, probable cause, etc. The current
|>> NOTIFICATION-TYPE construct was not designed for this purpose.
|>> Please consider this fully.
|>[Dan]  Hi David,
|>
|>We agree and understand this. We never said that there is a one-to-one
|>relationship between alarms and notifications. If there is no alarm for a
|>certain notification, you just do not define it in the alarmDetailsTable.
|>Definition of severity is part of the model specific part, and not linked to
|>notifications.
|>
|>Regards,
|>
|>Dan
|>>
|

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 26 Feb 2001 11:52:26 -0800 (PST)

Hi -

forwarded from Dan Romascanu.

|From [email-masked] Mon Feb 26 11:28:17 PST 2001
|Message-ID: <[email-masked]>
|From: Dan Romascanu <[email-masked]>
|To: "'David T. Perkins'" <[email-masked]>,
|        "'Sharon Chisholm'"
|	 <[email-masked]>, [email-masked],
|        [email-masked]
|Cc: [email-masked]
|Subject: RE: Analysis of Alarm MIBs
|Date: Mon, 26 Feb 2001 19:36:10 +0200
|
|Dave,
|
|This is not the major working paradigm that we have in mind. However, one
|way this would work would be first a timeFilter-ed search in the
|alarmActivetable for the alarmEngineId that sent the notification. If
|something is found, the next search would be in the alarmActivevariableTable
|for the ifOperStatus OID.
|
|Regards,
|
|Dan
|
|
|> -----Original Message-----
|> From:	David T. Perkins [SMTP:[email-masked]]
|> Sent:	Mon February 26 2001 19:07
|> To:	Dan Romascanu; Dan Romascanu; 'Sharon Chisholm'; [email-masked];
|> [email-masked]
|> Cc:	[email-masked]
|> Subject:	RE: Analysis of Alarm MIBs
|>
|> HI,
|>
|> How do you determine that an alarm is active for an interface, and
|> how do you report it? If you use a linkDown notification, then
|> how do you determine the difference between a linkDown notification
|> that is sent when there is no alarm and one that is sent when there
|> is an alarm?
|>
|> Regards,
|> /david t. perkins
|> At 06:58 PM 2/26/2001 +0200, Dan Romascanu wrote:
|> >        HI,
|> >
|> >> Consider the LinkDown notification. It can be sent when an interface
|> >> enters
|> >> the down or lowerLayerDown state. This can occur when there is a fault,
|> >> or when the value of ifAdminStatus is set to down. However, an alarm
|> >> should not be generated, since there is not a fault.
|> >>
|> >> Many factors are needed in deciding if an alarm should be generated,
|> >> as well as what severity, probable cause, etc. The current
|> >> NOTIFICATION-TYPE construct was not designed for this purpose.
|> >> Please consider this fully.
|> >[Dan]  Hi David,
|> >
|> >We agree and understand this. We never said that there is a one-to-one
|> >relationship between alarms and notifications. If there is no alarm for a
|> >certain notification, you just do not define it in the alarmDetailsTable.
|> >Definition of severity is part of the model specific part, and not linked
|> to
|> >notifications.
|> >
|> >Regards,
|> >
|> >Dan
|> >>

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 26 Feb 2001 11:53:16 -0800 (PST)

Hi -

Forwarded from Anni Huynh.

|From [email-masked] Mon Feb 26 11:28:26 PST 2001
|Message-ID: <[email-masked]>
|From: "Huynh, An-Ni (Anni)" <[email-masked]>
|To: "[email-masked]'" <[email-masked]>
|Subject: FW: Analysis of Alarm MIBs
|Date: Mon, 26 Feb 2001 14:24:41 -0500
|
|Randy:
|	Forget to put you in the cc list.
|
|Anni
|
|> ----------
|> From: 	Huynh, An-Ni (Anni)
|> Sent: 	Monday, February 26, 2001 2:22 PM
|> To: 	Dan Romascanu; Sharon Chisholm; Huynh, An-Ni (Anni); Lam, Hing-Kam
|> (Kam); 'David T. Perkins'
|> Hi, David.
|> I have not get a chance to get to the details, but have a quick comment on
|> the relationship between the two drafts:  condition-mib and arc-mib.
|> I will have more comments after I got a chance to read David's draft and
|> his analysis.
|> 1.  CondActiveTable, CondRetiredTable, and CondTransientTable are
|> designed for providing information of  alarm (condition) detected/declared
|> in a network device
|> in the timely order.  The entry is added to condActiveTable or
|> condTransientTable
|>  when a condition occurs, regardless whether the associated notification
|> is suppressed by the
|> setting of the object condNotificationSelection.
|> Also, the condTransientTable is nice to have to catch transient errors,
|> especially for debugging.
|> 2.  The arcTable is for controlling at the declaration of a condition at
|> the source.  If set at any
|> non alarm mode, there will be no entry in the condActiveTable.
|> The NALM-QI mode is meant to stop the declaration of invalid alarms when
|> the resource is
|> not in-service or in maintenance mode.
|> The NALM-TI or NALM-CD are used to delayed the declaration of alarms.  For
|> instance,
|> NALM-QI-CD provides some sort of hit-timing.  For example, an alarm is not
|> declared valid only
|> after the error condition is true for the specified time interval.
|> Note that (1) and (2) are related but not tiedly-coupled.
|> Anni
|> ----------
|> From: 	David T. Perkins[SMTP:[email-masked]]
|> Sent: 	Monday, February 26, 2001 3:51 AM
|> B) Alarm Reporting

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 26 Feb 2001 20:49:26 -0500

hi

The rest of this thread seems to be making its
way to the list.

Here's my $0.02(Can)

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:5K32:EXCH]
Sent: Monday, February 26, 2001 9:53 AM
To: 'David T. Perkins'; Dan Romascanu; [email-masked];
[email-masked]

hi

Due to the length of the email and yet more email quirks on my
end, I've adopted Mike Ayers annotation: <daveP> </daveP>,
<sharonC> </sharonC>

<daveP>
-----Original Message-----
From: David T. Perkins [mailto:[email-masked]]
Sent: Monday, February 26, 2001 3:52 AM
To: Dan Romascanu; Chisholm, Sharon [CAR:5K32:EXCH]; [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.
</daveP>

<sharonC>
It requires that the notification be defined, but not
that it be sent.  I believe this allows for both the
efficient exploitation of the body of defined notifications
and for the use of non-notification based systems.
</sharonC>

<daveP> 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.)
</daveP>

<sharonC>
Right, so do I need to duplicate all my notifications as alarms?
</sharonC>

<daveP>
 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.)
<daveP>

<sharonC>
What does this mean in a distributed environment?  If I'm an NMS
getting alarms from an EMS who gets alarms from a network element?
Does all this still work?
</sharonC>

<daveP>
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.
</daveP>

<sharonC>
Again, the Entity MIB might come in handy here.
</sharonC>

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.
</daveP>

<sharonC>
I think what you are talking about is alarm suppression, not
alarms.  I think the issue is less straight forward then
it originally seems.  To use your example, what if the link
is administratively taken down my accident or maliciously?
You might want an alarm in that case.  You might also want
to suppress these sort of alarms in other cases.
</sharonC>

<daveP>
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 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.
</daveP>

<sharonC>
Well, as I mentioned, the notification does not need to be
sent, but defined.  The raise/clear relationship is defined
in the alarmDetails table.
</sharonC>

<daveP>
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.
</daveP>

<sharonC>
Ok.  So I am defining new raise and clear alarms for all of
my existing notifications.  Am I then sending out both my
existing notifications and the new notifications associated
with the alarms?  Seems like a lot of extra work for the
device and something I've been trying to avoid since the beginning.
</sharonC>

<daveP>
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.
</daveP>

<sharonC>
The raise and clear relationship is defined in the alarmDetailsTable.
</sharonC>

<daveP>
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.

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.
</daveP>

<sharonC>
It's worth noting here, that since proposal #1) was written to compliment
the notification log MIB, it can be used for this feature as well.
</sharonC>

<daveP>
   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
   retrieved entries. Any alarms that were previous present, but
   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.)
</daveP>

<sharonC>
We discussed this limitation of the timeFiler, but felt it had other
value to add, which perhaps Dan can comment on, so we left it in.

The clear log is an interesting idea and certainly something that could
be easily added to proposal #1)
</sharonC>

<daveP>
   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.
</daveP>

<sharonC>
Actually there is a variable which tells you the number of
variable bindings in a trap.  You could therefore get all the
types in one get and then get all the values in the next.
</sharonC>

<daveP>
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.
</daveP>

<sharonC>
What happens if the index wraps?  It seems then that your last index
can be less than your first index.

I think timestamps of lastSet and lastClear could come in handy though.
</sharonC>

<daveP>
   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?)

Analysis: Proposal #1 appears to be broken.
</daveP>

<sharonC>
I think I missed a step here.  Broken because of what you said a
few paragraphs earlier?
</sharonC>

<daveP>
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.
</daveP>

<sharonC>
I think ARC could be added to either #1) or #2) just as easily.
Here is what I've started to play with as an exercise in seeing
how easily it would fit into the existing ITU Alarm MIB.  It's
very rough and I'm sure proposal #3) does a better job at covering
off the ARC requirements.

ituAlarmArcTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF ItuAlarmArcEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of ITU Alarm Reporting C."
    ::= { ituAlarmArc 1 }

ituAlarmArcEntry OBJECT-TYPE
    SYNTAX      ItuAlarmArcEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Entries appear in this table for each possible alarm."
    INDEX       { entityPhysicalIndex, alarmListName, alarmDetailsIndex }
    ::= { ituAlarmArcTable 1 }

ItuAlarmArcEntry ::= SEQUENCE {
    ituAlarmArcState INTEGER,
    ituAlarmArcQIStatus INTEGER,
    ituAlarmArcTimeoutInterval Integer32
    }

-- index EntityMibThing, alarmListName, alarmDetailsIndex
ituAlarmArcState OBJECT-TYPE
    SYNTAX  INTEGER
			{
            alm (1),  -- Alarm reporting on
            nalm (2), -- Alarm reporting off
            nalmQualifiedInhibit (3), -- Alarm reporting off waiting for
managed entity
            nalmTimedInhibit (4) -- alarm Reporting off for time-interval
            }
    MAX-ACCESS	read-write
    STATUS       current
    DESCRIPTION
             " "
     ::= { ituAlarmArcEntry 1 }

ituAlarmArcQIStatus OBJECT-TYPE
    SYNTAX  INTEGER
			{
            notApplicable (1),
            nalmNotReported (2),
            nalmCountDown (3)
            }
    MAX-ACCESS	read-only
    STATUS       current
    DESCRIPTION
             " "
     ::= { ituAlarmArcEntry 2 }

</sharonC>

<daveP>
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
</daveP>