Subject: [CCAMP] Comments regarding draft-ietf-ccamp-alarm-module-00

From: NICK HANCOCK <[email-masked]>
Date: Tue, 9 Jan 2018 14:52:42 +0000

Hi Stefan and Martin,

We have also been encountering some requirements with regard to certain features that are currently not directly supported in the alarm module. I realize that some of these requirements have been discussed in some form in earlier threads, but nevertheless would like to raise them again.

1. X.733 probable cause / probable cause description

One of the requirements encountered is to provide a textual description of the probable cause of an alarm type. The module 'ietf-alarms-x733' adds support for X.733 probable cause, but as a uint32. It is not clear who defines the integer values for probable cause or even if they are standardized or would even vary between vendors, thus raising interoperability issues. So what would be your opinion on either changing the type of the existing leaf 'probable-cause' to a string or the addition of a leaf 'probable-cause-description' of type string alongside the existing leaf 'probable-cause'?

2. Correlating the temporal order of alarm activations

We have encountered requirements for a relatively simple means for a NMS to be able to identify the temporal order, in which alarms have been raised by a system. Such information could, of course, be derived by a client by inspecting the system's 'alarm-list' and the entries in the 'status-change' list of each entry in the 'alarm-list', but then only if supported by a system. Although there is the leaf 'last-changed' in the lists 'alarm' and 'shelved-alarm' in the current implementation (equivalent to the leaf 'time' in 'alarm-notification'), which provides a timestamp of when the status of an alarm instance last changed, there are no explicit timestamps indicating when the alarm was last raised or last cleared. If these leafs were also supported and also included in 'alarm-notification', they could provide a means for a NMS to correlate alarm activations within the network.

Alternatively, a relatively simple addition to the core alarm module that could streamline this task would be, for example, to maintain a global alarm activation counter within a system and assign the value of the counter to an instance of an alarm each time it is raised, incrementing  the counter after assignment. This activation identifier, which would be stored for an alarm instance within the lists 'alarm-list' and 'shelved-alarm' and included within the 'alarm-notification' could then be used by a client to correlate the alarms of a system and easily construct a timeline. The counter's value itself would have no meaning, except to reconstruct  the order of alarms being raised. If an alarm is re-raised after being raised, it would receive a different value for its activation identifier.

3. Mapping custom information to alarm types

Some operators require to be able to associate their own specific information with alarm types for use within their networks. Such a requirement could be supported within the alarm module through a generic mechanism whereby one or more tag/values could be mapped to an alarm-type-id and/or alarm-type-qualifier-match in a similar way as the list 'x733-mapping' allows a client to override the default X.733 mapping. Any mapped value would also need to be listed within the alarm inventory entry for that alarm-type and included within the 'alarm-notification'.

We believe that it would be advantageous if these additional requirements on alarm management were supported directly within the core alarm module to avoid the situation of each vendor implementing its own solution, which may then lead to interoperability issues between different vendors equipment.

Best regards
Nick
This message has been classified General Business by NICK HANCOCK on 09 January 2018 at 15:52:39.

