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

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 26 April 2020 02:51 UTC

Return-Path: <jmh@joelhalpern.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 C27B43A091C for <teas@ietfa.amsl.com>; Sat, 25 Apr 2020 19:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-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=joelhalpern.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 1li-gkxEn7NV for <teas@ietfa.amsl.com>; Sat, 25 Apr 2020 19:51:50 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 4A1C63A0919 for <teas@ietf.org>; Sat, 25 Apr 2020 19:51:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 498sr61123z6GDbL; Sat, 25 Apr 2020 19:51:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1587869510; bh=MzDjWoXm97N2uOKPGw4rP4w5v/Q8apQ8ws38TOJ0398=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JfWJ2uaVnTC1wBmCY9sZsUnHXjI/zXSbcmKLssgFchTdIi3ifkd0MVMeF+OMGZWvF fvyqHpPzMqGMsKB+1c/2o1j+XVQo5mn7a06TcUsHV3tcEdHRCiC9q1ZcWdFABk4YGW /TFklS6fGt80PE0VLFv/yv+3Gpq73aA4/z/F7PNo=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 498sr52m0zz6GDYK; Sat, 25 Apr 2020 19:51:49 -0700 (PDT)
To: Zhenghaomian <zhenghaomian@huawei.com>, "teas@ietf.org" <teas@ietf.org>
References: <E0C26CAA2504C84093A49B2CAC3261A43F83079E@dggeml531-mbs.china.huawei.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <c467e349-efd8-1519-7d8a-1f242042cfed@joelhalpern.com>
Date: Sat, 25 Apr 2020 22:51:49 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <E0C26CAA2504C84093A49B2CAC3261A43F83079E@dggeml531-mbs.china.huawei.com>
Content-Type: text/plain; charset=gbk; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/EPjZAx-l_XUa1N-JiVvTrzfwwkU>
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 02:51:52 -0000

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.
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.)

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.

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.

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>om>; 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