[Teas-ns-dt] More comments on the definitions draft (part 1)

[Jari Arkko <[e-mail]>]

Kiran,

Thanks for your continued work. The document is coming along nicely.

I’ve again performed a review, however, and have some comments:

Section 1:

   Network slicing is a methodology to generically describe the logical
   partitioning of network resources associated with a service or an
   application.  Network slicing is expected to enable diverse devices/
   applications that have different requirements on communication to
   coexist on the same network efficiently.  Also, a network slice
   sometimes traverses multiple domains, and generalized interfaces,
   operations, and management would be important.

   Some key applications which might benefit from the use of network
   slicing include:

   o  5G services (e.g. eMBB, URLLC, mMTC)(See [TS.23.501-3GPP])
   o  Network wholesale
   o  Network infrastructure sharing among the operators
   o  NFV connectivity (Data Center Interconnect)

   A 'network slice' is composed of different endpoints, application
   logic and specific connectivity between them.  Transport slices are a
   part of the network slices that fulfill connection requirements
   between the endpoints.  Transport slices are created and managed
   within the scope of transport networks (e.g.  IP, MPLS, optical).

   This document provides a definition of a slice in the transport
   network (called "transport slice"), and describes its
   characteristics.

I think it is useful to mention end-to-end slicing but I’m concerned that our document should focus on definition what the concept is that we are defining, and spend less time on other people’s concepts. How about rearranging the introduction roughly along the following lines:

   A number of use cases benefit from establishing transport connectivity between
   a set of endpoints according to a given set of requirements. Some of the
  applications that can be benefit from such connectivity unclude

   o  VPNs
   o  5G services (e.g. eMBB, URLLC, mMTC)(See [TS.23.501-3GPP])
   o  Network wholesale
   o  Network infrastructure sharing among the operators
   o  NFV connectivity (Data Center Interconnect)

   This document
   defines a concept of “transport slice”.
   … include more about the definition here …
   Transport slices are created and managed
   within the scope of transport networks (e.g.  IP, MPLS, optical).
   Transport slices are expected to enable diverse devices/
   applications that have different requirements on communication to
   coexist on the same network efficiently.

   Transport slices relate also to the more general topic of network
   slicing. It is not the goal of this document to define this broader
   concept, but in general, it is a methodology to describe the logical
   partitioning of network resources associated with a service or an
   application.

Section 2:

2.  Terms and Abbreviations

   The terms and abbreviations used in this document are listed below.

   o  E2E NS: End to End Network Slice

   o  TS: Transport Slice

   o  TSC: Transport Slice Controller

   o  EP: Endpoint

   o  EU: End User

   o  NBI: North Bound Interface

   o  SBI: South Bound Interface

   o  SLO: Service Level Objective

   o  SLA: Service Level Agreement

   o  B/W: Bandwidth

   o  MTBF: Mean Time Between Failures

   o  MTTR: Mean Time To Repair

Good.

(Is it north bound or northbound?)

Do we really need to use B/W to replace a single word?

Section 3:

3.  High Level Description of End-to-End Network Slicing

This is good text, but, I’m very concerned that it takes away our focus. And it really isn’t our task to define. In addition, any errors or discussion or debates in this space would lead to problems, essentially for no good reason as we should be able to define our concept without having to define a particular way someone uses our concept.

I’d suggest deleting or, alternative, placing a compressed version of this text in a paragraph at the end of the document titled, for instance, “relation to concepts defined elsewhere”.  This new section could also take the text from sub-slices etc that are currently in Section 4.

Section 4.1:

4.  Definition and Scope of Transport slice

4.1.  Transport Slice Definition

   The basic definition of a transport slice is as follows:

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

   Note: The term sub-slice or slice-subnet is used by many standard
   organizations to refer to "Transport Slice" or "Other Slice" (i.e.
   transport sub-slice or transport slice-subnet).  From the IETF point
   of view, these terms are all equivalent.  We will use the term
   "slice" in this document (i.e. use transport slice)

   SLOs are used to clearly describe different network resources
   associated with the service delivered and corresponding parameters
   necessary to realize the transport slice.

   Transport slice should be technology-agnostic, and the means for
   realization can be chosen depending on several factors such as
   service requirements, specifications or capabilities of underlying
   infrastructure.  The structure and different characteristics of
   transport slices are described in the following sections.

I’d suggest moving the discussion of sub-slices etc to a new Section elsewhere.

Secondly, I feel that “shared or dedicated” network resources is unnecessarily lifting a particular aspect of the objectives to the top-level of the definition. It is also an inaccurate expression to use in a definition, because I can, for instance, give you always 100 timeslots but not exactly the same timeslots. But would that be sharing or dedication? And in any case, this is an implementation level requirement when we should be making requirement level requirements ☺ such as guarantees to be able to transport 100 packets on every period.

Jari