Subject: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt

From: Martin Bjorklund <[email-masked]>
Date: Wed, 05 Oct 2016 14:26:03 +0200 (CEST)

Hi,

We have posted a new version of the alarm module.  The previous
document was called draft-vallin-alarm-yang-module-00, this new
version is called draft-vallin-netmod-alarm-module (hence it is also a
-00).

This updated version incorporates comments on the previous docuement,
and adds support for alarm shelving.

It would be good to know if people in this WG are interested in this
work.

/martin and stefan

A new version of I-D, draft-vallin-netmod-alarm-module-00.txt
has been successfully submitted by Martin Bjorklund and posted to the
IETF repository.

Name:		draft-vallin-netmod-alarm-module
Revision:	00
Title:		YANG Alarm Module
Document date:	2016-10-05
Group:		Individual Submission
Pages:		58
URL:            https://www.ietf.org/internet-drafts/draft-vallin-netmod-alarm-module-00.txt
Status:         https://datatracker.ietf.org/doc/draft-vallin-netmod-alarm-module/
Htmlized:       https://tools.ietf.org/html/draft-vallin-netmod-alarm-module-00

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.

---

From: Alex Campbell <[email-masked]>
Date: Wed, 5 Oct 2016 22:22:23 +0000

Hi,

The main issue I have with this draft is that it's there's no way for the operator to get a list of all possible alarms on the device, without device-specific semantic knowledge.
They can get a list of all alarm *types*, but there's no information that says, for example, that a link-loss alarm can't be raised for a local CPU resource (or indeed, that the local CPU resource even exists).
This is exacerbated by the ability of operators can delete alarm entries; even if a device initially populates the alarm list with all possible alarms, the operator can still delete some of them, in which case the list no longer reflects all possible alarms.

We have an internally developed (but not yet published) YANG model for alarms which is very similar to this draft model, but with the following key differences:
* It does not track past status changes (they are stored in a separate event log); it is only concerned with current state.
* Alarms are associated with entities (from ietf-entity.yang) rather than arbitrary strings or instance-identifiers.
* It contains a list of all-alarms, regardless of whether they have ever been raised. This includes static information (description, severity) as well as current state information.
* It contains a separate list of raised-alarms, which mostly duplicates the information from all-alarms, but only contains an entry for an alarm if it is raised. This allows a subtree filter to retrieve only information about raised alarms, but it may be redundant.
* Instead of shelved alarms, we have a simple boolean "disabled" setting for each alarm; raised disabled alarms still appear as raised in the all-alarms list (with another indication they're disabled), but do not appear in the raised-alarms list.

With this model (and because ietf-entity.yang defines a hierarchy of entities) it is easy to display a hierarchical view of all entities and their associated alarms.

In our model, entries in the all-alarms list can only be added when resources are added to the system, and can only be deleted when resources are removed from the system.

Other comments:
* is-cleared feels like a double negation (false means "this alarm is not not raised"); I would like to see it changed to is-raised
* I would like to see a YANG feature for past status changes, or perhaps this part moved to a separate module augmenting ietf-alarms.
* has-clear doesn't need to be a union of only one type
* The meanings of "impacted resource" and "root cause resource" are unclear. 
* "This list is used to shelf alarms" should be "... to shelve alarms"
* "Shelv alarms for ..." should be "Shelve alarms for ..." (multiple occurrences)

Alex

________________________________________
From: netmod <[email-masked]> on behalf of Martin Bjorklund <[email-masked]>
Sent: Thursday, 6 October 2016 1:26 a.m.
To: [email-masked]
Subject: [netmod] New Version Notification for  draft-vallin-netmod-alarm-module-00.txt

Hi,

/martin and stefan

Abstract:

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: stefan vallin <[email-masked]>
Date: Fri, 7 Oct 2016 09:32:14 +0200

Hi!
Thanks for your comments!

Several of your comments seems to be that you might not have understood the difference between “alarm-list” and “alarm-inventory”
Please read those a bit before seeing my comments
See comments inline

> On 06 Oct 2016, at 00:22, Alex Campbell <[email-masked]> wrote:
> 
> Hi,
> 
I do not really get your comment here.
All possible alarms are published via the alarm inventory. Nothing can be delete in the inventory.
A manager reads this table to understand the possible alarms.
I do not understand when you say "initially populates the alarm list with all possible alarms”.
1) the read-only “alarm-inventory” publishes all possible alarms, including a description of the possible alarm
2) the “alarm-list” shows actual alarms, which are all of an alarm-type listed in the alarm inventory

> * It does not track past status changes (they are stored in a separate event log); it is only concerned with current state.
I think there is a huge value in this module design that as a client you see the alarm history per alarm not in a separate log.
As a user you select the interface of a device and you see the current alarm state as well as the history. This is important for trouble-shooting

> * Alarms are associated with entities (from ietf-entity.yang) rather than arbitrary strings or instance-identifiers.
But other things than entities can have alarms. AND instance-identifers are not “free-form”. It is a strange limitation to limit alarms to the entity-model
> * It contains a list of all-alarms, regardless of whether they have ever been raised. This includes static information (description, severity) as well as current state information.
See above, this is the alarm inventory
> * It contains a separate list of raised-alarms, which mostly duplicates the information from all-alarms, but only contains an entry for an alarm if it is raised. This allows a subtree filter to ret…
See above this is the alarm list
> * Instead of shelved alarms, we have a simple boolean "disabled" setting for each alarm; raised disabled alarms still appear as raised in the all-alarms list (with another indication they're disabl…
Can be done with shelfing
> In our model, entries in the all-alarms list can only be added when resources are added to the system, and can only be deleted when resources are removed from the system.
Alarm-inventory shall reflect the possible alarms, I will add your use case to the description.

> * is-cleared feels like a double negation (false means "this alarm is not not raised"); I would like to see it changed to is-raised
I think again your are confusing alarm-inventory and alarm-list. When the alarm appears for the first time it is not cleared by the resource

> * I would like to see a YANG feature for past status changes, or perhaps this part moved to a separate module augmenting ietf-alarms.
It is the “status-change” list, it shows all status changes
> * has-clear doesn't need to be a union of only one type
?
> * The meanings of "impacted resource" and "root cause resource" are unclear.
OK, I can work on improved descriptions. They idea is the following.
As an operator you would like to have *one* alarm although there are several symptoms, rather than having 15 alarms per symptom.
This module gives you the freedom of selecting should the faulty resource be the alarming object or the impacted resource.
Both options are available.
If you raise an alarm on an interface you might say that a VPN is “impacted”
If you raise an alarm on a VPN due to some probing you can hint the operator on the corresponding interface who might have a bad config

> * "Shelv alarms for ..." should be "Shelve alarms for ..." (multiple occurrences)
Thanks, will fix

br Stefan

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Oct 2016 09:42:23 +0200 (CEST)

Hi,

stefan vallin <[email-masked]> wrote:
> > * Instead of shelved alarms, we have a simple boolean "disabled" setting
> > * for each alarm; raised disabled alarms still appear as raised in the
> > * all-alarms list (with another indication they're disabled), but do not
> > * appear in the raised-alarms list.

I think both are valid designs; either there is a flag in the
alarm-list that marks an alarm as being shelved, or the shelved alarm
is (conceptually) moved to a separate list.  The design we chose is
the latter, which has the benefit of not cluttering down the real
alarm list with disabled stuff.

> > With this model (and because ietf-entity.yang defines a hierarchy of
> > entities) it is easy to display a hierarchical view of all entities
> > and their associated alarms.
> > 
> > In our model, entries in the all-alarms list can only be added when
> > resources are added to the system, and can only be deleted when
> > resources are removed from the system.
> > * is-cleared feels like a double negation (false means "this alarm is
> > * not not raised"); I would like to see it changed to is-raised
> I think again your are confusing alarm-inventory and alarm-list. When
> the alarm appears for the first time it is not cleared by the resource

I understand Alex's concern, but since the normal state is that the
alarm is not cleared, it makes sense that the node is 'is-cleared'.

> > * I would like to see a YANG feature for past status changes, or perhaps
> > * this part moved to a separate module augmenting ietf-alarms.

I think Alex's point is that support for status-changes could be
made optional, by introducing a YANG feature.

> > * has-clear doesn't need to be a union of only one type

For some reason we have today:

        leaf has-clear {
          type union {
            type boolean;
          }

(the reason for this is that originally this was a union of boolean
and the enumeration 'unknown').

/martin

---

From: stefan vallin <[email-masked]>
Date: Mon, 10 Oct 2016 11:38:17 +0200

Hi Again!
Alex, can you elaborate a bit more on your requirements for alarm-history?
What are you missing in this module?
I want to make sure I understand your comment properly.

Stefan Vallin
[email-masked]
+46705233262

> On 07 Oct 2016, at 09:42, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
>

---

From: Alex Campbell <[email-masked]>
Date: Mon, 10 Oct 2016 20:53:19 +0000

Hi,

alarm-list holds a list of raised and cleared alarms (but not those that have never been raised).
alarm-inventory holds a list of all possible alarm _types_.
If alarm-inventory were to hold a list of all possible alarms, that would indeed resolve my concern. (It would be equivalent to our all-alarms list)

As an example, suppose a server supports a few kinds of resources - interfaces, line cards, and timing cards - and the alarm types timing-signal-lost (which applies to timing cards) and timing-unsynchronized (which applies to TDM interfaces experiencing slips). An operator who is unaware of the distinction might configure the management application to send an email if a (timing-unsynchronized, TimingCard1) alarm is raised. If the server exported a list of all possible alarms, the management application would be able to prevent the operator from selecting this combination.

>> * has-clear doesn't need to be a union of only one type
The type of the leaf "/alarms/alarm-inventory/alarm-type/has-clear" is defined as "type union {type boolean;}"
This is redundant as it could simply be "type boolean;"

> As a user you select the interface of a device and you see the current alarm state as well as the history. This is important for trouble-shooting
Agreed.

> But other things than entities can have alarms. AND instance-identifers are not “free-form”. It is a strange limitation to limit alarms to the entity-model
I agree; however, it has the nice effects that it is possible to enumerate all resources, and also that the resources and their associated alarms form a hierarchy which can be visually displayed - an operator can expand a tree to get progressively more detail on the device status.
The top level of the tree shows "device has problems"; the next level shows "line card 3 has problems"; the next level shows "Interface 3/2 has problems"; the next level shows "Interface 3/2 has no media".
However, I think the concepts of root cause resources and impacted resources are more useful than this hierarchy.

> I do not understand when you say "initially populates the alarm list with all possible alarms”.
If the link is up on EthernetPort1, then in this model (link-down, EthernetPort1) is a "possible alarm" and not an "actual alarm", while in our model it is just an alarm, whose status is "cleared".
I'm not sure about the rest of the networking world, but this is the model Aviat devices currently use. If Aviat is the exception here, we can certainly adjust our terminology when implementing this module.

> If you raise an alarm on a VPN due to some probing you can hint the operator on the corresponding interface who might have a bad config
I like this idea, but I'm not sure how the device would determine which alarms to raise.
It sounds like an "interface is down" alarm would be raised if an interface goes down, *unless* that also causes a VPN to go down?

Alex

________________________________________
From: stefan vallin <[email-masked]>
Sent: Friday, 7 October 2016 8:32 p.m.
To: Alex Campbell
Cc: Martin Bjorklund; [email-masked]
Subject: Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt

Hi!

?

Thanks, will fix

br Stefan

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Oct 2016 08:42:46 +0200 (CEST)

Alex Campbell <[email-masked]> wrote:
> If alarm-inventory were to hold a list of all possible alarms, that
> would indeed resolve my concern. (It would be equivalent to our
> all-alarms list)

But this only works for devices where you can (statically?) enumerate
*all* resources that possibly could be in an alarm state!  This does
not seem very scalable to me.  Or did I miss something in your
descripition?

> > But other things than entities can have alarms. AND
> > instance-identifers are not “free-form”. It is a strange limitation to
> > limit alarms to the entity-model
> I agree; however, it has the nice effects that it is possible to
> enumerate all resources

See above.

> and also that the resources and their
> associated alarms form a hierarchy which can be visually displayed -
> an operator can expand a tree to get progressively more detail on the
> device status.
> The top level of the tree shows "device has problems"; the next level
> shows "line card 3 has problems"; the next level shows "Interface 3/2
> has problems"; the next level shows "Interface 3/2 has no media".
> However, I think the concepts of root cause resources and impacted
> resources are more useful than this hierarchy.

Why wouldn't this be possible with the model we propose?

/martin

---

From: stefan vallin <[email-masked]>
Date: Tue, 11 Oct 2016 09:18:27 +0200

Hi!

Alex, see inline on your comments.
Another thing, you had  an earlier comment:
"I would like to see a YANG feature for past status changes, or perhaps this part moved to a separate module augmenting ietf-alarms.”
Just to make sure I get your comment correctly.
Are you saying that you would like the alarm/status-change list to be a YANG feature to indicate “optionality"

   list status-change {
      if-feature alarm-status-changes;  <<<<<
      key time;
>> I agree; however, it has the nice effects that it is possible to

So, we could consider the alarm-inventory to have an additional leaf “resource”.
I think that would resolve your issue?
Of course not all systems know that, but for those that do, this helps a lot, I agree.
I see that go well with another relevant comment you had that the alarm-inventory should have
a requirement that it needs to be updated when new cards are inserted for example.
We might even add a notif for alarm-inventory changes.

> On 11 Oct 2016, at 08:42, Martin Bjorklund <[email-masked]> wrote:
> 
> See above.
> 

I think you are talking about a very useful application in the management system.
This does not mean the exact same view need to available in the alarm interface.

---

From: Vladimir Vassilev <[email-masked]>
Date: Tue, 11 Oct 2016 11:10:52 +0200

Hi,

I also reviewed the ietf-alarms model. We are interested and intend to 
implement it replacing our proprietary model.

The model is flexible and covers all alarms scenarios we support.

IMO the operator and shelving functionality can potentially be moved to 
additional module augmenting a simpler ietf-alarms.yang allowing 
possible alternative models.

As I understand Alex he would like to see some solution adding some 
determinism by pairing known "resource" and 
{alarm-type-id,alarm-type-qualifier} tuples. This can be done in 
additional model since I see it as an additional feature not necessary 
to be part of the core ietf-alarms.yang and I see nothing preventing 
such additional model to be built on top of the current ietf-alarms.yang

Vladimir

---

From: stefan vallin <[email-masked]>
Date: Tue, 11 Oct 2016 11:19:18 +0200

Hi!
Vladimir, you can exclude shelving and operator actions in your implementation.
These are YANG features that an implementation can exclude.
See RFC 6020  7.18.1.  The feature Statement
br Stefan

Stefan Vallin, Ph. D.
[email-masked]
+46705233262

> On 11 Oct 2016, at 11:10, Vladimir Vassilev <[email-masked]> wrote:
> 
> Hi,
> 
> I also reviewed the ietf-alarms model. We are interested and intend to implement it replacing our proprietary model.
> 
> IMO the operator and shelving functionality can potentially be moved to additional module augmenting a simpler ietf-alarms.yang allowing possible alternative models.
> 
> As I understand Alex he would like to see some solution adding some determinism by pairing known "resource" and {alarm-type-id,alarm-type-qualifier} tuples. This can be done in additional model since I see it as an additional feature not necessary to be part of the core ietf-alarms.yang and I see nothing preventing such additional model to be built on top of the current ietf-alarms.yang
> 
> Vladimir
> 
>

---

From: William Lupton <[email-masked]>
Date: Mon, 17 Oct 2016 18:37:45 +0100

All,

The Broadband Forum (BBF) is definitely interested and has been working on some extensions to the original draft.

BBF’s main technical change is to add an “alarm-history” feature (see below for an indication of what it does) that sounds quite like one of Alex Campbell’s proposals. There are also a few other minor changes, and others may arise as a result of the “Straw Ballot” process mentioned below.

The problem is that BBF wants to publish its changes very soon. The changes will be in “Straw Ballot” (similar to WGLC) at our upcoming Q4 meeting (next week), which would see them published in Q1 2017. They would presumably be published as a BBF YANG module that happened to be very similar to the new Vallin draft module (it wouldn’t be possible to use augment to add the alarm-history feature, right?).

In an ideal world we would prefer to work with IETF to define a module that we could then use or augment directly, but the timescales just don’t permit that. One “less bad” option might be to try to feed the proposed final BBF version (which should be available around the end of this month) into a new IETF draft resulting from (a) Direct collaboration between BBF representatives and the draft authors, or (b) BBF-led discussion on the NETMOD list. Then BBF could use this new IETF draft (not ideal, but reduces the chances of future divergence).

Thanks,
William Lupton

—— indication of what the BBF alarm-history feature does (still based on expired vallin draft) —— 

% grep -B1 -A0 'if-feature alarm-history' ietf-alarms.yang 
      leaf max-alarm-history {
        if-feature alarm-history;
--
      leaf notify-status-changes {
        if-feature alarm-history;
--
      leaf cleared {
        if-feature alarm-history;
--
        leaf is-cleared {
          if-feature alarm-history;
--
        list status-change {
          if-feature alarm-history;
--
  rpc compress {
    if-feature alarm-history;
--
  rpc compress-alarms {
    if-feature alarm-history;
--
  rpc purge-alarms {
    if-feature alarm-history;

> On 5 Oct 2016, at 13:26, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 17 Oct 2016 18:46:24 +0000

Hi Stefan,
Hi Martin,

The alarm model looks like a good match with yang-push<https://github.com/netconf-wg/yang-push/blob/drafts/draft-ietf-netconf-yang-push-04.txt>.   By combining the two, you should be able to have a remote entity track alarm changes at the consumer desired frequency.  Does this make sense to you?

Hi Bill,

Would an RFC5277bis<https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5277bis/?include_text=1> “replay” subscription aimed at a certain time period match to your need for history, or is that too heavyweight?

Eric

From: netmod [mailto:[email-masked]] On Behalf Of William Lupton
Sent: Monday, October 17, 2016 1:38 PM
To: [email-masked]
Subject: Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt

All,

Thanks,
William Lupton

On 5 Oct 2016, at 13:26, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

/martin and stefan

Abstract:

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Oct 2016 08:44:14 +0200 (CEST)

William Lupton <[email-masked]> wrote:
> All,
> 
> The Broadband Forum (BBF) is definitely interested and has been
> working on some extensions to the original draft.
> 
> BBF’s main technical change is to add an “alarm-history” feature (see
> below for an indication of what it does) that sounds quite like one of
> Alex Campbell’s proposals.

Yes, see Stefan's reply as well; we will introduce such a YANG feature
in the next revision.

> There are also a few other minor changes,

Any changes worth mentioning, or are they not of general interest?

> and others may arise as a result of the “Straw Ballot” process
> mentioned below.
> 
> The problem is that BBF wants to publish its changes very soon. The
> changes will be in “Straw Ballot” (similar to WGLC) at our upcoming Q4
> meeting (next week), which would see them published in Q1 2017. They
> would presumably be published as a BBF YANG module that happened to be
> very similar to the new Vallin draft module (it wouldn’t be possible
> to use augment to add the alarm-history feature, right?).

No, but since we'll add this feature to the base model this should be
fine.

> In an ideal world we would prefer to work with IETF to define a module
> that we could then use or augment directly, but the timescales just
> don’t permit that. One “less bad” option might be to try to feed the
> proposed final BBF version (which should be available around the end
> of this month) into a new IETF draft resulting from (a) Direct
> collaboration between BBF representatives and the draft authors, or
> (b) BBF-led discussion on the NETMOD list. Then BBF could use this new
> IETF draft (not ideal, but reduces the chances of future divergence).

We very much welcome feedback and proposals, in any form.  So if you
have more comments or ideas for changes, please let us know.

/martin

> > URL:
> > https://www.ietf.org/internet-drafts/draft-vallin-netmod-alarm-module-00.txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-vallin-netmod-alarm-module/
> > Htmlized:
> > https://tools.ietf.org/html/draft-vallin-netmod-alarm-module-00
> > 
> > 
> > Abstract: