Re: [CCAMP] YANG Alarm Module in CCAMP?

[stefan vallin <[e-mail]>]

Hi!
>  
> 1)      I agree this work is useful, i.e., to have a generic alarm model draft in NETMOD. We had a draft on related topic ashttps://tools.ietf.org/html/draft-sharma-netmod-fault-model-01 <https://tools.ietf.org/html/draft-sharma-netmod-fault-model-01>, unfortunately I have not got a chance to  compare the gap between this draft and yours, did you notice this draft?  And any comments? 
Yes, I did review it, see mail 31 oct 2016 in NETMOD. Included my response at the end of this email.

> 2)      I am confused with your 2nd comment in the following email. When you said  ‘We will have a problem if different technologies will define different alarm-modules.’, IMHO I have an opposite opinion, if different technologies are using same alarm-modules, that would be a trouble. I understand there is a lot of common stuff among different technical alarms, but it is an adventurous assumption to restrict any tech-specific work. Could you confirm on this?
Disagree :)
I am convinced that there is a generic alarm model irrespective of technology.
Then of course different technologies need to define different alarm types for the common alarm model.
If the generic alarm model restricts requirements for technology specific details, that points to a bug in the generic alarm model.
Without starting any argumentation if X.733 was good or bad, it did prove my assumption to some level.

> 3)      If there is any tech-specific alarm work (may not be much), especially for L0/L1/microwave, that would belong to CCAMP. It is also difficult to conclude now whether it will be defining additional identities or model augmentation.

Both augmentation and alarm types with identitities are fine.
But we have a problem if every working group creates a different alarm model. Then we are back to square zero

>  
> My 2 cents,
> Haomian

Review of sharma-netmod-fault-model
=============================
Hi!
We have reviewed draft-sharma-netmod-fault-model-01.
Glad to see that more people are interested in an alarm YANG module.
See comments below.

Please note that Martin and me has published a netmod alarm module:
https://www.ietf.org/id/draft-vallin-netmod-alarm-module-00.txt <https://www.ietf.org/id/draft-vallin-netmod-alarm-module-00.txt>
We are also about to published an updated version of this after comments on 
the netmod mailing list

This is updated from the version you are referring to:
https://tools.ietf.org/html/draft-vallin-alarm-yang-module-00 <https://tools.ietf.org/html/draft-vallin-alarm-yang-module-00>

Some comments after reviewing your module:
Overall comments
===============
*The sharma draft is a subset of the functionality in the vallin draft.
On top of the alarm-list, the vallin draft covers:
- alarm quality/usability requirements
- alarm summary
- alarm history (optional YANG feature)
- alarm operator actions like ack (optional YANG feature)
- alarm inventory (which are the possible alarms)
- alarm shelving (filtering)
- do not impose X733, rather this is an add-on

* Stateful vs notification-based definition of alarms.
 
The vallin draft focuses on representing alarms as an alarm state on a resource.
The notifications refers to alarm state changes for a specific alarm on a specific resource.
The alarm list represents the alarm state for a given resource and alarm type.

The sharma draft focuses on a notification focused view on alarms.
The alarm list represents the alarm notifications. The management system has to
correlate the notifications into an actual alarm state.

* On X733
The vallin draft does not use the X733 as a mandatory *core* model, rather it allows for X733 mapping when needed. 
While X733 has been the root for most telecom oriented alarm systems, it adds a bit of historic overhead.
For example globally standardised probable cause values have not shown to be useful in some cases.
X733 represents notifications and not state (see above).
Therefore an alarm is either cleared or minor for example.
The vallin draft clearly separates this. Severity is one thing, clearance is another.

* Terminology
the module is named “fault” while modelling alarms.
See for example X733 for definitions of fault, errror and alarm.



Detailed comments
================

Section 2
"  New network architectures that include controllers, orchestrators,
   PCE, applications, etc., require new alarm types and probable causes
   to be defined.  These new alarm types and probable causes will be
   defined in the next version of the model.”

