Subject: Re: [Netslices] [Teas] terminology discussion network slicing

From: "Kiran.Makhijani" <[email-masked]>
Date: Tue, 16 May 2017 15:18:04 +0000

Due to direct relvance to discussion – Ccing netslices.
-Kiran

On 5/16/17, 7:31 AM, "Teas on behalf of Leeyoung" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,
    
    This argument if network slicing = vpn has been discussed in the network slicing mailing list. If I recall correctly, network slicing =! vpn. Please check out the archives of the network slicing list ([email-masked]) if you are interested in this topic. I would say network slicing is bigger than vpn in its scope, one of which Igor pointed out. 
    
    Thanks,
    Young
    
    -----Original Message-----
    From: Lou Berger [mailto:[email-masked]] 
    Sent: Tuesday, May 16, 2017 8:35 AM
    To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Perhaps it's time to bring the discussion to the slicing list and report back their reaponse....
    
    Lou

    On May 16, 2017 8:31:19 AM Igor Bryskin <[email-masked]> wrote:
    
    > Hi Sergio,
    >
    > I would also like to hear more from network slicing experts.
    >
    > My understanding is that the difference in the separation (in terms of 
    > control and data planes, security, etc.). For example, traditional BGP 
    > based L3 VPNs (that use provider's common control plane for their 
    > management and IP/MPLS TE tunnels to inter-connect their PEs) will 
    > probably not be able guarantee for the clients msec range connectivity 
    > setup times required by 5g, while provided by the same provider fully 
    > separated/genuinely private IP/MPLS networks (that do not share 
    > IP/MPLS control plane and infrastructure, whose network topology is 
    > supported by separate L0/L1 connections) hopefully will be able to 
    > provide such guarantees. Therefore, I define layer network slices as 
    > dynamically managed fully isolated in control and data planes private 
    > TE layer networks, which may share one or more underlying server layer networks.
    >
    >
    > Cheers,
    > Igor
    >
    >
    >
    >
    > -----Original Message-----
    > From: Teas [mailto:[email-masked]] On Behalf Of Belotti, Sergio 
    > (Nokia - IT/Vimercate)
    > Sent: Tuesday, May 16, 2017 6:08 AM
    > To: Gert Grammel; Leeyoung; [email-masked]; [email-masked]
    > Subject: Re: [Teas] terminology discussion network slicing
    >
    > Hi Gert,
    >
    > "Thinking a bit about it I came to the point where "VPN" and "network 
    > slices" seem to describe the same entity or at least a "network slice"
    > being a VPN of VPNs?"
    >
    > I share completely your conclusion , I'd like if someone can explain 
    > if a difference really exists .
    >
    > Thanks
    > Sergio
    >
    >
    > -----Original Message-----
    > From: Teas [mailto:[email-masked]] On Behalf Of Gert Grammel
    > Sent: Monday, May 15, 2017 7:02 PM
    > To: Leeyoung <[email-masked]>; [email-masked]; [email-masked]
    > Subject: Re: [Teas] terminology discussion network slicing
    >
    > Leeyoung,
    >
    > Thank you for taking a stab on this. Usually when getting to a 
    > definition, I try to establish what kind of existing constructs would 
    > fall under the definition. If my understanding is correct, the 
    > following list of constructs would all satisfy the definition somehow.
    > - A TDM network with a p2p TDM connection
    > - A PSC capable network carrying a p2p circuit (such as EPL/EVPL)
    > - An MPLS LSP using a traffic engineered IP network
    > - A L2VPN using a traffic engineered MPLS network
    > - A L3VPN using a traffic engineered IP network
    > - A TCP connection using a traffic engineered IP network
    > - Different QoS classes in an IP network
    >
    > Thinking a bit about it I came to the point where "VPN" and "network 
    > slices" seem to describe the same entity or at least a "network slice"
    > being a VPN of VPNs?
    >
    > Gert
    >
    >
    > On 2017-05-17, 16:44, "Teas on behalf of Leeyoung" 
    > <[email-masked] on behalf of [email-masked]> wrote:
    >
    >     Hi Adrian and others,
    >
    >     We'd like cross check with you on some terminology we introduced newly. Any 
    >     comment on these terms will be greatly appreciated.
    >
    >     We introduced 'network slicing' as follows:
    >
    >             Network slicing is a collection of resources
    >             that are used to establish logically dedicated virtual networks
    >             over TE networks. It allows a network provider to provide
    >             dedicated virtual networks for application/customer over a
    >             common network infrastructure. The logically dedicated
    >             resources are a part of the larger common network
    >             infrastructures that are shared among various network slice
    >             instances which are the end-to-end realization of network
    >             slicing, consisting of the combination of physically or
    >             logically dedicated resources.
    >
    >
    >     Thanks.
    >     Young and Daniele
    >     -----Original Message-----
    >     From: Leeyoung
    >     Sent: Friday, May 05, 2017 1:41 PM
    >     To: [email-masked]
    >     Subject: RE: [Teas] I-D Action: 
    > draft-ietf-teas-actn-framework-05.txt
    >
    >     Hi,
    >
    >     This update is intended to incorporate the comments from the last WG 
    >     meeting and any pending issues. We also have taken the global editorial 
    >     changes to make it consistent through the document. Major changes are:
    >
    >     - Inclusion of "network slicing" definition from ACTN perspective (in the 
    >     terminology section)
    >     - Added virtual network service (VNS) section (Section 3) to define types 
    >     of VNS.
    >     - Incorporated "orchestration" (service/network) mapping to ACTN 
    >     architecture (See Section 5.2)
    >     - Created a new section 6 (Topology Abstraction Method) where we imported 
    >     some texts from ACTN abstraction method  
    >     https://tools.ietf.org/html/draft-lee-teas-actn-abstraction-01
    >     - Added Appendices A & B to discuss example deployment scenarios such as 
    >     example of MDSC and PNC functions integrated in Service/Network 
    >     Orchestrator (Appendix A) and example of IP + Optical network with L3VPN 
    >     service (Appendix B)
    >
    >     In regard to ACTN abstraction method draft, we are going to keep it as a 
    >     separate draft and use this document to elaborate other aspects not 
    >     imported to the framework document.
    >
    >     The following diff pointer will help you see the changes with this revision:
    >     
    > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-framework-05
    >
    >     The co-authors believe that the document is ready for WG LC. Any 
    >     changes/comments will be appreciated.
    >
    >     Thanks & Best regards,
    >     Young & Daniele (on behalf of other co-authors/contributors)
    >
    >     -----Original Message-----
    >     From: Teas [mailto:[email-masked]] On Behalf Of [email-masked]
    >     Sent: Friday, May 05, 2017 10:41 AM
    >     To: [email-masked]
    >     Cc: [email-masked]
    >     Subject: [Teas] I-D Action: draft-ietf-teas-actn-framework-05.txt
    >
    >
    >     A New Internet-Draft is available from the on-line Internet-Drafts directories.
    >     This draft is a work item of the Traffic Engineering Architecture and 
    >     Signaling of the IETF.
    >
    >             Title           : Framework for Abstraction and Control of Traffic 
    >             Engineered Networks
    >             Authors         : Daniele Ceccarelli
    >                               Young Lee
    >     	Filename        : draft-ietf-teas-actn-framework-05.txt
    >     	Pages           : 41
    >     	Date            : 2017-05-05
    >
    >     Abstract:
    >        Traffic Engineered networks have a variety of mechanisms to
    >        facilitate the separation of the data plane and control plane. They
    >        also have a range of management and provisioning protocols to
    >        configure and activate network resources.  These mechanisms
    >        represent key technologies for enabling flexible and dynamic
    >        networking.
    >
    >        Abstraction of network resources is a technique that can be applied
    >        to a single network domain or across multiple domains to create a
    >        single virtualized network that is under the control of a network
    >        operator or the customer of the operator that actually owns
    >        the network resources.
    >
    >        This document provides a framework for Abstraction and Control of
    >        Traffic Engineered Networks (ACTN).
    >
    >
    >
    >     The IETF datatracker status page for this draft is:
    >     https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/
    >
    >     There are also htmlized versions available at:
    >     https://tools.ietf.org/html/draft-ietf-teas-actn-framework-05
    >     
    > https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-framework-0
    > 5
    >
    >     A diff from the previous version is available at:
    >     
    > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-framework-05
    >
    >
    >     Please note that it may take a couple of minutes from the time of 
    >     submission until the htmlized version and diff are available at tools.ietf.org.
    >
    >     Internet-Drafts are also available by anonymous FTP at:
    >     ftp://ftp.ietf.org/internet-drafts/
    >
    >     _______________________________________________
    >     Teas mailing list
    >     [email-masked]
    >     https://www.ietf.org/mailman/listinfo/teas
    >
    >     _______________________________________________
    >     Teas mailing list
    >     [email-masked]
    >     https://www.ietf.org/mailman/listinfo/teas
    >
    >
    > _______________________________________________
    > Teas mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/teas
    >
    > _______________________________________________
    > Teas mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/teas
    >
    > _______________________________________________
    > Teas mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/teas
    >

    _______________________________________________
    Teas mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/teas

---

From: Leeyoung <[email-masked]>
Date: Fri, 19 May 2017 13:15:14 +0000

Hi,

Lou is right. There is a dedicated email list for the discussion of "network slicing (cc'ed)" and the discussion about what that term means should be held on that list. 

We have used similar language in draft-ietf-teas-actn-framework right from the
00 version. Recent changes have been an attempt to clarify what the terminology means in the context of ACTN. We are not trying to define or redefine "network slicing" in the ACTN document, but are trying to make it clear how ACTN works.

Therefore I propose the following resolution:

1. All discussion of the general applicability and definition of "network slicing" is held on the netslices mailing list.

2. We adopt Adrian's suggestion to explain that the scope of the definition of the terms used in the ACTN framework is limited to ACTN. That means effectively that if there are components of a wider definition of network slicing that are not supported by ACTN, that will be OK. 

I propose to post an updated version in the next few days and I believe that will allow this draft to move ahead without being blocked by the discussion in netslices. Once the IETF has a stable definition of network slicing we can return and see how ACTN is applicable to that definition an whether more wok is need (in a separate draft).

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 19 May 2017 20:17:58 +0100

Unsurprisingly, I think that Young's proposal to adopt my text change is a good
idea :-)

I think we can scope the ACTN documents to talk about ACTN only. That means that
the discussion of "network slicing" in the ACTN documents (which goes back to
the time of WG adoption) can and should remain, but should be described in terms
of "within the scope of ACTN".

That means that the netslices list remains the place to discuss the full breadth
of the definition of "network slicing", and also means that the ACTN documents
are not predicated on an external agreement on that wider definition.

Hope that works and we don't have to do a global replace of "network slice" in
the ACTN docs with a new term.

Cheers,
Adrian

> From: Netslices [mailto:[email-masked]] On Behalf Of Leeyoung
> Sent: 19 May 2017 14:15
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Netslices] [Teas] terminology discussion network slicing
> 
> Hi,
> 
> Lou is right. There is a dedicated email list for the discussion of "network
slicing
> (cc'ed)" and the discussion about what that term means should be held on that
> list.
> 
> 00 version. Recent changes have been an attempt to clarify what the
terminology
> means in the context of ACTN. We are not trying to define or redefine "network
> slicing" in the ACTN document, but are trying to make it clear how ACTN works.
> 
> 1. All discussion of the general applicability and definition of "network
slicing" is
> held on the netslices mailing list.
> 
> 2. We adopt Adrian's suggestion to explain that the scope of the definition of
the
> terms used in the ACTN framework is limited to ACTN. That means effectively
> that if there are components of a wider definition of network slicing that are
not
> supported by ACTN, that will be OK.
> 
> I propose to post an updated version in the next few days and I believe that
will
> allow this draft to move ahead without being blocked by the discussion in
> netslices. Once the IETF has a stable definition of network slicing we can
return
> and see how ACTN is applicable to that definition an whether more wok is need
> (in a separate draft).
> 
> Thanks,
> Young
> 
> To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia -
> IT/Vimercate) <[email-masked]>; Gert Grammel
> <[email-masked]>; Leeyoung <[email-masked]>; [email-masked];
> [email-masked]
> Perhaps it's time to bring the discussion to the slicing list and report back
their
> reaponse....
> Netslices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netslices

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 19 May 2017 20:18:47 +0000

Hi Young, all,

i agree with your conclusion but would like to clarify one thing that IMO got lost in the discussion since its beginning.

The 3GPP definition says: 
"A set of network functions and the resources for these network functions which are arranged and configured, forming a complete logical network to meet certain network characteristics."

This means that a network slice IS NOT a VPN or a TE Tunnel.
A network slice is "something" (netslices and 3GPP will define what this something is) that is composed by a "piece" in the RADIO domain, a "piece" in the CLOUD domain, a "piece" in the TRANSPORT domain, plus possible other pieces in possible other domains.

The word "transport" can be misleading here since one could think of transport technologies (e.g. WDM, OTN), but what I'm referring to as TRANSPORT DOMAIN is that part of the network that is used to carry a packet between two other domains. 
In order to have a slice, that portion of the transport domain needs to be engineered, hence it is all about building a TE entity and stitching services to such entity. This is what is in the ACTN scope.

My very personal opinion is that whatever belongs to the transport domain belongs to IETF (and is already being addressed), while the rest is a dangerous duplication of concepts standardized is other SDOs...but this is another discussion that doesn't fit here.

BR
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 19 May 2017 22:11:47 +0000

Hi Danielle,

Network slicing may have nothing to do with radio. 5g is just a big reason as to why the interest/focus is back on network slicing, which is a very old concept. I don't think that anyone is arguing with what you wrote. The questions are:
a) how do you manage these "pieces"?
b) what policy infrastructure should be put in place?
c) how do you ensure their separation or, conversely, the degree of resource sharing?
d) why exactly legacy VPNs are not good enough?

Cheers,
Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, May 19, 2017 4:19 PM
To: Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi Young, all,

BR
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 19 May 2017 20:32:56 -0400

On May 19, 2017 16:56, "Daniele Ceccarelli" <[email-masked]>
wrote:

Hi Young, all,

i agree with your conclusion but would like to clarify one thing that IMO
got lost in the discussion since its beginning.

The 3GPP definition says:
"A set of network functions and the resources for these network functions
which are arranged and configured, forming a complete logical network to
meet certain network characteristics."

This means that a network slice IS NOT a VPN or a TE Tunnel.
A network slice is "something" (netslices and 3GPP will define what this
something is) that is composed by a "piece" in the RADIO domain, a "piece"
in the CLOUD domain, a "piece" in the TRANSPORT domain, plus possible other
pieces in possible other domains.

The word "transport" can be misleading here since one could think of
transport technologies (e.g. WDM, OTN), but what I'm referring to as
TRANSPORT DOMAIN is that part of the network that is used to carry a packet
between two other domains.
In order to have a slice, that portion of the transport domain needs to be
engineered, hence it is all about building a TE entity and stitching
services to such entity. This is what is in the ACTN scope.

My very personal opinion is that whatever belongs to the transport domain
belongs to IETF (and is already being addressed), while the rest is a
dangerous duplication of concepts standardized is other SDOs...but this is
another discussion that doesn't fit here.

Given that "transport" has two completely orthogonal meanings in our
community now, and is already a source of confusion, if this term is not
already etched in stone, if you could think of another label, that would be
awesome.

Just from your description, I thought you're describing a transit operator.
I'm not saying that's the right term, but I think it would confuse fewer
people.

If you can think of a better term, please use it, of course.

Spencer, as *Transport* AD, but not the kind of Transport you're looking
for ...

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 20 May 2017 12:13:50 +0800

Hi Daniele,
I think that my interpretation of network slice construct definition by
3GPP is slightly different. Please find my comments in-line tagged GIM>>.
Some are to do with terminology but, I believe, it is helpful to settle the
dictionary and agree on the interpretation of terms.

Regards,
Greg

> This means that a network slice IS NOT a VPN or a TE Tunnel.
GIM>> My view is that VPN or a TE Tunnel could be part of instantiation of
a network slice. There likely to be additional to TE parameters that may be
considered, depending on the profile of the service requested the NS.

> pieces in possible other domains.
GIM>> I see separation of RAN and "transport" networks. Indeed, there will
be e2e construct (will it be still referred as "network slice" or
"multi-domain NS") but it can be decomposed into domain-scope NSes. What
you referred to as "piece" I consider as domain-scope NS.

> services to such entity. This is what is in the ACTN scope.
GIM>> Should we use Client-Server terms?

> Lou is right. There is a dedicated email list for the discussion of
> "network slicing (cc'ed)" and the discussion about what that term means
> should be held on that list.
>
> terminology means in the context of ACTN. We are not trying to define or
> redefine "network slicing" in the ACTN document, but are trying to make it
> clear how ACTN works.
>
> slicing" is held on the netslices mailing list.
>
> 2. We adopt Adrian's suggestion to explain that the scope of the
> definition of the terms used in the ACTN framework is limited to ACTN. That
> means effectively that if there are components of a wider definition of
> network slicing that are not supported by ACTN, that will be OK.
>
> I propose to post an updated version in the next few days and I believe
> that will allow this draft to move ahead without being blocked by the
> discussion in netslices. Once the IETF has a stable definition of network
> slicing we can return and see how ACTN is applicable to that definition an
> whether more wok is need (in a separate draft).
>
> Thanks,
> Young
>
> IT/Vimercate) <[email-masked]>; Gert Grammel <
> [email-masked]>; Leeyoung <[email-masked]>; [email-masked];
> [email-masked]

---

From: "qiangli (D)" <[email-masked]>
Date: Sat, 20 May 2017 08:32:06 +0000

Hi Daniele and all,

>> This means that a network slice IS NOT a VPN or a TE Tunnel.
I would like to understand this point as -- 1) VPN or TE tunnel != network slice
                                    2) And VPN or TE tunnel could be a technical solution of network slicing
Considering from the isolation perspective, VPN and TE tunnel could provide a certain degree of isolation. However, different VPNs/TE tunnels (i.e, different network slices) still may compete for underlying resources. Other hard-isolation methods are necessary for network slicing.

Another suggestion, could we use the terminology "network segment" to refer to Access network, "Transport" network, edge network, etc., and the terminology "domain" particularly refers to the domain of a certain network segment (a network segment may involve multiple domains due to geographic/administrative/etc. isolation).

Best regards,

Qiang, Li (Cristina)
NetLab, Huawei

-----邮件原件-----
发件人: Netslices [mailto:[email-masked]] 代表 Daniele Ceccarelli
发送时间: 2017年5月20日 4:19
收件人: Leeyoung; [email-masked]
抄送: [email-masked]
主题: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Young, all,

BR
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 20 May 2017 06:21:17 +0000

Hi,

1. Resources assigned to a slice are not necessarily virtual
2.An LSP that is used to provide transport for a service (eg L2/L3 VPN)is
not necessarily TE, and that doesn't make a VPN any less a VPN
3.Slice LS management is not done by IETF, YANG data modeling work is
crucial to provide level of abstraction needed in
multi-domain/multi-technology environment.

In general, from ACTN prospective it is nothing different than resource
allocation that meets constrains as requested by business logic.

Jari and myself have done 5G/slicing introduction to IAB during this week
retreat and planning to follow up with the work in that area.

Cheers,
Jeff
On Fri, May 19, 2017 at 21:14 Greg Mirsky <[email-masked]> wrote:

>> In order to have a slice, that portion of the transport domain needs to
>> be engineered, hence it is all about building a TE entity and stitching

---

From: "qiangli (D)" <[email-masked]>
Date: Sat, 20 May 2017 09:26:39 +0000

Hi Igor,

I have different opinion on " Network slicing may have nothing to do with radio".
IMO, network slicing should be a resource-oriented management mode. The end-to-end network slice (from UE to server/other UE) of course involves the radio resource, usually we use the word "RAN-radio access network" rather than simply say "radio". The Frequency
band, time, code, equipment/site, and software are a number of dimensions, in which RAN resources can be isolated [Online available http://www.huawei.com/en/industry-insights/mbb-2020/trends-insights/5g-service-guaranteed-network-slicing-whitepaper].

Best regards,

Qiang, Li (Cristina)
NetLab, Huawei

-----邮件原件-----
发件人: Netslices [mailto:[email-masked]] 代表 Igor Bryskin
发送时间: 2017年5月20日 6:12
收件人: Daniele Ceccarelli; Leeyoung; [email-masked]
抄送: [email-masked]
主题: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Danielle,

Cheers,
Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, May 19, 2017 4:19 PM
To: Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi Young, all,

BR
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Sat, 20 May 2017 15:49:36 +0000

Hi Cristina,

People whose opinion I respect very much told me that even the 3GPP network slicing definition and effort is not 5G specific.  Network slicing is viewed as an important capability of 5G, but it could serve other architectures.

Cheers,
Igor

-----Original Message-----
From: qiangli (D) 
Sent: Saturday, May 20, 2017 5:27 AM
To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
Cc: [email-masked]
Subject: 答复: [Teas] terminology discussion network slicing

Hi Igor,

Best regards,

Qiang, Li (Cristina)
NetLab, Huawei

-----邮件原件-----
发件人: Netslices [mailto:[email-masked]] 代表 Igor Bryskin
发送时间: 2017年5月20日 6:12
收件人: Daniele Ceccarelli; Leeyoung; [email-masked]
抄送: [email-masked]
主题: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Danielle,

Cheers,
Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, May 19, 2017 4:19 PM
To: Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi Young, all,

BR
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 23 May 2017 20:27:59 +0000

Ahah, good point Spencer.

Transit may not be good enough but we’ll look for a more appropriate term. For us in the routing area the network is what goes from layer 0 to layer 3…but there is an entire world above (and on the side).

BR/Daniele

From: Netslices [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: sabato 20 maggio 2017 02:33
To: Daniele Ceccarelli <[email-masked]>
Cc: Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

On May 19, 2017 16:56, "Daniele Ceccarelli" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Young, all,

Given that "transport" has two completely orthogonal meanings in our community now, and is already a source of confusion, if this term is not already etched in stone, if you could think of another label, that would be awesome.

Just from your description, I thought you're describing a transit operator. I'm not saying that's the right term, but I think it would confuse fewer people.

Spencer, as *Transport* AD, but not the kind of Transport you're looking for ...

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 23 May 2017 20:39:08 +0000

Hi Greg,

good points. Please see in line.

Cheers
Daniele

From: Greg Mirsky [mailto:[email-masked]]
Sent: sabato 20 maggio 2017 06:14
To: Daniele Ceccarelli <[email-masked]>
Cc: Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Daniele,
I think that my interpretation of network slice construct definition by 3GPP is slightly different. Please find my comments in-line tagged GIM>>. Some are to do with terminology but, I believe, it is helpful to settle the dictionary and agree on the interpretation of terms.

Regards,
Greg

On Sat, May 20, 2017 at 4:18 AM, Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>> wrote:
Hi Young, all,

This means that a network slice IS NOT a VPN or a TE Tunnel.
GIM>> My view is that VPN or a TE Tunnel could be part of instantiation of a network slice. There likely to be additional to TE parameters that may be considered, depending on the profile of the service requested the NS.
[>DC] I should have said “this means that a network might not be JUST a VPN or a TE Tunnel” and hence agree with you on the fact that the VPN or the TE Tunnel could be part of the network slice.

A network slice is "something" (netslices and 3GPP will define what this something is) that is composed by a "piece" in the RADIO domain, a "piece" in the CLOUD domain, a "piece" in the TRANSPORT domain, plus possible other pieces in possible other domains.
GIM>> I see separation of RAN and "transport" networks. Indeed, there will be e2e construct (will it be still referred as "network slice" or "multi-domain NS") but it can be decomposed into domain-scope NSes. What you referred to as "piece" I consider as domain-scope NS.
[>DC] This is another terminology issue. I agree on the separation between the RAN domain and the “transport” domain (let’s keep on using the work transport with quotation marks for the time being) and all the other domains in the network. IMO the network slice is the end to end entity that is built by a RAN slice plus a “transport” slice plus other potential slices. And the “transport” slice could be a VPN, a TE tunnel…

The word "transport" can be misleading here since one could think of transport technologies (e.g. WDM, OTN), but what I'm referring to as TRANSPORT DOMAIN is that part of the network that is used to carry a packet between two other domains.
In order to have a slice, that portion of the transport domain needs to be engineered, hence it is all about building a TE entity and stitching services to such entity. This is what is in the ACTN scope.
GIM>> Should we use Client-Server terms?
[>DC] WRT what? Do you mean wrt the fact that the relationship between e.g. the RAN slice and the “transport” slice could be client- server? I see it more a peering relationship. ON the other side WITHIN the “transport” slice you could have different layers with client-server relationship, that’s right.

BR
Daniele

-----Original Message-----
From: Teas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>; Gert Grammel <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] terminology discussion network slicing

Lou

On May 16, 2017 8:31:19 AM Igor Bryskin <[email-masked]<mailto:[email-masked]>> wrote:

> From: Teas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Belotti, Sergio
> (Nokia - IT/Vimercate)
> To: Gert Grammel; Leeyoung; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> From: Teas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Gert Grammel
> To: Leeyoung <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>
>     Hi Adrian and others,
>
>     To: [email-masked]<mailto:[email-masked]>
>     From: Teas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
>     To: [email-masked]<mailto:[email-masked]>
>     Cc: [email-masked]<mailto:[email-masked]>
>     submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
>     [email-masked]<mailto:[email-masked]>
>     [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

_______________________________________________
Netslices mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netslices

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 23 May 2017 20:44:16 +0000

Ciao Jeff,

please see in line.

Cheers
Daniele

From: Jeff Tantsura [mailto:[email-masked]]
Sent: sabato 20 maggio 2017 08:21
To: Greg Mirsky <[email-masked]>; Daniele Ceccarelli <[email-masked]>
Cc: Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] [Netslices] terminology discussion network slicing

Hi,

1. Resources assigned to a slice are not necessarily virtual
[>DC] i don’t disagree with this

2.An LSP that is used to provide transport for a service (eg L2/L3 VPN)is not necessarily TE, and that doesn't make a VPN any less a VPN
[>DC] yes, this is right in theory, but if we see the slice as something with guaranteed performances (and it has to be in the 5G context), the VPN has to be bound to a TE tunnel…

3.Slice LS management is not done by IETF, YANG data modeling work is crucial to provide level of abstraction needed in multi-domain/multi-technology environment.
[>DC] Agree. And I guess you are referring just to the “transport” slice, which in turn is a portion of the Network Slice.Right?

In general, from ACTN prospective it is nothing different than resource allocation that meets constrains as requested by business logic.

Jari and myself have done 5G/slicing introduction to IAB during this week retreat and planning to follow up with the work in that area.

Cheers,
Jeff

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 23 May 2017 20:47:28 +0000

Hi Cristina,

i've not been precise in my first email. I hope the reply to Greg clarifies my statement. Which is:

"I should have said “this means that a network might not be JUST a VPN or a TE Tunnel” and hence agree with you on the fact that the VPN or the TE Tunnel could be part of the network slice."

For me it's ok to use the term segment instead of domain...it depends if it's ok for everyone.

BR
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of qiangli (D)
Sent: sabato 20 maggio 2017 10:32
To: Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: [Teas] 答复: terminology discussion network slicing

Hi Daniele and all,

I would like to understand this point as -- 1) VPN or TE tunnel != network slice
                                    2) And VPN or TE tunnel could be a technical solution of network slicing Considering from the isolation perspective, VPN and TE tunnel could provide a certain degree of isolation. However, different VPNs/TE tunnels (i.e, different network slices) still may compete for underlying resources. Other hard-isolation methods are necessary for network slicing.

Best regards,

Qiang, Li (Cristina)
NetLab, Huawei

-----邮件原件-----
发件人: Netslices [mailto:[email-masked]] 代表 Daniele Ceccarelli
发送时间: 2017年5月20日 4:19
收件人: Leeyoung; [email-masked]
抄送: [email-masked]
主题: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Young, all,

BR
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 23 May 2017 21:00:39 +0000

Hi Igor,

let me try to answer in line.

Cheers
Daniele  (with a single L) :) 

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: sabato 20 maggio 2017 00:12
To: Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Danielle,

Network slicing may have nothing to do with radio. 5g is just a big reason as to why the interest/focus is back on network slicing, which is a very old concept. I don't think that anyone is arguing with what you wrote.

[>DC] Whether the network slice has to do with radio depends on the definition of network slice. If we focus on the "transport" slice then I agree with you, but the network slice IMO spans multiple domains/segments and radio can be one of them (as well as e.g. the cloud)

 The questions are:
a) how do you manage these "pieces"?
[>DC]  I would say independently in each domain/segment and then at the orchestration level someone will be in charge to put the pieces together.

b) what policy infrastructure should be put in place?
[>DC] good question. This definitely needs to be end to end, since the user is paying for it.

c) how do you ensure their separation or, conversely, the degree of resource sharing?
[>DC] Again per domain/segment. In the cloud you might have different slices sharing the same VNG (e.g. IMS or Packet Core), while in the "transport" you might have different slices sharing a same tunnel or having dedicated one.

d) why exactly legacy VPNs are not good enough?
[>DC] IMO legacy VPNs are good enough as "transport" slice. There are several mechanisms to e.g. extend them from the "transport" domain to the cloud domain or to stitch them to e.g. VXLAN in the DC. They just need to be bound to a TE-tunnel or an ACTN VN if you want to have guaranteed SLA for the service using such VPN

Cheers,
Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, May 19, 2017 4:19 PM
To: Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi Young, all,

BR
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: "qiangli (D)" <[email-masked]>
Date: Wed, 24 May 2017 08:39:53 +0000

Hi Danielle and Igor,

please see my reply inline below, marked as >>[Cr].

Best regards,

Cristina QIANG

-----邮件原件-----
发件人: Netslices [mailto:[email-masked]] 代表 Daniele Ceccarelli
发送时间: 2017年5月24日 5:01
收件人: Igor Bryskin; Leeyoung; [email-masked]
抄送: [email-masked]
主题: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Igor,

Cheers

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: sabato 20 maggio 2017 00:12
To: Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Danielle,

 The questions are:
>>[Cr] This question is related to the architecture of netslice. Daniele's answer is just one possibility (i.e, independently in each domain/segment + a common orchestration platform above). I can see another possibility that is independently each domain/segment + cross-domain/cross-segment negotiation & interoperation. IMO, the latter one may be more practical for netslice, since an end-to-end slice may involves different operators/administrative regions, and there does not exist a common platform.

>>[Cr] I will not deny that VPN could be one of the solutions for network slicing. However, it still has some deficiencies: 
1) as a overlay technology, it has little control of network resources 
2) Unlike hard isolation technologies (e.g., FlexE), even bound to other TE-tunnel or resource reservation protocols, different VPNs still have the risk of underlying resource competition in extremes.

Cheers,
Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, May 19, 2017 4:19 PM
To: Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi Young, all,

BR
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: "qiangli (D)" <[email-masked]>
Date: Wed, 24 May 2017 09:05:25 +0000

Hi Igor,

I share the same opinion on 5G and network slicing, but can't see the relation between this opinion and your conclusion that ns has nothing to do with radio.

Best regards,

Cristina QIANG

-----邮件原件-----
发件人: Igor Bryskin 
发送时间: 2017年5月20日 23:50
收件人: qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
抄送: [email-masked]
主题: RE: [Teas] terminology discussion network slicing

Hi Cristina,

Cheers,
Igor

-----Original Message-----
From: qiangli (D)
Sent: Saturday, May 20, 2017 5:27 AM
To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
Cc: [email-masked]
Subject: 答复: [Teas] terminology discussion network slicing

Hi Igor,

