Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

John E Drake <jdrake@juniper.net> Mon, 31 August 2020 13:40 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 765FA3A138C for <teas@ietfa.amsl.com>; Mon, 31 Aug 2020 06:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=tbXfIiRU; dkim=pass (1024-bit key) header.d=juniper.net header.b=dZHY2x9v
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 7Q90AjDOPZSb for <teas@ietfa.amsl.com>; Mon, 31 Aug 2020 06:40:01 -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 EC6B13A12EF for <teas@ietf.org>; Mon, 31 Aug 2020 06:40:00 -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 07VDcL2a015214; Mon, 31 Aug 2020 06:39:52 -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=fJPmChfE5TkgDaMkTH5EaHG52xxJIhYo3WOejro4U2M=; b=tbXfIiRU/lEPKpB8jMny3Ncbcsm9sdNB3nxxim+O6kSvkgJFoNgFEkcHbrCwgB3P7bvV KiPa6OH7gEwDjZ1UnYMiywl8nMDtgp8INkerQihBRedRxvvOU85R2LGder12hwCmrrfA MT/d7XFm8yh5/wpyJUnUq8qtiWRmkbW3vBRzMFNaTsSX5cuXQyfD6zUibSWowe0uRwja SNbXnxbyRbQQgp2Z35xQar+pc25cDtvPEkJt288HRgyJ3aW9TTW6OONS4BIRqXIZm48E mcC7aU5MrdqIM/UsOgPHWhWjznQs/b7FI9cshpytBi7F4Skf9i8RZZ2/HJkl6DA9qHOe iw==
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2104.outbound.protection.outlook.com [104.47.70.104]) by mx0b-00273201.pphosted.com with ESMTP id 3387rnsfhj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Aug 2020 06:39:51 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J/L2ftgYYt8HCJO6dJqEkyMttJc4s6il14PjTdSqRD4TH4x3w0g7OXWSLprpDopJeuM2vWcTSQU0jtb5/GYvN1y2IduwgcAoYmKsT3DZTzal/SBkY0ibnNTKa8BCnj7TVyG1F1ZcAzWXIOzjAtKQmBHksqqUIPJwHC7QuePhp6TAi6s2SjU2U4HBQNpp0CkgIh46p3obQc1TJLXZhwVLNllNp/7gRffzu3DB0yky3iQq0KJ1yoF280ki0GRf05QWyaByln7Ag1FotfYxAp/erAbC19rbs+TnUzYjIJhgK8fHLp6h4++auDzwB5Q8aFRiiV4Xo9JlFVLNlG+CIlDcLw==
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=fJPmChfE5TkgDaMkTH5EaHG52xxJIhYo3WOejro4U2M=; b=PQBKJFVnO9ku44ZmFkhz9zWAC5cIYYjZFyUNiSS2xy0RX/oQFHBwMUyHm6u51CazFH+K3t5cdgcJ0heQpwEfFQSqxa6m+gncPFCUAEzc2r0+Cr5JaJVj2AelUC0A37KB6zFbg304ugYbUxJ3QisP48OsdWPU5JC+FL/FmGzdOYZ+6iamCTe3QBiGHmeavGwm+xfYkYeOyttIRnNrBOilSjFUg5EyudDqPHgXQWky8L9e33jLPfN8P3T4LRaTd61XPQOrMP2ugubHdf2yAJ9NlfrkphQsPlLFXOn2SeuBRy0/dYIpcaIsFgtfXgTxViQ+Vh/Ddy3/H4Zj0QV0Ls48Bg==
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=fJPmChfE5TkgDaMkTH5EaHG52xxJIhYo3WOejro4U2M=; b=dZHY2x9vnDqmepAQb7bpejo34lFsW2KOMIKKdpoSjRDj28Fhe/yJqsIv11z6camWKri85crhNPsfQCJdhhbeZJHC/tr5/N2vRd103xW2LVvAMfOTcWH2y6i2FmvgjohL1/vlCeTDJ17jCoM3JAMLxPkxZ43ZEOWuC0VITOnTRXM=
Received: from BN6PR05MB3377.namprd05.prod.outlook.com (2603:10b6:405:3d::16) by BN7PR05MB3953.namprd05.prod.outlook.com (2603:10b6:406:8c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Mon, 31 Aug 2020 13:39:49 +0000
Received: from BN6PR05MB3377.namprd05.prod.outlook.com ([fe80::3166:322d:cc48:e2df]) by BN6PR05MB3377.namprd05.prod.outlook.com ([fe80::3166:322d:cc48:e2df%6]) with mapi id 15.20.3305.032; Mon, 31 Aug 2020 13:39:49 +0000
From: John E Drake <jdrake@juniper.net>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
CC: TEAS WG <teas@ietf.org>
Thread-Topic: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix
Thread-Index: AQHWd0W2s2bMXBMKXEWBYrLvT4JGkalB5J0AgAADA4CAAFM2AIAAT4kAgAAsvICAAboiAIAAE6QAgAMJYgCAAbfAgIAAKocAgABFSgCABfTagIAB76SAgAAFjYCAAKnpMA==
Date: Mon, 31 Aug 2020 13:39:48 +0000
Message-ID: <BN6PR05MB337780C4C2E26D835F217E92C7510@BN6PR05MB3377.namprd05.prod.outlook.com>
References: <CA+YzgTvnv5nUZ6OYx9GkFUxDHxAFNvYsx5LrFfho3860_MLfZA@mail.gmail.com> <93726585-ccdd-3460-e6c6-540f98ec9084@joelhalpern.com> <BYAPR13MB243700523A1B5D597973C1CCD95A0@BYAPR13MB2437.namprd13.prod.outlook.com> <2265a594-f48f-3903-d998-3bb764df627a@joelhalpern.com> <b7b110ce14344cadb74b80ea9ccce144@huawei.com> <f07c0de8-6d51-7ffe-7ff5-8fb13212708a@joelhalpern.com> <3f563fbf4a3742a195e61d96844bd042@huawei.com> <MN2PR15MB29903640C9630924BA18B61E8F5B0@MN2PR15MB2990.namprd15.prod.outlook.com> <77124c508ce54822a70afc616c31e5cf@att.com> <CAE4dcxnYo8NCB_ADmd-Qv-5ZwZ5hpM4FtgnF=oLcELTO2i7o=w@mail.gmail.com> <5765E489-B949-424B-8217-8049948AFD08@att.com> <CA+YzgTssZ750UXoc0xzCzD63rbbp3uA_4mzasfLMgni1_Z8J+A@mail.gmail.com> <CF569281-FBA6-4A6F-9888-FA61FA423C1A@piuha.net> <a2a3697e-53d0-4d61-8323-532cb74d5444@Spark> <c45ed6dd357842818c5840793cb17f36@huawei.com> <CA+RyBmV1ie4GD86RfRd7iqHjq-dMDm44onThqH3aXGroZDd7VA@mail.gmail.com> <de600c9d3f92433bb29ba98044530adc@huawei.com> <a6458ee8-b686-8433-9457-e0ec2d55dc07@joelhalpern.com>
In-Reply-To: <a6458ee8-b686-8433-9457-e0ec2d55dc07@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_SetDate=2020-08-31T13:39:46Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=f4d63543-11f2-430f-a019-f13c9caaad46; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
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: 393665cc-c77b-4b7d-6eaf-08d84db354f3
x-ms-traffictypediagnostic: BN7PR05MB3953:
x-microsoft-antispam-prvs: <BN7PR05MB3953D337DC8B73F6EC14C882C7510@BN7PR05MB3953.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jiUAQUMIf2HrMjRh4u391SmEdVAoIIuw5B9LuQ2nxO4khWfNQTFeYV5rOjXi3Px/FNDmdfOPa4Sh6UuDkKQ1VngMnY+DiBcIacXEjAZTPqyNARlXKlAN9rs3+lenqN1R1uvzWrHpRRppaesMqB5s7O0WbAoeRr1WLRLLclVHPccx/QzlwQMrp8WAM8VQyDaH6yIgVK92kIa5YyvMcwjSHn1kRiAb2UjTKsY/EaODx6CSt7c9gRt0V3gEfn5n//PFdcseZf1N821z+sE/QsyQ1+98j+sEzBl/YMaAtKeTFiF2QsD8Et/pC8vBZRYPHS/MuyDznv1/sTDt6GgP4QDsD01WOHkXH7Y+P9yFrcH9e4qHOmR/XTIEMs5JX9PN7iVkVhl1wVvKxtZVENeEWa5U5w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR05MB3377.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(346002)(39860400002)(396003)(136003)(26005)(110136005)(86362001)(55016002)(83380400001)(966005)(30864003)(6506007)(478600001)(53546011)(33656002)(66946007)(76116006)(4326008)(316002)(8676002)(9686003)(8936002)(186003)(66476007)(5660300002)(66556008)(52536014)(64756008)(66446008)(71200400001)(7696005)(2906002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: fQuCryn+HVjpRFiT8vSu1BWIPIjTxMfbzBGV/j7bayiAs/oJlLe73DCjKZCYjC25cp6icC4okIIT8gKIAG9tP0ku5APPfJ2nFNxlKqBPEoJLiZ27VLVdrfyO9o4Ai5xU+zCSMHMO1MyDWG1LccDrxnZqHlQVJfyPC5RmUVxvxN3Lrno6KJo/9u9tgfLU8a9qey+1RuauChg0T+HE/ERskGCYaAeQI8yw/o7EptbXSdEXPy3wcDZI+LDCgnLrwNw4iCKTObuTGp4fVaBVX+/4FZmC8Wmccva4IDvfpQCbsYxBB9JTkumyLmGkWM6U3KXPTIGwgW0nytQ6XXINiqyek5xzIkD33IHaNPqxYTzeApG/5llFKkEC0PpPeV5Eh9s0qKG6Rd+HQudC8HAL3aYemN/XP5W+P9KSWmIbI3a0YpN4AnCv59nf42l4hesQvU75OjYJJ5vxDNLFJ183M5xGPSPyRMGlKMBk6uHQ7gFG6tv1D9/4KbSV/7LtGRhgtqMOMgSq4zRF7CAg3DyXbDdSG75tacYroSr6RvenOSn8V9+mPAVQVZDu+Pu63Dn3WgSDwXqMCY6EEbyWolioK8bSBxtKZgNMc7g1l/MEPVhYyKly8+eBjH8uxGv8DRqNpOYfKRVFfWsdcmV0/XPvU+WEBQ==
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-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN6PR05MB3377.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 393665cc-c77b-4b7d-6eaf-08d84db354f3
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2020 13:39:48.9991 (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: MxKQq00cLbb0YfB+9Xrxd4uQQHmZKJcOyUCxCT+iW8Vw4LndGWox2Te+FLnoBove9GyttZZ8Fu8D1j/y+pcA5Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB3953
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-31_06:2020-08-31, 2020-08-31 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 bulkscore=0 spamscore=0 impostorscore=0 phishscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 clxscore=1011 priorityscore=1501 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008310079
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/XbS_07tiosVYQK9ITKAS0KtINSQ>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix
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: Mon, 31 Aug 2020 13:40:04 -0000

Precisely

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Teas <teas-bounces@ietf.org> On Behalf Of Joel M. Halpern
> Sent: Sunday, August 30, 2020 11:31 PM
> To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
> Cc: TEAS WG <teas@ietf.org>
> Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition -
> Appendix
> 
> [External Email. Be cautious of content]
> 
> 
> Assuming the description you give below, I have two related questions.
> If the performance is great, why would the transport user care whether it is not
> actually isolated?
> Conversely, if the performance does not meet the needs, then why would the
> transport user care that isolation has been preserved?
> 
> Yours,
> Joel
> 
> On 8/30/2020 11:11 PM, Gengxuesong (Geng Xuesong) wrote:
> > Hi Greg,
> >
> > Thank you for directing the discussion to the technical nature of
> > isolation. Please find comments below:
> >
> > I assume that the term "isolation" is not simply a replacement for
> > "dedicated" and is intended to apply to cases when transport slices
> > share underlying infrastructure.
> >
> > I agree about your description of isolation. Although there may be
> > other kinds of understanding which will broaden the scope of this
> > concept. I will leave it to the authors and WG. The discussions below
> > based on the assumption that “isolation is intended to apply to cases
> > when transport slices share underlying infrastructure ”.
> >
> > There is a number of performance metrics that may indicate the lack of
> > isolation but that, in my view, can be attributed to under-isolation
> > (for the lack of better term at the moment) between slices as the
> > result of root cause analysis of increased latency and/or packet loss.
> >
> > I think here hides some basic logic behind the debate: if the
> > isolation could be described indirectly by other SLO attribute,
> > whether we still need it as an independent concept. My answer is: the
> > hypothetical part of the question is incorrect, because *isolation
> > can’t be described by other attributes, although it influences other
> > attributes.* A further conclusion is that : *Deterioration of other
> > SLO metrics is neither sufficient nor necessary for isolation
> > absence*. Two simple examples to defense this:
> >
> > 1.When isolation is perfectly executed that there is no interfere
> > among different slices, the performance could still be very terrible
> > if the resource inside the slice is exhausted.
> >
> > 2.When there is no isolation among slices and all the resource is
> > shared, the performance could still be very great if the resource is
> > sufficient for all the slices.
> >
> > So the trick here is: other SLO attributes (delay, jitter, loss…)
> > depend on whether there is enough cake to make everybody happy, and
> > isolation prevents other guys to touch my cake. They're relevant, but
> > they're different, and not interchangeable.
> >
> > That is why I agree that isolation should be clearly defined in
> > draft-nsdt-teas-transport-slice-definition, not in Appendix.
> >
> > Regards,
> >
> > Xuesong
> >
> > *From:*Greg Mirsky [mailto:gregimirsky@gmail.com]
> > *Sent:* Sunday, August 30, 2020 5:38 AM
> > *To:* Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
> > *Cc:* Jeff Tantsura <jefftant.ietf@gmail.com>om>; TEAS WG
> > <teas@ietf.org>rg>; Jari Arkko <jari.arkko@piuha.net>et>; Vishnu Pavan
> > Beeram <vishnupavan@gmail.com>
> > *Subject:* Re: [Teas] WG adoption -
> > draft-nsdt-teas-transport-slice-definition - Appendix
> >
> > Hi Xuesong,
> >
> > I assume that the term "isolation" is not simply a replacement for
> > "dedicated" and is intended to apply to cases when transport slices
> > share underlying infrastructure. If that is the case,  I think there's
> > a sort of contradiction between statements "isolation is SLO" and
> > "isolation is not directly measurable [calculable GIM]". I wonder,
> > What is the opposite of isolation as a TS characteristic? I imagine
> > that one example of that would be a case when the flow from one slice
> > is using resources from another, i.e., interference between slices.
> > There is a number of performance metrics that may indicate the lack of
> > isolation but that, in my view, can be attributed to under-isolation
> > (for the lack of better term at the moment) between slices as the
> > result of root cause analysis of increased latency and/or packet loss.
> > And even if interference from another slice doesn't result in
> > observable quality degradation, an operator can compare the offered
> > load from the customer with the available BW. And that information
> > doesn't have to be measured by the client but reported by the operator
> > in the agreed intervals and aggregated on an hourly and daily basis.
> > Certainly, we can have more cases that constitute the un-isolationism
> > of slices but that, I suspect, still will be observable, measurable,
> > calculable through other SLOs and only the analysis will point to the
> inadequate isolation of resources.
> >
> > But back to the isolation. I believe that the proposal from WG Chairs
> > is the best way forward. Let us explore our interpretations of the
> > term and work on formulating one we can build consensus (rough)
> > around. And if so happens that there is none, then we all get a better
> > understanding of the problem and may get it in the new document.
> >
> > Regards,
> >
> > Greg
> >
> > On Tue, Aug 25, 2020 at 7:40 PM Gengxuesong (Geng Xuesong)
> > <gengxuesong@huawei.com <mailto:gengxuesong@huawei.com>> wrote:
> >
> >     +1
> >
> >     And one more supplementary comment about “Isolation is not a
> >     directly measurable SLO”. Maybe here is some fog about what is
> >     measurable. Isolation could not described by number/value. But it
> >     doesn’t mean that it is an abstract concept that could not be
> >     defined precisely. People are asking whether TE link is isolated or
> >     not. It could be clarified by some deep analysis, good discussions
> >     and clear text. There is no conclusion yet just because we don’t
> >     even allow it to be existing in an WG document. And I don’t think
> >     the definition of other SDOs really matter. Because isolation in
> >     mobile network is different from isolation in IETF. If there is
> >     requirement in IETF, define it in IETF. We can’t say we could not
> >     get to somewhere because there is no path. Build the path by ourselves.
> >
> >     Xuesong
> >
> >     *From:*Teas [mailto:teas-bounces@ietf.org
> >     <mailto:teas-bounces@ietf.org>] *On Behalf Of *Jeff Tantsura
> >     *Sent:* Wednesday, August 26, 2020 6:32 AM
> >     *To:* TEAS WG <teas@ietf.org <mailto:teas@ietf.org>>; Jari Arkko
> >     <jari.arkko@piuha.net <mailto:jari.arkko@piuha.net>>
> >     *Cc:* Vishnu Pavan Beeram <vishnupavan@gmail.com
> >     <mailto:vishnupavan@gmail.com>>
> >     *Subject:* Re: [Teas] WG adoption -
> >     draft-nsdt-teas-transport-slice-definition - Appendix
> >
> >     I find Pavan and Lou proposal reasonable and a good/working way forward.
> >     While isolation is not a directly measurable SLO, it is often a
> >     legally binding requirement wrt service provided, could be expressed
> >     as a physical SRLG or disjointness.
> >     It is also a viable constrain to be used in  a path computation logic.
> >     There are connectivity RFIs that explciteily require full physical
> >     separation/isolation - finance for security reasons,  DCI for
> >     resiliency, etc.
> >
> >     We could pretend it doesn’t exist (which is the complete removal) or
> >     find an appropriate and acceptable to the WG description as the
> >     document evolves.
> >
> >     Cheers,
> >
> >     Jeff
> >
> >     On Aug 25, 2020, 12:59 PM -0700, Jari Arkko <jari.arkko@piuha.net
> >     <mailto:jari.arkko@piuha.net>>, wrote:
> >
> >         High-level bit: I would like to see the document adopted. With
> >         changes if needed. Let the WG decide. Design teams are there
> >         just for preparing proposals. Authority to do stuff is entirely
> >         in the WG now.
> >
> >         When it comes to the isolation topic, however, FWIW, I wanted to
> >         provide both a context from design team discussions and my
> >         personal perspective on this.
> >
> >         Design team discussions:
> >
> >         We’ve had variants of this discussion on almost all of the calls
> >         we’ve had for the last year. One one side there was our shared
> >         observation that industry uses the term isolation, and (perhaps
> >         less widely shared conclusion) that it is important to be able
> >         to relate to this. On the other side, there was our shared
> >         agreement that what matters from a requirement perspective is
> >         the bandwidth and other requirements, and that there are several
> >         techniques that can provide the desired characteristic of not
> >         having your neighbour affect the bandwidth the service provider
> >         has agreed to give you.
> >
> >         The text that we had was in an appendix precisely because we
> >         felt that the top-level SLOs should be the requirement and are
> >         sufficient by themselves. The appendix only attempts to say that
> >         “there’s multiple ways to achieve this, and by the way, this
> >         term in the industry relates to our work in this indirect way”..
> >
> >         I can appreciate that we may have failed in the task of writing
> >         that. Delete and move on, no biggie :-)
> >
> >         Personal perspective:
> >
> >         My impression of customer requirements and how they get
> >         represented matches with what Joel has been saying in this thread.
> >
> >         I’m fine removing the appendix.
> >
> >         If I had my way, I would write the document based entirely on
> >         the primary characteristics — such as that we promise you n
> >         GB/s. Then I would write a footnote or appendix somewhere that
> >         explains that this notion isolation has also been discussed
> >         elsewhere, and that it can be represented using the primary
> >         characteristics, and hence need not be discussed further in this
> >         document. One could perhaps also point out that there are
> >         multiple ways to implement the primary characteristics promises,
> >         so that those promises can be kept despite what’s happening with
> >         your neighbour’s traffic. And leave it at that. But I understand
> >         from this thread that people are reluctant to do that, and may
> >         even be reluctant to write anything about isolation. I’m fine
> >         with that, too.
> >
> >         Jari
> >
> >         _______________________________________________
> >         Teas mailing list
> >         Teas@ietf.org <mailto:Teas@ietf.org>
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!Ugj_X1TkAhoanpKNU7xBQ3HnkOoF3uHpZW4-
> 2d0WPcdGw12Cw8M1k
> > PJeT478yjU$
> >
> >     _______________________________________________
> >     Teas mailing list
> >     Teas@ietf.org <mailto:Teas@ietf.org>
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!Ugj_X1TkAhoanpKNU7xBQ3HnkOoF3uHpZW4-
> 2d0WPcdGw12Cw8M1k
> > PJeT478yjU$
> >
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!Ugj_X1TkAhoanpKNU7xBQ3HnkOoF3uHpZW4-
> 2d0WPcdGw12Cw8M1k
> > PJeT478yjU$
> >
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!Ugj_X1TkAhoanpKNU7xBQ3HnkOoF3uHpZW4-
> 2d0WPcdGw12Cw8M1kPJeT478yjU$