Re: [nmrg] RG Last Call on Autonomic Networking Use Case for Distributed Detection of SLA Violations

"Alexander Clemm" <ludwig@clemm.org> Mon, 30 January 2017 02:17 UTC

Return-Path: <ludwig@clemm.org>
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333AE1298C7 for <nmrg@ietfa.amsl.com>; Sun, 29 Jan 2017 18:17:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.021
X-Spam-Level:
X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 WZ4zS5DtO-6a for <nmrg@ietfa.amsl.com>; Sun, 29 Jan 2017 18:17:10 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05F31298CF for <nmrg@irtf.org>; Sun, 29 Jan 2017 18:17:10 -0800 (PST)
Received: from LAPTOPR7T053C2 ([73.71.191.170]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MQPOs-1cvAZl2t6i-00TnUG for <nmrg@irtf.org>; Mon, 30 Jan 2017 03:17:09 +0100
From: Alexander Clemm <ludwig@clemm.org>
To: nmrg@irtf.org
References:
In-Reply-To:
Date: Sun, 29 Jan 2017 18:17:11 -0800
Message-ID: <00bc01d27a9e$f787a890$e696f9b0$@clemm.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BD_01D27A5B.E964DDC0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHYTLA0PJh4x73ZpwqTyrxoAa/si6FEpHUQ
Content-Language: en-us
X-Provags-ID: V03:K0:ekieTyMK9noCKpE/OuAT6R4mQGmMCOTMsuxlPyGcLFxvEA1muZl AJoMWQmNZaWQyXQXhFmwUg9q3WqipMc5yaY7J2BvpWT+GXv0p8dBnLVFQ+Fr0J1DNQCKqUb /IvjMnqx2BjQ5vTJXZdqMFt31BtYpbQSRQ9yiGmZVbIqhc/f6OQD9uNuBdnNdhqYU693Fxd 3abIeCTlGdlMthBrYc3kw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:J322sezlr8Y=:jRpD/g9PvzA6KZWK5Wr6IG 1xLzOgGoqTYi6at+FIauM0jIWMbbeiyyjgWwOSWNEuy6OjsUkaBMICgdyqPLX5EJT2zA/ydjK NVOa2UZVls4YD5AaH1oWIGPZ+T4CMDjv8dm/tolS1oDNLSHFo5H0TT0vnLzDNZC6hrkB9WkGu yob1aKWbJ8rpT8aweiYBiaBJocawOsPDWQ8q0EYvP2jCgQWvs4jzvCmddML/XdJspnHS3ppMZ u1nydzkoN3J++oZim0twu0wHXu90GQYVWABjKDjRzAnhGM/2xpgH39CpN65PXnJFUP+Ymwchn uy+nuj/hlUfw69QCW8ReznWoaGC6Ls/VZl9bSefqktapF1NshJ1WhE83yhfpn3rPq6u3UtbvI eYwm98DrZSRZqJH4ya2JoiR/vLxI9ZF2sCufcZYk+kHa6UxjK53tecYKBFwjA+ddDBz++znkQ 6ytRVKZZlSvsQagMZOwRm4Mremy+le15nyfgwNHaOs84peLVny91N+S4mwGGmDuNGQvcle1lA gM5gNFq1+BqftmUEYEQvuLDaI1cRv/UapZ2htlpppnFZIGwFCMHtTq99HbSO4xNoh7oI6en8d MAnjIGjBGyR6IxvsqgDZ1T8p6oX2JqK96fpddaLcZVtGif0gTEykpASBPgdW1V+bTFeFZ6WU/ QtxmUc+k+7X5S1DJIugIvGElO2SJ18lBjFQUhmHOXH0S3GOp7e4cHnGddb8eZmu7I5mFJsdRA al306c1A8YE1jvvt
Archived-At: <https://mailarchive.ietf.org/arch/msg/nmrg/ij8BL92MOlHHTogrufN0gtJpTXQ>
Subject: Re: [nmrg] RG Last Call on Autonomic Networking Use Case for Distributed Detection of SLA Violations
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Management Research Group discussion list <nmrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nmrg>, <mailto:nmrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nmrg/>
List-Post: <mailto:nmrg@irtf.org>
List-Help: <mailto:nmrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nmrg>, <mailto:nmrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2017 02:17:12 -0000

Hi,

 

As one of the coauthors, I support this draft to be advanced.  This is a
fairly small draft, but I think one important issue that it raises, besides
calling out the use case of needing to ensure that SLA violations are
detected (maximizing the likelihood of detecting violated service level
thresholds, as opposed to maximizing other things such as coverage),
concerns the issue of distributing and decentralizing the logic for this
across the network, as opposed to relying on central coordination.  Clearly,
this is an issue for potentially contentious debate, but I think it may be
worthwhile having requirements for this possibility spelled out.  

 

--- Alex