Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

From: "Natale, Bob" <[email-masked]>
Date: Mon, 6 Feb 2017 13:25:25 +0000

Hi Alex,

I just have two basic questions - more like "requests" - for now:

- How does a network "slice" differ from all established forms of network virtualization (VLANs, VPNs, SDPs, etc.?

- Do we really need the term "softwarization" (and its various derivatives) ... isn't that just a confounding way of saying "virtualization" ... as in "softwarizing and separating
   logical network components from the underlying physical network resources" ... isn't that latter part what we commonly call virtualization and, if so, how does "softwarization" differ from it?

>From a lurker,
BobN

From: Netslices [mailto:[email-masked]] On Behalf Of Alex Galis
Sent: Friday, January 20, 2017 3:54 AM
To: Network Slices <[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]>; Stewart Bryant <[email-masked]>; Alex Galis <[email-masked]>; Kiran.Makhijani <[email-masked]>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

20th January 2017

Dear All

Re:  Network Slicing - Introductory Document and Revised Problem Statement

         https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-00.txt

Thank you for your expressed interest in the Network Slicing.

One of the action from the Network Slicing side meeting at IETF 97 of 15th Nov 2016 was to consolidate all suggestions and comments received into an unified initial revised problem statement and work plan which would be the basis of a BoF at IETF 98 or IETF99. Such an introductory document is ready for your review and it is enclosed as a draft.

Would you be so kind as to provide your feedback, comments, contributions and work interest with the view of further progressing this draft for un update and presentation at IETF 98.

Thank you in advance,
Best Regards
Alex, Jie, Kiran and Stewart

Network Slicing - Introductory Document and Revised Problem Statement

Abstract:
  This document represents an introduction to the motivation and
  Network Slicing problems and work ares. It represents an initial
  revision of Network Slicing problem statement derived from the
  analysis of the technical gaps in IETF protocols ecosystem. It
  complements and it bring together the isolated efforts being carried
  out in several IETF working groups to achieve certain aspects of
  network slice functions and operations.
_______________________________________________
Netslices mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netslices

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 6 Feb 2017 21:57:17 +0000

Hey Bob,

Here are a few points that I find useful to understand Slicing and VPN's.

1.      A "slice" in the context of 5G is essentially an end to end set of resources which make up a fully functional wireless network drawn from larger pool of end to end resources.

2.      A slice is therefore a superset of the capabilities of an L0,L1,L3 or L3 VPN.

3.      An L2VPN or L3VPN is likely a useful connectivity model for the control and user plane data paths for the obvious reasons and DETNET type capabilities are of interest for stricter QOS guarantees. For even stricter guarantees ACTN etc. and L0/L1 control is required.

4.      I hate the term "softwarization" also, but essentially it's being used to describe a programmatic interface to each of the end to end sets of resources to allow them to be allocated/linked/deallocated/grown/shrunk etc. and is therefore more than just virtualization but of course covers virtualization.

I gave a short presentation on this at 5gandIp meeting last year which you may find useful, I'll be happy to send it to you directly or I suspect it's on an IETF server somewhere.

Cheers,

Peter

From: Netslices [mailto:[email-masked]] On Behalf Of Natale, Bob
Sent: Monday, February 06, 2017 8:25 AM
To: Alex Galis <[email-masked]>; Network Slices <[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]>; Kiran.Makhijani <[email-masked]>; Stewart Bryant <[email-masked]>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Hi Alex,

BobN

From: Netslices [mailto:[email-masked]] On Behalf Of Alex Galis
Sent: Friday, January 20, 2017 3:54 AM
To: Network Slices <[email-masked]<mailto:[email-masked]>>
Cc: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>; Alex Galis <[email-masked]<mailto:[email-masked]>>; Kiran.Makhijani <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

20th January 2017

Dear All

Thank you in advance,
Best Regards

Abstract:

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Feb 2017 18:51:50 -0500

Peter: 

On #3 on your list - do you believe all the L2VPN and L3VPN features are
needed?  Or can you suggest a smalls subset of these features that will be
needed to support network slicing. 

On #4 - how is this programmatic interface to the control plane different
than the work we are doing in I2RS.  

I would appreciate a copy of your short presentation on this matter. 

Sue Hares 

From: Netslices [mailto:[email-masked]] On Behalf Of
AshwoodsmithPeter
Sent: Monday, February 6, 2017 4:57 PM
To: Natale, Bob; Alex Galis; Network Slices
Cc: Dongjie (Jimmy); Stewart Bryant; Kiran.Makhijani
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised
Problem Statement

Hey Bob,

1.      A "slice" in the context of 5G is essentially an end to end set of
resources which make up a fully functional wireless network drawn from
larger pool of end to end resources. 

2.      A slice is therefore a superset of the capabilities of an L0,L1,L3
or L3 VPN.

3.      An L2VPN or L3VPN is likely a useful connectivity model for the
control and user plane data paths for the obvious reasons and DETNET type
capabilities are of interest for stricter QOS guarantees. For even stricter
guarantees ACTN etc. and L0/L1 control is required.

4.      I hate the term "softwarization" also, but essentially it's being
used to describe a programmatic interface to each of the end to end sets of
resources to allow them to be allocated/linked/deallocated/grown/shrunk etc.
and is therefore more than just virtualization but of course covers
virtualization.

I gave a short presentation on this at 5gandIp meeting last year which you
may find useful, I'll be happy to send it to you directly or I suspect it's
on an IETF server somewhere.

Cheers,

Peter

From: Netslices [mailto:[email-masked]] On Behalf Of Natale, Bob
Sent: Monday, February 06, 2017 8:25 AM
To: Alex Galis <[email-masked]>; Network Slices <[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]>; Kiran.Makhijani
<[email-masked]>; Stewart Bryant <[email-masked]>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised
Problem Statement

Hi Alex,

- How does a network "slice" differ from all established forms of network
virtualization (VLANs, VPNs, SDPs, etc.?

- Do we really need the term "softwarization" (and its various derivatives)
. isn't that just a confounding way of saying "virtualization" . as in
"softwarizing and separating

   logical network components from the underlying physical network
resources" . isn't that latter part what we commonly call virtualization
and, if so, how does "softwarization" differ from it?

BobN

From: Netslices [mailto:[email-masked]] On Behalf Of Alex Galis
Sent: Friday, January 20, 2017 3:54 AM
To: Network Slices <[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]>; Stewart Bryant
<[email-masked]>; Alex Galis <[email-masked]>; Kiran.Makhijani
<[email-masked]>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised
Problem Statement

20th January 2017

Dear All

https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-00.tx
t

One of the action from the Network Slicing side meeting at IETF 97 of 15th
Nov 2016 was to consolidate all suggestions and comments received into an
unified initial revised problem statement and work plan which would be the
basis of a BoF at IETF 98 or IETF99. Such an introductory document is ready
for your review and it is enclosed as a draft.
 
Would you be so kind as to provide your feedback, comments, contributions
and work interest with the view of further progressing this draft for un
update and presentation at IETF 98.
 
Thank you in advance,
Best Regards

 
Abstract:

[email-masked]

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Tue, 7 Feb 2017 09:31:45 +0900

Dear al,

Regarding the relation between current virtualization, network slicing,
and softwarization, I insist what I had already mentioned it in our F2F
meeting @ IETF 97, that we have some clashes. For instance:

- A slice is, by definition, "a portion" of something. There is no E2E
  implied on it, but there can be specifications including it (e.g. E2E
  slices).

- I identify two different but complementary points of view in relation
  to "network slices":
  
  1) The result of partitioning a set of (physical/virtual) resources to
  get the aforementioned "portions". This is the operator/owner point of
  view and is intrinsically related to the embedding and management.

  2) The set of resource portions assigned to a singe entity. As it is
  being currently used, for instance, by PlanetLab, a "slice" means a
  portion of the whole infrastructure and not just a portion of a single
  resource.

- The relation between virtualiation and slicing is that the latter can
  be implemented by the former. However, slices could be instantiated by
  other means, so the separate definitions are not superfluous. Also, it
  is not fair to link VPN capabilities and slices. A VPN can be embedded
  on a slice, but it is not the only purpose of the latter, so such link
  of capabilities could end up in some misunderstandings.

- Softwarization is "the act of converting hard-ware to soft-ware". It
  is not an interface or a mechanism but a method and process. As with
  slicing, virtualization can be used to implement such "process", but
  it is not limited to it. In fact, it could be the other way around, so
  using softwarized systems to implement virtual systems. For instance,
  an OpenFlow Switch is "a sofwarized switch" and its main relation to
  virtualization is that the flexibility provided by such softwarization
  process can be used to "slice" a physical switch and provide isolated
  virtual switches (using some tool like FlowVisor). This shows a way of
  link the three terms (slicing, softwarization, and virtualization).

Contrasting these and previous explanations, and considering all of them
as valid from different perspectives, I conclude that there are still
many nuances that need to be clarified and maybe some misconceptions on
current concepts that should be eradicated. Therefore, I insist in the
need to make some collaborative document (wiki, Google Doc, etc.) to try
to reach a common and agreed set of definitions.

Regards,
Pedro

-- 
Pedro Martinez-Julia
Network Science and Convergence Device Technology Laboratory
Network System Research Institute
National Institute of Information and Communications Technology (NICT)
4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan
Email: [email-masked]
---------------------------------------------------------
*** Entia non sunt multiplicanda praeter necessitatem ***

