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

From: "Susan Hares" <[email-masked]>
Date: Thu, 1 Jun 2017 04:51:45 -0400

Geng Liang: 

The service models that MED suggests fit within the type of service model fits within the original topology model (draft-ietf-i2rs-yang-network-topo-12).   I2RS WG did not have a particular community of interested operators to work on services models for:  

·         A service model to capture the requirements from applications/customers 

·         A service model to expose the capabilities of an underlying infrastructure 

These model would be a specific effort that parallels the TEAS efforts traffic engineering and QOS work.  This focus augments the TEAS and I2RS work.   

These models could leverage the NETCONF/NETMOD capabilities linked to the I2RS topology work.  The new NETCONF/NETMOD capabilities support:

1)      New PUSH mechanisms in NETCONF/RESTCONF for better telemetry mechanisms for monitoring and OAM work, and  

2)      dynamic datastores in the netmod data model structures:  https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores.   

Dynamic datastores allows different policies for models so that OAM functions can gather data from other data models across the network.   Dynamic datastores and the ephemeral datastore work in I2RS would provide the necessary “foundations” for your work tenant/provider OAM work in a secure fashion. 

Put simply, I2RS and TEAS have been building the foundations for applications like the net-slices service application.  By focusing on the service model, you can provide the requirements to these other WGs.   

I would be glad to provide addition input on this topic.

Best regards. 

Sue Hares 

From: Netslices [mailto:[email-masked]] On Behalf Of GENG Liang
Sent: Thursday, June 1, 2017 1:32 AM
To: [email-masked]; Anton Ivanov; [email-masked]
Subject: Re: [Netslices] [Teas] terminology discussion network slicing

Hi Med, Anton and all

I have my hands on with Med and Anton that defining models are currently the identified major issues of network slicing in the scope of IETF.

As an additional layer of abstraction of infrastructure/resources/fuctions etc., it only makes sense when multiply slices co-exists on a shared network in a Network Slice Provider point of view. The level of dedication depends on Network Slice Provider's business model and Network Slice Tenant's requirements. Having this in mind and back to Anton's and Med's points of IETF works:

Anton's suggestion

> 1. Layer 3 and higher protocols.

Yes if it is at the level of network slice concerns itself, not data/control plane for any flow QoS guarantee - this is not slice-specific issues.

> 2. Models describing network abstractions

Agree, maybe also plus information+service model capturing Network Slice Tenant's requirements

> 3. Interoperability with other IETF efforts.

Agree, many other IETF efforts maybe utilized in specific segment of a network slice instance. This should also echos with the layer of network slice abstraction. 

Med's suggestion

* A service model to capture the requirements from applications/customers

* A service model to expose the capabilities of an underlying infrastructure

If we regard service model as a specific type of data model, I suggest we also include information model which is more abstract inscope as well, especially for modeling requirements from application/customers. They don't need to know slice and these models are likely to be protocol nonspecific.

* A mechanism to automate the process of requesting underlying services and handling these requests

Agree, I understand this as E2E/domain slice management and orchestration

* Some customized OAM

It is challenging to provide customized OAM to specific network slice tenant. However, I do agree this is an important feature for network slice since some Network Slice Tenant's would want certain level of control of their sliced network. This OAM has to be provisioned by network slice provider for reliability and security reasons.

Best wishes

Liang GENG 

China Mobile Research Institute

From: [email-masked]

Date: 2017-05-31 20:29

To: Anton Ivanov <mailto:[email-masked]> ; [email-masked]

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

Hi Anton, all,

I do fully agree with you here that we need to be specific about the expected work to be conducted within the IETF. 

For where I sit, I see "network slice" as a construct that allows to offer differentiated services when crossing a domain. These differentiated services can be differentiated IP transfer capabilities and may invoke advanced Service Functions (as per SFC). 

A network slice can be seen as an augmented version of the PDB (Per-Domain Behavior, RFC3086) concept since not only forwarding is differentiated but also other dimensions.

Which technology-specific mechanisms are to be enabled to put into effect a slice is really a deployment matter. 

>From that standpoint, the topics that I do think the IETF can contribute to are:

* A service model to capture the requirements from applications/customers

* A service model to expose the capabilities of an underlying infrastructure

* A mechanism to automate the process of requesting underlying services and handling these requests

* Some customized OAM

(please refer to draft-wu-opsawg-service-model-explained for a good definition on the service models)

