Re: [Netslices] draft-arkko-arch-virtualization-01

Jari Arkko <> Wed, 14 March 2018 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F15521275FD for <>; Wed, 14 Mar 2018 12:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lW8c0AHdKPTy for <>; Wed, 14 Mar 2018 12:01:39 -0700 (PDT)
Received: from ( [IPv6:2001:14b8:1829::130]) by (Postfix) with ESMTP id 328E5127241 for <>; Wed, 14 Mar 2018 12:01:19 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC3156601EF; Wed, 14 Mar 2018 21:01:17 +0200 (EET)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QpP2VO-8tUjV; Wed, 14 Mar 2018 21:01:15 +0200 (EET)
Received: from [] ( [IPv6:2001:14b8:1829::130]) by (Postfix) with ESMTPS id 53C426601CD; Wed, 14 Mar 2018 21:01:15 +0200 (EET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jari Arkko <>
In-Reply-To: <>
Date: Wed, 14 Mar 2018 21:01:14 +0200
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Kiran.Makhijani" <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [Netslices] draft-arkko-arch-virtualization-01
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This list is intended for discussion and review of network slicing at IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Mar 2018 19:01:44 -0000


Thanks for discussing this important topic, and thanks for the feedback on our document. 

Please note that our doc is work in progress; we are all trying to describe how we envision future networks to be built (including 5G), and trying to converge our different findings. Sort of like each of us describing a different part of an elephant.

Some further discussion inline:

> 1.  "In particular, whether one calls a particular piece of technology "virtualization", "slicing", "separation", or "network selection" does not matter at the level of a system".
> ^^^^
> IMO, it should matter. virtualization is an old 'concept'. And what you call a particular piece of technology is important for clear differentiation. They may seem conceptually same at the top and may use common tools at the bottom but in-between techniques, usecases and methods would differ. Or perhaps you are alluding that all virtualization methods/technologies be uniformly done?

I think it is indeed very important to recognise those differing use cases and methods. 

But for what it is worth, my approach to things is usually to try describe the characteristics of things that I see, and while naming things is important, it is not as important as actually describing the things we try to convey. Admittedly, our document does not go very far in this direction either, but I think we can agree that we need to describe the different concepts and find their relations and differences.

And I don’t think we have a single concept nor a uniform solution for everything. I actually think that even for the 5G case, we actually have a collection different technologies that we have to put into use together. From cloud tech to network virtualisation to radio and whatever new things we will need to realize the business needs and concepts that are categorised under the term “slicing”.

> 2. For section 2, few things that raise curiosity is a) what is the purpose of many different definitions without inclination to a particular one or conclusive remark? b) to me discussion on NFV seems unnecessary here.

Clearly, more work is needed. What I would like to see is an explanation how the different concepts relate to each other. Clearly, NFV (and many other things) has a role, but is not the entirety of network slicing or virtualisation.

> 3. The discussion 5.2 to 5.5 were covered well in the problem statement-gap-analysis ( only the narrative is different.


I have added some discussion of that document (and few others) under a new section for related work.

> 4. also has 2 items that you touched upon (1) 3GPP-usecase (section 4.1), (2) role of virtualization (section 5).


> On the other hand, you do not talk about 5GEX type of usecases.

Probably should...

> Basically, are you saying that slices are only relevant for 5G?

Not at all, but again, I’m trying to describe concepts, and I see a toolbox of virtualisation - slicing - management - cloud tools that together are used in many networks (including 5G). Whether or not we call something “slicing” …

I can make that clearer in the next revision.

> 5. I think 5.5 is a very important discussion we need to have. As you say service models should just define characteristics, NSaas should be like that - important for IETF work.


> 6. In architectural principles - Data model layering,
> this is a very good observation; To me it means E2E integration which is a challenge in data models today; but the way you suggest, it sounds like a 'network design' problem. Should we tackle it here? Wouldn't a simpler way to connect different existing DMs together be sufficient (I think YANG allows to reference one DM from other - maybe develop this further)? maybe consider using a term other than 'layering’.

Re: should we tackle it here. For any work on data models at the IETF or elsewhere, one needs to have a clear picture of how that model fits to the rest of the world. For instance, it would be beneficial to understand that the goal of a model is to be an abstract model that ultimately maps to something more concrete in specific underlying device data models, for instance. So I’d say if we do data model work, we MUST understand how they are connected to the rest of the picture.

(But it doesn’t necessarily follow that we have to have the entire solution, or be able to solve all problems. But we have to understand what role we intend our creations to play.)

> 7. The ability to specify "statistical" rather than hard performance parameters.
> I don't understand the motivation here. The hard performance has been cited as a differentiator for slices (think URLLC type services), so it may not be a correct thing. Also think about if I want to map my parameters to DETNET YANG model, will I use statistical info? Although I agree on principle that TE models should have configs changes for different timescales.

Your comments are correct with respect to e.g. URLLC services. But what we intended to say was that you’ll need different types of guarantees, and I think at least one of my co-authors was arguing that today’s tech allows hard limits easier than statistical ones. So that might be a gap in current tech.

Do you agree or disagree? I’m not trying to argue the case either way, but I think we can find agreement that we actually need both types of guarantees in different circumstances. If we do agree, the only thing to find out is whether our current tech has some gaps on either.

> 8. Mapping from high abstraction level specifications to concrete network configurations.
> I think this is not specific to slices area and should be applicable to any service related work in data modeling space. It is an independent effort in itself that slices would directly benefit from.


> 9. cross-domain: quite an important aspect - if this is the only outcome from the slice activity, it would have served the purpose.

Right, agree.

> Overall the focus in the document is too much on modeling. It is ok to acknowledge that solutions are available at disposal but we should not completely eliminate/exclude work that may be needed in control and data plane (even though as extensions to existing protocol).

Ok. What were you thinking in terms of control and data plane work?