Re: [vnfpool] New VNFPool Charter - for London BoF

[LAC Chidung <[e-mail]>]

Sorry for forgetting to include the mailing list's address in my e-mail 
reproduced below.
Chidung

-------- Message original --------
Sujet: 	Re: [vnfpool] New VNFPool Charter - for London BoF
Date : 	Mon, 17 Feb 2014 10:31:50 +0100
De : 	LAC Chidung <[e-mail]>
Pour : 	Zongning <[e-mail]>


Hi Ning,
Some comments/suggestions below.
Best,
Chidung

Le 15/02/2014 04:02, Zongning a écrit :
>
> Hi, Folks,
>
> Please see the below new version of VNFPool Charter.
>
> Although the charter will be thoroughly discussed during BoF session, 
> I would encourage all of us to review and start discussion on the list 
> as soon as we could. Early feedback from the community will greatly 
> improve the efficiency and quality of our BoF in London !
>
> =============================================================================================
>
> 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 network services. There is a trend to implement 
> such network functions as software instances running on commodity 
> servers, via a virtualization layer (i.e., hypervisors). These 
> virtualized functions are called Virtualized Network Functions (VNFs).
>
> We call a group of VNFs a VNF set. A VNF set can include a single or 
> multiple types of VNF (e.g., virtual firewall, virtual load balancer), 
> where each type of VNF corresponds to a number of VNFs which is also 
> referred to as a VNF pool. A VNF set can be used to build network 
> services. For example, a VNF set can be used as a Service Function 
> Chain (SFC), where the VNFs are sequentially connected (i.e., chained) 
> to build a network service. Generally, a VNF set can be used not only 
> as a SFC, but also merely as a collection of multiple VNFs without 
> specific topological constraint.
>
> *
> CL: What is written above = a VNF set is composed of different VNF 
> pools, e.g., one pool with some (say X) vFWs, one pool with some (say 
> Y) vLBs. We can use this VNF set to realize a SFC. But what seems to 
> be missing is WHY pools of virtual functions ? Actually, to realize a 
> SFC, in the previous example, one vFW and one vLB are enough. I guess 
> the answer is: "We want to build a resilient SFC, i.e., redundancy is 
> needed - pools are thus needed" - if it is the case, we should 
> state/write/say it precisely.
> *
>
> A VNF set and the virtualized functions can introduce additional 
> points of failure beyond those inherent in a single specialized 
> server, and therefore poses additional challenges for the reliability 
> of the provided services. A single VNF would typically not have 
> built-in reliability mechanisms on its host (i.e., commodity server). 
> Instead, there are more factors of risk such as software failure, 
> server overload, and instance scaling and migration that may lead to 
> VNF failures. Existing pooling and other redundancy mechanisms should 
> be investigated and may be applied to address some reliability issues 
> of a single VNF.
>
> *CL:
> (i) How about "**software failure, server overload _due__to_ instance 
> scaling and migration that may lead to VNF failures" ? Actually, in 
> the 'commodity server' framework, software failures already exist - 
> what is new here is scaling and VM migration
> (ii) The use of pooling is mentioned NOW, but it was introduced 
> earlier without justification ... - also, pooling is part of the 
> options to be investigated BUT the use of this technique has already 
> been decided from the start (cf. the name of the "group", i.e., 
> "vnfpool") ...*
>
> However, the complexity of coordinating a growing number of VNFs 
> including stateful and stateless functions, and extending the 
> redundancy within 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 states of adjacent 
> VNFs before the failure of an adjacent VNF happens? How are the 
> service states of a VNF held and accessed for efficient 
> synchronization with backup VNFs?
>
> Ideally, the reliability of a VNF set means that the services provided 
> by such a VNF set will continue throughout an interruption within the 
> VNF set, and the outages of one or more VNFs will not be visible to 
> the users of the VNF set. The VNFPool WG focuses on mechanisms 
> supporting the reliability of a VNF set: redundancy within a VNF set, 
> and stateful failover among VNF pool members. Additional mechanisms 
> for reliable VNF set might be included after further gap analysis 
> between identified requirements and existing IETF technologies. The 
> VNFPool WG currently does not work to resolve the service availability 
> issue, although the reliability of VNF set will benefit service 
> availability.
>
> *CL: "after _a_ **further gap analysis between _the_ identified 
> requirements and existing IETF technologies"
>
> *
>
> The overall problem space can be further broken down into the 
> following objectives:
>
> . Signaling between members of a VNF pool, and across different VNF 
> pools for VNF transition (e.g., state change, scaling, moving) 
> notification, and backup advertisement;
>
> . Identification and evaluation of state sharing mechanisms between 
> members of a VNF pool, including distributed shared memory, gossip 
> protocols, pfsync, and state check pointing;
>
> . Exchange of reliability related information between a VNF set and 
> VNF set users, and information between a VNF set and underlying 
> network (e.g., interfacing with ALTO, I2RS);
>
> . Identify and analyze reliable transport characteristics for the 
> aforementioned control plane traffic of VNF pools;
>
> . Analysis of transport security characteristics to provide protection 
> against known threats, and identification of an appropriate trust model;
>
> * CL:
> (i) "**reliability related information**": examples of such info are 
> welcome
> (ii) "trust model_._"*
>
> Initially the VNFPool WG will develop a problem statement, VNF pooling 
> requirements and architecture, use cases, and gap analysis 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 
> redundancy mechanisms for a VNF set, state transfer, and 
> trust/security, all of which will need to be considered and addressed. 
> The VNFPool WG will include considerations on the manageability of VNF 
> pools in the requirements and architecture work items. The VNFPool WG 
> will seek re-chartering before adopting any work to develop new, or 
> extend existing, protocols.
>
> Particularly, we will work closely with the SFC WG, as we believe that 
> SFC and VNFPool are independent but complementary. SFC targets on 
> steering packets among VNFs, while VNFPool focuses on the redundancy, 
> e.g., managing active/standby instances, handling failure cases, 
> without caring about how to construct the data path. VNFPool could 
> interact with an SFC control entity to either advertise the status of 
> instance pools, or receive the redundancy requirement from the SFC 
> control entity. VNFPool is not only used in the case of "chained 
> VNFs", but also applicable to other cases where the VNFs are not 
> necessarily sequentially connected.
>
>
> *CL: "**but _is_ also applicable"*
>
> Goals and Milestones:
>
> December 2014 - Submit VNFPool Problem Statement to IESG for 
> publication as Informational
>
> April 2015 - Submit VNFPool Use Cases to IESG for publication as 
> Informational
>
> August 2015 - Submit VNF Pooling Requirements and Architecture 
> including the manageability of VNF pools to IESG for publication as 
> Proposed Standard
>
> August 2015 - Submit Gap Analysis to IESG for publication as Informational
>
> =============================================================================================
>
> Thanks.
>
> Melinda and Ning, as co-chair
>
>
>
> _______________________________________________
> vnfpool mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vnfpool