Re: [Teas] terminology discussion network slicing

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

On 5/16/17, 7:31 AM, "Teas on behalf of Leeyoung" <teas-bounces@ietf.org on behalf of leeyoung@huawei.com> 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 (NetSlices@ietf.org) 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:lberger@labn.net] 
    Sent: Tuesday, May 16, 2017 8:35 AM
    To: Igor Bryskin <Igor.Bryskin@huawei.com>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>; Gert Grammel <ggrammel@juniper.net>; Leeyoung <leeyoung@huawei.com>; teas@ietf.org; adrian@olddog.co.uk
    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 <Igor.Bryskin@huawei.com> 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:teas-bounces@ietf.org] On Behalf Of Belotti, Sergio 
    > (Nokia - IT/Vimercate)
    > Sent: Tuesday, May 16, 2017 6:08 AM
    > To: Gert Grammel; Leeyoung; teas@ietf.org; adrian@olddog.co.uk
    > 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:teas-bounces@ietf.org] On Behalf Of Gert Grammel
    > Sent: Monday, May 15, 2017 7:02 PM
    > To: Leeyoung <leeyoung@huawei.com>; teas@ietf.org; adrian@olddog.co.uk
    > 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" 
    > <teas-bounces@ietf.org on behalf of leeyoung@huawei.com> 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: teas@ietf.org
    >     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:teas-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
    >     Sent: Friday, May 05, 2017 10:41 AM
    >     To: i-d-announce@ietf.org
    >     Cc: teas@ietf.org
    >     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
    >     Teas@ietf.org
    >     https://www.ietf.org/mailman/listinfo/teas
    >
    >     _______________________________________________
    >     Teas mailing list
    >     Teas@ietf.org
    >     https://www.ietf.org/mailman/listinfo/teas
    >
    >
    > _______________________________________________
    > Teas mailing list
    > Teas@ietf.org
    > https://www.ietf.org/mailman/listinfo/teas
    >
    > _______________________________________________
    > Teas mailing list
    > Teas@ietf.org
    > https://www.ietf.org/mailman/listinfo/teas
    >
    > _______________________________________________
    > Teas mailing list
    > Teas@ietf.org
    > https://www.ietf.org/mailman/listinfo/teas
    >

    _______________________________________________
    Teas mailing list
    Teas@ietf.org
    https://www.ietf.org/mailman/listinfo/teas