[vnfpool] 答复: comment on draft-zong-vnfpool-problem-statement
Zongning <zongning@huawei.com> Fri, 25 April 2014 06:31 UTC
Return-Path: <zongning@huawei.com>
X-Original-To: vnfpool@ietfa.amsl.com
Delivered-To: vnfpool@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com
(Postfix) with ESMTP id B8C8D1A0458 for <vnfpool@ietfa.amsl.com>;
Thu, 24 Apr 2014 23:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.522
X-Spam-Level:
X-Spam-Status: No,
score=-98.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,
CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3,
MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272,
SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 k6S86b0JpgAV for
<vnfpool@ietfa.amsl.com>; Thu, 24 Apr 2014 23:31:27 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by
ietfa.amsl.com (Postfix) with ESMTP id 8C0B01A0441 for <vnfpool@ietf.org>;
Thu, 24 Apr 2014 23:31:26 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com)
([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
with ESMTP id BDM05683; Fri, 25 Apr 2014 06:31:19 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by
lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id
14.3.158.1; Fri, 25 Apr 2014 07:30:18 +0100
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by
lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server
(TLS) id 14.3.158.1; Fri, 25 Apr 2014 07:31:18 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by
nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001;
Fri, 25 Apr 2014 14:31:12 +0800
From: Zongning <zongning@huawei.com>
To: Marco Liebsch <Marco.Liebsch@neclab.eu>,
"vnfpool@ietf.org" <vnfpool@ietf.org>
Thread-Topic: comment on draft-zong-vnfpool-problem-statement
Thread-Index: Ac9fmDyzNcG0Cup+RbOtZ5jtaBTJgwAoStnw
Date: Fri, 25 Apr 2014 06:31:12 +0000
Message-ID: <B0D29E0424F2DE47A0B36779EC66677966115363@nkgeml501-mbs.china.huawei.com>
References: <69756203DDDDE64E987BC4F70B71A26D6987A833@PALLENE.office.hd>
In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D6987A833@PALLENE.office.hd>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.22]
Content-Type: multipart/alternative;
boundary="_000_B0D29E0424F2DE47A0B36779EC66677966115363nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/1IMCZzjFa8gh6qgaXFifPeFnk58
Subject: [vnfpool] =?gb2312?b?tPC4tDogY29tbWVudCBvbiBkcmFmdC16b25nLXZuZnBv?=
=?gb2312?b?b2wtcHJvYmxlbS1zdGF0ZW1lbnQ=?=
X-BeenThere: vnfpool@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for virtual network function resource pooling."
<vnfpool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vnfpool>,
<mailto:vnfpool-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vnfpool/>
List-Post: <mailto:vnfpool@ietf.org>
List-Help: <mailto:vnfpool-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vnfpool>,
<mailto:vnfpool-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Apr 2014 06:31:31 -0000
Hi, Marco, Please see inline my reply. Considering the list feedback, I will update 4th version to 5th version (with trivial changes) by early next week, to make our scope more clear. Hi Ning, all, please find some more feedback to the 4th revision of the VNFPool PS draft below. It's more about a clarification before I can send more detailed comments on the draft. The draft clarifies about the technical scope, which I understand is limited to redundancy management and failover handling within a group of VNFs of the same type, the VNF set. [Ning] Yes, our current scope is intended to a VNF pool including group of VNF instances of the same type. VNF set is the overall set of VNF instances that can be grouped into multiple VNF pools, with each VNF pool providing a different network function. Another word, our scope is mainly a part of VNF set (a VNF pool), not the whole VNF set. To coordinate between functions of different pools, the draft introduces the Service Control Entity. [Ning] Correct. Does the Service Control Entity play a role in building a single network function, e.g. a firewall, from function instances of different pools? [Ning] We assume that Service Control Entity builds a network service composed of different network functions (e.g. firewall, DPI, load balancer) provided by different pools. So, each VNF pool provides different network function. Note that this assumption is mainly to drive general pooling architecture and charter scope. We will consider general solution by releasing such assumption if we identify reasonable use cases. For example, we may consider solution that covers the case that a pool can also provide VNFCs… It does not play a role if the complete firewall functionality is provided by a single VNF of a single Pool. Is this the assumption for VNFPool? [Ning] Please see above. From Fig. 1 of the draft I understand that the complete function (e.g. the firewall), is provided by a single box above the Virtualization Platform layer. And each box seems to be a virtual machine. [Ning] One or more VNF instances could be hosted by a single VM. So the box in Fig.1 is not necessarily a VM, although it likely to be true in practice. This would mean that each VNFPool provides a self-contained function, e.g. firewall, web-service, etc. There is no functional dependency between VNFs of different Pools. Is this understanding correct? [Ning] It is correct anyway that there is no functional dependency between VNFs of different pools. My understanding of how a virtualized network function vNF is built is that it comprises multiple vNF Components (vNFC) of the same (for function-internal load balancing) and of different types. Each vNFC is instantiated in a separate virtual machine. [Ning] Yes, I agree with your view on how a VNF is built. As said, we currently assume that a VNF pool contains a number of VNF instances of same functional type (e.g. firewall). We describe general pooling architecture and scope our work based on this assumption. I am still not sure how to reflect this in VNFPool: It may be details that hide inside a VNF as e.g. depicted in Fig. 1. In such case, the function-internal architecture made from different vNFCs is not visible to VNFPool. [Ning] You are right that the VNF-internal architecture about different VNFCs is currently hidden inside a VNF. We choose to start from a single level (VNF level), rather than a hierarchical level including both VNF and VNFCs inside VNF. We will develop general solution to cover both as next step of work, based on further use case study. I hope this is reasonable. :) I hope my reply helps! Thanks. -Ning