IETF Logo Mail Archive

Re: [CCAMP] Question on alarm-notification draft-ietf-ccamp-alarm-module-07.txt

stefan vallin <stefan@wallan.se> Mon, 04 March 2019 08:31 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 5C42B130FDA for <ccamp@ietfa.amsl.com>; Mon, 4 Mar 2019 00:31:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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, URIBL_BLOCKED=0.001] 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 jtedQvgRQede for <ccamp@ietfa.amsl.com>; Mon, 4 Mar 2019 00:31:14 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 080901292F1 for <ccamp@ietf.org>; Mon, 4 Mar 2019 00:31:14 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id v185so2847971lfa.11 for <ccamp@ietf.org>; Mon, 04 Mar 2019 00:31:13 -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=rGJrRUOp5AsoDpQRt385w10UBxm7kBib/nOegHN5Oyc=; b=X6fIPjj+5ssGEMa0HmsP/VB/SskzIpAXc0Y1vSEvGfQlA1JTdxp0f++M+LN3FA9eGT ZTjuvsungqoK3Cme/cDfRkBaRv+lplnYtOPIKUh3nk1egfAIyrKte7IPglB3RfYk1VQD SY9R/+gbhmoGvAHkw6imSaMnjstcYvwwDjIPZorC9QZmpYZ5v9SHXOFCoDdNNGLlnwOl FSsWh4FcKghao5norDaySYHB0851YGJTzJnPHRr0cVvz80GqOwXe27wQYwbB9VIsofIo cD0jh6tquqWr51JC8+xzPQ5wxm8U/8HxujkUoVeRs97e7V9tqgOshd8sJONSsw/3NqUH 00vA==
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=rGJrRUOp5AsoDpQRt385w10UBxm7kBib/nOegHN5Oyc=; b=AQfaLzcovfgJa40y3UwqZA2YsQDYToocGNKnR2xq52hvC406Y61HJ3VNO1LPNEpftF OKyOAQQOtF9DDon5g7jkvDvXdyFeGdi6jy2FSB2GnQnDHuYK8ZVqLYQU3ptsr3fSiDdo ezRhA90mzbycf0FKEfECjxYGBxP9wGGS9/wUgws0uvtpUiKKXPqWeKNTe42BvVfw6OO/ vanWWdd6u6Q8FBUjWS1nhBGS4SCXTd/GfwIBgUz4nvwPhJYzEDegx+mXkyd/0fzIQtPI 2mD7vJo0gyIzfb+o8c0UwsEZ8rN+LngguwBA7WmFXo2yQNlfiMMoxX98+Er3ETFcYSDs yDFw==
X-Gm-Message-State: APjAAAXEWAHbnCSUNv7EyVtqIplzgIKtLacj+Swg1U106p6R6/F6h0hY ksZyaauUusu/oWxhi7yPcfXSZw==
X-Google-Smtp-Source: APXvYqyPrOdtMaOunWEEkodsWLyh32fm8d5BG4ptVmV5GOWdQzmxlo9p5LNICYAkW+pzYWWk0iQhpQ==
X-Received: by 2002:ac2:5607:: with SMTP id v7mr6445724lfd.50.1551688272135; Mon, 04 Mar 2019 00:31:12 -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 x2sm1398191ljj.79.2019.03.04.00.31.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Mar 2019 00:31:11 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: stefan vallin <stefan@wallan.se>
In-Reply-To: <20190304.091537.1434859750027847472.mbj@tail-f.com>
Date: Mon, 04 Mar 2019 09:31:10 +0100
Cc: "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>, Martin Bjorklund <mbj@tail-f.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CF33537-72A3-4F7A-A49F-184071A087B8@wallan.se>
References: <50762c99-ff06-e142-ae82-b8fccd75016a@nokia.com> <20190304.091537.1434859750027847472.mbj@tail-f.com>
To: "Beauville, Yves (Nokia - BE/Antwerp)" <yves.beauville@nokia.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/_LPbaX_7kiMUEWQB5GCBYkmwna0>
Subject: Re: [CCAMP] Question on alarm-notification draft-ietf-ccamp-alarm-module-07.txt
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, 04 Mar 2019 08:31:17 -0000

Hi!
Just to comment on your examples:
>>  *   re-configuration of severities
I do not think that changing the alarm severity profile should change the severity levels of *existing* alarms. 
At the time those alarm state changes appeared it was according to the configuration at *that* time. 
Strange if a configuration change affected previous alarm states. 
Therefore, no alarm state changes should be sent for a reconfiguration of severity levels.

>>  *   a transient network issue
See Appendix G (especially Table 4), the system should not send unnecessary alarm state changes for transient changes.
Hysteresis functions, alarm throttling etc are mechanisms outside the scope of this alarm model that should be managed by 
the system in order not to send too high alarm rates.

br Stefan

> On 4 Mar 2019, at 09:15, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> Hi,
> 
> "Beauville, Yves (Nokia - BE/Antwerp)" <yves.beauville@nokia.com> wrote:
>> Hello,
>> 
>> In the proposed YANG module, an alarm-notification conveys a single
>> alarm state change.
>> 
>> There are scenarios where server may want to send a possibly large set
>> of alarm state changes at the same time.
> 
> This is correct, but it is not limited to alarms; it applies to all
> kinds of notifications.  The NETCONF WG is working on a more generic
> solution to this problem, where a single notification message can
> contain multiple notifications
> (draft-ietf-netconf-notification-messages).   I think this is a more
> flexible solution than coding this into every YANG-defined notification
> (not just alarms).
> 
>> For example:
>> 
>>  *   re-configuration of severities
>>  *   a transient network issue
> 
> I think Stefan will send some comments re these examples.
> 
> 
>> Would we do this more efficiently by allowing the alarm-notification
>> to convey a list of state changes rather than a single one?
> 
> 
> 
> /martin
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

v2.23.0 | Report a Bug | By Email