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

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 1 Sep 2020 22:36:20 +0100

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 <[email-masked]> On Behalf Of Vishnu Pavan Beeram
Sent: 19 August 2020 16:50
To: TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>
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

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 2 Sep 2020 15:14:32 +0000 (UTC)

Hi,
I agree with Deborah and Adrian that at least some terms defined in this work could have been borrowed from other TEAS WG work.For example, I may have missed some discussions, but I still do not see much difference between transport slice as defined and an abstract network topology defined/configured by a client and provided as a service by the server as defined in network topology model family. If we could agree that the two are at least close cousins, the life would get much simpler IMHO.
Igor

    On Tuesday, September 1, 2020, 5:36:39 PM EDT, Adrian Farrel <[email-masked]> wrote:  
 
 <!--#yiv2325318554 _filtered {} _filtered {}#yiv2325318554 #yiv2325318554 p.yiv2325318554MsoNormal, #yiv2325318554 li.yiv2325318554MsoNormal, #yiv2325318554 div.yiv2325318554MsoNormal {margin:0cm;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv2325318554 span.yiv2325318554EmailStyle18 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv2325318554 .yiv2325318554MsoChpDefault {font-family:"Calibri", sans-serif;} _filtered {}#yiv2325318554 div.yiv2325318554WordSection1 {}-->
Hi,

it is a lengthy review.

adoption.

progress.

Thanks,

Adrian

===

clarity".

---

Section 1

   resources.

---

Section 1

   transport slice.

---

Section 1

---

Section 1.1

establish the need.

---

Section 1.1

where you state that 

resources?

---

Section 1.1

---

Section 1.1.

   document

   network slice

---

Section 2

for such key terms. 

defined.

---

Section 3

---

Section 3

---

Section 4

---

5.1.

---

Section 4.1

   If for

   in between.

value.

---

Section 4.1.1

very out of place.

slice?

---

Section 4.1.1

      associated with it.

---

Section 4.1.1

Security : really?

---

Section 4.1.2

sort of enhanced VPN?

---

Sections 4.2 and 4.3

---

Section 5.1

have "slice" for short?

---

5.2. 

      through an orchestrator.

hard to guess.

---

---

All,

Thanks,
Pavan and Lou
_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Shunsuke Homma <[email-masked]>
Date: Thu, 3 Sep 2020 01:21:43 +0900

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 <[email-masked]>:

> *From:* Teas <[email-masked]> *On Behalf Of *Vishnu Pavan Beeram
> *Sent:* 19 August 2020 16:50
> *To:* TEAS WG <[email-masked]>
> *Cc:* TEAS WG Chairs <[email-masked]>
> *Subject:* [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition
>
>
>
> All,
>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 2 Sep 2020 19:23:04 +0000

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 <[email-masked]> wrote:

Hi Adrian,

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 <[email-masked]<mailto:[email-masked]>>:
Hi,

Thanks,
Adrian

===

---

Section 1

---

Section 1

---

Section 1

---

Section 1.1

---

Section 1.1

---

Section 1.1

---

Section 1.1.

---

Section 2

---

Section 3

---

Section 3

---

Section 4

---

---

Section 4.1

   If for

---

Section 4.1.1

---

Section 4.1.1

---

Section 4.1.1

Security : really?

---

Section 4.1.2

---

Sections 4.2 and 4.3

---

Section 5.1

---

---

---

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

All,

Thanks,
Pavan and Lou
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=ANvgppm_Or8JLdWKnhhybVE2VrvWl5eueVL9E73GMAs&s=anWmC380QTyh7ApoymAicfwwM6uI2gSdUa7olRHB3BM&e=>
_______________________________________________
Teas mailing list
[email-masked]
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=

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 2 Sep 2020 20:49:43 +0100

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 <[email-masked]> 
Sent: 02 September 2020 20:23
To: Shunsuke Homma <[email-masked]>
Cc: [email-masked]; TEAS WG Chairs <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Hi, 

(as individual)

Thanks,

Deborah

Sent from my iPhone

Hi Adrian,

Best regards,

Shunsuke

2020年9月2日(水) 6:36 Adrian Farrel <[email-masked] <mailto:[email-masked]> >:

Hi,

it is a lengthy review.

adoption.

progress.

Thanks,

Adrian

===

clarity".

---

Section 1

   resources.

---

Section 1

   transport slice.

---

Section 1

---

Section 1.1

establish the need.

---

Section 1.1

where you state that 

resources?

---

Section 1.1

---

Section 1.1.

   document

   network slice

---

Section 2

for such key terms. 

defined.

---

Section 3

---

Section 3

---

Section 4

---

5.1.

---

Section 4.1

   If for

   in between.

value.

---

Section 4.1.1

very out of place.

slice?

---

Section 4.1.1

      associated with it.

---

Section 4.1.1

Security : really?

---

Section 4.1.2

sort of enhanced VPN?

---

Sections 4.2 and 4.3

---

Section 5.1

have "slice" for short?

---

5.2. 

      through an orchestrator.

hard to guess.

---

---

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

All,

Thanks,
Pavan and Lou

_______________________________________________
Teas mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/teas <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=ANvgppm_Or8JLdWKnhhybVE2VrvWl5eueVL9E73GMAs&s=anWmC380QTyh7ApoymAicfwwM6uI2gSdUa7olRHB3BM&e=>

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 2 Sep 2020 17:31:01 -0700

If this is the consensus - I think noone is particularly religious about the name?

Regards,
Jeff

> On Sep 2, 2020, at 12:28, BRUNGARD, DEBORAH A <[email-masked]> wrote:
> 
>  Hi,
> (as individual)
>

---

From: Shunsuke Homma <[email-masked]>
Date: Thu, 3 Sep 2020 10:43:31 +0900

Hi Deborah,

It should be applicable to 3GPP TN, but,  as other members mentioned, the
scope is  wider than 3GPP TN. The choice of term is for avoiding
misunderstandings that IETF designing network slicing for only 3GPP TN. At
least, I don't have strong will on wording for terms, and ok to use
transport network slice instead of transport slice.  (Actually, "transport
network slice" may be better from a perspective of aligning with terms of
other SDOs.)

In my understanding, the problem is that network slicing potentially has
wide meaning and many factors, including how to deploy data plane, control
and management of them, interwork/orchestration with other systems such as
5GS or NFV platform, etc.  This easily brings derailing of discussion, and
thus DT focuses on very limited scope, in other words, slicing on transport
networks.

I agree with that transport (network) slice is a type of network slice and
not the reverse. Do you mean we need to add the text describing general
meanings of network slicing and position of transport (network) slice with
it?

Best regards,

Shunsuke

2020年9月3日(木) 4:28 BRUNGARD, DEBORAH A <[email-masked]>:

> 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
>
>> *Subject:* [Teas] WG adoption -
>> draft-nsdt-teas-transport-slice-definition
>>
>>
>>
>> All,
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=ANvgppm_Or8JLdWKnhhybVE2VrvWl5eueVL9E73GMAs&s=anWmC380QTyh7ApoymAicfwwM6uI2gSdUa7olRHB3BM&e=>
>>

---

From: Shunsuke Homma <[email-masked]>
Date: Thu, 3 Sep 2020 11:41:51 +0900

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 <[email-masked]>:

> 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 <[email-masked]>
> *Sent:* 02 September 2020 20:23
> *To:* Shunsuke Homma <[email-masked]>
> *Cc:* [email-masked]; TEAS WG Chairs <[email-masked]>; Vishnu
> Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>
> *Subject:* Re: [Teas] WG adoption -

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 3 Sep 2020 03:40:11 +0000

Hi Shunsuke and all,

In 3GPP and other SDOs, an end-to-end network slice consists of 3 major types of network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN), the network slicing of transport network is out of the scope of 3GPP and is considered the job of IETF. Thus from the end-to-end network slicing perspective, we in IETF need to work to deliver the transport (network) slice. And I agree with Shunsuke that transport network slice may be better to align with other SDOs.

