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

[Shunsuke Homma <[e-mail]>]

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]>om>:

> 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.



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


>
> 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.


>
>
> 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.


>
>
> 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.


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


> 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.


> 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.



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



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



> 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.


>
>
> 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) .


> 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.


> 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.



> 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/


>
>
> 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.


> 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]] *On Behalf Of *Shunsuke
> Homma
> *Sent:* Thursday, December 19, 2019 11:32 AM
> *To:* [e-mail]
> *Cc:* LUIS MIGUEL CONTRERAS MURILLO <
> [e-mail]>gt;; Kiran Makhijani <
> [e-mail]>gt;; 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
>
>
>
>
>
>
>
>
>
>
>
>
>