Re: [CCAMP] comments for draft-ietf-ccamp-alarm-module-06

stefan vallin <stefan@wallan.se> Mon, 07 January 2019 08:35 UTC

Return-Path: <stefan@wallan.se>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7963130DE7 for <ccamp@ietfa.amsl.com>; Mon, 7 Jan 2019 00:35:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wallan-se.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyVdTjAMUujV for <ccamp@ietfa.amsl.com>; Mon, 7 Jan 2019 00:35:31 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE464129B88 for <ccamp@ietf.org>; Mon, 7 Jan 2019 00:35:30 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id k19-v6so37337393lji.11 for <ccamp@ietf.org>; Mon, 07 Jan 2019 00:35:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wallan-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UEDnRgu5rXqwPZHz8UU0Ey58sGizwwITACpyrN0XJFg=; b=ZDeaE6/bCRPRkheejwcf27fmvYJZpXP5h0enpAlV3+2hvEnLfaaBPXLZuZKX8Gg2pM IMsKnO6HS52rS8ElPvs3Xzg/tmb31KfLR3YwVUJwAWK+kwsHvopcnCjCavCR3F2TdRUC Z6WZH6QJOOo+CGh90lbT339772lqb78oY2dD/rLq0LCskZ2Yom+j5viFxgDr6OvJYFJL jedONXQ9gxWljzDVNHQ237RgPns0g0jUMNd4BSEQSkKP3ocHBP1/PL3eSmdKHIgxVYZ0 zB+sVOSZT2VWJ6GNM7XC+c6v09u7eZOFdqz+OvcYV+2/2O9g8+UNVSI5adVnOOC5mgIe xWzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UEDnRgu5rXqwPZHz8UU0Ey58sGizwwITACpyrN0XJFg=; b=NJVIecsnNgIwhau6lTGGxmdxtJq6OwfddTcqLbptU3AH4OrgWjhkfUIcdTh0x7i4UM YTTGxPLmP26M8pdY6SrVI0tavWKGDDh561igb56rvc1N0425LKObUb7kqVcItyjTpLB8 yqkTpAgjfsRlVYkO/Ed15FSAywnIv6+XlTLkkv3aq9Hp+WoEl18m78r0zf1go1C5aCFH 3ov/cY2HY+ZG+nNdTpZ9S4nFpnomQCjHhuUH52kBdhT7ncjh+S9vaY5cVkAyYxJEiUNL 2Gfi2/wK7J+CjbIfcvexzU/6cGwk7BfCnKIdiHkKfBfXLv1WRgnmv65dyb/9cxHAzVZ/ xsfQ==
X-Gm-Message-State: AJcUukeTod+BVGiDSDs8Xy2mpVpgc5sYGBbug2Oh2zcWkd51TE5jgAzI sGbnUZg+MELJrf2EOZO6RFtUXeBA3Vc=
X-Google-Smtp-Source: ALg8bN74w5VV+To1P5VqFuitWx1YlZyaDOePn7F6/tKAc5erzCDMYiblafVN6A2arak0t6i+GX228g==
X-Received: by 2002:a2e:8945:: with SMTP id b5-v6mr5084445ljk.55.1546850128866; Mon, 07 Jan 2019 00:35:28 -0800 (PST)
Received: from [192.168.72.11] (h95-155-237-105.cust.a3fiber.se. [95.155.237.105]) by smtp.gmail.com with ESMTPSA id z6sm12342965lfa.87.2019.01.07.00.35.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Jan 2019 00:35:28 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: stefan vallin <stefan@wallan.se>
In-Reply-To: <A8219E7785257C47B75B6DCE682F8D2FA645AFA9@nkgeml513-mbx.china.huawei.com>
Date: Mon, 7 Jan 2019 09:35:27 +0100
Cc: "ccamp@ietf.org" <ccamp@ietf.org>, Wangyonglong <wangyonglong@huawei.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F990C7F8-6B46-4DF0-B238-22889069E99A@wallan.se>
References: <A8219E7785257C47B75B6DCE682F8D2FA645AFA9@nkgeml513-mbx.china.huawei.com>
To: "Xiajinwei (Jinwei Xia, Network)" <xiajinwei@huawei.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/4ylU_bGv_VsCj_YqY9bZiSYSv-w>
Subject: Re: [CCAMP] comments for draft-ietf-ccamp-alarm-module-06
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2019 08:35:34 -0000

