Re: [netmod] New Version Notification for draft-sharma-netmod-fault-model-01.txt

[stefan vallin <[e-mail]>]

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


Stefan Vallin
[e-mail] <mailto:[e-mail]>
[phone]


> On 28 Oct 2016, at 01:04, Anurag Sharma <[e-mail]> wrote:
> 
> Hi,
> 
> A new version of "draft-sharma-netmod-fault-model-01” has been uploaded. In this version we have incorporated comments that we received on version "00". Please review the new version and let us know your comments.
> 
> We will also discuss with Martin and Stefan best path forward for draft-vallin-alarm-yang-module-00 and this draft.
> 
> Thanks,
> Anurag, Xian & Rajan
> 
>> On Oct 27, 2016, at 2:31 PM, [e-mail] wrote:
>> 
>> 
>> A new version of I-D, draft-sharma-netmod-fault-model-01.txt
>> has been successfully submitted by Anurag Sharma and posted to the
>> IETF repository.
>> 
>> Name:		draft-sharma-netmod-fault-model
>> Revision:	01
>> Title:		Alarm YANG Model
>> Document date:	2016-10-27
>> Group:		Individual Submission
>> Pages:		28
>> URL:            https://www.ietf.org/internet-drafts/draft-sharma-netmod-fault-model-01.txt
>> Status:         https://datatracker.ietf.org/doc/draft-sharma-netmod-fault-model/
>> Htmlized:       https://tools.ietf.org/html/draft-sharma-netmod-fault-model-01
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-sharma-netmod-fault-model-01
>> 
>> Abstract:
>>  This document describes the Alarm YANG data model for modeling and
>>  reporting standing alarm conditions.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod