Re: [Teas] Network Slicing design team definitions - isolation and resolution

"Dongjie (Jimmy)" <jie.dong@huawei.com> Sun, 26 April 2020 15:08 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FE23A0861 for <teas@ietfa.amsl.com>; Sun, 26 Apr 2020 08:08:37 -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, 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 mf-6kobfDVlZ for <teas@ietfa.amsl.com>; Sun, 26 Apr 2020 08:08:35 -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 0DA103A085F for <teas@ietf.org>; Sun, 26 Apr 2020 08:08:35 -0700 (PDT)
Received: from lhreml742-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6F813B2E57E1BFD714AE for <teas@ietf.org>; Sun, 26 Apr 2020 16:08:32 +0100 (IST)
Received: from dggeme702-chm.china.huawei.com (10.1.199.98) by lhreml742-chm.china.huawei.com (10.201.108.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Sun, 26 Apr 2020 16:08:31 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme702-chm.china.huawei.com (10.1.199.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Sun, 26 Apr 2020 23:08:29 +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; Sun, 26 Apr 2020 23:08:29 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Zhenghaomian <zhenghaomian@huawei.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Network Slicing design team definitions - isolation and resolution
Thread-Index: AdYbdItwHhNquBPnfUC6RexsODws4///fBCA//61/9A=
Date: Sun, 26 Apr 2020 15:08:29 +0000
Message-ID: <a94fe17dae2244b0af6a9303e68f1e0e@huawei.com>
References: <E0C26CAA2504C84093A49B2CAC3261A43F83079E@dggeml531-mbs.china.huawei.com> <c467e349-efd8-1519-7d8a-1f242042cfed@joelhalpern.com>
In-Reply-To: <c467e349-efd8-1519-7d8a-1f242042cfed@joelhalpern.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.171.22]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/1b08tulNDw3pPjUXJ7nIbLud9Dc>
Subject: Re: [Teas] Network Slicing design team definitions - isolation and resolution
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Apr 2020 15:08:37 -0000

Hi Joel, 

Please see some replies inline:

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Sunday, April 26, 2020 10:52 AM
> To: Zhenghaomian <zhenghaomian@huawei.com>; teas@ietf.org
> Subject: Re: [Teas] Network Slicing design team definitions - isolation and
> resolution
> 
> Actually, I am not at all sure that the erquest you describe is reasonable.  The
> data is going to go through devices with other people's
> data.  It's the Internet.   Even if you give them an entire wavelength,
> it is going through the same fiber as other people's data.

You are right that typically the data will share the network infrastructure with other data, while usually network slicing is not in internet. 

And your second point is related to the degree of isolation. Different fibers can also be possible it is required by a customer. 

> If the customer wants an entirely separate phsical infrastructure, then you do
> not need any of the orchestration taht has been discussed.
> Because in order to do that you ahve to physically wire up separate devices,
> separate cables, etc.  That can not be orchestrated.  It can not use data center
> technology.  (Sure, you can give a customer dedicated servers.  That is
> something I understand.  We do know that active compute can get across
> boundaries.  But we are discussing shared networking infrastructure, not the
> asigned compute platforms.)

Different customers of an operator can ask for different levels of isolation. These can be met with the same network infrastructure, using different approaches for network resource partitioning. It is similar to the server side, where there are different approaches for virtualization, with different levels of isolation.

> 
> And from the opposite perspective, data does not look at other data. (In
> contrast to compute, where we know it can look, and modify across
> boundaries.)  So going through the same cable with other people's data is an
> irrelevant constraint.  Even security folks do not ask for avoiding that.  What is
> the problem the customer wants to solve.

The impact between data of different customers is that data of one customer may have to wait for the processing of the data of another customer, which result in its SLA being violated.

> 
> More importantly, it is not something the customer has any way to verify.
> There is no test a customer can run that will verify this.
> Making unverifiable promises is rarely a useful thing to do.

Totally agree that tools for verification is important. As mentioned in Haomian's mail, isolation can be verified with suitable tools which can be used to collect the information at the necessary places with a suitable interval. And it is important that customers can be provided with such tools to monitor the performance and be informed of SLA violation.

Best regards,
Jie

> 
> Yours,
> Joel
> 
> PS: Note that I understand that operators get asked for odd things mby
> customers.  But if we are going to define standards to support it, we need to
> understand the actual need.
> 
> On 4/25/2020 10:44 PM, Zhenghaomian wrote:
> > Not sure if I understand your question correctly.
> > Well, it's reasonable for people to request hard isolation because 'I don't want
> my data to be transported together with other people's data'.
> > For delivery this can be achieved by separating physical devices/connections,
> which are visible to users. For example dedicated boxes and fibers will guarantee
> the user's data is not mixed with others...
> >
> > Best wishes,
> > Haomian
> >
> > -----邮件原件-----
> > 发件人: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> > 发送时间: 2020年4月26日 10:34
> > 收件人: Zhenghaomian <zhenghaomian@huawei.com>; teas@ietf.org
> > 主题: Re: [Teas] Network Slicing design team definitions - isolation and
> > resolution
> >
> > (trimmed)
> > What is the user perceivable effect that the user is asking for when you say "if
> the user requests isolation"?
> >
> > Yours,
> > Joel
> >
> > On 4/25/2020 10:31 PM, Zhenghaomian wrote:
> >> Hi, Kiran, Joel,
> >>
> > ...
> >> BTW, regarding the isolation, I don't see the necessity to argue whether it
> should be in SLO or not. The isolation itself, can either be requested by the user
> of the transport slice (then from NBI of TSC) to express the demand of reliability,
> or be offered by the provider of the transport slice (then from the SBI of TSC) to
> achieve the SLO requested from the user. In other words, if the user requests
> certain level of isolation in an SLO, such isolation should be provided; if the user
> does not request certain level of isolation (no isolation request in SLO), then
> there may be some isolation provided to satisfy the user's request.
> >>
> >> Best wishes,
> >> Haomian
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas