RE: Scope of strict SLA in network slicing
"Dongjie (Jimmy)" <jie.dong@huawei.com> Thu, 16 November 2017 08:41 UTC
Return-Path: <jie.dong@huawei.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF6E126BFD for <rtgwg@ietfa.amsl.com>; Thu, 16 Nov 2017 00:41:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 TaSgp6X_FJDj for <rtgwg@ietfa.amsl.com>; Thu, 16 Nov 2017 00:41:08 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 89AFA124217 for <rtgwg@ietf.org>; Thu, 16 Nov 2017 00:41:08 -0800 (PST)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 60D24CC7F73CB for <rtgwg@ietf.org>; Thu, 16 Nov 2017 08:41:05 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 16 Nov 2017 08:41:06 +0000
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.148]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 16:41:00 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: RE: Scope of strict SLA in network slicing
Thread-Topic: Scope of strict SLA in network slicing
Thread-Index: AQHTXqeIIbLq90mg60G8LZ0co9DN16MWnG5Q
Date: Thu, 16 Nov 2017 08:41:00 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927981311B3@NKGEML515-MBS.china.huawei.com>
References: <CA+RyBmX7zgp3WgeMpov2=vbThWwDXs_XJJiGeyiaSKgrPpo0RA@mail.gmail.com>
In-Reply-To: <CA+RyBmX7zgp3WgeMpov2=vbThWwDXs_XJJiGeyiaSKgrPpo0RA@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.33.217]
Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927981311B3NKGEML515MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/NW_HdxKs0B_z8C93lLoRAMrXmFg>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2017 08:41:11 -0000
Hi Greg, I agree that network slicing would mainly be used for URLLC services, which have stringent requirement on performance. To meet such requirement, we need to consider the E2E transport paths. FlexE can be one candidate technology for interface level channelization and isolation, and we also need to consider other pieces in the end-to-end paths. OTOH, as mentioned in the enhanced VPN presentation, the mechanism used to represent the underlay resources can be general and independent from the implementation of the resource partitioning, such as using SR SIDs to represent per-hop resource allocation. Best regards, Jie From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: Thursday, November 16, 2017 2:53 PM To: rtgwg@ietf.org Subject: Scope of strict SLA in network slicing Dear All, I'd like to stress what I've said at the mike. Two of three network slicing scenarios, enhanced mobile broadband and massive IoT, that have been defined by 3GPP do not set forth too strict latency/jitter/packet loss constraints. But netslices to support ultra-reliable and low latency communications (URLLC) are expected to have very stringent latency/jitter/packet loss constraints e2e. But, in my opinion, there's no requirement that URLLC slices must share physical resources. One of solutions may use, for example, FlexE to deliver CBR guaranteed services. Regards, Greg
- Scope of strict SLA in network slicing Greg Mirsky
- RE: Scope of strict SLA in network slicing Dongjie (Jimmy)