Subject: Re: [CCAMP] draft-ietf-ccamp-alarm-module-02

From: stefan vallin <[email-masked]>
Date: Tue, 2 Oct 2018 08:18:17 +0200

Hi Karen!
See inline
br Stefan and Martin

> 
> I hope that you can accept the follow up right below:
> 
> * Would it not be relevant in the draft to outline the relation to the alarm-state in RFC8348 ?
> 
> ** Possibly even in the substance of the document rather then in an appendix  - assuming that the two are seen as complementary mechanisms potentially based on the same underlying alarm framework (that you define in this draft)
We can add a short description on the relationship between the Alarm Module and RFC8348.
As Martin stated they serve different purposes:
"The "alarm-state" in RFC 8348 (and EntityAlarmStatus in RFC 4268) is
just a summary of the alarms that may be active on the specific
hardware component.  It doesn't say anything about how alarms are
reported, and it doesn't provide any details of the alarms; it is just
a bitmask. The alarm-module draft, specifies how alarms are reported,
generically.  It also provides a list of all active alarms."

The mapping between the data-models are outlined below.
Alarm YANG.                                 RFC 8348
alarm list
* resource                                      corresponds  to /hardware/component/
* is-cleared                                    no bit set in /hardware/component/state/alarm-state
* perceived-severity                       corresponding bit set in /hardware/component/state/alarm-state
* operator-state-change/state.      if the alarm is acked by the operator it could correspond to under-repair

> 
> ** In the draft you have "closed" state of an alarm. Wouldn't it be relevant, in your opinion. with this alarm framework in mind, also to have the closed state in the alarm-state object of RFC8348 ?
> 
> * The same question (should be included in alarm-state of RFC8348) for the shelved alarms ?
This would be an update to RFC 8348, and is out of scope for this work
> 
> Something else:
> 
> * Assuming that one has an alarm which have no clear  (see next question below) or where clear may not always come.
>   Would an operator close of this alarm make it disappear from the active alarms summary ? Can that be an implementation decision  - possibly depending on the alarm type, possibly configurable ?
The general answer is no, as stated in the document, there is no automatic purge/deletion of an alarm on clear from the resource or close from the operator.
This is by design, from an ops perspective it makes sense to be able to view the alarm even after it is cleared/closed. 
You might want to study the root cause afterwards to perform proactive actions for it not to appear again for example.

But as you say, you can make it an implementation decision, "purge on clear", "purge on close".
If it is hard-coded per alarm-type, describe it in the alarm inventory
You can also make it configurable per alarm type by augmenting the alarm profile with a purge-policy: "purge on clear", "purge on close"
> 
> * RFC3877 has the following statement: "Alarms SHOULD  be modelled so Notifications are sent on alarm Clear."  
> I did not find this statement in the substance of the draft nor in Appendix F (But it may have escaped me).  
> Is this also the mindset of this draft ?
According to this alarm module an alarm-notification will be sent with perceived-severity set to cleared.
> 
> * It is correctly understood that the Alarm Summary and the Alarm list contains the alarms which are presently in the system - i.e. which have not been purged ?
Correct
>  * Would it be relevant for the Alarm Summary list to tell when alarms was last purged due to administrative action ?
We do not want to load the alarm module with more features at this point, this could be done in the management application/client. 
> 
> * Are you considering to implement support for statistics ?
What do you mean with statistics?
a) Statistics on alarms or do you mean a b) performance monitoring module?
It a, no, that is up to the management application
If b, that is a separate module not within this one