I have different opinion on " Network slicing may have nothing to do with radio".
IMO, network slicing should be a resource-oriented management mode. The end-to-end network slice (from UE to server/other UE) of course involves the radio resource, usually we use the word "RAN-radio access network" rather than simply say "radio". The Frequency band, time, code, equipment/site, and software are a number of dimensions, in which RAN resources can be isolated [Online available http://www.huawei.com/en/industry-insights/mbb-2020/trends-insights/5g-service-guaranteed-network-slicing-whitepaper].

Best regards,

Qiang, Li (Cristina)
NetLab, Huawei

-----邮件原件-----
发件人: Netslices [mailto:[email-masked]] 代表 Igor Bryskin
发送时间: 2017年5月20日 6:12
收件人: Daniele Ceccarelli; Leeyoung; [email-masked]
抄送: [email-masked]
主题: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Danielle,

Cheers,
Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, May 19, 2017 4:19 PM
To: Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi Young, all,

BR
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 24 May 2017 12:26:21 +0000

Hi Cristina,

I didn’t say that ns has nothing to do with radio. I said that ns *may* have nothing to do with radio, i.e. may support/enable network architectures that do not involve radio necessarily.

Igor

-----Original Message-----
From: qiangli (D) 
Sent: Wednesday, May 24, 2017 5:05 AM
To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
Cc: [email-masked]
Subject: 答复: [Teas] terminology discussion network slicing

Hi Igor,

Best regards,

Cristina QIANG

-----邮件原件-----
发件人: Igor Bryskin 
发送时间: 2017年5月20日 23:50
收件人: qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
抄送: [email-masked]
主题: RE: [Teas] terminology discussion network slicing

Hi Cristina,

Cheers,
Igor

-----Original Message-----
From: qiangli (D)
Sent: Saturday, May 20, 2017 5:27 AM
To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
Cc: [email-masked]
Subject: 答复: [Teas] terminology discussion network slicing

Hi Igor,

Best regards,

Qiang, Li (Cristina)
NetLab, Huawei

-----邮件原件-----
发件人: Netslices [mailto:[email-masked]] 代表 Igor Bryskin
发送时间: 2017年5月20日 6:12
收件人: Daniele Ceccarelli; Leeyoung; [email-masked]
抄送: [email-masked]
主题: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Danielle,

Cheers,
Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, May 19, 2017 4:19 PM
To: Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi Young, all,

BR
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 24 May 2017 12:36:30 +0000

Hi Cristina,

You said:

[Cr] 

On this I fully agree with you. Dynamically re-configurable L3/L2 network topologies supported by hard separation transport connectivity (such as OTN or FlexE) have a potential to deliver far better level of separation than legacy L2/K3 VPNs. The work done in TEAS WG can greatly help the IETF network slicing story.

Cheers,
Igor  

-----Original Message-----
From: qiangli (D) 
Sent: Wednesday, May 24, 2017 4:40 AM
To: Daniele Ceccarelli; Igor Bryskin; Leeyoung; [email-masked]
Cc: [email-masked]
Subject: 答复: [Teas] terminology discussion network slicing

Hi Danielle and Igor,

Best regards,

Cristina QIANG

-----邮件原件-----
发件人: Netslices [mailto:[email-masked]] 代表 Daniele Ceccarelli
发送时间: 2017年5月24日 5:01
收件人: Igor Bryskin; Leeyoung; [email-masked]
抄送: [email-masked]
主题: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Igor,

Cheers

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: sabato 20 maggio 2017 00:12
To: Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Danielle,

 The questions are:

Cheers,
Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Friday, May 19, 2017 4:19 PM
To: Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi Young, all,

BR
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 24 May 2017 05:45:01 -0700

+1 Igor

>From transport side (L0-L3) we need to expose set of API’s that would allow to request a set of resources (a slice) either virtualized of physical that meet the constrains as requested by the business logic. Radio, while would definitely be one of most important use cases, would not be exclusively for radio use only. Any network management/ orchestration layer ideally should be able to use same set of API’s to request an e2e service.

Cheers,
Jeff

On 5/24/17, 05:26, "Teas on behalf of Igor Bryskin" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Cristina,

    Igor
    
    -----Original Message-----
    From: qiangli (D) 
    Sent: Wednesday, May 24, 2017 5:05 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Cristina QIANG

    -----邮件原件-----
    发件人: Igor Bryskin 
    发送时间: 2017年5月20日 23:50
    收件人: qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: RE: [Teas] terminology discussion network slicing
    
    Hi Cristina,

    Cheers,
    Igor
    
    -----Original Message-----
    From: qiangli (D)
    Sent: Saturday, May 20, 2017 5:27 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Qiang, Li (Cristina)
    NetLab, Huawei

    -----邮件原件-----
    发件人: Netslices [mailto:[email-masked]] 代表 Igor Bryskin
    发送时间: 2017年5月20日 6:12
    收件人: Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: Re: [Netslices] [Teas] terminology discussion network slicing
    
    Hi Danielle,

    Cheers,
    Igor

    
    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
    Sent: Friday, May 19, 2017 4:19 PM
    To: Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi Young, all,

    

    
    BR
    Daniele  

    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
    Sent: venerdì 19 maggio 2017 15:15
    To: [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi,

    

    
    
    Thanks,
    Young
    
    -----Original Message-----
    From: Lou Berger [mailto:[email-masked]]
    Sent: Tuesday, May 16, 2017 8:35 AM
    To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing

    Lou

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 24 May 2017 20:48:38 +0800

Hi Daniele,
thank you for your kind and thorough consideration, glad we agree on the
terminology. One minor, I think, note and the answer to your question under
GIM2>> tag in-line.

Regards,
Greg

On Wed, May 24, 2017 at 4:39 AM, Daniele Ceccarelli <
[email-masked]> wrote:

> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* sabato 20 maggio 2017 06:14
> *To:* Daniele Ceccarelli <[email-masked]>
> *Cc:* Leeyoung <[email-masked]>; [email-masked]; [email-masked]
> *Subject:* Re: [Netslices] [Teas] terminology discussion network slicing
>
>
>
> Hi Daniele,
>
> *[>DC] I should have said “this means that a network might not be JUST a
> VPN or a TE Tunnel” and hence agree with you on the fact that the VPN or
> the TE Tunnel could be part of the network slice. *
>
>
>
> *[>DC] This is another terminology issue. I agree on the separation
> between the RAN domain and the “transport” domain (let’s keep on using the
> work transport with quotation marks for the time being) and all the other
> domains in the network. IMO the network slice is the end to end entity that
> is built by a RAN slice plus a “transport” slice plus other potential
> slices. And the “transport” slice could be a VPN, a TE tunnel…*
>
GIM2>> If to a segment of a network slice instance in a core network we
refer as transport domain, then, as I understand, it's peer may be not only
RAN segment but, e.g., segment of an access network of another kind.

> *[>DC] WRT what? Do you mean wrt the fact that the relationship between
> e.g. the RAN slice and the “transport” slice could be client- server? I see
> it more a peering relationship. ON the other side WITHIN the “transport”
> slice you could have different layers with client-server relationship,
> that’s right.*
>
GIM2>> Yes, should have been clearer, it is the latter.

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 24 May 2017 12:55:54 +0000

Thanks Jeff,

I am glad we are in sync.

Igor

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2017 8:45 AM
To: Igor Bryskin; qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

+1 Igor

Cheers,
Jeff

    Hi Cristina,

    Igor
    
    -----Original Message-----
    From: qiangli (D) 
    Sent: Wednesday, May 24, 2017 5:05 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Cristina QIANG

    -----邮件原件-----
    发件人: Igor Bryskin 
    发送时间: 2017年5月20日 23:50
    收件人: qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: RE: [Teas] terminology discussion network slicing
    
    Hi Cristina,

    Cheers,
    Igor
    
    -----Original Message-----
    From: qiangli (D)
    Sent: Saturday, May 20, 2017 5:27 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Qiang, Li (Cristina)
    NetLab, Huawei

    -----邮件原件-----
    发件人: Netslices [mailto:[email-masked]] 代表 Igor Bryskin
    发送时间: 2017年5月20日 6:12
    收件人: Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: Re: [Netslices] [Teas] terminology discussion network slicing
    
    Hi Danielle,

    Cheers,
    Igor

    
    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
    Sent: Friday, May 19, 2017 4:19 PM
    To: Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi Young, all,

    

    
    BR
    Daniele  

    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
    Sent: venerdì 19 maggio 2017 15:15
    To: [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi,

    

    
    
    Thanks,
    Young
    
    -----Original Message-----
    From: Lou Berger [mailto:[email-masked]]
    Sent: Tuesday, May 16, 2017 8:35 AM
    To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing

    Lou

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 26 May 2017 02:35:44 +0000

Hi Igor, Cristina, 

Yes there are gaps in the legacy VPN technologies to meet the isolation requirement of network slicing. This needs to be further discussed in IETF to identify whether new work or enhancement is needed. I agree this is related to the work in TEAS WG.

Best regards,
Jie

> From: Teas [mailto:[email-masked]] On Behalf Of Igor Bryskin
> Sent: Wednesday, May 24, 2017 8:37 PM
> To: qiangli (D) <[email-masked]>; Daniele Ceccarelli
> <[email-masked]>; Leeyoung <[email-masked]>;
> [email-masked]
> Cc: [email-masked]
> 2) Unlike hard isolation technologies (e.g., FlexE), even bound to other
> TE-tunnel or resource reservation protocols, different VPNs still have the risk
> of underlying resource competition in extremes.
> 
> 
> On this I fully agree with you. Dynamically re-configurable L3/L2 network
> topologies supported by hard separation transport connectivity (such as OTN
> or FlexE) have a potential to deliver far better level of separation than legacy
> L2/K3 VPNs. The work done in TEAS WG can greatly help the IETF network
> slicing story.
> 
> Cheers,
> Igor
> 
> 
> Network slicing may have nothing to do with radio. 5g is just a big reason as
> to why the interest/focus is back on network slicing, which is a very old
> concept. I don't think that anyone is arguing with what you wrote.
> 
> [>DC] Whether the network slice has to do with radio depends on the
> definition of network slice. If we focus on the "transport" slice then I agree
> with you, but the network slice IMO spans multiple domains/segments and
> radio can be one of them (as well as e.g. the cloud)
> 
>  The questions are:
> [>DC]  I would say independently in each domain/segment and then at the
> orchestration level someone will be in charge to put the pieces together.
> >>[Cr] This question is related to the architecture of netslice. Daniele's
> answer is just one possibility (i.e, independently in each domain/segment + a
> common orchestration platform above). I can see another possibility that is
> independently each domain/segment + cross-domain/cross-segment
> negotiation & interoperation. IMO, the latter one may be more practical for
> netslice, since an end-to-end slice may involves different
> operators/administrative regions, and there does not exist a common
> platform.
> 
> [>DC] Again per domain/segment. In the cloud you might have different
> slices sharing the same VNG (e.g. IMS or Packet Core), while in the
> "transport" you might have different slices sharing a same tunnel or having
> dedicated one.
> 
> [>DC] IMO legacy VPNs are good enough as "transport" slice. There are
> several mechanisms to e.g. extend them from the "transport" domain to the
> cloud domain or to stitch them to e.g. VXLAN in the DC. They just need to be
> bound to a TE-tunnel or an ACTN VN if you want to have guaranteed SLA for
> the service using such VPN
> >>[Cr] I will not deny that VPN could be one of the solutions for network
> slicing. However, it still has some deficiencies:
> 2) Unlike hard isolation technologies (e.g., FlexE), even bound to other
> TE-tunnel or resource reservation protocols, different VPNs still have the risk
> of underlying resource competition in extremes.
> 
> 
> Cheers,
> Igor
> 
> 
> 
> 
> i agree with your conclusion but would like to clarify one thing that IMO got
> lost in the discussion since its beginning.
> 
> in the CLOUD domain, a "piece" in the TRANSPORT domain, plus possible
> other pieces in possible other domains.
> 
> TRANSPORT DOMAIN is that part of the network that is used to carry a
> packet between two other domains.
> engineered, hence it is all about building a TE entity and stitching services to
> such entity. This is what is in the ACTN scope.
> 
> slicing (cc'ed)" and the discussion about what that term means should be
> held on that list.
> 
> the terms used in the ACTN framework is limited to ACTN. That means
> effectively that if there are components of a wider definition of network
> slicing that are not supported by ACTN, that will be OK.
> 
> will allow this draft to move ahead without being blocked by the discussion
> in netslices. Once the IETF has a stable definition of network slicing we can
> return and see how ACTN is applicable to that definition an whether more
> wok is need (in a separate draft).
> 
> Thanks,
> Young
> 
> their reaponse....

---

From: "sebastian" <[email-masked]>
Date: Sat, 27 May 2017 14:13:00 -0500

Hello, Greg,

Concur with the following generalized definition of a network slice:

The existence certain artifacts, such as tunnels or other attributes that in unison provide some capability, does not alter the notion that it is still some arrangement of resources (e.g. functions, storage, spectrum etc.)

The scope of a network slice must also be extensible to any set of endpoints (e.g. orchestration across multiple administrative domains).

Many thanks.

-Sebastian

From: Netslices [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Wednesday, May 24, 2017 7:49 AM
To: Daniele Ceccarelli <[email-masked]>
Cc: Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Daniele,

thank you for your kind and thorough consideration, glad we agree on the terminology. One minor, I think, note and the answer to your question under GIM2>> tag in-line.

Regards,

Greg

On Wed, May 24, 2017 at 4:39 AM, Daniele Ceccarelli <[email-masked] <mailto:[email-masked]> > wrote:

Hi Greg,

Cheers

Daniele  

From: Greg Mirsky [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: sabato 20 maggio 2017 06:14
To: Daniele Ceccarelli <[email-masked] <mailto:[email-masked]> >
Cc: Leeyoung <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Daniele,

Regards,

Greg

On Sat, May 20, 2017 at 4:18 AM, Daniele Ceccarelli <[email-masked] <mailto:[email-masked]> > wrote:

Hi Young, all,

GIM2>> If to a segment of a network slice instance in a core network we refer as transport domain, then, as I understand, it's peer may be not only RAN segment but, e.g., segment of an access network of another kind. 

BR
Daniele

-----Original Message-----
From: Teas [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked] <mailto:[email-masked]> >; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked] <mailto:[email-masked]> >; Gert Grammel <[email-masked] <mailto:[email-masked]> >; Leeyoung <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Teas] terminology discussion network slicing

Lou

On May 16, 2017 8:31:19 AM Igor Bryskin <[email-masked] <mailto:[email-masked]> > wrote:

> From: Teas [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Belotti, Sergio
> (Nokia - IT/Vimercate)
> To: Gert Grammel; Leeyoung; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
> From: Teas [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Gert Grammel
> To: Leeyoung <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
> <[email-masked] <mailto:[email-masked]>  on behalf of [email-masked] <mailto:[email-masked]> > wrote:
>
>     Hi Adrian and others,
>
>     To: [email-masked] <mailto:[email-masked]> 
>     From: Teas [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of [email-masked] <mailto:[email-masked]> 
>     To: [email-masked] <mailto:[email-masked]> 
>     Cc: [email-masked] <mailto:[email-masked]> 
>     submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> .
>
>     [email-masked] <mailto:[email-masked]> 
>     [email-masked] <mailto:[email-masked]> 
> [email-masked] <mailto:[email-masked]> 
> [email-masked] <mailto:[email-masked]> 
> [email-masked] <mailto:[email-masked]> 

_______________________________________________
Teas mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/teas

_______________________________________________
Netslices mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/netslices

---

From: "sebastian" <[email-masked]>
Date: Sun, 28 May 2017 00:12:02 -0500

Hello, Jeff,

Agree with your view that the scope (core and/or radio layer) of a 'network slice' could vary depending on the triggers for instantiating the 'network slice'.

On the other hand the instantiation of a 'network slice' may also be e2e (end-to-end), such as in device roaming scenarios, or in the case of vertical services that span different service providers.

The span of a 'network slice' is only limited by the availability of resources and appropriate policies (e.g. SLAs), independent of whether those resources are in the core network layer or in the radio network layer.

The management and orchestration of resources should be capable of instantiating a 'network slice' with an e2e (end-to-end) scope, where the scope could be between two devices, connected across intervening radio networks and core networks that may belong to the same or different administrative domains.

Many thanks.
-Sebastian

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, May 24, 2017 7:56 AM
To: Jeff Tantsura <[email-masked]>; qiangli (D) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Thanks Jeff,

Igor

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2017 8:45 AM
To: Igor Bryskin; qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

+1 Igor

Cheers,
Jeff

    Hi Cristina,

    Igor
    
    -----Original Message-----
    From: qiangli (D) 
    Sent: Wednesday, May 24, 2017 5:05 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Cristina QIANG

    -----邮件原件-----
    发件人: Igor Bryskin 
    发送时间: 2017年5月20日 23:50
    收件人: qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: RE: [Teas] terminology discussion network slicing
    
    Hi Cristina,

    Cheers,
    Igor
    
    -----Original Message-----
    From: qiangli (D)
    Sent: Saturday, May 20, 2017 5:27 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Qiang, Li (Cristina)
    NetLab, Huawei

    -----邮件原件-----
    发件人: Netslices [mailto:[email-masked]] 代表 Igor Bryskin
    发送时间: 2017年5月20日 6:12
    收件人: Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: Re: [Netslices] [Teas] terminology discussion network slicing
    
    Hi Danielle,

    Cheers,
    Igor

    
    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
    Sent: Friday, May 19, 2017 4:19 PM
    To: Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi Young, all,

    

    
    BR
    Daniele  

    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
    Sent: venerdì 19 maggio 2017 15:15
    To: [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi,

    

    
    
    Thanks,
    Young
    
    -----Original Message-----
    From: Lou Berger [mailto:[email-masked]]
    Sent: Tuesday, May 16, 2017 8:35 AM
    To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing

    Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 29 May 2017 08:04:10 +0000

Hi Greg,

GIM2>> If to a segment of a network slice instance in a core network we refer as transport domain, then, as I understand, it's peer may be not only RAN segment but, e.g., segment of an access network of another kind

Yep, totally agree.

Cheers
Daniele

Sent: mercoledì 24 maggio 2017 14:49

Hi Daniele,

Regards,
Greg

On Wed, May 24, 2017 at 4:39 AM, Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Cheers
Daniele

From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: sabato 20 maggio 2017 06:14
To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>
Cc: Leeyoung <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Daniele,

Regards,
Greg

BR
Daniele

-----Original Message-----
From: Teas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>; Gert Grammel <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 29 May 2017 08:08:17 +0000

Hi Sebastian,

this definition IMHO is so generalized that is always correct but at the same time too vague that is prone to different interpretations.

We all started from this definition and came out with so many different points of view. According to this definition a network slice can be almost everything.

BR
Daniele

From: sebastian [mailto:[email-masked]]
Sent: sabato 27 maggio 2017 21:13
To: 'Greg Mirsky' <[email-masked]>
Cc: 'Leeyoung' <[email-masked]>; [email-masked]; [email-masked]; Daniele Ceccarelli <[email-masked]>
Subject: RE: [Netslices] [Teas] terminology discussion network slicing

Hello, Greg,

Many thanks.
-Sebastian

Cc: Leeyoung <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Daniele,

Regards,
Greg

Cheers
Daniele

Hi Daniele,

Regards,
Greg

BR
Daniele

-----Original Message-----
From: Teas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Leeyoung
Sent: venerdì 19 maggio 2017 15:15
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] terminology discussion network slicing

Hi,

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 16, 2017 8:35 AM
To: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>; Gert Grammel <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] terminology discussion network slicing

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 29 May 2017 09:01:19 +0000

Hi Sebastian, Jeff, Igor, all,

I understand Jeff and Igor agree on the fact that a network slice does not necessarily include resources in the radio segment/domain and in the packet core one.
An example could be an enterprise with dedicated resources in the "transport" segment (e.g. VPN, VN and TE-tunnels) that connect the customer premises to a data center where a number of VNF (e.g. firewall, nat, dpi) is dedicated to that given customer.
My personal opinion is that this should be considered a network slice.

The definition of network slice should allow for this scenario and mostly should clearly state whether this is included or not. 

Sebastian, I don't understand if your statement: 
" The management and orchestration of resources should be capable of instantiating a 'network slice' with an e2e (end-to-end) scope, where the scope could be between two devices, connected across intervening radio networks and core networks that may belong to the same or different administrative domains."
implies that there must be a radio and a core segment in order to have a slice.

BR
Daniele  

-----Original Message-----
From: sebastian [mailto:[email-masked]] 
Sent: domenica 28 maggio 2017 07:12
To: 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; Daniele Ceccarelli <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Netslices] [Teas] terminology discussion network slicing

Hello, Jeff,

Many thanks.
-Sebastian

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, May 24, 2017 7:56 AM
To: Jeff Tantsura <[email-masked]>; qiangli (D) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Thanks Jeff,

Igor

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2017 8:45 AM
To: Igor Bryskin; qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

+1 Igor

Cheers,
Jeff

    Hi Cristina,

    Igor
    
    -----Original Message-----
    From: qiangli (D) 
    Sent: Wednesday, May 24, 2017 5:05 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Cristina QIANG

    -----邮件原件-----
    发件人: Igor Bryskin 
    发送时间: 2017年5月20日 23:50
    收件人: qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: RE: [Teas] terminology discussion network slicing
    
    Hi Cristina,

    Cheers,
    Igor
    
    -----Original Message-----
    From: qiangli (D)
    Sent: Saturday, May 20, 2017 5:27 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Qiang, Li (Cristina)
    NetLab, Huawei

    -----邮件原件-----
    发件人: Netslices [mailto:[email-masked]] 代表 Igor Bryskin
    发送时间: 2017年5月20日 6:12
    收件人: Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: Re: [Netslices] [Teas] terminology discussion network slicing
    
    Hi Danielle,

    Cheers,
    Igor

    
    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
    Sent: Friday, May 19, 2017 4:19 PM
    To: Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi Young, all,

    

    
    BR
    Daniele  

    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
    Sent: venerdì 19 maggio 2017 15:15
    To: [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi,

    

    
    
    Thanks,
    Young
    
    -----Original Message-----
    From: Lou Berger [mailto:[email-masked]]
    Sent: Tuesday, May 16, 2017 8:35 AM
    To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing

    Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 29 May 2017 09:12:48 +0000

Hi Jie, all,

The lack of VPN isolation is a problem wider than the network slicing. Please find below a reference to the work we started on the mapping between services (e.g. L3VPN, L2VPN) and traffic engineering infrastructures (i.e. TE-tunnels, ACTN VNs).

https://tools.ietf.org/id/draft-lee-teas-te-service-mapping-yang-00.txt

Abstract

   This document provides a YANG data model to map service model (e.g.
   L3SM) and Traffic Engineering model (e.g. TE Tunnel or ACTN VN
   model). This model is referred to as TE service Mapping Model. This
   model is applicable to the operation's need for a seamless control
   and management of their L3VPN with TE tunnel support.

Hope this helps

BR
Daniele  

-----Original Message-----
From: Dongjie (Jimmy) [mailto:[email-masked]] 
Sent: venerdì 26 maggio 2017 04:36
To: Igor Bryskin <[email-masked]>; qiangli (D) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Teas] terminology discussion network slicing

Hi Igor, Cristina, 

Best regards,
Jie

> 2) Unlike hard isolation technologies (e.g., FlexE), even bound to 
> other TE-tunnel or resource reservation protocols, different VPNs 
> still have the risk of underlying resource competition in extremes.
> 
> 
> On this I fully agree with you. Dynamically re-configurable L3/L2 
> network topologies supported by hard separation transport connectivity 
> (such as OTN or FlexE) have a potential to deliver far better level of 
> separation than legacy
> Network slicing may have nothing to do with radio. 5g is just a big 
> reason as to why the interest/focus is back on network slicing, which 
> is a very old concept. I don't think that anyone is arguing with what you wrote.
> 
> definition of network slice. If we focus on the "transport" slice then 
> I agree with you, but the network slice IMO spans multiple 
> domains/segments and radio can be one of them (as well as e.g. the 
> cloud)
> 
>  The questions are:
> [>DC]  I would say independently in each domain/segment and then at 
> the orchestration level someone will be in charge to put the pieces together.
> answer is just one possibility (i.e, independently in each 
> domain/segment + a common orchestration platform above). I can see 
> another possibility that is independently each domain/segment + 
> cross-domain/cross-segment negotiation & interoperation. IMO, the 
> latter one may be more practical for netslice, since an end-to-end 
> slice may involves different operators/administrative regions, and 
> there does not exist a common platform.
> 
> "transport" you might have different slices sharing a same tunnel or 
> having dedicated one.
> 
> several mechanisms to e.g. extend them from the "transport" domain to 
> the cloud domain or to stitch them to e.g. VXLAN in the DC. They just 
> need to be bound to a TE-tunnel or an ACTN VN if you want to have 
> guaranteed SLA for the service using such VPN
> 2) Unlike hard isolation technologies (e.g., FlexE), even bound to 
> other TE-tunnel or resource reservation protocols, different VPNs 
> still have the risk of underlying resource competition in extremes.
> 
> 
> Cheers,
> Igor
> 
> 
> 
> 
> i agree with your conclusion but would like to clarify one thing that 
> IMO got lost in the discussion since its beginning.
> 
> "A set of network functions and the resources for these network 
> functions which are arranged and configured, forming a complete 
> logical network to meet certain network characteristics."
> 
> A network slice is "something" (netslices and 3GPP will define what 
> this something is) that is composed by a "piece" in the RADIO domain, a "piece"
> In order to have a slice, that portion of the transport domain needs 
> to be engineered, hence it is all about building a TE entity and 
> stitching services to such entity. This is what is in the ACTN scope.
> 
> My very personal opinion is that whatever belongs to the transport 
> domain belongs to IETF (and is already being addressed), while the 
> rest is a dangerous duplication of concepts standardized is other 
> SDOs...but this is another discussion that doesn't fit here.
> 
> BR
> Daniele
> 
> 
> "network slicing (cc'ed)" and the discussion about what that term 
> means should be held on that list.
> 
> terminology means in the context of ACTN. We are not trying to define 
> or redefine "network slicing" in the ACTN document, but are trying to 
> make it clear how ACTN works.
> 
> 1. All discussion of the general applicability and definition of 
> "network slicing" is held on the netslices mailing list.
> 
> definition of the terms used in the ACTN framework is limited to ACTN. 
> That means effectively that if there are components of a wider 
> definition of network slicing that are not supported by ACTN, that will be OK.
> 
> I propose to post an updated version in the next few days and I 
> believe that will allow this draft to move ahead without being blocked 
> by the discussion in netslices. Once the IETF has a stable definition 
> of network slicing we can return and see how ACTN is applicable to 
> that definition an whether more wok is need (in a separate draft).
> 
> Thanks,
> Young
> 
> > My understanding is that the difference in the separation (in terms 
> > of control and data planes, security, etc.). For example, 
> > traditional BGP based L3 VPNs (that use provider's common control 
> > plane for their management and IP/MPLS TE tunnels to inter-connect 
> > their PEs) will probably not be able guarantee for the clients msec 
> > range connectivity setup times required by 5g, while provided by the 
> > same provider fully separated/genuinely private IP/MPLS networks 
> > (that do not share IP/MPLS control plane and infrastructure, whose 
> > network topology is supported by separate L0/L1 connections) 
> > hopefully will be able to provide such guarantees. Therefore, I 
> > define layer network slices as dynamically managed fully isolated in 
> > control and data planes private TE layer networks, which may share 
> > one or more underlying server layer
> networks.
> >
> >
> > Cheers,
> > Igor
> >
> >
> >
> >
> > From: Teas [mailto:[email-masked]] On Behalf Of Belotti, 
> > Sergio (Nokia - IT/Vimercate)
> > "Thinking a bit about it I came to the point where "VPN" and 
> > "network slices" seem to describe the same entity or at least a "network slice"
> > being a VPN of VPNs?"
> >
> > definition, I try to establish what kind of existing constructs 
> > would fall under the definition. If my understanding is correct, the 
> >     This update is intended to incorporate the comments from the 
> > last
> WG
> >     changes to make it consistent through the document. Major 
> > changes
> are:
> >
> >     - Inclusion of "network slicing" definition from ACTN 
> > perspective (in
> the
> >     terminology section)
> >     - Added virtual network service (VNS) section (Section 3) to 
> > define
> types
> >     of VNS.
> >     Orchestrator (Appendix A) and example of IP + Optical network 
> > with
> L3VPN
> >     service (Appendix B)
> >
> >     In regard to ACTN abstraction method draft, we are going to keep 
> > it as
> a
> >     The following diff pointer will help you see the changes with 
> > this
> revision:
> >
> >     A New Internet-Draft is available from the on-line 
> > Internet-Drafts
> directories.
> >        This document provides a framework for Abstraction and 
> > Control
> of

---

From: Gert Grammel <[email-masked]>
Date: Mon, 29 May 2017 13:33:32 +0000

Daniele,

Trying to summarize what you're saying: a Network slice is an overlay network with minimum service guarantees, including virtual network functions available in this overlay network.  
In your text I have issues with "dedicated to a given customer". Whether such construct is dedicated to one or shared among several legal customers shouldn't be of concern for the definition of a Network Slice.
On similar terms, whether a resource (being a NF or transport capacity) is shared or not is a design choice rather than a definition. In particular, Multiplexer by definition share some sort of common capacity irrespective whether it is TDM, Packet, WDM or CDM. So, the nature of multiplexing technique shouldn't be a definition criteria for a Network Slice either.

Another food for thought:
- I would also add that a network slice may use it's own internal addressing scheme isolated from other slices. While this is optional, I would expect it to be used quite often. 
- Why is it necessary to dedicate resources to a "Network Slice" at all? If e.g. a firewall NFV is in the DC and communicates over the Internet with a CPE (both belonging to a single owner) it would not fulfil the criteria of dedicated resource (Internet after all isn't dedicated), but it still looks pretty much like a "network slice".

Gert 

On 2017-05-29, 11:01, "Teas on behalf of Daniele Ceccarelli" <[email-masked] on behalf of [email-masked]> wrote:

    

    BR
    Daniele  

    -----Original Message-----
    From: sebastian [mailto:[email-masked]] 
    Sent: domenica 28 maggio 2017 07:12
    To: 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; Daniele Ceccarelli <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
    Cc: [email-masked]
    Subject: RE: [Netslices] [Teas] terminology discussion network slicing
    
    Hello, Jeff,

    

    Many thanks.
    -Sebastian

    -----Original Message-----
    From: Netslices [mailto:[email-masked]] On Behalf Of Igor Bryskin
    Sent: Wednesday, May 24, 2017 7:56 AM
    To: Jeff Tantsura <[email-masked]>; qiangli (D) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Netslices] [Teas] terminology discussion network slicing
    
    Thanks Jeff,

    Igor
    
    -----Original Message-----
    From: Jeff Tantsura [mailto:[email-masked]] 
    Sent: Wednesday, May 24, 2017 8:45 AM
    To: Igor Bryskin; qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    +1 Igor

    Cheers,
    Jeff

        Hi Cristina,

        Igor
        
        -----Original Message-----
        From: qiangli (D) 
        Sent: Wednesday, May 24, 2017 5:05 AM
        To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
        Cc: [email-masked]
        Subject: 答复: [Teas] terminology discussion network slicing
        
        Hi Igor,

        Best regards,
        
        Cristina QIANG

        -----邮件原件-----
        发件人: Igor Bryskin 
        发送时间: 2017年5月20日 23:50
        收件人: qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
        抄送: [email-masked]
        主题: RE: [Teas] terminology discussion network slicing
        
        Hi Cristina,

        Cheers,
        Igor
        
        -----Original Message-----
        From: qiangli (D)
        Sent: Saturday, May 20, 2017 5:27 AM
        To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
        Cc: [email-masked]
        Subject: 答复: [Teas] terminology discussion network slicing
        
        Hi Igor,

        Best regards,
        
        Qiang, Li (Cristina)
        NetLab, Huawei

        -----邮件原件-----
        发件人: Netslices [mailto:[email-masked]] 代表 Igor Bryskin
        发送时间: 2017年5月20日 6:12
        收件人: Daniele Ceccarelli; Leeyoung; [email-masked]
        抄送: [email-masked]
        主题: Re: [Netslices] [Teas] terminology discussion network slicing
        
        Hi Danielle,

        Cheers,
        Igor

        
        -----Original Message-----
        From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
        Sent: Friday, May 19, 2017 4:19 PM
        To: Leeyoung; [email-masked]
        Cc: [email-masked]
        Subject: Re: [Teas] terminology discussion network slicing
        
        Hi Young, all,

        

        
        BR
        Daniele  

        -----Original Message-----
        From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
        Sent: venerdì 19 maggio 2017 15:15
        To: [email-masked]
        Cc: [email-masked]
        Subject: Re: [Teas] terminology discussion network slicing
        
        Hi,

        

        
        
        Thanks,
        Young
        
        -----Original Message-----
        From: Lou Berger [mailto:[email-masked]]
        Sent: Tuesday, May 16, 2017 8:35 AM
        To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
        Subject: Re: [Teas] terminology discussion network slicing

        Lou

---

From: "sebastian" <[email-masked]>
Date: Mon, 29 May 2017 11:12:35 -0500

Hello, Daniele,

Appreciate your query.

Yes, the following statement, implies a network slice being instantiated includes the necessary resources, across any intervening core, and radio access networks, between a source device (entity) and a destination device (entity):
"The management and orchestration of resources should be capable of instantiating a 'network slice' with an e2e (end-to-end) scope, where the scope could be between two devices, connected across intervening radio networks and core networks that may belong to the same or different administrative domains."

The maximum scope of an e2e network slice instantiation, would be between two devices (entities), connected via intervening administrative domains)
Shorter spans of a network slice may be instantiated to suit other scenarios (e.g. between any two any entities, such as within a network, where one entity may require the services of another etc.)