---

From: Yudelei <[email-masked]>
Date: Tue, 7 Feb 2017 01:51:18 +0000

Hi, all
I reply on this thread, but I’ve read another thread Jim start.
Before argue on the terminology definition and scope, it need to come to the requirement again.
I conclude the two important requirement as:

1.       Dedicated network resource for a network slice.

2.       Independent operation on a network slice
There are no absolute dedicated resource, e.g., even use two fiber each for one network slice, they may still share the same plastic pipe. But if use MPLS label, it will be shared on VPN tunnel level, the thing may just keep in VPN scope, there actually no network slice concept, what we do is just call the VPN to another name. So I suggest we define the network slice more on dedicated resource, suppose to provide the dedicated enough logical path/port/link/node to the network slice tenant. I understand it is a un-efficient way to do this, against the sharing spirit of MPLS/IP network. This will be compensate by network slice management dynamically.
The network slice is to be provided to a particular e.g. 5G service or a 5G tenant. So it is allowed the network slice tenant to operate on it independently, the network slice looks like a dedicated network for the tenant, it has a logical topology, with expected QoS property, the tenant can deploy the service on it, e.g., by programming interface, and can have state report from it. It is clear different with VPN, which cannot be operated on it by the tenant.

Delei

发件人: Netslices [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2017年2月7日 7:52
收件人: AshwoodsmithPeter; 'Natale, Bob'; 'Alex Galis'; 'Network Slices'
抄送: Dongjie (Jimmy); Kiran.Makhijani; 'Stewart Bryant'
主题: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Peter:

On #3 on your list – do you believe all the L2VPN and L3VPN features are needed?  Or can you suggest a smalls subset of these features that will be needed to support network slicing.

On #4 – how is this programmatic interface to the control plane different than the work we are doing in I2RS.

Sue Hares

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

Hey Bob,

Here are a few points that I find useful to understand Slicing and VPN’s.

1.      A “slice” in the context of 5G is essentially an end to end set of resources which make up a fully functional wireless network drawn from larger pool of end to end resources.

4.      I hate the term “softwarization” also, but essentially it’s being used to describe a programmatic interface to each of the end to end sets of resources to allow them to be allocated/linked/deallocated/grown/shrunk etc. and is therefore more than just virtualization but of course covers virtualization.

I gave a short presentation on this at 5gandIp meeting last year which you may find useful, I’ll be happy to send it to you directly or I suspect it’s on an IETF server somewhere.

Cheers,

Peter

From: Netslices [mailto:[email-masked]] On Behalf Of Natale, Bob
Sent: Monday, February 06, 2017 8:25 AM
To: Alex Galis <[email-masked]<mailto:[email-masked]>>; Network Slices <[email-masked]<mailto:[email-masked]>>
Cc: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Kiran.Makhijani <[email-masked]<mailto:[email-masked]>>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Hi Alex,

I just have two basic questions – more like “requests” – for now:

- How does a network “slice” differ from all established forms of network virtualization (VLANs, VPNs, SDPs, etc.?

- Do we really need the term “softwarization” (and its various derivatives) … isn’t that just a confounding way of saying “virtualization” … as in “softwarizing and separating
   logical network components from the underlying physical network resources” … isn’t that latter part what we commonly call virtualization and, if so, how does “softwarization” differ from it?

From a lurker,
BobN

20th January 2017

Dear All

Thank you in advance,
Best Regards

Abstract:

---

From: "Natale, Bob" <[email-masked]>
Date: Tue, 7 Feb 2017 04:53:34 +0000

Hi Pedro,

Concerning your explanation that 'Softwarization is "the act of converting hard-ware to soft-ware"', isn't that just "function virtualization" as in, for example, NFV?

Avanti,
BobN

-----Original Message-----
From: Pedro Martinez-Julia [mailto:[email-masked]] 
Sent: Monday, February 06, 2017 7:32 PM
To: AshwoodsmithPeter <[email-masked]>
Cc: Natale, Bob <[email-masked]>; Alex Galis <[email-masked]>; Network Slices <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Stewart Bryant <[email-masked]>; Kiran.Makhijani <[email-masked]>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Dear al,

Regarding the relation between current virtualization, network slicing, and softwarization, I insist what I had already mentioned it in our F2F meeting @ IETF 97, that we have some clashes. For instance:

  

Contrasting these and previous explanations, and considering all of them as valid from different perspectives, I conclude that there are still many nuances that need to be clarified and maybe some misconceptions on current concepts that should be eradicated. Therefore, I insist in the need to make some collaborative document (wiki, Google Doc, etc.) to try to reach a common and agreed set of definitions.

Regards,
Pedro

--
Pedro Martinez-Julia
Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan
Email: [email-masked]
---------------------------------------------------------
*** Entia non sunt multiplicanda praeter necessitatem ***

---

From: "Natale, Bob" <[email-masked]>
Date: Tue, 7 Feb 2017 04:57:09 +0000

Thanks for the responses, Peter ... I'll stay in "learning mode" on these topics (with the aim of overcoming my skepticism :)).

(I would appreciate a copy of your presentation to help me in that endeavor.)

Avanti,
BobN

From: AshwoodsmithPeter [mailto:[email-masked]]
Sent: Monday, February 06, 2017 4:57 PM
To: Natale, Bob <[email-masked]>; Alex Galis <[email-masked]>; Network Slices <[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]>; Kiran.Makhijani <[email-masked]>; Stewart Bryant <[email-masked]>
Subject: RE: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Hey Bob,

Cheers,

Peter

Hi Alex,

BobN

20th January 2017

Dear All

Thank you in advance,
Best Regards

Abstract:

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Tue, 7 Feb 2017 14:26:10 +0900

On Tue, Feb 07, 2017 at 04:53:34AM +0000, Natale, Bob wrote:
> Hi Pedro,
> 
> Concerning your explanation that 'Softwarization is "the act of
> converting hard-ware to soft-ware"', isn't that just "function
> virtualization" as in, for example, NFV?

They can be somehow related but it is not the same concept. Using NFV to
illustrate the difference, it defines a set of fixed functions that are
virtualized, but the resulting functions are not 100% soft-ware because
they resemble the corresponding "hardware", which is quite fixed. Taking
this into account I would say that NFV is a mechanism for softwarizing a
network infrastructure (making it more flexible, programmable, etc.) but
it is only limited to the infrastructure boundary because the functions
themselves are "hard-fixed" unless they are also softwarized.

I hope this adds some useful concepts about the relations and diferences
between virtualization and softwarization...

Regards,
Pedro

---

From: Loa Andersson <[email-masked]>
Date: Tue, 7 Feb 2017 15:19:39 +0800

Folks,

I may be kicking in open doors, or alternatively showing that I 
misunderstood thing fundamentally.

I thought that "network slicing" meant that a network provider can
give a network user, a slice of the network (with all functions needed),
to satisfy the network users requirements.

So E2E if E2E is needed.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Tue, 7 Feb 2017 09:20:25 +0000

Hi Loa,

> I thought that "network slicing" meant that a network provider can give a network user, a slice of the network (with all functions needed), to satisfy the network users requirements. So E2E if E2E is needed.

Yes,  although that may not be fully E2E if the origin server is hosted outside of the providers' network. Network slicing should allow the network provider to rapidly allocate/deallocate network resources towards flows, based on the characteristics of each flow. So each flow will demand a certain blend of latency, mobility, capacity, resilience, pacing, durability etc. - it doesn't necessarily need to be a function as such, although those can be added a la service chaining if required. In a cellular network this can also include radio resources, so terminal-to-external-edge-of-operator-network (maybe 'operator domain' is snappier :)).

All best,
Kevin

Kevin Smith, Vodafone

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: 07 February 2017 07:20
To: [email-masked]
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Folks,

I may be kicking in open doors, or alternatively showing that I misunderstood thing fundamentally.

I thought that "network slicing" meant that a network provider can give a network user, a slice of the network (with all functions needed), to satisfy the network users requirements.

So E2E if E2E is needed.

/Loa

On 2017-02-07 13:26, Pedro Martinez-Julia wrote:
> They can be somehow related but it is not the same concept. Using NFV 
> to illustrate the difference, it defines a set of fixed functions that 
> are virtualized, but the resulting functions are not 100% soft-ware 
> because they resemble the corresponding "hardware", which is quite 
> fixed. Taking this into account I would say that NFV is a mechanism 
> for softwarizing a network infrastructure (making it more flexible, 
> programmable, etc.) but it is only limited to the infrastructure 
> boundary because the functions themselves are "hard-fixed" unless they are also softwarized.
>
> I hope this adds some useful concepts about the relations and 
> diferences between virtualization and softwarization...
>
>> Avanti,
>> BobN
>
> Regards,
> Pedro
>

--

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 7 Feb 2017 17:55:53 +0000

Hi Loa,

> I thought that "network slicing" meant that a network provider can give a network user

Agree with Kevin below and he put it more eloquently.  I see and  agree it's mostly  per user (well it could be)  but primarily for a flow in mobile networks with also different QoE requirements.

> In a cellular network this can also include radio resources, so terminal-to-external-edge-of-operator-network (maybe 'operator domain' is snappier :)).

