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&amp;data=02
> *7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ecb5d308*7
> C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637238138022686963&am
> p;sdata=hF6Uo1VE2OQyRm1EsWlbtO3whH1phaee*2Bw2e8XK5zZ0*3D&amp;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&amp;
> d
> >>ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ec
> b5d30
> >>8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63723813802269695
> 9&amp;
> >>sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&amp;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&amp;
> d
> >>ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ec
> b5d30
> >>8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63723813802269695
> 9&amp;
> >>sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&amp;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&amp;
> d
> >>ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ec
> b5d30
> >>8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63723813802269695
> 9&amp;
> >>sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&amp;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&amp;
> d
> >>ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ec
> b5d30
> >>8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63723813802269695
> 9&amp;
> >>sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&amp;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&amp;d
> >
> ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ecb5
> d30
> >
> 8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637238138022696959&
> amp;
> >
> sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&amp;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