Re: [CCAMP] New Liaison Statement, "LS/r IETF CCAMP work on YANG Alarm Module Submission (reply to IETF-LS16 )"

stefan vallin <> Wed, 07 March 2018 11:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2457126CE8 for <>; Wed, 7 Mar 2018 03:08:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y6K0zjqYZjd1 for <>; Wed, 7 Mar 2018 03:08:55 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83640127137 for <>; Wed, 7 Mar 2018 03:08:54 -0800 (PST)
Received: by with SMTP id m69-v6so2611889lfe.8 for <>; Wed, 07 Mar 2018 03:08:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AwnpQK5GszF/hdCeEphmupYfDvuHMlxwTREi+M/VZf0=; b=suHJphrFSurPbxftk6rY0RrKmryWUjqJnHLqHOP4YrFLncL+F6m2TwWE4pojjInzrb 4Ty1g5BsExe3SVe7w0aPD5yIFU8BBbzXviDaF7Dag7RHWJe23ZcY+VQg79XUIB5P07xf FZ1qS59XS7WnuQiFOQnloQmCDJdZi6gyYN1CYKXP8xBQ3SaPLLTPZq0Rwkk/HeF5zdW2 4cl2fU+yXZpC98sWwZGxZvE6Iuu3FruNGn6tYd3KaS1qleIrzEpeM5+2y5nSZliT3YRl 9D/Cst/IWSBOf1YXPA1KY9IPjQoUO1sAHWf0sQnXlqiFRbSZDpJjb0D/dqyEMJQJfiYO uc9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AwnpQK5GszF/hdCeEphmupYfDvuHMlxwTREi+M/VZf0=; b=s36LNe1CdEOBAo9GMAtV0tla/N+JUYq5XGAzEn9HYu3Mf/NGx4M4KngLkOkQ3sRFLq lQSNXBIlYOAw640j+t3MlooqpWKJ2hhBTkmD2nWHKu8e7RJuMsq5fmpLiTn3eo0PhfXf XAnIBlOvQIW0BwN9WRQ1EopZshQuFYIl/8NsMNuiVdzb++o92uaOgsUcavRTZJGc20bm 7yoUP/jdepzYugQ+YBWr8B+EAk9NY0QfOMUzAZ8M/4O2GPvI4MFjvNJgIey0YGGfGKXM QIGYq5mpciihcLS2cx4dl29WUxWNDY/JY+J1Rjuingsq9iK81SvvHAuupoLT4/4HrncL jK0A==
X-Gm-Message-State: AElRT7GRFikGXLRJEB8aishEEsrGsgeajxd/dyegXMhTXHmQ/hUEF87E 6i4mzROGw43203Fznc5rNVWrgQ==
X-Google-Smtp-Source: AG47ELuiKatA9pbyBSEt1DaIoyAQWTEkdwDaQDU+p2MqwBx2EXwsnlBspYuKNa7KLB/xm8BtNvro/A==
X-Received: by with SMTP id c66mr16123005ljd.116.1520420932644; Wed, 07 Mar 2018 03:08:52 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id t24sm263075lfi.30.2018. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 07 Mar 2018 03:08:51 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: stefan vallin <>
In-Reply-To: <>
Date: Wed, 7 Mar 2018 12:08:47 +0100
Cc: Fatai Zhang <>, Daniele Ceccarelli <>,, Common Control and Measurement Plane Discussion List <>, Alia Atlas <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Liaison Statement Management Tool <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [CCAMP] New Liaison Statement, "LS/r IETF CCAMP work on YANG Alarm Module Submission (reply to IETF-LS16 )"
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Mar 2018 11:08:58 -0000

Thanks for the review! Happy to cooperate with ITU.
See comments inline:

Br Stefan and Martin

> On 02 Mar 2018, at 20:07, Liaison Statement Management Tool <> wrote:
> Title: LS/r IETF CCAMP work on YANG Alarm Module Submission (reply to IETF-LS16 )
> Submission Date: 2018-03-02
> URL of the IETF Web page:
> From: Hiroshi Ota <>
> To: Daniele Ceccarelli <>,Fatai Zhang <>
> Cc: Deborah Brungard <>,Scott Mansfield <>,Fatai Zhang <>,Alvaro Retana <>,Alia Atlas <>,Daniele Ceccarelli <>,Common Control and Measurement Plane Discussion List <>,
> Response Contacts: 
> Technical Contacts: 
> Purpose: For information
> Body: ITU-T Study Group 15 thanks IETF CCAMP WG for informing us about the adoption of a WG document on “YANG Alarm Module” and requesting review on the module.
Note that we have published a new version
> ITU-T Study Group 15 has been working, with collaboration with the ONF OIMT Group, on a Core Information Model in Recommendation G.7711 (ONF TR-512). The Core IM is neutral to any transport technology and is specified in UML, which is neutral to any management/control interface protocol. The Core IM can be pruned/refactored to provide a purpose-specific IM and translated into YANG code by automated tooling (xmi2yang). The OAM functionality, including Fault Management (FM) and Performance Monitoring (PM) is an area being modelled in G.7711 (ONF TR-512).
> Regarding the alarm management, we would like to see the FM and PM modelling based on the same architecture, and to harmonize with the requirements in Recommendation G.7710.
We have read G.7711 and see no FM requirements or models.
Have we missed anything in here? 
G.7710 provides Alarm Reporting Control, ARC,  and 
Alarm Severity Assignment Profile, ASAP.

Our approach is to define a core Alarm YANG model in the IETF that is
simple enough to get wide implementation support, and that can be
augmented by other models. We have by design simplified/excluded 
some of the ITU features in order to keep the ietf-alarms YANG module 
small and simple. 
See more details below. 

We could consider to make a separate augmenting module "itu-alarm-module”
that includes some of the more advanced ITU features. 
That could also include moving the X733 mapping out of this draft and place it
in the "itu-alarm-module”.

> The YANG module should also allow transport technology specific augmentations.
That is the intention. That would mostly mean to  define YANG identities for the 
technology specific alarm types.
> Regarding the scope of the YANG Alarm Module, the draft should explicitly state that the modeling of how transport resource alarms are raised and cleared by the underlying transport instrumentation is out of the scope of this draft. Specifically, the modelling of defect detection, defect coordination into fault cause, consequent action, persistency verification declaring fault cause as failure, and raising failure as alarm and its subsequent clearing should belong to the SDO/group that owns the transport technology.
Ok, will add that in Section 1 Introduction

> The alarm YANG draft adopts the X.733 alarm severities, but doesn’t support the function of alarm severity assignment (i.e., configuring the severity of an alarm type of a resource), i.e., the feature of the Alarm Severity Assignment Profile (ASAP) object of M.3160/M.3100 is not supported by the draft. Is this intended to be out of the scope of the alarm YANG draft?

Yes we have excluded that from being supported over the management 
interface. This for several reasons: 
1) Our experience is that the *management systems* will anyhow reassign
severity/priority levels based on contextual information. A managed system
has very little contextual information on services, topology, administrative
state etc that would allow it to set the “final” severity level. Therefore the 
ASP function is of little use. We did not see ASP being used based on 
our practical experience on ITU M.3160/M.3100 systems.

2) Setting proper severity levels is probably more complex than what is
offered by ASP, complex mechanism per alarm type and system is not
covered by the simple alarm type (probable cause) - severity mapping. 
This lends towards configurable severity levels being a local configuration
issue specific per system type and alarm type.

3) ASP makes the assumption that there is a 1-1 mapping between 
alarm-type (probable cause) and severity level. That is not necessarily true.

