[vnfpool] 答复: State management

Zongning <zongning@huawei.com> Tue, 29 July 2014 08: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 []) by ietfa.amsl.com (Postfix) with ESMTP id F210B1A0086 for <vnfpool@ietfa.amsl.com>; Tue, 29 Jul 2014 01:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.901
X-Spam-Status: No, score=-103.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 In_UAeUrg4At for <vnfpool@ietfa.amsl.com>; Tue, 29 Jul 2014 01:31:13 -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 627921A00FA for <vnfpool@ietf.org>; Tue, 29 Jul 2014 01:31:12 -0700 (PDT)
Received: from (EHLO lhreml406-hub.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKQ43210; Tue, 29 Jul 2014 08:31:11 +0000 (GMT)
Received: from NKGEML410-HUB.china.huawei.com ( by lhreml406-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Tue, 29 Jul 2014 09:31:08 +0100
Received: from NKGEML501-MBS.china.huawei.com ([]) by nkgeml410-hub.china.huawei.com ([]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 16:31:05 +0800
From: Zongning <zongning@huawei.com>
To: "Y. Richard Yang" <yry@cs.yale.edu>, Melinda Shore <melinda.shore@gmail.com>
Thread-Topic: [vnfpool] State management
Thread-Index: Ac+oVZenuSdQzK7FTsCQOip43tv5w///phyAgAAJwoCAAAZxAP/6Xx7Q
Date: Tue, 29 Jul 2014 08:31:04 +0000
Message-ID: <B0D29E0424F2DE47A0B36779EC66677966176DEA@nkgeml501-mbs.china.huawei.com>
References: <06be01cfa855$9bd1acd0$d3750670$@olddog.co.uk> <CANUuoLom=PGhypssOcjiYRbAMjw35_voLaG-4671Y6-8PmHSqw@mail.gmail.com> <53D303B3.4030205@gmail.com> <CANUuoLqNVBdoZMfMUZKfQAmuPx5qA6_GMB-_LcTajPU+-Vc3zw@mail.gmail.com>
In-Reply-To: <CANUuoLqNVBdoZMfMUZKfQAmuPx5qA6_GMB-_LcTajPU+-Vc3zw@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677966176DEAnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/zyIy9VAATEhGPGmnCriuNkdJEc4
Cc: "vnfpool@ietf.org" <vnfpool@ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Subject: [vnfpool] 答复: State management
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: Tue, 29 Jul 2014 08:31:21 -0000

Hi, Richard, and all,

I don’t see a big dispute in your conversation. We don’t exclude state management as a whole. If we agree on a modular approach, we can carry on our work step by step.
Firstly I agree with Adrian that we should draw a distinction between the interface between pool members for state data transfer, and the interface between pool manager and pool member for state management. Although both these two interfaces are called “state management” in general - from many people’s perspective, they are quite different in nature.
The former is vendor specific and obviously needs agreement among multiple vendors in terms of failover (and state data transfer) between VNFs from different vendors. We are not in such situation yet, but will encourage vendors to discuss and bring gap analysis to show their support on interoperability. So your proposed work of gap analysis on state management is a good idea.
The latter is actually implicitly included in the charter, serving as a common substrate for state management. We agree that such standard interface between pool manager and pool members are important for decoupled innovation of different VNF and controller implementations. This issue has been clarified in early email from Melinda.
IMO, the VNF pool is usable and valuable, provided the standard interface between pool manager and pool members are well designed, to allow for interoperability between pool manager, and pool members from different vendors. This is quite different with any proprietary pooling solution based on single vendor implementation, and is the key value we want bring via IETF.

The real concern in my mind is that someone may still think that the whole VNF pool won’t succeed without opening the interface between pool members for state data transfer – which I strongly disagree.



发件人: vnfpool [mailto:vnfpool-bounces@ietf.org] 代表 Y. Richard Yang
发送时间: 2014年7月26日 9:49
收件人: Melinda Shore
抄送: vnfpool@ietf.org; adrian@olddog.co.uk
主题: Re: [vnfpool] State management

Hi Melinda,

Not sure why you got the impression of these people arguing against a modular. I do not. I strongly support.

Go back to industry practice. Zookeeper (Google) uses a single unifying mechanism (its special file system abstraction)to handle instance registration, instance keep alive, state sync, etc. A great design!

Given that the initial purpose of the WG appears to be gap analysis, according to my understanding, I feel that leaving state sync, arguably a key piece, out of scope, is not ideal.  If the concern is that design is hard, gap analysis may be not. This will make your WG work more valuable. Make sense?

I am taking off now, and may be quiet for a while. I certainly hope the proposed work (and adding one more item: state gap analysis) be approved.


On Jul 25, 2014 9:26 PM, "Melinda Shore" <melinda.shore@gmail.com<mailto:melinda.shore@gmail.com>> wrote:
On 7/25/14, 8:51 PM, Y. Richard Yang wrote:
In my view, without state management, the vnfpool problem is hardly
solvable, i.e., reaching a usable goal. Hence, it is my attempt to
understand the "puzzle" posted by Martin. IETF prefers real use case
droven design.

I'd argue that while it may be the case, the piece that's
missing here, I think, is that the IETF prefers problems
to be broken down into solvable chunks.  State management
is necessarily application-specific, while what we've been
trying to work on is a common substrate that can be used
to carry application-specific state.  So, for the time being,
the substrate would be in-scope and the application state
would be out-of-scope, whether it would be handled by a
rechartered vnfpool or a separate working group (or
working groups).  There's certainly precedent for this
sort of approach - for example nsis, MPLS, and others.
One of the things that concerns me, as someone who'd like
to see the work progress, is that those who are insisting
that this is an atomic problem seem also to effectively be
arguing against a modular approach to designing a solution.
And frankly I'm somewhat dismayed by that.


vnfpool mailing list