> 
> 
> BR, Karen
> 
> -----Original Message-----
> From: Martin Bjorklund <[email-masked]> 
> Sent: 20. september 2018 10:31
> To: Karen Elisabeth Egede Nielsen <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: draft-ietf-ccamp-alarm-module-02
> 
> Hi,
> 
> Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
>> Hi,
>> 
>> This draft is new to me and modelling of alarm management also 
>> somewhat....
>> 
>> Could you enlighten me on the relationship, if any, in between the 
>> alarm module of this draft and the Device/resource alarm state within 
>> RFC8348 (equivalently the EntityAlarmStatus of RFC4268) ?
> 
> The "alarm-state" in RFC 8348 (and EntityAlarmStatus in RFC 4268) is just a summary of the alarms that may be active on the specific hardware component.  It doesn't say anything about how alarms are reported, and it doesn't provide any details of the alarms; it is just a bitmask.
> 
> The alarm-module draft OTOH, specifies how alarms are reported, generically.  It also provides a list of all active alarms.
> 
>> E.g.  are the two they considered complementary mechanisms (modules), 
>> just different view glasses, or are they non-compatible or redundant 
>> ..?
> 
> So if both modules are implemented (they don't have to be), the information can be viewed as redundant or just different views.
> 
> 
> /martin
> 
> 
> 
>> 
>> Many Thanks in advance !
>> 
>> 
>> BR, Karen Nielsen
>>

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Tue, 2 Oct 2018 07:27:20 +0000

HI Stefan, Martin,

Thanks a lot.
Pls see inline below.

BR, Karen

<snip>

> > ** Possibly even in the substance of the document rather then in an
> > appendix  - assuming that the two are seen as complementary
> mechanisms
> > potentially based on the same underlying alarm framework (that you
> > define in this draft)
> "The "alarm-state" in RFC 8348 (and EntityAlarmStatus in RFC 4268) is just
> a summary of the alarms that may be active on the specific hardware
> component.  It doesn't say anything about how alarms are reported, and it
> doesn't provide any details of the alarms; it is just a bitmask. The alarm-
> module draft, specifies how alarms are reported, generically.  It also
> provides a list of all active alarms."
> 
[Keen] I would appreciate that very much. Thanks !
> >
> > ** In the draft you have "closed" state of an alarm. Wouldn't it be
> relevant, in your opinion. with this alarm framework in mind, also to have
> the closed state in the alarm-state object of RFC8348 ?
> >
[Keen] Yes. However the IETF makes comprehensive standards. 
The present gap in between this work (which I support) and RFC8348 is actually also one of the reasons why I think that it is important to 
explicitly relate to  RFC8348 in this work (draft in subject).

For our usecase (IoT) I think that it will be relevant to implement a solution inline with this draft. However I also believe that we would like to implement support for alarm-state object of RFC8348, in this case then for usefulness extended with the "closed" state.

> >
> > Something else:
> >
> > * Assuming that one has an alarm which have no clear  (see next question
> below) or where clear may not always come.
> >   Would an operator close of this alarm make it disappear from the active
> alarms summary ? Can that be an implementation decision  - possibly
> depending on the alarm type, possibly configurable ?
> The general answer is no, as stated in the document, there is no automatic
> purge/deletion of an alarm on clear from the resource or close from the
> operator.
> This is by design, from an ops perspective it makes sense to be able to view
> the alarm even after it is cleared/closed.
> You might want to study the root cause afterwards to perform proactive
> actions for it not to appear again for example.
> 
[Keen] Yes that makes good sense.

> If it is hard-coded per alarm-type, describe it in the alarm inventory You can
> also make it configurable per alarm type by augmenting the alarm profile
> with a purge-policy: "purge on clear", "purge on close"
> >
[Keen] Thanks.

> According to this alarm module an alarm-notification will be sent with
> perceived-severity set to cleared

[Keen] Is that stated explicitly in the draft ?
Will you associate a keyword  with this statement ?

> >
> > * It is correctly understood that the Alarm Summary and the Alarm list
> contains the alarms which are presently in the system - i.e. which have not
> been purged ?
> Correct
> >  * Would it be relevant for the Alarm Summary list to tell when alarms was
> last purged due to administrative action ?
> We do not want to load the alarm module with more features at this point,
> this could be done in the management application/client.
> >
[Keen] It might be prudent to have this state in the server as well (?)

> It a, no, that is up to the management application If b, that is a separate
> module not within this one

[Keen] I was referring to the first. Here first and foremost statistics on received alarms divided on severity level.

Yes it can be done in the management application, but I am not sure why it is necessarily "up to the management application" to do this ?

Would some global statistics in the server not make sense - or do you have specific reasons for placing all statistics in the management application layer ?

BR, Karen

> > The "alarm-state" in RFC 8348 (and EntityAlarmStatus in RFC 4268) is just
> a summary of the alarms that may be active on the specific hardware
> component.  It doesn't say anything about how alarms are reported, and it
> doesn't provide any details of the alarms; it is just a bitmask.
> >
> > The alarm-module draft OTOH, specifies how alarms are reported,
> generically.  It also provides a list of all active alarms.
> >
> > So if both modules are implemented (they don't have to be), the
> information can be viewed as redundant or just different views.
> >
> >
> > /martin
> >
> >
> >
> >>
> >> Many Thanks in advance !
> >>
> >>
> >> BR, Karen Nielsen
> >>