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

[Jeff Tantsura <[e-mail]>]

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

> 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.
>
>
>> 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.
>
>>
>> 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?
>
>>
>> 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
>>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>