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

[stefan vallin <[e-mail]>]

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 <[e-mail]> 
> Sent: 20. september 2018 10:31
> To: Karen Elisabeth Egede Nielsen <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: draft-ietf-ccamp-alarm-module-02
> 
> Hi,
> 
> Karen Elisabeth Egede Nielsen <[e-mail]> 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
>>