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

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Thu, 30 April 2020 08:43 UTC

Return-Path: <daniele.ceccarelli@ericsson.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 78E833A0BB8 for <teas@ietfa.amsl.com>; Thu, 30 Apr 2020 01:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.82
X-Spam-Level:
X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.82, 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=ericsson.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 E1ZLIH0yx8J7 for <teas@ietfa.amsl.com>; Thu, 30 Apr 2020 01:43:15 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2063.outbound.protection.outlook.com [40.107.20.63]) (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 0FEA23A0BBE for <teas@ietf.org>; Thu, 30 Apr 2020 01:43:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DklzEOdB3SBU9swTD9jPdbsz5kv66mfQy/ZBiR9HB+06spgTV0Dt8Popln2umIyCBMSu3SfQFPIWbzLMVhg50lmO88GNyLcvbgkaUirJeGsPRWsE7SE22gY0D7VVzF7fPOHd3j5oaBd59D4U75ZOWlcxWwauRwVbFDb2INQ1vaO6Y6bk6JoJQoPvN+4nfN6xVbXuO5cKLSgSbmvQfDZb7he9amgzgZTG3G/kAqbw9j+NClfOcWKoBQ2kGw8QCoWyj8l3S7y38s7qU234afnC+SI1SclBvx+Liw3Zyq9ZF7ARNMSsrPlPh7kTlNvRbjt0z15dRAsK7R+Fk6LqH3yegg==
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=PmLymy/4e+FFFQCCEobZnG2TBpgKS6NtbkcKiZsTY8M=; b=kjLgnzDOAnvV4Co2oHrAwfS8KAU+y0er0EIvYgo9JQwI0MeL5ybKfWid+pBQibjWIac69pvwVlNHLCAedHW04cv6A+lTbFYzmGx8lVLC6P2x+F2WTMgeJcStFzlweyMCRTAy0jCRKvjKqikOgQQ541G9i4ptWitUx55LZrGf7aP4KBWAFREMpeFznfoGPiUeargDU+AoP9dYeSBzP4h+TjaWZoUZcJit9zGSC7tNqrqleG5qEqyfbun8fvJmix1pUrd+YkV1Zf0PbJJVn7TDi42bkja+TB7onjljuQLk8HNwdXy0hkHU15XVnWZ2eK8IXUSHKN3YIdnm8yatjNuALQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PmLymy/4e+FFFQCCEobZnG2TBpgKS6NtbkcKiZsTY8M=; b=SsDMi+8HMcD/7wpd/55NaBaqwsmh++BxM9ShMRM15t1VJyz2XQcDCouZ2578Yq6/1NrSDsm9KP2X5GlErMEIJzA10GvCRHZPNSRhVgcLoJzs1iBh6IVEZbKscy/uXG5MKVqFv5ZKmBrOhWUvA7DOcZbGhWthTuSzzyKnxFGcB4c=
Received: from AM6PR0702MB3606.eurprd07.prod.outlook.com (2603:10a6:209:10::20) by AM6PR0702MB3735.eurprd07.prod.outlook.com (2603:10a6:209:7::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.12; Thu, 30 Apr 2020 08:43:12 +0000
Received: from AM6PR0702MB3606.eurprd07.prod.outlook.com ([fe80::8882:b749:b7d1:30e9]) by AM6PR0702MB3606.eurprd07.prod.outlook.com ([fe80::8882:b749:b7d1:30e9%5]) with mapi id 15.20.2958.020; Thu, 30 Apr 2020 08:43:12 +0000
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Kiran Makhijani <kiranm@futurewei.com>, "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+j4ACCUPQA==
Date: Thu, 30 Apr 2020 08:43:11 +0000
Message-ID: <AM6PR0702MB3606CED3F6E414FFAF452AD3F0AA0@AM6PR0702MB3606.eurprd07.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> <BYAPR13MB24378B008A7E7B553D45E21BD9AA0@BYAPR13MB2437.namprd13.prod.outlook.com>
In-Reply-To: <BYAPR13MB24378B008A7E7B553D45E21BD9AA0@BYAPR13MB2437.namprd13.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: futurewei.com; dkim=none (message not signed) header.d=none; futurewei.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [93.38.67.165]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 24693fb9-3b34-4260-6670-08d7ece2843f
x-ms-traffictypediagnostic: AM6PR0702MB3735:
x-microsoft-antispam-prvs: <AM6PR0702MB3735E7837C03FAE2D1DD2B3FF0AA0@AM6PR0702MB3735.eurprd07.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:AM6PR0702MB3606.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(39860400002)(366004)(136003)(376002)(5660300002)(2906002)(110136005)(7696005)(53546011)(6506007)(478600001)(966005)(45080400002)(8936002)(30864003)(26005)(8676002)(71200400001)(64756008)(4326008)(186003)(66476007)(66556008)(66946007)(66446008)(33656002)(76116006)(66574012)(86362001)(9686003)(52536014)(55016002)(316002)(44832011)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0HSe7BnFprBKhiQxid7bQ6KtTf08VbFpm8N4L0ujrD8ylVcoZ28Nq6gkKRRLuPSO99uTC8n0IrlSaFwWMWg7Z9cAFm+dZy+s9xBZdmDAmxlkzmyDHuppEVyLY7STB3weCDg0FW2zsHa7T0zb9as43Up9tlrD9lgzKJxq4atyUwMxd6cPjXPgteXD423zXyRi2+AQOhXMG4a6lUl9n/ma/XhJNL58TOfxe7vnEiWNIfOlaMRcIE1gWV7ddCpSbckvwb2N3SV5+vzkMlVawoIDeaHk/4se1qxBj0GwylR1HG12hQQC4Lq7DVMoesfkKmujGukZKcrvg1uVxBD6pqTQlLTuviaOPABfUp9eiVH1CaS6+hrIfqI4goZ/pfDYmoBcuXDbuQss4PrWtmCBm66hPJqa/bNU5Xawn7A9GMNAKzNRQbWUgXo/ZnFo24m8LkbMRSlE+rF40bWx3dP/mD5SJn0E1AXAckvL6JQNI8Xu5Yyb+s9i6nOVLrogDQZN3OZovJiQL4kHXyYpiUryhbM14w==
x-ms-exchange-antispam-messagedata: Ra8KqFCY1VWp8RCjBkvWPZU6/zQKd6spDkhIhMz5J7/ry8eNKzGg3ILcxnYB18MHkfKFWZBSjDK/1wYe3HeQXP7sra83KJbjpHxSFayA3vu+EdH/qa17/h80lBbKIFjuPA09jYNpNWublk6nOyLjjaEOOWgayRlyJ26Ptw9fvKGRMekqYz+QPct8pFkuo5Axkpj/GOGkQbvhGYFK6FTgFA2y4g6Y/202LSVTEuoX80o4izW19Pz2enQNBATwfpB+9pfhoCb1B0K3MyDAhWPXYP1yYS+N4OIej4NYjyKF79I+pb1NUzANJHezWjbUyiteW7sK6zm891TyA1SFnG+agrpAS2zpoDvoARBGQklFTRMOGh0zccS8LJ9euxiWumC0SrsUEM94cW4BeNkOP7FIJmXm2POIZC0hG3LcmhFMxe6vpk0uYLCxsvN++oTDNjVbXSHU7eB5T/NNJTULJzFe8Ib3ftEcWLNXYWE/i0HP+Ac4IJcAXcRQcjMgf1uHMVNvKZKSDjs0ZR8cPvbyXfb24wh++MUEmw+dphiSyhHqim3WbfFIFiZJfYv2ICK8r4wXv9muniKpc0H8GkfiBinQDhWbwxCWb+56P4hLFpjNHJTB4ucSfmlmV+qjAQPuPaIACbq8qNbba0fBARfn2l6Y+cjADKsvvehruYFCmjrOA8FrZbGKX9p3qXxzYw1kFCbCniUFVA8ETadaoQYQOvktrIqtdvGecQIwLb0tdUYMPlSPxfiziWgJStcKhcdq7GKeApck6iaFeGm6Wlc7bhlTq6FzWlEftHlWPAc1uUPucz8=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM6PR0702MB3606CED3F6E414FFAF452AD3F0AA0AM6PR0702MB3606_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 24693fb9-3b34-4260-6670-08d7ece2843f
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2020 08:43:11.8707 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: RL93e4Gh9UShjcv4aInKqvY9ksxF+G3yOhOcGtNwcFGxDpGKc3n7gCeneSABbH3hiUm3Aj2aHVGcySvZ8TuRdtbiNZ0RaLMHZ3rcFHyPTiI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0702MB3735
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/NO6l-1_8EtHQo1jXYiqOwRyRgow>
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 08:43:20 -0000

Hi Kiran,

I agree with Joel on the fact that we don’t need this distinction.
I don’t think the customer of the slice needs a complete separation, what is needed is a given performance.
If for some reasons there is the need to something totally dedicated with no interference, where there are the good old leased lines, right?

Cheers,
Daniele

From: Teas <teas-bounces@ietf.org> On Behalf Of Kiran Makhijani
Sent: den 30 april 2020 06:47
To: Joel M. Halpern <jmh@joelhalpern.com>om>; Greg Mirsky <gregimirsky@gmail.com>
Cc: teas@ietf.org
Subject: Re: [Teas] Network Slicing design team definitions - isolation and resolution

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<mailto:teas-bounces@ietf.org>> on behalf of Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>
Sent: Wednesday, April 29, 2020 8:22:37 PM
To: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Cc: teas@ietf.org<mailto:teas@ietf.org> <teas@ietf.org<mailto: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%20%0b>> <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%0b>>     <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%0b>>         <mailto:gregimirsky@gmail.com>>
>          > Cc: teas@ietf.org<mailto: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%0b>>         <mailto:jmh.direct@joelhalpern.com>
>         <mailto:jmh.direct@joelhalpern.com
<mailto:jmh.direct@joelhalpern.com%0b>>         <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%0b>>         <mailto:zhenghaomian@huawei.com>
>          > >     <mailto:zhenghaomian@huawei.com
<mailto:zhenghaomian@huawei.com%0b>>         <mailto:zhenghaomian@huawei.com>>>; teas@ietf.org<mailto: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%0b>>         <mailto:zhenghaomian@huawei.com>
>          > >     <mailto:zhenghaomian@huawei.com
<mailto:zhenghaomian@huawei.com%0b>>         <mailto:zhenghaomian@huawei.com>>>; teas@ietf.org<mailto: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 <mailto:Teas@ietf.org>>
>          > >      >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022686963&amp;sdata=hF6Uo1VE2OQyRm1EsWlbtO3whH1phaee%2Bw2e8XK5zZ0%3D&amp;reserved=0<https://protect2.fireeye.com/v1/url?k=863b9a86-dab23545-863bda1d-0cc47ad93d36-b3362418dc02d3f6&q=1&e=de9c3dd0-284d-4520-b57a-42c1d74c97c8&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas%26amp%3Bdata%3D02%257C01%257Ckiranm%2540futurewei.com%257C248a23140e1a44a2aff008d7ecb5d308%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637238138022686963%26amp%3Bsdata%3DhF6Uo1VE2OQyRm1EsWlbtO3whH1phaee%252Bw2e8XK5zZ0%253D%26amp%3Breserved%3D0>
>          > >
>          > >     _______________________________________________
>          > >     Teas mailing list
>          > > Teas@ietf.org<mailto:Teas@ietf.org> <mailto:Teas@ietf.org> <mailto:Teas@ietf.org
<mailto:Teas@ietf.org%0b>>         <mailto:Teas@ietf.org>>
>          > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0<https://protect2.fireeye.com/v1/url?k=5a325ab1-06bbf572-5a321a2a-0cc47ad93d36-947af5a2ee92c483&q=1&e=de9c3dd0-284d-4520-b57a-42c1d74c97c8&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas%26amp%3Bdata%3D02%257C01%257Ckiranm%2540futurewei.com%257C248a23140e1a44a2aff008d7ecb5d308%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637238138022696959%26amp%3Bsdata%3Ddyr8KnHm1N1A193%252FHsl0S9I3LczD5cvx60HfJVnNcDc%253D%26amp%3Breserved%3D0>
>          > >
>          > >
>          > > _______________________________________________
>          > > Teas mailing list
>          > > 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&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0<https://protect2.fireeye.com/v1/url?k=2a48ccd9-76c1631a-2a488c42-0cc47ad93d36-b6d9c9f1274be9cf&q=1&e=de9c3dd0-284d-4520-b57a-42c1d74c97c8&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas%26amp%3Bdata%3D02%257C01%257Ckiranm%2540futurewei.com%257C248a23140e1a44a2aff008d7ecb5d308%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637238138022696959%26amp%3Bsdata%3Ddyr8KnHm1N1A193%252FHsl0S9I3LczD5cvx60HfJVnNcDc%253D%26amp%3Breserved%3D0>
>          > >
>          >
>          > _______________________________________________
>          > Teas mailing list
>          > 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&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0<https://protect2.fireeye.com/v1/url?k=39a40fbd-652da07e-39a44f26-0cc47ad93d36-03a7d986e4f736a1&q=1&e=de9c3dd0-284d-4520-b57a-42c1d74c97c8&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas%26amp%3Bdata%3D02%257C01%257Ckiranm%2540futurewei.com%257C248a23140e1a44a2aff008d7ecb5d308%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637238138022696959%26amp%3Bsdata%3Ddyr8KnHm1N1A193%252FHsl0S9I3LczD5cvx60HfJVnNcDc%253D%26amp%3Breserved%3D0>
>
>     _______________________________________________
>     Teas mailing list
>     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&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0<https://protect2.fireeye.com/v1/url?k=7b928849-271b278a-7b92c8d2-0cc47ad93d36-695f10ee0b5d178a&q=1&e=de9c3dd0-284d-4520-b57a-42c1d74c97c8&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas%26amp%3Bdata%3D02%257C01%257Ckiranm%2540futurewei.com%257C248a23140e1a44a2aff008d7ecb5d308%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637238138022696959%26amp%3Bsdata%3Ddyr8KnHm1N1A193%252FHsl0S9I3LczD5cvx60HfJVnNcDc%253D%26amp%3Breserved%3D0>
>

_______________________________________________
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&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0<https://protect2.fireeye.com/v1/url?k=2b5032e0-77d99d23-2b50727b-0cc47ad93d36-4a8555bbe875224c&q=1&e=de9c3dd0-284d-4520-b57a-42c1d74c97c8&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas%26amp%3Bdata%3D02%257C01%257Ckiranm%2540futurewei.com%257C248a23140e1a44a2aff008d7ecb5d308%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637238138022696959%26amp%3Bsdata%3Ddyr8KnHm1N1A193%252FHsl0S9I3LczD5cvx60HfJVnNcDc%253D%26amp%3Breserved%3D0>