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

Greg Mirsky <gregimirsky@gmail.com> Sat, 29 August 2020 21:37 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56093A105B for <teas@ietfa.amsl.com>; Sat, 29 Aug 2020 14:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Level:
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK7hS1V1OhU5 for <teas@ietfa.amsl.com>; Sat, 29 Aug 2020 14:37:51 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4753A105A for <teas@ietf.org>; Sat, 29 Aug 2020 14:37:51 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id r13so2680011ljm.0 for <teas@ietf.org>; Sat, 29 Aug 2020 14:37:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lKwjQsJGOPhC8KOqTgFhgdfRx3RG4CxUYRgUVzkcDAE=; b=MOTzL9e6YAhwgWGQePOa3vHk2/OcdypyIAdQT7o52423OEfwPvF7OiL3dwtXPunc1y 0NQuD8Gp3EgcdedVv7y1nXsvCBozDuOVpPqm9Ivh/3d2KzjsnloKUDGa+YqRNl0k8XmT hRPYuhoFLZLaRkPwP+jnW+k4593zZiq84jdfBaK9W+qs8ACMFsry7OwQgn6QNSCEs/+a RPkNwlI8QvPN8pc1m/ga8NNOAiFULD8PfQfd4/Yhvj/eGXAPsDnzbZROyHbFbcZkF3TN djmiRmAeIt66JurbPILfY5dPjfk7KYBJK7xMfKUGz5c6iXDil+4cpVPDeuhUi6mXyyGM /w/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lKwjQsJGOPhC8KOqTgFhgdfRx3RG4CxUYRgUVzkcDAE=; b=sCQeN0zxgNvyQf4J/sqYhrlLJXHUr2q+4+/c9gD+mnlH3UP0eypHDSJ3pwsYH780aK ITM6k3MMU7DIHWdLHosHjmhvezfqRt5WJq4MyW4S1Q9K4qqXV0+QULNA8ZvR91u/NmDe jKw89qMmw/EY8pdP3Bu7iwJ1cNfHExOwsknTTAw1YsaQywx5HtU9YXrKVf2W1IDaRFvW ml7/2zilNE2yIlwLltl8r+Yn7mKMNHATUrk3qaWdoP2EBE75gSCrqa0dX2DL4zKgZz46 5GInkwU0zM1GiiOtlTUvUxAhcs8XoGTNgyCrkVqWIg+ZJ3ATmKKm7rIu0dJSwUZw7JK1 Iz7g==
X-Gm-Message-State: AOAM532FLrRd4BTbPSL2D3Dhyi2nL0+4ow+c4WAvlI7SCp4+QMy6jJFq sZqpcMhrNfAQdRwSxBbdQp4JpPyAW5ayCRTsbfI=
X-Google-Smtp-Source: ABdhPJxPQYN29li7jxSRdg949UELyk6NumbcCNC/VtIqDWhE8GssVUkSDEHV6VwI+h0FhcWKpGExI9lBEo/9UfefleM=
X-Received: by 2002:a2e:8648:: with SMTP id i8mr2309821ljj.288.1598737069018; Sat, 29 Aug 2020 14:37:49 -0700 (PDT)
MIME-Version: 1.0
References: <CA+YzgTvnv5nUZ6OYx9GkFUxDHxAFNvYsx5LrFfho3860_MLfZA@mail.gmail.com> <330a76d8-2f05-795f-42a6-01de094b54b4@joelhalpern.com> <BYAPR13MB2437D23542B163D477B583C8D95A0@BYAPR13MB2437.namprd13.prod.outlook.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>
In-Reply-To: <c45ed6dd357842818c5840793cb17f36@huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 29 Aug 2020 14:37:37 -0700
Message-ID: <CA+RyBmV1ie4GD86RfRd7iqHjq-dMDm44onThqH3aXGroZDd7VA@mail.gmail.com>
To: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, TEAS WG <teas@ietf.org>, Jari Arkko <jari.arkko@piuha.net>, Vishnu Pavan Beeram <vishnupavan@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000016920f05ae0afb6f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/2VV6jyYmQOIuixYjtt1QcwjDE3o>
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: Sat, 29 Aug 2020 21:37:54 -0000

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> 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] *On Behalf Of *Jeff Tantsura
> *Sent:* Wednesday, August 26, 2020 6:32 AM
> *To:* TEAS WG <teas@ietf.org>rg>; Jari Arkko <jari.arkko@piuha.net>
> *Cc:* Vishnu Pavan Beeram <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>et>, 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
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>