Re: [vnfpool] State management

"Y. Richard Yang" <> Sat, 26 July 2014 00:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7E8F11A0AEF for <>; Fri, 25 Jul 2014 17:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AxcG_BVB_Qsw for <>; Fri, 25 Jul 2014 17:51:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 341011A0AF2 for <>; Fri, 25 Jul 2014 17:51:16 -0700 (PDT)
Received: by with SMTP id la4so8280924vcb.5 for <>; Fri, 25 Jul 2014 17:51:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uNbdP5fwzkxPl2ToT1lBHB291wYGoB5LDkBqt6aAnrE=; b=FXs0/K+c+g0camFqfVHzqTSNnj4PIvjzA80mLZ4y6eCTuiC0E88R29KiQ6ttFnQlQS wC14nyOVrgZfaQDF53rfX8IGCIEp/qad5zsIK5lXpZjxUxW4Z73eIKqsoCl6PZ+ggy7A /nxp6zWujaqXJ6GWKxpTkhcgv2BzD/WEd61zuQtPw47azGnBV+vhYIpuXDLVM49aGoag a1JQBHopa1xnq3ZSGA+mGcHR4+ugPGyy6K4ONKhXUMsWRevao+VSkBC2pn5nrrfPulVO KouVcRUOG46bt7RShmLyeUDHvKqXtgW7FEhCDKKmnprogocf4cdlF621wol1z5iguiMr StDA==
MIME-Version: 1.0
X-Received: by with SMTP id e7mr5576593vdh.55.1406335875148; Fri, 25 Jul 2014 17:51:15 -0700 (PDT)
Received: by with HTTP; Fri, 25 Jul 2014 17:51:15 -0700 (PDT)
Received: by with HTTP; Fri, 25 Jul 2014 17:51:15 -0700 (PDT)
In-Reply-To: <06be01cfa855$9bd1acd0$d3750670$>
References: <06be01cfa855$9bd1acd0$d3750670$>
Date: Fri, 25 Jul 2014 20:51:15 -0400
X-Google-Sender-Auth: 84BsyKTM5Ky7cyJbJZmfO9YMerM
Message-ID: <>
From: "Y. Richard Yang" <>
Content-Type: multipart/alternative; boundary="20cf307c9ee645f33504ff0e162b"
Subject: Re: [vnfpool] State management
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for virtual network function resource pooling." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 26 Jul 2014 00:51:18 -0000

Hi Adrian,

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. What is a use case with reasonable SLA but no dynamic state? Static
Web proxies? Even in this case, the controller has dynamic state. Hence, my
view is that we need to consider state management up front, to make sure it
is not the case that we are learning walking on the ground,  but the goal
is swimming in the water :-)

Regarding considering that state will turn into research. This is a valid
convern. My feeling is that both industry and academia have made good
progress on generic solutions. I support the formation of the proposed WG
so that it checks out solutions such as Zookeeper and merge/split, which
provide good examples of generic mechanisms/abstraction, considering state.
In other words, I am slightly more optimistic here in that IETF can jump
in, adopt the progress already made, and make an impact on a real problem
that IETF has more expertise (i.e., VNF).

Just my 2 cents. And I am also looking forward to others sharing aspects.


I completely understand why people want to work on state management: it is
a hugely interesting and hard problem, and a lot of fun. But...

- Learn to walk before you try to run
- Not doing state management in the first pass at IETF work on this topic
   does not preclude doing the research in your own labs and bring the
   ideas to the IETF
- Draw a distinction between learned/derived state and programmed state.
   The former is complex to synchronise. The latter is centrally controlled
   easy to synchronise/manage. I would argue the latter is automagically in
   scope, but is not really "synchronisation", just parallel configuration.
- Don't assume that you can derive a generic solution for synchronising
   dynamic state across a whole set of different classes of virtual

And lastly, the question Martin asked interests me:

"Why do people are not convinced that the technical problem is solveable?"

The answer so far seems to be to a different question (e.g. "What else
would you like to see in scope to make the problem interesting or more
applicable to your deployment models?"). It is fine to answer that question
and discuss the charter (although in my opinion trying to put state
synchronisation in from day one will completely turn this from a real
problem for rapid deployment into a research topic for many years). I would
*really* like to hear whether there is an answer to Martin's question, or
did the people who hummed also hum to the wrong question?


vnfpool mailing list