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

Jeff Tantsura <jefftant.ietf@gmail.com> Tue, 25 August 2020 22:32 UTC

Return-Path: <jefftant.ietf@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 BDBB13A0770 for <teas@ietfa.amsl.com>; Tue, 25 Aug 2020 15:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 uc2s58T8gMuh for <teas@ietfa.amsl.com>; Tue, 25 Aug 2020 15:32:10 -0700 (PDT)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 BD8A83A052C for <teas@ietf.org>; Tue, 25 Aug 2020 15:32:10 -0700 (PDT)
Received: by mail-pg1-x533.google.com with SMTP id g1so6520pgm.9 for <teas@ietf.org>; Tue, 25 Aug 2020 15:32:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=0zhsAFQO0Jj3sXPAnjhROj3lTP75f1fAcw/Q7+ndpqU=; b=MXumKZiDzJZywecHZENpmWce0QTiHB7m6wZKQ8KkEzHGuSfmFiYbTdf16OjZK7AHCu I3NOvVU5aa2hv61NGs1yBWcDdrK/swef7cLQ/p6XktXjFGwnLr4cfuWjUhSYdS0p0uID I2xh4fjCVqHZGBoW8UsdbWBrN0NE+rc+wBsJF0P1yfVoeTF8igJHxzDD91p+e+tKqGl7 I5dNXziSNB40WuXlpIeDVXWN/wll9molamHuom1bmShLry7HU8JDXDi6bDFW6eTJ655Q 0ZoHFtaAPXElMgFsN0cG69vXWG++8lfELwKnss4dgK1cEiITnlehS9r4f3j/zjEHcUEx ja+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=0zhsAFQO0Jj3sXPAnjhROj3lTP75f1fAcw/Q7+ndpqU=; b=GkSs3LBpVPgKC8h2AWa4RJlxbCwnb0Q6lwoMiOa8WI6SJ4fkjrlqbtdMzECY9kBqEF j08ycJlNLrkKHwTLtUMq12b9yuuMm4QOyaAUEyYHCjk2A/t9jz/2P5Le3B3cUU2mzSyb fQ5PFWFtvKLjZ6P/c6wcMKz1S6G8TiXsqr2nU/3lrmRsyGq2hOBgbWYGH2Nb2/iK1y0z E2+XySgjlrFX4Eyp17/zfUsnqEnN5NszauZLCXUS3PxRt+pOIKRwyJ0Q5Dqdb0bhgm1P HHWaeTnjZKLwRY7dtGB2rYaN2+ZKiOYe/znbIw9I1rczBZ3Qo1d0Z4ruDTubAy/X1UE/ 8b6A==
X-Gm-Message-State: AOAM533OcE3Fu4JLPpMYdj/hlORYdOwV3qEHf5nP9DQLqbHfYZOjTelZ l2IAfoCusAmMDzQ9ewnAsqYdiQCD1ms=
X-Google-Smtp-Source: ABdhPJxjqAxvx4JN7tJmthB8/cwzQG7xUesQL+kGkrd6s9RjlUlBxha6Rzfvkh9dAI332hwX2hEoyw==
X-Received: by 2002:a63:3d8c:: with SMTP id k134mr8016605pga.279.1598394729717; Tue, 25 Aug 2020 15:32:09 -0700 (PDT)
Received: from [192.168.1.8] (047-036-118-016.res.spectrum.com. [47.36.118.16]) by smtp.gmail.com with ESMTPSA id il14sm94540pjb.10.2020.08.25.15.32.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Aug 2020 15:32:08 -0700 (PDT)
Date: Tue, 25 Aug 2020 15:31:58 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: TEAS WG <teas@ietf.org>, Jari Arkko <jari.arkko@piuha.net>
Cc: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Message-ID: <a2a3697e-53d0-4d61-8323-532cb74d5444@Spark>
In-Reply-To: <CF569281-FBA6-4A6F-9888-FA61FA423C1A@piuha.net>
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>
X-Readdle-Message-ID: a2a3697e-53d0-4d61-8323-532cb74d5444@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5f459167_4c04a8af_f91"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/LrbdBqwg5iBd8u1FjpH7epe9Lp8>
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 22:32:13 -0000

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