Re: [Teas-ns-dt] Status on updating of definition draft

["Dongjie (Jimmy)" <[e-mail]>]

Hi Shunsuke and all,

Happy New Year!

To start the network slicing work in the new year, I just reread the definition draft, basically I think it improved a lot by introducing the terms and characteristics related to network slicing. Here are some comments from my side.

General comments:

1. Suggest to discuss and finalize whether we use the term “transport slice” or “transport network slice”. There was some discussion on mail list and during IETF106 meeting, but still no consensus yet. Considering that 5G E2E network is divided into AN (Access Network), CN (Core Network) and TN (Transport Network) parts, it would be clearer to call it “TN slice” or “transport network slice”.

2. Suggest this document focus on the transport (network) slice definition, the related terminology, and the key characteristics of transport network slice. While the network slicing scenarios (either 5G or non-5G) and the realization considerations could be moved to a separate document, or some of them may be covered by the framework document. This could make the definition draft concise and easier to reach agreement on it.


Some detailed comments:


1.       Introduction:

Since network slicing is firstly introduced for 5G, it could be helpful to refer to the definition of network slice in 3GPP TS 23.501, in which Network Slice is defined as "a logical network that provides specific network capabilities and network characteristics", and Network Slice Instance is defined as "A set of Network Function instances and the required resources (e.g. compute, storage and networking resources) which form a deployed Network Slice".

In the second sentence:
“Network Slicing is considered very useful…there is a need to generically describe diverse set of services describe diverse set of services and related resource requirements that can then be applied to any number or type of proposed, implemented and/or deployed technologies and associated devices.”

Suggest to replace “describe diverse set of services and related resource requirements” with “meet the diverse service and resource related requirement”, and remove the latter part of the sentence. As here it just generally provides the benefits of network slicing, how the requirements are described and implemented could be introduced later.

Since the second paragraph lists both 5G and non-5G applications, it is supposed the first paragraph already talks about “transport network slice”, not the general network slice in 5G. Then I’d suggest to make this clear in the first paragraph by adding the following sentence:

“This document focuses on transport network slice, which can be considered as a subnetwork of 5G end-to-end network slice, while it can also be useful in non-5G network scenarios”

The second application “wholesale business VPN” is a little bit confusing. I guess it refers to VPN services which have some specific performance or reliability requirement. If so, I’d suggest to call it “premium business VPN”?

The fourth application is “NFV connectivity (Data Center Interconnect)”. Data center interconnect can be related or not related to NFV, in order to make this case more generic, suggest to remove “NFV connectivity”. Also currently it does not reflect why network slicing is needed for data center interconnect. Perhaps could add something like “Data center interconnect for different service types or tenants”？

The sentence “A network slice is composed of different endpoints and application specific connectivity between them”. If this is the description about end-to-end network slice, it needs to add network functions into the scope, not just endpoints and connectivity. Also it is suggested to move the description of E2E network slicing to the beginning of the introduction.

2. Terminology

TS ID: Suggest to change to TNS ID (Transport Network Slice Identifier). Also need to explain whether this ID is used in management plane or other plane.

SBI and SF: these two terms are not used in other sections of this document, suggest to remove

And I agree to add more explanation to the terms such as SLO and SLA.

Other terms used in the transport network slice definition could also be listed here, such as abstract topology or logical network.

3. High level architecture

The first paragraph mentions “the IETF definitions of both E2E network slice and transport slice”, while as discussed the design team will only focus on the definition of transport (network) slice. Thus it is suggested to just make this clear in this paragraph.

Since the definition of transport network slice needs to be generic, maybe the technology-specific descriptions could be reduced in this section.

It is described that an end-to-end network slice consists of multiple technology-specific networks, while in the E2E network slice context, should each of them be called a “network slice subnet” or “sub-network slice”?

If transport network consists of multiple “technology specific networks”, will each of them be exposed in the E2E network slice as separate transport network slices, or their differences are implementation details whih should be hidden inside the transport network slice?

In the list of network node types, it would be helpful to classify them into transport nodes and non-transport nodes.

In the example given in this section, the requirement from the customer is a “separate and independent E2E logical network with specific SLO”, thus maybe these characteristics could be reflected in the definition of transport network slice.

Section 4.1

Although the current definition is generic, I still feel that is may not be complete. It mainly talks about an abstract topology, while IMO topology is just one attribute of a transport network slice. And abstraction is the approach to expose the network slice to other entities or the management plane, it is not the attribute of the transport network slice itself. Maybe we could use the term a “logical network” as in the examples in previous section and also the next section. This logical network could have a customized topology, and it could have other attributes.

The sentence “Transport slice should be technology-agnostic”, could be changed to “The definition of transport (network) slice should be technology-agnostic”.

Section 4.2

Figure 2 shows an example that one transport network slice built from multiple networks. IMO this is the right approach to expose transport network slice to the E2E network slice customers, they only need to see one transport network slice, inside which there can be multiple transport network segments or domains, but they are not visible to the customer of E2E network slice.

Section 5.1

In the list of characteristics, level of isolation could be added, and detailed explanation could be given in following sections.

Section 5.4

The description about isolation could be expanded based on the text in VPN+ framework section 2.1.

Section 6

Suggest to move the content of this section to a separate document, so as to keep this document focusing on the network slice definition and terminology.


Best regards,
Jie

From: Teas-ns-dt [mailto:[e-mail]] On Behalf Of Shunsuke Homma
Sent: Thursday, December 19, 2019 11:32 AM
To: [e-mail]
Cc: LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>om>; Kiran Makhijani <[e-mail]>om>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Subject: [Teas-ns-dt] Status on updating of definition draft

Hi NS-DT members,

In response to the feedback from IETF106 and the last web meeting, we are updating the definition draft, and  I'm sending the latest version.

The major update points are below:
- Modified definition and terms to ones concluded in IETF106.
- Reflected conclusion at  the last web meeting (see section 4.1 and section 5).
- Restructure the  draft:
    - separated definition section into two parts: one for describing just definition and the other for supplementary explanation.
    - merged description about e2e network slice into section 2.
    - made an individual section about characteristics.
    - moved subsection for examples into realization section.

Also, we assume that the follows might be new discussion points:
  - definition about minimum unit of transport slice
  - necessity of hierarchical concept

If you have any questions or comments, please let  us know.
Also, if you prefer, I can explain summary of the updates in today's meeting. (I'm in business trip now, and I'm sorry if I can't attend the meeting due to any  troubles....)

Regards,

Shunsuke