All resources, associated with a network slice that is instantiated, may not be subject to virtualization (e.g. physical entities, such as antenna elements, which require a physical geometry.)

Many thanks.,
   Sebastian

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Monday, May 29, 2017 4:01 AM
To: [email-masked]; 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Netslices] [Teas] terminology discussion network slicing

BR
Daniele  

-----Original Message-----
From: sebastian [mailto:[email-masked]] 
Sent: domenica 28 maggio 2017 07:12
To: 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; Daniele Ceccarelli <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Netslices] [Teas] terminology discussion network slicing

Hello, Jeff,

Many thanks.
-Sebastian

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, May 24, 2017 7:56 AM
To: Jeff Tantsura <[email-masked]>; qiangli (D) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Thanks Jeff,

Igor

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2017 8:45 AM
To: Igor Bryskin; qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

+1 Igor

Cheers,
Jeff

    Hi Cristina,

    Igor
    
    -----Original Message-----
    From: qiangli (D) 
    Sent: Wednesday, May 24, 2017 5:05 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Cristina QIANG

    -----邮件原件-----
    发件人: Igor Bryskin 
    发送时间: 2017年5月20日 23:50
    收件人: qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: RE: [Teas] terminology discussion network slicing
    
    Hi Cristina,

    Cheers,
    Igor
    
    -----Original Message-----
    From: qiangli (D)
    Sent: Saturday, May 20, 2017 5:27 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Qiang, Li (Cristina)
    NetLab, Huawei

    -----邮件原件-----
    发件人: Netslices [mailto:[email-masked]] 代表 Igor Bryskin
    发送时间: 2017年5月20日 6:12
    收件人: Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: Re: [Netslices] [Teas] terminology discussion network slicing
    
    Hi Danielle,

    Cheers,
    Igor

    
    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
    Sent: Friday, May 19, 2017 4:19 PM
    To: Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi Young, all,

    

    
    BR
    Daniele  

    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
    Sent: venerdì 19 maggio 2017 15:15
    To: [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi,

    

    
    
    Thanks,
    Young
    
    -----Original Message-----
    From: Lou Berger [mailto:[email-masked]]
    Sent: Tuesday, May 16, 2017 8:35 AM
    To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing

    Lou

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Mon, 29 May 2017 16:29:05 +0000

Network slice is end-to-end concept in other SDOs, like in 3GPP and in NGMN descriptions. It will be highly confusing if the IETF ends up with some other scope.

Best regards
Hannu

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of sebastian
Sent: Sunday, May 28, 2017 8:12 AM
To: 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; 'Daniele Ceccarelli' <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Hello, Jeff,

Many thanks.
-Sebastian

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, May 24, 2017 7:56 AM
To: Jeff Tantsura <[email-masked]>; qiangli (D) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Thanks Jeff,

Igor

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2017 8:45 AM
To: Igor Bryskin; qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

+1 Igor

Cheers,
Jeff

    Hi Cristina,

    Igor
    
    -----Original Message-----
    From: qiangli (D) 
    Sent: Wednesday, May 24, 2017 5:05 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Cristina QIANG

    -----邮件原件-----
    发件人: Igor Bryskin 
    发送时间: 2017年5月20日 23:50
    收件人: qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: RE: [Teas] terminology discussion network slicing
    
    Hi Cristina,

    Cheers,
    Igor
    
    -----Original Message-----
    From: qiangli (D)
    Sent: Saturday, May 20, 2017 5:27 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Qiang, Li (Cristina)
    NetLab, Huawei

    -----邮件原件-----
    发件人: Netslices [mailto:[email-masked]] 代表 Igor Bryskin
    发送时间: 2017年5月20日 6:12
    收件人: Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: Re: [Netslices] [Teas] terminology discussion network slicing
    
    Hi Danielle,

    Cheers,
    Igor

    
    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
    Sent: Friday, May 19, 2017 4:19 PM
    To: Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi Young, all,

    

    
    BR
    Daniele  

    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
    Sent: venerdì 19 maggio 2017 15:15
    To: [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi,

    

    
    
    Thanks,
    Young
    
    -----Original Message-----
    From: Lou Berger [mailto:[email-masked]]
    Sent: Tuesday, May 16, 2017 8:35 AM
    To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing

    Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 30 May 2017 08:17:37 +0000

Ciao Gert,

Please see in line
Cheers
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Gert Grammel
Sent: lunedì 29 maggio 2017 15:34
To: Daniele Ceccarelli <[email-masked]>; [email-masked]; 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] [Netslices] terminology discussion network slicing

Daniele,

Trying to summarize what you're saying: a Network slice is an overlay network with minimum service guarantees, including virtual network functions available in this overlay network.  
[>DC] why do you speak about an overlay network? If for example you have a site connected with a lambda to a data center and there you have a number of VNF, that's IMO a slice but there is no overlay. I'd say that there could be an overlay but that's not mandatory.

In your text I have issues with "dedicated to a given customer". Whether such construct is dedicated to one or shared among several legal customers shouldn't be of concern for the definition of a Network Slice.
[>DC] Correct, it should be possible to have it dedicated or shared. We just need to make sure that both options are supported.  

Another food for thought:
- I would also add that a network slice may use it's own internal addressing scheme isolated from other slices. While this is optional, I would expect it to be used quite often. 
[>DC] agree. Ala VPN.
- Why is it necessary to dedicate resources to a "Network Slice" at all? If e.g. a firewall NFV is in the DC and communicates over the Internet with a CPE (both belonging to a single owner) it would not fulfil the criteria of dedicated resource (Internet after all isn't dedicated), but it still looks pretty much like a "network slice".
[>DC] Think of remote surgery...wouldn't you want every single part of the end to end network from the doctor's hands to the scalpel being totally dedicated? :) ...and in that case I don't think the packets would go through the internet

Gert 

    

    
    BR
    Daniele  

    -----Original Message-----
    From: sebastian [mailto:[email-masked]] 
    Sent: domenica 28 maggio 2017 07:12
    To: 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; Daniele Ceccarelli <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
    Cc: [email-masked]
    Subject: RE: [Netslices] [Teas] terminology discussion network slicing
    
    Hello, Jeff,

    

    Many thanks.
    -Sebastian

    -----Original Message-----
    From: Netslices [mailto:[email-masked]] On Behalf Of Igor Bryskin
    Sent: Wednesday, May 24, 2017 7:56 AM
    To: Jeff Tantsura <[email-masked]>; qiangli (D) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Netslices] [Teas] terminology discussion network slicing
    
    Thanks Jeff,

    Igor
    
    -----Original Message-----
    From: Jeff Tantsura [mailto:[email-masked]] 
    Sent: Wednesday, May 24, 2017 8:45 AM
    To: Igor Bryskin; qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    +1 Igor

    Cheers,
    Jeff

        Hi Cristina,

        Igor
        
        -----Original Message-----
        From: qiangli (D) 
        Sent: Wednesday, May 24, 2017 5:05 AM
        To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
        Cc: [email-masked]
        Subject: 答复: [Teas] terminology discussion network slicing
        
        Hi Igor,

        Best regards,
        
        Cristina QIANG

        -----邮件原件-----
        发件人: Igor Bryskin 
        发送时间: 2017年5月20日 23:50
        收件人: qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
        抄送: [email-masked]
        主题: RE: [Teas] terminology discussion network slicing
        
        Hi Cristina,

        Cheers,
        Igor
        
        -----Original Message-----
        From: qiangli (D)
        Sent: Saturday, May 20, 2017 5:27 AM
        To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
        Cc: [email-masked]
        Subject: 答复: [Teas] terminology discussion network slicing
        
        Hi Igor,

        Best regards,
        
        Qiang, Li (Cristina)
        NetLab, Huawei

        -----邮件原件-----
        发件人: Netslices [mailto:[email-masked]] 代表 Igor Bryskin
        发送时间: 2017年5月20日 6:12
        收件人: Daniele Ceccarelli; Leeyoung; [email-masked]
        抄送: [email-masked]
        主题: Re: [Netslices] [Teas] terminology discussion network slicing
        
        Hi Danielle,

        Cheers,
        Igor

        
        -----Original Message-----
        From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
        Sent: Friday, May 19, 2017 4:19 PM
        To: Leeyoung; [email-masked]
        Cc: [email-masked]
        Subject: Re: [Teas] terminology discussion network slicing
        
        Hi Young, all,

        

        
        BR
        Daniele  

        -----Original Message-----
        From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
        Sent: venerdì 19 maggio 2017 15:15
        To: [email-masked]
        Cc: [email-masked]
        Subject: Re: [Teas] terminology discussion network slicing
        
        Hi,

        

        
        
        Thanks,
        Young
        
        -----Original Message-----
        From: Lou Berger [mailto:[email-masked]]
        Sent: Tuesday, May 16, 2017 8:35 AM
        To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
        Subject: Re: [Teas] terminology discussion network slicing

        Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 30 May 2017 08:28:47 +0000

Hi Sebastian,

let me use the remote surgery simple use case once again, where you have a doctor sitting in his office in New Jersey connected with his super high bandwidth and super low latency fiber (fixed) connection and a patient having surgery in California, where the connection is again fixed and the two sites being connected by a dedicated connection provided ad hoc by Verizon or AT&T (or both) and obviously not using the internet.

Wouldn't you call that a network slice?

BR
Daniele  

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of sebastian
Sent: lunedì 29 maggio 2017 18:13
To: Daniele Ceccarelli <[email-masked]>; [email-masked]; 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] [Netslices] terminology discussion network slicing

Hello, Daniele,

Appreciate your query.

The maximum scope of an e2e network slice instantiation, would be between two devices (entities), connected via intervening administrative domains) Shorter spans of a network slice may be instantiated to suit other scenarios (e.g. between any two any entities, such as within a network, where one entity may require the services of another etc.)

Many thanks.,
   Sebastian

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Monday, May 29, 2017 4:01 AM
To: [email-masked]; 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Netslices] [Teas] terminology discussion network slicing

BR
Daniele  

-----Original Message-----
From: sebastian [mailto:[email-masked]]
Sent: domenica 28 maggio 2017 07:12
To: 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; Daniele Ceccarelli <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Netslices] [Teas] terminology discussion network slicing

Hello, Jeff,

Many thanks.
-Sebastian

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, May 24, 2017 7:56 AM
To: Jeff Tantsura <[email-masked]>; qiangli (D) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Thanks Jeff,

Igor

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]]
Sent: Wednesday, May 24, 2017 8:45 AM
To: Igor Bryskin; qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] terminology discussion network slicing

+1 Igor

Cheers,
Jeff

    Hi Cristina,

    Igor
    
    -----Original Message-----
    From: qiangli (D) 
    Sent: Wednesday, May 24, 2017 5:05 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Cristina QIANG

    -----邮件原件-----
    发件人: Igor Bryskin 
    发送时间: 2017年5月20日 23:50
    收件人: qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: RE: [Teas] terminology discussion network slicing
    
    Hi Cristina,

    Cheers,
    Igor
    
    -----Original Message-----
    From: qiangli (D)
    Sent: Saturday, May 20, 2017 5:27 AM
    To: Igor Bryskin; Daniele Ceccarelli; Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: 答复: [Teas] terminology discussion network slicing
    
    Hi Igor,

    Best regards,
    
    Qiang, Li (Cristina)
    NetLab, Huawei

    -----邮件原件-----
    发件人: Netslices [mailto:[email-masked]] 代表 Igor Bryskin
    发送时间: 2017年5月20日 6:12
    收件人: Daniele Ceccarelli; Leeyoung; [email-masked]
    抄送: [email-masked]
    主题: Re: [Netslices] [Teas] terminology discussion network slicing
    
    Hi Danielle,

    Cheers,
    Igor

    
    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
    Sent: Friday, May 19, 2017 4:19 PM
    To: Leeyoung; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi Young, all,

    

    
    BR
    Daniele  

    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
    Sent: venerdì 19 maggio 2017 15:15
    To: [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing
    
    Hi,

    

    
    
    Thanks,
    Young
    
    -----Original Message-----
    From: Lou Berger [mailto:[email-masked]]
    Sent: Tuesday, May 16, 2017 8:35 AM
    To: Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [Teas] terminology discussion network slicing

    Lou

---

From: Gert Grammel <[email-masked]>
Date: Tue, 30 May 2017 11:17:13 +0000

Hi Daniele,

See below for more details:

On 2017-05-30, 10:17, "Daniele Ceccarelli" <[email-masked]> wrote:

    Ciao Gert,
    
    Please see in line
    Cheers
    Daniele  

    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Gert Grammel
    Sent: lunedì 29 maggio 2017 15:34
    To: Daniele Ceccarelli <[email-masked]>; [email-masked]; 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] [Netslices] terminology discussion network slicing
    
    Daniele,
    
    Trying to summarize what you're saying: a Network slice is an overlay network with minimum service guarantees, including virtual network functions available in this overlay network.  
    [>DC] why do you speak about an overlay network? If for example you have a site connected with a lambda to a data center and there you have a number of VNF, that's IMO a slice but there is no overlay. I'd say that there could be an overlay but that's not mandatory.
GGR> A Lambda travels through a WDM which is a Multiplexer (see discussion below). So a lambda is in my view an overlay, the multiplexed signal (OMS) being the underlay.    

    In your text I have issues with "dedicated to a given customer". Whether such construct is dedicated to one or shared among several legal customers shouldn't be of concern for the definition of a Network Slice.
    [>DC] Correct, it should be possible to have it dedicated or shared. We just need to make sure that both options are supported.  
GGR>> So if it can either be dedicated or shared, why mentioning this at all? Is there anything else?    

    [>DC] Think of remote surgery...wouldn't you want every single part of the end to end network from the doctor's hands to the scalpel being totally dedicated? :) ...and in that case I don't think the packets would go through the internet
GGR>> There are a few issues here:
1)	this example looks a bit out-dated to me. There is only a one-to-one relationship between doctor and patient. This is what I would call a classical client-server model with protected resources. Ask for SONET leased line circuits if this is what a "slice" would mean. In defining what constitutes a slice you would also have to think about what constitutes a "doctor-slice" and what would be a "patient-slice"? (assuming responsible health care to avoid sarcastic interpretation)
2)	The question asked in my earlier email is whether the packets *must* go through a dedicated resource to call the thing "slice". In other words, if a thing that uses a non-dedicated "underlay" resource like the Internet can be called "slice" too? It is puzzling to me why the definition of "slice" would need any dedicated resource at all. It is in the end an implementers choice how much dedicated equipment is needed to provide a service. So why a slice has to use "dedicated resources", and what kind of "dedication" is meant? (See our earlier discussion about WDM)? Take your mobile as an example. It supports telephony and email. Those are different apps, potentially running in different VMs. 
a.	Is your phone a shared device or a dedicated one? 
b.	does using different apps means to use a different slices?
c.	If you write emails to different recipients, would that qualify your email to be "dedicated", hence a different slice, just because they are in different address books?
d.	If you switch from 3G to VoIP, does it mean to switch the slice, even if it is the same app?

GGR> My thinking is that the definition of "slice" needs to make practical sense. The 3GPP definition is probably a bit too high level but makes sense to me:
    "A set of network functions and the resources for these network functions which are arranged and configured, forming a complete logical network to meet certain network characteristics."

    Gert 

        

        
        BR
        Daniele  

        -----Original Message-----
        From: sebastian [mailto:[email-masked]] 
        Sent: domenica 28 maggio 2017 07:12
        To: 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; Daniele Ceccarelli <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
        Cc: [email-masked]
        Subject: RE: [Netslices] [Teas] terminology discussion network slicing
        
        Hello, Jeff,

        

        Many thanks.
        -Sebastian

        -----Original Message-----
        From: Netslices [mailto:[email-masked]] On Behalf Of Igor Bryskin
        Sent: Wednesday, May 24, 2017 7:56 AM
        To: Jeff Tantsura <[email-masked]>; qiangli (D) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
        Cc: [email-masked]
        Subject: Re: [Netslices] [Teas] terminology discussion network slicing
        
        Thanks Jeff,

        Igor
        
        -----Original Message-----
        From: Jeff Tantsura [mailto:[email-masked]] 
        Sent: Wednesday, May 24, 2017 8:45 AM
        To: Igor Bryskin; qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
        Cc: [email-masked]
        Subject: Re: [Teas] terminology discussion network slicing
        
        +1 Igor

        Cheers,
        Jeff

            Hi Cristina,

            Igor
            
            -----Original Message-----
            From: qiangli (D) 
            
            Hi Igor,

            Best regards,
            
            Cristina QIANG

            -----邮件原件-----
            发件人: Igor Bryskin 
            发送时间: 2017年5月20日 23:50
            
            Hi Cristina,

            Cheers,
            Igor
            
            -----Original Message-----
            From: qiangli (D)
            
            Hi Igor,

            Best regards,
            
            Qiang, Li (Cristina)
            NetLab, Huawei

            -----邮件原件-----
            
            Hi Danielle,

            Cheers,
            Igor

            
            -----Original Message-----
            
            Hi Young, all,

            

            
            BR
            Daniele  

            -----Original Message-----
            
            Hi,

            

            
            
            Thanks,
            Young
            
            -----Original Message-----

            Lou

---

From: "sebastian" <[email-masked]>
Date: Tue, 30 May 2017 06:44:04 -0500

Hello, Gert,

Good points.

There are various instantiations of a 'network slice' that are likely, based on a diverse array of usage scenarios.
These diverse instantiations of a 'network slice', with a corresponding allocation of the required logical or physical resources, should be allowed to suit different usage scenarios that may range from a 'segment' to 'e2e' (end-to-end), in a 5G ecosystem.

Hence a generalized definition for the instantiation of a 'network slice' such as the one referred to below (3GPP) is reasonable:
    "A set of network functions and the resources for these network functions which are arranged and configured, forming a complete logical network to meet certain network characteristics."

Many thanks.
-Sebastian

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Gert Grammel
Sent: Tuesday, May 30, 2017 6:17 AM
To: Daniele Ceccarelli <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Daniele,

    Ciao Gert,
    
    Please see in line
    Cheers
    Daniele  

    -----Original Message-----
    From: Teas [mailto:[email-masked]] On Behalf Of Gert Grammel
    Sent: lunedì 29 maggio 2017 15:34
    To: Daniele Ceccarelli <[email-masked]>; [email-masked]; 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Teas] [Netslices] terminology discussion network slicing
    
    Daniele,

    

    Gert 

        

        
        BR
        Daniele  

        -----Original Message-----
        From: sebastian [mailto:[email-masked]] 
        Sent: domenica 28 maggio 2017 07:12
        To: 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)' <[email-masked]>; Daniele Ceccarelli <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
        Cc: [email-masked]
        Subject: RE: [Netslices] [Teas] terminology discussion network slicing
        
        Hello, Jeff,

        

        Many thanks.
        -Sebastian

        -----Original Message-----
        From: Netslices [mailto:[email-masked]] On Behalf Of Igor Bryskin
        Sent: Wednesday, May 24, 2017 7:56 AM
        To: Jeff Tantsura <[email-masked]>; qiangli (D) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]
        Cc: [email-masked]
        Subject: Re: [Netslices] [Teas] terminology discussion network slicing
        
        Thanks Jeff,

        Igor
        
        -----Original Message-----
        From: Jeff Tantsura [mailto:[email-masked]] 
        Sent: Wednesday, May 24, 2017 8:45 AM
        To: Igor Bryskin; qiangli (D); Daniele Ceccarelli; Leeyoung; [email-masked]
        Cc: [email-masked]
        Subject: Re: [Teas] terminology discussion network slicing
        
        +1 Igor

        Cheers,
        Jeff

            Hi Cristina,

            Igor
            
            -----Original Message-----
            From: qiangli (D) 
            
            Hi Igor,

            Best regards,
            
            Cristina QIANG

            -----邮件原件-----
            发件人: Igor Bryskin 
            发送时间: 2017年5月20日 23:50
            
            Hi Cristina,

            Cheers,
            Igor
            
            -----Original Message-----
            From: qiangli (D)
            
            Hi Igor,

            Best regards,
            
            Qiang, Li (Cristina)
            NetLab, Huawei

            -----邮件原件-----
            
            Hi Danielle,

            Cheers,
            Igor

            
            -----Original Message-----
            
            Hi Young, all,

            

            
            BR
            Daniele  

            -----Original Message-----
            
            Hi,

            

            
            
            Thanks,
            Young
            
            -----Original Message-----

            Lou

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 30 May 2017 13:39:07 +0100

>      "A set of network functions and the resources for these network functions which are arranged and configured, forming a complete logical network to meet certain network characteristics."

That is excellent. And too broad. That can be anything from connection 
between two computers and a whole provider network. They both fit this 
rather elastic definition.

