Re: [vnfpool] State management

Melinda Shore <melinda.shore@gmail.com> Sat, 26 July 2014 01:26 UTC

Return-Path: <melinda.shore@gmail.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 6D8931AD6B0 for <vnfpool@ietfa.amsl.com>; Fri, 25 Jul 2014 18:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 9kl4fFLUGb6p for <vnfpool@ietfa.amsl.com>; Fri, 25 Jul 2014 18:26:15 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6DB1AC0D2 for <vnfpool@ietf.org>; Fri, 25 Jul 2014 18:26:15 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id x48so4944211wes.19 for <vnfpool@ietf.org>; Fri, 25 Jul 2014 18:26:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2xvEFpfTs2+ZGI1VM8pdQ+RRSFzSzYN7Q2B1upR3IeY=; b=h/ciw9Fi7+FGeMfpO6abV94tM5gadqi6g4hPDSJbvxiLUbsYLtmVj93ivn4VRDNy5N CjHSvMForVk85d+qHRGMokQ3OHT48Lwqs7NKjCuJMya7Vg0YlHlrIlUP8qTsdmDGjuGi E7E5yONa7ycX9GDYTlhSGNkQ5Z8cXmFbSRGxUvVhMmJzwtPHF7Gl59za2M/bPW8PPxw7 pj0LHywP7RcuWRt7VJo33PEhYYpEV4WUrLyggbFGaDOlUYghXZBKsbV+lvGhC+CNXSsF pFsOKUN3ICr9z8TCdQTtZyh0RQMQfXoeKtt29AL8tTZ7+kWM+EhoFieSHuZPQDrEA376 0rsw==
X-Received: by 10.180.39.73 with SMTP id n9mr9872377wik.70.1406337973781; Fri, 25 Jul 2014 18:26:13 -0700 (PDT)
Received: from Melindas-MacBook-Pro.local ([206.47.221.210]) by mx.google.com with ESMTPSA id nc19sm1726456wic.4.2014.07.25.18.26.11 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 18:26:13 -0700 (PDT)
Message-ID: <53D303B3.4030205@gmail.com>
Date: Fri, 25 Jul 2014 21:26:11 -0400
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Y. Richard Yang" <yry@cs.yale.edu>, adrian@olddog.co.uk
References: <06be01cfa855$9bd1acd0$d3750670$@olddog.co.uk> <CANUuoLom=PGhypssOcjiYRbAMjw35_voLaG-4671Y6-8PmHSqw@mail.gmail.com>
In-Reply-To: <CANUuoLom=PGhypssOcjiYRbAMjw35_voLaG-4671Y6-8PmHSqw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/jSHB4fo9gofvEEJPxOgpIP7oTts
Cc: vnfpool@ietf.org
Subject: Re: [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: Sat, 26 Jul 2014 01:26:17 -0000

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