[Teas] New term for the underlay construct used for slice realization

Lizhenbin <lizhenbin@huawei.com> Tue, 10 August 2021 15:21 UTC

Return-Path: <lizhenbin@huawei.com>
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 AF7D83A0FCB for <teas@ietfa.amsl.com>; Tue, 10 Aug 2021 08:21:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gKc-SOvm1Cw1 for <teas@ietfa.amsl.com>; Tue, 10 Aug 2021 08:21:30 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE773A0FCA for <teas@ietf.org>; Tue, 10 Aug 2021 08:21:30 -0700 (PDT)
Received: from fraeml740-chm.china.huawei.com (unknown []) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Gkc902CByz6DKRk for <teas@ietf.org>; Tue, 10 Aug 2021 23:20:52 +0800 (CST)
Received: from dggpemm500006.china.huawei.com ( by fraeml740-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 10 Aug 2021 17:21:24 +0200
Received: from dggpemm500008.china.huawei.com ( by dggpemm500006.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 10 Aug 2021 23:21:22 +0800
Received: from dggpemm500008.china.huawei.com ([]) by dggpemm500008.china.huawei.com ([]) with mapi id 15.01.2176.012; Tue, 10 Aug 2021 23:21:22 +0800
From: Lizhenbin <lizhenbin@huawei.com>
To: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: New term for the underlay construct used for slice realization
Thread-Index: AdeN+wpTY0PlvtVsQlC++M4sZJMfAA==
Date: Tue, 10 Aug 2021 15:21:22 +0000
Message-ID: <2ae53e44d60548e6ac961ac992615e9b@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/mQVUDuHr-ME2EjnMEQEOxFBO_HA>
Subject: [Teas] New term for the underlay construct used for slice realization
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: Tue, 10 Aug 2021 15:21:35 -0000

Hi Folks, 

On the TEAS meeting in IETF 111, it was discussed that a common "new term" will need to be proposed for the underlay construct used for slice realization. 

There have been several related terminologies: 

1.	VTN (Virtual Transport Network)

In the early days of network slicing discussion in IETF, it was suggested that the technology in IETF should be neutral and not bound to network slicing only. Following this approach, the term VTN is defined in the enhanced VPN draft already adopted and progressing in TEAS. It is expected that the VTNs with guaranteed resources can also be applicable to services other than network slices. The VPN+ architecture allows flexible mapping (including 1:1, N:1 and 1:N mapping) between the overlay VPN services and the underlay VTNs. Since VTN is a generic term, in the context of network slicing we may still need a specialized term.

2.	Slice Aggregate

It is claimed that the scope of Slice Aggregate is tied to the scope of IETF network slices. This term implies an aggregation of one or more IETF network slices into an aggregate construct, so that only a 1:1 and N:1 mapping of network slice service to underlay construct can be achieved. However, if this is a mapping of network slice traffic streams to underlay constructs, then it may be possible to map network slice services to the underlay construct as 1:1, N:1 and 1:N, but the name may be confusing because it is not the slices that are aggregated. 

With this background in mind, now we can discuss how to define the new term. Here are some points for the WG to consider:

1.	Should the underlay construct for network slice realization bound to network slice services? That is, is the underlay construct only for use in network slicing, or should it be generalized for more possible uses?

2.	If the answer to question 1 is YES, should it reflect the following characteristics?

a.	It is about the underlay
b.	It is about the partitioned resources used to deliver the network slice services
c.	It allows the 1:1, N:1, and 1:N mapping models between the network slice services and the underlay construct. The 1:1 and N:1 mapping may be straightforward. Does it also make sense to divide the elements or traffic flows in a single network slice service to carry them in different underlay constructs?

Lastly, here are some candidates of the "new term":

Option 1: The network slice service is called "overlay slice", then the underlay construct is called "underlay slice".

Option 2: The network slice service is called "service slice", then the underlay construct is called "resource slice".

Your opinion about these candidates are much appreciated. You may also propose other new term if it complies with the above two points.

Best Regards,