Re: [vnfpool] State management

"Susan Hares" <> Sat, 26 July 2014 12:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 30E181ABB34 for <>; Sat, 26 Jul 2014 05:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NP4f96IQWvtQ for <>; Sat, 26 Jul 2014 05:03:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C8EAA1ABB31 for <>; Sat, 26 Jul 2014 05:03:38 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: Susan Hares <>
To: 'Melinda Shore' <>, "'Y. Richard Yang'" <>,
References: <06be01cfa855$9bd1acd0$d3750670$> <> <>
In-Reply-To: <>
Date: Sat, 26 Jul 2014 08:03:34 -0400
Message-ID: <002101cfa8c9$a07be240$e173a6c0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQGHQjPlgyd5Ecxjxu96RYI796ioAQJLDE0NAWzhk3ucJU890A==
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 12:03:40 -0000


A modular solution is key to the success of the VNF Pool work. Thank you for
reminding us of this fact.  


-----Original Message-----
From: vnfpool [] On Behalf Of Melinda Shore
Sent: Friday, July 25, 2014 9:26 PM
To: Y. Richard Yang;
Subject: Re: [vnfpool] State management

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