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

["Adrian Farrel" <[e-mail]>]

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

> -----Original Message-----
> From: Netslices [mailto:[e-mail]] On Behalf Of Leeyoung
> Sent: 19 May 2017 14:15
> To: [e-mail]
> Cc: [e-mail]
> 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.
> 
> 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 internet-
> [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
> >
> 
> 
> _______________________________________________
> Netslices mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netslices