Re: [CCAMP] Alarm Module work

stefan vallin <stefan@wallan.se> Mon, 04 June 2018 11:56 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 C60F712D946 for <ccamp@ietfa.amsl.com>; Mon, 4 Jun 2018 04:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 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_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] 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 FtVJFcbEzMKD for <ccamp@ietfa.amsl.com>; Mon, 4 Jun 2018 04:56:13 -0700 (PDT)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 C2D45124319 for <ccamp@ietf.org>; Mon, 4 Jun 2018 04:56:12 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id j13-v6so20296705lfb.13 for <ccamp@ietf.org>; Mon, 04 Jun 2018 04:56:12 -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=By2fK1qjtxKMt8tP31IEY4qnbEhOx1cfZnqHRgl/9So=; b=rpp9MvhqdRLqSBFqPSJHYB7SsjbyNUulM7U/CCm/EHWByDlsjVhnjn2N+O76DCTBvC cyFtfTDcAJuoGVS3jwZpCircRHahEgOx6aMOMnqlm2LjfPcEc+C/xlxhLk1DdougOtnn v6vRmcMXnA4HvCbUUV/Dq7JH6O/rUyoKrp4qgS/SOVH8Hzr0Lb9W9nrn+FAZARW8zd3u 39B1he2PQXo1qLf4JaCbtdXmeyPTiqpUWi7WvpDSOWQXyXZ0R58S1Gk1JNHZDMXGjaUS w/UlPIuvcBRzVb/GpTsBRHMEzf2JysizjsAb2dvRhrYO8GgOwhybMA7z+QTA52grYL6q gsyw==
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=By2fK1qjtxKMt8tP31IEY4qnbEhOx1cfZnqHRgl/9So=; b=OHSxz+E23hHc8n6EAGzf680RwN5nM1+jRMmtsALTB3J4iig6WoXZpisl6EZUBznM9J 2mvltXVSU7hSEOFDQTnL2TCKZI9dSrv4biMWFtm4tq/GJaF529FFvBuzQ5LqKVYOEtcZ T8/hWf9a/pTv+F4VZ7lB9l0b+PPt0bnhkWkDEUIZM3LtWocq79v6mLyYzqaCfEcTp4Om GtxEhe2Bx0nvapstFY7z46fVUTxO+UyR9Ai7e9pI+slISQmHL6y+O7tAu6NL4YKclcSM aqWxxUNZalk8IUYJVOUSJQ/ntGb6rEB4c0Darcqvb6bOvwpgu93k2wEglym18IBigf+n LqOw==
X-Gm-Message-State: APt69E0ZuquKsVSp+139wLU8oMiRxT4jVg1BknEL1baybGYYhZx3Acmw o9WLCDnJH9ImQ9b8kt0YSQsDGA==
X-Google-Smtp-Source: ADUXVKKzZwJZ2wqGzdQcINTV67xBrtORe4TwG14YEAnScKBL9oCNzLW05Cppfx50zoUyJT/m+8R30A==
X-Received: by 2002:a19:d957:: with SMTP id q84-v6mr7527614lfg.79.1528113370662; Mon, 04 Jun 2018 04:56:10 -0700 (PDT)
Received: from [192.168.99.195] ([195.234.15.132]) by smtp.gmail.com with ESMTPSA id u10-v6sm5732252ljh.23.2018.06.04.04.56.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jun 2018 04:56:10 -0700 (PDT)
From: stefan vallin <stefan@wallan.se>
Message-Id: <4FF6AFED-369D-407E-8757-1707E1F2C1EA@wallan.se>
Content-Type: multipart/alternative; boundary="Apple-Mail=_38782B5C-ED29-47A0-B6CB-28664472F4D0"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 4 Jun 2018 13:56:08 +0200
In-Reply-To: <BD6D193629F47C479266C0985F16AAC7F0705D2A@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> <7906650D-4E83-4386-AA08-43B120CD6866@wallan.se> <BD6D193629F47C479266C0985F16AAC7F0705D2A@ex-mb1.corp.adtran.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/SdqQ1UDkDY2NW48cxlZg8Un1E7I>
Subject: Re: [CCAMP] Alarm Module work
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.22
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 Jun 2018 11:56:17 -0000

Hi Nick!
See inline:
> 
> 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.
> Adding some severity changes to your scenario
> [(T1, major, -), (T2, critical, -), (T3, major, -), (T4, minor, -), (T5, warning), (T6, major), (T7, clear)]
> <image002.png>
>  
> Notifications will be sent at T1, T2, T3, T4, T6, T7
> [Nick] So you are saying that with the method you are proposing, you did intend that the notification would be sent at T2 (critical) in your example above, although strictly the severity did not ‘cross’ the specified severity level ? I didn’t understand it that way from the description. Then that would be what I would have expected.
Yes, that was my intention, will clarify. Thanks for pointing this out.

> 
> 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.
> Or keep it :)
> [Nick] See above.
> 
>  
> 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?
> Good comment!
> Priority order:
> 1) the more specific
>   1.1) resource
>   1.2) alarm type (remember hierarchical)
> 2) order in list
> 
> 
>  
> 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.
> We are circling back and forth here.
> [Nick] I nevertheless feel we are converging on a solution and that we are almost there!
I think so as well

> The list has expressed the need to support ITU Alarm Severity Assignment Profile, this is exactly what the suggested model does.
> [Nick] Yes, but the proposed ASAP list could do much more is what I am saying. Maybe the question is: does the list require a specific implementation, specifically an ASAP, or does it require the alarm module to provide a function that allows severities to be assigned to alarm types? My understanding is the latter. Maybe others on the list could also comment.
>  
> As you may recall, we have also been discussing other features in past threads, for example, to assign operator specific information to alarm types. We can argue whether the core module should or should not support this directly. More importantly we need the alarm module to progress to RFC. If certain features are not supported in the core model, then other SDOs and/or vendors would need to provide a solution and the obvious one would be to extend/augment some existing mechanism. This list would be a suitable candidate to be extended/augmented to provide a solution to enable this custom information to be assigned to alarm types, for example. But currently given its name, the list would be limited to alarm severity assignment.
>  
> My recommendation would be:
> -          rename the list, say to ‘alarm-profile’
> -          add a reference statement to severity-level (I would use the singular and not plural as it reads better in XML) referencing M3100/M3160.
> -          move it to ietf-alarms (or to its own module, but that maybe an overkill)
> -          leave ietf-alarms-x733 as is.

Ok, ready you, good suggestion, let me think...
>  
> And although it does fulfil the requirements of M.3100/M.3160,
> as requested :)
> 
> including the list within the module ietf-alarms-itu would basically restrict the use and possible extension of the ASAP to ITU requirements only.
> Not sure what you mean with "restrict"
> [Nick] What I am saying here is that if the list is implemented as part of a module that specifically supports  ITU requirements, augmenting the list with non-ITU features goes against the grain. 
Got it
> 
> 
> 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.
> Nothing stops augmentations and additions of other features. Just felt there was a high pressure for ASAP which the suggestion captures.
> [Nick] I would put it another way. Yes, there is a high pressure to support severity assignments to alarm type as I discussed above, but the core module should balance that with  being as generic as possible – which it does generally very well - and allow extension/augmentation by other SDOs and vendors in a generic way.
Ok