Re: [nmrg] Autonomic Use Cases

"Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com> Sat, 08 March 2014 14:03 UTC

Return-Path: <dimitri.papadimitriou@alcatel-lucent.com>
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6201A0159 for <nmrg@ietfa.amsl.com>; Sat, 8 Mar 2014 06:03:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 fGIkOE31hZPK for <nmrg@ietfa.amsl.com>; Sat, 8 Mar 2014 06:03:44 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 605701A00FC for <nmrg@irtf.org>; Sat, 8 Mar 2014 06:03:43 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s28E3buR027067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 8 Mar 2014 08:03:38 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s28E3ZWD027808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Mar 2014 15:03:35 +0100
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.10]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sat, 8 Mar 2014 15:03:35 +0100
From: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
To: "Michael Behringer (mbehring)" <mbehring@cisco.com>, "nmrg@irtf.org" <nmrg@irtf.org>
Thread-Topic: Autonomic Use Cases
Thread-Index: Ac86X5T6lfxN1wJKTHant9hA7a0vlgAXSsnA
Date: Sat, 08 Mar 2014 14:03:34 +0000
Message-ID: <84675BAA8C49154AB81E2587BE8BDF8308B4AC52@FR711WXCHMBA07.zeu.alcatel-lucent.com>
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9AEDD9@xmb-rcd-x14.cisco.com>
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9AEDD9@xmb-rcd-x14.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/DMnDi4VHCh7E9abEUou9k0-CnQk
Subject: Re: [nmrg] Autonomic Use Cases
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
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: <http://www.irtf.org/mail-archive/web/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: Sat, 08 Mar 2014 14:03:46 -0000

Hi Michael,

I certainly share this goal. 

Reading throughout the intro, OSPF currently provides adaptive routing (within the setting for which they have been configured, information exchanged with other OSPF routers, etc.), a main goal that requires also further wording is the augmentation of their capability by means of predictive (and not only reactive) re-parametrization that couldn't be diagnosed by OSPF alone, information element not exchanged by the OSPF protocol itself, and procedures not currently part of its algorithmic. This example can be generalized to other protocols and processes but bare with me, the ultimate goal of autonomics is indeed to provide network-wide (so-called) intelligence to nodes while minimizing functional and informational dependence on centralized management or control systems. 

Hence, the focus of this design goal should be on autonomic (distributed) control plane elements.

Thanks,
-dimitri.

> -----Original Message-----
> From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Michael Behringer
> (mbehring)
> Sent: Saturday, March 08, 2014 00:47
> To: nmrg@irtf.org
> Subject: [nmrg] Autonomic Use Cases
> 
> NMRG,
> 
> During the meeting we mentioned the need to document use cases. This
> section in the definitions draft is so far empty. Since we should have
> that section BEFORE working out the use cases, I drafted something up
> here.
> 
> I also realised that while we haven't really written down in the draft
> that the key point of this work really is to work out common
> infrastructure requirements. So I'm also suggesting an additional short
> section in the Design Goals section:
> 
>       <section title="Common Autonomic Networking Infrastructure">
> 	<t><xref target="I-D.irtf-nmrg-an-gap-analysis"/> points out that
> there are already a number of fully or partially autonomic functions
> available today. However, they are largely independent, and each has its
> own methods and protocols to communicate, discover, define and distribute
> policy, etc. </t>
> 	<t>The goal of the work on autonomic networking in the IETF is
> therefore not just to create autonomic functions, but to define a common
> infrastructure that autonomic functions can use. This autonomic networking
> infrastructure may contain common control and management functions such as
> messaging, service discovery, negotiation, intent distribution, etc. A
> common approach to define and manage intent is also required. </t>
> 	<t>Refer to the reference model below: All the components around the
> "autonomic service agents" should be common components, such that the
> autonomic service agents do not have to replicate common tasks
> individually. </t>
>       </section>
> 
> Comments? Does this capture the idea well?
> 
> And then, the use case section could look like this:
> 
>       <section title="Guidelines for Case Studies">
> 	<t>Case studies and problem statements are mandatory to understand
> common requirements for autonomic functions. This section explains how
> case studies should be outlined and what they should describe:
>         <list style="symbols">
> 	  <t>Title</t>
> 	  <t>Problem Statement: An explanation which problem is being
> addressed, with information about existing solutions and their
> shortcomings.</t>
> 	  <t>Intended user / administrator experience: The goal of autonomic
> networking is to simplify network administration and usage. Use cases
> should point out how their experience differs from current solutions. If a
> use case depends on configuration, it may include configuration samples,
> although obviously the goal is to reduce or eliminate configuration. </t>
> 	  <t>Intent: Strictly speaking intent is part of the administrator
> experience, but should probably explained explicitly with a high-level
> view on how the autonomic function could be defined in intent (if
> required). </t>
> 	  <t>Local knowledge: What the function needs to know about the
> capabilities of the node itself, and which local resources need to be
> accessed.</t>
> 	  <t>Communication requirements: The requirements for message
> exchange, discovery, negotiation, etc with other autonomic nodes. </t>
>         </list>
> 	</t>
> 	<t>Use cases are not required to outline a solution in detail, nor
> to specify precise protocol or intent details. They are used at this point
> to determine a consolidated approach to developping an autonomic
> networking infrastructure. </t>
>       </section>
> 
> Comments?
> Michael
> 
> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg