Subject: [CCAMP] draft-vallin-netmod-alarm-module again

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Oct 2017 11:13:54 +0200 (CEST)

Hi,

We have received quite a lot of emails indicating support for the
draft "draft-vallin-netmod-alarm-module".  People are asking why
nothing happens with this draft.

It was decided that CCAMP might be the best place for this draft, but
since then people have expressed that they rather want NETMOD to work
on it.

I sent this email to CCAMP but never got any feedback:
https://mailarchive.ietf.org/arch/msg/ccamp/f4qUNkpsT5dVF_1l9Ibd3hH1YA4/?qid=2187bb6a3443f12d15a29a03486f0754

It would be much appreciated if anyone in CCAMP that are also working
on the generic alarm functionality in ITU could send feedback on this
document.

The document can be found here:
https://datatracker.ietf.org/doc/draft-vallin-netmod-alarm-module

/martin

---

From: Zhenghaomian <[email-masked]>
Date: Mon, 9 Oct 2017 09:28:54 +0000

Hello Martin, 

Great to see this work brought back, actually we are interested and looking forward to see this work progress in IETF 99 but there was no presentation and we failed to find any of the co-authors of this draft. 

We had similar idea about the alarm work and there was one draft published as https://tools.ietf.org/html/draft-sharma-netmod-fault-model-01 . we have reviewed both this draft and draft-vallin-netmod-alarm-module, and would like to drive on merging into one. It was observed that draft-vallin is more complete than draft-sharma, but the only problem is that the reference to ITU-T work is too old. We are also seeking for some support from ITU side, so that we can update the draft after there were agreement. 

Please feel free to comment if you have other ideas, thank you. 

Best wishes,
Haomian

-----邮件原件-----
发件人: CCAMP [mailto:[email-masked]] 代表 Martin Bjorklund
发送时间: 2017年10月9日 17:14
收件人: [email-masked]
抄送: [email-masked]; [email-masked]
主题: [CCAMP] draft-vallin-netmod-alarm-module again

Hi,

We have received quite a lot of emails indicating support for the draft "draft-vallin-netmod-alarm-module".  People are asking why nothing happens with this draft.

It was decided that CCAMP might be the best place for this draft, but since then people have expressed that they rather want NETMOD to work on it.

It would be much appreciated if anyone in CCAMP that are also working on the generic alarm functionality in ITU could send feedback on this document.

/martin

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 9 Oct 2017 11:32:08 +0200

Dear all,

I'm also interested to see if CCAMP people are really interested to 
provide feedback...

Regards, Benoit
> .

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 9 Oct 2017 13:28:38 +0000

Martin,

what was agreed was to have the draft re-published as a CCAMP draft and then presented at IETF99 during the CCAMP session. Since none of the two things happened it is quite difficult to have people in CCAMP noticing it, reviewing it and providing comments. 

BR
Daniele  

> -----Original Message-----
> From: CCAMP [mailto:[email-masked]] On Behalf Of Martin
> Bjorklund
> Sent: lunedì 9 ottobre 2017 11:14
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [CCAMP] draft-vallin-netmod-alarm-module again
> 
> Hi,
> 
> We have received quite a lot of emails indicating support for the draft "draft-
> vallin-netmod-alarm-module".  People are asking why nothing happens with
> this draft.
> 
> It was decided that CCAMP might be the best place for this draft, but since
> then people have expressed that they rather want NETMOD to work on it.
> 
> It would be much appreciated if anyone in CCAMP that are also working on
> the generic alarm functionality in ITU could send feedback on this document.
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Oct 2017 15:40:23 +0200 (CEST)

Hi,

Daniele Ceccarelli <[email-masked]> wrote:
> Martin,
> 
> what was agreed was to have the draft re-published as a CCAMP draft
> and then presented at IETF99 during the CCAMP session.

Ok, but this was not communicated to the authors.  See the email that
I quoted in my last email, to which I never got a reply.

Re. re-publishing as CCAMP draft, doesn't the WG first have to
formally adopt it?  Maybe the process is different in other WGs, but
I'm used to a process where the WG first review the document, then
adopt it.

> Since none of the two things happened it is quite difficult to have
> people in CCAMP noticing it, reviewing it and providing comments.

The draft is out there (the individual version), and we would still
appreciate feedback on the content!

/martin

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 9 Oct 2017 13:54:44 +0000

Martin,

published in CCAMP means to publish it as: draft-vallin-ccamp-alarm-module, i.e. an individual contribution in CCAMP, showing up on CCAMP page, not a CCAMP WG draft.

We never spoke of a straight adoption without any WG polling, IPR declarations and so on.
Both the Netmod chairs and the routing AD said in their opinion the draft should have been moved to CCAMP and the authors have been copied in all of the email exchanges.

