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

[Greg Mirsky <[e-mail]>]

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 <
[e-mail]> wrote:

> Hi Greg,
>
>
>
> good points. Please see in line.
>
>
>
> Cheers
>
> Daniele
>
>
>
> *From:* Greg Mirsky [mailto:[e-mail]]
> *Sent:* sabato 20 maggio 2017 06:14
> *To:* Daniele Ceccarelli <[e-mail]>
> *Cc:* Leeyoung <[e-mail]>; [e-mail]; [e-mail]
> *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 <
> [e-mail]> 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.
>
> 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…*
>
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.

>
> 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.*
>
GIM2>> Yes, should have been clearer, it is the latter.

>
> 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:[e-mail]] On Behalf Of Leeyoung
> Sent: venerdì 19 maggio 2017 15:15
> To: [e-mail]
> Cc: [e-mail]
>
> Subject: Re: [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.
>
> 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:[e-mail]]
> Sent: Tuesday, May 16, 2017 8:35 AM
> To: Igor Bryskin <[e-mail]>; Belotti, Sergio (Nokia -
> IT/Vimercate) <[e-mail]>; Gert Grammel <
> [e-mail]>; Leeyoung <[e-mail]>; [e-mail];
> [e-mail]
> 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 <[e-mail]> 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:[e-mail]] On Behalf Of Belotti, Sergio
> > (Nokia - IT/Vimercate)
> > Sent: Tuesday, May 16, 2017 6:08 AM
> > To: Gert Grammel; Leeyoung; [e-mail]; [e-mail]
> > 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:[e-mail]] On Behalf Of Gert Grammel
> > Sent: Monday, May 15, 2017 7:02 PM
> > To: Leeyoung <[e-mail]>; [e-mail]; [e-mail]
> > 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"
> > <[e-mail] on behalf of [e-mail]> 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: [e-mail]
> >     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:[e-mail]] On Behalf Of
> [e-mail]
> >     Sent: Friday, May 05, 2017 10:41 AM
> >     To: [e-mail]
> >     Cc: [e-mail]
> >     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
> >     [e-mail]
> >     https://www.ietf.org/mailman/listinfo/teas
> >
> >     _______________________________________________
> >     Teas mailing list
> >     [e-mail]
> >     https://www.ietf.org/mailman/listinfo/teas
> >
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/teas
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/teas
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/teas
> >
>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Netslices mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netslices
>
>
>