Re: [Teas] terminology discussion network slicing

"Dongjie (Jimmy)" <jie.dong@huawei.com> Fri, 26 May 2017 02:36 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040DC128796; Thu, 25 May 2017 19:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zpoWyTPaH5w; Thu, 25 May 2017 19:35:58 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7840D12945B; Thu, 25 May 2017 19:35:57 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNU56209; Fri, 26 May 2017 02:35:55 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 26 May 2017 03:35:54 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 26 May 2017 10:35:44 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Igor Bryskin <Igor.Bryskin@huawei.com>, "qiangli (D)" <qiangli3@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Leeyoung <leeyoung@huawei.com>, "teas@ietf.org" <teas@ietf.org>
CC: "NetSlices@ietf.org" <NetSlices@ietf.org>
Thread-Topic: [Teas] terminology discussion network slicing
Thread-Index: AdLNibwU9LLkPQ+KR4i49jploFvNwAAI/kYAAB+Mu/AABD85EP//knkAgASxhwCAAHZXgIAAH5KAgAY1dICAAMNdgIAAQhwA//0BKDA=
Date: Fri, 26 May 2017 02:35:44 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927936C5883@NKGEML515-MBX.china.huawei.com>
References: <7AEB3D6833318045B4AE71C2C87E8E172B2CA60E@SJCEML702-CHM.china.huawei.com> <97EE7243-CB44-40AD-B02D-98E07D9C79F2@juniper.net> <DB3PR07MB0588EA2B00C389E762D8C59F91E60@DB3PR07MB0588.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD00786390993DBF8@SJCEML702-CHM.china.huawei.com> <15c1177e0c0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172B2CC48E@SJCEML702-CHM.china.huawei.com> <AM2PR07MB099483A94CDDD068D0F86CD5F0E50@AM2PR07MB0994.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD0078639099515B3@SJCEML702-CHM.china.huawei.com> <DB5PR07MB0999A8C95CD9A68B7B7210F9F0F90@DB5PR07MB0999.eurprd07.prod.outlook.com> <06C389826B926F48A557D5DB5A54C4ED29BB51D9@SZXEMI507-MBS.china.huawei.com> <0C72C38E7EBC34499E8A9E7DD007863909966428@SJCEML702-CHM.china.huawei.com>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863909966428@SJCEML702-CHM.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.151.75]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5927948B.00BA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 1ed5454d87f42c48cf97f9697837e7a6
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/yXNtTc_rxZTo2E_wy-ooo7SQVv0>
Subject: Re: [Teas] terminology discussion network slicing
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 May 2017 02:36:02 -0000

Hi Igor, Cristina, 

Yes there are gaps in the legacy VPN technologies to meet the isolation requirement of network slicing. This needs to be further discussed in IETF to identify whether new work or enhancement is needed. I agree this is related to the work in TEAS WG.

