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

Uma Chunduri <umac.ietf@gmail.com> Tue, 25 August 2020 23:51 UTC

Return-Path: <umac.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 DBBD13A08CB for <teas@ietfa.amsl.com>; Tue, 25 Aug 2020 16:51:36 -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 AY1NpCvNTDhu for <teas@ietfa.amsl.com>; Tue, 25 Aug 2020 16:51:34 -0700 (PDT)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 93CAE3A08C7 for <teas@ietf.org>; Tue, 25 Aug 2020 16:51:34 -0700 (PDT)
Received: by mail-ua1-x934.google.com with SMTP id s29so14128uae.1 for <teas@ietf.org>; Tue, 25 Aug 2020 16:51:34 -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=K0FdJMIYE4RQ8w62oRG5JJbU7QVe7BSMQofhe7Co/9c=; b=afpRjfiU9zYlkExCqoyNmDLhaIJVuvf9gy5za/PmzSunknEc72k86b+nm0JlTYak3A 8ybywaK49on3pyACoMFxk0g+3An3hljYsug12hoMgDr4p73NrjjfRwVbDnmzx9qaGm37 QcwXdebp2yHCt1TfBfDgqZspH8OQ2xR9WBS56n0ejJKT2jUsImGdV+uE4na6aiSDWjXM 9X4eYLIanouBzSEgVIUxcRNcEnGXrxUXFvlGoLaIVIQv4Hdn2g/9woW0nACLdIbbbKvk NFsDut6EKmIqngxYlqgea0ZybeIspmcppUpgT8Zi/c9AEHjpJGoM3ub1vLfbU17p0dPy eXFA==
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=K0FdJMIYE4RQ8w62oRG5JJbU7QVe7BSMQofhe7Co/9c=; b=K0b0y906ES03nlFXaiwTgjXfx0un+qf29tS+OVsFVc0kpsj+6+p0+yOmkIcUL4U1Es cnXZpQOa7vegbpn9hJJOv5C54VPSX4Ka0rwmNPva+uG3WSS0rPopYavAfbyWB9JOSs5k RSeogj1ZH3GYaZNd5mghp18eks9i3a3xGfrxV9HVoPqJUDzAt0VKH+R6NVSOknqUMbmd g8ScWHSk9n68pjCkuMkTlpTuZXziEu2S15JSHsp0dg7iIAQghUZr2wLWLMTVlUaeUfvJ RT81K5YxvfkGwMJTro4Q7Z7DbvGyMf3JbGudO5jiA1H5A7ChDtebJ68N80xW0+Lm4wFv fnxg==
X-Gm-Message-State: AOAM532mfrn/2osqz18TJvzvALu1hVdVyIxkmxOLkNr4Fdhe0tXD9tTe 719YM/VeWhO20+q6y2q7prjce1mR2iURiNZ/YUs=
X-Google-Smtp-Source: ABdhPJyX5k2a73ZL1moUBS/fuHzq+xhBSgKLEHmXm4trrwoKyMddi6NObmBDjfc8nIYmQUyRJOEFB60wyRZ3TpvvFPc=
X-Received: by 2002:ab0:6054:: with SMTP id o20mr7072136ual.87.1598399493462; Tue, 25 Aug 2020 16:51:33 -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> <CAGHSPWMxYwAvnht0zmos9cMX3qvySduuq59C2n9ufq=b-wNuWA@mail.gmail.com>
In-Reply-To: <CAGHSPWMxYwAvnht0zmos9cMX3qvySduuq59C2n9ufq=b-wNuWA@mail.gmail.com>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Tue, 25 Aug 2020 16:51:29 -0700
Message-ID: <CAF18ct4TCkU=k1RRvi5yJebeLKdR8Z2+n+rZ-R4wUqva10DNsg@mail.gmail.com>
To: Young Lee <younglee.tx@gmail.com>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, Jari Arkko <jari.arkko@piuha.net>, Vishnu Pavan Beeram <vishnupavan@gmail.com>, TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000045ff505adbc628d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/ViedIJt2GukIdvtg6yH7QsRt9ZY>
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:51:37 -0000

+1 (Jeff and Young).

2 quick thoughts:

a) Sometimes (based on the context) it also can be viewed as isolation from
the best-effort/shortest-path traffic path or a TE tunnel specifically
created for that slice (one basic form of isolation in the TE world).
Extreme form of  isolation lends itself to a dedicated network (private 5G)
and that may not be much to do with this document, perhaps.

b) In the below message, though it might be giving an example
    "... desired characteristic of not having your neighbour affect the
bandwidth the service provider has agreed to give you."

   It sounded like what an end user is getting from an SP? If that is the
case the scope is way bigger than PE to PE case (need to read the latest
version to see what's the scope).
   In any case, it's good to clarify the entreprise traffic isolation or
end user. If it is later the implications that need to be dealt with would
be much more here.

And finally isolation in all cases in shared infrastructure could be a myth.


--
Uma C.



On Tue, Aug 25, 2020 at 4:33 PM Young Lee <younglee.tx@gmail.com> wrote:

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