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

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

Hi Shunsuke,

Thanks a lot for your prompt reply.  It’s great to know we reach agreement on many of the following items.

Please see some further replies inline with [Jie].

Best regards,
Jie

From: Shunsuke Homma [mailto:[e-mail]]
Sent: Sunday, January 5, 2020 9:05 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: Kiran Makhijani <[e-mail]<mailto:[e-mail]>>; LUIS MIGUEL CONTRERAS MURILLO <[e-mail]<mailto:[e-mail]>>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Teas-ns-dt] Status on updating of definition draft

Hi Jie,

A Happy New Year! Thank you very much for your review and useful feedback. Further update of the definition draft is undergoing, and I send my personal opinions to your feedback. Please see inline.

Best regards,

Shunsuke


2020年1月3日(金) 1:10 Dongjie (Jimmy) <[e-mail]<mailto:[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”.

[SH] OK. We can change the terms depending on the conclusion of the further discussion.
[Jie] OK, we can have some further discussion in the design team.


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.

[SH]  I agree with that the section about realization considerations can be moved to other document such as framework draft. While, I assume that the section would be useful to understand what transport slice is, and we may be able to leave essential points. Do you think the realization section should be completely removed?

[Jie] It would be fine to summarize some essential points to help the understanding of the network slice definition.


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".
[SH] Exactly, references from 3GPP 5G definitions would be help to get an overview of network slicing. However, I'm worrying that it may give a prejudice to transport  slice defined  in  this document.
Anyway, we'll consider whether 3GPP 5G definitions can be quoted there.

[Jie] Referencing to 3GPP definitions is just to provide some background of network slicing work. This document could clarify that transport network slice can be used in both the 5G network slicing scenario and other general scenarios.


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.
[SH] I agree.


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”
[SH] The current text describes general network slice, and thus I think it is not needed unless any 3GPP 5G definitions are quoted there.

[Jie] Agreed. If 3GPP network slicing definitions will be quoted in this section, then some text would be needed to distinguish 5G network slice and the general network slice.


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”?

[SH] I think that "premium business VPN" is also ambiguous. Furthermore, in my understanding, the key factor of this is not VPN type but wholesale model where someone(e.g., network operator, slice broker) provides VPN to customers with network slicing.

[Jie] OK, so the key word here is “wholesale”, not “business VPN”. Then maybe “network wholesale” is a better term?

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”？

[SH] I agree. VNFs would be parts of network slicing, and provision of NVF connectivity won't be a purpose of network slice.


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.

[SH] I assume that this paragraph indicate general network slice (not only e2e slice) , but I agree that network functions should be described in addition to endpoints. How about the following text?
“A network slice is composed of different endpoints/ network functions and service specific connectivity among them”.

[Jie] OK, it seems we may need different terms for “general” network slice and “5G E2E” network slice, so that people can understand which one is being discussed in different sections.

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.

[SH] OK.

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

[SH] SFs appear in the realization section. Also, actually SBI is not used, but figures related to realization implicitly use it. We'll update the list according to the content.

[Jie] OK, thanks.

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.

[SH] Note that this  section describes Terms and "Abbreviations",  and their definitions would be described in the following sections.

[Jie] OK.

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.

[SH] That is described at the last paragraph in the introduction section. Do you think this section also need describing it again?

[Jie] The point here is according to previous discussion, IETF will not define “E2E network slice”, thus the description “the IETF definitions of both E2E network slice and transport slice” here seems conflict with the decision. The suggested change would be to replace the words “To illustrate the IETF definitions of both E2E network slice and transport slice” with “To illustrate the relationship between E2E network slice and transport (network) slice”.


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

[SH] OK.


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”?

[SH] Because it seems that someones dislike to use such words, we avoided using them. Do you think we should use word "network slice subnet" or " sub-slice"?

[Jie] To my understanding here it just refers to different subsets of an end-to-end network slice, no matter what implementation technology is used. The exact term could be discussed further, personally I think “sub-slice” or “sub-network slice” would be better than “network slice subnet”.

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?
[SH] It will be a discussion point. I assume we need defining minimum unit of network slices, and it will help to make it be clear.

[Jie] Agreed.


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.

[SH] They would be described in the section about characteristics (i.e., section 5) .

[Jie] OK.

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.

[SH] I personally agree with you ( actually, I use "logical network" in explanations about network slice in other my drafts.), but I'd like to hear opinions from other members.

[Jie] OK, this could be discussed further on design team meeting.

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

[SH] IMHO, what is technology-agnostic is not "definition" but transport slice itself. Also, I don't want to use word "definition" in explanation of definition.

[Jie] When a transport network slice is instantiated or realized, it must be associated with particular implementation technology. Technology-agnostic is from the view of the network slice consumer or the end-to-end network slice manager.

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.
[SH] This section shows a simple case, and it doesn't care whether transport slices as parts of an e2e slice should be visible to customers. And I assume visibility of subslices to customers will vary depending on who manages e2e slice. For example, in case where customer X uses e2e slice traversing networks of operator A, B, and C, customer X may need to control subslice A, B, and C directly. This may be a discussion point.
Some classification is described  in the following  draft:
https://datatracker.ietf.org/doc/draft-homma-slice-provision-models/

[Jie] OK, will take a look at that document. Thanks.

Section 5.1

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

[SH] In my understanding, isolation is a means to guarantee specific communication quality, and isolation level would be decided on the basis of listed items and their allowable ranges.

[Jie] Isolation level is one attribute of GST defined by GSMA. Just want to indicate that isolation could be a range.

Section 5.4

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

[SH] Thanks. I'll refer VPN+ description.


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]<mailto:[e-mail]>] On Behalf Of Shunsuke Homma
Sent: Thursday, December 19, 2019 11:32 AM
To: [e-mail]<mailto:[e-mail]>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[e-mail]<mailto:[e-mail]>>; Kiran Makhijani <[e-mail]<mailto:[e-mail]>>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[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