Just to add a bit more, I see slice as a combination of radio resource, transport network resource and the packet core resource ..

Best Regards,
--
Uma C.

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Smith, Kevin, (R&D) Vodafone Group
Sent: Tuesday, February 07, 2017 1:20 AM
To: Loa Andersson <[email-masked]>; [email-masked]
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Hi Loa,

All best,
Kevin

Kevin Smith, Vodafone

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: 07 February 2017 07:20
To: [email-masked]
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Folks,

So E2E if E2E is needed.

/Loa

--

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 7 Feb 2017 18:16:02 +0000

On 07/02/2017 05:26, Pedro Martinez-Julia wrote:
> they resemble the corresponding "hardware", which is quite fixed.

I don't agree with that.

I can instantiate any function I wish as an NFV function, be it a well 
known function
such as a load balancer, or it can be some relatively unknown function 
such as a
homomorphic packet timestamper, or it could be some function only known
to the customer but hosted in the network as an opaque function.

I can dynamically provision such functions on CPU and add or remove them 
from
a path.

Thus I see no difference between a softwarized system and a system of NFV
components stitched together with SFC, at least with the definition 
provided
above.

>   Taking

Obviously I don't agree with that. What constrains them to be hard-fixed?

- Stewart

---

From: Andrew McLachlan <[email-masked]>
Date: Tue, 7 Feb 2017 18:21:03 +0000

Agree that it will be combinations of infrastructure to achieve something E2E in most cases, and I hope this does not drive us to put more complexity into the various control planes / infras, but rather we take an approach to expose the capabilities through high-functioning brokers, controllers and functions such as PCE.

Essentially this could be an NNI / UNI exercise out of band of the network. 

> On 7 Feb 2017, at 17:55, Uma Chunduri <[email-masked]> wrote:
> 
> Hi Loa,
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 7 Feb 2017 18:24:23 +0000

> Just to add a bit more, I see slice as a combination of radio resource, transport network resource and the packet core resource ..

Are those the position of the resources or the resources themselves?

In other words do you include or exclude functions inline with the path, 
and even functions at the terminal of the path?

So where does NFV and the compute resources to run it fit in?

Now people have talked about dedicated resources. Are the end customers 
prepared to pay for the consequences of dedicated resources? If a 
resource is dedicated they have to pay the full overhead cost of every 
nut and bolt along the path including a real proportion of some very 
expensive linecards, which contrasts with mainstream networking where 
these  costs are shared much more widely.

- Stewart

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 7 Feb 2017 18:32:57 +0000

Hi Stewart,

First let me correct I intend to say "not" per user mostly (well it could be)...
In-line [Uma]:
--
Uma C.

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Tuesday, February 07, 2017 10:24 AM
To: Uma Chunduri <[email-masked]>; Smith, Kevin, (R&D) Vodafone Group <[email-masked]>; Loa Andersson <[email-masked]>; [email-masked]
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

On 07/02/2017 17:55, Uma Chunduri wrote:
>> give a network user

[Uma]: Position is merely how the mobile network is architected today and being evolved, but I see it's about combination of E2E resources.

In other words do you include or exclude functions inline with the path, and even functions at the terminal of the path?
So where does NFV and the compute resources to run it fit in?

Now people have talked about dedicated resources. Are the end customers prepared to pay for the consequences of dedicated resources? If a resource is dedicated they have to pay the full overhead cost of every nut and bolt along the path including a real proportion of some very expensive linecards, which contrasts with mainstream networking where these  costs are shared much more widely.

[Uma]: I see this mostly shared flows (even considering  where 5G is going) with defined QCI values (with certain E2E promises on jitter, latency, Qos etc..). I don't think it's per user at all (but in future it may be .. I am not sure on that part!)

- Stewart

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 7 Feb 2017 21:54:30 +0000

Hi Sue, comments in-line.

Peter:

On #3 on your list - do you believe all the L2VPN and L3VPN features are needed?  Or can you suggest a smalls subset of these features that will be needed to support network slicing.

[PETER] - It's possible that the control planes may not be required in all their glory and that much of the functionality can be done via logically central control under an orchestrator of the different VPN data planes. This is because much of the VPN encapsulation happens in the DC's/C-RANs where more centralized control is the norm as opposed to fully distributed stuff that may be the case. In our proof of concepts we use fairly simple overlapping IP addresses spaces within a given slice with the same subnet actually in each slice to make it simpler to debug. Kind of like a template that you instantiate over and over again. Makes it simpler to understand.

On #4 - how is this programmatic interface to the control plane different than the work we are doing in I2RS.

[PETER] Well you are doing an interface to a routing system but slicing requires and interface to lots of different things including a routing system. It needs an interface to antennas, an interface to fronthaul, an interface to the cran DSPs, an interface to the cran fabric and eventually we get to interfaces to transport/routing/NFV etc. All that to say that softwarization is being used as a term to mean all the hardware and software end to end has programmable interfaces that meet an orchestration system. The softwarization may or may not end up in something virtual being created it can just as easily be something physical and as Loa alluded to in a later message the slices do not have to be end to end separate they can and will share many resources as long as there are other means to provide guarantees them where they overlap.

I would appreciate a copy of your short presentation on this matter

[PETER] will do In a direct email.

Sue Hares

Hey Bob,

Cheers,

Peter

Hi Alex,

BobN

20th January 2017

Dear All

Thank you in advance,
Best Regards

Abstract:

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 7 Feb 2017 22:05:11 +0000

One of the reasons I don't really like the term softwarization is because its being used in a few different ways.

Softwarization as I hear it in the context of 5G is being used to describe how all the bits and pieces that go together can be assembled and programmed by higher layer software. 

NFV is as you say being used to describe the use of software to replace hardware and thereby virtualize it. Hence softwarization does not imply virtualization.

So:

NFV can be softwarized by putting a proper layer above it to allow it to be programmed.
Antennas can be softwarized by putting a proper layer above them to allow them to be programmed.
The hut that stores eNBs can be softwarized by making access to its heat/cooling/security etc.

Many of the components that the IETF does are of course already 'softwarized' but the wireless world is slowly catching up with these concepts and hence you get some new terminology like softwarize/slicing etc. 

Peter

-----Original Message-----
From: Natale, Bob [mailto:[email-masked]] 
Sent: Monday, February 06, 2017 11:54 PM
To: Pedro Martinez-Julia <[email-masked]>; AshwoodsmithPeter <[email-masked]>
Cc: Alex Galis <[email-masked]>; Network Slices <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Stewart Bryant <[email-masked]>; Kiran.Makhijani <[email-masked]>
Subject: RE: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Hi Pedro,

Avanti,
BobN

-----Original Message-----
From: Pedro Martinez-Julia [mailto:[email-masked]] 
Sent: Monday, February 06, 2017 7:32 PM
To: AshwoodsmithPeter <[email-masked]>
Cc: Natale, Bob <[email-masked]>; Alex Galis <[email-masked]>; Network Slices <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Stewart Bryant <[email-masked]>; Kiran.Makhijani <[email-masked]>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Dear al,

  

Regards,
Pedro

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Wed, 8 Feb 2017 08:50:31 +0900

Dear Stewart,

Find my comments in-line.

On Tue, Feb 07, 2017 at 06:16:02PM +0000, Stewart Bryant wrote:
> > They can be somehow related but it is not the same concept. Using
> > NFV to illustrate the difference, it defines a set of fixed
> > functions that are virtualized, but the resulting functions are not
> > 100% soft-ware because they resemble the corresponding "hardware",
> > which is quite fixed.
> 
> I don't agree with that.
> 
> known function such as a load balancer, or it can be some relatively
> unknown function such as a homomorphic packet timestamper, or it could
> be some function only known to the customer but hosted in the network
> as an opaque function.
> 
> I can dynamically provision such functions on CPU and add or remove
> them from a path.
> 
> Thus I see no difference between a softwarized system and a system of
> NFV components stitched together with SFC, at least with the
> definition provided above.

As I mentioned in my following paragraph, what you are describing is a
softwarized "infrastructure" composed of non-softwarized functions. Thus
you are true that they are related, I am not saying the opposite, but it
is not the same.

We can say that "NFV is a mechanism to sofwarize the infrastructure
aspects of a network system" but it does not mean that "softwarization
is virtualization" or that "NFV is a subset of softarization". They are
different mechanisms/techniques for purposes that overlap, but only to
some extent.

> > Taking this into account I would say that NFV is a mechanism for
> > softwarizing a network infrastructure (making it more flexible,

I think that Pete's message in this thread gives a better illustration
of the meaning of such "hard-fixed" concept. In summary is that although
the infrastructure, as I mentioned above, can be programmable (flexible,
soft-ware), the individual mechanisms that compose do not usually expose
such degree of programmability. As you mentioned, a homomorphic packet
time stamper or a load balancer, for instance, usually have pre-defined
behaviours which are configurable but not programmable.

To sum up, I am not arguing that NFV "is not softwarization", just that
softwarization is not virtualization, at least "not just". They can have
some common goals but the former emphasizes the migration from pre-fixed
to dynamic *behaviors* while the latter lies in the migration from fixed
to dynamic *elements* (services, devices, infrastructures).

Regards,
Pedro

---

From: Loa Andersson <[email-masked]>
Date: Wed, 8 Feb 2017 11:51:16 +0800

Kevin,

On 2017-02-07 17:20, Smith, Kevin, (R&D) Vodafone Group wrote:
> Yes,  although that may not be fully E2E
I - think we agree. You y´say "may not be fully E2"", which I take to
be more or less the same as "E2E if E2E is needed".

So we have a BIG and resourceful network, from which we can cut slices
in such a way that a particular slice may serve a particular network
user exactly as a purpose built network woud?

/Loa
if the origin server is hosted outside of the providers' network. 
Network slicing should allow the network provider to rapidly 
allocate/deallocate network resources towards flows, based on the 
characteristics of each flow. So each flow will demand a certain blend 
of latency, mobility, capacity, resilience, pacing, durability etc. - it 
doesn't necessarily need to be a function as such, although those can be 
added a la service chaining if required. In a cellular network this can 
also include radio resources, so 
terminal-to-external-edge-of-operator-network (maybe 'operator domain' 
is snappier :)).

