Re: [Anima] Comments from Alex G. on draft-carpenter-anima-asa-guidelines

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 20 March 2018 20:00 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D96126C83 for <anima@ietfa.amsl.com>; Tue, 20 Mar 2018 13:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 huOO4qpu0sL9 for <anima@ietfa.amsl.com>; Tue, 20 Mar 2018 13:00:54 -0700 (PDT)
Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (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 CA75012025C for <anima@ietf.org>; Tue, 20 Mar 2018 13:00:54 -0700 (PDT)
Received: by mail-pl0-x22f.google.com with SMTP id f5-v6so1663864plj.13 for <anima@ietf.org>; Tue, 20 Mar 2018 13:00:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=u/bFlASiiAbOLKWEI/Zvk+qnhQ29dJhUKoVsYYsUNg8=; b=PDNYdp9MSij53cEdhyiBg0vUs3s6raRPigyhhw0SWppGhBtpYumB3uBtd13KKFMT/D E3I2l2+EA6TMPrdOoU45YJr1i6AGfcKV0axhiFvtbdisGY1/FlC10SAgqYNSUt8liyhU PfpHPqtyZRd8V+gtw/M2Z24GzoWcetCDJN4c/S8vEFvRbIitapcns17h26/wIsnZW5A1 t2yeUAwNAM1vt13CyFK0gNo/riYTub7Gsdw9vN7VH0F7VWaIJJ922uXod4h4Je5iZ52K paSKxb+M1gxoNgdQYTx63lkGoZ7jynoHN7N3N9lATL6zZs4apLKdoYA2+l1fia1uXgZ4 vUkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=u/bFlASiiAbOLKWEI/Zvk+qnhQ29dJhUKoVsYYsUNg8=; b=AJxiE3nFoCxYee3Oa+S2Nqj9XmSEWvPt2jt6nrZlcB2BJUILGKfe/uqr8cY42Qotj0 jT7/fIDJMO/E9eMRLBxkMxyO3d8YuxGmQqilgqXAWa2X6yuL55kI2ugEiR1d8no4oiDs HCwISOr7YNxsZciSkknupJMq4MTcp/tFh+4rT/09iXH9Tw/CjOTqaLVLPfjDQNE9hwDJ K5Y3VSfHicIVQ+uOO/qn9kx+3XQek2QpO5ZKO7TBLLV5YNlVdMw2gF3krGt9eImjpkZn 3ngCM9GdePkEP6fpBUuLG9oqb3ogrSa5f72gIMflISgnM/w5o2Vg3prO0zpSh5wkkiLN sJwA==
X-Gm-Message-State: AElRT7HXTRMpZbprDlwJpyuYB6nJn/c19ZvuwAP6/LgFLe4HsjC18XUa RjSnmw9z7UD6/qEsex3gLajr8Q==
X-Google-Smtp-Source: AG47ELtN6rJy2Yx3XvqeplAZTS5LyoLGe5OmEeezELg3COsGH40PRE6e3np+RpX7AO2Boeuwn1mnSA==
X-Received: by 2002:a17:902:7401:: with SMTP id g1-v6mr18084230pll.4.1521576054023; Tue, 20 Mar 2018 13:00:54 -0700 (PDT)
Received: from [192.168.178.30] (86.225.69.111.dynamic.snap.net.nz. [111.69.225.86]) by smtp.gmail.com with ESMTPSA id b18sm4695461pfi.34.2018.03.20.13.00.51 for <anima@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 13:00:52 -0700 (PDT)
Sender: Brian Carpenter <becarpenter46@gmail.com>
To: anima@ietf.org
References: <HE1PR0701MB22037C4685F11D0C6983451BE8AB0@HE1PR0701MB2203.eurprd07.prod.outlook.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <5b0c9c0c-8661-d41f-c4d1-eb058b87f944@gmail.com>
Date: Wed, 21 Mar 2018 09:00:52 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <HE1PR0701MB22037C4685F11D0C6983451BE8AB0@HE1PR0701MB2203.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/ptkqelBW8FCvzs3y93XLn4W6fz0>
Subject: Re: [Anima] Comments from Alex G. on draft-carpenter-anima-asa-guidelines
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2018 20:00:56 -0000

On 20/03/2018 23:39, Ciavaglia, Laurent (Nokia - FR/Paris-Saclay) wrote:
> Hi Alex,
> 
> Thanks for your comments on draft-carpenter-anima-asa-guidelines.
> 
> If I get it correctly you raised the following points:
> 
>   1.  -better describe what ASA are: rather application or network service, and better describe the border between the two and implications for ASA designers/developers in the draft.
> 
> I think it is an important (and not so simple) topic and worth being discussed.
> 
> Would welcome views from the group.

Yes, these are aspects that we discussed in NMRG and also in the UCAN BOF and early
days of the WG. Probably we have most of the points scattered around in various
documents and meeting minutes, but we need to collect them in one place.

>   1.  -NFV is an important area for future networks, and more focus for ANIMA and ASA should be devoted.
> 
> Agreed; However, I'm not aware that NFV community is following ANIMA work and guidelines on autonomic VNF design/development. Although there are several autonomic/self-* behavior/functionality being developed in NFV.
> 
> There is clearly a gap here, and a difference in approach.

I couldn't find an adequate reference for NFV, which is why the drafts says
[reference needed]. I didn't find a clear definition of "microservices" either,
which is why I didn't use the term.

I think autonomic networking is a new form of network management. Is there
anything wrong with the current statement?
  "For example, the services envisaged for
   network function virtualisation [reference needed] or for service
   function chaining [RFC7665] might be managed by an ASA rather than by
   traditional configuration tools."

An ASA to manage SFC might be an interesting use case to develop.
 
>   1.  -You mentioned something about the decoupling of self-* functionality (self-configuration, self-healing...)
> 
> Not sure I get fully what was your comment on this aspect. Could you clarify / develop?

Again, I think this is a use case issue. The way these self- properties
interact is surely not the same in all cases?

    Brian