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

Zhenghaomian <zhenghaomian@huawei.com> Sun, 26 April 2020 06:27 UTC

Return-Path: <zhenghaomian@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 562693A096B for <teas@ietfa.amsl.com>; Sat, 25 Apr 2020 23:27:21 -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 S-hjsJw_x7zZ for <teas@ietfa.amsl.com>; Sat, 25 Apr 2020 23:27:18 -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 8CADA3A0967 for <teas@ietf.org>; Sat, 25 Apr 2020 23:27:18 -0700 (PDT)
Received: from lhreml712-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 98257297B980ED03FA0B for <teas@ietf.org>; Sun, 26 Apr 2020 07:27:16 +0100 (IST)
Received: from lhreml712-chm.china.huawei.com (10.201.108.63) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sun, 26 Apr 2020 07:27:16 +0100
Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Sun, 26 Apr 2020 07:27:16 +0100
Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.240]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0487.000; Sun, 26 Apr 2020 14:27:11 +0800
From: Zhenghaomian <zhenghaomian@huawei.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Network Slicing design team definitions - isolation and resolution
Thread-Index: AdYbdItwZqSV0WoJSFOt1j29Tf6CaP//fBCA//9EhRA=
Date: Sun, 26 Apr 2020 06:27:09 +0000
Message-ID: <E0C26CAA2504C84093A49B2CAC3261A43F830980@dggeml531-mbs.china.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: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.24.176.178]
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/a84agqtiddbIppZ86BVKxx4pn-0>
Subject: [Teas] =?gb2312?b?tPC4tDogIE5ldHdvcmsgU2xpY2luZyBkZXNpZ24gdGVh?= =?gb2312?b?bSBkZWZpbml0aW9ucyAtIGlzb2xhdGlvbiBhbmQgcmVzb2x1dGlvbg==?=
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 06:27:23 -0000

Inline...

Best wishes,
Haomian

-----邮件原件-----
发件人: Joel M. Halpern [mailto:jmh@joelhalpern.com] 
发送时间: 2020年4月26日 10:52
收件人: Zhenghaomian <zhenghaomian@huawei.com>om>; teas@ietf.org
主题: 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.
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.)
[Haomian] An example: some people travel by taxi, some others travel by bus. They are both 'on the road with each other', but they service level should be differentiated and the user should be able to select between taxi and bus. I think the network is in similar circumstance. 

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.
[Haomian] Agree on 'data does not look at other data'. The isolation should not be checked by data. 

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.
[Haomian] I agree this is more important, and also agree on the statement 'Making unverifiable promises is rarely a useful thing to do '. I am not sure if you are claiming 'the isolation is not verifiable' or 'the customer is lack of capability to verify isolation'. For the former, when the congestion is analyzed, engineers may know where the data is stuck, such as 'there are many different slices queuing at this router/link', which helps understanding the slice is not isolated. For the latter, I had a feeling that the customer may be lack of capability to verify not only isolation, but other more fundamental parameters like redundancy and security mentioned in section 4.1 of the draft. 

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.
[Haomian] Yes, that is exactly why I was writing and requesting for the explanation on explicit understanding SLO, then we will know what is the user 'should ask' and what is not. Unfortunately our current discussion is losing focus... maybe I suggest we come back once we are clear on SLO. 

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