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

Kiran.Makhijani <Kiran.Makhijani@huawei.com> Thu, 15 March 2018 21:04 UTC

Return-Path: <Kiran.Makhijani@huawei.com>
X-Original-To: netslices@ietfa.amsl.com
Delivered-To: netslices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D317A126DED for <netslices@ietfa.amsl.com>; Thu, 15 Mar 2018 14:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THf7ZA86f_Jo for <netslices@ietfa.amsl.com>; Thu, 15 Mar 2018 14:04:40 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E59A1270B4 for <netslices@ietf.org>; Thu, 15 Mar 2018 14:04:40 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 802601772338E for <netslices@ietf.org>; Thu, 15 Mar 2018 21:04:36 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 15 Mar 2018 21:04:37 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML702-CHM.china.huawei.com ([169.254.4.179]) with mapi id 14.03.0382.000; Thu, 15 Mar 2018 14:04:32 -0700
From: "Kiran.Makhijani" <Kiran.Makhijani@huawei.com>
To: Jari Arkko <jari.arkko@piuha.net>
CC: "netslices@ietf.org" <netslices@ietf.org>
Thread-Topic: [Netslices] draft-arkko-arch-virtualization-01
Thread-Index: AQHTtTEgiYAywsp4bk2gljtABxJzlqPNgqiAgAMV9ACAAT0RAA==
Date: Thu, 15 Mar 2018 21:04:32 +0000
Message-ID: <5D401AE1-C32B-4A1A-A6C3-E8EABBD7CB49@huawei.com>
References: <2638F192-DDC1-45A2-B816-BA577038E335@piuha.net> <ED3F27B9-B6D5-4D55-B575-194E7E7A8E11@huawei.com> <A4D73A1C-DBEA-49F0-A757-3CEFA74F00BF@piuha.net>
In-Reply-To: <A4D73A1C-DBEA-49F0-A757-3CEFA74F00BF@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.246.107]
Content-Type: text/plain; charset="utf-8"
Content-ID: <7B92338E3AA9AA4486F0BF645483153A@huawei.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netslices/pYL1Bf8wXjNDzUOdZmO9zZgcww8>
Subject: Re: [Netslices] draft-arkko-arch-virtualization-01
X-BeenThere: netslices@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This list is intended for discussion and review of network slicing at IETF." <netslices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netslices>, <mailto:netslices-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netslices/>
List-Post: <mailto:netslices@ietf.org>
List-Help: <mailto:netslices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netslices>, <mailto:netslices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Mar 2018 21:04:43 -0000

Ok. What were you thinking in terms of control and data plane work?
^^^^^
Frankly, I don't know clearly yet. Just maybe: Things added to describe (a) newer QoS or reliability       aspects better and have them distributed from controller to devices. (b) virtual-networks type work: let's say I want to augment exchange tenant's policies from head-end of a slice to alter a flow dynamically, (c) Stitching of subnets with different kinds of isolations (VXLAN, VPN etc.).

For now, COMS has focused on 2 interfaces (1) from slice provider to infrastructure, (2) tenant to slice    provider. So 3rd thing will be how controllers of infrastructures will delegate tasks to devices for efficiency and dynamicity.

I may be wrong with the above examples. But more importantly, thinking about data-models should be done after we have identified what we want to do; it should not be starting architectural principle which to me is reversing the process.

-Kiran

On 3/14/18, 12:01 PM, "Jari Arkko" <jari.arkko@piuha.net> wrote:

    Kiran,
    
    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 (https://tools.ietf.org/html/draft-qiang-netslices-gap-analysis-01). only the narrative is different.
    
    Good!
    
    I have added some discussion of that document (and few others) under a new section for related work.
    
    > 4. https://tools.ietf.org/html/draft-netslices-usecases-02 also has 2 items that you touched upon (1) 3GPP-usecase (section 4.1), (2) role of virtualization (section 5).
    
    Yes.
    
    > 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.
    
    Right.
    
    > 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.
    
    Right.
    
    > 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?
    
    Jari