Re: [vnfpool] New Charter for Toronto

[Don Clarke <[e-mail]>]

Ning and All,

I welcome this work as I have a strong belief that such mechanisms if properly implemented will enable NFV-based network topologies to provide many more options for delivering scalable high reliability networks than traditional point-hardware bounded topologies. I have highlighted this message in public statements whenever I get an opportunity and I have encouraged efforts in the ETSI NFV ISG towards this goal.

I would like to see a reference in this charter to related work in the ETSI NFV ISG for example in the REL Working Group (Naseem Khan copied) and the INF Working Group (Steve Wright copied). Also MANO (Raquel Morera copied). I know that you and no doubt many others on this list are involved in both places, but could we at least see some words in this charter that acknowledge relevant requirements coming from the NFV ISG?

Suggested text in line below.

Regards,
Don Clarke.

Chair, NFV ISG Network Operator Council

From: vnfpool [mailto:[e-mail]] On Behalf Of Zongning
Sent: Thursday, July 03, 2014 8:37 PM
To: [e-mail]
Subject: [vnfpool] New Charter for Toronto

Hi, all,
Please find below the new VNFPool Charter, by which I'd like to keep entertaining you. :)
This new version is based on the list discussion and feedback mainly from LAC Chidung, Hidetoshi, Sood, and Adrian. Thank you guys for improving our charter. Although I'd regard this version as a stable charter that reflects a rough agreement on the list and is ready for Toronto, further comments and suggestions are *always* welcome.
=======================================================================
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 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). 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 risk factors such as software failure at various 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 implementation 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, e.g., selects active/standby VNF instances, and potentially interacts 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 adopted by 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.
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 considering the infrastructure conditions, and scale a VNF instance 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?

*       After a VNF instance failover, how does the Pool Manager notify the service control entity of some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure?
The WG will refer to published ETSI NFV ISG documents relevant to this work, notably (but not limited to) the outputs of the REL, MANO and INF Working Groups to ensure that VNF Pooling mechanisms are compatible with the requirements published by the ETSI NFV ISG.
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 a same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed of 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.
Specifically, the WG will study 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.

*           Protocol between the Pool Manager and the underlying network to collect the network information required for appropriate placement/selection of backup instances.

*           Protocol between a VNF and the service control entity to exchange operational information between a VNF Pool and the service control entity.

*           Identification and analysis of 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 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.
We will work closely with the SFC WG, as we believe that SFC and VNF Pool are 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).
=======================================================================
Thanks.
-Ning