--

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Wed, 8 Feb 2017 13:16:59 +0900

> user exactly as a purpose built network woud?

This is a key definition for network slicing. However, we have also to
consider two different manners to provision such slices:

- That the slice is provided "as a set of resources" (which would be
  most probably virtual) without being pre-configured. This way, the
  user is responsible of the management of such resources to form and
  control/manage its infrastructure.

- That the slice is provided as an infrastructure for a specific purpose
  requested by the user. The provider is responsible of the management
  of both the underlying and overlaying infrastructures and the user is
  limited to consume it and make any management-related request to the
  provider.

As we are trying to get a proper definition of slice and its scope, I
think we have to clarify those two alternatives or, at least, be sure
that the definition we finally push forward is not tied to just one of
them.

Regards,
Pedro

---

From: "Kiran.Makhijani" <[email-masked]>
Date: Wed, 8 Feb 2017 05:09:34 +0000

The provider is responsible of the management
  of both the underlying and overlaying infrastructures.
^^^^^^**
I like the way you explain it, but disagree with the above; the overlaying infrastructures should be managed by different set of operators who'd own those logical infrastructures. Isn't it?

Regards
Kiran
From: Pedro Martinez-Julia
To: Loa Andersson;
Cc: Smith, Kevin; [email-masked];
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement
Time: 2017-02-07 20:17:34

Regards,
Pedro

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Wed, 8 Feb 2017 14:28:58 +0900

> I like the way you explain it, but disagree with the above; the overlaying infrastructures should be managed by different set of operators who'd own those logical infrastructures. Isn't it?

Hence such operators are "the provider". However, they do not need to be
different, so:

Some role definitions:

- Infrastructure Provider (InP): Owner and manager of the underlying
  physical infrastructure (*).

- Virtual Network Operator (VNO): Gets one or more slices of resources
  from the InP and offers a network service them to users.

- User: Exploits the network service, such as connectivity (**).

Possible scenarios:

- The three roles (InP, VNO, User) are played by different entities.

- The same entity plays the InP and VNO roles, the user role is played
  by a different entity. This is one of the cases I mentioned.

- An entity plays the InP role and other entity plays the VNO and User
  roles. This is the other case I mentioned and reflects a user that
  needs (or wants) to self-manage their slices.
  
(*) On purpose of simplicity I do not mention the scenario where the
underlying infrastructure is virtual. However, this scheme can be made
recursive, so we have a single InP, multiple VNOs, and a final User.

(**) Here the "user" can be a final user or a service provider. I also
avoid delving on it to keep the example simple.

This view is quite extended but, please, give your comments so we can
refine it together. Thank you.

Regards,
Pedro

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 8 Feb 2017 06:22:56 +0000

Hi Kevin, 

> Sent: Tuesday, February 07, 2017 5:20 PM
> > I thought that "network slicing" meant that a network provider can give a
> network user, a slice of the network (with all functions needed), to satisfy the
> network users requirements. So E2E if E2E is needed.
> 
> Yes,  although that may not be fully E2E if the origin server is hosted outside of
> the providers' network. Network slicing should allow the network provider to
> rapidly allocate/deallocate network resources towards flows, based on the
> characteristics of each flow. So each flow will demand a certain blend of latency,
> mobility, capacity, resilience, pacing, durability etc. - it doesn't necessarily need to
> be a function as such, although those can be added a la service chaining if
> required. In a cellular network this can also include radio resources, so
> terminal-to-external-edge-of-operator-network (maybe 'operator domain' is
> snappier :)).

Thanks for the description about the requirements on network slicing. May I summarize it as "on demand network resource allocation to meet the characteristics required by particular service"?

And I agree that a network slice may simply provide the connectivity with required characteristics, or together with some network or service functions, this all depends on the requirements of the slice user. 

Best regards,
Jie

> I thought that "network slicing" meant that a network provider can give a
> network user, a slice of the network (with all functions needed), to satisfy the
> network users requirements.
> 
> So E2E if E2E is needed.
> 
> /Loa
> 
>

---

From: Mach Chen <[email-masked]>
Date: Wed, 8 Feb 2017 06:35:17 +0000

Hi Pedro,

I like your explanation below and the two categories of network slice. I think we are approaching to give a definition of network slice.

Best regards,
Mach

> From: Netslices [mailto:[email-masked]] On Behalf Of Pedro
> Martinez-Julia
> Sent: Wednesday, February 08, 2017 1:29 PM
> To: Kiran.Makhijani
> Cc: Smith, Kevin; [email-masked]; [email-masked]
> > I like the way you explain it, but disagree with the above; the overlaying
> infrastructures should be managed by different set of operators who'd own
> those logical infrastructures. Isn't it?
> 
> (*) On purpose of simplicity I do not mention the scenario where the underlying
> infrastructure is virtual. However, this scheme can be made recursive, so we
> have a single InP, multiple VNOs, and a final User.
> 
> (**) Here the "user" can be a final user or a service provider. I also avoid
> delving on it to keep the example simple.
> 
> This view is quite extended but, please, give your comments so we can refine it
> together. Thank you.
> 
> > Regards
> > Kiran
> 
> Regards,
> Pedro
> 
> --
> Pedro Martinez-Julia
> Network Science and Convergence Device Technology Laboratory Network
> System Research Institute National Institute of Information and
> Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo
> 184-8795, Japan
> Email: [email-masked]

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 8 Feb 2017 08:39:55 +0000

Hi Pedro, 

Thanks for the analysis of the roles and possible scenarios. IMO all the three scenarios can be possible, while in the first case the VNO may be seen as the user of the InP, so it is kind of recursion here.

According to recent discussions, maybe we could list the key properties of network slicing, such as:

1. On-demand creation and adjustment of a logical network according to the user requirements

2. Allocation of appropriate network resources to guarantee the characteristics of the network slice

3. Management and operation of the network slice can be done by either the network operator or the network slice user.

And there could be others...

Hope this helps to build the definition of network slice. 

Best regards,
Jie

> To: Kiran.Makhijani <[email-masked]>
> Cc: Smith, Kevin <[email-masked]>; [email-masked];
> [email-masked]
> This view is quite extended but, please, give your comments so we can refine
> it together. Thank you.
> 
> > Regards
> > Kiran
> 
> Regards,
> Pedro
> 
> --
> Pedro Martinez-Julia

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Wed, 8 Feb 2017 17:44:12 +0900

On Wed, Feb 08, 2017 at 08:39:55AM +0000, Dongjie (Jimmy) wrote:
> Hi Pedro, 
> 
> Thanks for the analysis of the roles and possible scenarios. IMO all
> the three scenarios can be possible, while in the first case the VNO
> may be seen as the user of the InP, so it is kind of recursion here.

Yes, it can. However, without additional levels, the functions used by
the InP and VNO are different. The former "slices" its resources while
the latter "services" the infrastructure to the users. If you add more
levels, you actually have that the middle would have a VNO interface to
their "parent" InP and an InP interface to their "child" VNO...

> 3. Management and operation of the network slice can be done by either
> the network operator or the network slice user.
> 

I agree with this line of definition, although there could be nuances to
add to each aspect. I insist to proceed with the collection of all this
information in some wiki...

Regards,
Pedro

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 8 Feb 2017 10:13:26 +0000

Pedro

Maybe we start from different positions.

My assumption is that I can create at will a new virtual function, and 
instantiate it at will and configure it at will, and create and modify 
the SFC chain at will. My further assumption is that we are building 
programmatic systems whereby the controls to do the above can be 
assessed by someone creating a service and that they can do so in a 
programming environment of their choice.

If your fundamental assumption is that NFV functionality is created on 
the basis of the current hardware catalogue, and is forever fixed, then 
we have radically different views of what NFV will be.

At the end of the day a virtual NF is a computer program running on a 
device that provides it with a network interface, CPU cycles and 
storage, an operator can spin up any program they wish on the device 
that hosts the NF.

I think that what you are saying is that softwarization a step forward 
that allow the dynamic  instantiation of general functions to create 
services, whereas I had assumed that this was always the end-game in NFV 
and SFC.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 8 Feb 2017 10:33:05 +0000

>    control/manage its infrastructure.

So what you are saying here is that one organization sells bit pipes, 
compute cycles
and storage. A second organization loads software of its choosing that 
consumes
those compute cycles and bit pipes, and this is sold to a third 
organization as
a bespoke service?

So at the lower layer this is in essence what DC providers already 
provide but with
tight SLA on the compute cycles and data paths?