Cheers,

Med 

> -----Message d'origine-----

> De : Netslices [mailto:[email-masked]] De la part de Anton

> Ivanov

> Envoyé : mardi 30 mai 2017 14:39

> À : [email-masked]

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

> On 30/05/17 12:44, sebastian wrote:

> > Hello, Gert,

> > Good points.

> > There are various instantiations of a 'network slice' that are likely,

> based on a diverse array of usage scenarios.

> > These diverse instantiations of a 'network slice', with a corresponding

> allocation of the required logical or physical resources, should be

> allowed to suit different usage scenarios that may range from a 'segment'

> to 'e2e' (end-to-end), in a 5G ecosystem.

> > Hence a generalized definition for the instantiation of a 'network

> slice' such as the one referred to below (3GPP) is reasonable:

> >      "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."

> That is excellent. And too broad. That can be anything from connection

> between two computers and a whole provider network. They both fit this

> rather elastic definition.

> So, in order for this to be discussed at IETF at all we should limit the

> scope a little bit to one or more subject areas worked on at IETF:

> 1. Layer 3 and higher protocols.

> 2. Models describing network abstractions

> 3. Interoperability with other IETF efforts.

> Otherwise, both the definition and the discussion should stay at 3GPP.

> They are good at discussing schemes of world domination, though from a

> point of view of network technology the results are quite often fit for

> Mr Bean, instead of Mr Blofeld (as intended).

> A.

> > Many thanks.

> > -Sebastian

> > -----Original Message-----

> > From: Netslices [mailto:[email-masked]] On Behalf Of Gert

> Grammel

> > Sent: Tuesday, May 30, 2017 6:17 AM

> > To: Daniele Ceccarelli <[email-masked]>; [email-masked]

> > Cc: [email-masked]

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

> > Hi Daniele,

> > See below for more details:

> > On 2017-05-30, 10:17, "Daniele Ceccarelli"

> <[email-masked]> wrote:

> >      Ciao Gert,

> >      Please see in line

> >      Cheers

> >      Daniele

> >      -----Original Message-----

> >      From: Teas [mailto:[email-masked]] On Behalf Of Gert Grammel

> >      Sent: lunedì 29 maggio 2017 15:34

> >      To: Daniele Ceccarelli <[email-masked]>;

> [email-masked]; 'Igor Bryskin' <[email-masked]>;

> 'Jeff Tantsura' <[email-masked]>; 'qiangli (D)'

> <[email-masked]>; 'Leeyoung' <[email-masked]>; [email-masked]

> >      Cc: [email-masked]

> >      Subject: Re: [Teas] [Netslices] terminology discussion network

> slicing

> >      Daniele,

> >      Trying to summarize what you're saying: a Network slice is an

> overlay network with minimum service guarantees, including virtual network

> functions available in this overlay network.

> >      [>DC] why do you speak about an overlay network? If for example you

> have a site connected with a lambda to a data center and there you have a

> number of VNF, that's IMO a slice but there is no overlay. I'd say that

> there could be an overlay but that's not mandatory.

> > GGR> A Lambda travels through a WDM which is a Multiplexer (see

> discussion below). So a lambda is in my view an overlay, the multiplexed

> signal (OMS) being the underlay.

> >      In your text I have issues with "dedicated to a given customer".

> Whether such construct is dedicated to one or shared among several legal

> customers shouldn't be of concern for the definition of a Network Slice.

> >      [>DC] Correct, it should be possible to have it dedicated or

> shared. We just need to make sure that both options are supported.

> > GGR>> So if it can either be dedicated or shared, why mentioning this at

> all? Is there anything else?

> >      On similar terms, whether a resource (being a NF or transport

> capacity) is shared or not is a design choice rather than a definition. In

> particular, Multiplexer by definition share some sort of common capacity

> irrespective whether it is TDM, Packet, WDM or CDM. So, the nature of

> multiplexing technique shouldn't be a definition criteria for a Network

> Slice either.

> >      Another food for thought:

> >      - I would also add that a network slice may use it's own internal

> addressing scheme isolated from other slices. While this is optional, I

> would expect it to be used quite often.

> >      [>DC] agree. Ala VPN.

> >      - Why is it necessary to dedicate resources to a "Network Slice" at

> all? If e.g. a firewall NFV is in the DC and communicates over the

