Re: [vnfpool] Updated VNFPool Charter

"Adrian Farrel" <> Tue, 24 June 2014 15:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 669DB1B2DAA for <>; Tue, 24 Jun 2014 08:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.2
X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZDKK9FYWzOpP for <>; Tue, 24 Jun 2014 08:30:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 951311B2AE1 for <>; Tue, 24 Jun 2014 08:27:34 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id s5OFRSvi013688; Tue, 24 Jun 2014 16:27:28 +0100
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s5OFRPH4013623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 16:27:26 +0100
From: Adrian Farrel <>
To: 'Zongning' <>,
References: <>
In-Reply-To: <>
Date: Tue, 24 Jun 2014 16:27:23 +0100
Message-ID: <02a301cf8fc0$cdf87a20$69e96e60$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGXNHh9HDAl8lOajOMEndIa7WFO05vxBDCg
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--20.633-10.0-31-10
X-imss-scan-details: No--20.633-10.0-31-10
X-TMASE-MatchedRID: 1ZHks2aQIkgk+4CnIn89IkhEDfw/93Bu+28MI88F5wTSYAzZ6KmqWmdd JepSFIdbIXuvUou2O0I5Bl0soiSEgd0FJl9zMXJU5gCHftmwEMIL8TGleseLPMkLZWuRur/xAv7 OaBdp4pKePUMPKDXhTuo3AJ/I+56AGCrhIPeWraaTeuX4xo2DECOjxzQ2RhginW4ZfaLgTQ5Pyx GdDFJKp6554+9Kr8EheieKSUBgIIPuHXE92Wk6HC2taMI32X8WcW+VwHmrYOVeoerFpvqVnf3tb KDJQoHTjPVpVub5F3FepDCqGaXzaZSL8e/MGApZE0Q83A2vD+uhKzbbSmEIF5dyc1Rr5oVFVaH1 pFj4a7WyetNrM/a8w+Fb/MUHDuO1XaB/chJb3tM6N/cDgNNi4bj89ydM+VlpVz8J52OVy+TLoqg zFwc5ifEzZQxj55s56S20eSyoghRbwfTXIdSuF4+YSzwl92XTwLlnHU0okA1tw+n+iKWyyI4tVe oS0/jnDkFsMFoNsCN8a2cWQ4WCaQgpNt5EgFbMVHX1qbz1ZDWC7C2rJeUToc7EPIkVcg+OxN0ok 49BhMeWzMwH7CIZQsdQf2Kqw9/GPRZQmUyuOaDG693ff8j9ZNIv4RV84lHTf7FDYGpyXq3Q4Ayj AwaAOMXzK2yYRXL0NPKRAucpRbrIMH0cCOoOna91/YHX0i1lCAruoteJOhwVuD482edP4/i7JjF pg6pYzrv9EgckBmORk6XtYogiarQ/aqQZTRfKVnRXm1iHN1bEQdG7H66TyOk/y0w7JiZo
Subject: Re: [vnfpool] Updated VNFPool Charter
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: Tue, 24 Jun 2014 15:30:56 -0000

Hi Ning,

I know that there have been some discussions on the list about the draft
charter, but I am returning to your clean copy from 12th June.

The charter looks good to me (at least from an RTG perspective). I have some
nits and a minor comment below.


> Network functions such as firewalls, load balancers, and WAN optimizers are
> conventionally deployed as specialized hardware servers in both network 
> operators' networks and data center networks as the building blocks of the

s/of the/of/

> network services. There is a trend to implement such network functions as
> software instances running on general purpose servers, via a virtualization
> layer (i.e., hypervisors).

I think that should read...
(i.e., under the control of a hypervisor)

> These virtualized functions are called Virtualized Network Functions (VNFs),
> which can be used to build network services.
>The use of VNFs introduces additional challenges to the reliability of the
> provided network services. A single VNF instance would typically not have
> built-in reliability mechanisms on its host (i.e., a general purpose server). 
> Instead, there are more factors of risk such as software failure at various

s/factors of risk/risk factors/

> levels including hypervisors and virtual machines, hardware failure, and
> instance migration that can make a VNF instance unreliable.
> In order to achieve higher reliability, a VNF may adopt a pooling
> mechanism, where a number of VNF instances with the same function
> can be grouped as a pool to provide the function. We call such a pool a
> VNF Pool.Conceptually, a Pool Manager is used to manage a VNF Pool,

s/Pool.Conceptually/Pool. Conceptually/

> e.g., selects active/standby VNF instances, and potentially interacts

s/selects/to select/
s/interacts/to interact/

