Re: [CCAMP] Alarm Module work

stefan vallin <stefan@wallan.se> Wed, 04 July 2018 08:20 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 45514130ED4 for <ccamp@ietfa.amsl.com>; Wed, 4 Jul 2018 01:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 jGtYAu845aTG for <ccamp@ietfa.amsl.com>; Wed, 4 Jul 2018 01:20:25 -0700 (PDT)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 3D231130E8C for <ccamp@ietf.org>; Wed, 4 Jul 2018 01:20:24 -0700 (PDT)
Received: by mail-lf0-x230.google.com with SMTP id l16-v6so3693163lfc.13 for <ccamp@ietf.org>; Wed, 04 Jul 2018 01:20:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wallan-se.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=j08294ENEj1LYkFby+QIt9+vkYeAAj9/LSGJP+PNRq4=; b=wrVYlc885IiWPK98010uVC3Zefq3EW4eH8YorCBMl3LarZmKgBF81leJHoq23N2OuT anE6OHoX/ZvmDe9ajfP/7LGV2AzQu6+j7yXzxlOaYl7UALtN7sDU13LxMGg8x3nEio3N //qgbuiddN7j/5c1zAiv7U5y7wFBHLSrQVwjFxO1wfw+hPfTMCyQa1dFmNSfFmnyAoif 7157Xpx50Mp/CivATMN5ZJ9PmEKlyJVwZn6S1pkOxvSMgrxrQEbtE+QhLLJBOLzFPGtg /5TACOEok3wIYQcWM76udjD+i/JGCsL7gWcDJu01CGUzdJp1xRyGCLL2g/jwoHTudJxS eyuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=j08294ENEj1LYkFby+QIt9+vkYeAAj9/LSGJP+PNRq4=; b=B4HJvgBw5wi2IMdUA1jlC4d/xW1WeIz7+dMMwdXmltGSXAJmEtcdd2HoaI5mDGhzF9 06I/Di6O1fL82bpxWZAGWZuh0TQD0nhKcSAU5tWvxjSF+BsAVMbFbn1xe/mSQ/525BIp b8RBnbTNATOpk/OX6o8x/rg/scJyJQyly/oQWLwOvMBqgmlla0NXxKjAFs7LIXL7LomJ /+pfSbKgSIbPNJipbAy7V1OQS1yMAmEfPDufsEtVj4mU7Lq6tY02TR9pi3ljrXRzteY4 5JI5DwuIwXWeVcngjjECMmGfTuEG6RdP3TBGnRPCEwkZ78D5tzqlaUD4O/DkemFIpUWH mobw==
X-Gm-Message-State: APt69E1PiLPhZB0DNUPOE8WSC57l9niZIe5Hee3tC6EhC8jDZ6R/T+lv 4br23o/Ir9mkqGONbNFqdOOyvw==
X-Google-Smtp-Source: AAOMgpco+4HEA+/REmKoLDuOvOmQM5byo5VywH3SOE/Uo2qNzw9HdhCivo++BsF/LVrk7CTJZWschA==
X-Received: by 2002:a19:a417:: with SMTP id q23-v6mr815213lfc.59.1530692422467; Wed, 04 Jul 2018 01:20:22 -0700 (PDT)
Received: from [192.168.8.50] ([195.234.15.130]) by smtp.gmail.com with ESMTPSA id f3-v6sm661057lfa.21.2018.07.04.01.20.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 01:20:21 -0700 (PDT)
From: stefan vallin <stefan@wallan.se>
Message-Id: <D5A878BC-3F47-4FA8-95D7-5C73CC86863B@wallan.se>
Content-Type: multipart/alternative; boundary="Apple-Mail=_94A32783-1DA5-4A68-9B1B-F712A860D1DE"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 04 Jul 2018 10:20:21 +0200
In-Reply-To: <BD6D193629F47C479266C0985F16AAC7F070E2F9@ex-mb1.corp.adtran.com>
Cc: Common Control and Measurement Plane Discussion List <ccamp@ietf.org>
To: NICK HANCOCK <nick.hancock@adtran.com>
References: <D174588E-1233-4B53-B5BB-D29DE14B3888@wallan.se> <BD6D193629F47C479266C0985F16AAC7F07058E9@ex-mb1.corp.adtran.com> <DABC5B07-77FC-4623-84FF-8989CB40556A@wallan.se> <BD6D193629F47C479266C0985F16AAC7F070E2F9@ex-mb1.corp.adtran.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/6ZSpnJdG6XLTy_is9iZLMJnK-_A>
Subject: Re: [CCAMP] Alarm Module work
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 04 Jul 2018 08:20:38 -0000

Hi Nick!
Good suggestion!
Thanks for your support on this part of the alarm module,
Br Stefan


> On 4 Jul 2018, at 09:50, NICK HANCOCK <nick.hancock@adtran.com> wrote:
> 
> Hi Stefan,
>  
> Thanks for providing this info upfront.
>  
> Looks good, but am wondering whether ‘alarm-type-qualifier-match’ would be better than ‘alarm-type-qualifier’.
>  
> Best regards
> Nick
>  
>  <>From: stefan vallin [mailto:stefan@wallan.se <mailto:stefan@wallan.se>] 
> Sent: Tuesday, July 03, 2018 2:13 PM
> To: NICK HANCOCK
> Cc: Common Control and Measurement Plane Discussion List
> Subject: Re: [CCAMP] Alarm Module work
>  
> Hi Nick!
> Working on an updated revision based on feedback from the list. This is how alarm-profile looks right now.
> Following your suggestions. Let me know what you think!
>  
> Br Stefan
>  
>  
> Back in ietf-alarms.yang
>  
>      +--rw alarm-profile* [alarm-type-id alarm-type-qualifier resource] {alarm-profile}?
>         +--rw alarm-type-id                        al:alarm-type-id
>         +--rw alarm-type-qualifier                 string
>         +--rw resource                             al:resource-match
>         +--rw description                          string
>         +--rw alarm-severity-assignment-profile {severity-assignment}?
>            +--rw severity-levels*   al:severity
>  
> So it can be used for augmentation and the severity assignment profile is there as well
>  
>     list alarm-profile {
>       if-feature alarm-profile;
>       key "alarm-type-id alarm-type-qualifier resource";
>       ordered-by user;
>       description
>         "This list is used to assign further information or
>        configuration for each alarm type. This module supports
>        a mechanism where the client can override the system
>        default alarm severity levels. The alarm-profile is
>        also a useful augmentation point for specific additions
>        to alarm types.";
>       leaf alarm-type-id {
>         type al:alarm-type-id;
>         description
>           "The alarm type identifier to match.";
>       }
>       leaf alarm-type-qualifier {
>         type string;
>         description
>           "A W3C regular expression that is used to
>          match.";
>       }
>       leaf resource {
>         type al:resource-match;
>         description
>           "Specifies which resources to match.";
>       }
>       leaf description {
>         type string;
>         mandatory true;
>         description
>           "A description of the alarm profile.";
>       }
>       container alarm-severity-assignment-profile {
>         if-feature severity-assignment;
>         description
>           "The client can ovveride the system default
>          severity level.";
>         reference
>           "ITU M.3100, ITU M.3160
>          - Generic Network Information Model,
>            Alarm Severity Assignment Profile";
>         leaf-list severity-levels {
>           type al:severity;
>           ordered-by user;
>           description
>             "Specifies the configured severity level(s) for the
>            matching alarm. If the alarm has several severity
>            levels the leaf-list shall be given in rising severity
>            order. The original M3100/M3160 ASAP function only
>            allows for a one-to-one mapping between alarm type and
>            severity but since the IETF alarm module supports stateful
>            alarms the mapping must allow for several severity levels.
>  
>            Assume a high-utilisation alarm type with two
>            thresholds with the system default severity levels of
>            threshold1 = warning and threshold2 = minor. Setting this
>            leaf-list to (minor, major) will assign the severity
>            levels threshold1 = minor and threshold2 = major";
>         }
>       }
>     }
>  
>  
> 
> 
> On 31 May 2018, at 18:24, NICK HANCOCK <nick.hancock@adtran.com <mailto:nick.hancock@adtran.com>> wrote:
>  
> Hi Stefan,
>  
> Thanks for sharing this for discussion.
>  
> I absolutely agree that it is most important that we can progress the YANG Alarm Module to RFC asap, so that support for it can begin to be implemented in the industry.
>  
>  
> 1) Extended notification filtering.
>  
> The introduction of ‘notify-security-level’ here has one drawback in that it is a global configuration applying to all alarm types and thus does not allow the behaviour to be assigned based on type of resource, such as interface or object. This does not allow you to suppress alarms below a certain severity for some interface types that are not so important, for example, but keep normal alarm behaviour for other more important interfaces. 
>  
> Also just 'Crossing the specified level' may fulfil the desired behaviour for alarm types with a 1:1 mapping to severity level, but not for alarm types with severity life cycles. if the severity of the alarm continues to increase above the configured severity level, alarm notifications would also need to be sent.
> Consider the following example assuming the severity-level is set to ‘major’:
>            [(Time, severity, clear)]:
>            [(T1, major, -), (T2, critical, -), (T3, major, -), (T4, minor, -), (T5, major), (T6, major, clear)]
> I would expect alarm notifications at T1, T2, T3, and T6.
>  
> Changing this configuration to a choice does have its advantages, such as to allow the addition of other cases later or allow other SDOs or vendors to augment other cases.
> So maybe a pragmatic approach so as to not block progress of this draft could be to keep the choice format but omit the ‘notify-security-level’ for now and continue discussions.
>  
>  
> 2) Alarm Severity Assignment Profile
>  
> The proposed implementation provides the means to override severities for alarm types with severity life cycles, but at the same time the implementation is relatively simple.
> Also the use of a criteria to assign the severity to alarms – and I am assuming that it would work like for the shelf - allows resource-independent overriding of factory default severities through specification of an alarm-type only, but also to add additional overrides for specific resources. The only question is if there are multiple assignments that apply to a specific alarm instance which assignment should apply? For example, if I create an entry for 
> [(alarm-type-id, alarm-type-id-qualifier, resource, severity-level]
> [(los,,,major),(los,,”interface 1”, critical)]
> which severity assignment applies to interface 1? The more specific?
>  
> The implementation is also very specific to alarm severity assignment. The mechanism itself, though, is relatively generic, mapping information to alarms, in this case alarm severities. Other SDOs or vendors may wish to augment the list with other data nodes to use this mechanism to associate other data with alarm types and avoid having to implement multiple lists. So I believe that there would be a great advantage and added-value, if this list would be made more generic, such as renaming it to just ‘alarm-profile’, for example.
>  
> And although it does fulfil the requirements of M.3100/M.3160, including the list within the module ietf-alarms-itu would basically restrict the use and possible extension of the ASAP to ITU requirements only. Since possible augmentations could originate from requirements coming from other SDOs and vendors, it would IMHO not be prudent to include it in this module.
>  
> Best regards
> Nick
>  
>  
>  
> This message has been classified General Business by NICK HANCOCK on Thursday, 31 May 2018 at 18:24:19.
>  
> From: CCAMP [mailto:ccamp-bounces@ietf.org <mailto:ccamp-bounces@ietf.org>] On Behalf Of stefan vallin
> Sent: Monday, May 28, 2018 2:12 PM
> To: Common Control and Measurement Plane Discussion List
> Subject: [CCAMP] Alarm Module work
>  
> Hi!
> Me and Martin are working on an updated version of the alarm module. Several smaller things pointed out by reviewers. Thank you all.
>  
> We would like to share 2 things for discussion:
> 1) Extended notification filtering
> 2) Alarm Severity Assignment Profile
>  
> We are now stretching the limit for being a first core module with only relevant features.
> At this point I think it is more important to start having implementation support rather than adding even more features which might scare people of from implementing it.
>  
>  
> 1) Extended notification filtering
> ========================
> See suggestion below, added the capability to filter on severity.
> We did not include resource filtering since that would be too much overlap with shelving.
>  
>       choice notify-status-changes {
>         description
>           "This leaf controls the notifications sent for alarm status
>            updates. There are three options:
>            1. notifications are sent for all updates, severity level
>               changes and alarm text changes
>            2. notifications are only sent for alarm raise and clear
>            3. notifications are sent for status changes equal to or
>               above the specified severity level. Clear notifications
>               shall always be sent
>               Notifications shall also be sent for state changes that
>               makes an alarm less severe than the specified level.
>            In option 3, assuming the severity level is set to major,
>            and that the alarm has the following state changes
>            [(Time, severity, clear)]:
>            [(T1, major, -), (T2, minor, -), (T3, warning, -),
>             (T4, minor, -), (T5, major), (T6, major, clear)]
>            In that case, notifications will be sent at
>            T1, T2, T5 and T6";
>         leaf notify-all-state-changes {
>           type empty;
>           description
>             "Send notifications for all status changes.";
>         }
>         leaf notify-raise-and-clear {
>           type empty;
>           description
>             "Send notifications only for raise, clear, and re-raise.
>              Notifications for severity level changes or alarm text
>              changes are not sent.";
>         }
>         leaf notify-severity-level {
>           type severity;
>           description
>             "Only send notifications for alarm state changes
>              crossing the specified level. Always send clear
>              notifications.";
>         }
>       }
>  
>  
>  
> 2) Alarm Severity Assignment Profile
> ============================
>  
> We have renamed ietf-alarms-x733 to ietf-alarms-itu since it now includes X.733 as well as M.3100/M.3160 features
>  
>   list alarm-severity-assignment-profile {
>       if-feature alarm-severity-assignment-profile;
>       key "alarm-type-id alarm-type-qualifier resource";
>       ordered-by user;
>       description
>         "If an alarm matches the criteria in one of the entries
>          in this list the configured severity levels shall be
>          used instead of the system default. Note well that the
>          mapping allows for several severity levels since this
>          alarm module uses a stateful alarm model where
>          the same alarm can have the following states:
>          [(warning, not cleared),(minor, not cleared),
>           (minor, cleared)]
>  
>          The configuration of this list shall update the
>          /al:alarms/al:alarm-inventory/al:alarm-type list so that a
>          client can always get a full picture of the possible alarms
>          by reading the alarm inventory. If an alarm matches several
>          entries in this list, the first match is used.";
>       reference
>         "M.3160/M.3100 Alarm Severity Assignment Profile, ASAP";
>       leaf alarm-type-id {
>         type al:alarm-type-id;
>         description
>           "The alarm type identifier to match for severity
>            assignment.";
>       }
>       leaf alarm-type-qualifier {
>         type string;
>         description
>           "A W3C regular expression that is used to match
>            an alarm type qualifier.";
>       }
>       leaf resource {
>         type al:resource-match;
>         description
>           "Specifies which resources to match for severity
>            assignment.";
>       }
>       leaf-list severity-levels {
>         type al:severity;
>         ordered-by user;
>         description
>           "Specifies the configured severity level(s) for the
>            matching alarm. If the alarm has several severity
>            levels the leaf-list shall be given in rising severity
>            order. The original M3100/M3160 ASAP function only
>            allows for a one-to-one mapping between alarm type and
>            severity but since the IETF alarm module supports stateful
>            alarms the mapping must allow for several severity levels.
>  
>            Assume a high-utilisation alarm type with two
>            thresholds with the system default severity levels of
>            threshold1 = warning and threshold2 = minor. Setting this
>            leaf-list to (minor, major) will assign the severity
>            levels threshold1 = minor and threshold2 = major";
>       }
>       leaf description {
>         type string;
>         mandatory true;
>         description
>           "A description of the alarm severity profile.";
>       }
>     }
>  
>  
> Stefan Vallin
> stefan@wallan.se <mailto:stefan@wallan.se>
> +46705233262