Subject: [CCAMP] YANG Alarm Module in CCAMP?

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 May 2017 10:09:42 +0200 (CEST)

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

  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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 8 May 2017 14:40:21 +0000

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:[email-masked]] On Behalf Of Martin Bjorklund
Sent: lunedì 8 maggio 2017 10:10
To: [email-masked]
Cc: [email-masked]
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?

  Abstract:

/martin & stefan

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

---

From: t.petch <[email-masked]>
Date: Tue, 9 May 2017 10:02:36 +0100

I am content to read and comment thereon but do not know how widely this
would be implemented.  I am conscious of how much time I spent on
Sharon's SMI versions, which I did not then see in the wild.  Dan might
know better.

Tom Petch

----- Original Message -----
From: "Daniele Ceccarelli" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 08, 2017 3:40 PM

Hi Martin, Stefan,

thanks a lot for sharing the draft. I'll read it and let you know my
personal opinion ASAP.

Thanks
Daniele

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Martin
Bjorklund
Sent: lunedì 8 maggio 2017 10:10
To: [email-masked]
Cc: [email-masked]
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.

The latest version is available as:
https://www.ietf.org/internet-drafts/draft-vallin-netmod-alarm-module-02
.txt

  Abstract:

/martin & stefan

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 9 May 2017 09:34:18 +0000

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:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: lunedì 8 maggio 2017 16:40
To: Martin Bjorklund <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [CCAMP] YANG Alarm Module in CCAMP?

Hi Martin, Stefan,

Thanks
Daniele  

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: lunedì 8 maggio 2017 10:10
To: [email-masked]
Cc: [email-masked]
Subject: [CCAMP] YANG Alarm Module in CCAMP?

Hi,

  Abstract:

/martin & stefan

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 9 May 2017 09:51:27 +0000

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:[email-masked]] 代表 Daniele Ceccarelli
发送时间: 2017年5月9日 17:34
收件人: Daniele Ceccarelli; Martin Bjorklund; [email-masked]
抄送: [email-masked]; [email-masked]
主题: Re: [CCAMP] YANG Alarm Module in CCAMP?

BR
Daniele  

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: lunedì 8 maggio 2017 16:40
To: Martin Bjorklund <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [CCAMP] YANG Alarm Module in CCAMP?

Hi Martin, Stefan,

Thanks
Daniele  

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: lunedì 8 maggio 2017 10:10
To: [email-masked]
Cc: [email-masked]
Subject: [CCAMP] YANG Alarm Module in CCAMP?

Hi,

  Abstract:

/martin & stefan

---

From: stefan vallin <[email-masked]>
Date: Tue, 9 May 2017 12:14:44 +0200

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
[email-masked]
+46705233262

> On 09 May 2017, at 11:51, Fatai Zhang <[email-masked]> wrote:
> 
> Hi Daniele and all,
> 
> Yes, I agree with you.
>

---

From: "Yemin (Amy)" <[email-masked]>
Date: Wed, 10 May 2017 01:07:01 +0000

Regardless which WG should take care of this work, the alarm YANG itself is worthy to work on.
In the microwave YANG module, we want to define some microwave specific alarms based on generic alarm definition. Maybe as the way Stefan said, just to define additional YANG identities.

BR,
Amy
From: CCAMP [mailto:[email-masked]] On Behalf Of stefan vallin
Sent: Tuesday, May 09, 2017 6:15 PM
To: Fatai Zhang <[email-masked]>
Cc: [email-masked]; [email-masked]; Martin Bjorklund <[email-masked]>
Subject: Re: [CCAMP] YANG Alarm Module in CCAMP?

Hi All!

Here is a presentation

Stefan Vallin
[email-masked]<mailto:[email-masked]>
+46705233262

On 09 May 2017, at 11:51, Fatai Zhang <[email-masked]<mailto:[email-masked]>> wrote:

Hi Daniele and all,

Yes, I agree with you.

Thanks

Fatai

-----邮件原件-----
发件人: CCAMP [mailto:[email-masked]] 代表 Daniele Ceccarelli
发送时间: 2017年5月9日 17:34
收件人: Daniele Ceccarelli; Martin Bjorklund; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [CCAMP] YANG Alarm Module in CCAMP?

BR
Daniele

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: lunedì 8 maggio 2017 16:40
To: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] YANG Alarm Module in CCAMP?

Hi Martin, Stefan,

Thanks
Daniele

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: lunedì 8 maggio 2017 10:10
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] YANG Alarm Module in CCAMP?

Hi,

 Abstract:

/martin & stefan

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

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

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

---

From: Zhenghaomian <[email-masked]>
Date: Wed, 10 May 2017 01:41:45 +0000