From: CCAMP [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, December 14, 2017 11:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-alarm-module-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane WG of the IETF.

Title : YANG Alarm Module
Authors : Stefan Vallin
Martin Bjorklund
Filename : draft-ietf-ccamp-alarm-module-00.txt
Pages : 58
Date : 2017-12-14

Abstract:
This document defines a YANG module for alarm management. It
includes functions for alarm list management, alarm shelving and
notifications to inform management systems. There are also RPCs to
manage the operator state of an alarm and administrative alarm
procedures. The module carefully maps to relevant alarm standards.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/<https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/>

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ccamp-alarm-module-00<https://tools.ietf.org/html/draft-ietf-ccamp-alarm-module-00>
https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-alarm-module-00<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-alarm-module-00>

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<ftp://ftp.ietf.org/internet-drafts/>

_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp<https://www.ietf.org/mailman/listinfo/ccamp>

---

From: stefan vallin <[email-masked]>
Date: Thu, 11 Jan 2018 14:27:05 +0100

Hi!
Again, thanks for your excellent comments and suggestions.
First set of comments/questions from my side below.

Stefan Vallin
[email-masked]
+46705233262

> On 09 Jan 2018, at 15:52, NICK HANCOCK <[email-masked]> wrote:
> 
> Hi Stefan and Martin,
>  
> One of the requirements encountered is to provide a textual description of the probable cause of an alarm type. The module ‘ietf-alarms-x733’ adds support for X.733 probable cause, but as a uint32. It is not clear who defines the integer values for probable cause or even if they are standardized or would even vary between vendors, thus raising interoperability issues. So what would be your opinion on either changing the type of the existing leaf ‘probable-cause’ to a string or the addition of a leaf ‘probable-cause-description’ of type string alongside the existing leaf ‘probable-cause’?

So my thinking is.
Probable cause as a global flat enum maintained by a standards body like ITU tried (and the IETF ALARM MIB) will never work

In most cases the top level NMS has an authoritative enum and the notifications from various systems needs to be mapped to this.
The systems are normally from various vendors which all have their own local enums. And of course these enums per system is in conflict with each other and the top level enum in the NMS.
We have a better mechanism with hierarchical alarm types in the alarm module. 

Therefore my thinking is to relax the whole probable cause handling. 
If you use the X733 module you can *configure* integers that match your NMS. Much easier than managing conflicting enums at design-time.
I would like to keep it as an integer for that purpose.
But lets add a string leaf as well. Good suggestion.

> We have encountered requirements for a relatively simple means for a NMS to be able to identify the temporal order, in which alarms have been raised by a system. Such information could, of course, be derived by a client by inspecting the system’s ‘alarm-list’ and the entries in the ‘status-change’ list of each entry in the ‘alarm-list’, but then only if supported by a system. Although there is the leaf ‘last-changed’ in the lists ‘alarm’ and ‘shelved-alarm’ in the current implementation (equivalent to the leaf ‘time’ in ‘alarm-notification’), which provides a timestamp of when the status of an alarm instance last changed, there are no explicit timestamps indicating when the alarm was last raised or last cleared. If these leafs were also supported and also included in ‘alarm-notification’, they could provide a means for a NMS to correlate alarm activations within the network.
Just to make sure I get it right. If the server supports the alarm-history features you have the time-stamps you need.
a) since each notification will give you a time-stamp for temporal order
b) since earlier alarm state changes temporal order can be calculated by the status-change list time stamps. last raised or last cleared can be ca)lculated from the status-change list.

So the temporal order can be correlated using the current module.

But your “problem” is:
a) the alarm-history feature might not be supported
b) you would like each notification to tell raise and clear time-stamps?

>  
> Alternatively, a relatively simple addition to the core alarm module that could streamline this task would be, for example, to maintain a global alarm activation counter within a system and assign the value of the counter to an instance of an alarm each time it is raised, incrementing  the counter after assignment. This activation identifier, which would be stored for an alarm instance within the lists ‘alarm-list’ and ‘shelved-alarm’ and included within the ‘alarm-notification’ could then be used by a client to correlate the alarms of a system and easily construct a timeline. The counter’s value itself would have no meaning, except to reconstruct  the order of alarms being raised. If an alarm is re-raised after being raised, it would receive a different value for its activation identifier.

Ok, got it.
This acts as a hint for the management system to do the temporal correlation. The information is almost there (see above) using time-stamps.
So how important is this in the general case for a core alarm module do your think? Or is this a specific feature for an NMS application. 

br Stefan

> Some operators require to be able to associate their own specific information with alarm types for use within their networks. Such a requirement could be supported within the alarm module through a generic mechanism whereby one or more tag/values could be mapped to an alarm-type-id and/or alarm-type-qualifier-match in a similar way as the list ‘x733-mapping’ allows a client to override the default X.733 mapping. Any mapped value would also need to be listed within the alarm inventory entry for that alarm-type and included within the ‘alarm-notification’.
>  
>  
>  <>From: CCAMP [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/ <https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/>
> 
> https://tools.ietf.org/html/draft-ietf-ccamp-alarm-module-00 <https://tools.ietf.org/html/draft-ietf-ccamp-alarm-module-00>
> https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-alarm-module-00 <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-alarm-module-00>
> 
> 
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>

---

From: stefan vallin <[email-masked]>
Date: Thu, 11 Jan 2018 14:29:14 +0100

and your last comment…

>> We believe that it would be advantageous if these additional requirements on alarm management were supported directly within the core alarm module to avoid the situation of each vendor implementin…

Makes sense, I think we should add this capability to the alarm inventory. So the system publishes its possible alarm types (read-only).
But each of those alarm types can have a configurable description leaf.
Ok?

---

From: NICK HANCOCK <[email-masked]>
Date: Fri, 12 Jan 2018 15:19:51 +0000

Hi Stefan,

Your comment:

We believe that just a single configurable description leaf would be somewhat restrictive. We would rather take a more generic and extensible direction, whereby a client can map zero or more tagged values as required by his network implementation to an alarm-type-id and/or alarm-type-qualifier-match. For example, something like that shown below.

As configuration:

  +--rw custom-tags {custom-tags}?
     +--rw custom-tag* [alarm-type-id alarm-type-qualifier-match tag-name]
        +--rw alarm-type-id               alarm-type-id
        +--rw alarm-type-qualifier-match  string
        +--rw tag-name                    string
        +--rw tag-value?                  tag-value

In the alarm inventory (state):

  +--ro alarm-type* [alarm-type-id alarm-type-qualifier]
     +--ro alarm-type-id                       alarm-type-id
     +--ro alarm-type-qualifier                alarm-type-qualifier
     +--ro resource*                           string
    :
     +--ro custom-tags {custom-tags}?
        +--ro custom-tag* [tag-name]
           +--ro tag-name   string
           +--ro tag-value? tag-value

Best regards
Nick
This message has been classified Public by NICK HANCOCK on 12 January 2018 at 16:19:49.

From: stefan vallin [mailto:[email-masked]]
Sent: Thursday, January 11, 2018 2:29 PM
To: NICK HANCOCK
Cc: [email-masked]; JOEY BOYD
Subject: Re: Comments regarding draft-ietf-ccamp-alarm-module-00

and your last comment...

Best regards
Nick

From: CCAMP [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, December 14, 2017 11:34 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-alarm-module-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

---

From: stefan vallin <[email-masked]>
Date: Fri, 12 Jan 2018 19:07:36 +0100

Hi!
Thanks for your response.
Is this something that should reside in the server?
I could argue this mapping should be done in the client, management system

br Stefan

Stefan Vallin
[email-masked]
+46705233262

> On 12 Jan 2018, at 16:19, NICK HANCOCK <[email-masked]> wrote:
> 
> Hi Stefan,
>  
> Your comment:
>  
>  <>From: stefan vallin [mailto:[email-masked]] 
> From: CCAMP [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of [email-masked] <mailto:[email-masked]>

---

From: NICK HANCOCK <[email-masked]>
Date: Mon, 15 Jan 2018 17:19:20 +0000

Hi Stefan!

Please see my comments below.

Best regards
Nick
This message has been classified Public by NICK HANCOCK on 15 January 2018 at 18:19:16.

From: stefan vallin [mailto:[email-masked]]
Sent: Friday, January 12, 2018 7:08 PM
To: NICK HANCOCK
Cc: [email-masked]; JOEY BOYD
Subject: Re: Comments regarding draft-ietf-ccamp-alarm-module-00

Hi!
Thanks for your response.
Is this something that should reside in the server?
I could argue this mapping should be done in the client, management system
[Nick] Yes, generally this would be true, but what we are encountering are existing network implementations that cannot be migrated to YANG-based solutions overnight and to ease this transition, operators would prefer to be able to tag alarms with their own information to be used by the client and/or applications further up the network, at least initially. Indeed in the early stages of a migration the client or application processing the alarm notifications may not even be a NETCONF client and thus may simply be parsing the XML, for example. The question may be whether the core YANG Alarm Module is the correct place to support this. My arguments for the YANG Alarm Module would be that it extends the alarm information of an alarm type in a very generic way and would also argue that as such it does not break the concept of the module. Supporting such a feature would avoid vendors implementing their own individual solutions, which most likely would result in interoperability issues arising between different vendor's equipment. Another possibility could be a separate module that augments the core module in the same way as ietf-alarms-x733 does for X.733 extensions.

br Stefan

Stefan Vallin
[email-masked]<mailto:[email-masked]>
+46705233262

On 12 Jan 2018, at 16:19, NICK HANCOCK <[email-masked]<mailto:[email-masked]>> wrote:

Hi Stefan,

Your comment:

As configuration:

Best regards
Nick

From: stefan vallin [mailto:[email-masked]]
Sent: Thursday, January 11, 2018 2:29 PM
To: NICK HANCOCK
Cc: [email-masked]<mailto:[email-masked]>; JOEY BOYD
Subject: Re: Comments regarding draft-ietf-ccamp-alarm-module-00

and your last comment...

Best regards
Nick

Abstract: