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

Stewart Bryant <stewart.bryant@gmail.com> Sun, 17 November 2019 22:20 UTC

Return-Path: <stewart.bryant@gmail.com>
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 53D13120110 for <ieee-ietf-coord@ietfa.amsl.com>; Sun, 17 Nov 2019 14:20:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 EZngPyv-1DAV for <ieee-ietf-coord@ietfa.amsl.com>; Sun, 17 Nov 2019 14:20:49 -0800 (PST)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 4A612120106 for <ieee-ietf-coord@ietf.org>; Sun, 17 Nov 2019 14:20:49 -0800 (PST)
Received: by mail-pl1-x634.google.com with SMTP id j12so8540525plt.9 for <ieee-ietf-coord@ietf.org>; Sun, 17 Nov 2019 14:20:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=una6Rv4eIuizOA2CH/G6PE2fOY3p6PNSfGSd05GB2ic=; b=vA53L/RB30Tol8hx/aUFghUM16wcKnL6ho5N7M2B6bbcutafOGl4Ax81pYVTyEu+Hz TrDn+xuSWXpICJbhh35nijz/7WyQVF6o/614VQ1HxYE9O6TZaQL2e+OOEMa6bW0v062p HL+kPhkq5rCIQUdjs+TKGz6dUUe4Wxd2irKrfaj7LXC2xQGhMkm8khQ+xi/tt7R6x9qQ 3H8qBpve+5wyWcO1IWt4J/h9b43DbRUYOixXUSmNmhob9ClKXjz6DNrNT54OJC9lF5UQ iyXBa/7xtXr/UEK96wKgkLSBU0dNWoaZ+xcj1nSBChlkSItl+a1qnuR8Zz0OiJxtsUSb x/KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=una6Rv4eIuizOA2CH/G6PE2fOY3p6PNSfGSd05GB2ic=; b=diKkmW7uSqb2oiS8cViVaWijD1Qw7Zxd2EjmOesnpfmwa3RmV6iUakluKkHTrKYEbo QxfJx56xcswylSCrVriGXpFNbWXuySjfX2JpTsqhwWDX8MYAinZSu5sQJ2xGgWef3fC+ 9mlSGtm8oG/22+O9EBLyGG0C7jRAvKtRdAG3lA/YolZTfXjd2bhY4lqk3IXIr2Ep//db nRoT5D0Qbu6/b2/KM9mKojFpD+w5MBjBvPeLqwV1ZBK7RSrj0mmJuVL7cRTZug4zMuSj tC4B1OwqgVcl1kbkdWUuh66BENrF7ayqFiRFE66hY8lGdIv00l4tLJI+euPERMKPcJQm Bsxw==
X-Gm-Message-State: APjAAAVKVmOgcH/bsvFbSmN0Mt4zbNRyABHvJKGwTkOcbwp7hWp2cwvb 1ZaE7ePM49wnFE+3TKsQgiiorTp9DBE=
X-Google-Smtp-Source: APXvYqwe0nUa2Cp/c6vFHHCiyosMYVGC11rat+wuPkDx/N3XueUIEkKZjCnsnjHr2HCzGCOAaIsD/g==
X-Received: by 2002:a17:902:a714:: with SMTP id w20mr25074875plq.162.1574029248624; Sun, 17 Nov 2019 14:20:48 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:8d5:b53d:5f20:e073? ([2001:67c:1232:144:8d5:b53d:5f20:e073]) by smtp.gmail.com with ESMTPSA id w15sm13013700pfi.168.2019.11.17.14.20.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 14:20:47 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <17A5D058-4C63-49E3-9FA6-7659FC04438D@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_141C1351-6442-4478-BDEF-C0F3E55CD77F"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Mon, 18 Nov 2019 06:20:45 +0800
In-Reply-To: <MN2PR11MB44618CBD0231468892EF0E6CCF720@MN2PR11MB4461.namprd11.prod.outlook.com>
Cc: Russ Housley <housley@vigilsec.com>, "<ieee-ietf-coord@ietf.org>" <ieee-ietf-coord@ietf.org>
To: "Andrew Myles (amyles)" <amyles@cisco.com>
References: <A1623302-8C4F-4756-A9C9-0AAA34BFA9DB@vigilsec.com> <MN2PR11MB44618CBD0231468892EF0E6CCF720@MN2PR11MB4461.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ieee-ietf-coord/9Rbyg9rIbvIBnXoVmDZqJlgUs88>
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 22:20:51 -0000

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 <mailto: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 <mailto:ieee-ietf-coord@ietf.org>> <ieee-ietf-coord@ietf.org <mailto: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 <mailto:ieee-ietf-coord@ietf.org>
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord <https://www.ietf.org/mailman/listinfo/ieee-ietf-coord>_______________________________________________
> ieee-ietf-coord mailing list
> ieee-ietf-coord@ietf.org <mailto:ieee-ietf-coord@ietf.org>
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord <https://www.ietf.org/mailman/listinfo/ieee-ietf-coord>