We doubt that having globally defined probable causes is a scalable way forward.
Did not work well in X733 or RFC3877.

Probable cause values from standards has been more of historical value then real
value to alarm operators and alarm systems. Most telecom oriented alarm systems
require this alarm attribute. However the actual values are different for all management
systems. It is a confusing area with conflicting enum values. Our approach is different.
We consider this to be a configurable mapping to match the needs of the management
system and no values are defined in the alarm module.
It is also kept separate as a X733 mapping rather than part of the core model.


Section 2.2

The definition of 'alarm-id' is unclear. 
"In most cases this will be a combination of entity-type, entity-id,
probable-cause and severity”

entity-type: string
entity-id: inet:uri
probable-cause: identity-ref
severity: enum

Several questions on this:
a) why does not the entity (called resource in the vallin draft) refer to a path in the YANG data tree?
In the vallin draft we use an instance-identifier. We also allow for other resource instances based on SNMP or even a string as last resort.

b) Alarm list key
- assume you have a threshold alarm with the following life-cycle:
  T1, T2, T3, are the times for the alarm state changes.
  T1: raise, minor
  T2: major
  T3: clear

In the sharma draft this will be  *three different entries* in the alarm list. The client
would have to correlate those.

In the vallin draft this is *one entry*, one alarm, with three different states.
The vallin draft also clearly separates the severity from the clearance state.
The final state model is
(major, cleared)
This is important, what was the severity of the alarm and is it cleared or not?
This is not easily seen in the sharma draft.

This implies that the sharma draft alarm list is more of a notification log rather than an 
alarm-list that shows the current state. The vallin draft  alarm-list focuses on current state
of the alarms. Notifications represent state changes on the alarm state.

c) the service-affecting flag
This is superfluous. If the X733 severity levels are set correctly this is enough for
service-affecting or not. See the X733 definition of severity levels.
The vallin draft also has a leaf impacted-resources. In this leaf an alarm can refer to
affected/impacted services.

d) alarm-sequence number
Not needed, NETCONF has notification replay and uses SSH sessions.
Furthermore, since the sharma alarm list key is the identification of an alarm notification, why is this needed at all?
There has been these kinds of var-binds in SNMP Alarm MIBs as well, it was a bit flawed there as well: you could use informs instead of trap-pdus. How does this work with filtering mechanisms?
Do not try to do protocol stuff in the model.


e) House-keeping
Unclear how the list is managed, when are entries removed?


f) Other considerations:
- The vallin draft allows for more flexible resource (entity) identification, see below:

The primary mechanism is an instance-identifier so that a node in the data-tree can be referenced
The sharma draft uses  string/uri which is another domain than the module. A bit strange, say you have
an interface alarm, why should you not send an alarm on the path to interface in the data-model.

