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

Young Lee <> Tue, 25 August 2020 23:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BF6D3A086D for <>; Tue, 25 Aug 2020 16:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WMF3fAE9E5-b for <>; Tue, 25 Aug 2020 16:32:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A0BD3A0866 for <>; Tue, 25 Aug 2020 16:32:58 -0700 (PDT)
Received: by with SMTP id w3so128098ilh.5 for <>; Tue, 25 Aug 2020 16:32:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <a2a3697e-53d0-4d61-8323-532cb74d5444@Spark>
In-Reply-To: <a2a3697e-53d0-4d61-8323-532cb74d5444@Spark>
From: Young Lee <>
Date: Wed, 26 Aug 2020 08:32:45 +0900
Message-ID: <>
To: Jeff Tantsura <>
Cc: TEAS WG <>, Jari Arkko <>, Vishnu Pavan Beeram <>
Content-Type: multipart/alternative; boundary="0000000000007c11ed05adbc1f2b"
Archived-At: <>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Aug 2020 23:33:00 -0000


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


2020년 8월 26일 (수) 오전 7:32, Jeff Tantsura <>님이 작성:

> 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 <>, 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 mailing list