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

Kiran Makhijani <kiranm@futurewei.com> Thu, 03 September 2020 05:24 UTC

Return-Path: <kiranm@futurewei.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 573383A0B35; Wed, 2 Sep 2020 22:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 vmBLqZxTw8Tu; Wed, 2 Sep 2020 22:24:50 -0700 (PDT)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2096.outbound.protection.outlook.com [40.107.236.96]) (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 ED89C3A0B22; Wed, 2 Sep 2020 22:24:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Yx2AosxV+MYvfIuRj4ZC61bXrATOBwdmEbA2AutCJHtQSpNIVEVleG2M5C9hejK1dJ7+RmzhahEDVVrb9Vq2nXJLZ7WzqNvHgiwwoAezdQQAXcZBl2w7+btyavgJG52Zu7DOY9VQDRexKSKzFSdGJdNa52xDdNrJ4DLkBXrwWyDyUx3tMCISS5X7FdAXZQ2r2FdzB5DqlsYBM8sekY3WlkjrKwA999w9bEOuplowM8WQ7ZVXWdNsLibtvyjRBTdzmoLt+p/27RrBl4ddttIbOe/c/WQkRhwQWPSE2eMlt6ri7d47UJaGsnnFA/pCmQk5XTGr/mqDLbe8WBm7xfyVzQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RgDjEV0bK2S6GcX8IiUjz1xfHZyU/yDwHfHRtyVhEqw=; b=Dro3OsvAZCjI70sgaA0wZXJJA/nVznjKTmjanq1QIc7DKKrE8FhLWxkkHaGtMNQKoJBCG6GygHRG8fO8WCaAL4xOzfrEL70nmJhJSJo6g5zg6LTI3in/HObmtIHKBTUfZ71ZPAH4aZWThVgRy2kSDQ1GoMj0TOebzHv66KSemWrs5wAbP/Vzf8MZd1ECbMz6F36NIPY8uvgM6pPbd68qcoquDkusVjM9CWyi/cGdkSJL+goIDPH46nio5JknYqZSIC6DyNOBNixyiqptAEfYdTGEjY18yhhk/ard70xoen/ou/BtKqUZZFRVR9F2rwq+oFuFJOi099HNdBIyccmF5g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RgDjEV0bK2S6GcX8IiUjz1xfHZyU/yDwHfHRtyVhEqw=; b=LjFvPBsniWbn7LwX/yHUC8Dvx3f/SNOiGdFFLvq8HvimDQ06sUqqOn1ZZc8jLkwz6rn9MC0BysME7lRjbPqEgWQbGBcF5R3PRM7vR8UYEkH/CvQnR+7SedHm6b7y/nW1/mXDxfZT9EYrPR2KDxb9mU8cytlDYmJ9P/oIiRaPQWg=
Received: from BYAPR13MB2437.namprd13.prod.outlook.com (2603:10b6:a02:cb::23) by BYAPR13MB2343.namprd13.prod.outlook.com (2603:10b6:a02:c5::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.9; Thu, 3 Sep 2020 05:24:45 +0000
Received: from BYAPR13MB2437.namprd13.prod.outlook.com ([fe80::4596:6de4:d7fe:66ee]) by BYAPR13MB2437.namprd13.prod.outlook.com ([fe80::4596:6de4:d7fe:66ee%3]) with mapi id 15.20.3348.014; Thu, 3 Sep 2020 05:24:45 +0000
From: Kiran Makhijani <kiranm@futurewei.com>
To: Shunsuke Homma <s.homma0718@gmail.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
CC: TEAS WG <teas@ietf.org>, TEAS WG Chairs <teas-chairs@ietf.org>, Vishnu Pavan Beeram <vishnupavan@gmail.com>, "BRUNGARD, DEBORAH A" <db3546@att.com>
Thread-Topic: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition
Thread-Index: AQHWdkCSDxwa/BdjN0OJZziYM0mD76lUY1sAgAE6boCAADKrAIAAB3KAgABzJoCAACpLIA==
Date: Thu, 3 Sep 2020 05:24:45 +0000
Message-ID: <BYAPR13MB243778E4EB91EB67FB8D30C6D92C0@BYAPR13MB2437.namprd13.prod.outlook.com>
References: <CA+YzgTvnv5nUZ6OYx9GkFUxDHxAFNvYsx5LrFfho3860_MLfZA@mail.gmail.com> <009001d680a7$eee86630$ccb93290$@olddog.co.uk> <CAGU6MPcdBkBMotvh=GM0rmFv3MnYVdEHk5cUJ6dF0KBRpL0C4g@mail.gmail.com> <26E73EA2-FE9D-4DDD-ADFE-3F1184AA4451@att.com> <026201d68162$353da9a0$9fb8fce0$@olddog.co.uk> <CAGU6MPcyM2V77RW=3U8y-dCfNW2orPrhjWuUz7rxv=k1V8+eVA@mail.gmail.com>
In-Reply-To: <CAGU6MPcyM2V77RW=3U8y-dCfNW2orPrhjWuUz7rxv=k1V8+eVA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [67.188.27.49]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1e9ebade-83db-413d-eaf1-08d84fc9ab26
x-ms-traffictypediagnostic: BYAPR13MB2343:
x-microsoft-antispam-prvs: <BYAPR13MB23432DA407FFF7D54E5F7C8AD92C0@BYAPR13MB2343.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ooC5BO0+BTJmzu5CfSn33vhvAURilR4VwoFLUXYjBJSJgB2mdVTrGpb2P6lwO8nX2BISlBCdjJlx7H9Vs8WdC1usisqRmVnIjL5K4LTBQ0GunOJrfeXxE+Z1Mj7vEvRag3wtX5HmNe/FvHjMRkINiUxwu+chqDNK1COPl8HixAhanV+B3rQp25lUtoiQZsqZiTHdwuL0EKOoWhIQiwT2obvHJlp5GzMJ5B3NtyOJV7k0UyRIGRoyTIwB+gs2iJt0QE9n77kJjXfpxzLHkOlnsRutzqoX/N28Zr/q9679KBIKhAhSiSV0uUqHnlOsSw+SPKDVxvK6GPa5JIP0R2d1B0ZWYjOfDieAs50Qj53K7IGCdBCGqFa8BwseJuYPgS5M5vYgesHibOWzOxKutb/1pA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR13MB2437.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39850400004)(376002)(396003)(366004)(136003)(71200400001)(53546011)(8676002)(7696005)(33656002)(5660300002)(66946007)(66556008)(30864003)(66476007)(55016002)(8936002)(6506007)(64756008)(186003)(54906003)(52536014)(83380400001)(76116006)(66446008)(86362001)(316002)(2906002)(4326008)(110136005)(478600001)(966005)(9686003)(166002)(26005)(579004)(559001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: lEPMNBkupiuuEoaAOeJGRB+UwJ5W4/R+L+xRXeu7xbs06429VowNzQPUzZk6VfY7avPTHoftpq5d9iBo9MK7aDURgU/NdWmWnVuwVXP/6NI7unaN4MZzwneXQWfhYpE5XcZ5LplIxHSz0X7HpUm40lqLMXwbObJb4266YEknYqUf+yXZ5W7zJLt7KFfuu9oxm5MPssypwq6vy7VJQlOuS0PxIwTDAM6A99Qa9Xo3wQtVGjIeQFpOWYCUEi0aZtDmDWPGDK6HTbKqZk49NCUi6B/KroE3doKiwnKxkTAzZsvA0iB8eG5IjMOfONhs77tDMG3IAox+LI4345B7T/umX4sdYmsnQDHYsBFZzLZvw7x6WaqozCYqkA7bN04xhtXdSPdqKS0Ah7mlYeVVICoK62T7Gd/T02DD8wjxHInGS/KueQX36bwzd4uxCf8zpVK5QjPmZZ4pSsLf4FB7qXMPiWpVWMDq6R7hNDxxvrPVHF618rt/wwqqBW98hcRtCTYU6c39o5wIsQYIO/w+31kUldqpqQ4tW4U3N7ESYmQnRCkVVIiEgjstPbb85IeUIN6FJ7Fv9rp9QoAUZ+V1cximlqPAxnF1Drr8tIS/rm0EyjBSnnN4SZQjI1w2wZsvxvrE7+tib0lp91AifXddfCW5aQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR13MB243778E4EB91EB67FB8D30C6D92C0BYAPR13MB2437namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR13MB2437.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1e9ebade-83db-413d-eaf1-08d84fc9ab26
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2020 05:24:45.0660 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wEOhreXu0RmsDQpIULYuullI4xEJwVPZeOjvKvbyFHp0gdqaBe0JvmYzV/ALCIHyR+dNwRcp/I7hlJCBM2+Z6Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2343
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/LP3jhh7CKsXhe1o0COgTT5sO0vY>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition
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: Thu, 03 Sep 2020 05:25:00 -0000

+1 Shunsuke,

I should have said this earlier when Deborah asked–merging the 2 makes sense. Earlier it helped a lot to separate out basic characteristics of transport slices from the framework and we could progress in parallel.

Apart from naming, other comments from Adrian are well understood. We did not add too many details because we wanted to see how TEAS assesses this work. But can certainly improve the document once the course of action is agreed upon.

-Kiran

From: Teas <teas-bounces@ietf.org> On Behalf Of Shunsuke Homma
Sent: Wednesday, September 2, 2020 7:42 PM
To: adrian@olddog.co.uk
Cc: TEAS WG <teas@ietf.org>rg>; TEAS WG Chairs <teas-chairs@ietf.org>rg>; Vishnu Pavan Beeram <vishnupavan@gmail.com>om>; BRUNGARD, DEBORAH A <db3546@att.com>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Hi Adrian,

Yes, we can consider to merge definition and framework drafts together if WG judges it is better.

Again, my points are we will need central definition within IETF and pointer to other SDOs.  Even if there are no serious discrepancies among past RFCs and drafts,  nobody can assure that any mismatch won't happen in future work. Another point is the definitions are scattered in several RFCs, and they are described from view points of their own solutions. It will not be friendly for other SDOs.

Please note that DT is creating the definition with referring past studies. Actually, for making this draft, Jie provided many advices from VPN+ aspects. We'll welcome constructive proposals.

Best regards,

Shunsuke


2020年9月3日(木) 4:49 Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>:
Yes,

I would prefer that we define “network slicing” scoped to the IETF and then write a paragraph showing its applicability or mapping to other work in other bodies.  This is the sort of thing we’ve done before for other overlaps with other SDOs and it typically works better than trying to import concepts wholesale.

But I do agree with Shunsuke, that we need some clarity about our terms and their meaning. Without having reviewed the design team’s framework draft yet, it would seem most logical that the framework described and defined the necessary terms. So perhaps the material could all be rolled in together?

It is interesting to note previous RFCs that have referred to network slicing. As Shunsuke notes, these include RFC 8578 and RFC 8453. I also find RFC 8568 (which doesn’t have IETF consensus, but is relevant). And, as we all know, there are quite a lot of drafts all trying to make their own definitions – probably because we lack consensus on a central definition. I did a quick re-read of 8578, 8453, 8568, and draft-king-teas-applicability-actn-slicing and didn’t find any worrying discrepancies. So perhaps, rather than a new definition leaning on other SDOs, what we need is to distil what we already have to produce the IETF definition.

Best,
Adrian

From: BRUNGARD, DEBORAH A <db3546@att.com<mailto:db3546@att.com>>
Sent: 02 September 2020 20:23
To: Shunsuke Homma <s.homma0718@gmail.com<mailto:s.homma0718@gmail.com>>
Cc: adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>; Vishnu Pavan Beeram <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>; TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Hi,
(as individual)

Thanks Shunsuke - if this work is scoped to 3GPP TN, as you say to fill that gap, I can understand the DT’s choice of term. But the definition document and framework imply a broader scope. I thought the DT was scoped to a TE network solution? Was there an analysis why a general solution can not be developed?

Suggest first use the term Network slice for in general and then use transport slice for 3GPP specifics. Not the reverse.

Thanks,
Deborah

Sent from my iPhone

On Sep 2, 2020, at 12:22 PM, Shunsuke Homma <s.homma0718@gmail.com<mailto:s.homma0718@gmail.com>> wrote:

Hi Adrian,

Thank you for your detailed review and valuable feedback.

Regarding the necessity of this work, in my understanding, there are mainly two reasons:
- Unifying understanding about network slicing and scope of design team's work. As you know, network slice have wide meaning and the definition is very ambiguous.  There are many drafts and some RFCs which mention network slicing, but the terms and definitions seem not unified. For example, RFC 8578 describes what network slicing is. Is it completely the same with one defined in RFC 8453? For designing the framework and NBI, we need to be on the same page, and documentation is an approach to do this. At least, we found there is a gap between understanding between DT and WG by this draft, and this was help at that point, isn't it?
- Showing IETF's understanding on network slicing to externals such as other SDOs. Currently, several SDOs are discussing network slicing, but the scopes are based on their ranges of responsibility. For example, the main scope of 3GPP is standardizing specification of radio communication and user plane for mobility management of UE's.  Transport network is out of their scope, and TN slicing is not discussed enough. This work is expected to fill the lack. For realizing E2E network slices which includes not only transport network but other slices and network functions, it is needed to harmonize technologies of several SDOs including IETF, and it would be important to show thought of IETF on network slices. Actually, some SDOs are interested in IETF technologies for network slicing usage, but wondered which documents they should refer to.

If they are achieved, I personally think we can select other ways, for example, as Deborah recommended, moving the essences to other related drafts such as framework or  NBI drafts.

Best regards,

Shunsuke

2020年9月2日(水) 6:36 Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>:
Hi,

I've reviewed this document as part of the adoption poll. My review has
been partially overtaken by threads on the list. Sorry about that, but
it is a lengthy review.

I'd like to start by thanking the design team for tackling the thorny
subject of terminology, and the authors of this draft for pulling
together the various opinions of the team so that we, the working group,
can do the easier task of reviewing the material.

I'm aware that the conditions for WG adoption specifically do not
include that the document should be perfect. But it is important that
the work is clear enough and sufficiently on message that we can work
out what it is for and why we might adopt it.

In my review, below, I raise a number of points that I think are quite
serious and need to be addressed before we can look at the document
properly and decide whether or not to adopt it. These points call into
question what is actually being defined. That is, I am reserving
judgement and not saying "adopt once these issues are fixed."

Above all, I see no benefit to a document that defines a term that seems
to have no particular benefit or use. We know that underlay networks
carry traffic for overlay networks. We know that virtualisation can be
done at different technology levels and that networks can be arranged
hierarchically or stitched together with abstraction and adaptation.
We know that an underlay network can be sliced. What additional benefit
is the definition of the term "Transport Slice" bring? It looks that the
composed end-to-end transport slice is another term for a virtual
network, where at the lowest level a transport slide seems to be a
network slice. This question has to be answered before I can support
adoption.

Finally, I want to say that we often decide to adopt a document on the
understanding that we can fix it up later. But in this case I am very
concerned that adopting this document would be interpreted as the
acceptance of the concept of a transport slice without agreement on
what it is or why we want it. That would surely lead us into a very
difficult place where debate about the document would be hard to
progress.

Thanks,
Adrian

===

I brought up my concern about the use of the term "Transport" around
IETF-106 and it still bothers me. The Abstract says "...the definition
of a slice in the transport networks" but since that term is not common
in the IETF (or rather, it has two very specific meanings neither of
which is intended here) the Abstract fails in its goal "to bring
clarity".

A more accurate Abstract might be:

   This document provides a definition of the term "Transport Slice" for
   use within the IETF and specifically within other IETF documents that
   describe aspects of network slicing.

   The document also describes the characteristics of a transport slice,
   describes related terms and their meanings, and explains how
   transport slices can be used in combination with end to end network
   slices or independent of them.

Section 3 goes on to reference RFC 5921 to give basis for use of the
word "transport". In view of this, it might be interesting to examine
how any network slice can be anything other than a transport slice. That
will lead to a discussion about why this document needs to be separate
from the slicing framework draft. The answers to these questions would
usefully be placed in the document.

---

Section 1

   A number of use cases benefit from establishing network connectivity
   providing transport and assurance of a specific set of network
   resources.

I cannot understand this sentence. What does it mean to "provide
transport"? Transport of what? And, is there a punctuation issue or does
the text mean "transport of network resources"?

What does "assurance of network resources" mean?

---

Section 1


   In this document, as detailed in the subsequent sections,
   we refer to this connectivity and resource commitment as the
   transport slice.

It is unhelpful to include this text here. Is this the normative
definition of a transport slice or just a passing comment?

---

Section 1

   Services that might benefit from the transport
   slices include but not limited to:

Since this assertion is unsubstantiated and expressed as a speculation
it reads like marketing! I suspect we don't need it or the list of
bullets, but maybe you could insert forward references to the sections
that describe the use cases and how a transport slice might be
beneficial in those cases (those would be sections yet to be written).
If, as you seem to imply, the reason for this document is to describe
a term for a concept that has value in certain deployments, I think it
is incumbent on you to describe those cases.

I would recommend throwing out the whole of Section 1 as currently
written and replacing it with an Introduction that expands upon the
Abstract as well as describing what the document will do. You would
still want to add the use case descriptions.

---

Section 1.1

This section launches into a discussion of why we want a transport
slice, but it does so before defining (section 3) what a transport slice
actually is. The later paragraphs of this section are descriptive about
transport slices, but are presumably not normative definitions.

You may find it helpful to re-write this section in abstract terms. What
behaviors are needed from the network? How is the network operated? How
does this compare with "traditional" VPNs? In other words, don't mention
Transport Slice in this section at all, but use this section to
establish the need.

---

Section 1.1

   Transport slice is described as a construct that specifies
   connectivity requirements, emphasizing on assurance of those
   requirements.  Transport slice is unaware of the underlying
   infrastructure connectivity (hence, the term "transport").

Firstly, please avoid using passive voice. I think you are defining (in
this not document) not running a commentary on the fact that someone
somewhere describes "transport slice" in a particular way.

More important, however, is what is going on here. It appears that you
are describing a "transport slice as a service". This would be really
helpful to state up front. That is, you are not describing how the
transport slice is delivered by the network, nor any visibility that
the client has of that network. Hence, "[the] transport slice if unaware
of the underlying infrastructure connectivity".

But this view as a "service" seems at odds with the quote in Section 3
where you state that

   "A transport slice is a logical network topology connecting a number
   of endpoints with a set of shared or dedicated network resources,
   that are used to satisfy specific Service Level Objectives (SLOs)".

...If the transport slice is unaware of the underlying infrastructure
connectivity, how can the slice be a set of shared or dedicated network
resources?

I don't understand how you get to 'hence the term "transport"' from the
lack of awareness of underlying infrastructure.

---

Section 1.1

Relation to Enhanced VPN. As you know, VPN+ is adopted TEAS work. I see
that you have an Informative reference to draft-ietf-teas-enhanced-vpn,
but I also see that you never make use of this reference until the
appendix. I think you need to discuss VPN+ in Section 1.1 to provide
sufficient contrast and to explain why you need your new concept.

---

Section 1.1.

The final paragraph in this section says "Transport slices relate to a
more general topic of network slicing." It is hard to evaluate this
without a more detailed description of network slicing than is provided
in the single next sentence. In particular, we need to understand why
you need the term "transport slice" instead of simply "network slice."

I'd say you could go one of three ways:
1. Provide a more detailed description of network slicing in this
   document
2. Make a normative reference to some other document that defines a
   network slice
3. Remove this paragraph and clean the document so that the focus is
   entirely on the definition of "transport slice" and no mention is
   made of "network slicing".

---

Section 2

Trying to not nit-pick this section (it can be worked on later), but
the terms SLI, SLO, and SLA seem to be fairly important within this
document. These three brief paragraphs are not very much information
for such key terms.

You probably either need a section to go into more details of these
definitions or you need external references to where these concepts are
defined.

---

Section 3

Why is the definition of a transport slice in quotes? Is it a definition
taken from somewhere else?

---

Section 3

   "Slice" refers to a set of characteristics that separate
   one type of user-traffic from other types.

Is "separation" a different term from "isolation"? They are often used
as synonyms. If you mean them to be the same, it may help to use only
one term in this document, but if you mean them to be different, it may
help to provide some statement of contrast.

---

Section 4

   The following subsections describe the characteristics needed for
   support of transport slices.

"Characteristics" of what? "Needed" by whom?

---

Section 4.1 (and elsewhere)

The use of the term "end user" may not convey the message you intend.
(Or maybe it does!) An end user is usually conceived to be a person or
machine that it the ultimate source or sink of packet data. Do you
define that the consumer/customer/client of a transport slice is such an
individual person/component? Or is a transport slice provided as a
service to support another network (like a pseudowire, VLAN, VPN, etc.)?

If you plan to continue using "end user" you might include it in Section
5.1.

---

Section 4.1

   If for
   example the range of latencies a network can provide is 50ms-100ms,
   then this would be the range of values the end user should be able to
   request, it would be as low as 50ms or as high as 100ms or anything
   in between.

Is this just a bad example, or is there something I am not seeing?
Surely no one request a latency. They may indicate that they can
tolerate a latency: that is, they may request an upper bound to the
latency they will receive. If so, just because the network "can provide"
latency of 50-100ms, does not restrict the user from giving a higher
value.

There is also some question of who asks and who provides. As you have it
phrased, the network must tell the end user what is available, and the
end user can then select. Is that really how it works? Doesn't latency
in a network depend on many factors (including where the sources and
destinations are, and what other service parameters are being
delivered)? If so, wouldn't the end user make a request with a set of
SLIs and the network would respond yes/no/negotiate?

---

Section 4.1.1

I'm not sure what this paragraph is doing here. If it were illustrative
it might be acceptable but currently it has:

   This document defines a minimal set of SLOs and later systems or
   standards could extend this set and define more SLOs.  For example,
   we included Guaranteed bandwidth which is the minimum requested
   bandwidth for the transport slice.  The later standard might define
   other SLOs related to bandwidth if needed.

This document is not positioned as Standards Track, so this text looks
very out of place.

I do understand that is a transport slice is to be viewed as a service
then it is important to qualify the service parameters. Is this the
same list of service requirements as we find in section 3 of
draft-ietf-teas-enhanced-vpn? Are any differences the clue to
understanding the difference between an enhanced VPN and a transport
slice?

---

Section 4.1.1

   o  Availability: is defined as the ratio of uptime to
      total_time(uptime+downtime), where uptime is the time the
      transport slice is available in accordance with the SLOs
      associated with it.

There is some circuitous definition here since an SLO is "A target value
or range of values for a service level that is measured by an SLI."
You also need to indicate what you mean by "the transport slice is
available"? Does the disconnection of one TSE from a slice mean the
slice is not available, or just downgraded?

(This may be a comment too far! It is probably off in the details that
the WG might discuss if/when the document is adopted.)

---

Section 4.1.1

Security : really?

draft-ietf-teas-enhanced-vpn has:

   While an enhanced VPN service may be sold as offering encryption and
   other security features as part of the service, customers would be
   well advised to take responsibility for their own security
   requirements themselves possibly by encrypting traffic before
   handing it off to the service provider.

Do you really believe that "encrypted connectivity" is likely to be an
SLI of a transport slice?

---

Section 4.1.2

   With these objectives incorporated, a customer sees transport slice
   as a dedicated network for its exclusive use.

Do you mean like a VPN? A sort of VPN with enhanced attributes? Like a
sort of enhanced VPN?

---

Sections 4.2 and 4.3

I didn't really understand how/why we need another decomposition of
network services, network virtualisation, and hierarchical networks
that is essentially functionally the same as many of the ones we have
worked n before but which has a different set of names for things. Is
there really a big difference between this and work we have done before?

---

Section 5.1

I'm a bit confused by your statement (in the TSC definition) that there
are different types of orchestrators and different types of TSC. There
is no explanation of this and the definitions appear to be generic.

If it is OK to have "slice operator for short" why is it not OK to
have "slice" for short?

---

The only mention of the "e2e network slice orchestrator" is in Section
5.2.

This seems to be related to some text in 5.1

      A user may either directly manage its service
      by interfacing with the transport slice controller or indirectly
      through an orchestrator.

   Orchestrator:  An orchestrator is an entity that composes different
      services, resource and network requirements.  It interfaces with
      the transport slice controllers.

...which is slightly in conflict with text in 5.

   A transport slice is requested from an entity (such as an
   orchestrator or a system-wide controller) performing broader service
   or application specific functions.

There is probably some unspoken meaning to these differences, but it is
hard to guess.

---

I consider the distinction in Section 6 between "end-to-end slice",
"other slice", and "transport slice" to be somewhat bogus. The customer
of an end-to-end slice might be directly using the "transport network".
The IETF only deals with IETF technologies.

---

Section 7 will need to filled in at some stage. At the least, you have a
suggestion that security is an SLI. But probably, there are plenty of
security and privacy concerns with all aspects of network slicing.

From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> On Behalf Of Vishnu Pavan Beeram
Sent: 19 August 2020 16:50
To: TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Cc: TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>
Subject: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

All,

This is start of a *three* week poll on making
draft-nsdt-teas-transport-slice-definition-03 a TEAS working group document.
Please send email to the list indicating "yes/support" or "no/do not
support". If indicating no, please state your reservations with the
document. If yes, please also feel free to provide comments you'd
like to see addressed once the document is a WG document.

The poll ends September 9th (extra week to account for vacation season).

Thanks,
Pavan and Lou
_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_teas%26d%3DDwMFaQ%26c%3DLFYZ-o9_HUMeMTSQicvjIg%26r%3D6UhGpW9lwi9dM7jYlxXD8w%26m%3DANvgppm_Or8JLdWKnhhybVE2VrvWl5eueVL9E73GMAs%26s%3DanWmC380QTyh7ApoymAicfwwM6uI2gSdUa7olRHB3BM%26e%3D&data=02%7C01%7Ckiranm%40futurewei.com%7C29b43cea1c13488cb4d908d84fb31238%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346977829137026&sdata=4LZigRQMtorohWd0t69J9TVaAX%2BgGlP8ck6zVQJg8Wg%3D&reserved=0>
_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=ANvgppm_Or8JLdWKnhhybVE2VrvWl5eueVL9E73GMAs&s=anWmC380QTyh7ApoymAicfwwM6uI2gSdUa7olRHB3BM&e=<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_teas%26d%3DDwICAg%26c%3DLFYZ-o9_HUMeMTSQicvjIg%26r%3D6UhGpW9lwi9dM7jYlxXD8w%26m%3DANvgppm_Or8JLdWKnhhybVE2VrvWl5eueVL9E73GMAs%26s%3DanWmC380QTyh7ApoymAicfwwM6uI2gSdUa7olRHB3BM%26e%3D&data=02%7C01%7Ckiranm%40futurewei.com%7C29b43cea1c13488cb4d908d84fb31238%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346977829137026&sdata=Bzvjqq0j9ZQx7ddH7hbxBYrEMEtmpnbQRJI6JvGi08Q%3D&reserved=0>