Re: [Idnet] Architecture and standard opportunities of IDN

Pedro Martinez-Julia <> Thu, 27 July 2017 00:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DEC26131F17 for <>; Wed, 26 Jul 2017 17:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GSzpUE34BWYn for <>; Wed, 26 Jul 2017 17:45:19 -0700 (PDT)
Received: from ( [IPv6:2001:df0:232:300::2]) by (Postfix) with ESMTP id 7FF0B131F0B for <>; Wed, 26 Jul 2017 17:45:19 -0700 (PDT)
Received: from ( []) by with ESMTP id v6R0jCVp003234; Thu, 27 Jul 2017 09:45:12 +0900 (JST)
Received: from ( []) by with ESMTP id v6R0jCSE003226; Thu, 27 Jul 2017 09:45:12 +0900 (JST)
Received: from spectre (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (NICT Mail Spool Server2) with ESMTPS id 6A0C3BCF7; Thu, 27 Jul 2017 09:45:12 +0900 (JST)
Date: Thu, 27 Jul 2017 09:45:12 +0900
From: Pedro Martinez-Julia <>
To: Sheng Jiang <>
Cc: "" <>, yanshen <>
Message-ID: <20170727004512.GC18300@spectre>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.8.3 (2017-05-23)
X-Virus-Scanned: clamav-milter 0.98.7 at zenith2
X-Virus-Status: Clean
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: Thu, 27 Jul 2017 00:45:22 -0000

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.

- 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.

- 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

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.


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

Pedro Martinez-Julia
Network Science and Convergence Device Technology Laboratory
Network System Research Institute
National Institute of Information and Communications Technology (NICT)
4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan
*** Entia non sunt multiplicanda praeter necessitatem ***