Re: [Teas] Network Slicing design team definitions - isolation and resolution
Kiran Makhijani <kiranm@futurewei.com> Thu, 30 April 2020 04:47 UTC
Return-Path: <kiranm@futurewei.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 C57AA3A11E6 for <teas@ietfa.amsl.com>; Wed, 29 Apr 2020 21:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.908
X-Spam-Level:
X-Spam-Status: No, score=-2.908 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 bPbgEU0ohI2h for <teas@ietfa.amsl.com>; Wed, 29 Apr 2020 21:47:10 -0700 (PDT)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2130.outbound.protection.outlook.com [40.107.223.130]) (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 479013A11EB for <teas@ietf.org>; Wed, 29 Apr 2020 21:47:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P9iIEQ2lukWnnnnyN4VaP8CR+4lRCpVC7+ClGomi7d7D/oBZHYZ7uY+FdkU8iTRU/VxQ2EdkUW7l6DioWQpMIVA/8Jis0rnCnrMAAoU/1HICJ3v6oERARVxH6x3CFLgDveyHlCP59ZO3p10l1MUvJmpGU9Wi29STv0k3KjWvcYO8fg9pB3NDWIJLw/POaGV6mVr14Ov+uG10ul7urOxvRLl3het7GxCuKNvuWvkY8hLqhTZsN/Zw0vEakgPbvfzfdRCMoe1tW9YYzRNDlho1F/QXJFemhWSfzU7P12EBfJgwcX3QSrutZvN8J85nhqIgr3SCi8UoILdP8Sxg/NA7EA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rXhgymg5Spm7jhoht8WJHE2fbD1BAVqDSCPKY+WJNlM=; b=QOb7Gohg3PJXfXYSCRMwg8MQKZVn8xQ7wmKZ16chadUyiObCeDme1xUouW6K2PspwglLUJ0kMvMl6cSoAQSX5xHyHGku/56R9mOehJ+4J229INdeBQvNUTXAKkiSrE0MA82cd1ih4tFwvoWv0ob9x2d73BAAIARPENUKWwtGnUb97ZzkiISe2WKeDlrOHo3aB3doQl07ryLUKascHjrZcqMy1Zu4kHEgffRr/F3dMzNPQy0yrg/9U4T/6wTnS+Hah1RJi6pxMeZ0ngCBEmoaR3zrf4xBGcObNgXZfGZIJpM4EC4wJTNF6i0rW+aYHLZ2iqwdOQM6RK36hv/RE3o/mQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rXhgymg5Spm7jhoht8WJHE2fbD1BAVqDSCPKY+WJNlM=; b=UOFTvLtz8kizu5m/QzRgtgQKvnpogbXSlQGFJKZ8PR3O+WcCk4IQ+uqmqgwwSmchGRvctgiEinGqqLe806tj4czGW5AQ8Br6caHAoSkNOrTNqaEqMMYxMNYMwwLWG/fr2JQhiHNNCGWQJmsAAFF/G5NNoSP/SFZV5c1FeGGTdC0=
Received: from BYAPR13MB2437.namprd13.prod.outlook.com (2603:10b6:a02:cb::23) by BYAPR13MB2488.namprd13.prod.outlook.com (2603:10b6:a02:cc::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.11; Thu, 30 Apr 2020 04:47:04 +0000
Received: from BYAPR13MB2437.namprd13.prod.outlook.com ([fe80::8c6a:9bdd:5a1d:fd6e]) by BYAPR13MB2437.namprd13.prod.outlook.com ([fe80::8c6a:9bdd:5a1d:fd6e%4]) with mapi id 15.20.2979.013; Thu, 30 Apr 2020 04:47:04 +0000
From: Kiran Makhijani <kiranm@futurewei.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Greg Mirsky <gregimirsky@gmail.com>
CC: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Network Slicing design team definitions - isolation and resolution
Thread-Index: AdYbdItwZqSV0WoJSFOt1j29Tf6CaAAARYmAABm6UIAAAbR0AAA9qRkAAABZaQAAGRTDgAAOoY6AAALbDYAARezqAAAATjuAAALy+j4=
Date: Thu, 30 Apr 2020 04:47:04 +0000
Message-ID: <BYAPR13MB24378B008A7E7B553D45E21BD9AA0@BYAPR13MB2437.namprd13.prod.outlook.com>
References: <E0C26CAA2504C84093A49B2CAC3261A43F83079E@dggeml531-mbs.china.huawei.com> <c467e349-efd8-1519-7d8a-1f242042cfed@joelhalpern.com> <a94fe17dae2244b0af6a9303e68f1e0e@huawei.com> <b54e1be6-cfd2-0bf7-1601-f6764253dfa3@joelhalpern.com> <CA+RyBmWaBN=WP3A4qwCOvm5Vax2ookYYas1-L5yQFiGmRH2OBA@mail.gmail.com> <aac854e6-92e5-59ea-3dac-e95fbf424a98@joelhalpern.com> <fc242b850689461da7861d81e3ab1a13@huawei.com> <CA+RyBmXrqjXNtFiYyoUT5ACtJ8fOJF7z78xnjC1MosNxXTZYzw@mail.gmail.com> <1212271585.1682731.1588096301849@mail.yahoo.com> <CA+RyBmU=cvnthYwP8JFOw1yLScb5c+M986dGjib=Y9ie9LQiJQ@mail.gmail.com>, <c5e31d85-76bf-1d7b-58b8-cf997a407e5e@joelhalpern.com>
In-Reply-To: <c5e31d85-76bf-1d7b-58b8-cf997a407e5e@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [73.63.186.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 193ae52b-d0ee-470b-217e-08d7ecc187d7
x-ms-traffictypediagnostic: BYAPR13MB2488:
x-microsoft-antispam-prvs: <BYAPR13MB248818882C9FCA2317F7756BD9AA0@BYAPR13MB2488.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0389EDA07F
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR13MB2437.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(346002)(39850400004)(376002)(366004)(8676002)(186003)(71200400001)(8936002)(18265965003)(86362001)(52536014)(26005)(5660300002)(478600001)(30864003)(2906002)(6506007)(33656002)(966005)(66574012)(7696005)(9686003)(110136005)(45080400002)(66946007)(76116006)(66556008)(66476007)(53546011)(55016002)(4326008)(316002)(66446008)(64756008)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: G96cfSuIUypXuDeJwK2HsI3cUGAaH5sulc3fC9ct17qPWl1XTo8LmSjkWYcoZauDweZCQBTrknekZ8Bc2Rcr32HcPggISR+8IFytRb5LjWAK7UjWTmn9StUWe9EFbJB7DZCO5V2W0NuND8osyG0LQZAn292JYWB5OuDIsNCX6agOB9YRUnMEVxVVxK2qU4v4ZFw98HTv4Q9u3k9iai+aSFXsXKundFlQd6nqlaaw0qIVORy/zYMD5mFnfzn9LGv/RYMkAKLfJ4XRB3xt0h2qtaSLwlzLtg3jY8mXzvoPq2WYZ3uvy2PfJzW+x6P8ACWz1lAkJ3QeAgdNesDrNsTCq+xVtcEi6m/usW7BqLBZxkUZ/fEpg0KqkEoHIKjZvRPoZvWRuM5fYD3iP+2rnpLJE8nMudktbsrvhaXBnEBGdHAcqla7n4yMvqpX83MQqsFLw9acvFm1u8ZQ+GE4Zcz4fI1pkVo595S1ZW10C7150VsnaXHr3rXxFZNwVFh9TxZq986WrYwWMptc15n11eWv9GrSF0PwPkaEZ2Wnmt3zpRoW/S5q6gdS5c8EGyRmF0I351KEhZMWmxTIx3e2/wB8fw==
x-ms-exchange-antispam-messagedata: ypc6sHxt1K8q6W21pUG41pwjK3TxtCZbbrr99Fd0DoBYIAdMf92ifprGaLco/1CwygqWKGmsEFI2byEzy0/53IN6sfye6sCKYSANIqljcjjX7TqvxnET8ZIXO6KDySAShwEVTKlkkiJVAcTU47FW5Ky4TMn2bcTEdC6/vdK4mJh5vzc/Cd2nxooJlet6+F4QAFm7c8LN4UEogLVAu/8/WDWszlt/zxbC65ElgUNnhgbHnfcNvB25z22edCQvKe3ae25Ox0n+n5TXsaqVAmo6AhvGRp5/ygYhZBL5sdL9S2KmqCwAzhs2MNdJ16AaWlohaA8d5dw9llEIGDXlgwvaT4ZhnjnB2PC8diQCauzB1HIo/OioQ3wr0ovXJ6mBC+mX5HmCHIrDbnr3AD+lkBT9doLY7iDViCMnzQjr7FcK0ix3CvqOZj0qmlCu6sRYGXQaJBI+kPPlE+OOf3XF6ndvwze2/MhMGsVGJ9IXEMApdlU2as9hiOZ0Aim4YyvSpsuK6lke9F162gh++P42ODVf4pZR4AMZ/zH/Cn9odB6wugvidXPRsS8BFzJk5BXLz1eLnUtaSizW0PvHK3Lt33SmP5LaaaOJZ2pQ2VpQcRgLSR5rlQNWcgQLIjNW/c1WaEMs/aruvP53mA04Zs6dS1kXiRoautH69BIh78hcD+QuiI/faKqajKv1jpRBA+1RwdYE7zJKkVoiLxPSXyhwKRCLJOL1TekAHSv7YKtTBNqgVHJgOyi44cTH0R5XZOpaIkzCdpPZD+rcW9TZb2SYCxkABXZIBQyEh+SGPn085vSAxng=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR13MB24378B008A7E7B553D45E21BD9AA0BYAPR13MB2437namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 193ae52b-d0ee-470b-217e-08d7ecc187d7
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2020 04:47:04.7221 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wsZx10fB3mqzzaRaQkASUPKugQEOagMCN5j66nEzJiUfi7Fb4TwWI+QY//A5j6RuzaY9LUvt+Jyrpjuo+a6KiA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2488
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/69tP7xdog5yp-xjJ3XW1EZYPNwM>
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: Thu, 30 Apr 2020 04:47:15 -0000
A lot of this should be seen in the context of why would we do slices? The way I see it - it is about supporting diverse set of services with their own set of SLOs. A few of those services really need complete separation and no interference, while others will have some wiggle room ( tolerance to some amount of interference). I am ok with what we call it - but both should be possible. Seems to me most of the discussion we have had are in the generic sense and not considering the slicing aspect. -Kiran Regards Kiran ________________________________ From: Teas <teas-bounces@ietf.org> on behalf of Joel M. Halpern <jmh@joelhalpern.com> Sent: Wednesday, April 29, 2020 8:22:37 PM To: Greg Mirsky <gregimirsky@gmail.com> Cc: teas@ietf.org <teas@ietf.org> Subject: Re: [Teas] Network Slicing design team definitions - isolation and resolution I have never seen a good or useful distinction between hard and soft isolation. The one described in the draft (based on causes of failure) is not effective. Everything has a confidence / reliability / variability. some are better than 5 9s. And some are one 9. Niether is hard. And neither is soft. Yours, Joel On 4/29/2020 11:13 PM, Greg Mirsky wrote: > Hi Igor, > I agree with you but with some clarification. If we, as in the draft, > introduce the notion of "hard isolation" and "soft isolation", then, in > my opinion, we acknowledge that in some cases isolation is not > guaranteed. Hence, everything that you've said is the case for hard > isolation. But for soft isolation, I think, a network might be affected > by another network. > What is your opinion on hard vs. soft isolation? > > Regards, > Greg > > On Tue, Apr 28, 2020 at 10:52 AM Igor Bryskin <i_bryskin@yahoo.com > <mailto:i_bryskin@yahoo.com>> wrote: > > Hi Greg, > > Flow isolation and network isolation are different things. For > example, you do not expect receiving data in one network broadcasted > over properly isolated another network. Likewise, you do not expect > congestion in one network caused by an activity in another > (isolated) network. Om the other hand, flows in the same network may > influence on each other. > > Igor > > > On Tuesday, April 28, 2020, 12:30:38 PM EDT, Greg Mirsky > <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> wrote: > > > Hi Jie, > thank you for listing the existing cases of isolation term use in > IETF RFCs. My understanding of these quotes is that most of them > refer to data flow isolation/separation. And that is what > Connectivity Verification OAM is intended to monitor. At the same > time, as Joel has pointed out, the term isolation is being used in > the draft-nsdt-teas-transport-slice-definition in a different > manner, particularly in Section 4.1.1. In that section, several > levels (hard and soft) of the isolation are discussed whereas > isolation of data flows, in my understanding, is always "hard". As > I've mentioned earlier, we might look for different terms when > referring to use/access to underlay resources vs. data flows > interaction. > > Regards, > Greg > > > On Tue, Apr 28, 2020 at 2:31 AM Dongjie (Jimmy) <jie.dong@huawei.com > <mailto:jie.dong@huawei.com>> wrote: > > Hi Joel and Greg, > > As I mentioned during the virtual meeting, isolation was > described as a requirement in several PPVPN requirement and > framework RFCs. In summary, isolation is firstly required to > avoid unwanted exposure of both data traffic and routing > information, then it is also mentioned that isolation is needed > to avoid the effects of traffic congestion happened in other > VPNs in the network. > > Just quote some of them: > > RFC 3809: Generic Requirements for Provider Provisioned Virtual > Private Networks (PPVPN) > > 4.4. Data isolation > > The PPVPN MUST support forwarding plane isolation. The > network MUST > never deliver user data across VPN boundaries unless the two > VPNs > participate in an intranet or extranet. > > Furthermore, if the provider network receives signaling or > routing > information from one VPN, it MUST NOT reveal that information to > another VPN unless the two VPNs participate in an intranet or > extranet. > > > RFC 4031: Service Requirements for Layer 3 Provider Provisioned > Virtual Private Networks (PPVPNs) > > 4.1. Isolated Exchange of Data and Routing Information > > A mechanism must be provided for isolating the distribution of > reachability information to only those sites associated with > a VPN. > ... > Note that isolation of forwarded data or exchange of > reachability > information to only those sites that are part of a VPN may > be viewed > as a form of security - for example, [Y.1311.1], [MPLSSEC]. > > 5.8. Isolation > > These features include traffic and routing information exchange > isolation, similar to that obtained in VPNs based on Layer 1 and > Layer 2 (e.g., private lines, FR, or ATM) [MPLSSEC]. > > 6.8. Isolation of Traffic and Routing > ... > From a high-level SP perspective, a PE-based L3VPN MUST > isolate the > exchange of traffic and routing information to only those > sites that > are authenticated and authorized members of a VPN. > > In a CE-based VPN, the tunnels that connect the sites > effectively > meet this isolation requirement if both traffic and routing > information flow over the tunnels. > > An L3VPN solution SHOULD provide a means to meet L3VPN QoS SLA > requirements that isolates VPN traffic from the effects of > traffic > offered by non-VPN customers. Also, L3VPN solutions SHOULD > provide a > means to isolate the effects that traffic congestion produced by > sites as part of one VPN can have on another VPN. > > > RFC 4110: A Framework for Layer 3 Provider-Provisioned Virtual > Private Networks (PPVPNs) > > 1.2 Overview of Virtual Private Networks > > In PE-based layer 3 VPNs, the PE devices may > route the VPN traffic based on the customer addresses found > in the IP > headers; this implies that the PE devices need to maintain a > level of > isolation between the packets from different customer networks.. > ... > Tunneling is also important for other reasons, such as providing > isolation between different customer networks, allowing a > wide range > of protocols to be carried over an SP network, etc. > Different QoS > and security characteristics may be associated with different > tunnels. > > 4. 3 VPN Tunneling > > Another capability optionally provided by tunneling is that of > isolation between different VPN traffic flows. The QoS and > security > requirements for these traffic flows may differ, and can be > met by > using different tunnels with the appropriate > characteristics. This > allows a provider to offer different service characteristics for > traffic in different VPNs, or to subsets of traffic flows > within a > single VPN. > > > Hope this helps. > > Best regards, > Jie > > > -----Original Message----- > > From: Teas [mailto:teas-bounces@ietf.org > <mailto:teas-bounces@ietf.org>] On Behalf Of Joel M. Halpern > > Sent: Tuesday, April 28, 2020 5:33 AM > > To: Greg Mirsky <gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com>> > > Cc: teas@ietf.org <mailto:teas@ietf.org> > > Subject: Re: [Teas] Network Slicing design team definitions - > isolation and > > resolution > > > > Greg, that definition seems to be a specific subset of VPN. > > As far as I can tell, the slice definition does include what > endpoints the slice > > participants can talk to. Presumably, with some way to say > "the Internet". > > So Whether the slice supports communication with the Internet > or not is > > definitely an observable property. I would tend not to call > it isolation. > > Separately, the definition you propose is unrelated to the > definition in the > > document, Which is why I suggest, for now, removing all > discussion of > > isolation from the document. > > > > Yours, > > Joel > > > > On 4/27/2020 5:22 PM, Greg Mirsky wrote: > > > Dear Joel, > > > thank you for bringing the matter of "isolation" to the > discussion. I > > > agree, that it is not practical to expect physical > isolation in modern > > > networks. In my view, a transport slice that requires > isolation is as > > > a transport connection that expects to receive data only > from the > > > specific domain and not from any other domain. In other > words, I view > > > isolation as the absence of mis-connectivity (in transport > network > > > interpretation which differentiates between path continuity > check and > > > connectivity verification). If my interpretation is > acceptable, then > > > isolation can be monitored using connectivity verification OAM > > mechanism(s). > > > I much appreciate your thoughts, opinion on the proposed > > > interpretation of isolation on transport slice. > > > > > > Regards, > > > Greg > > > > > > On Sun, Apr 26, 2020 at 8:57 AM Joel Halpern Direct > > > <jmh.direct@joelhalpern.com > <mailto:jmh.direct@joelhalpern.com> > <mailto:jmh.direct@joelhalpern.com > <mailto:jmh.direct@joelhalpern.com>>> > > wrote: > > > > > > Trimmed, in line. > > > Joel > > > > > > On 4/26/2020 11:08 AM, Dongjie (Jimmy) wrote: > > > > Hi Joel, > > > > > > > > Please see some replies inline: > > > > > > > >> -----Original Message----- > > > >> From: Teas [mailto:teas-bounces@ietf.org > <mailto:teas-bounces@ietf.org> > > > <mailto:teas-bounces@ietf.org > <mailto:teas-bounces@ietf..org>>] On Behalf Of Joel M. Halpern > > > >> Sent: Sunday, April 26, 2020 10:52 AM > > > >> To: Zhenghaomian <zhenghaomian@huawei.com > <mailto:zhenghaomian@huawei.com> > > > <mailto:zhenghaomian@huawei.com > <mailto:zhenghaomian@huawei.com>>>; teas@ietf.org > <mailto:teas@ietf.org> > > <mailto:teas@ietf.org <mailto:teas@ietf.org>> > > > >> Subject: Re: [Teas] Network Slicing design team > definitions - > > > isolation and > > > >> resolution > > > >> > > > .... > > > >> 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. > > > > > > As far as I can tell, the observable that you describe > is latency > > > variation (or maybe loss). Fine, describe the SLO in > terms of latency > > > variation (or loss). Given that there are always > imperfections in > > the > > > system, the customer may think that the issue is > isolation. But > > > what he > > > can observe, and as far as I can tell what he cares > about, is delay > > > variation, loss, or other factors that affect his traffic. > > > > > > To use a different example, I have learned from the > advocates to hate > > > bufferbloat. But even their tests measure delay, delay > variation, > > > etc.. > > > They then infer the presence of large buffers. But in > fact, if the > > > large buffers are present but never used, we would all > be happy. So > > > the > > > SLO on this would be in terms of latency, latency > variation, loss, etc. > > > Not bufferbloat.` > > > > > > Yours, > > > Joel > > > > > > > > > > > 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 <mailto:jmh@joelhalpern.com> > > > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>] > > > >>> 发送时间: 2020年4月26日 10:34 > > > >>> 收件人: Zhenghaomian <zhenghaomian@huawei.com > <mailto:zhenghaomian@huawei.com> > > > <mailto:zhenghaomian@huawei.com > <mailto:zhenghaomian@huawei.com>>>; teas@ietf.org > <mailto:teas@ietf.org> > > <mailto:teas@ietf.org <mailto: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 <mailto:Teas@ietf.org> > <mailto:Teas@ietf.org <mailto:Teas@ietf.org>> > > > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022686963&sdata=hF6Uo1VE2OQyRm1EsWlbtO3whH1phaee%2Bw2e8XK5zZ0%3D&reserved=0 > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org <mailto:Teas@ietf.org> <mailto:Teas@ietf.org > <mailto:Teas@ietf.org>> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&reserved=0 > > > > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org <mailto:Teas@ietf.org> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&reserved=0 > > > > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org <mailto:Teas@ietf.org> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&reserved=0 > > _______________________________________________ > Teas mailing list > Teas@ietf.org <mailto:Teas@ietf.org> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&reserved=0 > _______________________________________________ Teas mailing list Teas@ietf.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&reserved=0
- [Teas] Network Slicing design team definitions - … Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… Kiran Makhijani
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… Zhenghaomian
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… Zhenghaomian
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- [Teas] 答复: Network Slicing design team definition… Zhenghaomian
- Re: [Teas] Network Slicing design team definition… Luis M. Contreras
- Re: [Teas] Network Slicing design team definition… Luis M. Contreras
- Re: [Teas] Network Slicing design team definition… Dongjie (Jimmy)
- Re: [Teas] Network Slicing design team definition… Joel Halpern Direct
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas] Network Slicing design team definition… Kiran Makhijani
- Re: [Teas] Network Slicing design team definition… Greg Mirsky
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… Dongjie (Jimmy)
- Re: [Teas] Network Slicing design team definition… Joel Halpern Direct
- Re: [Teas] Network Slicing design team definition… Dongjie (Jimmy)
- Re: [Teas] Network Slicing design team definition… Greg Mirsky
- Re: [Teas] Network Slicing design team definition… Greg Mirsky
- Re: [Teas] Network Slicing design team definition… Igor Bryskin
- Re: [Teas] Network Slicing design team definition… Zhenghaomian
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… John E Drake
- Re: [Teas] Network Slicing design team definition… Dongjie (Jimmy)
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… Dongjie (Jimmy)
- Re: [Teas] Network Slicing design team definition… David Sinicrope
- Re: [Teas] Network Slicing design team definition… Greg Mirsky
- Re: [Teas] Network Slicing design team definition… Zhenghaomian
- Re: [Teas] Network Slicing design team definition… Greg Mirsky
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… Kiran Makhijani
- Re: [Teas] Network Slicing design team definition… Daniele Ceccarelli
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… John E Drake
- Re: [Teas] Network Slicing design team definition… Igor Bryskin
- Re: [Teas] Network Slicing design team definition… Jari Arkko
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern