[vnfpool] 答复: 答复: Updated VNFPool Charter
Zongning <zongning@huawei.com> Mon, 30 June 2014 01:14 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 E7E551A0080 for <vnfpool@ietfa.amsl.com>; Sun, 29 Jun 2014 18:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.851
X-Spam-Level:
X-Spam-Status: No, score=-101.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n779m8cxthf for <vnfpool@ietfa.amsl.com>; Sun, 29 Jun 2014 18:14:55 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BDA1A007F for <vnfpool@ietf.org>; Sun, 29 Jun 2014 18:14:54 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGP73196; Mon, 30 Jun 2014 01:14:53 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 30 Jun 2014 02:14:50 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 30 Jun 2014 09:14:45 +0800
From: Zongning <zongning@huawei.com>
To: Hidetoshi Yokota <yokota@kddilabs.jp>, "vnfpool@ietf.org" <vnfpool@ietf.org>
Thread-Topic: [vnfpool] 答复: Updated VNFPool Charter
Thread-Index: AQHPjU0+OAdNG7vYaUyCr/Rq9MKw/ZuI4g0w
Date: Mon, 30 Jun 2014 01:14:44 +0000
Message-ID: <B0D29E0424F2DE47A0B36779EC66677966169825@nkgeml501-mbs.china.huawei.com>
References: <B0D29E0424F2DE47A0B36779EC666779661445F6@nkgeml501-mbs.china.huawei.com> <539F0610.2030601@kddilabs.jp> <B0D29E0424F2DE47A0B36779EC66677966145BDD@nkgeml501-mbs.china.huawei.com> <53A57BE1.8000302@kddilabs.jp>
In-Reply-To: <53A57BE1.8000302@kddilabs.jp>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.54]
Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677966169825nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/13IUe6pInbU7z_CcV1hWyEdp2do
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: Mon, 30 Jun 2014 01:14:59 -0000
Hi, Hidetoshi, Sorry for my belated reply. I tend to agree that we could at least discuss the use cases and requirements for service state synchronization among different vendors, but without making a formal deliverable until re-charter. Let’s put this as a open question to be discussed during Toronto BoF. Thanks. -Ning 发件人: vnfpool [mailto:vnfpool-bounces@ietf.org] 代表 Hidetoshi Yokota 发送时间: 2014年6月21日 20:35 收件人: vnfpool@ietf.org 主题: Re: [vnfpool] 答复: Updated VNFPool Charter Hi Ning, Thanks for your answer and clarification and sorry for my late response. Please see inline: (2014/06/17 10:36), Zongning wrote: Hi, Hidetoshi, Thanks for reviewing the new charter. Please see inline. -----邮件原件----- 发件人: vnfpool [mailto:vnfpool-bounces@ietf.org] 代表 Hidetoshi Yokota 发送时间: 2014年6月16日 22:58 收件人: vnfpool@ietf.org<mailto:vnfpool@ietf.org> 主题: Re: [vnfpool] Updated VNFPool Charter Dear Ning, Thanks a lot for updating the charter and congratulations on BoF approval! Allow me to ask a couple of clarification questions. o Could you clarify what "service state synchronization" is and why it is out of scope in this phase? [Ning] Service state related to a specific function, e.g., NAT translation table, is usually synchronized between a live and backup VNF instance for stateful failover. However, this seemed to be a controversial item during the last BoF in London IETF, where we could not find multi-vendor support to standardize the state synchronization interface among their VNFs. We certainly understand that this is still a very important item for VNF failover, and will keep looking for the multi-vendor support. As mentioned in the charter, we leave it out of scope in this phase, which means we don't exclude it but will treat it as a future work. HY> State synchronization is already identified by the PS document, so it is not appropriate just to say "out of scope in this phase". It may be possible to provide some assisting functions to the VNF even if service state synchronization is done within VNFs. At least, it should be discussed what level of synchronization can be supported and when. My proposal is: "The support of service state synchronization (e.g., its level and timing) will be determined during the course of this work" - Does this service state include "networking service"? If so, active/active redundancy cannot maintain the state information in, for example, virtual routers any more, which would be a significant degrade from the current physical networks. [Ning] See above. We agree it is important to maintain service state, but leave it out of scope until we find enough multi-vendor support. HY> The same discussion as the above. We should at least discuss it and potential requirement may be identified apart from when to fulfill it. - What is the relationship between service state synchronization and pool state maintenance? [Ning] Pool states could be operational information of VNF pool itself, e.g. redundancy settings (n+k, 1:n, etc.), backup location/status, etc. They are not related to service state. HY> Ok. Thanks. 2) Is the service control entity the NFV Orchestrator or VNF Manager or none of them in NFV terminolgy? [Ning] I would guess it is more like the NFV Orchestrator to orchestrate the whole service, although we don’t map the VNFPool terminology to NFV terminology by purpose. :-) 3) In the last paragraph just before Goals and Milestones, it says, "the information exchanged between the VNF Pool and the SFC may..." If some information is exchanged between them, they are not independent any more, which would contradict the first sentence of this paragraph. [Ning] Well, "independent" means that the pooling mechanisms defined in VNFPool are not coupled/dependent to SFC. But "independent" doesn't mean that they are not communicating at all. :-) So we have "information exchanged ...". HY> Ok, I think what is important is "complementary" and "independent" could be misleading. My proposal is: In particular, the WG will work closely with the SFC WG, which is expected to provide complementary functionality to VNF Pool. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp<mailto:e-mail:yokota@kddilabs.jp> Could you clarify a bit more on them please? Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp<mailto:e-mail:yokota@kddilabs.jp> (2014/06/12 12:19), Zongning wrote: Dear all, Based on the list discussion since we posted the last version, I have made some (minor) revision of the charter. The main changes are: 1)State that service state synchronization is out of scope “in this phase”;** 2)Include VNF Pool with both virtualized and non-virtualized network function for further study;** 3)Explicitly state that the reference solution & gap analysis is not limited to RSerPool, but open to any other solutions, although no decision on protocols will be made in this phase;** 4)State that the linkage between SFC and VNF Pool is just like a pool user and a pool – nothing specified (yet);** 5)Update bullet #4 under “Questions that are raised…”, to keep it consistent with the idea that pooling is not visible to the service control entity.** ====================================================================== ==== Network functions such as firewalls, load balancers, and WAN optimizers are conventionally deployed as specialized hardware servers in both network operators' networks and data center networks as the building blocks of the network services. There is a trend to implement such network functions as software instances running on general purpose servers, via a virtualization layer (i.e., hypervisors). These virtualized functions are called Virtualized Network Functions (VNFs), which can be used to build network services. The use of VNFs introduces additional challenges to the reliability of the provided network services. A single VNF instance would typically not have built-in reliability mechanisms on its host (i.e., a general purpose server). Instead, there are more factors of risk such as software failure at various levels including hypervisors and virtual machines, hardware failure, and instance migration that can make a VNF instance unreliable. In order to achieve higher reliability, a VNF may adopt a pooling mechanism, where a number of VNF instances with the same function can be grouped as a pool to provide the function. We call such a pool a VNF Pool.Conceptually, a Pool Manager is used to manage a VNF Pool, e.g., selects active/standby VNF instances, and potentially interacts 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. Questions that are raised by the addition of a pooling mechanism to VNF include: ·How to manage the redundancy model, e.g., select active/standby VNF instances in a VNF Pool? ·What pool states need to be maintained to support the pooling mechanism itself, and how are such states maintained? ·What information is exchanged between a VNF and a service control entity? For example, how can a VNF Pool be addressed by the service control entity? ·After a VNF instance failover, how does the Pool Manager notify the service control entity some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure? 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 WGassumesthat 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. Specifically, the WG will work on the following technical aspects: ·Redundancy management within a VNF Pool, such as the signaling between the Pool Manager and the instances in the pool for instance registration, backup instances selection, and switching between active and standby instances. ·The protocol between the Pool Manager and the underlying network to collect the network information required for appropriate placement/selection of backup instances. ·The protocol between a VNF and the service control entity to exchange operational information between a VNF Pooland the service control entity. ·Identify and analyze reliable interfaces, such as transport protocol like MPTCP and SCTP for reliable delivery of the messages associated with the redundancy management within a VNF Pool. ·Analysis of pooling security characteristics and requirements to identify and mitigate threats against the pooling mechanism. Identification of an appropriate trust model between pool members, and between pool members and the Pool Manager. The WG plans to deliver a problem statement, a set of use cases, requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies including but not limited to RSerPool. We will rely heavily on existing IETF technologies, but that gaps will be found around problems like redundancy mechanisms, state maintenancesolely for pooling purposes, reliable transport, and trust/security, all of which will need to be considered and addressed. Although no decision on protocols will be made in this phase, we will keep open for candidate protocols for VNF Pool. The WG will seek re-chartering before adopting any work to develop new, or extend existing, protocols. In particular, we will work closely with the SFC WG, as we believe that SFC and VNF Pool are independent but complementary. SFC would essentially see aVNFPool-enabled VNFas a normal service function and therefore be able to merge it into an SFC just like any other service functions. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool. Goals and Milestones: December 2014 - Submit VNFPool Problem Statement to IESG for publication as an Informational document. April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document. August 2015 - Submit VNFPool Requirements, including the manageability of VNF Pool to IESG for publication as an Informational document. August 2015 - Submit VNFPool Architecture to IESG for publication as an Informational document. December 2015 - Submit one or more Applicability and Gap Analysis of existing protocols to VNFPool to IESG for publication as Informational document(s). ====================================================================== ==== Your comments and suggestions to the charter are ALWAYS highly appreciated! Thanks. -Ning _______________________________________________ vnfpool mailing list vnfpool@ietf.org<mailto:vnfpool@ietf.org> https://www.ietf.org/mailman/listinfo/vnfpool _______________________________________________ vnfpool mailing list vnfpool@ietf.org<mailto:vnfpool@ietf.org> https://www.ietf.org/mailman/listinfo/vnfpool _______________________________________________ vnfpool mailing list vnfpool@ietf.org<mailto:vnfpool@ietf.org> https://www.ietf.org/mailman/listinfo/vnfpool
- [vnfpool] Updated VNFPool Charter Zongning
- [vnfpool] 答复: Updated VNFPool Charter Zongning
- Re: [vnfpool] Updated VNFPool Charter Hidetoshi Yokota
- [vnfpool] 答复: Updated VNFPool Charter Zongning
- Re: [vnfpool] 答复: Updated VNFPool Charter LAC Chidung
- [vnfpool] 答复: 答复: Updated VNFPool Charter Zongning
- [vnfpool] 答复: 答复: Updated VNFPool Charter Zongning
- Re: [vnfpool] 答复: Updated VNFPool Charter Hidetoshi Yokota
- Re: [vnfpool] Updated VNFPool Charter Adrian Farrel
- Re: [vnfpool] 答复: 答复: Updated VNFPool Charter LAC Chidung
- [vnfpool] 答复: Updated VNFPool Charter Zongning
- [vnfpool] 答复: 答复: 答复: Updated VNFPool Charter Zongning
- Re: [vnfpool] 答复: 答复: 答复: Updated VNFPool Charter LAC Chidung
- [vnfpool] 答复: 答复: 答复: 答复: Updated VNFPool Charter Zongning
- [vnfpool] 答复: 答复: Updated VNFPool Charter Zongning
- Re: [vnfpool] 答复: 答复: 答复: Updated VNFPool Charter Linda Dunbar
- [vnfpool] 答复: 答复: 答复: 答复: Updated VNFPool Charter Zongning
- Re: [vnfpool] 答复: 答复: 答复: Updated VNFPool Charter LAC Chidung