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

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 31 August 2020 03:31 UTC

Return-Path: <jmh@joelhalpern.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 AADDA3A0DEA for <teas@ietfa.amsl.com>; Sun, 30 Aug 2020 20:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.048
X-Spam-Level:
X-Spam-Status: No, score=-3.048 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, NICE_REPLY_A=-0.948, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 8uZ7BKZxjVa3 for <teas@ietfa.amsl.com>; Sun, 30 Aug 2020 20:31:29 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 DBC4F3A0DE9 for <teas@ietf.org>; Sun, 30 Aug 2020 20:31:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BfwjF5kXGz6GD5C; Sun, 30 Aug 2020 20:31:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1598844689; bh=SXuMOhuEWpMdhwOw9p55rQtgmTbm10p/iPo5KVnx5Lg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=T8aw3TdZQtJ4gKzcsd5zft1XcHrzr1ZfLn48Yp3rJSuRnoYflJMGaXwYjLQX7NoPd iZ65vyZVJR6Pv1xUWsjxV27iepPP0REye/sV0FVZVRy+uCLkShxUy/E0OJdFa3Nio5 qi1zAEplzd8vr+A+4dMls72aya/rU3qzYkfg64OE=
X-Quarantine-ID: <el-45LJ9fIo3>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BfwjD60Hnz6G99X; Sun, 30 Aug 2020 20:31:28 -0700 (PDT)
To: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
Cc: TEAS WG <teas@ietf.org>
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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <a6458ee8-b686-8433-9457-e0ec2d55dc07@joelhalpern.com>
Date: Sun, 30 Aug 2020 23:31:27 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <de600c9d3f92433bb29ba98044530adc@huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/ghOr4NBtl9R-q2F2oWKhYWPqbGQ>
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 03:31:32 -0000

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://www.ietf.org/mailman/listinfo/teas
> 
>     _______________________________________________
>     Teas mailing list
>     Teas@ietf.org <mailto:Teas@ietf.org>
>     https://www.ietf.org/mailman/listinfo/teas
> 
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>