Applied to the cellular market this includes a wireless component, but 
in the
general case it applies to any last mile technology.

Is that correct?

>    limited to consume it and make any management-related request to the

Doesn't this describe the normal VPN business model updated with virtual 
functions?

Regards

Stewart

---

From: Javier Antich Romaguera <[email-masked]>
Date: Wed, 8 Feb 2017 11:08:36 +0000

Hi Stewart/all,
   I admit may have got lost a bit on the subtleties of the terminology, but from my point of view it is important to emphasize that NFV is one possible mechanism/vehicle for network slicing, but there could be others. If by softwarization we are implying a more general definition, that in some cases may be represented by NFV, and in others may be a different approach, I support that view. We should emphasize on the requirements and how network slicing can address them. NFV seems to me more an example of implementation of network-slicing for certain use cases.

Thanks
Javier.

______________________________________________
Javier Antich Romaguera
Product Line Manager. JUNOS Team.
Juniper Networks
email: [email-masked]<mailto:[email-masked]>
m. +34639218428
“Achieving the difficult, trying the impossible"

From: Netslices <[email-masked]<mailto:[email-masked]>> on behalf of Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 8, 2017 at 11:13 AM
To: Pedro Martinez-Julia <[email-masked]<mailto:[email-masked]>>
Cc: "Dongjie (Jimmy)" <[email-masked]<mailto:[email-masked]>>, Network Slices <[email-masked]<mailto:[email-masked]>>, AshwoodsmithPeter <[email-masked]<mailto:[email-masked]>>, "Kiran.Makhijani" <[email-masked]<mailto:[email-masked]>>, "Natale, Bob" <[email-masked]<mailto:[email-masked]>>, Alex Galis <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Pedro

- Stewart

Taking this into account I would say that NFV is a mechanism for
softwarizing a network infrastructure (making it more flexible,
programmable, etc.) but it is only limited to the infrastructure
boundary because the functions themselves are "hard-fixed" unless
they are also softwarized.
Obviously I don't agree with that. What constrains them to be
hard-fixed?
I think that Pete's message in this thread gives a better illustration
of the meaning of such "hard-fixed" concept. In summary is that although
the infrastructure, as I mentioned above, can be programmable (flexible,
soft-ware), the individual mechanisms that compose do not usually expose
such degree of programmability. As you mentioned, a homomorphic packet
time stamper or a load balancer, for instance, usually have pre-defined
behaviours which are configurable but not programmable.

- Stewart
Regards,
Pedro

---

From: Loa Andersson <[email-masked]>
Date: Wed, 8 Feb 2017 20:09:30 +0800

Pedro,

On 2017-02-08 12:16, Pedro Martinez-Julia wrote:
>> user exactly as a purpose built network would?
>

I think I understand your comments about "two different manners", but
what I was trying to figure out was the E2E discussion and how it
relates to network slicing. From the discussion I got the impression
that E2E there were opinions that E2E were one of the characteristic of
network slizing. While I always thought that any network characteristic
has the same relationship to networks in general as they have to
network slices. I just wanted to verify this.

/Loa

--

---

From: <[email-masked]>
Date: Wed, 8 Feb 2017 14:08:59 +0000

Hi Javier, 

Re: Network Softwarization Vs. Network Slicing 

It may be useful for you to consider the context of the term "network softwarization” which was coined in the preparation of the IEEE Network Softwarization -NetSoft 2015 conference [13-17 April 2015 hosted by University College London (UCL) in London - http://sites.ieee.org/netsoft2015/ <http://sites.ieee.org/netsoft2015/>]

Network softwarization - it is an overall transformation trend for designing, implementing, deploying, managing and maintaining network equipment and/or network components by software programming, exploiting the natures of software such as flexibility and rapidity all along the lifecycle of network equipment/components, for the sake of creating conditions enabling the re-design of network and services architectures, optimizing costs and processes, enabling self-management and bringing added values in network infrastructures. 

In this context Software-Defined Networks (SDN), Network Function Virtualization (NFV), Software-Defined Clouds, Network Virtualization, Network Programmability could be seen as different expressions of network softwarization which would deeply impacting and bridging Telecom and IT industries. This trend is also transforming several other Industries, in using “softwarization” to optimize costs and processes and in bringing new values in infrastructures. In particular, SDN, NFV and network programmability are creating the conditions to reinvent network and cloud architectures, accelerate service deployment and facilitate infrastructure management.

In practice softwarization would be embedded across all layers and network components by explicitly leveraging programmability of the data, control and management planes.

On the other hand Network Slicing may be viewed as a partitioning of networking where different types of programmability enables could be activated and use. As such it would be practical to envisaged separate and isolated SDN enabled slices, NFV enabled slices, etc.

I hope that the above clarification of terms would be of help to you.

Best Regards

Alex

Professor in Networked and Service Systems
Communications and Information Systems Group
Department of Electronic and Electrical Engineering  
University College London
Torrington Place, London WC1E 7JE
United Kingdom

Skype: AlexGalis
Phone +44-20-3108 9441
Mobile +44-7768 493 095
Fax +44-20-7916 0388 /+44-20-7388 9325
E-mail: [email-masked]
Personal Web Page: www.ee.ucl.ac.uk/~agalis

Disclaimer:

The information in this email and in any files transmitted with it is intended only for the addressee and may contain confidential and/or privileged material. Access to this email by anyone else is unauthorized. If you receive this in error, please contact the sender immediately and delete the material from any computer. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is strictly prohibited. Statement and opinions expressed in this e-mail are those of the sender, and do not necessarily reflect those of University College London.

Examples
> On 8 Feb 2017, at 11:08, Javier Antich Romaguera <[email-masked]> wrote:
> 
> Hi Stewart/all, 
> email: [email-masked] <mailto:[email-masked]>
> m. +34639218428
> From: Netslices <[email-masked] <mailto:[email-masked]>> on behalf of Stewart Bryant <[email-masked] <mailto:[email-masked]>>
> To: Pedro Martinez-Julia <[email-masked] <mailto:[email-masked]>>
> Cc: "Dongjie (Jimmy)" <[email-masked] <mailto:[email-masked]>>, Network Slices <[email-masked] <mailto:[email-masked]>>, AshwoodsmithPeter <[email-masked] <mailto:[email-masked]>>, "Kiran.Makhijani" <[email-masked] <mailto:[email-masked]>>, "Natale, Bob" <[email-masked] <mailto:[email-masked]>>, Alex Galis <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 8 Feb 2017 14:28:30 -0000

