Re: [Teas-ns-dt] Appendix text on isolation

"Dongjie (Jimmy)" <jie.dong@huawei.com> Wed, 17 June 2020 02:26 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 3099B3A0DAE for <teas-ns-dt@ietfa.amsl.com>; Tue, 16 Jun 2020 19:26:11 -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=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 4g9izLUnNrun for <teas-ns-dt@ietfa.amsl.com>; Tue, 16 Jun 2020 19:26:09 -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 A70BD3A0DAB for <teas-ns-dt@ietf.org>; Tue, 16 Jun 2020 19:26:08 -0700 (PDT)
Received: from lhreml743-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DFE96301A27A621F8684 for <teas-ns-dt@ietf.org>; Wed, 17 Jun 2020 03:26:06 +0100 (IST)
Received: from dggeme704-chm.china.huawei.com (10.1.199.100) by lhreml743-chm.china.huawei.com (10.201.108.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Wed, 17 Jun 2020 03:26:06 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme704-chm.china.huawei.com (10.1.199.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 17 Jun 2020 10:26:03 +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; Wed, 17 Jun 2020 10:26:03 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Kiran Makhijani <kiranm@futurewei.com>, Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org>, "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
Thread-Topic: Appendix text on isolation
Thread-Index: AQHWQxMeOnwlM6C7q0au6xJVzwQhZajbG8KA///hwpCAAQKvQIAACSbQ
Date: Wed, 17 Jun 2020 02:26:03 +0000
Message-ID: <6429055ec57f4bd483cd4f0e5716d5f2@huawei.com>
References: <0A04E8C3-55DF-4146-8BE0-4189AE5844CE@ericsson.com> <846A4B09-4EDE-4617-9C7E-5E0CAD96029C@ericsson.com> <09d82c1775574d9bb79adbe73d3877f1@huawei.com> <BYAPR13MB2437129DFCC21CFDDE5C8063D99A0@BYAPR13MB2437.namprd13.prod.outlook.com>
In-Reply-To: <BYAPR13MB2437129DFCC21CFDDE5C8063D99A0@BYAPR13MB2437.namprd13.prod.outlook.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_6429055ec57f4bd483cd4f0e5716d5f2huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/zf1S3dRH-6diAxxKTBhQcRY4H14>
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: Wed, 17 Jun 2020 02:26:11 -0000

Hi Kiran and all,

Your concern is part of the reason that I suggest to describe the requirement and realization of isolation separately. Firstly, multi-dimension can help to clarify the different requirements related to isolation, such as traffic separation and interference avoidance, in my understanding both of which can be raised by a customer as requirement, and they do not reflect implementation details. Then the implementation-specific mechanisms could be briefly described to match each dimension of the requirement.

The sentence you added in the end of the paragraph looks good, while maybe it could be better if such requirement description be moved to the beginning of the paragraph. Please check the modified text below:

A consumer of transport slice may ask for isolation from other transport slices.
The term “isolation” can refer to multiple dimensions of requirements,
such as traffic separation, or interference avoidance, or both. Accordingly, from
realization’s perspective, traffic separation can be provided by VPN technologies,
and interference avoidance may be provided by mechanisms such as capacity
planning, policing or shaping, priority mechanisms, selecting dedicated resources, and so on.

Please let me know your thoughts. Thanks.

Best regards,
Jie

From: Kiran Makhijani [mailto:kiranm@futurewei.com]
Sent: Wednesday, June 17, 2020 9:30 AM
To: Dongjie (Jimmy) <jie.dong@huawei.com>om>; Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org>rg>; teas-ns-dt@ietf.org
Subject: RE: Appendix text on isolation

Hi Jie, and all,
One argument against using isolation as an SLO is that it is an implementation specific detail that customer should not have to (always) concern with. So I am not comfortable with the use of ‘multi-dimensional’.
One way to separate realization and customer requirement may be we can use business objective/case. May be we can add, one sentence  at the end of the original paragraph. What do you think?

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. Business objectives may require a customer
to ask for explicit traffic separation or interference avoidance mechanisms.

-Kiran

From: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Sent: Tuesday, June 16, 2020 3:15 AM
To: Jari Arkko <jari.arkko=40ericsson.com@dmarc.ietf.org<mailto:jari.arkko=40ericsson.com@dmarc.ietf.org>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>
Cc: Kiran Makhijani <kiranm@futurewei.com<mailto:kiranm@futurewei.com>>
Subject: RE: Appendix text on isolation

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<mailto:teas-ns-dt@ietf.org>
Cc: Kiran Makhijani <kiranm@futurewei.com<mailto: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.