Re: [vnfpool] Updated VNFPool Charter

["Adrian Farrel" <[e-mail]>]

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.

Thanks,
Adrian

> 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
technologies,
> 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
Informational
> 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).