BR
Daniele (not speaking for both the CCAMP chairs)

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: lunedì 9 ottobre 2017 15:40
> To: Daniele Ceccarelli <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-vallin-netmod-alarm-
> [email-masked]
> Subject: Re: [CCAMP] draft-vallin-netmod-alarm-module again
> 
> Hi,
> 
> Ok, but this was not communicated to the authors.  See the email that I
> quoted in my last email, to which I never got a reply.
> 
> Re. re-publishing as CCAMP draft, doesn't the WG first have to formally
> adopt it?  Maybe the process is different in other WGs, but I'm used to a
> process where the WG first review the document, then adopt it.
> 
> The draft is out there (the individual version), and we would still appreciate
> feedback on the content!
> 
> 
> /martin
> 
> 
> >
> > BR
> > Daniele
> >
> > > draft "draft- vallin-netmod-alarm-module".  People are asking why
> > > It was decided that CCAMP might be the best place for this draft,
> > > but since then people have expressed that they rather want NETMOD to
> work on it.
> > >
> https://mailarchive.ietf.org/arch/msg/ccamp/f4qUNkpsT5dVF_1l9Ibd3hH1
> > > Y
> > > A4/?qid=2187bb6a3443f12d15a29a03486f0754
> > >
> > > It would be much appreciated if anyone in CCAMP that are also
> > > working on the generic alarm functionality in ITU could send feedback on
> this document.
> > >

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Oct 2017 16:07:47 +0200 (CEST)

Hi,

Daniele Ceccarelli <[email-masked]> wrote:
> Martin,
> 
> published in CCAMP means to publish it as:
> draft-vallin-ccamp-alarm-module,

Again; this has not been communicated to the authors.  We have not
seen an email where this was stated.

Do you think that we will get feedback from the people in the CCAMP WG
that also work on general alarm functionality in the ITU if we post
it as draft-vallin-ccamp-alarm-module?  If so, we'll do that.

/martin

> i.e. an individual contribution in CCAMP, showing up on CCAMP page, not a CCAMP WG draft.
>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 9 Oct 2017 16:14:37 +0200

Daniele,

I'm with Martin here. Can we please focus on having the right content 
and the right feedback, before focusing on the process.

Regards, Benoit

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 9 Oct 2017 14:29:04 +0000

Martin, Benoit,

i can't force the WG to review a draft (even if we got feedbacks last time and we just had another reply from Haomian earlier today).
What I can say is that there are more chances to have the working group review a ccamp draft than a netmod draft and even more if the draft is presented during a meeting.

BR
Daniele  

> From: Benoit Claise [mailto:[email-masked]]
> Sent: lunedì 9 ottobre 2017 16:15
> To: Daniele Ceccarelli <[email-masked]>; Martin Bjorklund
> <[email-masked]>
> Cc: [email-masked]; [email-masked]
> I'm with Martin here. Can we please focus on having the right content and
> the right feedback, before focusing on the process.
> 
> Regards, Benoit
> > Martin,
> >
> > published in CCAMP means to publish it as: draft-vallin-ccamp-alarm-
> module, i.e. an individual contribution in CCAMP, showing up on CCAMP
> page, not a CCAMP WG draft.
> >
> > Both the Netmod chairs and the routing AD said in their opinion the draft
> should have been moved to CCAMP and the authors have been copied in all
> of the email exchanges.
> >
> > BR

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Oct 2017 16:41:18 +0200 (CEST)

Hi,

Daniele Ceccarelli <[email-masked]> wrote:
> Martin, Benoit,
> 
> i can't force the WG to review a draft (even if we got feedbacks last
> time and we just had another reply from Haomian earlier today).
> What I can say is that there are more chances to have the working
> group review a ccamp draft than a netmod draft and even more if the
> draft is presented during a meeting.

Ok.  But do we agree that the reason for potentially doing this work
in CCAMP is b/c there are people active in CCAMP that also work on
generic alarm functionality in the ITU?

The reason I ask this is that after we had the previous discussion
re. the home of this draft, several people have asked why it isn't
done in NETMOD, and expressed the opinion that it should be done
there.  Reading the CCAMP charter, it is not clear to me how this
document would fit.  So it would be very valuable to get some feedback
indicating that people that also work with alarms in ITU are
interested in this work.

/martin

> > and

---

From: stefan vallin <[email-masked]>
Date: Mon, 9 Oct 2017 18:57:19 +0200

Hi All!
Please see two responses I wrote last year:
* 31 oct 2016: Comparison of Vallin and Sharma Draft
* 12 dec 2016: Comment on the ITU-T reference.

Vallin vs Sharma
**********************

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.

ITU-T
****************
First of all, I need to stress the fact that we carefully *did not* do the module design based on X.733.
There is a *separate*, optional, module to map to X733 which is still relevant for *some* management platforms.
So I do not really agree on that top-level comment.

But also note that G.7710 and G.806 are not replacing X.733. X.733 defines the information model
for *alarm reporting* along with the ASN.1 data definitions. G.7710 and G.806 defines the equipment fault
management functions that leads to alarm reporting at the end. The alarm list functions and alarm notifications
are not defined by G.7710 and G.806 to my knowledge.

G.806
Not so much related to general alarm management, this is more specifying instrumentation and 
behaviour for transmission alarm types like LOS, AIS etc.

G.7710
* Alarm Report Control maps to alarm shelving in the vallin alarm yang model. We could rename
  to ARC. Will do a detailed study if it maps 100% or if there is missing pieces.
* Alarm Severity Assignment Profile, configurable severity levels could be introduced. 
I doubt this being useful however. That is more for the management application itself rather than 
configuring on the device. But if you see requirements and scenarios for that, we can add it.

RFC7260
We need to make sure all requirements are covered. I think we are fine. 
Requirements on alarm filters, avoiding spurious alarms etc are covered

RFC5860
See above.

So in summary, there would be very little work to reference 
RFC7260, RFC5860, G.7710, G.806.
There are no big missing pieces, more on terminology especially ARC.

Stefan Vallin
[email-masked]
+46705233262

> On 09 Oct 2017, at 11:28, Zhenghaomian <[email-masked]> wrote:
> 
> Hello Martin, 
>