On the other hand, the “network slicing” mechanism provided by IETF may be used in a wider scope than end-to-end network slicing of 5G, thus I understand Deborah’s concern about whether we need to have a more generic term. While the term network slice already have its meaning and scope widely accepted in the industry, I’m not sure whether it could be used directly for an IETF solution. Perhaps we could either add some attributives in front of “network slice” to show it is scoped to IETF, or choose another term which is more IETF specific, and describes its applicability to transport network slice in the context of end-to-end network slicing. Note the second approach was chosen when enhanced VPN (VPN+) framework was developed.

Best regards,
Jie

From: Teas [mailto:[email-masked]] On Behalf Of Shunsuke Homma
Sent: Thursday, September 3, 2020 9:44 AM
To: BRUNGARD, DEBORAH A <[email-masked]>
Cc: [email-masked]; TEAS WG Chairs <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Hi Deborah,

It should be applicable to 3GPP TN, but,  as other members mentioned, the scope is  wider than 3GPP TN. The choice of term is for avoiding misunderstandings that IETF designing network slicing for only 3GPP TN. At least, I don't have strong will on wording for terms, and ok to use transport network slice instead of transport slice.  (Actually, "transport network slice" may be better from a perspective of aligning with terms of other SDOs.)

In my understanding, the problem is that network slicing potentially has wide meaning and many factors, including how to deploy data plane, control and management of them, interwork/orchestration with other systems such as 5GS or NFV platform, etc.  This easily brings derailing of discussion, and thus DT focuses on very limited scope, in other words, slicing on transport networks.

I agree with that transport (network) slice is a type of network slice and not the reverse. Do you mean we need to add the text describing general meanings of network slicing and position of transport (network) slice with it?

Best regards,

Shunsuke

2020年9月3日(木) 4:28 BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>:
Hi,
(as individual)

Thanks,
Deborah

Sent from my iPhone

On Sep 2, 2020, at 12:22 PM, Shunsuke Homma <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adrian,

Best regards,

Shunsuke

Thanks,
Adrian

===

---

Section 1

---

Section 1

---

Section 1

---

Section 1.1

---

Section 1.1

---

Section 1.1

---

Section 1.1.

---

Section 2

---

Section 3

---

Section 3

---

Section 4

---

---

Section 4.1

   If for

---

Section 4.1.1

---

Section 4.1.1

---

Section 4.1.1

Security : really?

---

Section 4.1.2

---

Sections 4.2 and 4.3

---

Section 5.1

---

---

---

All,

Thanks,
Pavan and Lou

---

From: Kiran Makhijani <[email-masked]>
Date: Thu, 3 Sep 2020 05:24:45 +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 <[email-masked]> On Behalf Of Shunsuke Homma
Sent: Wednesday, September 2, 2020 7:42 PM
To: [email-masked]
Cc: TEAS WG <[email-masked]>; TEAS WG Chairs <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>>:
Yes,

Best,
Adrian

From: BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>
Sent: 02 September 2020 20:23
To: Shunsuke Homma <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Hi,
(as individual)

Thanks,
Deborah

Sent from my iPhone

Hi Adrian,

Best regards,

Shunsuke

Thanks,
Adrian

===

---

Section 1

---

Section 1

---

Section 1

---

Section 1.1

---

Section 1.1

---

Section 1.1

---

Section 1.1.

---

Section 2

---

Section 3

---

Section 3

---

Section 4

---

---

Section 4.1

   If for

---

Section 4.1.1

---

Section 4.1.1

---

Section 4.1.1

Security : really?

---

Section 4.1.2

---

Sections 4.2 and 4.3

---

Section 5.1

---

---

---

All,

Thanks,
Pavan and Lou
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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>

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 3 Sep 2020 14:35:01 +0000

Hi Deborah,
                >>>>> Why are you excluding RAN? RAW is already doing IP solutions, SG15 has RAN transport solutions for IP. IP is already in the RAN.

We are not excluding the RAN. This is the explanation.
RAN NEs has two logical components, Radio and Transport. When I mentioned in my previous email that a “5G network slice has RAN Slice, Transport Slice and Core slice, I refer to the Radio portion of the RAN.
The transport portion of the RAN can be consider as part of the transport slice. This is clearly pointed out in the draft with definition of Transport Slice Endpoint (TSE). Please see picture below where for example the TSE could be the endpoint inside the Transport portion of the RAN.

Hi Igor,
                >>>> I agree with Deborah and Adrian that at least some terms defined in this work could have been borrowed from other TEAS WG work.

You have a valid point of using the exiting IETF terms as much as we can. And this was the intention of the draft authors.
Having said that, It is important to consider that the operator can realize a “Transport Slice” in a TE or NON-TE network. They can even realize a transport slice in NON-IP/MPLS network (like PON).
The point is that the  transport slice is not necessarily associated to a TE network.
As pointed out in the draft, the realize of a transport slice can be in  TE network and any IETF models/works can be utilized for realization.

Cheers,

Reza

From: Teas <[email-masked]> on behalf of Igor Bryskin <i_bryskin=[email-masked]>
Date: Wednesday, September 2, 2020 at 11:14 AM
To: 'Vishnu Pavan Beeram' <[email-masked]>, 'TEAS WG' <[email-masked]>, Adrian Farrel <[email-masked]>
Cc: 'TEAS WG Chairs' <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Hi,

I agree with Deborah and Adrian that at least some terms defined in this work could have been borrowed from other TEAS WG work.
For example, I may have missed some discussions, but I still do not see much difference between transport slice as defined and an abstract network topology defined/configured by a client and provided as a service by the server as defined in network topology model family. If we could agree that the two are at least close cousins, the life would get much simpler IMHO.

Igor

Hi,

it is a lengthy review.

adoption.

progress.

Thanks,

Adrian

===

clarity".

---

Section 1

   resources.

---

Section 1

   transport slice.

---

Section 1

---

Section 1.1

establish the need.

---

Section 1.1

where you state that

resources?

---

Section 1.1

---

Section 1.1.

   document

   network slice

---

Section 2

for such key terms.

defined.

---

Section 3

---

Section 3

---

Section 4

---

5.1.

---

Section 4.1

   If for

   in between.

value.

---

Section 4.1.1

very out of place.

slice?

---

Section 4.1.1

      associated with it.

---

Section 4.1.1

Security : really?

---

Section 4.1.2

sort of enhanced VPN?

---

Sections 4.2 and 4.3

---

Section 5.1

have "slice" for short?

---

5.2.

      through an orchestrator.

hard to guess.

---

---

All,

Thanks,
Pavan and Lou

---

From: Eric Gray <[email-masked]>
Date: Thu, 3 Sep 2020 11:19:46 -0400

Reza,

It’s tempting to say that I agree with whatever it is that you said below.  :-)

However, you’ve dived directly into a details-based explanation - where it is possible (or even quite likely) that your details-based explanation has a Ouroboros-like circularity that depends on how you’ve defined the details.

Instead, I suggest summarizing the process by which we decided to compromise in using “transport slice” (or “transport slicing”).

I personally thought (and - to some extent - still think) we should be using “transport network slices” - for at least the case where we are using packet-based (or other IETF supported methodologies for) connectivity services to support RAN and Packet Core applications in mobile networks -  mostly to be consistent with 3GPP terminology.  That was at least my starting position.

	But we (the IETF) are already (and arguably have been for some time) using the phrase “network slicing” to refer to mostly technology (and layer) agnostic network virtualization.  That obviously applies very nicely in cases where we are talking only of IETF defined/maintained technologies.  For example: in DC networking.

	But using “network slicing” in the mobile networking application clashes badly with other uses that apply in the same space.  For example: 3GPP defines "network slices" as originating on a UE, and terminating on a UPF (and vice-versa) and these “network slices” have to be carried (i.e. - "transported”) over the slices provided for that purpose by what 3GPP consistently refers to as a “Transport Network.”  It is possible that 3GPP (or mobile operators) may extend usage to include “network slices” that extend from one or more UEs to one or more other UEs, through one or more (essentially concatenated) UPFs - but dealing with this case is not essential (or arguably even useful) to understanding requirements of the mobile network application in general. 

	On top of that, in the mobile networking application, there is no presumption that a “transport network” will be anything that the IETF defines or maintains.  Microwave technology is - for instance - a technology that many mobile operators go to first (or at least most often) in providing “transport” for a mobile operator’s RAN traffic (including network slices), and obviously these services have previously been (and will for some time be) provided using some form of synchronous optical networking (which is a driver for some of the interest in TDM-like “transport services”).

	So there are multiple dimensions to this naming choice, and I don’t think anyone will be completely satisfied with any name we select.

	To the extent possible, we should try to define a northbound interface generic enough to support any technology - including largely those that are defined/maintained by the IETF - while trying to avoid naming ambiguity to the extent possible.  And we should try to include sufficient flexibility to support “carrying” (i.e. - “transport”) of "network slices" as we have defined them in the IETF.

	We cannot actually use the phrase “network slices” (or “network slicing”) for all of the cases, as that will be far too ambiguous and will lead to the need to “qualify” every usage to remove the inherent ambiguity we would be creating. 

	Hence the compromise of using “transport slice.”  I don’t like it, and I am not alone in that - but that is pretty much the definition of what a “compromise” is.

—
Eric

> On Sep 3, 2020, at 10:35 AM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]> wrote:
> 
> Hi Deborah,
> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>_______________________________________________
> Teas mailing list
> [email-masked]

---

From: John E Drake <[email-masked]>
Date: Thu, 3 Sep 2020 15:56:13 +0000

Hi,

This extended discussion has convinced me that we need to use terminology that is consistent with the existing IETF terminology, of which we have plenty in this area.  E.g., we have an entire area devoted to transport and it has nothing to do with network slicing, and transport networks are an ITU thing.

I think it is up to an application that uses IETF network slices as components to indicate where in its design these IETF network slices fit.  I.e., IETF network slices are being designed for use by a multiplicity of applications and trying to make our terminology congruent with this one application is problematic.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Eric Gray
Sent: Thursday, September 3, 2020 11:20 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Cc: BRUNGARD, DEBORAH A <[email-masked]>; TEAS WG Chairs <[email-masked]>; TEAS WG <[email-masked]>; Igor Bryskin <i_bryskin=[email-masked]>; [email-masked] <[email-masked]>; Adrian Farrel <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

[External Email. Be cautious of content]

Reza,

It's tempting to say that I agree with whatever it is that you said below.  :-)

However, you've dived directly into a details-based explanation - where it is possible (or even quite likely) that your details-based explanation has a Ouroboros-like circularity that depends on how you've defined the details.

Instead, I suggest summarizing the process by which we decided to compromise in using "transport slice" (or "transport slicing").

I personally thought (and - to some extent - still think) we should be using "transport network slices" - for at least the case where we are using packet-based (or other IETF supported methodologies for) connectivity services to support RAN and Packet Core applications in mobile networks -  mostly to be consistent with 3GPP terminology.  That was at least my starting position.

But we (the IETF) are already (and arguably have been for some time) using the phrase "network slicing" to refer to mostly technology (and layer) agnostic network virtualization.  That obviously applies very nicely in cases where we are talking only of IETF defined/maintained technologies.  For example: in DC networking.

But using "network slicing" in the mobile networking application clashes badly with other uses that apply in the same space.  For example: 3GPP defines "network slices" as originating on a UE, and terminating on a UPF (and vice-versa) and these "network slices" have to be carried (i.e. - "transported") over the slices provided for that purpose by what 3GPP consistently refers to as a "Transport Network."  It is possible that 3GPP (or mobile operators) may extend usage to include "network slices" that extend from one or more UEs to one or more other UEs, through one or more (essentially concatenated) UPFs - but dealing with this case is not essential (or arguably even useful) to understanding requirements of the mobile network application in general.

On top of that, in the mobile networking application, there is no presumption that a "transport network" will be anything that the IETF defines or maintains.  Microwave technology is - for instance - a technology that many mobile operators go to first (or at least most often) in providing "transport" for a mobile operator's RAN traffic (including network slices), and obviously these services have previously been (and will for some time be) provided using some form of synchronous optical networking (which is a driver for some of the interest in TDM-like "transport services").

So there are multiple dimensions to this naming choice, and I don't think anyone will be completely satisfied with any name we select.

To the extent possible, we should try to define a northbound interface generic enough to support any technology - including largely those that are defined/maintained by the IETF - while trying to avoid naming ambiguity to the extent possible.  And we should try to include sufficient flexibility to support "carrying" (i.e. - "transport") of "network slices" as we have defined them in the IETF.

We cannot actually use the phrase "network slices" (or "network slicing") for all of the cases, as that will be far too ambiguous and will lead to the need to "qualify" every usage to remove the inherent ambiguity we would be creating.

Hence the compromise of using "transport slice."  I don't like it, and I am not alone in that - but that is pretty much the definition of what a "compromise" is.

-
Eric

On Sep 3, 2020, at 10:35 AM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Deborah,

We are not excluding the RAN. This is the explanation.
RAN NEs has two logical components, Radio and Transport. When I mentioned in my previous email that a "5G network slice has RAN Slice, Transport Slice and Core slice, I refer to the Radio portion of the RAN.
The transport portion of the RAN can be consider as part of the transport slice. This is clearly pointed out in the draft with definition of Transport Slice Endpoint (TSE). Please see picture below where for example the TSE could be the endpoint inside the Transport portion of the RAN.

Hi Igor,

You have a valid point of using the exiting IETF terms as much as we can. And this was the intention of the draft authors.
Having said that, It is important to consider that the operator can realize a "Transport Slice" in a TE or NON-TE network. They can even realize a transport slice in NON-IP/MPLS network (like PON).
The point is that the  transport slice is not necessarily associated to a TE network.
As pointed out in the draft, the realize of a transport slice can be in  TE network and any IETF models/works can be utilized for realization.

Cheers,

Reza

From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Igor Bryskin <i_bryskin=[email-masked]<mailto:i_bryskin=[email-masked]>>
Date: Wednesday, September 2, 2020 at 11:14 AM
To: 'Vishnu Pavan Beeram' <[email-masked]<mailto:[email-masked]>>, 'TEAS WG' <[email-masked]<mailto:[email-masked]>>, Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: 'TEAS WG Chairs' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Hi,

Igor

On Tuesday, September 1, 2020, 5:36:39 PM EDT, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

it is a lengthy review.

adoption.

progress.

Thanks,

Adrian

===

clarity".

---

Section 1

   resources.

---

Section 1

   transport slice.

---

Section 1

---

Section 1.1

establish the need.

---

Section 1.1

where you state that

resources?

---

Section 1.1

---

Section 1.1.

   document

   network slice

---

Section 2

for such key terms.

defined.

---

Section 3

---

Section 3

---

Section 4

---

5.1.

---

Section 4.1

   If for

   in between.

value.

---

Section 4.1.1

very out of place.

slice?

---

Section 4.1.1

      associated with it.

---

Section 4.1.1

Security : really?

---

Section 4.1.2

sort of enhanced VPN?

---

Sections 4.2 and 4.3

---

Section 5.1

have "slice" for short?

---

5.2.

      through an orchestrator.

hard to guess.

---

---

All,

Thanks,
Pavan and Lou
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!QWlAbeCX_8M_Za6ta5syn3QKS2IPDaq-6eb4LcLbhN9o_PfeU28zqh4cqpRH7wU$>
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!QWlAbeCX_8M_Za6ta5syn3QKS2IPDaq-6eb4LcLbhN9o_PfeU28zqh4cqpRH7wU$>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Sep 2020 18:13:18 +0100

Thank you Eric for what is the clearest email to date on how we got to where we are. It helps me understand a lot better the questions we should be asking. I’m sure many of these questions were debated at length in the design team, but “we thought about it and came to a conclusion” is never the strongest argument to present to a working group, so we may have to unpack some of the compromises that were made in order to bring everyone along with the ideas. (I also hope that the compromise wasn’t reached on the basis of most of the team saying they didn’t like it and a few people digging in. But that will come out if the members of the team speak up on the list to say what they do or don’t like.)

I appreciate the desire to be consistent with the terminology used in other bodies. There is no reason not to do that where that terminology is clear and where it is not in conflict with terminology already in use in the IETF. On the other hand, where the IETF is already using terminology we have to be more careful.

It looks to me that the 3GPP has some nice core definitions in TS 23.501 (I’m looking at v16.2.0). For example:

Network Slice: A logical network that provides specific network capabilities and network characteristics.

That definition looks pretty much consistent with every definition I have seen in use in the IETF.

The problem seems to come as we move from the abstract/generic to the specific. I believe it will always be the case that the concept of “transport” is a relative term. Any network that can carry traffic for an application or another network is (by definition of “transport” meaning to carry) a transport network. If you build IP networks then any sub-IP network is a transport network. If you build radio networks then you may see an IP network as a transport network. If you run IP over radio, then you probably see the radio network as transport.

As a concept, then, “transport” adds value when it describes the relationship between network layers. 

But I think we find that the 3GPP definition of “network slice” embraces the wider and more general concept that we also need. That is, we need to describe the creation and management of logical networks that provides specific network capabilities and network characteristics. I don’t think we want to be limited to when those logical networks are specifically intended to carry traffic for client networks that are themselves network slices. 

If, as some people seem to argue, there is a need to constrain the description to be limited to just a specific use case of a network slice, then I suggest that is exactly what should be done. That is: define a network slice and get comfortable with that definition; specify the use case; describe how the generic network slice is used in that case; set out any limitations or additions needed to the generic definition.

Two other small points:

*	Igor noted how ACTN was renamed from “transport” to “TE” to ensure it was applicable to all network types for which the IETF (and specifically TEAS) could apply the technology. I agreed with that change and I think it applies here, too.
*	There may be a desire to apply the concept of network slicing to non-TE networks (but still considering IETF technologies). I would be intrigued to understand how that works without some form of ‘reservation’ of network resources and ‘steering’ of traffic. It may be that:

*	The advocates of this idea should read (and contribute to) draft-ietf-teas-rfc3272bis
*	We should all think hard about where such work should be done given the scope of TEAS

Best,

Adrian

From: Eric Gray <[email-masked]> 
Sent: 03 September 2020 16:20
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Cc: Igor Bryskin <i_bryskin=[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>; Adrian Farrel <[email-masked]>; TEAS WG Chairs <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Reza,

—

Eric

On Sep 3, 2020, at 10:35 AM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> > wrote:

Hi Deborah,

 

Hi Igor,

 

Cheers,

Reza

From: Teas <[email-masked] <mailto:[email-masked]> > on behalf of Igor Bryskin <i_bryskin=[email-masked] <mailto:i_bryskin=[email-masked]> >
Date: Wednesday, September 2, 2020 at 11:14 AM
To: 'Vishnu Pavan Beeram' <[email-masked] <mailto:[email-masked]> >, 'TEAS WG' <[email-masked] <mailto:[email-masked]> >, Adrian Farrel <[email-masked] <mailto:[email-masked]> >
Cc: 'TEAS WG Chairs' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Hi,

Igor

On Tuesday, September 1, 2020, 5:36:39 PM EDT, Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

it is a lengthy review.

adoption.

progress.

Thanks,

Adrian

===

clarity".

---

Section 1

   resources.

---

Section 1

   transport slice.

---

Section 1

---

Section 1.1

establish the need.

---

Section 1.1

where you state that

resources?

---

Section 1.1

---

Section 1.1.

   document

   network slice

---

Section 2

for such key terms.

defined.

---

Section 3

---

Section 3

---

Section 4

---

5.1.

---

Section 4.1

   If for

   in between.

value.

---

Section 4.1.1

very out of place.

slice?

---

Section 4.1.1

      associated with it.

---

Section 4.1.1

Security : really?

---

Section 4.1.2

sort of enhanced VPN?

---

Sections 4.2 and 4.3

---

Section 5.1

have "slice" for short?

---

5.2.

      through an orchestrator.

hard to guess.

---

---

All,

Thanks,
Pavan and Lou

---

From: Kiran Makhijani <[email-masked]>
Date: Fri, 4 Sep 2020 01:44:38 +0000

Hi Adrian,
If I understood your email, I think you will be fine with the term network slice.

But then, network slice is generic, defined elsewhere so we may have to inherit its other terminology as well (for example it has a notion of subnet slices, subnetworks, how there are different means of  connecting then in shared and non-shared basis, and so on). Where as I would like the scope to be more specific.

A user asks for a part of network to transport its traffic with  certain characteristics - hence the term transport (network) slice.

Our scope is to specify connectivity or transmission  characteristics and what are the things needed to support requested SLOs. For generic, wider approaches, there are already many standard and informational documents in TEAS.

RFC 5921 definition of transport network seemed very appropriate then and is still the right reference in my mind.  Because all we have done is inherit a standard IETF definition of term transport and built slice aspect on top of it.
We were aware of ACTN, enhanced VPN, and several data models to fulfill many of the needs for
transport slices. But at least I wanted start from an independent view from the perspective of a
user of slice. This was one of the reasons to not directly pull content from those documents to the definitions draft which is implementation independent. But  later describe them as mappings in framework.

I really don’t know what will be the outcome of this discussion and can not justify more than what’s already been said. But it looks like industry is quite comfortable with using the term transport. I wont be surprised if this discussion surfaces again.
-Kiran

From: Teas <[email-masked]> On Behalf Of Adrian Farrel
Sent: Thursday, September 3, 2020 10:13 AM
To: 'Eric Gray' <[email-masked]>; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>
Cc: 'Igor Bryskin' <i_bryskin=[email-masked]>; 'TEAS WG Chairs' <[email-masked]>; 'Vishnu Pavan Beeram' <[email-masked]>; 'TEAS WG' <[email-masked]>; 'BRUNGARD, DEBORAH A' <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Two other small points:

Best,
Adrian

From: Eric Gray <[email-masked]<mailto:[email-masked]>>
Sent: 03 September 2020 16:20
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: Igor Bryskin <i_bryskin=[email-masked]<mailto:i_bryskin=[email-masked]>>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Adrian Farrel <[email-masked]<mailto:[email-masked]>>; TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>; BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Reza,

—
Eric

Hi Deborah,

Hi Igor,

Cheers,

Reza

Hi,

Igor

Hi,

it is a lengthy review.

adoption.

progress.

Thanks,

Adrian

===

clarity".

---

Section 1

   resources.

---

Section 1

   transport slice.

---

Section 1

---

Section 1.1

establish the need.

---

Section 1.1

where you state that

resources?

---

Section 1.1

---

Section 1.1.

   document

   network slice

---

Section 2

for such key terms.

defined.

---

Section 3

---

Section 3

---

Section 4

---

5.1.

---

Section 4.1

   If for

   in between.

value.

---

Section 4.1.1

very out of place.

slice?

---

Section 4.1.1

      associated with it.

---

Section 4.1.1

Security : really?

---

Section 4.1.2

sort of enhanced VPN?

---

Sections 4.2 and 4.3

---

Section 5.1

have "slice" for short?

---

5.2.

      through an orchestrator.

hard to guess.

---

---

All,

Thanks,
Pavan and Lou
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7Cb6152b2db4334e5f201e08d8502ce948%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637347501157061529&sdata=9EYSOhNCdO6ezp4bFopQFg4S2f3lcjj4%2Bk%2FeXKhxg8Y%3D&reserved=0>
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7Cb6152b2db4334e5f201e08d8502ce948%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637347501157061529&sdata=9EYSOhNCdO6ezp4bFopQFg4S2f3lcjj4%2Bk%2FeXKhxg8Y%3D&reserved=0>

---

From: Shunsuke Homma <[email-masked]>
Date: Fri, 4 Sep 2020 22:48:25 +0900

I think the definition you referred to in TS23.501 came from ITU-T (ITU-T
Y.3100) . And, I assume that the ambiguous definition brought this
confusion (i.e., the ambiguity allows readers to create their own
interpretations).
# It's obvious that definitions of IETF documents are consistent with it,
because everyone would refer to it.

3GPP has their more concrete concept of network slicing on the basis of the
above definition  in TS28.530. I think we also need to break down the
definition from IETF perspective and clarify our concrete scope.

Regarding slicing on non-TE networks, for example,  a network can be
logically separated with OSPF multi-instance or IGP Flex-Algo. Or, in some
cases, operators may lend whole physical links. Of course, in many cases,
it is better to use TE technologies. But we need not to limit the target to
TE networks, I think.

Regards,

Shunsuke

2020年9月4日(金) 2:13 Adrian Farrel <[email-masked]>:

> Thank you Eric for what is the clearest email to date on how we got to
> where we are. It helps me understand a lot better the questions we should
> be asking. I’m sure many of these questions were debated at length in the
> design team, but “we thought about it and came to a conclusion” is never
> the strongest argument to present to a working group, so we may have to
> unpack some of the compromises that were made in order to bring everyone
> along with the ideas. (I also hope that the compromise wasn’t reached on
> the basis of most of the team saying they didn’t like it and a few people
> digging in. But that will come out if the members of the team speak up on
> the list to say what they do or don’t like.)
>
>
>
> I appreciate the desire to be consistent with the terminology used in
> other bodies. There is no reason not to do that where that terminology is
> clear and where it is not in conflict with terminology already in use in
> the IETF. On the other hand, where the IETF is already using terminology we
> have to be more careful.
>
>
>
> *Network Slice**:* A logical network that provides specific network
> capabilities and network characteristics.
>
> The problem seems to come as we move from the abstract/generic to the
> specific. I believe it will always be the case that the concept of
> “transport” is a relative term. Any network that can carry traffic for an
> application or another network is (by definition of “transport” meaning to
> carry) a transport network. If you build IP networks then any sub-IP
> network is a transport network. If you build radio networks then you may
> see an IP network as a transport network. If you run IP over radio, then
> you probably see the radio network as transport.
>
>
>
> But I think we find that the 3GPP definition of “network slice” embraces
> the wider and more general concept that we also need. That is, we need to
> describe the creation and management of logical networks that provides
> specific network capabilities and network characteristics. I don’t think we
> want to be limited to when those logical networks are specifically intended
> to carry traffic for client networks that are themselves network slices.
>
>
>
> If, as some people seem to argue, there is a need to constrain the
> description to be limited to just a specific use case of a network slice,
> then I suggest that is exactly what should be done. That is: define a
> network slice and get comfortable with that definition; specify the use
> case; describe how the generic network slice is used in that case; set out
> any limitations or additions needed to the generic definition.
>
>
>
> Two other small points:
>
>    - Igor noted how ACTN was renamed from “transport” to “TE” to ensure
>    it was applicable to all network types for which the IETF (and specifically
>    TEAS) could apply the technology. I agreed with that change and I think it
>    applies here, too.
>    - There may be a desire to apply the concept of network slicing to
>    non-TE networks (but still considering IETF technologies). I would be
>    intrigued to understand how that works without some form of ‘reservation’
>    of network resources and ‘steering’ of traffic. It may be that:
>       - The advocates of this idea should read (and contribute to)
>       draft-ietf-teas-rfc3272bis
>       - We should all think hard about where such work should be done
>       given the scope of TEAS
>
>
>
> Best,
>
> Adrian
>
>
>
> *From:* Eric Gray <[email-masked]>
> *Sent:* 03 September 2020 16:20
> *To:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> *Cc:* Igor Bryskin <i_bryskin=[email-masked]>; Vishnu Pavan
> Beeram <[email-masked]>; TEAS WG <[email-masked]>; Adrian Farrel <
> [email-masked]>; TEAS WG Chairs <[email-masked]>; BRUNGARD,
> DEBORAH A <[email-masked]>
> However, you’ve dived directly into a details-based explanation - where it
> is possible (or even quite likely) that your details-based explanation has
> a Ouroboros-like circularity that depends on how you’ve defined the details.
>
>
>
> Instead, I suggest summarizing the process by which we decided to
> compromise in using “transport slice” (or “transport slicing”).
>
>
>
> I personally thought (and - to some extent - still think) we should be
> using “transport network slices” - for at least the case where we are using
> packet-based (or other IETF supported methodologies for) connectivity
> services to support RAN and Packet Core applications in mobile networks -
>  mostly to be consistent with 3GPP terminology.  That was at least my
> starting position.
>
>
>
>                But we (the IETF) are already (and arguably have been for
> some time) using the phrase “network slicing” to refer to mostly technology
> (and layer) agnostic network virtualization.  That obviously applies very
> nicely in cases where we are talking *only* of IETF defined/maintained
> technologies.  For example: in DC networking.
>
>
>
>                But using “network slicing” in the mobile networking
> application clashes badly with other uses that apply in the same space.
> For example: 3GPP defines "network slices" as originating on a UE, and
> terminating on a UPF (and vice-versa) and these “network slices” have to be
> carried (i.e. - "transported”) over the slices provided for that purpose by
> what 3GPP consistently refers to as a “Transport Network.”  It is possible
> that 3GPP (or mobile operators) may extend usage to include “network
> slices” that extend from one or more UEs to one or more other UEs, through
> one or more (essentially concatenated) UPFs - but dealing with this case is
> not essential (or arguably even useful) to understanding requirements of
> the mobile network application in general.
>
>
>
>                On top of that, in the mobile networking application,
> there is no presumption that a “transport network” will be anything that
> the IETF defines or maintains.  Microwave technology is - for instance - a
> technology that many mobile operators go to first (or at least most often)
> in providing “transport” for a mobile operator’s RAN traffic (including
> network slices), and obviously these services have previously been (and
> will for some time be) provided using some form of synchronous optical
> networking (which is a driver for some of the interest in TDM-like
> “transport services”).
>
>
>
>                So there are multiple dimensions to this naming choice,
> and I don’t think anyone will be completely satisfied with any name we
> select.
>
>
>
>                To the extent possible, we should try to define a
> northbound interface generic enough to support any technology - including
> largely those that are defined/maintained by the IETF - while trying to
> avoid naming ambiguity to the extent possible.  And we should try to
> include sufficient flexibility to support “carrying” (i.e. - “transport”)
> of "network slices" as we have defined them in the IETF.
>
>
>
>                We cannot actually use the phrase “network slices” (or
> “network slicing”) for all of the cases, as that will be far too ambiguous
> and will lead to the need to “qualify” every usage to remove the inherent
> ambiguity we would be creating.
>
>
>
>                Hence the compromise of using “transport slice.”  I don’t
> like it, and I am not alone in that - but that is pretty much the
> definition of what a “compromise” is.
>
>
>
> —
>
> Eric
>
>
>
>                 >>>>> Why are you excluding RAN? RAW is already doing IP
> solutions, SG15 has RAN transport solutions for IP. IP is already in the
> RAN.
>
>
>
> RAN NEs has two logical components, Radio and Transport. When I mentioned
> in my previous email that a “*5G network slice* has RAN Slice, Transport
> Slice and Core slice, I refer to the Radio portion of the RAN.
>
> The transport portion of the RAN can be consider as part of the transport
> slice. This is clearly pointed out in the draft with definition of
> Transport Slice Endpoint (TSE). Please see picture below where for example
> the TSE could be the endpoint inside the Transport portion of the RAN.
>
>
>
>
>
>
> Hi Igor,
>
>                 >>>> I agree with Deborah and Adrian that at least some
> terms defined in this work could have been borrowed from other TEAS WG work.
>
>
>
> You have a valid point of using the exiting IETF terms as much as we can.
> And this was the intention of the draft authors.
>
> Having said that, It is important to consider that the operator can
> realize a “Transport Slice” in a TE or NON-TE network. They can even
> realize a transport slice in NON-IP/MPLS network (like PON).
>
> As pointed out in the draft, the realize of a transport slice can be in
>  TE network and any IETF models/works can be utilized for realization.
>
>
>
>
>
> Cheers,
>
>
>
> Reza
>
>
>
>
>
> *From: *Teas <[email-masked]> on behalf of Igor Bryskin <
> i_bryskin=[email-masked]>
> *Date: *Wednesday, September 2, 2020 at 11:14 AM
> *To: *'Vishnu Pavan Beeram' <[email-masked]>, 'TEAS WG' <
> [email-masked]>, Adrian Farrel <[email-masked]>
> *Cc: *'TEAS WG Chairs' <[email-masked]>
> *Subject: *Re: [Teas] WG adoption -
> I agree with Deborah and Adrian that at least some terms defined in this
> work could have been borrowed from other TEAS WG work.
>
> For example, I may have missed some discussions, but I still do not see
> much difference between transport slice as defined and an abstract network
> topology defined/configured by a client and provided as a service by the
> server as defined in network topology model family. If we could agree that
> the two are at least close cousins, the life would get much simpler IMHO.
>
>
>
> Igor
>
>
>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 4 Sep 2020 17:33:46 +0000 (UTC)

H9 Reza,
One important thing to understand about TEAS TE Topology model is  that it should have been called TE *aware* Topology model instead. It is perfectly legal, for example, to drop all TE related attributes for all topology nodes and links and, thus, configure/control/describe generic ( not necessarily TE) network topology. Even without TE related attributes the model provides a rich set of systematic that would be valuable in the context of network slicing, specifically:- means for controlling/describing horizontal network hierarchies via open-ended access and inter-domain links  and inter-domain locks;- means for controlling/describing vertical (multi-layer) network hierarchies via transitional links or inter-layer locks;- means for controlling/describing overlay/underlay relationships and topology stacks supporting each of nodes/links via source/supporting node/link objects;- topology element coordinates in space via GPS attribute;-etc.
Igor
    On Friday, September 4, 2020, 9:48:51 AM EDT, Shunsuke Homma <[email-masked]> wrote:  
 
 I think the definition you referred to in TS23.501 came from ITU-T (ITU-T Y.3100) . And, I assume that the ambiguous definition brought this confusion (i.e., the ambiguity allows readers to create their own interpretations). 
# It's obvious that definitions of IETF documents are consistent with it, because everyone would refer to it.

3GPP has their more concrete concept of network slicing on the basis of the above definition  in TS28.530. I think we also need to break down the definition from IETF perspective and clarify our concrete scope.

Regarding slicing on non-TE networks, for example,  a network can be logically separated with OSPF multi-instance or IGP Flex-Algo. Or, in some cases, operators may lend whole physical links. Of course, in many cases, it is better to use TE technologies. But we need not to limit the target to TE networks, I think.

Regards,
Shunsuke

Two other small points:
   
   - Igor noted how ACTN was renamed from “transport” to “TE” to ensure it was applicable to all network types for which the IETF (and specifically TEAS) could apply the technology. I agreed with that change and I think it applies here, too.
   - There may be a desire to apply the concept of network slicing to non-TE networks (but still considering IETF technologies). I would be intrigued to understand how that works without some form of ‘reservation’ of network resources and ‘steering’ of traffic. It may be that:
   
   - The advocates of this idea should read (and contribute to) draft-ietf-teas-rfc3272bis
   - We should all think hard about where such work should be done given the scope of TEAS

Best,

Adrian

Reza,

—

Eric

Hi Deborah,

                >>>>> Why are you excluding RAN? RAW is already doing IP solutions, SG15 has RAN transport solutions for IP. IP is already in the RAN.

 

Hi Igor,

                >>>> I agree with Deborah and Adrian that at least some terms defined in this work could have been borrowed from other TEAS WG work.

 

Cheers,

Reza

Hi,

Igor

 

Hi,

it is a lengthy review.

adoption.

progress.

Thanks,

Adrian

===

clarity".

---

Section 1

   resources.

---

Section 1

   transport slice.

---

Section 1

---

Section 1.1

establish the need.

---

Section 1.1

where you state that

resources?

---

Section 1.1

---

Section 1.1.

   document

   network slice

---

Section 2

for such key terms.

defined.

---

Section 3

---

Section 3

---

Section 4

---

5.1.

---

Section 4.1

   If for

   in between.

value.

---

Section 4.1.1

very out of place.

slice?

---

Section 4.1.1

      associated with it.

---

Section 4.1.1

Security : really?

---

Section 4.1.2

sort of enhanced VPN?

---

Sections 4.2 and 4.3

---

Section 5.1

have "slice" for short?

---

5.2.

      through an orchestrator.

hard to guess.

---

---

All,

Thanks,
Pavan and Lou

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 15 Sep 2020 06:39:31 -0500

WG,

Thanks to everyone who contributed to the discussion! It's clear there is
significant interest in this topic – and that we have not yet reached a
point where this version of the document is ready to be published as -00 WG
document.  The discussion has been quite productive and we see a number of
points on which there is general consensus on how the document should be
changed.  Once these changes are made, we can reevaluate publication as a
WG document.  Our reading of the discussion so far:

   1. The objective of this work is to define how IETF technology can be
   used to support Network Slicing. This could be to realize an end-to-end
   network slice including all constituent network slices (multiple network
   slices can be arranged hierarchically or stitched together to constitute an
   end-to-end network slice) or to realize a specific sub-set of the
   end-to-end network slice (as is the case with the 3GPP NSSI use-case). We
   understand that the focus of the 2 documents produced by the DT is on the
   latter (understandably so, given the current interest and immediate need).
   The discussion on the list suggests that there is a need to articulate (the
   focus of the document) this better.
   2. The term "transport slice" seems to have been coined to define the
   specific usage of IETF network slice in the 3GPP NSSI use-case. There is
   currently no consensus on the introduction of the term "transport
   slice"/"transport network slice" and this usage needs more debate and
   justification.
   3. Our (the chairs') intent is for the definitions document to be rolled
   into the framework document after both the documents get adopted.
   4. While not part of this adoption call, we expect that the framework
   will define what network slicing is (using language from the definition
   document) and discuss what is needed to support slicing. Though we do not
   expect the framework document to provide/define solutions, mentioning
   how existing/emerging IETF technology such as ACTN and Enhanced VPN can be
   used to support slicing is within scope (particularly if gaps are
   identified).
   5. The TEAS WG will continue to discuss and progress the framework for
   IETF support of network slicing (independent of solutions). The appropriate
   WG will work on specific protocol extensions/definitions. For example, any
   discussion on use/extension of Transport NBI could take place in CCAMP.

@Authors -- Please make the required changes to the document as per above
and publish a new individual revision.

We are also considering an interim meeting in October to facilitate more
discussion on this topic – please look out for more details on the list.

Regards,
Pavan and Lou