So, in order for this to be discussed at IETF at all we should limit the 
scope a little bit to one or more subject areas worked on at IETF:

1. Layer 3 and higher protocols.
2. Models describing network abstractions
3. Interoperability with other IETF efforts.

Otherwise, both the definition and the discussion should stay at 3GPP. 
They are good at discussing schemes of world domination, though from a 
point of view of network technology the results are quite often fit for 
Mr Bean, instead of Mr Blofeld (as intended).

A.

---

From: "sebastian" <[email-masked]>
Date: Tue, 30 May 2017 08:40:36 -0500

Hello, Anton,

The 5G ecosystem contains pragmatic usage scenarios (mobile, fixed, verticals etc.) that require flexible orchestration methods that would enable various choices with respect to the span of an instantiated 'network slice'

This would imply both 'segmented' and 'e2e' instantiations of a 'network slice' based on a given usage scenario.
Signaling, orchestration, and interoperability, with respect to the required protocols and procedures would be relevant.

Many thanks.
-Sebastian

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: Tuesday, May 30, 2017 7:39 AM
To: [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

>      "A set of network functions and the resources for these network functions which are arranged and configured, forming a complete logical network to meet certain network characteristics."

That is excellent. And too broad. That can be anything from connection between two computers and a whole provider network. They both fit this rather elastic definition.

So, in order for this to be discussed at IETF at all we should limit the scope a little bit to one or more subject areas worked on at IETF:

1. Layer 3 and higher protocols.
2. Models describing network abstractions 3. Interoperability with other IETF efforts.

Otherwise, both the definition and the discussion should stay at 3GPP. 
They are good at discussing schemes of world domination, though from a point of view of network technology the results are quite often fit for Mr Bean, instead of Mr Blofeld (as intended).

A.

>      [>DC] Think of remote surgery...wouldn't you want every single 
> part of the end to end network from the doctor's hands to the scalpel 
> being totally dedicated? :) ...and in that case I don't think the 
> packets would go through the internet

---

From: Gert Grammel <[email-masked]>
Date: Tue, 30 May 2017 13:54:10 +0000

Anton,

We are in agreement that the 3GPP definition is too high level. It is useful however that it stays away from a few arguments that frequently come up in our discussion:
- It doesn't say end-to-end – hence no need to define "The End"
- It doesn't require "dedicated" resources, hence no need to define levels of dedication
- It doesn't use the term "layer", hence no need to define what a Layer would mean 
- It doesn't use "owner" to express a technical relation

I am all for adding meat to above definition but at the same time reluctant to fall back using controversial terminology.

Gert

On 2017-05-30, 14:39, "Netslices on behalf of Anton Ivanov" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    
    A.

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 30 May 2017 14:20:38 +0000

Gert,

You seem to like the 3gpp network slice definition for all things it didn’t say anything about. It is a hack of a praise for a definition! :=)

But in order to work on network slicing in IETF we need some (reasonably) tight definitions to see how we can actually help.
So, when Anton enlists things like:
"
    1. Layer 3 and higher protocols.
    2. Models describing network abstractions 
"
I find it positive, helpful and constructive.