> with a service control entity. Such a service control entity is an entity
> that orchestrates a set of network functions to build network services.
> The major benefit of using VNF Pool is that reliability mechanisms such
> as redundancy model are achieved by the VNF Pool inside the VNF and
> thus not visible to the service control entity. A VNF Pool-enabled VNF
> still appears as a normal VNF when orchestrated by a service control
> entity.

Is this completely how you want it? Isn't there some benefit to a service
control entity in knowing that a VNF is protected through a pool compared to
unprotected? That is, when a service control entity is selecting between NFV
instances it may select according to various factors (such as path length
between functions in a chain, and loading of VNF instances) and the knowledge
that one VNF instance is protected through an VNV pool may be significant.

So, I think that it is the operation of the VNF pool reliability mechanism that
is unknown to the service control entity, but not the fact of reliability.

> Questions that are raised by the addition of a pooling mechanism to 
> VNF include:
> . How to manage the redundancy model, e.g., select active/standby
>   VNF instances in a VNF Pool?
> . What pool states need to be maintained to support the pooling
>   mechanism itself, and how are such states maintained?
> . What information is exchanged between a VNF and a service
>   control entity? For example, how can a VNF Pool be addressed by
>   the service control entity?

Here we include the fact of reliability.

> . After a VNF instance failover, how does the Pool Manager notify
>    the service control entity some characteristic changes of the VNF,
>    e.g., capacity change, but without disclosure of the pooling
>   procedure?
> The WG initially focuses on several reliability mechanisms that are
> mainly associated with a redundancy model based on a VNF Pool.
> Additional mechanisms may include pool state maintenance only 
> for pooling purpose. Service state synchronization is out of scope
> for this phase. The WG assumes that a VNF Pool contains redundant
> VNF instances of same functional type. Different types of VNFs are
> envisioned to be held in separate VNF Pools. VNF Pool composed
> by both virtualized and non-virtualized functional instances may be 
> included after further use case and requirements study. The WG
> will address the reliability of an individual VNF, but not the reliability
> related to the control or the routing between adjacent VNFs that
> can form a network service.

I wonder whether the charter should be clearer that the VNF pool appears as an
instance and that only one instance in a pool is really active. The point here
is that the pool is not a set for load balancing across and does not increase
the load capacity of the VNF that the service control function can see.

> Specifically, the WG will work on the following technical aspects:
> . Redundancy management within a VNF Pool, such as the signaling
>   between the Pool Manager and the instances in the pool for instance
>   registration, backup instances selection, and switching between
>   active and standby instances.
> . The protocol between the Pool Manager and the underlying network
>    to collect the network information required for appropriate placement/
>    selection of backup instances.
> . The protocol between a VNF and the service control entity to exchange
>    operational information between a VNF Pool and the service control
>    entity.
> . Identify and analyze reliable interfaces, such as transport protocol like
>    MPTCP and SCTP for reliable delivery of the messages associated with
>    the redundancy management within a VNF Pool.
> . Analysis of pooling security characteristics and requirements to identify
>    and mitigate threats against the pooling mechanism. Identification of an
>    appropriate trust model between pool members, and between pool
>    members and the Pool Manager.
> The WG plans to deliver a problem statement, a set of use cases, 
> requirements and an architecture covering the aforementioned technical
> aspects, and applicability and gap analysis of existing technologies including
> but not limited to RSerPool. We will rely heavily on existing IETF
> but that gaps will be found around problems like redundancy mechanisms, 
> state maintenance solely for pooling purposes, reliable transport, and trust/
> security, all of which will need to be considered and addressed. Although no
> decision on protocols will be made in this phase, we will keep open for 
> candidate protocols for VNF Pool. The WG will seek re-chartering before
> adopting any work to develop new, or extend existing, protocols.
> In particular, we will work closely with the SFC WG, as we believe that SFC
> and VNF Pool are independent but complementary. SFC would essentially
> see a VNF Pool-enabled VNF as a normal service function and therefore be
> able to merge it into an SFC just like any other service functions. Just like
> the communication between any pool users and VNF Pool, the information
> exchanged between the VNF Pool and the SFC may include some operational
> information of the VNF Pool.
> Goals and Milestones:
> December 2014 - Submit VNFPool Problem Statement to IESG for publication
> as an Informational document.
> April 2015 - Submit VNFPool Use Cases to IESG for publication as an
> document.
> August 2015 - Submit VNFPool Requirements, including the manageability of VNF
> Pool to IESG for publication as an Informational document.
> August 2015 - Submit VNFPool Architecture to IESG for publication as an
> Informational document.
> December 2015 - Submit one or more Applicability and Gap Analysis of existing
> protocols to VNFPool to IESG for publication as Informational document(s).