[vnfpool] State management

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 25 July 2014 22:13 UTC

Return-Path: <adrian@olddog.co.uk>
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 AD8E91A03BB for <vnfpool@ietfa.amsl.com>; Fri, 25 Jul 2014 15:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OW05tdwBpC3X for <vnfpool@ietfa.amsl.com>; Fri, 25 Jul 2014 15:13:05 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BDE81A037C for <vnfpool@ietf.org>; Fri, 25 Jul 2014 15:13:04 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain []) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6PMD2iH008227 for <vnfpool@ietf.org>; Fri, 25 Jul 2014 23:13:02 +0100
Received: from 950129200 ([]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6PMD0OC008215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <vnfpool@ietf.org>; Fri, 25 Jul 2014 23:13:02 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: vnfpool@ietf.org
Date: Fri, 25 Jul 2014 23:13:04 +0100
Message-ID: <06be01cfa855$9bd1acd0$d3750670$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac+oVZenuSdQzK7FTsCQOip43tv5ww==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--5.685-10.0-31-10
X-imss-scan-details: No--5.685-10.0-31-10
X-TMASE-MatchedRID: jsxUPcGNVV7/TZdFgL/x66/CFdNrq+rVk9atiES99p2jdLyRE42E9mlF 7OhYLlctyKzYuAfVtMKib2Eymq9o7s1ybZtba3mcVtZNMIeE5PGrDPxf3LbqpE+0uGVOF08QIvE 3uA6qAEytWNmeiSi8s030aT0AOD6cbCKCT8RVQPoS7luGt6tlhiH2Y0Xxk8nYi2g8XzxCDfv9z+ z1eRqf0GntCa/pSQHPu9+soTfTMPe68Mln9Nwu0+J28KqpjndpZijLrBI/sgUgUEQTkIWiYllzo 9zSKaiK8Z+lsw1JOq8fZdczzDm/ur9ZdlL8eonaC24oEZ6SpSlsZUSYh+N/e7eO0FxOLtFrEFYy 4g7QN9l7KfldF9zaRuflAoHi2EDKNg3tecCMDvk=
Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/9q6dr4RedbzM8CJQ99TYJy3Q_08
Subject: [vnfpool] State management
X-BeenThere: vnfpool@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Fri, 25 Jul 2014 22:13:06 -0000


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 and
   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 functions.

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?