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

Young Lee <younglee.tx@gmail.com> Tue, 25 August 2020 23:33 UTC

Return-Path: <younglee.tx@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 1BF6D3A086D for <teas@ietfa.amsl.com>; Tue, 25 Aug 2020 16:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 WMF3fAE9E5-b for <teas@ietfa.amsl.com>; Tue, 25 Aug 2020 16:32:58 -0700 (PDT)
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 1A0BD3A0866 for <teas@ietf.org>; Tue, 25 Aug 2020 16:32:58 -0700 (PDT)
Received: by mail-il1-x131.google.com with SMTP id w3so128098ilh.5 for <teas@ietf.org>; Tue, 25 Aug 2020 16:32:58 -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=gn3yR57512zPChvyCA9/P9DfdWbSsDCJ/cMOAto1iUY=; b=dM5Vt3J7jrjfK/Ctl0SzcHJUd6Bu6nPX4IR2D0U5bB8y335SlGLg4gAFjNLnVpEY7w 9rDRvpvJbwE/n7qXDbUfSMM8vI8HT8IzYK5XpIPLUNj6Ywec640TdLnLr4E1kp4pgcaq xPm/0xJ81fAmasusRUenw0nuNIlC1fvw9FRykZ20Iba9VoawO6lzABlhEoaWfyWo1222 Ra1HCyPuht7jHsXo5wJPEgNVll4/pc/k8oh1hKI+VXns9FcIDR6eUir2kiIO8MDk0Olk P0Hu61urPsbE5RD85KMDaW0nHRXi2zR4+eAQ2v5MLOK7hEmMyOGH1dzzz+rTO6pDcY4O RimA==
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=gn3yR57512zPChvyCA9/P9DfdWbSsDCJ/cMOAto1iUY=; b=S0j09WwR5m0CYx0MTlcBnScok6r0rbnVvGboWAkAlbsEX54Cc4dOuAc9GpSUMDFZ9F ABbnkFRK+OeEJZXzL3lCbZAys4fFYT3WV7vI2kBWG9OdQJl5EsGHXsvPoom9K6g2Y8MK SIt20BJbSYI8LyNKsK/784E9i4cCUfFBjagy32SGNGItZB3dF+XCaWOXXP1VaIrQenF7 Ph8XWCZiZwGEt3UAiKZr8/Qa8ysoQfxyEUC7gjFkjALqbINgywNTCuaRpJAa4oQVyy1M MLosfrJNEGK3A0PhNtmlt3S3KlnkM2Cc+gD7gbzcS17s0Tr83HLQjuQo+BR3X8yB0Dqs KlDQ==
X-Gm-Message-State: AOAM5323nA2tUDN4/47wl0bs7+3GI1jLHaLqddTMxAUT75gXMsQx0FEo YQRlHFEctWbyxAJX7AKSEK7llVNf2BbYT4qrgAA=
X-Google-Smtp-Source: ABdhPJyJJV0WUG0gd3h7fDEE+TZORQrSlAorz87XoGPh+yDUpBnKeKaJKJWIQ3dm6OY8kDJ/mLjy8CJBq41YL8cQwKQ=
X-Received: by 2002:a92:9881:: with SMTP id a1mr11406546ill.232.1598398377233; Tue, 25 Aug 2020 16:32:57 -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>
In-Reply-To: <a2a3697e-53d0-4d61-8323-532cb74d5444@Spark>
From: Young Lee <younglee.tx@gmail.com>
Date: Wed, 26 Aug 2020 08:32:45 +0900
Message-ID: <CAGHSPWMxYwAvnht0zmos9cMX3qvySduuq59C2n9ufq=b-wNuWA@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: TEAS WG <teas@ietf.org>, Jari Arkko <jari.arkko@piuha.net>, Vishnu Pavan Beeram <vishnupavan@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007c11ed05adbc1f2b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/9RGwvirQw971cDqHO-CvZoN53YA>
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: Tue, 25 Aug 2020 23:33:00 -0000

+1

If isolation is not the right term in IETF, I'd think a reasonable
compromise is to use terms like 'sharing property' or a similar term. The
extreme case of the attributes under this property disjointness in
port/node/link/path level. This would be equivalent to private dedicated
network level if you will. Other level of sharing can be enumerated
thereof.

Thanks.
Young


2020년 8월 26일 (수) 오전 7:32, Jeff Tantsura <jefftant.ietf@gmail.com>님이 작성:

> 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
>