The Vallin draft also allows for other naming schemes, for example SNMP OIDs:
  typedef resource {
    type union {
      type instance-identifier {
        require-instance false;
      }
      type yang:object-identifier;
      type string;
    }


The alarm also has an optional leaf for referring to the alarming resource using an alternate naming scheme
        +--ro alarm* [resource alarm-type-id alarm-type-qualifier]
           +--ro resource                      resource
           +--ro alarm-type-id                 alarm-type-id
           +--ro alarm-type-qualifier          alarm-type-qualifier
           +--ro alt-resource*                 resource

So the alarm can use both the instance-identifer and the SNMP OID for the alarming interface for example.



br Stefan and Martin







> 发件人: CCAMP [mailto:[e-mail] <mailto:[e-mail]>] 代表 stefan vallin
> 发送时间: 2017年5月9日 18:15
> 收件人: Fatai Zhang
> 抄送: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; Martin Bjorklund
> 主题: Re: [CCAMP] YANG Alarm Module in CCAMP?
>  
> Hi All! 
> Thanks for reading the doc.
> A couple of comments:
> 1) I personally agree it fits in NETMOD, but the discussion in NETMOD said we would get much more relevant input in CCAMP since there is more alarm expertise in this group. So this is circular :)
> 2) I do not really agree when you say "extend it with technological aspect”, “optical alarm Yang should be in the scope of CCAMP” requires a dedicated CCAMP YANG module. The tech specific alarms are “alarm types” according to the alarm-module. Those are defined as YANG identities. So the tech specific part is “only” defining the corresponding identity. No real model here, just the identities. We will have a problem if different technologies will define different alarm-modules.
> 3) To Petch point on "I am conscious of how much time I spent on Sharon's SMI versions, which I did not then see in the wild”.
> Same here :) I took part of a couple of implementations as well.
> And that is one of the main reasons why I think an Alarm YANG is critical. Why do we not see the IETF Alarm MIB in the wild?
> * It came too late, all devices had proprietary ways of reporting alarms (if devices had a notion of alarms at all….). Lets do an Alarm YANG now to avoid that problem.
> * Since it had to add on top of existing MIBs it became a complex alarm mapping MIB (Mapping existing notfs into an alarm model) rather than an alarm MIB. That made it very complex.
>  
> Here is a presentation
>  
>  
> Stefan Vallin
> [e-mail] <mailto:[e-mail]>
> [phone]
>  
> On 09 May 2017, at 11:51, Fatai Zhang <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi Daniele and all,
> 
> Yes, I agree with you.
> 
> As I said to Lou in another thread, I think the generic alarm Yang could be defined in either Netmod or Teas, but the technology specific such as optical alarm Yang should be in the scope of CCAMP. 
> 
> 
> 
> Thanks
> 
> Fatai
> 
> 
> -----邮件原件-----
> 发件人: CCAMP [mailto:[e-mail] <mailto:[e-mail]>] 代表 Daniele Ceccarelli
> 发送时间: 2017年5月9日 17:34
> 收件人: Daniele Ceccarelli; Martin Bjorklund; [e-mail] <mailto:[e-mail]>
> 抄送: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> 主题: Re: [CCAMP] YANG Alarm Module in CCAMP?
> 
> Hi authors, NETMOD chairs, CCAMP WG,
> 
> i went through the document and, despite believing it's a super well written and understandable document, I don't think it fits in CCAMP. 
> This is a more generic work with a scope broader than CCAMP. At a first thought I would say TEAS, but also TEAS is not the right place since it's not related to traffic engineering. 
> The day you plan to extend it with technological aspect, then CCAMP would be its natural home.
> 
> Fatai, do you agree with the analysis?
> 
> BR
> Daniele  
> 
> 
> 
> -----Original Message-----
> From: CCAMP [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Daniele Ceccarelli
> Sent: lunedì 8 maggio 2017 16:40
> To: Martin Bjorklund <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: Re: [CCAMP] YANG Alarm Module in CCAMP?
> 
> Hi Martin, Stefan,
> 
> thanks a lot for sharing the draft. I'll read it and let you know my personal opinion ASAP.
> 
> Working group, could you please do the same and share your thoughts?
> 
> Thanks
> Daniele  
> 
> -----Original Message-----
> From: CCAMP [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Martin Bjorklund
> Sent: lunedì 8 maggio 2017 10:10
> To: [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: [CCAMP] YANG Alarm Module in CCAMP?
> 
> Hi,
> 
> We have been working an a generic YANG module for alarm management for a while (draft-vallin-netmod-alarm-module).  The model is based on experience from several alarm management system over the years.  It has been presented in NETMOD (reflected in the draft name), but the NETMOD chairs felt that maybe CCAMP would be a better home for this draft.
> 
> So our question is if CCAMP would be interested in working on this draft?
> 
> The latest version is available as:
> https://www.ietf.org/internet-drafts/draft-vallin-netmod-alarm-module-02.txt <https://www.ietf.org/internet-drafts/draft-vallin-netmod-alarm-module-02.txt>
> 
>  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.
> 
> 
> /martin & stefan
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>