[vnfpool] 答复: Updated VNFPool Charter

Zongning <zongning@huawei.com> Fri, 27 June 2014 01:22 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 1FBC31B3094 for <vnfpool@ietfa.amsl.com>; Thu, 26 Jun 2014 18:22:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.563
X-Spam-Status: No, score=-98.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wpmFUEnPx_cK for <vnfpool@ietfa.amsl.com>; Thu, 26 Jun 2014 18:22:53 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E091B298B for <vnfpool@ietf.org>; Thu, 26 Jun 2014 18:22:52 -0700 (PDT)
Received: from (EHLO lhreml404-hub.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGN67224; Fri, 27 Jun 2014 01:22:50 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com ( by lhreml404-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Fri, 27 Jun 2014 02:22:49 +0100
Received: from NKGEML501-MBS.china.huawei.com ([]) by nkgeml405-hub.china.huawei.com ([]) with mapi id 14.03.0158.001; Fri, 27 Jun 2014 09:22:45 +0800
From: Zongning <zongning@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "vnfpool@ietf.org" <vnfpool@ietf.org>
Thread-Topic: [vnfpool] Updated VNFPool Charter
Thread-Index: Ac+F7Smw56e+lYSeR1G1yb67uu0iZwJkJPOAAIkazrA=
Date: Fri, 27 Jun 2014 01:22:44 +0000
Message-ID: <B0D29E0424F2DE47A0B36779EC66677966168E1C@nkgeml501-mbs.china.huawei.com>
References: <B0D29E0424F2DE47A0B36779EC666779661445F6@nkgeml501-mbs.china.huawei.com> <02a301cf8fc0$cdf87a20$69e96e60$@olddog.co.uk>
In-Reply-To: <02a301cf8fc0$cdf87a20$69e96e60$@olddog.co.uk>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/vO_BCxrtTDf7TfDbtur_CnHU960
Subject: [vnfpool] 答复: Updated VNFPool Charter
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, 27 Jun 2014 01:22:55 -0000

Hi, Adrian,

Thank you for kindly review. I appreciate the nits correction, and see inline for minor comments.

发件人: Adrian Farrel [mailto:adrian@olddog.co.uk] 
发送时间: 2014年6月24日 23:27
收件人: Zongning; vnfpool@ietf.org
主题: RE: [vnfpool] Updated VNFPool Charter

Hi Ning,

I know that there have been some discussions on the list about the draft charter, but I am returning to your clean copy from 12th June.

The charter looks good to me (at least from an RTG perspective). I have some nits and a minor comment below.


> with a service control entity. Such a service control entity is an 
> entity that orchestrates a set of network functions to build network services.
> The major benefit of using VNF Pool is that reliability mechanisms 
> such as redundancy model are achieved by the VNF Pool inside the VNF 
> and thus not visible to the service control entity. A VNF Pool-enabled 
> VNF still appears as a normal VNF when orchestrated by a service 
> control entity.

Is this completely how you want it? Isn't there some benefit to a service control entity in knowing that a VNF is protected through a pool compared to unprotected? That is, when a service control entity is selecting between NFV instances it may select according to various factors (such as path length between functions in a chain, and loading of VNF instances) and the knowledge that one VNF instance is protected through an VNV pool may be significant.

So, I think that it is the operation of the VNF pool reliability mechanism that is unknown to the service control entity, but not the fact of reliability.

[Ning] Yes, you are right. A VNF could tell a service control entity that it is protected by a pool for better service orchestration. But this should be based on the negotiation between VNF pool and service control entity. Some control entity may only wants to know if a VNF is reliable or less reliable, without knowing too much about if there is a pool ... Anyway, thank you for suggestion, and we will keep this as an important case during requirement study. :)

> The WG initially focuses on several reliability mechanisms that are 
> mainly associated with a redundancy model based on a VNF Pool.
> Additional mechanisms may include pool state maintenance only for 
> pooling purpose. Service state synchronization is out of scope for 
> this phase. The WG assumes that a VNF Pool contains redundant VNF 
> instances of same functional type. Different types of VNFs are 
> envisioned to be held in separate VNF Pools. VNF Pool composed by both 
> virtualized and non-virtualized functional instances may be included 
> after further use case and requirements study. The WG will address the 
> reliability of an individual VNF, but not the reliability related to 
> the control or the routing between adjacent VNFs that can form a 
> network service.

I wonder whether the charter should be clearer that the VNF pool appears as an instance and that only one instance in a pool is really active. The point here is that the pool is not a set for load balancing across and does not increase the load capacity of the VNF that the service control function can see.

[Ning] You are right that a VNF pool appears as a single instance to outside entity such as service control entity. Regarding the internal model to a VNF pool, I do agree with Lac Chidung that we would not constrain a VNF pool's internal model to have only one active instance. Redundancy model with more than one active instance (e.g. n+k, n:m) is inherent to pooling methodology and will benefit a VNF pool with good flexibility & reliability.

Please let me know your further comments & suggestions.