Hi, Stefan,

Thank you for bring the draft and the document, please find some of my comments as follow:

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 as 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?

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?

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.

My 2 cents,
Haomian
发件人: CCAMP [mailto:[email-masked]] 代表 stefan vallin
发送时间: 2017年5月9日 18:15
收件人: Fatai Zhang
抄送: [email-masked]; [email-masked]; Martin Bjorklund
主题: Re: [CCAMP] YANG Alarm Module in CCAMP?

Hi All!

Here is a presentation

Stefan Vallin

Hi Daniele and all,

Yes, I agree with you.

Thanks

Fatai

-----邮件原件-----
发件人: CCAMP [mailto:[email-masked]] 代表 Daniele Ceccarelli
发送时间: 2017年5月9日 17:34
收件人: Daniele Ceccarelli; Martin Bjorklund; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [CCAMP] YANG Alarm Module in CCAMP?

BR
Daniele

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: lunedì 8 maggio 2017 16:40
To: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] YANG Alarm Module in CCAMP?

Hi Martin, Stefan,

Thanks
Daniele

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: lunedì 8 maggio 2017 10:10
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] YANG Alarm Module in CCAMP?

Hi,

 Abstract:

/martin & stefan

---

From: stefan vallin <[email-masked]>
Date: Wed, 10 May 2017 09:14:14 +0200

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 o…
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 addi…

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

> 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:[email-masked] <mailto:[email-masked]>] 代表 stefan vallin
> 发送时间: 2017年5月9日 18:15
> 收件人: Fatai Zhang
> 抄送: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Martin Bjorklund
> [email-masked] <mailto:[email-masked]>
> +46705233262
>  
> On 09 May 2017, at 11:51, Fatai Zhang <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Daniele and all,
> 
> Yes, I agree with you.
> 
> 发件人: CCAMP [mailto:[email-masked] <mailto:[email-masked]>] 代表 Daniele Ceccarelli
> 发送时间: 2017年5月9日 17:34
> 收件人: Daniele Ceccarelli; Martin Bjorklund; [email-masked] <mailto:[email-masked]>
> 抄送: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> From: CCAMP [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Daniele Ceccarelli
> To: Martin Bjorklund <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> From: CCAMP [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Martin Bjorklund
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> 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:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>

---

From: t.petch <[email-masked]>
Date: Wed, 10 May 2017 10:25:49 +0100

<inline tp>

----- Original Message -----
From: "stefan vallin" <[email-masked]>
Sent: Wednesday, May 10, 2017 8:14 AM

>
> 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

<tp>

Yes, if there is to be an Alarm module in YANG, then a base module with
technology specific extensions seems the right way to go (and that is
much easier in YANG than ever it was in SMI).

But as the references to X.733 hint at, is this work for the IETF or
does it belong in ITU-T? I note that with LANs, the IETF did the early
work but even the MIB modules got transferred out of the IETF (to the
IEEE).   When we produced the Alarm MIB Modules, I felt that the work
was at the edge of the expertise of the IETF with perhaps not as many
reviews as would be desirable.

So when I read from the NETMOD WG something along the lines of 'Not
here' and then something similar from the CCAMP WG, well I think perhaps
not IETF but ITU-T.

Tom Petch

========================

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>

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

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

Section 2

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

entity-type: string
entity-id: inet:uri

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

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

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:[email-masked]
<mailto:[email-masked]>] 代表 stefan vallin
> 发送时间: 2017年5月9日 18:15
> 收件人: Fatai Zhang
> 抄送: [email-masked] <mailto:[email-masked]>;
[email-masked] <mailto:[email-masked]>; Martin Bjorklund
> 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”.
> 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 [email-masked] <mailto:[email-masked]>
> +46705233262
>
> On 09 May 2017, at 11:51, Fatai Zhang <[email-masked] 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:[email-masked]
<mailto:[email-masked]>] 代表 Daniele Ceccarelli
> 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.
> From: CCAMP [mailto:[email-masked]
<mailto:[email-masked]>] On Behalf Of Daniele Ceccarelli

---

From: stefan vallin <[email-masked]>
Date: Wed, 10 May 2017 20:05:06 +0200

Hi!
> not IETF but ITU-T.

i think that would be a mistake by IETF…
We have to admit, alarms is a fundamental piece of any device or controller.
IETF has a good history of defining *working and interoperable* standards.
Why should IETF skip alarms?

And, note well, the ietf-alarms module is not even close to the X.733 piece from a design perspective.
I am just referring to the principle of a generic alarm module.
/s

Stefan Vallin
[email-masked]
+46705233262