> Internet with a CPE (both belonging to a single owner) it would not fulfil

> the criteria of dedicated resource (Internet after all isn't dedicated),

> but it still looks pretty much like a "network slice".

> >      [>DC] Think of remote surgery...wouldn't you want every single part

> of the end to end network from the doctor's hands to the scalpel being

> totally dedicated? :) ...and in that case I don't think the packets would

> go through the internet

> > GGR>> There are a few issues here:

> > 1) this example looks a bit out-dated to me. There is only a one-to-one

> relationship between doctor and patient. This is what I would call a

> classical client-server model with protected resources. Ask for SONET

> leased line circuits if this is what a "slice" would mean. In defining

> what constitutes a slice you would also have to think about what

> constitutes a "doctor-slice" and what would be a "patient-slice"?

> (assuming responsible health care to avoid sarcastic interpretation)

> > 2) The question asked in my earlier email is whether the packets *must*

> go through a dedicated resource to call the thing "slice". In other words,

> if a thing that uses a non-dedicated "underlay" resource like the Internet

> can be called "slice" too? It is puzzling to me why the definition of

> "slice" would need any dedicated resource at all. It is in the end an

> implementers choice how much dedicated equipment is needed to provide a

> service. So why a slice has to use "dedicated resources", and what kind of

> "dedication" is meant? (See our earlier discussion about WDM)? Take your

> mobile as an example. It supports telephony and email. Those are different

> apps, potentially running in different VMs.

> > a. Is your phone a shared device or a dedicated one?

> > b. does using different apps means to use a different slices?

> > c. If you write emails to different recipients, would that qualify your

> email to be "dedicated", hence a different slice, just because they are in

> different address books?

> > d. If you switch from 3G to VoIP, does it mean to switch the slice, even

> if it is the same app?

> > GGR> My thinking is that the definition of "slice" needs to make

> practical sense. The 3GPP definition is probably a bit too high level but

> makes sense to me:

> >      "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."

> >      Gert

> >      On 2017-05-29, 11:01, "Teas on behalf of Daniele Ceccarelli" <teas-

> [email-masked] on behalf of [email-masked]> wrote:

> >          Hi Sebastian, Jeff, Igor, all,

> >          I understand Jeff and Igor agree on the fact that a network

> slice does not necessarily include resources in the radio segment/domain

> and in the packet core one.

> >          An example could be an enterprise with dedicated resources in

> the "transport" segment (e.g. VPN, VN and TE-tunnels) that connect the

> customer premises to a data center where a number of VNF (e.g. firewall,

> nat, dpi) is dedicated to that given customer.

> >          My personal opinion is that this should be considered a network

> slice.

> >          The definition of network slice should allow for this scenario

> and mostly should clearly state whether this is included or not.

> >          Sebastian, I don't understand if your statement:

> >          " The management and orchestration of resources should be

> capable of instantiating a 'network slice' with an e2e (end-to-end) scope,

> where the scope could be between two devices, connected across intervening

> radio networks and core networks that may belong to the same or different

> administrative domains."

> >          implies that there must be a radio and a core segment in order

> to have a slice.

> >          BR

> >          Daniele

> >          -----Original Message-----

> >          From: sebastian [mailto:[email-masked]]

> >          Sent: domenica 28 maggio 2017 07:12

> >          To: 'Igor Bryskin' <[email-masked]>; 'Jeff Tantsura'

> <[email-masked]>; 'qiangli (D)' <[email-masked]>; Daniele

> Ceccarelli <[email-masked]>; 'Leeyoung'

> <[email-masked]>; [email-masked]

> >          Cc: [email-masked]

> >          Subject: RE: [Netslices] [Teas] terminology discussion network

> slicing

> >          Hello, Jeff,

> >          Agree with your view that the scope (core and/or radio layer)

> of a 'network slice' could vary depending on the triggers for

> instantiating the 'network slice'.

> >          On the other hand the instantiation of a 'network slice' may

> also be e2e (end-to-end), such as in device roaming scenarios, or in the

> case of vertical services that span different service providers.

> >          The span of a 'network slice' is only limited by the

> availability of resources and appropriate policies (e.g. SLAs),

> independent of whether those resources are in the core network layer or in

> the radio network layer.

> >          The management and orchestration of resources should be capable

> of instantiating a 'network slice' with an e2e (end-to-end) scope, where