Hi Jinwei!
Thanks for your comments and support of the alarm module.
Note that it has passed last call. Your comments have been addressed previously on the mailing list
We provide a summary of the answers inline below.

br Stefan and Martin


> On 28 Dec 2018, at 03:30, Xiajinwei (Jinwei Xia, Network) <xiajinwei@huawei.com> wrote:
> 
> Dear editors,
> 
>  
> 
> As a new comer of CCAMP, I am happy with the good progress of the YANG alarm module and definitely support it.
> 
>  
> 
> Since I am working on the alarm design, I have a few comments on this draft:
> 
>  
> 
> 1, the draft identifies the alarm-type via the combination of alarm-type-id and alarm-type-qualifier. We fully like that, by the way, would we add one complemented and optional leaf, e.g., alarm-name (R-LOS), to briefly indicate the alarm type? While the corresponding alarm-text shows the comprehensive information about this alarm, e.g., the signal is lost on the receiver side.
> 
That would be the name of of the alarm identity (or the string qualifier)
such as:
import ietf-alarms {
     prefix al;
   }
   identity vendor-alarms {
     base al:alarm-type;
   }
   identity communications-alarm {
     base vendor-alarms;
   }
   identity R-LOS {
     base communications-alarm;
   }
>  
> 
> 2, for the alarm instance, the draft uses the triple-keys (resource, alarm-type-id and alarm-type-qualifier) to identify it. From my point of view, the design is great. Besides of the triple-keys identification in our design, we also add a complemented and optional alarm-serial-no leaf to do the same work. An alarm-serial-no is unique to identity one alarm instance, and thus the OSS can locate an alarm via the alarm-serial-no directly and save the time to map the triple-keys one by one. Does it make any sense
No, having redundant/overlapping keys is not optimal, this can create non-consistency.
See the following example from 3GPP Alarm IRP Appendix C:
* the Alarm IRP has an alarm identity, ai, corresponding to your proposal for alarm-serial-no
* moc = managed object class, moi = managed object instance; corresponds to resource in the alarm YANG module
* et = event-type, pc= probable-cause; corresponds to alarm-type in the alarm YANG module
* sp = specific-problem; corresponds to alarm-qualifier in the alarm YANG module

3GPP Alarm IRP snippet:
----
EXAMPLE 3: Invalid sequence of a hypothetical case:

(1) NotifyNewAlarm
(ni=1, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical)

(2) NotifyChangedAlarm
(ni=2, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

...
Interaction (2) is illegal since it uses a different ai for the same alarm. It should use ai=X as in interaction (1).
END snippet
----

We do not want to enable these kind of inconsistencies.
We prefer a semantic key triplet whereby the manager can get the composite alarm state for a given resource and alarm-type




> 
> 
> 3, for the alarm-type-id, could it be possible to support a union of identity and string? Currently, we have more or less 40000 alarm types in our implementation and the number is still rising right now. The YANG alarm module is still a huge volume when we build our own alarm-type augment.
40 000 alarm types, have you validated them against Appendix G, Alarm Usability Requirements?
No, a union would not be a good idea. To the extent possible all alarm-types should be defined at design time by YANG identifiers.
This gives the users/managers a way to prepare consequent actions and not discover these at run-time.
If your system really has 40 000 alarm types than that is what you should publish AND how to resolve the alarms.

Alarm qualifiers should be avoided as much as possible, they should only be used for alarm types that are configurable, like a digital input.
> 
>  
> 
> 4, in alarm notification message, the severity information is great to let operator know the alarm state (i.e., cleared, raised and changed). We like that, but it’d be better if there was a definite alarm-category leaf to indicate the brief alarm state regardless of the severity, any thoughts?
if the notification severity is cleared, the alarm is cleared
if the [resource, alarm-type, alarm-qualifier] tuple matches an existing alarm it is an update
if the [resource, alarm-type, alarm-qualifier] tuple does not match an existing alarm it is a raise

There are corner cases on the above relating to that a client/server might have performed house-keeping/purging actions.
> 
>  
> 
> Sorry for bringing any inconvenience of the late comments on the WGLC stage. Your feedbacks are very helpful for us J

All feedback is welcome :)
> 
>  
> 
> Merry Christmas and Happy New Year!
> 
>  
> 
> Jinwei
> 
>  
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp