Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt
William Lupton 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
>
> 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 wrote:
> >
> > 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.
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt
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:netmod-boun...@ietf.org] On Behalf Of William Lupton
Sent: Monday, October 17, 2016 1:38 PM
To: netmod@ietf.org
Subject: Re: [netmod] New Version Notification for
draft-vallin-netmod-alarm-module-00.txt
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
mailto:m...@tail-f.com>> wrote:
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.
___
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt
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 wrote:
>
> 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.
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt
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.
ste...@wallan.se
+46705233262
> On 11 Oct 2016, at 11:10, Vladimir Vassilev wrote:
>
> 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
>
>
> On 10/11/2016 09:18 AM, stefan vallin wrote:
>> 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;
>>> Alex Campbell wrote:
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)
>>> 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
>> 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 wrote:
>>>
>>> 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?
>> 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.
>>
>>>
>>>
>>> /martin
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt
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
On 10/11/2016 09:18 AM, stefan vallin wrote:
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;
Alex Campbell wrote:
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)
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
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 wrote:
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?
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.
/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt
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;
>
> Alex Campbell wrote:
>> 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)
>
> 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
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 wrote:
>
> 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?
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.
>
>
>
> /martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt
Alex Campbell wrote: > 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) 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt
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;"
> 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
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.
> 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
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
Sent: Friday, 7 October 2016 8:32 p.m.
To: Alex Campbell
Cc: Martin Bjorklund; netmod@ietf.org
Subject: Re: [netmod] New Version Notification for
draft-vallin-netmod-alarm-module-00.txt
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 wrote:
>
> 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.
Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt
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
ste...@wallan.se
+46705233262
> On 07 Oct 2016, at 09:42, Martin Bjorklund wrote:
>
> Hi,
>
> stefan vallin wrote:
>>> On 06 Oct 2016, at 00:22, Alex Campbell
>>> 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.
>> Can be done with shelfing
>
> 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.
>> Alarm-inventory shall reflect the possible alarms, I will add your use
>> case to the description.
>>
>>>
>>>
>>>
>>> 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 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.
>> It is the “status-change” list, it shows all status changes
>
> 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt
Hi,
stefan vallin wrote:
> > On 06 Oct 2016, at 00:22, Alex Campbell
> > 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.
> Can be done with shelfing
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.
> Alarm-inventory shall reflect the possible alarms, I will add your use
> case to the description.
>
> >
> >
> >
> > 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 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.
> It is the “status-change” list, it shows all status changes
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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt
he operator on the corresponding interface who might have a bad config > * "This list is used to shelf alarms" should be "... to shelve alarms" > * "Shelv alarms for ..." should be "Shelve alarms for ..." (multiple > occurrences) Thanks, will fix br Stefan > > Alex > > > From: netmod on behalf of Martin Bjorklund > > Sent: Thursday, 6 October 2016 1:26 a.m. > To: netmod@ietf.org > Subject: [netmod] New Version Notification for > draft-vallin-netmod-alarm-module-00.txt > > 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. > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt
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 on behalf of Martin Bjorklund Sent: Thursday, 6 October 2016 1:26 a.m. To: netmod@ietf.org Subject: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt 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. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt
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. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
