Re: [ieee-ietf-coord] ITU-T SG13 / FG NET-2030

Mirja Kuehlewind <ietf@kuehlewind.net> Sun, 17 November 2019 23:40 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: ieee-ietf-coord@ietfa.amsl.com
Delivered-To: ieee-ietf-coord@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7244D120220 for <ieee-ietf-coord@ietfa.amsl.com>; Sun, 17 Nov 2019 15:40:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 DXoxOkrfFzUW for <ieee-ietf-coord@ietfa.amsl.com>; Sun, 17 Nov 2019 15:40:13 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 9F422120144 for <ieee-ietf-coord@ietf.org>; Sun, 17 Nov 2019 15:40:13 -0800 (PST)
Received: from [2001:67c:1232:144:5057:1b49:f9a:8d93]; authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iWU9J-0007GS-2V; Mon, 18 Nov 2019 00:40:09 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <17A5D058-4C63-49E3-9FA6-7659FC04438D@gmail.com>
Date: Mon, 18 Nov 2019 07:40:06 +0800
Cc: "Andrew Myles (amyles)" <amyles@cisco.com>, Russ Housley <housley@vigilsec.com>, "<ieee-ietf-coord@ietf.org>" <ieee-ietf-coord@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F221450-EC18-4620-B40E-EA2B54B4FD06@kuehlewind.net>
References: <A1623302-8C4F-4756-A9C9-0AAA34BFA9DB@vigilsec.com> <MN2PR11MB44618CBD0231468892EF0E6CCF720@MN2PR11MB4461.namprd11.prod.outlook.com> <17A5D058-4C63-49E3-9FA6-7659FC04438D@gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1574034013;b8f25a0a;
X-HE-SMSGID: 1iWU9J-0007GS-2V
Archived-At: <https://mailarchive.ietf.org/arch/msg/ieee-ietf-coord/StYXyAi8XGC4hxEQlMMpdNymAFU>
Subject: Re: [ieee-ietf-coord] ITU-T SG13 / FG NET-2030
X-BeenThere: ieee-ietf-coord@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Management-level discussions between IEEE and IETF on topics of interest to both SDOs <ieee-ietf-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ieee-ietf-coord>, <mailto:ieee-ietf-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ieee-ietf-coord/>
List-Post: <mailto:ieee-ietf-coord@ietf.org>
List-Help: <mailto:ieee-ietf-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ieee-ietf-coord>, <mailto:ieee-ietf-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Nov 2019 23:40:16 -0000

I believe this was also presented in HotRFC yesterday:

https://datatracker.ietf.org/meeting/106/materials/slides-106-hotrfc-future-networks-in-2030-00


> On 18. Nov 2019, at 06:20, Stewart Bryant <stewart.bryant@gmail.com> wrote:
> 
> RENA was also pushed in ETSI as a solution to 5G backhaul. I am not sure what its standing is there, but it is not a concept that comes up in any of the backhaul discussions that I have been involve in.
> 
> To focus on FGnet2030. RENA was presented at one of the FGnet2030 workshops and John Day is an active participant in the work of the FG. However. RENA has not been formally selected and it not called up in the SubG2 work on new applications, nor is it called up in the fledgling SubG3 Architectural framework. Thus, as of today, RENA has no formal standing in FGnet2030. It is entirely legitimate within an open standards process that RENA is advocated by an individual contributor, but RENA is a long way from being selected as a technology to be recommended for development by the FG.
> 
> Best regards
> 
> Stewart
> 
> 
> 
>> On 18 Nov 2019, at 04:55, Andrew Myles (amyles) <amyles@cisco.com> wrote:
>> 
>> G'day Russ
>>  
>> You may also be interested in some work in ISO/IEC JTC1/SC6/WG7. This WG is generally planning to replace the entire internet protocol stack. J
>>  
>> More specifically, in recent times a NP Ballot (ISO/IEC NP 4396) has started  (the ballot closes 1 Feb 2020) to standardise RINA. This is a protocol that I understand John Day proposed in the IETF some time ago, but it was not taken up.
>>  
>> The proposed scope is:
>> This NP will define the Recursive IPC Network Architecture, an architecture that can meet the requirements set out in ISO/IEC TR 29181-1. It can deliver services beyond the limitations of the current Internet by providing security and guaranteeing QoS while maintaining scalability and ease of configuration. This single NP will consist of multiple specifications as follows:
>> ·       Part 1: Architecture
>> ·       Part 2: Common application connection establishment phase
>> ·       Part 3: Common distributed application protocol
>> ·       Part 4: Flow allocator
>> ·       Part 5: Error and flow control protocol
>> The work to be carried out in this project requires additional protocol specifications for the future work, which support defined architecture. Current proposed specifications are included in this document as drafts for the work to be undertaken.
>>  
>> The purpose and justification is:
>> There are significant conundrums present in the current Internet architecture. Multi-homing and mobility of hosts are not easily achievable with a standard TCP/IP stack. APIs are not standardised, making the connection between systems a problem. The Internet also has well known issues related to security, Quality of Service (QoS) and multicast. One of the worst problems is the explosion in complexity by the ever growing Internet protocol suite. These issues illustrate the need for well-defined network architectures that encourage networking engineers to apply a disciplined approach towards solving networking problems. This is the right moment to prepare specifications as different companies and governments are backing the deployment of RINA(Recursive Inter-Network Architecture)-enabled networks.
>>  
>> The ballot includes relatively complete drafts, which were written by John Day (Boston University), Eduard Grasa (i2CAT Foundation) & Miquel Tarzan (i2CAT Foundation).
>>  
>> The NP was submitted by the Spanish NB but it has support from at least the US NB and the Belgium NB
>>  
>> Andrew
>>  
>> -----Original Message-----
>> From: ieee-ietf-coord <ieee-ietf-coord-bounces@ietf.org> On Behalf Of Russ Housley
>> Sent: Saturday, 16 November 2019 2:00 PM
>> To: <ieee-ietf-coord@ietf.org> <ieee-ietf-coord@ietf.org>
>> Subject: [ieee-ietf-coord] ITU-T SG13 / FG NET-2030
>>  
>>  
>> I was recently told about an effort to take over significant standards work currently being led by the IETF.   The work taking place in ITU-T Study Group 13 / Focus Group on Technologies for Network 2030, lead by Dr. Richard Li as the FG NET-2030 chairman. The group appears to be looking to redesign the layer 3 and 4 protocols to centralize functions that would enable/facilitate data aggregation and surveillance.
>>  
>> Does anyone on this list know if FG NET-2030 is actually gaining ground?
>>  
>> Russ
>> _______________________________________________
>> ieee-ietf-coord mailing list
>> ieee-ietf-coord@ietf.org
>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>> _______________________________________________
>> ieee-ietf-coord mailing list
>> ieee-ietf-coord@ietf.org
>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
> 
> _______________________________________________
> ieee-ietf-coord mailing list
> ieee-ietf-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord