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

    On Tuesday, September 1, 2020, 5:36:39 PM EDT, Adrian Farrel <adrian@olddog.co.uk> 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,

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> On Behalf Of Vishnu Pavan Beeram
Sent: 19 August 2020 16:50
To: TEAS WG <teas@ietf.org>
Cc: TEAS WG Chairs <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
https://www.ietf.org/mailman/listinfo/teas