> the scope could be between two devices, connected across intervening radio

> networks and core networks that may belong to the same or different

> administrative domains.

> >          Many thanks.

> >          -Sebastian

> >          -----Original Message-----

> >          From: Netslices [mailto:[email-masked]] On Behalf

> Of Igor Bryskin

> >          Sent: Wednesday, May 24, 2017 7:56 AM

> >          To: Jeff Tantsura <[email-masked]>; qiangli (D)

> <[email-masked]>; Daniele Ceccarelli

> <[email-masked]>; Leeyoung <[email-masked]>;

> [email-masked]

> >          Cc: [email-masked]

> >          Subject: Re: [Netslices] [Teas] terminology discussion network

> slicing

> >          Thanks Jeff,

> >          I am glad we are in sync.

> >          Igor

> >          -----Original Message-----

> >          From: Jeff Tantsura [mailto:[email-masked]]

> >          Sent: Wednesday, May 24, 2017 8:45 AM

> >          To: Igor Bryskin; qiangli (D); Daniele Ceccarelli; Leeyoung;

> [email-masked]

> >          Cc: [email-masked]

> >          Subject: Re: [Teas] terminology discussion network slicing

> >          +1 Igor

> >          From transport side (L0-L3) we need to expose set of API’s that

> would allow to request a set of resources (a slice) either virtualized of

> physical that meet the constrains as requested by the business logic.

> Radio, while would definitely be one of most important use cases, would

> not be exclusively for radio use only. Any network management/

> orchestration layer ideally should be able to use same set of API’s to

> request an e2e service.

> >          Cheers,

> >          Jeff

> >          On 5/24/17, 05:26, "Teas on behalf of Igor Bryskin" <teas-

> [email-masked] on behalf of [email-masked]> wrote:

> >              Hi Cristina,

> >              I didn’t say that ns has nothing to do with radio. I said

> that ns *may* have nothing to do with radio, i.e. may support/enable

> network architectures that do not involve radio necessarily.

> >              Igor

> >              -----Original Message-----

> >              From: qiangli (D)

> >              Sent: Wednesday, May 24, 2017 5:05 AM

> >              To: Igor Bryskin; Daniele Ceccarelli; Leeyoung;

> [email-masked]

> >              Cc: [email-masked]

> >              Subject: 答复: [Teas] terminology discussion network slicing

> >              Hi Igor,

> >              I share the same opinion on 5G and network slicing, but

> can't see the relation between this opinion and your conclusion that ns

> has nothing to do with radio.

> >              Best regards,

> >              Cristina QIANG

> >              -----邮件原件-----

> >              发件人: Igor Bryskin

> >              发送时间: 2017年5月20日 23:50

> >              收件人: qiangli (D); Daniele Ceccarelli; Leeyoung;

> [email-masked]

> >              抄送: [email-masked]

> >              主题: RE: [Teas] terminology discussion network slicing

> >              Hi Cristina,

> >              People whose opinion I respect very much told me that even

> the 3GPP network slicing definition and effort is not 5G specific.

> Network slicing is viewed as an important capability of 5G, but it could

> serve other architectures.

> >              Cheers,

> >              Igor

> >              -----Original Message-----

> >              From: qiangli (D)

> >              Sent: Saturday, May 20, 2017 5:27 AM

> >              To: Igor Bryskin; Daniele Ceccarelli; Leeyoung;

> [email-masked]

> >              Cc: [email-masked]

> >              Subject: 答复: [Teas] terminology discussion network slicing

> >              Hi Igor,

> >              I have different opinion on " Network slicing may have

> nothing to do with radio".

> >              IMO, network slicing should be a resource-oriented

> management mode. The end-to-end network slice (from UE to server/other UE)

> of course involves the radio resource, usually we use the word "RAN-radio

> access network" rather than simply say "radio". The Frequency band, time,

> code, equipment/site, and software are a number of dimensions, in which

> RAN resources can be isolated [Online available

> http://www.huawei.com/en/industry-insights/mbb-2020/trends-insights/5g-

> service-guaranteed-network-slicing-whitepaper].

> >              Best regards,

> >              Qiang, Li (Cristina)

> >              NetLab, Huawei

> >              -----邮件原件-----

> >              发件人: Netslices [mailto:[email-masked]] 代表 Igor

> Bryskin

> >              发送时间: 2017年5月20日 6:12