> It may be useful for you to consider the context of the term
> "network softwarization” which was coined in the preparation
> of the IEEE Network Softwarization -NetSoft 2015 conference 
> [13-17 April 2015 hosted by University College London (UCL) in
> London - http://sites.ieee.org/netsoft2015/]

Alex, don't run yourself down, mate.
You were using the term way back in 2013.
http://www.iaria.org/conferences2013/filesICDT13/NexCOMM-KeyNote_AGalis_v5.pdf

(Doesn't mean I like the term, but it has a long and proud history.)

Adrian

---

From: Andrew McLachlan <[email-masked]>
Date: Wed, 8 Feb 2017 14:40:24 +0000

Networks have always been software driven and also been programable via multiple methods, CLI, SNMP (occasionally), and the myriad of orchestration tools, some open and some not.

Networks themselves are not being re-invented, we are literally going full circle back to using an NMS approach to manage blocks of elements..but today we now call them ‘controllers'.

We are already seeing the impact of moving features from hardware into software now being returned to hardware in order to achieve the performance that is required and to meet the low power consumption requirements.

Yes some services can and should move to a virtual environment, to achieve better scale and faster deployment, but when we start to look at the requirements for latency, path failover and other features needing extremely tight restoration… we quickly move back to needing hardware based feature sets to achieve this.

I think we need to ditch this term softwareization, as it is extremely misleading. 

Also SDN is really about software driven networks, not defined networking. Networking, services, infrastructure are not defined by software, they are operated by software, via programable interfaces (if available) and or by a controller/NMS layer.

As for Network Slicing, this has been done for years. It might be new in a 5G world, but should not be confused with being something actually new.

The question for this group in the IETF should surely be.. do we need any new protocols or enhancements in this area, bearing in might that most of the ‘glue’ for E2E will be done at the high orchestration layer.

> On 8 Feb 2017, at 14:08, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Javier, 
> 
> E-mail: [email-masked] <mailto:[email-masked]>
> Personal Web Page: www.ee.ucl.ac.uk/~agalis <http://www.ee.ucl.ac.uk/~agalis>
> 
> Disclaimer:
> 
>> On 8 Feb 2017, at 11:08, Javier Antich Romaguera <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Stewart/all,

---

From: Anton Ivanov <[email-masked]>
Date: Wed, 8 Feb 2017 14:46:42 +0000

On 08/02/17 14:40, Andrew McLachlan wrote:
>
>
> Networks have always been software driven and also been programable 
> via multiple methods, CLI, SNMP (occasionally), and the myriad of 
> orchestration tools, some open and some not.
>
> Networks themselves are not being re-invented, we are literally going 
> full circle back to using an NMS approach to manage blocks of 
> elements..but today we now call them ‘controllers'.
>
> We are already seeing the impact of moving features from hardware into 
> software now being returned to hardware in order to achieve the 
> performance that is required and to meet the low power consumption 
> requirements.
>
> Yes some services can and should move to a virtual environment, to 
> achieve better scale and faster deployment, but when we start to look 
> at the requirements for latency, path failover and other features 
> needing extremely tight restoration… we quickly move back to needing 
> hardware based feature sets to achieve this.
>
> Also SDN is really about software driven networks, not defined 
> networking. Networking, services, infrastructure are not defined by 
> software, they are operated by software, via programable interfaces 
> (if available) and or by a controller/NMS layer.
>
> As for Network Slicing, this has been done for years. It might be new 
> in a 5G world, but should not be confused with being something 
> actually new.
>
> The question for this group in the IETF should surely be.. do we need 
> any new protocols or enhancements in this area, bearing in might that 
> most of the ‘glue’ for E2E will be done at the high orchestration layer.

No.

A.

>
>
>
>> On 8 Feb 2017, at 14:08, <[email-masked] 
>> <mailto:[email-masked]>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Javier,
>>
>> It may be useful for you to consider the context of the term "network 
>> softwarization” which was coined in the preparation of the IEEE 
>> Network Softwarization -NetSoft 2015 conference [13-17 April 2015 
>> hosted by University College London (UCL) in London - 
>> http://sites.ieee.org/netsoft2015/]
>>
>> Network softwarization - it is an overall transformation trend for 
>> designing, implementing, deploying, managing and maintaining network 
>> equipment and/or network components by software programming, 
>> exploiting the natures of software such as flexibility and rapidity 
>> all along the lifecycle of network equipment/components, for the sake 
>> of creating conditions enabling the re-design of network and services 
>> architectures, optimizing costs and processes, enabling 
>> self-management and bringing added values in network infrastructures.
>>
>> In this context Software-Defined Networks (SDN), Network Function 
>> Virtualization (NFV), Software-Defined Clouds, Network 
>> Virtualization, Network Programmability could be seen as different 
>> expressions of network softwarization which would deeply impacting 
>> and bridging Telecom and IT industries. This trend is also 
>> transforming several other Industries, in using “softwarization” to 
>> optimize costs and processes and in bringing new values in 
>> infrastructures. In particular, SDN, NFV and network programmability 
>> are creating the conditions to reinvent network and cloud 
>> architectures, accelerate service deployment and facilitate 
>> infrastructure management.
>>
>> In practice softwarization would be embedded across all layers and 
>> network components by explicitly leveraging programmability of the 
>> data, control and management planes.
>>
>> On the other hand Network Slicing may be viewed as a partitioning of 
>> networking where different types of programmability enables could be 
>> activated and use. As such it would be practical to envisaged 
>> separate and isolated SDN enabled slices, NFV enabled slices, etc.
>>
>> <http://www.ee.ucl.ac.uk/%7Eagalis>
>>
>> Disclaimer:
>>
>> The information in this email and in any files transmitted with it is 
>> intended only for the addressee and may contain confidential and/or 
>> privileged material. Access to this email by anyone else is 
>> unauthorized. If you receive this in error, please contact the sender 
>> immediately and delete the material from any computer. If you are not 
>> the intended recipient, any disclosure, copying, distribution or any 
>> action taken or omitted to be taken in reliance on it, is strictly 
>> prohibited. Statement and opinions expressed in this e-mail are those 
>> of the sender, and do not necessarily reflect those of University 
>> College London.
>>
>>
>>
>>
>> Examples
>>> On 8 Feb 2017, at 11:08, Javier Antich Romaguera 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>> Hi Stewart/all,
>>>    I admit may have got lost a bit on the subtleties of the 
>>> terminology, but from my point of view it is important to emphasize 
>>> that NFV is one possible mechanism/vehicle for network slicing, but 
>>> there could be others. If by softwarization we are implying a more 
>>> general definition, that in some cases may be represented by NFV, 
>>> and in others may be a different approach, I support that view. We 
>>> should emphasize on the requirements and how network slicing can 
>>> address them. NFV seems to me more an example of implementation of 
>>> network-slicing for certain use cases.
>>>
>>> Thanks
>>> Javier.
>>> From: Netslices <[email-masked] 
>>> <mailto:[email-masked]>> on behalf of Stewart Bryant 
>>> <[email-masked] <mailto:[email-masked]>>
>>> Cc: "Dongjie (Jimmy)" <[email-masked] 
>>> <mailto:[email-masked]>>, Network Slices <[email-masked] 
>>> <mailto:[email-masked]>>, AshwoodsmithPeter 
>>> <[email-masked] 
>>> <mailto:[email-masked]>>, "Kiran.Makhijani" 
>>> <[email-masked] <mailto:[email-masked]>>, 
>>> "Natale, Bob" <[email-masked] <mailto:[email-masked]>>, Alex 
>>> Galis <[email-masked] <mailto:[email-masked]>>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 8 Feb 2017 15:27:53 +0000

I agree with the points that Andrew makes, and I understand the 
sentiment in Anton's statement, but am open minded, particularly when it 
comes to the lower layers. 5G is driving NS and 5G is placing stricter 
requirements on the lower layers which need to be supported, quite 
possibly in hardware.

>> orchestration tools, some open and some not.
We do indeed seem to be going round a very large circle and I don't 
think any of us know where it will pause its rotation. The original 
forwarders were s/w on dedicated h/w, then they were s/w on general 
purpose computers, then they went round a tight circle between 
micro-code and full h/w, now they are drifting back to s/w on 
multi-purpose computers, who knows where this will settle and how the 
network context will drive it.

>> We are already seeing the impact of moving features from hardware 
>> into software now being returned to hardware in order to achieve the 

In a recent seminar, Giles used the term model driven networks, and I 
think that fits better. Of course the models are driven from both sides 
of the interface by software, how else would you do it?

>> most of the ‘glue’ for E2E will be done at the high orchestration layer.

I am more open minded. We need to be careful not to make gratuitous 
changes, but I am none the less unconvinced that what we currently have 
is perfect.

- Stewart

>>> "network softwarization” which was coined in the preparation of the 
>>> IEEE Network Softwarization -NetSoft 2015 conference [13-17 April 
>>> 2015 hosted by University College London (UCL) in London - 
>>> all along the lifecycle of network equipment/components, for the 
>>> sake of creating conditions enabling the re-design of network and 
>>> services architectures, optimizing costs and processes, enabling 
>>> The information in this email and in any files transmitted with it 
>>> is intended only for the addressee and may contain confidential 
>>> and/or privileged material. Access to this email by anyone else is 
>>> unauthorized. If you receive this in error, please contact the 
>>> sender immediately and delete the material from any computer. If you 
>>> are not the intended recipient, any disclosure, copying, 
>>> distribution or any action taken or omitted to be taken in reliance 
>>> on it, is strictly prohibited. Statement and opinions expressed in 
>>> this e-mail are those of the sender, and do not necessarily reflect 
>>> those of University College London.
>>>
>>>
>>>
>>>
>>> Examples

---

From: Anton Ivanov <[email-masked]>
Date: Wed, 8 Feb 2017 15:38:10 +0000

[snip]

>
>>>
>>> As for Network Slicing, this has been done for years. It might be 
>>> new in a 5G world, but should not be confused with being something 
>>> actually new.
>>>
>>> The question for this group in the IETF should surely be.. do we 
>>> need any new protocols or enhancements in this area, bearing in 
>>> might that most of the ‘glue’ for E2E will be done at the high 
>>> orchestration layer.
>>
>> No.
>>
>> A.
>>
>
> changes, but I am none the less unconvinced that what we currently 
> have is perfect.

IMHO what we have across the various WGs suffices for the needs of 
mobile, it is more of a question of settling down on a small subset of 
available candidates which have already been defined, standardized and 
proven in the field. We also need need to make sure that the chosen 
candidate(s) will not become obsolete by the time they are standardized 
in the other mobile organizations.

3GPP has a superb form in choosing archaeological specimens for 
standardization. Frame Relay for GPRS, ATM for 3G, etc.

There is no need to reinvent the wheel unless there is a specific use 
case and a test case which proves that this is needed.

A.

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 8 Feb 2017 10:51:52 -0500

> On Feb 8, 2017:10:27 AM, at 10:27 AM, Stewart Bryant <[email-masked]> wrote:
> 
> I agree with the points that Andrew makes, and I understand the sentiment in Anton's statement, but am open minded, particularly when it comes to the lower layers. 5G is driving NS and 5G is placing stricter requirements on the lower layers which need to be supported, quite possibly in hardware.
> 
> We do indeed seem to be going round a very large circle and I don't think any of us know where it will pause its rotation. The original forwarders were s/w on dedicated h/w, then they were s/w on general purpose computers, then they went round a tight circle between micro-code and full h/w, now they are drifting back to s/w on multi-purpose computers, who knows where this will settle and how the network context will drive it.
> 
> In a recent seminar, Giles used the term model driven networks, and I think that fits better. Of course the models are driven from both sides of the interface by software, how else would you do it?
> 
>>> 
> I am more open minded. We need to be careful not to make gratuitous changes, but I am none the less unconvinced that what we currently have is perfect.
> 
> - Stewart

	I don’t believe anyone is saying what we have is perfect by any means; what you should ask is: is it good enough to achieve the goals and requirements of network operators?

	—Tom

> 
>>>  
>>> 
>>> 
>>> 
>>>> On 8 Feb 2017, at 14:08, <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> Hi Javier, 
>>>> 
>>>> Personal Web Page: www.ee.ucl.ac.uk/~agalis <http://www.ee.ucl.ac.uk/%7Eagalis>
>>>> 
>>>> Disclaimer:
>>>>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 8 Feb 2017 15:59:13 +0000

On 08/02/2017 15:51, Thomas Nadeau wrote:
> I don’t believe anyone is saying what we have is perfect by any means; 
> what you should ask is: is it good enough to achieve the goals and 
> requirements of network operators?
>
> —Tom

Agreed, and assuming the delay jitter and isolation requirements hold 
up, I think these need new work.

People  with experience on controller systems and models are better 
placed to consider whether this is a good enough fit for the 
requirements that have been expressed by the mobile operators.

- Stewart

---

From: Anton Ivanov <[email-masked]>
Date: Wed, 8 Feb 2017 16:21:16 +0000

On 08/02/17 15:59, Stewart Bryant wrote:
>> I don’t believe anyone is saying what we have is perfect by any 
>> means; what you should ask is: is it good enough to achieve the goals 
>> and requirements of network operators?
>>
>> —Tom
>

My exact point - as someone who works on various software aspects 
related to this. I would like to see a negative test case proving that 
what is currently available is insufficient.

More importantly, I would like to see quantifiable negative test case - 
the stuff which we presently have on offer is off by X us (or ms), Y 
Gbit, Z size of address space of  particular type, etc.

We can generate the requirements based on the difference (if such 
difference can be demonstrated) and work on the gap from that point onwards.

If there is no negative test case showing a clear quantifiable 
deficiency in the standards and architectures presently available across 
the IETF and the other standard bodies, then..., well..., we are back to 
my original answer: "No".

A.

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Thu, 9 Feb 2017 08:51:34 +0900

On Wed, Feb 08, 2017 at 10:33:05AM +0000, Stewart Bryant wrote:
> > > So we have a BIG and resourceful network, from which we can cut
> > > slices in such a way that a particular slice may serve a
> > > particular network user exactly as a purpose built network woud?
> > This is a key definition for network slicing. However, we have also
> > to consider two different manners to provision such slices:
> > 
> compute cycles and storage. A second organization loads software of
> its choosing that consumes those compute cycles and bit pipes, and
> this is sold to a third organization as a bespoke service?
> 
> provide but with tight SLA on the compute cycles and data paths?
> 
> in the general case it applies to any last mile technology.
> 
> Is that correct?

It is. However, the objective of my position is to push the flexible and
even genericity into the definition of "slice", surrounded by the needed
functions to implement such aspects when delivering slices.

> > - That the slice is provided as an infrastructure for a specific
> > purpose requested by the user. The provider is responsible of the
> > management of both the underlying and overlaying infrastructures and
> > the user is limited to consume it and make any management-related
> > request to the provider.
> 
> Doesn't this describe the normal VPN business model updated with
> virtual functions?

If you limit the infrastructure to connectivity, yes. But, as I mention
above, this manner only shows the flexibility of slices. Thus, a VPN can
be seen as "a slice consisting on connectivity with some properties" but
it does NOT mean that "a slice is a VPN" :-D.

Regards,
Pedro

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Thu, 9 Feb 2017 08:56:20 +0900

Dear Stewart,

> the basis of the current hardware catalogue, and is forever fixed,
> then we have radically different views of what NFV will be.
> 
> services, whereas I had assumed that this was always the end-game in
> NFV and SFC.

In summary you are true, we started from different positions. Although I
understand you view of NFV/SFC in the long term, the reality is that you
cannot match it with softwarization. As it has been mentioned before and
in other threads, NFV is a particularization of softwarization, but as I
also mentioned, that depends on the scope and level of programmability
that the VNF you are instantiating provides. Nevertheless, as it ensures
flexibility, we can assume that it can be true for all layers of NFV,
regardless of that the VNF is fixed (e.g. simple L2 learning switch) or
more dynamic (e.g. OpenFlow switch).

Regards,
Pedro

---

From: "Kiran.Makhijani" <[email-masked]>
Date: Thu, 9 Feb 2017 00:55:37 +0000

My exact point - as someone who works on various software aspects related to this. I would like to see a negative test case proving that what is currently available is insufficient.
^^^^^^^
Hi Anton,
It is also important to consider efficiency of current solutions. The degree of customization anticipated for 5g and slicing will be much higher. NS should be looked at as a lean network infrastructure from top-down and e2e in terms of minimizing overheads all across (in configs, protocols, mgmt., OSS…) and strictly isolating partitioned-resources from each other.

Regards
Kiran

From: Netslices <[email-masked]> on behalf of Anton Ivanov <[email-masked]>
Date: Wednesday, February 8, 2017 at 8:21 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

—Tom

Agreed, and assuming the delay jitter and isolation requirements hold up, I think these need new work.

People  with experience on controller systems and models are better placed to consider whether this is a good enough fit for the requirements that have been expressed by the mobile operators.

My exact point - as someone who works on various software aspects related to this. I would like to see a negative test case proving that what is currently available is insufficient.

More importantly, I would like to see quantifiable negative test case - the stuff which we presently have on offer is off by X us (or ms), Y Gbit, Z size of address space of  particular type, etc.

We can generate the requirements based on the difference (if such difference can be demonstrated) and work on the gap from that point onwards.

If there is no negative test case showing a clear quantifiable deficiency in the standards and architectures presently available across the IETF and the other standard bodies, then..., well..., we are back to my original answer: "No".

A.

- Stewart

Netslices mailing list

---

From: Anton Ivanov <[email-masked]>
Date: Thu, 9 Feb 2017 06:56:11 +0000

On Thu, 9 Feb 2017 00:55:37 +0000
"Kiran.Makhijani" <[email-masked]> wrote:

> related to this. I would like to see a negative test case proving
> that what is currently available is insufficient. ^^^^^^^ Hi Anton,
> It is also important to consider efficiency of current solutions. The
> degree of customization anticipated for 5g and slicing will be much
> higher. NS should be looked at as a lean network infrastructure from
> top-down and e2e in terms of minimizing overheads all across (in
> configs, protocols, mgmt., OSS…) and strictly isolating
> partitioned-resources from each other.

Apologies, I am an engineer and as most engineers I am not particularly
good at parsing Markitechture-speak mumbo-jumbo like lean top-down e2e. 

Can you please express in clear engineering terms suitable for an IETF
WG mailing list what is exactly wrong with the current spectrum of
solutions. 

By the way "Anticipation" != "Requirement". What is the REQUIREMENT
which we are failing to address in l2vpn, l3vpn, etc. 

As I said in my original email - Numbers of microseconds, Gigabits,
sizes of address spaces, sizes of config spaces, model defficiencies,
etc.

At least ONE example where we are failing to address a defined
requirement and "citation needed" for that requirement please.

A.

> 
> Regards
> Kiran
> 
> From: Netslices <[email-masked]> on behalf of Anton
> Ivanov <[email-masked]> Date: Wednesday, February 8,
> 2017 at 8:21 AM To: "[email-masked]" <[email-masked]>
> related to this. I would like to see a negative test case proving
> that what is currently available is insufficient.
> 
> More importantly, I would like to see quantifiable negative test case
> - the stuff which we presently have on offer is off by X us (or ms),
> Y Gbit, Z size of address space of  particular type, etc.
> 
> deficiency in the standards and architectures presently available
> across the IETF and the other standard bodies, then..., well..., we
> are back to my original answer: "No".
> 
> A.
> 
> 
> 
> - Stewart
> 
> 
> 
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 13 Feb 2017 08:42:33 +0000

Hi Anton,

Yes, the use cases which cannot be fully met with existing solutions are exactly what we would like to discuss on this mailing list. As you said, quantifiable use cases would be quite useful, while since it is just the beginning of the network slicing discussion in IETF,  qualitative use cases would also be helpful. I'd like to encourage people who has specific use cases to briefly introduce them to the list, so that we could have further discussion based on that.

One use case discussed on the side meeting is the banking service which has strict requirements on low latency and security, currently it is still using a dedicated network which is not economical. If we aim to migrate such kind of service onto the common network infrastructure in 5G, the latency, isolation and security must be guaranteed. And in 5G more critical service such as industrial control, remote surgery, automated-driving, etc. are emerging, they would need guaranteed network performance and different levels of isolation if the infrastructure is shared with other services.

Best regards,
Jie

From: Netslices [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: Thursday, February 09, 2017 12:21 AM
To: [email-masked]
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

On 08/02/2017 15:51, Thomas Nadeau wrote:
  I don't believe anyone is saying what we have is perfect by any means; what you should ask is: is it good enough to achieve the goals and requirements of network operators?

  -Tom

A.

- Stewart

Netslices mailing list

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 13 Feb 2017 12:04:41 -0500

Perhaps you could write up a short draft explaining the details of that use case? On the surface, I can see how existing 
tech can work but you may have some requirements that I am missing from your high level description.

	—Tom

> On Feb 13, 2017:3:42 AM, at 3:42 AM, Dongjie (Jimmy) <[email-masked]> wrote:
> 
> Hi Anton,
>  
> Yes, the use cases which cannot be fully met with existing solutions are exactly what we would like to discuss on this mailing list. As you said, quantifiable use cases would be quite useful, while since it is just the beginning of the network slicing discussion in IETF,  qualitative use cases would also be helpful. I’d like to encourage people who has specific use cases to briefly introduce them to the list, so that we could have further discussion based on that.
>  
> From: Netslices [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Anton Ivanov
> To: [email-masked] <mailto:[email-masked]>

---

From: Andrew McLachlan <[email-masked]>
Date: Mon, 13 Feb 2017 18:28:28 +0000

Hi Jie

I agree that there are emerging scenarios in the mobile networking space along the lines of what you have described. However do they generate requirements which necessitate new standards/functions or enhancements to existing solutions?

So far the described use cases do seem to be covered by existing methods, they have just so far not been so far widely used in the mobile space.

Agree with Tom, adding that the use cases need to go beyond the conceptual problem and into specific missing functions, since we already have multiple methods for separation and at multiple layers using for ‘slicing’ up infrastructures, both physical and virtual.

In addition as I have stated previously in this thread, the problem space imo, lies mostly above the network/protocol layer and more in the orchestration domain.

Andrew

> On 13 Feb 2017, at 17:04, Thomas Nadeau <[email-masked]> wrote:
> 
> 
>> On Feb 13, 2017:3:42 AM, at 3:42 AM, Dongjie (Jimmy) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Anton,
>>

---

From: Anton Ivanov <[email-masked]>
Date: Mon, 13 Feb 2017 19:41:11 +0000

+1

While there are trading scenarios which demand dedicated networks most 
of them have been put in place to achieve very specific use cases. None 
of these has any intention to share as far as I know as they are part of 
what gives the company the special advantage.

I would definitely like to see this written up so we can see how we can 
work towards a SHARING solution - something we can drive towards a 
standard within the concepts being discussed here.

So I concur with Tom, I would like to see this use case written out so 
it can be analyzed in context.

As far as the other ones - surgery, etc - the ones that have known 
working prototypes with known actual parameters can be dealt with using 
existing solutions. I would be interested to see some numbers proving a 
specific use case that they cannot. Similar - a draft describing a use 
case would be needed as a part of forming the requirements.

A.

On 13/02/17 17:04, Thomas Nadeau wrote:
>
> Perhaps you could write up a short draft explaining the details of 
> that use case? On the surface, I can see how existing
>> On Feb 13, 2017:3:42 AM, at 3:42 AM, Dongjie (Jimmy) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Anton,
>> Yes, the use cases which cannot be fully met with existing solutions 
>> are exactly what we would like to discuss on this mailing list. As 
>> you said, quantifiable use cases would be quite useful, while since 
>> it is just the beginning of the network slicing discussion in IETF, 
>>  qualitative use cases would also be helpful. I’d like to encourage 
>> people who has specific use cases to briefly introduce them to the 
>> list, so that we could have further discussion based on that.
>> One use case discussed on the side meeting is the banking service 
>> which has strict requirements on low latency and security, currently 
>> it is still using a dedicated network which is not economical. If we 
>> aim to migrate such kind of service onto the common network 
>> infrastructure in 5G, the latency, isolation and security must be 
>> guaranteed. And in 5G more critical service such as industrial 
>> control, remote surgery, automated-driving, etc. are emerging, they 
>> would need guaranteed network performance and different levels of 
>> isolation if the infrastructure is shared with other services.
>> Best regards,
>> Jie
>> *From:*Netslices [mailto:[email-masked]]*On Behalf 
>> Of*Anton Ivanov
>> *Sent:*Thursday, February 09, 2017 12:21 AM
>> *To:[email-masked] <mailto:[email-masked]>
>> *Subject:*Re: [Netslices] Network Slicing - Introductory Document and 
>> Revised Problem Statement
>>         I don’t believe anyone is saying what we have is perfect by
>>         any means; what you should ask is: is it good enough to
>>         achieve the goals and requirements of network operators?
>>         —Tom
>>
>>
>>     People  with experience on controller systems and models are
>>     better placed to consider whether this is a good enough fit for
>>     the requirements that have been expressed by the mobile operators.
>>
>>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 17 Feb 2017 09:48:04 +0000

Hi Tom,

Sorry for the late reply.

Yes we plan to write up a draft to describe the use cases which triggers the requirement of 5G network slicing. Input and involvement from network operators and the potential users of network slices would be much appreciated.

Best regards,
Jie

From: Thomas Nadeau [mailto:[email-masked]]
Sent: Tuesday, February 14, 2017 1:05 AM
To: Dongjie (Jimmy) <[email-masked]>
Cc: Anton Ivanov <[email-masked]>; [email-masked]
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

   —Tom

On Feb 13, 2017:3:42 AM, at 3:42 AM, Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Anton,

Best regards,
Jie

From: Netslices [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: Thursday, February 09, 2017 12:21 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

  —Tom

A.

- Stewart

Netslices mailing list

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 17 Feb 2017 09:59:50 +0000

Hi Andrew,

Thanks a lot for your comments.

Yes new services are emerging in 5G, whether they have new requirement on the network or they can just be met with existing solutions deserves further analysis and discussion.

As for the use cases, I would like to encourage people on this mailing list to speak up about the use case they considered in 5G, and we can see what are the missing functions or capabilities for specific use case.

I agree with you that the orchestration domain is important  to network slicing, and we need to figure out which part in this domain should be discussed and developed in IETF. Could you help with this?

Best regards,
Jie

From: Andrew McLachlan [mailto:[email-masked]]
Sent: Tuesday, February 14, 2017 2:28 AM
To: Thomas Nadeau <[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]>; Anton Ivanov <[email-masked]>; [email-masked]
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Hi Jie

Andrew

On 13 Feb 2017, at 17:04, Thomas Nadeau <[email-masked]<mailto:[email-masked]>> wrote:

—Tom

Hi Anton,

Best regards,
Jie

  —Tom

A.

- Stewart

Netslices mailing list

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 17 Feb 2017 10:12:12 +0000

Hi Anton,

Thanks a lot for your feedbacks.

I may misunderstood your here, do you mean the trading scenarios which currently require dedicated network will not be covered with a common network infrastructure in future? But 5G aims to cover various vertical industries which currently may use dedicated networks. It may be beneficial to both the network operators and the vertical industry users if such stringent service requirements can be met using a shared infrastructure.

We plan to write up a use case draft recently and it would be great to get input from you and people on this mailing list.

Best regards,
Jie

From: Anton Ivanov [mailto:[email-masked]]
Sent: Tuesday, February 14, 2017 3:41 AM
To: Thomas Nadeau <[email-masked]>; Dongjie (Jimmy) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

+1

While there are trading scenarios which demand dedicated networks most of them have been put in place to achieve very specific use cases. None of these has any intention to share as far as I know as they are part of what gives the company the special advantage.

I would definitely like to see this written up so we can see how we can work towards a SHARING solution - something we can drive towards a standard within the concepts being discussed here.

So I concur with Tom, I would like to see this use case written out so it can be analyzed in context.

As far as the other ones - surgery, etc - the ones that have known working prototypes with known actual parameters can be dealt with using existing solutions. I would be interested to see some numbers proving a specific use case that they cannot. Similar - a draft describing a use case would be needed as a part of forming the requirements.

A.

—Tom

Hi Anton,

Best regards,
Jie

  —Tom

A.

- Stewart

Netslices mailing list

---

From: Anton Ivanov <[email-masked]>
Date: Fri, 17 Feb 2017 19:49:12 +0100

You have the wrong vertical example. If you cater for what dedicated is used today, the trading engineering will move the goalposts.

Industries with active technological arms races do not make good standardisation material. You have to be past the arms race stage and into the common ground stage.

On 17 February 2017 11:12:12 CET, "Dongjie (Jimmy)" <[email-masked]> wrote:
>I may misunderstood your here, do you mean the trading scenarios which
>currently require dedicated network will not be covered with a common
>network infrastructure in future? But 5G aims to cover various vertical
>industries which currently may use dedicated networks. It may be
>beneficial to both the network operators and the vertical industry
>users if such stringent service requirements can be met using a shared
>infrastructure.
>
>We plan to write up a use case draft recently and it would be great to
>get input from you and people on this mailing list.
>
>Best regards,
>Jie
>
>of these has any intention to share as far as I know as they are part
>of what gives the company the special advantage.
>
>Perhaps you could write up a short draft explaining the details of that
>use case? On the surface, I can see how existing
><[email-masked]<mailto:[email-masked]>> wrote:
>
>Hi Anton,
>
>are exactly what we would like to discuss on this mailing list. As you
>said, quantifiable use cases would be quite useful, while since it is
>just the beginning of the network slicing discussion in IETF, 
>One use case discussed on the side meeting is the banking service which
>has strict requirements on low latency and security, currently it is
>still using a dedicated network which is not economical. If we aim to
>migrate such kind of service onto the common network infrastructure in
>5G, the latency, isolation and security must be guaranteed. And in 5G
>more critical service such as industrial control, remote surgery,
>automated-driving, etc. are emerging, they would need guaranteed
>network performance and different levels of isolation if the
>infrastructure is shared with other services.
>
>Best regards,
>Jie
>
>across the IETF and the other standard bodies, then..., well..., we are
>back to my original answer: "No".
>
>A.
>
>
>
>
>- Stewart
>
>
>
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.