Re: [Teas-ns-dt] Definition of transport network slicing

"Dongjie (Jimmy)" <jie.dong@huawei.com> Thu, 17 October 2019 09:24 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: teas-ns-dt@ietfa.amsl.com
Delivered-To: teas-ns-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F62120854 for <teas-ns-dt@ietfa.amsl.com>; Thu, 17 Oct 2019 02:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 IAi0dly0ChTz for <teas-ns-dt@ietfa.amsl.com>; Thu, 17 Oct 2019 02:24:46 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AECD412084D for <teas-ns-dt@ietf.org>; Thu, 17 Oct 2019 02:24:45 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 859398A1B94230D55F23 for <teas-ns-dt@ietf.org>; Thu, 17 Oct 2019 10:24:43 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 17 Oct 2019 10:24:41 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0439.000; Thu, 17 Oct 2019 17:24:36 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>, "'Rokui, Reza (Nokia - CA/Ottawa)'" <reza.rokui@nokia.com>, "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
Thread-Topic: [Teas-ns-dt] Definition of transport network slicing
Thread-Index: AQHVhCmLNkwDr32fR0W4Hi17u6EzmKdeAz5QgACK+vA=
Date: Thu, 17 Oct 2019 09:24:35 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927CD28C42B@NKGEML515-MBX.china.huawei.com>
References: <23F39B19-B3FE-4F67-BCB2-4C4891A591AB@nokia.com> <019d01d58487$a50d95c0$ef28c140$@org.cn>
In-Reply-To: <019d01d58487$a50d95c0$ef28c140$@org.cn>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.151.75]
Content-Type: multipart/related; boundary="_004_76CD132C3ADEF848BD84D028D243C927CD28C42BNKGEML515MBXchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/6MaaNZv4vVAFrVm-2doli8F9NwM>
Subject: Re: [Teas-ns-dt] Definition of transport network slicing
X-BeenThere: teas-ns-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TEAS Network Slicing Design Team <teas-ns-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas-ns-dt>, <mailto:teas-ns-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas-ns-dt/>
List-Post: <mailto:teas-ns-dt@ietf.org>
List-Help: <mailto:teas-ns-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas-ns-dt>, <mailto:teas-ns-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2019 09:24:49 -0000

Hi Aijun,

In my understanding isolation is one of the target of transport network slicing, and depends on the service requirement, different levels of isolation may be required. For example, some service may simply require isolation of service accessibility, while some other service requires resource isolation to provide guaranteed or predictable SLA. The definition needs to cover both cases.

Best regards,
Jie

From: Aijun Wang [mailto:wangaijun@tsinghua.org.cn]
Sent: Thursday, October 17, 2019 9:10 AM
To: 'Rokui, Reza (Nokia - CA/Ottawa)' <reza.rokui@nokia.com>; Dongjie (Jimmy) <jie.dong@huawei.com>; teas-ns-dt@ietf.org
Subject: 答复: [Teas-ns-dt] Definition of transport network slicing

Hi, Reza,Jie and all:
For the transport, do we need to emphasize the isolation? Is any solution that can meet the application’ SLA  acceptable?
From the 5G document, the isolation concept refer mainly to its functional entities.

Best Regards.

Aijun Wang
China Telecom

发件人: teas-ns-dt-bounces@ietf.org<mailto:teas-ns-dt-bounces@ietf.org> [mailto:teas-ns-dt-bounces@ietf.org] 代表 Rokui, Reza (Nokia - CA/Ottawa)
发送时间: 2019年10月16日 21:57
收件人: Dongjie (Jimmy); teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>
抄送: Rokui, Reza (Nokia - CA/Ottawa)
主题: Re: [Teas-ns-dt] Definition of transport network slicing

Hi Jie and all,

Your definition is correct. However, the following is my view. Please add comments.

In general a transport slice has a definition and a realization (aka implementation). The transport slice definition is whatever Jie mentioned below and I rephrase it here. i.e.

  *   Transport slice definition: A set of connections each with appropriate isolation and specific Service Level Agreement (SLA).

However an transport slice has an implementation (or realization) as well. To clarify, let’s have an example.
The following picture shows the most complex 5G network (i.e. Cloud RAN where it contains fronthaul, midhaul and backhaul networks. In this picture there are 4 different transport slices for a single E2E network slice.

Each of transport slices 1 to 4 has an implementation which potentially has different technologies and different techniques. For example, the transport slice 3 can be realized on IP network using L3VPN or VPN+ or any other techniques to satisfy certain SLAs. The fact is that we can realize the transport slice 3 using different techniques but the regardless of that, the definition of the transport slice 3 does not change (which is connectivity of CUs to Core network).

Another example is the transport slice 2 in midhaul which its definition is connectivity between DUs to CUs. In majority of  deployments, this transport slice will be realized using PON technique or IP VPNs. Again regardless of implementation, the transport slice 2’s definition is DUs to CUs connectivity with certain SLAs.

If needed, I can present a few slides during our call on Oct 17th.

Cheers,
Reza


[cid:image001.png@01D5850F.2E81CD80]



From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org<mailto:teas-ns-dt-bounces@ietf.org>> on behalf of "Dongjie (Jimmy)" <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Date: Monday, October 14, 2019 at 5:57 PM
To: "teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>" <teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>>
Subject: [Teas-ns-dt] Definition of transport network slicing

Hi,

As one of the action points of the design team conference call in last week, we will discuss and give the definition of transport network slicing. Here I’d like to reference the definition in https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-03 as the starting point:

“A transport network slice is a virtual (logical) network with a particular network topology and a set of shared or dedicated network resources, which are used to provide the network slice consumer with the required connectivity, appropriate isolation and specific Service Level Agreement (SLA). “

Please feel free to provide your comments and suggestions.

Best regards,
Jie