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

Kiran Makhijani <kiranm@futurewei.com> Thu, 17 October 2019 13:59 UTC

Return-Path: <kiranm@futurewei.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 CF4C6120288 for <teas-ns-dt@ietfa.amsl.com>; Thu, 17 Oct 2019 06:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 xyxwvuwgoP4c for <teas-ns-dt@ietfa.amsl.com>; Thu, 17 Oct 2019 06:59:49 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750110.outbound.protection.outlook.com [40.107.75.110]) (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 A8F2012000F for <teas-ns-dt@ietf.org>; Thu, 17 Oct 2019 06:59:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lD/0cTsng72WaPFXTQpgzTdWp2/CqWZe/dQpzNMonKD7Zd2U89XzPzIDEciTDcPZITwDPKtyIh0xrRriNJNC5yVuC+YcTmszjHqnrzDjQQ6Eb0FLjSXSksmK6+Af2gkG+OTP0U6Ykl0lVnKGNdpbnnIAdpWxGguxHpvhrcM6AaODGwx4XzikzHMHKeHSrUbDx5W3zC9zWw7KSA/IZPvtMB5aF5TCxwsZo3ZkDinnYmmo5iEBUtAlzLBm4hD4ufpiOK93kr7lX+34saADKx1e6MytPEe6JAV15q6utowx6rAq5VTA6YqYlHx0v2zFOyX1fEAAaob1vS94bxOY2w1D3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k/Gx/XRmALi2C9A1UWJ7DIKShBI+UK6SV2/2pIoqi8g=; b=bTjf7Ltj3NpaKvTx3k+PXt4LeAMpZsuQOrjs8Ule1PwbsPOvtJ1rFMTAEp52KZaE+BseWeQfDQlDZmjkwkcvHt3PBN3EEjb0qWieTOl1MWQJPLskL6hxndUMiKMJi/VZoNRdiGPFBW2c2bk8j8TSpkbdj5474J6QsI/IfaSEVyWHMvst1lnWlsiiNIeerzPV9DIRcXyq33KO171NJeo3sEgnLaAFygW6X7j5qtto5RPU+ExF4lwv1GHpiOdf2G0i1GVmrCOSwXGNeFbOCZsAlfl5bqOHcH0JxPOeDhISrxPpO+8Ujwt9HwotSkQN4NQXtKPJJkNMPEucPeLU0E4Ojg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k/Gx/XRmALi2C9A1UWJ7DIKShBI+UK6SV2/2pIoqi8g=; b=LV3c+A8EhzdfeS9mQdph7GORdnqHPix3Q3q2LY0FCP+xbooywjzKZtfA/ss1pYIf90Hghfzs6awpq8D/ABTt2PiG0wqDy7FDDjByVNqpmPulnYohNvS0DE0F3+yG+yOmqTOEetpOzrEje0ye8Btn2nXykFhU1YYTCIIu3gJXhoQ=
Received: from BYAPR13MB2437.namprd13.prod.outlook.com (52.135.229.151) by BYAPR13MB2871.namprd13.prod.outlook.com (20.178.239.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2367.14; Thu, 17 Oct 2019 13:59:44 +0000
Received: from BYAPR13MB2437.namprd13.prod.outlook.com ([fe80::c5ad:a8df:eae5:ba62]) by BYAPR13MB2437.namprd13.prod.outlook.com ([fe80::c5ad:a8df:eae5:ba62%7]) with mapi id 15.20.2367.014; Thu, 17 Oct 2019 13:59:44 +0000
From: Kiran Makhijani <kiranm@futurewei.com>
To: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>, "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, "'Dongjie (Jimmy)'" <jie.dong@huawei.com>, "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
Thread-Topic: [Teas-ns-dt] 答复: Definition of transport network slicing
Thread-Index: AQHVhJcov8PLXqPj/EGKUlyDhoBAyKde0W2A//+WOgA=
Date: Thu, 17 Oct 2019 13:59:43 +0000
Message-ID: <6B535592-4BF5-48F8-8437-7B3F6333396D@futurewei.com>
References: <57B59086-BFF0-412E-9FD2-121801FF6DB5@nokia.com> <AM6PR06MB608860D492743790B0D4E5FE9E6D0@AM6PR06MB6088.eurprd06.prod.outlook.com>
In-Reply-To: <AM6PR06MB608860D492743790B0D4E5FE9E6D0@AM6PR06MB6088.eurprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kiranm@futurewei.com;
x-originating-ip: [156.106.233.213]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6559c765-87bd-4e3b-261a-08d7530a4354
x-ms-traffictypediagnostic: BYAPR13MB2871:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BYAPR13MB2871F0A909AA64BAC2E6FD98D96D0@BYAPR13MB2871.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01930B2BA8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39840400004)(376002)(346002)(396003)(366004)(136003)(199004)(40134004)(189003)(2906002)(8936002)(99936001)(7736002)(25786009)(296002)(9326002)(316002)(54896002)(6306002)(446003)(6512007)(6506007)(6246003)(110136005)(2501003)(3846002)(81156014)(224303003)(81166006)(6116002)(790700001)(66574012)(86362001)(66066001)(33656002)(606006)(2616005)(6436002)(66946007)(99286004)(476003)(5660300002)(229853002)(76116006)(486006)(14444005)(256004)(66616009)(733005)(6486002)(236005)(66556008)(478600001)(66476007)(66446008)(64756008)(91956017)(14454004)(966005)(186003)(76176011)(71200400001)(71190400001)(11346002)(53546011)(102836004)(36756003)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR13MB2871; H:BYAPR13MB2437.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LUiKhGEoMF688GS8GuTs65Ccen5zCYorXSPhd6yH0mg89ydJ8Avdl/tNZGLM596FpiburdaVRS46oCgJZf0iZUTeU1XlbbfwXV8t0j4j9CEsIg7eRqsHO7TB1/WBg4LYMBwcfXM8+W2cfVgsZV37j89VWK0quUd6oeF76D3MdvcJBT+5BOD5r1l7YhzUToRF89pWZf8fxUZRnysH2SwNefG5zZJ01DQ8tZRcVGWSPP2OwVd2w0zoE+cy0U8ovxlfDmnGF5Q2gxzY2Zo4KrOJ95xNg4KrGdsfSG39/wgUY/c09nb+fqqt7SLzWstgSWSKV+DoCgBVuvsYmB9uppjDfLoo2wfAOrD7RX0pMOyqKYLavcy6A/o677+PWokm1wPmSkSXLB/mkcLXm+pWEZCfTkfXPU9MjLrCrl2cgFsLYgGjDTs98cQpK9DKZ2EBxTPn+EClzi+W2xXi22bUypG8bg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_004_6B5355924BF548F884377B3F6333396Dfutureweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6559c765-87bd-4e3b-261a-08d7530a4354
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2019 13:59:43.9341 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ua2mOR98x218qIukgaEeTnOCwa0hWNZYJwwict8i+DxQSVrnf3KYoOtt9+SMzQMhLdGXXpD/71Lhp5xac3GELg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2871
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/lPrCXv4LzpENLTzqQcosPj-1r3k>
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 13:59:54 -0000

Hello Luis,
any action from this customer could collide with actions from others.
^^^^
Did you mean with in the set of resources allocated to the customer or otherwise? If it is with in the allocated resources, there should not be collision. Otherwise, in my opinion customer interface should only be  allowed to request resource changes via the slice operator – which in turn will be able to figure out if such a request is possible..

--
Regards,
Kiran



From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org> on behalf of LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
Date: Thursday, October 17, 2019 at 3:23 PM
To: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, "'Dongjie (Jimmy)'" <jie.dong@huawei.com>, "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
Subject: Re: [Teas-ns-dt] 答复: Definition of transport network slicing

Hi Reza, all,

Regarding: “shared or dedicated transport slices is up to the MNO which in turn depends on level of customers (i.e. customer is Gold, Silver etc) and customers’ use-cases. Not all the use cases need strict SLA” some thoughts come to my mind.

I think there is also a dependency on the level of control that could be granted to the customer/tenant for his/her slice, in the sense that if the customer requires control (e.g., reconfiguring of paths or modification of their characteristics) any action from this customer could collide with actions from others. In consequence, a separated slice would be required to be allocated. Different levels of control could be identified, and in base of that, maybe some customers could coexist on top of the same slice or not.

Best regards

Luis

De: Teas-ns-dt <teas-ns-dt-bounces@ietf.org> En nombre de Rokui, Reza (Nokia - CA/Ottawa)
Enviado el: jueves, 17 de octubre de 2019 0:01
Para: Aijun Wang <wangaijun@tsinghua.org.cn>; 'Dongjie (Jimmy)' <jie.dong@huawei.com>; teas-ns-dt@ietf.org
CC: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>
Asunto: Re: [Teas-ns-dt] 答复: Definition of transport network slicing

Hi Aijun,

The isolation of transport slices shall be possible and it depends on the use-case and customer’s request (aka tenant).

For example let’s assume the customer (aka Tenant) City Of New York would like to have an E2E network slice to connect all the CCTVs in the buses across the city. In this case it asks the MNO (e.g. AT&T) to create an e2e network slice which in turn results in creation of one or more transport slices (in addition to RAN Slice and Core slice). If for example customer City of NY is gold customer for AT&T, it will decide to have dedicated transport slices to make sure the SLAs are met.
It is also possible for AT&T to share one or more transport slices for a few customers.

In summary, shared or dedicated transport slices is up to the MNO which in turn depends on level of customers (i.e. customer is Gold, Silver etc) and customers’ use-cases. Not all the use cases need strict SLA.

Cheers,
Reza


From: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Date: Thursday, October 17, 2019 at 6:40 AM
To: Reza Rokui <reza.rokui@nokia.com<mailto:reza.rokui@nokia.com>>, "'Dongjie (Jimmy)'" <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>, "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, 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@01D58503.DAF6C860]



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<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teas-enhanced-vpn-03&data=02%7C01%7Ckiranm%40futurewei.com%7Cdf51b7a5bdef4a7e930d08d753051e7a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637069153824385941&sdata=gPj6StzF5QQ6LJCwaSvOTvOAHPFCXQ6y0t2Qi4naPDU%3D&reserved=0> 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

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição