Re: [Anima] Next steps for the reference document

Laurent Ciavaglia <Laurent.Ciavaglia@alcatel-lucent.com> Thu, 04 June 2015 14:56 UTC

Return-Path: <laurent.ciavaglia@alcatel-lucent.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858921A8797 for <anima@ietfa.amsl.com>; Thu, 4 Jun 2015 07:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 i_CkeDTnduWn for <anima@ietfa.amsl.com>; Thu, 4 Jun 2015 07:55:57 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334221A1BC9 for <anima@ietf.org>; Thu, 4 Jun 2015 07:55:57 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id BCD6C737949F9; Thu, 4 Jun 2015 14:55:51 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t54EtptY012689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jun 2015 16:55:51 +0200
Received: from [172.27.204.69] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 4 Jun 2015 16:55:51 +0200
Message-ID: <557066F0.80902@alcatel-lucent.com>
Date: Thu, 04 Jun 2015 16:55:44 +0200
From: Laurent Ciavaglia <Laurent.Ciavaglia@alcatel-lucent.com>
Organization: Alcatel-Lucent Bell Labs France
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "Michael Behringer (mbehring)" <mbehring@cisco.com>, Anima WG <anima@ietf.org>
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com>
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com>
Content-Type: multipart/alternative; boundary="------------070104090902040006070908"
X-Originating-IP: [135.239.27.41]
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima/OKck3ea5uNuIjrg_9vLl31Vy3Zo>
Subject: Re: [Anima] Next steps for the reference document
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 04 Jun 2015 14:56:00 -0000

Hi Michael,

Thanks for rounding the todo / issue list.

I am ok to contribute on the intent and section 8 - "coordination / 
conflict resolution" (as per draft-behringer-anima-reference-model-01), 
and section 9 - "Hybrid Approach with Non-Autonomic Functions".

For "constrained" AN nodes, I think they are in scope, but what is the 
implication for the reference model document? Do we already have some 
inputs/requirements (e.g. from other WGs or sources) that could 
enlighten how / to which extent autonomic networks / their 
functionalities and mechanisms shall (or not) adapt (to such constrained 
nodes)?

I am not quite sure what you meant by the "management angle"... I assume 
you are talking about the management/operations of the whole system (as 
if deployed by e.g. a network operator). if correct, then I think some 
aspects of lifecycle / phases/ operations should be considered / written 
in the document. I can contribute to this but would prefer to start with 
some group discussions to see if we agree on the scope first.

A tricky (missing) part might be the relationships among the various 
component. If judged useful (I think it is especially for ANIMA 
"outsiders"), it could be in the form of a diagram and/or linked to the 
(TBC) lifecycle section.
Of course, we shall not seek a ultimate, absolute reference diagram, but 
at least proposing one can help understanding, as you wrote: "show how 
all the various drafts, protocols, and discussions in the ANIMA WG fit 
together".

Thanks, best regards, Laurent.


On 04/06/2015 15:18, Michael Behringer (mbehring) wrote:
> Thanks for all who volunteered to participate in the reference doc. While detailed discussions may be between the contributors, the main technical discussions should probably take place on the main list. Here, I summarise my view on what needs to be done in the reference document.
>
> If someone thinks he/she can produce text for the respective sections, please let me / the list know.
>
> The overall goal is to show how all the various drafts, protocols, and discussions in the ANIMA WG fit together.
>
> Points to address:
>
> -	We should have a short section on intent. Explaining ingest of intent, distribution, the nature (on top of what's in RFC7575). That intent is signed, time stamps, etc. Probably pointing back to RFC7575. (Note intent distribution is handled in section 7.3)
> -	Do we want to address "constrained" AN nodes, with limited capabilities, here? I think so... We'll need that for AN in constrained environments. This could go into a new section in section 3: "constrained network elements".
> -	The masa section needs to be written. The masa will be an optional element. Needs to point to the bootstrap draft, which explains the basics.
> -	Naming section needs meat. What names are used for, where it is in the domain cert.
> -	Addressing section needs to bring in recent discussions. Needs to include how an ASA uses addressing. per node or per ASA. (I think we concluded per node).
> -	Domain certificate template. We should write a section on the AN domain certificate. How the various fields are used.
> -	Need to explain sub-domains
> -	Section 9 needs to be worked out. This is all about conflict resolution. Maybe we should re-name that section? RFC 7575 already mentions this. Maybe we don't need much more here.
> -	trust management: inside a domain, between domain and sub-domain, and between domains. This should become a new section.
> -	Need to treat the question of the "out of band" ACP versus the inline ACP. The two models both work, but there are implications, different benefits, drawbacks, etc. This needs to be explained.
> -	Routing: In the case of a virtually separate ACP, as in draft-behringer-anima-autonomic-control-plane, we need to also define a routing protocol (thinking of the discussion in homenet, this might be "fun"...)
> -	Need considerations for APIs: How can ASAs use the ANI?
> -	Need considerations for a data model. What it should cover, scope.
> -	We should also describe the management angle
> -	Security considerations need to be expanded. Threat analysis needs work; need general security considerations, talk about the PKI and trust model, etc.
>
> Thoughts? Anything missing? Any volunteer for a specific part?
>
> Michael
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>
>

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com 
<mailto:laurent.ciavaglia@alcatel-lucent.com>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France