> >              收件人: Daniele Ceccarelli; Leeyoung; [email-masked]

> >              抄送: [email-masked]

> >              主题: 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. The questions are:

> >              a) how do you manage these "pieces"?

> >              b) what policy infrastructure should be put in place?

> >              c) how do you ensure their separation or, conversely, the

> degree of resource sharing?

> >              d) why exactly legacy VPNs are not good enough?

> >              Cheers,

> >              Igor

> >              -----Original Message-----

> >              From: Teas [mailto:[email-masked]] On Behalf Of

> Daniele Ceccarelli

> >              Sent: Friday, May 19, 2017 4:19 PM

> >              To: Leeyoung; [email-masked]

> >              Cc: [email-masked]

> >              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:[email-masked]] On Behalf Of

> Leeyoung

> >              Sent: venerdì 19 maggio 2017 15:15

> >              To: [email-masked]

> >              Cc: [email-masked]

> >              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:[email-masked]]

> >              Sent: Tuesday, May 16, 2017 8:35 AM

> >              To: Igor Bryskin <[email-masked]>; Belotti, Sergio

> (Nokia - IT/Vimercate) <[email-masked]>; Gert Grammel

> <[email-masked]>; Leeyoung <[email-masked]>; [email-masked];

> [email-masked]

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

> <[email-masked]> 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:[email-masked]] On Behalf Of

> Belotti, Sergio

> >              > (Nokia - IT/Vimercate)

> >              > Sent: Tuesday, May 16, 2017 6:08 AM

> >              > To: Gert Grammel; Leeyoung; [email-masked];

> [email-masked]

> >              > 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:[email-masked]] On Behalf Of

> Gert Grammel

> >              > Sent: Monday, May 15, 2017 7:02 PM

> >              > To: Leeyoung <[email-masked]>; [email-masked];

> [email-masked]

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

> >              > <[email-masked] on behalf of [email-masked] <mailto:[email-masked][email-masked]> >

> 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: [email-masked]

> >              >     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:[email-masked]] On Behalf

> Of [email-masked]

> >              >     Sent: Friday, May 05, 2017 10:41 AM

> >              >     To: [email-masked]

> >              >     Cc: [email-masked]

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

> >              >     [email-masked]

> >              >     https://www.ietf.org/mailman/listinfo/teas

> >              >     _______________________________________________

> >              >     Teas mailing list

> >              >     [email-masked]

> >              >     https://www.ietf.org/mailman/listinfo/teas

> >              > _______________________________________________

> >              > Teas mailing list

> >              > [email-masked]

> >              > https://www.ietf.org/mailman/listinfo/teas

> >              > _______________________________________________

> >              > Teas mailing list

> >              > [email-masked]

> >              > https://www.ietf.org/mailman/listinfo/teas

> >              > _______________________________________________

> >              > Teas mailing list

> >              > [email-masked]

> >              > https://www.ietf.org/mailman/listinfo/teas

> >              _______________________________________________

> >              Teas mailing list

> >              [email-masked]

> >              https://www.ietf.org/mailman/listinfo/teas

> >              _______________________________________________

> >              Teas mailing list

> >              [email-masked]

> >              https://www.ietf.org/mailman/listinfo/teas

> >              _______________________________________________

> >              Netslices mailing list

> >              [email-masked]

> >              https://www.ietf.org/mailman/listinfo/netslices

> >              _______________________________________________

> >              Teas mailing list

> >              [email-masked]

> >              https://www.ietf.org/mailman/listinfo/teas

> >          _______________________________________________

> >          Netslices mailing list

> >          [email-masked]

> >          https://www.ietf.org/mailman/listinfo/netslices

> >          _______________________________________________

> >          Teas mailing list

> >          [email-masked]

> >          https://www.ietf.org/mailman/listinfo/teas

> >      _______________________________________________

> >      Teas mailing list

> >      [email-masked]

> >      https://www.ietf.org/mailman/listinfo/teas

> > _______________________________________________

> > Netslices mailing list

> > [email-masked]

> > https://www.ietf.org/mailman/listinfo/netslices

> > _______________________________________________

> > Netslices mailing list

> > [email-masked]

> > https://www.ietf.org/mailman/listinfo/netslices

> _______________________________________________

> Netslices mailing list

> [email-masked]

> https://www.ietf.org/mailman/listinfo/netslices

_______________________________________________

Netslices mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/netslices