ietf-alarms

Organization:

IETF NETMOD (NETCONF Data Modeling Language) Working Group

Module:

ietf-alarms

Version:

2015-05-04

File:

ietf-alarms.yang

Abstract:

This module is an interface for managing alarms. Main inputs to the module design are the 3GPP Alarm IRP and ITU-T X.733 alarm ...

Contact:

WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>

WG Chair: Thomas Nadeau
<mailto:tnadeau@lucidvision.com>

WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>

Editor: Stefan Vallin
<mailto:svallin@cisco.com>

Editor: Martin Bjorklund
<mailto:mbj@tail-f.com>

Check for an additional details:

YANG Catalog

Description:

This module is an interface for managing alarms. Main inputs to
the module design are the 3GPP Alarm IRP and ITU-T X.733 alarm
standards. Main features:
* alarm list: a list of all alarms. Cleared alarms stay in the
list until explicitly removed.
* operator actions on alarms: acknowledging and closing alarms.
* administrative actions on alarms: purging alarms from the list
according to specific criteria.
* alarm inventory: a management application can read all
alarm types implemented by the system.
* alarm shelving: shelving (blocking) alarms according
to specific criteria.

This module uses a stateful view on alarms. An alarm is a state
for a specific resource. An alarm type is a possible alarm
state for a resource. For example, the tuple ('linkAlarm',
'GigabitEthernet0/25') is an alarm of type 'linkAlarm' on the
resource 'GigabitEthernet0/25'.

Alarm types are identified using YANG identities and an optional
string-based qualifier. The string-based qualifier allows for
dynamic extension of the statically defined alarm types. Alarm
types identifies a possible alarm state and not the individual
notifications. 'linkDown' and 'linkUp' notifications are two
notifications refering to the same alarm type 'linkAlarm'.

In this way there is no ambiguity about how alarm and alarm
clear correlation should be performed: notifications reporting
the same resource, and alarm type are considered updates of the
same alarm, such as clearing an active alarm or changing the
severity of an active alarm.

Severity and alarm text can be changed on an existing alarm.
The above alarm example can therefore look like: (('linkAlarm',
'GigabitEthernet0/25'), warning, 'interface down while interface
admin state is ip')

There is a clear separation between updates on the alarm from
the underlying resource, like clear, and updates from an
operator like acknowledge or closing an alarm: (('linkAlarm',
'GigabitEthernet0/25'), warning, 'interface down while interface
admin state is ip', cleared, closed)

Administrative actions like removing closed alarms older than a
given time is supported.