Re: [Idnet] Architecture and standard opportunities of IDN

Jérôme François <> Fri, 28 July 2017 10:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9656131898 for <>; Fri, 28 Jul 2017 03:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y4aAOuQsmLLO for <>; Fri, 28 Jul 2017 03:13:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E9DD12EA95 for <>; Fri, 28 Jul 2017 03:13:19 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.40,425,1496095200"; d="scan'208";a="233042473"
Received: from (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES128-SHA; 28 Jul 2017 12:13:17 +0200
References: <> <20170727004512.GC18300@spectre>
From: =?UTF-8?B?SsOpcsO0bWUgRnJhbsOnb2lz?= <>
Message-ID: <>
Date: Fri, 28 Jul 2017 12:13:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170727004512.GC18300@spectre>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Idnet] Architecture and standard opportunities of IDN
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "The IDNet \(Intelligence-Defined Network\) " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Jul 2017 10:13:23 -0000


Le 27/07/2017 à 02:45, Pedro Martinez-Julia a écrit :
> Dear Sheng,
> First of all, and considering my recent experience with the Network
> Slicing work, I think we have some aspects of our work that are probably
> essential for the IETF and network technology in general:
> - As you mention and all of us know well, we need to standardize the
>   data format, so it is a good opportunity to define some ontology and
>   the corresponding YANG model that structures such data.
Do you imagine kind of a transformation process in the architecture as
data to be used can come with pre-existing various data formats ?
> - We have also a good opportunity to define a "benchmarking framework"
>   that can be used with whatever dataset we can gather in the future in
>   order to validate some approach. This would be a combination of YANG
>   model and work protocols (not network, but procedure protocols) that
>   would be required to ensure the results are universally valid and can
>   be contrasted to other results. This is essential in any discipline,
>   as we can find in areas such as multimedia communications or computer
>   vision, but the networking area does not have anything like it.
Fully agree, this is essential for comparing results. This is well
linked to datasets issues as well and in general with reproducible
> - The definition of "wire protocols", interfaces, and the format of data
>   exchanged (also as YANG models) that are easily identified in the IDN
>   architecture figure that I think all of us support to some extent.
> - Of course, the IDN reference architecture (but this has been deeply
>   discussed).
> As you can perceive, I am trying to be practical. This somehow contrasts
> with my typical views, which are normally quite abstract, but those work
> are quite obvious, are not defined elsewhere, and can be a good starting
> point to form a WG in the future. For the moment, we can address such
> work through other RG/WG (e.g. NMRG) so we can begin the writing of some
> drafts-of-drafts for IETF 100. If you are interested on doing it, please
> let me know and we can define some schedule and some rough ToC for those
> documents. Thank you very much.
> Regards,
> Pedro
> On Wed, Jul 26, 2017 at 11:38:09AM +0000, Sheng Jiang wrote:
>> Hi, all,
>> Please find the below figure that I shared in the IDN discussion meeting last week in Prague. This illustrates the IDN architecture in a very generic way. The on-site participants had the very similar understanding that the upper left box - the unified and selected data is should be the prior work towards standardization. Also, the participants shared the same opinion that the data structure may be various among use cases. So, we should keep discussing on use cases with the target to converge on one or two significant and specific use cases.
>> [cid:image001.png@01D30643.900DB7F0]
>> Regards,
>> Sheng
>> _______________________________________________
>> IDNET mailing list