[Teas] networking slicing design team results + call for feedback

Jari Arkko <jari.arkko@piuha.net> Thu, 02 April 2020 09:37 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A78BD3A0E66 for <teas@ietfa.amsl.com>; Thu, 2 Apr 2020 02:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LfbYvApjIxlK for <teas@ietfa.amsl.com>; Thu, 2 Apr 2020 02:36:59 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF3C3A0E65 for <teas@ietf.org>; Thu, 2 Apr 2020 02:36:59 -0700 (PDT)
Received: from localhost (localhost []) by p130.piuha.net (Postfix) with ESMTP id 93D616601DF for <teas@ietf.org>; Thu, 2 Apr 2020 12:36:58 +0300 (EEST)
Received: from p130.piuha.net ([]) by localhost (p130.piuha.net []) (amavisd-new, port 10024) with ESMTP id BXZ_F6Rsf9CQ for <teas@ietf.org>; Thu, 2 Apr 2020 12:36:57 +0300 (EEST)
Received: from [] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id F1D4A66018B for <teas@ietf.org>; Thu, 2 Apr 2020 12:36:56 +0300 (EEST)
From: Jari Arkko <jari.arkko@piuha.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <FF568B3C-DC75-4E5F-A393-D2CB3F83AF97@piuha.net>
Date: Thu, 2 Apr 2020 12:36:56 +0300
To: teas@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/CCnfzDAgk_P7Z26Mr2WV5ezcN4g>
Subject: [Teas] networking slicing design team results + call for feedback
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2020 09:37:02 -0000

As you know, we’ve had a design team looking at how IETF VPN and TE technologies can be used to assist network slicing; to provide a framework [1]. The design team has been running for a couple of months, enough to have some first, very early results. We have two documents, one about definitions and another one about a framework of how slicing, underlying technologies, controllers, etc. fit together. The central concept is that one of a “transport slice”, which we believe would be useful as a component in various people building their networks. A transport slice is nothing magical, it is simply the service that many IETF technologies are already offering. And we can of course keep improving them.
It is important to understand that the design team is not here to develop new VPN/TE technologies, not here to focus on specific new characteristics that one may want from one’s VPNs, not here to define 5G slicing, not here to look at compute and services, and hopefully not here to boil the ocean. We’re also not done, as noted the documents that we have are early, and perhaps more importantly, there are still other things to develop. For instance, presumably one would like to have a data model or an interface with which one can request transport slices. Such an interface may partially exist already but the design team seems to believe that at least some enhancements will be needed. That’s all future work, either in the design team or as part of existing tech being improved. We also do not at the moment have a document that would point to all the relevant existing technologies that can be used to realise the framework or other frameworks across technologies for other reasons (e.g., enhanced-vpn that looked at enhanced isolation and also has a very good documentation of the existing IETF VPN technologies). Those are all forthcoming work as well.

At this point we’d love to get feedback on these documents though:
[1] https://mailarchive.ietf.org/arch/msg/teas/jiHWXU_i5kK5BzjRffFbYnbZJfs/