Best regards,
Jie

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Igor Bryskin
> Sent: Wednesday, May 24, 2017 8:37 PM
> To: qiangli (D) <qiangli3@huawei.com>; Daniele Ceccarelli
> <daniele.ceccarelli@ericsson.com>; Leeyoung <leeyoung@huawei.com>;
> teas@ietf.org
> Cc: NetSlices@ietf.org
> Subject: Re: [Teas] terminology discussion network slicing
> 
> Hi Cristina,
> 
> You said:
> 
> [Cr]
> 
> 2) Unlike hard isolation technologies (e.g., FlexE), even bound to other
> TE-tunnel or resource reservation protocols, different VPNs still have the risk
> of underlying resource competition in extremes.
> 
> 
> On this I fully agree with you. Dynamically re-configurable L3/L2 network
> topologies supported by hard separation transport connectivity (such as OTN
> or FlexE) have a potential to deliver far better level of separation than legacy
> L2/K3 VPNs. The work done in TEAS WG can greatly help the IETF network
> slicing story.
> 
> Cheers,
> Igor
> 
> 
> -----Original Message-----
> From: qiangli (D)
> Sent: Wednesday, May 24, 2017 4:40 AM
> To: Daniele Ceccarelli; Igor Bryskin; Leeyoung; teas@ietf.org
> Cc: NetSlices@ietf.org
> Subject: 答复: [Teas] terminology discussion network slicing
> 
> Hi Danielle and Igor,
> 
> please see my reply inline below, marked as >>[Cr].
> 
> 
> Best regards,
> 
> Cristina QIANG
> 
> 
> -----邮件原件-----
> 发件人: Netslices [mailto:netslices-bounces@ietf.org] 代表 Daniele
> Ceccarelli
> 发送时间: 2017年5月24日 5:01
> 收件人: Igor Bryskin; Leeyoung; teas@ietf.org
> 抄送: NetSlices@ietf.org
> 主题: Re: [Netslices] [Teas] terminology discussion network slicing
> 
> Hi Igor,
> 
> let me try to answer in line.
> 
> Cheers
> Daniele  (with a single L) :)
> 
> -----Original Message-----
> From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Igor Bryskin
> Sent: sabato 20 maggio 2017 00:12
> To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Leeyoung
> <leeyoung@huawei.com>; teas@ietf.org
> Cc: NetSlices@ietf.org
> Subject: Re: [Netslices] [Teas] terminology discussion network slicing
> 
> Hi Danielle,
> 
> Network slicing may have nothing to do with radio. 5g is just a big reason as
> to why the interest/focus is back on network slicing, which is a very old
> concept. I don't think that anyone is arguing with what you wrote.
> 
> [>DC] Whether the network slice has to do with radio depends on the
> definition of network slice. If we focus on the "transport" slice then I agree
> with you, but the network slice IMO spans multiple domains/segments and
> radio can be one of them (as well as e.g. the cloud)
> 
>  The questions are:
> a) how do you manage these "pieces"?
> [>DC]  I would say independently in each domain/segment and then at the
> orchestration level someone will be in charge to put the pieces together.
> >>[Cr] This question is related to the architecture of netslice. Daniele's
> answer is just one possibility (i.e, independently in each domain/segment + a
> common orchestration platform above). I can see another possibility that is
> independently each domain/segment + cross-domain/cross-segment
> negotiation & interoperation. IMO, the latter one may be more practical for
> netslice, since an end-to-end slice may involves different
> operators/administrative regions, and there does not exist a common
> platform.
> 
> b) what policy infrastructure should be put in place?
> [>DC] good question. This definitely needs to be end to end, since the user is
> paying for it.
> 
> c) how do you ensure their separation or, conversely, the degree of resource
> sharing?
> [>DC] Again per domain/segment. In the cloud you might have different
> slices sharing the same VNG (e.g. IMS or Packet Core), while in the
> "transport" you might have different slices sharing a same tunnel or having
> dedicated one.
> 
> d) why exactly legacy VPNs are not good enough?
> [>DC] IMO legacy VPNs are good enough as "transport" slice. There are
> several mechanisms to e.g. extend them from the "transport" domain to the
> cloud domain or to stitch them to e.g. VXLAN in the DC. They just need to be
> bound to a TE-tunnel or an ACTN VN if you want to have guaranteed SLA for
> the service using such VPN
> >>[Cr] I will not deny that VPN could be one of the solutions for network
> slicing. However, it still has some deficiencies:
> 1) as a overlay technology, it has little control of network resources
> 2) Unlike hard isolation technologies (e.g., FlexE), even bound to other
> TE-tunnel or resource reservation protocols, different VPNs still have the risk
> of underlying resource competition in extremes.
> 
> 
> Cheers,
> Igor
> 
> 
> 
> 
> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
> Sent: Friday, May 19, 2017 4:19 PM
> To: Leeyoung; teas@ietf.org
> Cc: NetSlices@ietf.org
> Subject: Re: [Teas] terminology discussion network slicing
> 
> 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.
> 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.
> 
> 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.
> 
> 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:teas-bounces@ietf.org] On Behalf Of Leeyoung
> Sent: venerdì 19 maggio 2017 15:15
> To: teas@ietf.org
> Cc: NetSlices@ietf.org
> 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: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
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
> 
> _______________________________________________
> Netslices mailing list
> Netslices@ietf.org
> https://www.ietf.org/mailman/listinfo/netslices
> 
> _______________________________________________
> Netslices mailing list
> Netslices@ietf.org
> https://www.ietf.org/mailman/listinfo/netslices
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas