Re: [Teas] Network Slicing design team definitions - isolation and resolution
John E Drake <jdrake@juniper.net> Thu, 30 April 2020 14:11 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 8C4983A0848 for <teas@ietfa.amsl.com>; Thu, 30 Apr 2020 07:11:22 -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=IpmTswZN; dkim=pass (1024-bit key) header.d=juniper.net header.b=X/+Lk7N+
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 0d-ELDKSy3zM for <teas@ietfa.amsl.com>; Thu, 30 Apr 2020 07:11:19 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 75A9A3A0845 for <teas@ietf.org>; Thu, 30 Apr 2020 07:11:19 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03UE8O7L008053; Thu, 30 Apr 2020 07:11:16 -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=d5GL2ydU5n6ZwBP6RjYGV9ws8mWtbhI4ZKuoURGad9w=; b=IpmTswZN2C6Fj9/8zXCq6vaKKnp5dkkXnCf7bwSgLsk3Q88dVcHK6DwcYhNQiGx7bpDE v0xmoadOGp5alz0HwFgdtbKyw1Jl75fRLvU6Wpn2uySR8h5Wm1pqrnvBHPOUTzBfw+mx QMkeNVZk+WlWFE4jNsZQqwDqu3+8AyNJCf3NLL98mwYnWSFT2JTaMPlv42c7qkYZY3im 90Dj0Z79/SMH7+OVtcF4N2v8cPg48LL5mEebuIU6Q1Bq3ns+aHMzKj7RTl2xe5Ru6bkE Vyw27kUl/yjH0HCDDGFfUXnmwghB/WPEAT/Cnd+VVYLVNgGZvDqDRx9fOimkKm9waYPX oQ==
Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2170.outbound.protection.outlook.com [104.47.57.170]) by mx0a-00273201.pphosted.com with ESMTP id 30psm2v2m1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Apr 2020 07:11:14 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ciJ+vXakYyfXADRUciTZUduPKgHnWo1cnwysrE6YfrNiavQkvDUmsJJaegL0eSZzFnOLFYsDU+19/uD9bp/eevRX8yPKmqKTLVtp3O0hMyq8yeHwnhNADQ2t+2BRs0HJu8ZpuERExs8X9S1Lcz1hmCmx8WcJIZN4YBCD6X+bnD1Y6z9UkuSo7eIL6RAH5f8pXUzxPPHfimA6eJRTam5/n1lNa9+ATLM9csDR+FU3EAZfli/XXEeyXp5NINmdqVXZZxlLe8aU6r7qX9Ti48Ca/L5uZ+Lq53Ed0R1T5dcEtHnicheS79+4BnPQd0EJjsRQYSlV07jQSspWNS0dSyBywQ==
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=d5GL2ydU5n6ZwBP6RjYGV9ws8mWtbhI4ZKuoURGad9w=; b=K3EKCpRYIPU48eYfvtEWxEYltIiEotSWEp4RC+PWLvYx/FNFxsNMhCBctYrifmdB3YVBLkQQhUCKf2T4K7OcEAbqOg8f5pFbNKWP2iWbsrZbi0IfPveEawueLsrtwrhtdpxElIvOOLT4LR6uLYS1tN+vNNjwD8QGxmg/ve7/YRyCJ4FT6LPl1EyKzJMIsJI5g06JohAkNi0k1nmapbn9V5ZswGLXqnBdgzgFNwRZvoiUdh3J2gy5l2/x/hBlt5loPiw33TdRRFRNZzH4exNSYvLSuzJ9QB9/mCmezVBRvGQVVXBySm/YSju2Kj7wO1kOJT/VjyXxZEbAQgd2zWGQkQ==
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=d5GL2ydU5n6ZwBP6RjYGV9ws8mWtbhI4ZKuoURGad9w=; b=X/+Lk7N+/5QlfG3oPx4QXOeKFI4lLtI7P8ATq6rfkdneRuWPJic8GXk9NWdRteLHtw/dAt8PCVj3yhaRmFZ3s+cebDqLmOIB73RKD47ugSpVWiZoWUTaK9/VpeX1Cw2DdpTAu1zFgo1zq1IHyV52BRwOcbywxrA83h5iH34GDRk=
Received: from DM5PR05MB3388.namprd05.prod.outlook.com (2603:10b6:4:40::18) by DM5PR05MB3113.namprd05.prod.outlook.com (2603:10b6:3:c6::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.14; Thu, 30 Apr 2020 14:11:11 +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; Thu, 30 Apr 2020 14:11:11 +0000
From: John E Drake <jdrake@juniper.net>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Kiran Makhijani <kiranm@futurewei.com>
CC: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Network Slicing design team definitions - isolation and resolution
Thread-Index: AdYbdItwZqSV0WoJSFOt1j29Tf6CaAAARYmAABm6UIAAAbR0AAA9qRkAAABZaQAAGRTDgAAOoY6AAALbDYAARezqAAAATjuAAALy+j4AEuPwgAAASoiA
Date: Thu, 30 Apr 2020 14:11:10 +0000
Message-ID: <DM5PR05MB338815CB418F3509C511080EC7AA0@DM5PR05MB3388.namprd05.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> <b6b2cfe1-58ff-2969-1448-ee49f4565962@joelhalpern.com>
In-Reply-To: <b6b2cfe1-58ff-2969-1448-ee49f4565962@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-30T14:11:08.9685870Z; 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=64ebbb28-0736-4a44-8505-1c4f2b28ec40; 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.12]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 46911bed-7bef-42bb-de92-08d7ed1055cd
x-ms-traffictypediagnostic: DM5PR05MB3113:
x-microsoft-antispam-prvs: <DM5PR05MB31139CCCE498DB3749EFEA21C7AA0@DM5PR05MB3113.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0389EDA07F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 46ir880dtHOtm16YXZQW2vz4OoLhATaT4Qdc8lhvLa4TZuIqCBtt/6ms5FwTsUL0vJF00Ny9MJQ/TTA5h/V84MlObGtyj2KyoZEHFi+jJ06zw9UpKZFxNo8dH/sQq6XqMlRu5Bl5OljGcD9XeC17RQuyhF8xqWsFoD+OR7s7hS6yBS78EAMrBxACfiDc6lMglezg4PSaYe5GY5l3QE6yyRlcISko1Q5LQJETsTE5nAewf5PO0ou5p5vzHcH9VQddNnKDKuF8vqNpD7Hn2RCmF6HMkVrPhD2ZLztDyRABBYv49oW4Z7D8eD7Zx4q4hoUTaJx68ouGBf+27R96d8g+ZBueHyhf60rHynd/Zaur2m9cb8JauU2dwHpymLy9YW7+uWMvtyDocObQrl7pBvkfoLc/AgnO5rdqutIEFbYbAQdqYJGVa2X0Fp3itg1DRBHhYmn0Ko6pNlUso7YES+ZDux7svki/RXSeFDm/LJ6SaQw4g8Z180Of5vJ6ig30LwJkkokyJRLgtlEXNv62jEUW/w==
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)(366004)(346002)(136003)(39860400002)(376002)(396003)(64756008)(52536014)(8676002)(66556008)(66574012)(66446008)(71200400001)(66476007)(8936002)(76116006)(6506007)(53546011)(478600001)(66946007)(4326008)(45080400002)(2906002)(26005)(316002)(19627235002)(186003)(33656002)(9686003)(966005)(110136005)(30864003)(55016002)(86362001)(7696005)(5660300002)(559001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: kCsnvQdSf79ZiCHLlAes6DHREuZk80zaFBe6IFIYl1LYtfjZ9LsDDUAycjETwAjCcL14ryxzl4esfyN9Udk4YmaZNoHUZ0Wbz6L1myYTbsWrItuzlZEblORarKoAJR6xAYvQ974pBQHu6O27qQiayFyn6iUq9RZ9qZWzW/znzZCZ0Rlm9PteknJELEUMLuEFjJDdeDzIUsliX3hYNiJQfVHPEjYL9BEXOF2pycS76xd4bwAy78KXsA6aP66rBjfI3dU/HNJ6hqvRu1cXgpBXMMUN1gY3CHZP/Y3lEVclSCIlnMh/ht9u2Mgk4uVCauBXumHjxtP69q2hL+Zv4ZfiRFEFvae61pMtNRdt34qovI1zK5yn0zjA0jiQCtad1LJRTodqu+O33rw6OdOjvPhMgCNU3oPIuoDOlr5hKiuS8bI3ChUs/KTnvQRMEeGxLoWzhQjFBYSJqt2OBUJCIFBVBCxwmI74Ai2NfYHDMilX3Pu1RlWIzfIeiXSMeC4Gf7qk/vn+XnSxRDjm07WY1z+x0s62MCd3rfKcDpzcnmPgIDITuMUrEfKINZpkEb3Bvf5x7oOxGSj1dmkBDDWwi7w/aduWjMMZaIdFJP50DnNoAkWW3VFWBT8DsR2N95jsCXjU0U4cUbt+aR/W4dr32CLoW67Xx+Ip1jFQoLJH3p+RY9bi7B6VtNw8Vn3X+GDT6SpP2Fkc1qmljA4aITO9VlJwjgACchFsseaupdGXR4HQ94/x4kyT1ZEJ6biS5a6SY16Kphzqmri2cmhNISEz5sCDymx/3poWLugzVnxMFtKMWak=
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: 46911bed-7bef-42bb-de92-08d7ed1055cd
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2020 14:11:10.9390 (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: i7JOQeCFM7XU9Z0qEa8CvYCb7a1jRxECGTaduSXiXPACNPjY2n+YiyMZ28IQb3cLB1rkGNyzPfgm85IayIhPkQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3113
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-30_08:2020-04-30, 2020-04-30 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 clxscore=1015 adultscore=0 mlxlogscore=999 lowpriorityscore=0 phishscore=0 priorityscore=1501 impostorscore=0 spamscore=0 suspectscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004300113
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/nXHGNR9CrHr_66yLUWmXVq-Xq8k>
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 14:11:23 -0000
Hi, As someone pointed out, even 'hard isolation' does not use completely dedicated resources; i.e., it shares software, hardware, wavelengths, fibers, power, etc. I think that what people have in mind when they talk about 'hard isolation' is something like a TDM circuit. If this is the case, then it should be possible to describe it in terms of an SLO/SLA because there have been SLOs/SLAs for TDM circuits since the dawn of time. Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: Teas <teas-bounces@ietf.org> On Behalf Of Joel M. Halpern > Sent: Thursday, April 30, 2020 9:48 AM > To: Kiran Makhijani <kiranm@futurewei.com> > Cc: teas@ietf.org > Subject: Re: [Teas] Network Slicing design team definitions - isolation and > resolution > > [External Email. Be cautious of content] > > > I think we all agree that we need to support a range of services. > > We need to know the parameters of those services. If "complete separation" is > an observable rather than a philosophical concept, then define what it means in > terms of observables. Heck, we have claimed conceptually that VPNs already > provide "separation", but we do not make that a parameter of the VPN. > > Similarly, if "interference" is an observable, define it. Remembering that from > the perspective of the customer of the slice, the customer cares about effects > on his traffic, not on causes. > > This is described as a definitions document. Not a conceptual discussion > document. > > Yours, > Joel > > On 4/30/2020 12:47 AM, Kiran Makhijani wrote: > > 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://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/ > ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fteas&data=02 > *7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ecb5d308*7 > C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637238138022686963&am > p;sdata=hF6Uo1VE2OQyRm1EsWlbtO3whH1phaee*2Bw2e8XK5zZ0*3D&re > served=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq- > iOcrp4s1zN_XiiFeC3u8lY63P9B6s9o0GYqZsXjvd9O8a4$ > >> > > > >> > > _______________________________________________ > >> > > Teas mailing list > >> > > Teas@ietf.org <mailto:Teas@ietf.org> > >><mailto:Teas@ietf.org > >> <mailto:Teas@ietf.org>> > >> > > > >>https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook > >>.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fteas& > d > >>ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ec > b5d30 > >>8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63723813802269695 > 9& > >>sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&reserv > ed=0_ > >>_;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq-iOcrp4s1zN_XiiF > >>eC3u8lY63P9B6s9o0GYqZsXjgUN8ytU$ > >> > > > >> > > > >> > > _______________________________________________ > >> > > Teas mailing list > >> > > Teas@ietf.org <mailto:Teas@ietf.org> > >> > > > >>https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook > >>.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fteas& > d > >>ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ec > b5d30 > >>8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63723813802269695 > 9& > >>sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&reserv > ed=0_ > >>_;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq-iOcrp4s1zN_XiiF > >>eC3u8lY63P9B6s9o0GYqZsXjgUN8ytU$ > >> > > > >> > > >> > _______________________________________________ > >> > Teas mailing list > >> > Teas@ietf.org <mailto:Teas@ietf.org> > >> > > >>https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook > >>.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fteas& > d > >>ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ec > b5d30 > >>8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63723813802269695 > 9& > >>sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&reserv > ed=0_ > >>_;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq-iOcrp4s1zN_XiiF > >>eC3u8lY63P9B6s9o0GYqZsXjgUN8ytU$ > >> > >> _______________________________________________ > >> Teas mailing list > >> Teas@ietf.org <mailto:Teas@ietf.org> > >> > >>https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook > >>.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fteas& > d > >>ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ec > b5d30 > >>8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63723813802269695 > 9& > >>sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&reserv > ed=0_ > >>_;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq-iOcrp4s1zN_XiiF > >>eC3u8lY63P9B6s9o0GYqZsXjgUN8ytU$ > >> > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook > > > .com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fteas&d > > > ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ecb5 > d30 > > > 8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637238138022696959& > amp; > > > sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&reserved > =0_ > > _;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq-iOcrp4s1zN_XiiF > > eC3u8lY63P9B6s9o0GYqZsXjgUN8ytU$ > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas > > __;!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq- > iOcrp4s1zN_XiiFeC3u8lY63P9B6s9o0GYqZ > > sXjcmeGkV4$ > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N > Et6yMaO-gk!SA_HL9cyyH-DrEoq- > iOcrp4s1zN_XiiFeC3u8lY63P9B6s9o0GYqZsXjcmeGkV4$ Juniper Business Use Only
- [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