[vnfpool] 答复: State management

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.

Thanks.

-Ning

发件人: 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.

Cheers,

Richard
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.

Melinda

_______________________________________________
vnfpool mailing list
vnfpool@ietf.org<mailto:vnfpool@ietf.org>
https://www.ietf.org/mailman/listinfo/vnfpool