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

John E Drake <jdrake@juniper.net> Wed, 29 April 2020 13:57 UTC

Return-Path: <jdrake@juniper.net>
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 9513E3A1022 for <teas@ietfa.amsl.com>; Wed, 29 Apr 2020 06:57:58 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=k6q9UkUz; dkim=pass (1024-bit key) header.d=juniper.net header.b=WQW8CnVg
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 3eY2pNpwlMEu for <teas@ietfa.amsl.com>; Wed, 29 Apr 2020 06:57:56 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 DFB353A07F0 for <teas@ietf.org>; Wed, 29 Apr 2020 06:57:55 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03TDuxBJ032126; Wed, 29 Apr 2020 06:57:48 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=mcw+5Nia2OXhUX4ygyltyczU7IJ42poymQKaiOPZTgA=; b=k6q9UkUz3gdpWAeC++oGTV/n1FMHkTOHo66ZirhE6G37fJQkr324XpFZNmOISimm7ltK YWgTds/Pny2Wf8Q5EmOukNVet5VQpvtmD5/HevKqHkM8+2HQ1Wa/nhTK8iD/ZpJ6Ctup FY4XkKdlw2YMMH/8RTUr6LOarkgF4RC9u5RIUFsG31pxpNdD0W5ssxpYQd6VEn7aOh5D zsG+NYjVxmABRUFGJY3ANjuvrrCmXOLqEcnWiPXtbIvkuVLfA1zcwp8onoAY1U8W7yKp mHFXr19inIW/1nZ7bSk7v9Fb1qxtZDtZaUlMebcpbF0pF/2Afccuw1FivNzjBK9fQ+2c hQ==
Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2177.outbound.protection.outlook.com [104.47.55.177]) by mx0b-00273201.pphosted.com with ESMTP id 30mmaxyh49-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Apr 2020 06:57:48 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GjZuKf9HRpQogTAnKN2EOLHd1giM/ncPmb9t/UPXKwvCgpj/7c5/LbD8/phvABA5mctq3beHokahImkak0RNISpt+r4BpiaNnSwH547LqITjWUF7FsbaVNChiDJ4HIm/3TLiymweOy5I2Ni8EvGWQaqKShTVGI0iepZtt5V03lYykDMW1MthD8srokGo7NOsLxsPnxRldf3XEWmrU7Ul7o9KQDkjtNm3R71Sj9UIxzBYfQBHUHWVHfkrzB3YCMOliHSqIgEHmeOCnJ9mq0sXuI2DBIc/YxNKuV0EQ2o2mWx7JKvvz4d8uOOWmzQtE5JXTq7l2StIv567C3aQhpiUKA==
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=mcw+5Nia2OXhUX4ygyltyczU7IJ42poymQKaiOPZTgA=; b=RhGM6IBFDiELy742QG9RLq8NnkXk3RnZnIol4aV0w6IRJVxa4DuCvpqHy7b7uekIt3JLm8Q2nXLYxspH04HyN7nkwy5Ikq5aacpWQ1ZQcUVMH6HErBultNus+yglInEYj5B4vYcAkzdimHyswsTg6Mz99geYw0HXcJ0adeONh3x6efed+HYWRBivYY7UtackzieY6245nAEb3I35WBhruXjrqoP0witYXINU1UiofeWcLwzb+nzb4R2NjFiXE9cxGTzfOBD6+hCdPrW1PN7BjgYHmwEnijjLml+jSAtPYo2BwlXxuaEQHIX4HIQ5NAQCkvXCe0AIC3Xef1lC5uLWXQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mcw+5Nia2OXhUX4ygyltyczU7IJ42poymQKaiOPZTgA=; b=WQW8CnVgZbZRtRDfY1dlifrkyxkkSi6fi2FBomr0DnIepGO+M/2fvam0UDdRUstF/+apNYkGvyXFXm3O2Hy8hgQAuu9haLZ9PFrcwPuH+OYu0vURvk/onx+LTC2Wt0CcPC9Lub/qHVpXh9I4UIrOLkvRu1353BxgSXq93aNnYlE=
Received: from DM5PR05MB3388.namprd05.prod.outlook.com (2603:10b6:4:40::18) by DM5PR05MB3435.namprd05.prod.outlook.com (2603:10b6:4:44::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.12; Wed, 29 Apr 2020 13:57:46 +0000
Received: from DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::71ec:50b0:1f06:50e7]) by DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::71ec:50b0:1f06:50e7%4]) with mapi id 15.20.2958.020; Wed, 29 Apr 2020 13:57:46 +0000
From: John E Drake <jdrake@juniper.net>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Zhenghaomian <zhenghaomian@huawei.com>
CC: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Network Slicing design team definitions - isolation and resolution
Thread-Index: AdYd1eGV3VnoXr05SR2yuuNBtJK0vwAA6XGAABUWY9A=
Date: Wed, 29 Apr 2020 13:57:45 +0000
Message-ID: <DM5PR05MB33883A602AF13C76325FFFADC7AD0@DM5PR05MB3388.namprd05.prod.outlook.com>
References: <E0C26CAA2504C84093A49B2CAC3261A43F8369C3@dggeml531-mbs.china.huawei.com> <7faa674d-36cb-9b11-1db6-72839b252dac@joelhalpern.com>
In-Reply-To: <7faa674d-36cb-9b11-1db6-72839b252dac@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=jdrake@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-04-29T13:57:43.5210854Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=3735bade-9d81-40ef-97be-03438583a938; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.3.2.8
dlp-reaction: no-action
authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: b926d44d-62bf-4ffe-7ab4-08d7ec454b87
x-ms-traffictypediagnostic: DM5PR05MB3435:
x-microsoft-antispam-prvs: <DM5PR05MB343589FDD30D2FF207B50EA4C7AD0@DM5PR05MB3435.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03883BD916
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Io9fOmupnKFxG+tC9ow0yxdtcxNCj3cyMVzYCPGN/ZzWF1uBdCwODJBVz4gdfT+AkoZyGXMV5R6wPXNhc3hTddUIKaonZ4t0a+AIkRQMKu7RlTS/Od9utLg0UhWIUi2MjhtyGh/jq4c30cEuQr76GvvoI4obo/GpDQ6F2ypRnvORhQ7GViOa7DVI1S9vW6sNkaJfxfAZbZuSUjMhp1Drdn3fMF3glMOjuWCmx17nfDLy0XInvb64lolB8PuDUiox0/0Mc9Jz7A4Fts1rOkv7li7yFYkwDpwVKmNQptkvnF/ZJ8ruJ8h/v4AFjUCKc36pHAnVm9W2giDaMT01H6fIY2HfQbXOsX2mCxZ128MWfzz7s1Eeq2YMI2F0ikcGLNtJyyQNhJBY3x1bJO8zw4cHyZMRtWVLFgjfeHwJzP3JTaeTKXoAL6vpekIBDX4H0ltomkVlppp/ZfeSmOIIzGkoy7z+Vw17HGxB/SnqknqTlbVmIkV/vbqLhUIVyLRru2ORRj22E1MBZBEoAbxeCOCLVQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR05MB3388.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(39860400002)(396003)(136003)(366004)(53546011)(19627235002)(6506007)(66574012)(7696005)(9686003)(30864003)(52536014)(66946007)(4326008)(33656002)(66446008)(5660300002)(66476007)(76116006)(110136005)(86362001)(64756008)(66556008)(55016002)(71200400001)(966005)(8676002)(2906002)(8936002)(186003)(478600001)(26005)(316002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: b2jMnOc2IxuPmuX31XwIoEwIRIbac9Bj+zsg8thuuY5F0/W14aTg23dVZ/9tAtoN4mfahMSqmUQQzM6kNZcGtWVEiy2k0uctQaTqhvvdzcHEbI9YuQ1m+CzJ6AqFpKhEppYIih3hN02iVSaqVExgii9wzVGFG/yfgbcqritt5WjIi7sIuw/Kg6GHXOd7lxOgA458lO61RsLhWjIeNyNWUdV67ymvdfzowutrAr4Cdqt3ud0nLN68ciCzkntf5oNS0HwxBoEr5QUxrwCkxUKAynnqQAlMUR5ETmlbjPRr3eKOeNGP06jMwFNXZ7hWGAPh/CZUyaH+vXXfHPDP5MEUKd+5LooonOYvr730TBnx4PUzgMAtFZxUVsEPqosWdL1gQz4ZZ/oO2l5+QzFxDK1ubIXR14HnABxNKqeHsm0yDP7Ja+VE7uCwsJjVvPO8B4Ft1817F1FMmA+1IQF7d2PNPWb9GhQGGCP0gU1RFCIWLt4wjuMkQca6hi5RgP3Ni02KA8OJV5Rc/yhjDt8LNC2jjQveUcdjDXb0BkMj5/9/nVWQxVwNGSE8rQg62mrkFXT6dnYxTQlOTGixDSCSZknkGgAazn348jav59X6VbXTHaw3qijqlL6dAyuULlycp5cOw7R83vNKwJimCYFmP7RbqIjueu0Ypa01PuRXPbRnZaF1J8ogfC4lLQ8t91XPXttWOPwh4uaMIY7o1Fw0W5fX8efy2bSyA9S7q+Zn0UxjVRdeklu+9AdEQt6CFopLqVvVq0kwwkRyCI6WZacBKdaFHE73xMOWL5wPOoCy6mZ+z/o=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: b926d44d-62bf-4ffe-7ab4-08d7ec454b87
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2020 13:57:45.9673 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Z608IQheJdV0x/mbLYUZv7uKNiNlUqayMlRYg2/gHrjuIKtPhuONIxNOZo9Cg8KXL79bPRnM2YLyxJp80a/7ig==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3435
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-29_05:2020-04-29, 2020-04-29 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 impostorscore=0 clxscore=1011 mlxlogscore=999 spamscore=0 bulkscore=0 adultscore=0 phishscore=0 mlxscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004290116
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/6o7f1KqzdckhNqN2jMJcwy-QN_w>
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: Wed, 29 Apr 2020 13:57:59 -0000

This is exactly correct.  How an SP chooses to meet an SLO is their business.

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Teas <teas-bounces@ietf.org> On Behalf Of Joel M. Halpern
> Sent: Tuesday, April 28, 2020 11:52 PM
> To: Zhenghaomian <zhenghaomian@huawei.com>
> Cc: teas@ietf.org
> Subject: Re: [Teas] Network Slicing design team definitions - isolation and
> resolution
> 
> [External Email. Be cautious of content]
> 
> 
> On the topic of isolation, I would suggest that you
> 1) remove the current text related to isolation
> 2) figure out what it is that is observable and well-defined
> 3) figure out a name for that, and propose the name and definition
> 
> I presume that this addition will require discussion among the design team, since
> it would be a significant change to the document.  Or it could be proposed in a
> separate document for now.
> 
> Separately, I suggest a similar approach to the current resolution text, as it does
> not make sense as written.
> 
> Yours,
> Joel
> 
> On 4/28/2020 11:36 PM, Zhenghaomian wrote:
> > Hi, All,
> >
> > Agree on we have multiple kinds of isolations, and we may need to
> > differentiate them. It reminds me in some previous discussions we may
> > separate the isolation from the user side and from the network side.
> >
> > Isolation at the user side: just indicate the demand about a
> > comprehensive performance from the user. For example, when requesting
> > a transport slice, request some isolation if the user is sensitive to
> > latency (or something similar); or, don’t request any isolation if the
> > user is not sensitive to such parameters.
> >
> > Isolation at the network side: how to technically guarantee the
> > isolation (in VPN, etc.), which is already existing as cited in Jie’s
> > email.
> >
> > Basically I think we need the ‘isolation at the user side’, but this
> > isolation is different with what is indicated in ‘Isolation at the
> > network side’. We may need better definition on ‘isolation as a part
> > of SLO’, instead of simply removing it.
> >
> > Best wishes,
> >
> > Haomian
> >
> > *发件人:*Teas [mailto:teas-bounces@ietf.org] *代表 *Igor Bryskin
> > *发送时间:*2020年4月29日1:52
> > *收件人:*Dongjie (Jimmy) <jie.dong@huawei.com>om>; Greg Mirsky
> > <gregimirsky@gmail.com>
> > *抄送:*Joel M. Halpern <jmh@joelhalpern.com>om>; teas@ietf.org
> > *主题:*Re: [Teas] Network Slicing design team definitions - isolation
> > and resolution
> >
> > 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-m9b0CoNPmTInchmF-
> 5E564tOGGuu5Hro$
> >     > >
> >     > >     _______________________________________________
> >     > >     Teas mailing list
> >     > >     Teas@ietf.org <mailto:Teas@ietf.org> <mailto:Teas@ietf.org
> >     <mailto:Teas@ietf.org>>
> >     > >
> https://urldefense.com/v3/__https://www.ietf..org/mailman/listinfo/teas__;!!
> NEt6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-m9b0CoNPmTInchmF-
> 5E564tOGW8R9S1s$
> >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!
> NEt6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-m9b0CoNPmTInchmF-
> 5E564tOGGuu5Hro$ >
> >     > >
> >     > >
> >     > > _______________________________________________
> >     > > Teas mailing list
> >     > > Teas@ietf.org <mailto:Teas@ietf.org>
> >     > >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-m9b0CoNPmTInchmF-
> 5E564tOGGuu5Hro$
> >     > >
> >     >
> >     > _______________________________________________
> >     > Teas mailing list
> >     > Teas@ietf.org <mailto:Teas@ietf.org>
> >     >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-
> m9b0CoNPmTInchmF-5E564
> > tOGGuu5Hro$
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org <mailto:Teas@ietf.org>
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-
> m9b0CoNPmTInchmF-5E564
> > tOGGuu5Hro$
> >
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-m9b0CoNPmTInchmF-
> 5E564tOGGuu5Hro$