Re: [Teas] terminology discussion network slicing

[Igor Bryskin <[e-mail]>]

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-05
    
    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