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

From: Alex Galis <[email-masked]>
Date: Tue, 14 Feb 2017 20:45:01 +0000

14th February 2017

Dear All,

Re: "Network Slicing - Introductory Document and Revised Problem Statement" draft 02

Thank you for your contributions, reviews  and discussions on the  "Network Slicing - Introductory Document and Revised Problem Statement” draft 00.

An update as draft 02 was produced and submitted to the IETF repository.

This is a king request for you to consider this draft as input to :

• further discussions on the mailing list.
• further updates and clarifications with the view of update it before the IETF98 In Chicago (26-31 March 2017).
• starting new drafts before IETF98 In Chicago on the following topics: 
		I) relevant use cases ; 
		II) reference model for network slices ; 
		III) Exposure Interface specification and Data model for Network Slicing ; 
		iV) detailed problem statements (i.e. based on already identified list of 20 problems)

We are planning for a side meeting on Network Slicing at IETF 98.

Best Regards

Alex, Jimmy, Kiran, Stewart, Mod, Petro

N.B. A new version of I-D, draft-gdmb-netslices-intro-and-ps-02.txt
has been successfully submitted by Alex Galis and posted to the
IETF repository.

Name:		draft-gdmb-netslices-intro-and-ps
Revision:	02
Title:		Network Slicing - Introductory Document and Revised Problem Statement
Document date:	2017-02-14
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-02.txt
Status:         https://datatracker.ietf.org/doc/draft-gdmb-netslices-intro-and-ps/
Htmlized:       https://tools.ietf.org/html/draft-gdmb-netslices-intro-and-ps-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-gdmb-netslices-intro-and-ps-02

Abstract:
  This document introduces Network Slicing problems and the motivation
  for new work areas. It represents an initial revision of the Network
  Slicing problem statement derived from the analysis of the technical
  gaps in IETF protocols ecosystem.  It complements and brings together
  the silo efforts being carried out in several other IETF working groups
  to achieve certain aspects of Network Slicing functions and operations.

---

From: Anton Ivanov <[email-masked]>
Date: Mon, 20 Feb 2017 15:03:50 +0000

Questions:

1. What do you mean under "four-dimensional"?

2. Operations - most of that sounds like defining a FSM and a matching 
model. Thus - the model for slices should not sit as a small sub-point 
of the last bullet point. It is where you start (along with the FSM).

3. Notes - half of that goes away once you define the FSM - they are 
just transitions along the FSM and relevant model changes.

As a side effect of 2+3 once that is defined it becomes a simple manner 
of coding said FSM and orchestrating how it effects network and cloud 
resources unless we get bogged down in the end-to-end QoS swamp. That 
particular swamp probably needs some narrowing down in order to have a 
viable problem statement. Doing it to cover all possible arbitrary ideas 
of end-to-end QoS is just not feasible. That has been tried quite a few 
times and has been unsuccessful every time. So a narrowed down 
definition of supported end-to-end qos metrics and a matching model is 
needed as a part of defining the problem statement.

A.

On 14/02/17 20:45, Alex Galis wrote:
> _______________________________________________
> Netslices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netslices

---

From: "Kiran.Makhijani" <[email-masked]>
Date: Tue, 21 Feb 2017 06:57:11 +0000

Anton,
Thanks for looking at the document.
Please see inline

Regards
Kiran 

On 2/20/17, 7:03 AM, "Netslices on behalf of Anton Ivanov" <[email-masked] on behalf of [email-masked]> wrote:

    Questions:
    
    1. What do you mean under "four-dimensional"?
    [KM] these are (a) Data /(b) Control /(c) Management /(d) Service planes. The expectation is to have an independent view of NS from each of these perspectives. 

    2. Operations - most of that sounds like defining a FSM and a matching 
    model. Thus - the model for slices should not sit as a small sub-point 
    of the last bullet point. It is where you start (along with the FSM).
 [KM] can you elaborate a bit more what kind of FSM and what’s a ‘matching model’? Here Slice operations may have different goals, (a) some being operator driven slice create/delete/modify; (b) others being about runtime adjustments of capabilities, (c) aspects like intelligence in self-monitoring actions and so on. I am not able to relate these to FSM but if possible, this may be an interesting approach to explore further. 

[KM] That said, introductory document aims to ‘what’ not ‘how’. 

    
[KM] not sure with qos metrics part either because each service vertical will have specific requirement; we don’t want to be in a kludgy situation where an application cannot be served in the context of a slice. Since I am still not clear about matching model, could you please suggest the text - that will be helpful.
Thanks 
Kiran

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 21 Feb 2017 08:00:31 +0000

>      [KM] these are (a) Data /(b) Control /(c) Management /(d) Service planes. The expectation is to have an independent view of NS from each of these perspectives.

Needs a definition. Otherwise it reads as a Star Trek fan fiction script 
not a draft.

>   [KM] can you elaborate a bit more what kind of FSM and what’s a ‘matching model’? Here Slice operations may have different goals, (a) some being operator driven slice create/delete/modify; (b) ot…

You are defining a standard which needs to be coded.

I read the wishlist in the draft - it needs to be narrowed to a set of 
defined states, formed into an orderly FSM and expressed as data. 
Otherwise it is not standards material.

This does not need to be done in the problem statement, the problem 
statement should however narrow the scope to make sure that this is the 
required end-product.

> [KM] That said, introductory document aims to ‘what’ not ‘how’.

See above.

> [KM] not sure with qos metrics part either because each service vertical will have specific requirement; we don’t want to be in a kludgy situation where an application cannot be served in the context of a slice.

You will always have at least one corner case like that. You cannot have 
a Santa wishlist where this does everything. It should be clear WHAT it 
it is intended to do and that WHAT should be expressible as numbers so 
that implementers can express it as code.

A.

>   Since I am still not clear about matching model, could you please suggest the text - that will be helpful.
> Thanks
> Kiran
>
>      
>

---

From: Andrew McLachlan <[email-masked]>
Date: Tue, 21 Feb 2017 16:57:20 +0000

Hi Alex

I think we are creating confusion by talking about 'slice control planes', as this seems to imply something akin to the normal meaning of control plane, as related to IETF work.

I believe what we are really looking at here is the something more like ‘ multi infrastructure tenant orchestration’. By way of example what we do today already with services over and / or connected to networks such as SFC connected to a VPN.

Resources in any part of the chain for an E2E service will need to be booked/allocated/managed by an overlord, with the control plane functions essentially performing the same functions as today. For examples attachments using vxlan, vNICs, VMs and all things beginning with ‘v’.

Different resources will need to be described and modelled, and we already have drafts / standards aplenty for this. Outside of the IETF scope, there is also an abundance for each infra type, NFV and so forth.

I have read the document twice and understand that it is talking about a potential problem space, but without providing details of issues which need to be addressed by IETF. 

It speaks of new protocols, but again there is no hint what they might be or what problems have been identified so far, other that the need for really good orchestration to bring the various functions together.

So far I believe we are still covered by existing technologies, and likely the biggest problem will be to pair down the list of which ones to recommend, with the rest of the problem statement being outside of the scope of the IETF.

I might even go so far as to say that this is potentially more a TOSCA type problem, with network modern SDN /programatic capabilities simply making the job of turning up network service easier, which was kinda the goal of SDN.

cheers

Andrew

> On 14 Feb 2017, at 20:45, Alex Galis <[email-masked]> wrote:
> 
> 14th February 2017
> 
> Dear All,
>