Hi, folks,

Based on the feedback, I made another revision of the problem description text, as below. The main updates are:

1)       Modification based on the comments from Hidetoshi and Lac, thank you;

2)       Avoid limiting VNF pools to be applied to SFC, by rewording VNF chain to VNF set;

3)       Add goals and milestones to make the whole text more like a charter.
I believe we need a draft charter as we are going to request a WG forming BoF in London. This is also why I changed the name of the thread.
You are welcome to use this version as a starting point for further comments, or bring a completely new *and* better one in your mind. :)

============================================================
A Virtualized Network Function (VNF) provides network function (e.g., packet filtering at firewalls, load balancing, etc) and is typically implemented as software instance running on commodity hardware server via virtualization layer (i.e., hypervisor). This is distinct from monolithic network devices, where either a single or a number of different network functions are provided in the same specialized hardware server.

There is a trend to move such network functions away from specialized hardware to commodity hardware server, based on virtualized resources, to support VNF and further also to support Service Function Chaining (SFC). In SFC, a network service can be implemented by a set of sequentially connected VNFs deployed at different points in the network. We call a group of VNFs a VNF set, which can be used not only as a SFC, but also solely as one or more pools of VNFs.

A VNF set can introduce additional points of failure beyond those inherent in a single specialized server, and therefore poses additional challenges on reliability of the provided services. For a single VNF, it typically would not have built-in reliability mechanisms on its host (i.e., a commodity hardware server). Instead, there are more factors or risk such as software failure, server overload, and instance migration that may lead to VNF failures. Currently generalized pooling and other redundancy mechanisms may be applied to address some reliability requirements of a single VNF.

However, the complexity of dealing with a growing number of VNFs including stateful and stateless functions, and extending the redundancy across a VNF set (i.e., multiple pools for multiple VNFs) requires further solution development. For example, when a "live" VNF pool member goes out of service, how do adjacent entities learn which pool member will replace it? How do VNFs learn the state of adjacent VNFs to support reliability mechanisms like load sharing and switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances and other members of its pool?

Ideally, the reliability of a VNF set means that the services provided by such a VNF set will continue throughout an interruption and the outages of one or more VNFs will not be visible to the users of the VNF set. In the current charter, the WG focuses the work around several mechanisms supporting the reliability of a VNF set: redundancy across a VNF set and stateful failover among pool members. Additional mechanisms for reliable VNF set might be included after further gap analysis between our requirements and IETF technologies.

The overall problem space can be further broken to include the following items:
. Signaling within and between VNF pools for transition (e.g. state change, scaling, moving) notification, backup advertisement;
. Identification and evaluation of state sharing mechanisms, including (but not limited to) distributed shared memory, gossip protocols, pfsync, and state check pointing;
. Exchange of reliability related information between a VNF set and the underlying network (e.g. interfacing with ALTO, I2RS);
. Identify and analyze reliable transport characteristics for control plane traffic;
. Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model;

The initial work will include a problem statement, VNF pooling architecture, use cases and requirements analysis, and an evaluation of existing technologies against the architecture and requirements. It is our expectation that we will be able to rely heavily on existing IETF technologies but that gaps will be found around problems like state transfer and trust/security, which will need to be addressed. Particularly, we will work closely with SFC WG to develop mechanisms complementary to SFC approaches, based on identified reliability requirements.

Goals and Milestones:
September 2014  Submit VNF Pool Problem Statement to IESG for publication as Informational
December 2014  Submit VNF Pool Use Cases and Requirements to IESG for publication as Informational
April 2015  Submit VNF Pooling Architecture to IESG for publication as Proposed Standard
April 2015  Submit first document of gap analysis to IESG for publication as Informational
============================================================

Thanks.

-Ning