Re: [CCAMP] YANG Alarm Module in CCAMP?

[t.petch <[e-mail]>]

<inline tp>

----- Original Message -----
From: "stefan vallin" <[e-mail]>
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






>
> 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] 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
> 主题: 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
>
> Hi Martin, Stefan,
>
https://www.ietf.org/mailman/listinfo/ccamp