Re: [nmrg] Adoption call for draft-clemm-nmrg-dist-intent-03

Jérôme François <jerome.francois@inria.fr> Mon, 16 December 2019 09:56 UTC

Return-Path: <jerome.francois@inria.fr>
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 73F2D120129; Mon, 16 Dec 2019 01:56:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_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 I5HruXmMeZ7y; Mon, 16 Dec 2019 01:56:27 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 0EF68120127; Mon, 16 Dec 2019 01:56:25 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.69,321,1571695200"; d="scan'208";a="333295827"
Received: from tadam.loria.fr (HELO [152.81.3.52]) ([152.81.3.52]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 16 Dec 2019 10:56:21 +0100
From: Jérôme François <jerome.francois@inria.fr>
To: "nmrg@irtf.org" <nmrg@irtf.org>
Cc: "nmrg-chairs@irtf.org" <nmrg-chairs@irtf.org>
References: <0fcdbe0e-90ad-0c62-eae3-021c131c70df@inria.fr>
Message-ID: <6b090fa9-4022-d0ba-3d0d-091208089ccb@inria.fr>
Date: Mon, 16 Dec 2019 10:56:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1
MIME-Version: 1.0
In-Reply-To: <0fcdbe0e-90ad-0c62-eae3-021c131c70df@inria.fr>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/nmrg/RKrDwF-iuHSDoRincd4XPpvai6Q>
Subject: Re: [nmrg] Adoption call for draft-clemm-nmrg-dist-intent-03
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.29
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, 16 Dec 2019 09:56:29 -0000

Dear all,

Speaking as an individual.

The document already offers a good support to understand the IBN concepts and how 
they relate to other ones.
So I support the adoption of the draft but would like to hear from authors a more 
concrete working plan for the following items:

1) Principles - abstractions: a lot of potential other principles to be 
investigated in future revisions. What will be your plan here. Are some of these 
principles already identified to be documented (some priority) or are they open 
questions for the community? Note that explainability is already in item 5. I 
recommend not to use "how to?" for principles.
2) Lifecycle: different lifecycles are proposed in the draft. I understand from 
discussions it is hard/impossible to have a unique lifecycle for IBN. However, 
will it be possible to identify one or a few of "generic lifecycles" with minimal 
functions? Or should it be possible to identify a core sets of "atomic" functions 
and a secondary sets? In my opinion, in the two lifecycles proposed, there are 
some clear similarities in their description (plan  ~ decompose ? render ~ 
communicate ?) and so some convergence might de done.


Below are other comments on specific items:
- "Ideally, it should not even be orchestrated or broken down by a higher-level, 
centralized system, but by the network devices themselves" -> so it supposes that 
ideally it should be decentralized. Why an IBN system should be decentralized. I 
think from a conceptual point of view, there is no reason for that.
- "this interpretation opens a slippery slope of how to clearly distinguish 
"intent" from other higher-layer abstractions": good to plan to investigate that 
in further revisions but would like to understand how you plan to address this, in 
particular to see if you plan to modify the intent concepts/definition to make it 
quite unique or evaluate how much they are close/far from other propositions.
- Section 4.2.2: "it is present today..." -> but reference is from 2007, maybe 
complete with a more recent one.
- Section 4.2.3 - difference with service models: in my understanding, you 
decouple here, the model itself from the orchestrator but we could think the same 
between "intent expression" and "intent realization"
- Lifecycle: refer to figure in text (hard to map each function into figure, no 
1-to-1 mapping)

Best regards
jerome

Le 04/12/2019 à 18:27, Jérôme François a écrit :
> Dear all,
>
> We recently received an RG adoption request for draft-clemm-nmrg-dist-intent-03 
> (https://www.ietf.org/id/draft-clemm-nmrg-dist-intent-03.txt)
>
> Please let us know if you support the work becoming a RG document or if you 
> think it should not be adopted. In all cases, provide detailed comments to 
> support your opinion and send them on the mailing list.
>
> This call for adoption is open for two weeks and ends up on 19 December 2019.
>
> The procedure for RG document adoption and important criteria are detailed here: 
> https://mailarchive.ietf.org/arch/msg/nmrg/CVEyLUvfxJk1Ud5WdM9Y5LGvQmU
>
> Best regards
> NMRG chairs
> Laurent & Jérôme
>
>
> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg