Re: [Teas-ns-dt] Appendix text on isolation
"Dongjie (Jimmy)" <jie.dong@huawei.com> Tue, 16 June 2020 10:15 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 2A6BF3A14CA
for <teas-ns-dt@ietfa.amsl.com>; Tue, 16 Jun 2020 03:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001,
SPF_PASS=-0.001, URIBL_BLOCKED=0.001]
autolearn=unavailable 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 5uInkwPxHd2O for <teas-ns-dt@ietfa.amsl.com>;
Tue, 16 Jun 2020 03:15:23 -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 60EB33A14C9
for <teas-ns-dt@ietf.org>; Tue, 16 Jun 2020 03:15:23 -0700 (PDT)
Received: from lhreml712-chm.china.huawei.com (unknown [172.18.7.107])
by Forcepoint Email with ESMTP id BEE48F3EE9755BC21A69
for <teas-ns-dt@ietf.org>; Tue, 16 Jun 2020 11:15:21 +0100 (IST)
Received: from dggeme701-chm.china.huawei.com (10.1.199.97) by
lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id
15.1.1913.5; Tue, 16 Jun 2020 11:15:20 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by
dggeme701-chm.china.huawei.com (10.1.199.97) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
15.1.1913.5; Tue, 16 Jun 2020 18:15:18 +0800
Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by
dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007;
Tue, 16 Jun 2020 18:15:18 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org>,
"teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
CC: Kiran Makhijani <kiranm@futurewei.com>
Thread-Topic: Appendix text on isolation
Thread-Index: AQHWQxMeOnwlM6C7q0au6xJVzwQhZajbG8KA///hwpA=
Date: Tue, 16 Jun 2020 10:15:18 +0000
Message-ID: <09d82c1775574d9bb79adbe73d3877f1@huawei.com>
References: <0A04E8C3-55DF-4146-8BE0-4189AE5844CE@ericsson.com>
<846A4B09-4EDE-4617-9C7E-5E0CAD96029C@ericsson.com>
In-Reply-To: <846A4B09-4EDE-4617-9C7E-5E0CAD96029C@ericsson.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.148.231]
Content-Type: multipart/alternative;
boundary="_000_09d82c1775574d9bb79adbe73d3877f1huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/8GpE57_QkLskJ-Iea50gz4Dyxso>
Subject: Re: [Teas-ns-dt] Appendix text on isolation
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: Tue, 16 Jun 2020 10:15:25 -0000
Hi Jari, Thanks for considering most of my comments in this revision. And as mentioned yesterday and in my previous email, I’d like to suggest whether the description about isolation could be rephrased a bit, so as to better clarify the requirement and realization of isolation in different dimensions. The term “isolation” can refer to multiple dimensions of requirements. A customer may ask for traffic separation or interference avoidance, or both. Accordingly, from realization’s perspective, traffic separation can be provided by VPNs, and interference avoidance can be provided by mechanisms such as capacity planning, priority mechanisms, policing or shaping, selecting dedicated resources, and so on. Hope this helps. Best regards, Jie From: Teas-ns-dt [mailto:teas-ns-dt-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Tuesday, June 16, 2020 4:26 PM To: teas-ns-dt@ietf.org Cc: Kiran Makhijani <kiranm@futurewei.com> Subject: Re: [Teas-ns-dt] Appendix text on isolation Here’s a suggested 2nd revision of the suggested text, based on yesterday’s comments on the call and Kiran’s email. Transport slices are perceived as if slice was provisioned for the customer as a dedicated network with specific SLOs. These committed SLOs for a given customer should be maintained during the life-time of the slice even in the face of potential disruptions. Such disruptions include sudden traffic volume changes either from the customer itself or others, equipment failures in the service provider network, and various misbehaviors or attacks. The service provider needs to ensure that their network can provide the requested slices with the availability agreed with its customers. Some of the main technical approaches to ensuring guarantees are about network planning, managing capacity, priority mechanisms, policing or shaping customer traffic, selecting dedicated resources, and so on. One term that has commonly been also used in this context is "isolation". This is discussed further in the framework draft [I-D.nsdt-teas-ns-framework] and has also been a topic in [I-D.ietf-teas-enhanced-vpn]. The term “isolation” implies in part traffic separation (a common feature in VPNs) and in part the selection of dedicated resources. Dedicated resources can help assure that, for instance, traffic in other slices does not affect a given slice. However, it should also be noted that this is one particular realization of a requirement for guarantees, and other mechanisms may also be used, such as priority mechanisms or policing amount of traffic entering a link from different sources. It should also be noted that neither dedicated resources or the other mechanisms can provide a 100% guarantee against problems. To maintain protection against resource and equipment failures techniques such as redundancy are needed.
- [Teas-ns-dt] Appendix text on isolation Jari Arkko
- Re: [Teas-ns-dt] Appendix text on isolation Kiran Makhijani
- Re: [Teas-ns-dt] Appendix text on isolation Dongjie (Jimmy)
- Re: [Teas-ns-dt] Appendix text on isolation Jari Arkko
- Re: [Teas-ns-dt] Appendix text on isolation Jari Arkko
- Re: [Teas-ns-dt] Appendix text on isolation LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas-ns-dt] Appendix text on isolation Luis M. Contreras
- Re: [Teas-ns-dt] Appendix text on isolation Jari Arkko
- Re: [Teas-ns-dt] Appendix text on isolation Dongjie (Jimmy)
- Re: [Teas-ns-dt] Appendix text on isolation Kiran Makhijani
- Re: [Teas-ns-dt] Appendix text on isolation Dongjie (Jimmy)
- Re: [Teas-ns-dt] Appendix text on isolation Kiran Makhijani
- Re: [Teas-ns-dt] Appendix text on isolation Dongjie (Jimmy)
- Re: [Teas-ns-dt] Appendix text on isolation Kiran Makhijani
- Re: [Teas-ns-dt] Appendix text on isolation LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas-ns-dt] Appendix text on isolation Kiran Makhijani
- Re: [Teas-ns-dt] Appendix text on isolation Dongjie (Jimmy)
- Re: [Teas-ns-dt] Appendix text on isolation Xufeng Liu
- Re: [Teas-ns-dt] Appendix text on isolation Kiran Makhijani
- Re: [Teas-ns-dt] Appendix text on isolation Eric Gray