Cheers,
Igor

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Gert Grammel
Sent: Tuesday, May 30, 2017 9:54 AM
To: Anton Ivanov; [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Anton,

Gert

    

    

    A.

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 30 May 2017 15:56:11 +0100

Which is exactly my point.

IETF is not a 5G standards body and it is not its job to standardize the 
5G ecosystem.

A.

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 30 May 2017 16:09:16 +0100

What is a slice is more or less defined by 3GPP.

The issue is - what SUBSET of slicing problem space will IETF tackle?

The 3GPP definition is so ridiculously broad that it is of no use at 
all. It has to be narrowed down and cut to size so it can be worked on.

We have to be realistic, stick to stuff which is in scope and which has 
overlap to existing IETF problem space.

A.

On 30/05/17 15:58, Thomas Nadeau wrote:
> 	I am still having difficulty understanding just what this group is trying to accomplish.
> The best I can figure from these discussions has been a definition that a slice is
> an overlay of some sort, which as we all know, has been defined well in a number of
> forms, for a number of years.
>
> 	—Tom
>
>
>> On May 30, 2017:9:54 AM, at 9:54 AM, Gert Grammel <[email-masked]> wrote:
>>
>> Anton,
>>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 30 May 2017 11:10:58 -0400

—Tom

---

From: Gert Grammel <[email-masked]>
Date: Tue, 30 May 2017 16:55:05 +0000

Igor,

It appears to me that Anton and myself are pretty aligned in what would be needed, perhaps we have a little different approach in getting there. The 3GPP definition is way too broad for the IETF to work on something reasonable. However, it is at least a common starting point that has to be narrowed down. My point is that narrowing down by using fluffy terms is actually equivalent in broadening the scope even more.
Anton's list is a valid attempt to narrow the scope and I would encourage him to continue (and others to contribute).

The target is to define the term "Network Slice" in a way that can be used in the IETF and which is sharp enough to distinguish constructs that are no slice from constructs that are slices.

Gert

On 2017-05-30, 16:20, "Igor Bryskin" <[email-masked]> wrote:

    Gert,

    
    Cheers,
    Igor

    -----Original Message-----
    From: Netslices [mailto:[email-masked]] On Behalf Of Gert Grammel
    Sent: Tuesday, May 30, 2017 9:54 AM
    To: Anton Ivanov; [email-masked]
    Subject: Re: [Netslices] [Teas] terminology discussion network slicing
    
    Anton,

    
    Gert

        

        

        A.

---

From: "sebastian" <[email-masked]>
Date: Tue, 30 May 2017 12:17:21 -0500

Hello, Igor, Gert,

The high-level definition of a 'network slice' in 3GPP should serve as a context and background that is not violated, while drilling down into the details of the required suite of protocols and procedures (IETF), across the different layers of the stack.

Support for the e2e(end-to-end) aspect of a 'network slice' is important to support the usage scenarios that underscore the 5G ecosystem.

Many thanks.
-Sebastian

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Tuesday, May 30, 2017 9:21 AM
To: Gert Grammel <[email-masked]>; Anton Ivanov <[email-masked]>; [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Gert,

    2. Models describing network abstractions "

Cheers,
Igor

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Gert Grammel
Sent: Tuesday, May 30, 2017 9:54 AM
To: Anton Ivanov; [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Anton,

Gert

    

    

    A.

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 30 May 2017 18:34:26 +0000

Gert,

I am not arguing with you. This is what I am also trying to say: we need to identify things that IETF can contribute to the network slicing architecture. This depends on a reasonably tight definition of what network slice is. For example, I believe that abstract TE topology models we develop in TEAS WG could be instrumental. SF/NF aware abstract topology models we are currently discussing could do even better.

Igor

-----Original Message-----
From: Gert Grammel [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2017 12:55 PM
To: Igor Bryskin; Anton Ivanov; [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Igor,

Gert

    Gert,

    
    Cheers,
    Igor

    -----Original Message-----
    From: Netslices [mailto:[email-masked]] On Behalf Of Gert Grammel
    Sent: Tuesday, May 30, 2017 9:54 AM
    To: Anton Ivanov; [email-masked]
    Subject: Re: [Netslices] [Teas] terminology discussion network slicing
    
    Anton,

    
    Gert

        

        

        A.

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 30 May 2017 19:41:54 +0100

On 30/05/17 18:17, sebastian wrote:
> Hello, Igor, Gert,
>
> The high-level definition of a 'network slice' in 3GPP should serve as a context and background that is not violated,

I do not see any justification for such declarations of sanctity of 3GPP 
principles.

For example a slice representing a tenant in a vCPE design has nothing 
to do with 3GPP. It is clearly a slice. It fits the definition. It is 
not 3GPP.

It is also more in scope for IETF than any of the 3GPP RAN+Radio stuff.

Let's walk through it: customer premises networking and configuration 
(HOMENET), network overlays over WAN to CO (L2VPN, L3VPN, L2TP, 
L2TPEXT), Datacenter networking - NVO3, SFC, etc. All clearly in-scope, 
IETF and currently being worked on in 6+ working groups (either complete 
or active). All of them constitute the components of a slice which has 
nothing to do with 3GPP.

>   while drilling down into the details of the required suite of protocols and procedures (IETF), across the different layers of the stack.
>

Correct, however a lot of the e2e is orchestration material. It is not 
in scope for the IETF. The only part I can see in scope (unless I am 
missing something) is the model.

A.

---

From: "Kiran.Makhijani" <[email-masked]>
Date: Tue, 30 May 2017 19:47:59 +0000

Hi, 
>> 3. Interoperability with other IETF efforts.
Great summary. I am onboard with others on #2 and #3. But not clear about #1. There will be many other enabling technologies based on what a particular domain offers – I am thinking Detnet, Flex-E, GMPLS, L1VPN (may be). Arent they under #3? By the same logic #1 should also be with “#3 interoperability work”. Isn’t it?

>>  Support for the e2e(end-to-end) aspect of a 'network slice' is important to support the usage scenarios that underscore the 5G ecosystem.
+1, this should be must as it gives us a real shot of deploying NS solutions.

  >> Correct, however a lot of the e2e is orchestration material. 
But what to orchestrate and make it inter-operable needs to be done as well.

I think trying to define slicing so that it reflects what IETF can do is not fair. We all ‘sort of’ understand what slices are wrt to supporting service verticals, that may be 3GPP or non-3GPP (fixed or mobile).  Some of the documents (see Github for work-in-progress docs) being worked are trying to capture the essence of this thread.

Thanks
Kiran 

On 5/30/17, 11:41 AM, "Netslices on behalf of Anton Ivanov" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    
    
    A.

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 30 May 2017 15:52:29 -0400

> On May 30, 2017:12:55 PM, at 12:55 PM, Gert Grammel <[email-masked]> wrote:
> 
> Igor,
> 

	And to the point of this list/BoF/etc…  specifically describing what if anything, can be worked on here at the IETF.
To this point in the discussions, I agree with Anton in that it appears that it might just be models for managing
the service.

	—Tom

---

From: Gert Grammel <[email-masked]>
Date: Tue, 30 May 2017 20:02:01 +0000

Anton,

I am a bit confused about your last email. 
Lets forget for a moment the source of the definition (was 3GPP)
"A set of network functions and the resources for these network functions which are arranged and configured, forming a complete logical network to meet certain network characteristics."

For more see in line

    I do not see any justification for such declarations of sanctity of 3GPP 
    principles.
→ what are 3GPP principles and why should they be sanctuary?
    
    For example a slice representing a tenant in a vCPE design has nothing 
    to do with 3GPP. It is clearly a slice. It fits the definition. It is 
    not 3GPP.
→ can you tell me how a tenant in a vCPE design would not fall in above definition of a slice?
    
    It is also more in scope for IETF than any of the 3GPP RAN+Radio stuff.
→ there is no RAN mentioned in above definition
    
→ agree, but the definition provided by 3GPP seems to cover those cases

    Correct, however a lot of the e2e is orchestration material. It is not 
    in scope for the IETF. The only part I can see in scope (unless I am 
    missing something) is the model.
→ before concluding what is missing, I would prefer to get a clear and agreed view of what the heck do we mean with "network slice" and what do we not mean by "network slice".
    
- Gert 
    A.

---

From: "sebastian" <[email-masked]>
Date: Tue, 30 May 2017 20:53:04 -0500

Hello, Gert, Igor, Anton,

Agree that the source of the definition, is not as significant as the definition for a 'network slice':

Quoted from the text below:
"A set of network functions and the resources for these network functions, which are arranged and configured, forming a complete logical network to meet certain network characteristics."

The phrase 'complete logical network' is the 'network slice'
See the NGMN reference, on the 'network slice' concept:
https://www.ngmn.org/uploads/media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf 

Orchestration aspects to instantiate a 'network slice' could be referenced by the draft, where it may not be in-scope for the draft.

Many thanks.
-Sebastian

-----Original Message-----
From: Gert Grammel [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2017 3:02 PM
To: Anton Ivanov <[email-masked]>; [email-masked]; 'Igor Bryskin' <[email-masked]>; [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Anton,

I am a bit confused about your last email. 
Lets forget for a moment the source of the definition (was 3GPP) "A set of network functions and the resources for these network functions which are arranged and configured, forming a complete logical network to meet certain network characteristics."

For more see in line

    

    

- Gert 
    A.

---

From: Anton Ivanov <[email-masked]>
Date: Wed, 31 May 2017 05:15:36 +0100

> → can you tell me how a tenant in a vCPE design would not fall in above definition of a slice?

My exact point.

> → there is no RAN mentioned in above definition

No, but the moment we start narrowing down someone immediately tries to 
stick in "5G RAN needs" all over the place into it. We tried it.

Caring about the 5G RAN is 3GPP job. Not ours.

So from my perspective, the test here is - can we formulate a task or 
set of of tasks which do not have 5G RAN in the task definition. Sure, 
RAN can be a use case, but it does not belong anywhere above the use 
case level.

If we can formulate such a set - we have a winner. If not, we can all go 
and do something more interesting instead.

> → agree, but the definition provided by 3GPP seems to cover those cases

Correct, see above.

---

From: Gert Grammel <[email-masked]>
Date: Wed, 31 May 2017 06:51:05 +0000

Anton,

Understood now that you like to keep the definition of "network slice" independent of technology specific vocabulary; that resonates with me.

Gert

On 2017-05-31, 06:15, "Anton Ivanov" <[email-masked]> wrote:

    
    My exact point.

    

    
    
    Correct, see above.

---

From: <[email-masked]>
Date: Wed, 31 May 2017 12:29:33 +0000

Hi Anton, all,

I do fully agree with you here that we need to be specific about the expected work to be conducted within the IETF. 

For where I sit, I see "network slice" as a construct that allows to offer differentiated services when crossing a domain. These differentiated services can be differentiated IP transfer capabilities and may invoke advanced Service Functions (as per SFC). 

A network slice can be seen as an augmented version of the PDB (Per-Domain Behavior, RFC3086) concept since not only forwarding is differentiated but also other dimensions.

Which technology-specific mechanisms are to be enabled to put into effect a slice is really a deployment matter. 
 
From that standpoint, the topics that I do think the IETF can contribute to are:

* A service model to capture the requirements from applications/customers
* A service model to expose the capabilities of an underlying infrastructure
* A mechanism to automate the process of requesting underlying services and handling these requests
* Some customized OAM

(please refer to draft-wu-opsawg-service-model-explained for a good definition on the service models)

Cheers,
Med 

> -----Message d'origine-----
> De : Netslices [mailto:[email-masked]] De la part de Anton
> Ivanov
> Envoyé : mardi 30 mai 2017 14:39
> À : [email-masked]
> Objet : Re: [Netslices] [Teas] terminology discussion network slicing
> 
> 
> 
> > There are various instantiations of a 'network slice' that are likely,
> based on a diverse array of usage scenarios.
> > These diverse instantiations of a 'network slice', with a corresponding
> allocation of the required logical or physical resources, should be
> allowed to suit different usage scenarios that may range from a 'segment'
> to 'e2e' (end-to-end), in a 5G ecosystem.
> >
> > Hence a generalized definition for the instantiation of a 'network
> slice' such as the one referred to below (3GPP) is reasonable:
> functions which are arranged and configured, forming a complete logical
> network to meet certain network characteristics."
> 
> >      To: Daniele Ceccarelli <[email-masked]>;
> [email-masked]; 'Igor Bryskin' <[email-masked]>;
> 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)'
> <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]
> >      Cc: [email-masked]
> >      Trying to summarize what you're saying: a Network slice is an
> overlay network with minimum service guarantees, including virtual network
> functions available in this overlay network.
> >      [>DC] why do you speak about an overlay network? If for example you
> have a site connected with a lambda to a data center and there you have a
> number of VNF, that's IMO a slice but there is no overlay. I'd say that
> there could be an overlay but that's not mandatory.
> > GGR> A Lambda travels through a WDM which is a Multiplexer (see
> discussion below). So a lambda is in my view an overlay, the multiplexed
> signal (OMS) being the underlay.
> >
> >
> >
> >      In your text I have issues with "dedicated to a given customer".
> Whether such construct is dedicated to one or shared among several legal
> customers shouldn't be of concern for the definition of a Network Slice.
> >      [>DC] Correct, it should be possible to have it dedicated or
> shared. We just need to make sure that both options are supported.
> >      On similar terms, whether a resource (being a NF or transport
> capacity) is shared or not is a design choice rather than a definition. In
> particular, Multiplexer by definition share some sort of common capacity
> irrespective whether it is TDM, Packet, WDM or CDM. So, the nature of
> multiplexing technique shouldn't be a definition criteria for a Network
> Slice either.
> >
> >      - I would also add that a network slice may use it's own internal
> addressing scheme isolated from other slices. While this is optional, I
> would expect it to be used quite often.
> >      [>DC] agree. Ala VPN.
> >
> >      - Why is it necessary to dedicate resources to a "Network Slice" at
> all? If e.g. a firewall NFV is in the DC and communicates over the
> Internet with a CPE (both belonging to a single owner) it would not fulfil
> the criteria of dedicated resource (Internet after all isn't dedicated),
> but it still looks pretty much like a "network slice".
> >
> >      [>DC] Think of remote surgery...wouldn't you want every single part
> of the end to end network from the doctor's hands to the scalpel being
> totally dedicated? :) ...and in that case I don't think the packets would
> go through the internet
> > 1)	this example looks a bit out-dated to me. There is only a one-to-one
> relationship between doctor and patient. This is what I would call a
> classical client-server model with protected resources. Ask for SONET
> leased line circuits if this is what a "slice" would mean. In defining
> what constitutes a slice you would also have to think about what
> constitutes a "doctor-slice" and what would be a "patient-slice"?
> (assuming responsible health care to avoid sarcastic interpretation)
> > 2)	The question asked in my earlier email is whether the packets *must*
> go through a dedicated resource to call the thing "slice". In other words,
> if a thing that uses a non-dedicated "underlay" resource like the Internet
> can be called "slice" too? It is puzzling to me why the definition of
> "slice" would need any dedicated resource at all. It is in the end an
> implementers choice how much dedicated equipment is needed to provide a
> service. So why a slice has to use "dedicated resources", and what kind of
> "dedication" is meant? (See our earlier discussion about WDM)? Take your
> mobile as an example. It supports telephony and email. Those are different
> apps, potentially running in different VMs.
> > c.	If you write emails to different recipients, would that qualify your
> email to be "dedicated", hence a different slice, just because they are in
> different address books?
> > GGR> My thinking is that the definition of "slice" needs to make
> practical sense. The 3GPP definition is probably a bit too high level but
> makes sense to me:
> functions which are arranged and configured, forming a complete logical
> network to meet certain network characteristics."
> >
> >      Gert
> >
> >      On 2017-05-29, 11:01, "Teas on behalf of Daniele Ceccarelli" <teas-
> [email-masked] on behalf of [email-masked]> wrote:
> >
> >          I understand Jeff and Igor agree on the fact that a network
> slice does not necessarily include resources in the radio segment/domain
> and in the packet core one.
> >          An example could be an enterprise with dedicated resources in
> the "transport" segment (e.g. VPN, VN and TE-tunnels) that connect the
> customer premises to a data center where a number of VNF (e.g. firewall,
> nat, dpi) is dedicated to that given customer.
> >          The definition of network slice should allow for this scenario
> and mostly should clearly state whether this is included or not.
> >
> >          " The management and orchestration of resources should be
> capable of instantiating a 'network slice' with an e2e (end-to-end) scope,
> where the scope could be between two devices, connected across intervening
> radio networks and core networks that may belong to the same or different
> administrative domains."
> >          To: 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura'
> <[email-masked]>; 'qiangli (D)' <[email-masked]>; Daniele
> Ceccarelli <[email-masked]>; 'Leeyoung'
> <[email-masked]>; [email-masked]
> >          Cc: [email-masked]
> >          Agree with your view that the scope (core and/or radio layer)
> of a 'network slice' could vary depending on the triggers for
> instantiating the 'network slice'.
> >
> >          On the other hand the instantiation of a 'network slice' may
> also be e2e (end-to-end), such as in device roaming scenarios, or in the
> case of vertical services that span different service providers.
> >
> >          The span of a 'network slice' is only limited by the
> availability of resources and appropriate policies (e.g. SLAs),
> independent of whether those resources are in the core network layer or in
> the radio network layer.
> >
> >          The management and orchestration of resources should be capable
> of instantiating a 'network slice' with an e2e (end-to-end) scope, where
> the scope could be between two devices, connected across intervening radio
> networks and core networks that may belong to the same or different
> administrative domains.
> >
> >          Many thanks.
> >          -Sebastian
> >
> >
> >          To: Jeff Tantsura <[email-masked]>; qiangli (D)
> <[email-masked]>; Daniele Ceccarelli
> >          From transport side (L0-L3) we need to expose set of API’s that
> would allow to request a set of resources (a slice) either virtualized of
> physical that meet the constrains as requested by the business logic.
> Radio, while would definitely be one of most important use cases, would
> not be exclusively for radio use only. Any network management/
> orchestration layer ideally should be able to use same set of API’s to
> request an e2e service.
> >
> >          Cheers,
> >          Jeff
> >
> >
> >          On 5/24/17, 05:26, "Teas on behalf of Igor Bryskin" <teas-
> [email-masked] on behalf of [email-masked]> wrote:
> >
> >              Hi Cristina,
> >
> >              I didn’t say that ns has nothing to do with radio. I said
> that ns *may* have nothing to do with radio, i.e. may support/enable
> network architectures that do not involve radio necessarily.
> >
> >              Igor
> >
> >              I share the same opinion on 5G and network slicing, but
> can't see the relation between this opinion and your conclusion that ns
> has nothing to do with radio.
> >
> >              Best regards,
> >
> >              Cristina QIANG
> >
> >
> >              -----邮件原件-----
> >              发件人: Igor Bryskin
> >              发送时间: 2017年5月20日 23:50
> >              People whose opinion I respect very much told me that even
> the 3GPP network slicing definition and effort is not 5G specific.
> Network slicing is viewed as an important capability of 5G, but it could
> serve other architectures.
> >
> >              Cheers,
> >              Igor
> >
> >              IMO, network slicing should be a resource-oriented
> management mode. The end-to-end network slice (from UE to server/other UE)
> of course involves the radio resource, usually we use the word "RAN-radio
> access network" rather than simply say "radio". The Frequency band, time,
> code, equipment/site, and software are a number of dimensions, in which
> RAN resources can be isolated [Online available
> http://www.huawei.com/en/industry-insights/mbb-2020/trends-insights/5g-
> service-guaranteed-network-slicing-whitepaper].
> >
> >              Best regards,
> >
> >              Qiang, Li (Cristina)
> >              NetLab, Huawei
> >
> >
> >              -----邮件原件-----
> >              Network slicing may have nothing to do with radio. 5g is
> just a big reason as to why the interest/focus is back on network slicing,
> which is a very old concept. I don't think that anyone is arguing with
> what you wrote. The questions are:
> >              i agree with your conclusion but would like to clarify one
> thing that IMO got lost in the discussion since its beginning.
> >
> >              "A set of network functions and the resources for these
> network functions which are arranged and configured, forming a complete
> >              A network slice is "something" (netslices and 3GPP will
> define what this something is) that is composed by a "piece" in the RADIO
> domain, a "piece" in the CLOUD domain, a "piece" in the TRANSPORT domain,
> plus possible other pieces in possible other domains.
> >
> >              The word "transport" can be misleading here since one could
> think of transport technologies (e.g. WDM, OTN), but what I'm referring to
> as TRANSPORT DOMAIN is that part of the network that is used to carry a
> >              In order to have a slice, that portion of the transport
> domain needs to be engineered, hence it is all about building a TE entity
> and stitching services to such entity. This is what is in the ACTN scope.
> >
> >              My very personal opinion is that whatever belongs to the
> transport domain belongs to IETF (and is already being addressed), while
> the rest is a dangerous duplication of concepts standardized is other
> >              Lou is right. There is a dedicated email list for the
> discussion of "network slicing (cc'ed)" and the discussion about what that
> term means should be held on that list.
> >
> >              00 version. Recent changes have been an attempt to clarify
> what the terminology means in the context of ACTN. We are not trying to
> define or redefine "network slicing" in the ACTN document, but are trying
> to make it clear how ACTN works.
> >
> >              1. All discussion of the general applicability and
> definition of "network slicing" is held on the netslices mailing list.
> >
> >              2. We adopt Adrian's suggestion to explain that the scope
> of the definition of the terms used in the ACTN framework is limited to
> ACTN. That means effectively that if there are components of a wider
> >              I propose to post an updated version in the next few days
> and I believe that will allow this draft to move ahead without being
> blocked by the discussion in netslices. Once the IETF has a stable
> definition of network slicing we can return and see how ACTN is applicable
> to that definition an whether more wok is need (in a separate draft).
> >
> >              Thanks,
> >              Young
> >
> >              To: Igor Bryskin <[email-masked]>; Belotti, Sergio
> (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel
> perspective (in the
> Internet-Drafts directories.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 31 May 2017 18:00:58 +0000

[Uma]: Concept of slice came from 3GPP to have a unified view of a resource from very different domains (RAN, Transport and Core network) it operates 
               to provide service to the end user (in future it could be M2M, high-speed vehicular traffic with low latency needs) . 
               And we all agree the  transport part obviously belongs here.  If we generalize the problem, we can solve a different and perhaps smaller issue which nobody asked for  
              (or nobody bothered to care with the IP networks) because these have (3GPP service/non-3GPP service)  different 
               characteristics from service, billing etc.
               
               We need  to formulate a generic problem statement  in the transport domain, which can be used independent of any  technology (3GPP/non-3GPP/whatever) 
               but need not invent a non-existent hazy requirement (tenant in vCPE design, what??) in the name of generalization. 

               I see couple of  things in particular (not exhaustive):

               1. Generalized mapping (beyond L2VPN, L3VPN today) of incoming traffic  to transport tunnels (MPLS, non-MPLS) spanned  across single/multiple areas/ASes.
                          - or new transport networks with simplified designs (FlexE, XE etc..) 
               2. Cross domain orchestration  of  networks ( with access, aggregation and core rings) 
               3. E2E (only from transport pov) Monitoring of above cross domain network  for changes in jitter, latency, all forms of BW etc for fast feedback  loops.

               We might have solutions in most of the above aspects but putting together all required pieces, might have some gaps and also lack a standardized mechanism to transcend
               various deployments from operators perspective (remember slicing has been proto-typed/show-cased from all major wireless vendors in last 1/1.5 years)
               I still believe the use case for this work is 3GPP, else we can call this list with a different term and solve a completely different use case.
               We don't have to solve RAN pieces or virtualized 3GPP core pieces here but the generic requirements  from these domain to transport networks is perhaps important.

--
Uma C.

---

From: GENG Liang <[email-masked]>
Date: Thu, 1 Jun 2017 05:32:02 +0000

Hi Med, Anton and all

I have my hands on with Med and Anton that defining models are currently the identified major issues of network slicing in the scope of IETF.

As an additional layer of abstraction of infrastructure/resources/fuctions etc., it only makes sense when multiply slices co-exists on a shared network in a Network Slice Provider point of view. The level of dedication depends on Network Slice Provider's business model and Network Slice Tenant's requirements. Having this in mind and back to Anton's and Med's points of IETF works:

Anton's suggestion
> 1. Layer 3 and higher protocols.
Yes if it is at the level of network slice concerns itself, not data/control plane for any flow QoS guarantee - this is not slice-specific issues.
> 2. Models describing network abstractions
Agree, maybe also plus information+service model capturing Network Slice Tenant's requirements
> 3. Interoperability with other IETF efforts.
Agree, many other IETF efforts maybe utilized in specific segment of a network slice instance. This should also echos with the layer of network slice abstraction.

Med's suggestion
* A service model to capture the requirements from applications/customers
* A service model to expose the capabilities of an underlying infrastructure
If we regard service model as a specific type of data model, I suggest we also include information model which is more abstract inscope as well, especially for modeling requirements from application/customers. They don't need to know slice and these models are likely to be protocol nonspecific.

* A mechanism to automate the process of requesting underlying services and handling these requests
Agree, I understand this as E2E/domain slice management and orchestration
* Some customized OAM
It is challenging to provide customized OAM to specific network slice tenant. However, I do agree this is an important feature for network slice since some Network Slice Tenant's would want certain level of control of their sliced network. This OAM has to be provisioned by network slice provider for reliability and security reasons.

Best wishes
Liang GENG
China Mobile Research Institute

From: [email-masked]<mailto:[email-masked]>
Date: 2017-05-31 20:29
To: Anton Ivanov<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netslices] [Teas] terminology discussion network slicing
Hi Anton, all,

Cheers,
Med