AlarmSeverityAssignment ::= SEQUENCE { 
       problem ProbableCause, 
       severityAssignedServiceAffecting AlarmSeverityCode  OPTIONAL,
       severityAssignedNonServiceAffecting AlarmSeverityCode  OPTIONAL,
       severityAssignedServiceIndependent AlarmSeverityCode  OPTIONAL

Assume a LOSS threshold, it makes perfect sense to have 3 thresholds, each
of them with a different severity. In our model that is one alarm type “loss” and 
an alarm can have a life-cycle (minor, major, critical, major, minor) for example.
This is one alarm-type “loss”. The benefit iof that is for example that it is one 
alarm rather than 3 in the alarm list (since probable cause/alarm type is a key).

The alarm severity assignment profile mechanism would force three alarm types
to be defined LOSS-threshold-1, LOSS-threshold-2 etc, each with separate 
severity assignment.

The above arguments for keeping ASAP out  of the IETF alarm model.

An ASAP mechanism could be defined in an augmenting module.
it would look something like the shelf criteria in this draft: resource, alarm-type, 
alarm-qualifier-match and corresponding  severity level.
But, again the problem is alarm types with several severity levels. Any thoughts on this?

> For alarm reporting control, the alarm YANG draft supports only the simple alarm shelf function. It doesn’t support the rich features of the Alarm Reporting Control (ARC) function of M.3160/M.3100, which is required by G.7710.

This is by design. The shelf mechanism is simpler to understand, 
implement and design. We are not convinced that ARC is required.
It is a fairly complex model. Our experience has not shown real usage
of ARC. For example, see is an ARC MIB, 
to our knowledge it is not widely spread. This said, a more advanced 
ARC feature could be defined as an extension in the future.

On a more philsophical perspective, rather than providing complex
mechanisms for the management system to configure advanced
filtering requirements we have formed strong requirements on alarm
quality, see appendix F in version 01. This is how the process industry has worked
in order to address the alarm overload and alarm quality problem. 
This puts the burden on the equipment/software vendor to implement 
proper alarm instrumentation rather than pushing the problem to complex 
configuration by the alarm manager.

> We support the clear separation of resource alarm life-cycle from the operator and administrative life-cycle of an alarm.
Good :)
> Listed below are specific comments from our review of the YANG Alarm Module
> 1.   Section 4.2, paragraphs 5 & 6 discuss unknow alarm type at design time and dynamic addition of alarm types using string. Please note that the Spec Model approach of the Core Information Model (ITU-T Recommendation G.7711 Annex G) (also in ONF TR-512.7) provides a generic formal way to allow run time enhancement/decoration.

G.7711 is a fairly generic UML extension approach.
The use of alarm-qualifier is a specific mechanism to allow for
dynamic alarm types which are included as key in the alarm list.
Alarm-qualifier roughly matches X.733 specific-problem but with the 
requirement that they must be published in the alarm inventory.

> 2.   Section 4.4, first paragraph, second last sentence: Add “and alarm type qualifier” so that the sentence becomes “This means that alarm notifications for the same resource, same alarm type and same alarm type qualifier are matched to update the same alarm instance.”

We will clarify this

> 3.   Section 4.5: What is the relationship (dependency) among “alarm clearance”, “alarm closing”, and “alarm deleting”. Will administrative deleting automatically results in operator closing? Need more clarification among the three types of alarm life-cycle. Otherwise will cause inconsistent handling of alarm among different systems.

Alarm clearance is the resource life-cycle, the instrumentation
clearing the alarm

Alarm closing is the operator life-cycle, the alarm is not important
from an operations perspective (might be cleared or not)

Deleting and alarm means it is removed from the list and therefore has no states…

Will improve the text in this section to make this more clear

> 4.   Section 4.5.1, first paragraph, second line: Editorial error: “change severity” occurs twice.

That is a feature, not a bug :)
"   From a resource perspective, an alarm can have the following life-
   cycle: raise, change severity, change severity, clear, being raised
   again etc”

The alarm list has the following structure:
[resource, alarm-type-id, alarm-type-qualifier], [(time, severity, text, cleared), (...), (...)]

[link42, highUtilization,-](t1, warning, “”,-), (t2, minor, “”, -),(t3, minor, “”, cleared)

> We appreciate again for the chance to exchange information. We would like take this opportunity to inform IETF that we are currently working on a new draft Recommendation that describes the requirement and information & data model for transport media management.
> Attachments:
> No document has been attached
> _______________________________________________
> CCAMP mailing list