Re: [vnfpool] 答复: Updated VNFPool Charter

[LAC Chidung <[e-mail]>]

Hi Ning,
1) Is it exact that scaling out/in, one main characteristic of VNFs 
(compared to PNFs), is not included ?
2) Some comments/suggestions are enclosed.
Best,
Chidung

Le 12/06/2014 05:38, Zongning a écrit :
>
> Dear all,
> Please review the charter text included in the last email. We are 
> hoping that a general consensus on the charter could be achieved on 
> the list, then a stable charter is ready for the VNFPool session in 
> Toronto.
> Thanks.
> -Ning
>
> *发件人:*vnfpool [mailto:[e-mail]] *代表 *Zongning
> *发送时间:*2014年6月12日11:20
> *收件人:*[e-mail]
> *主题:*[vnfpool] Updated VNFPool Charter
>
> Dear all,
>
> Based on the list discussion since we posted the last version, I have 
> made some (minor) revision of the charter. The main changes are:
>
> 1)State that service state synchronization is out of scope “in this 
> phase”;**
>
> 2)Include VNF Pool with both virtualized and non-virtualized network 
> function for further study;**
>
> 3)Explicitly state that the reference solution & gap analysis is not 
> limited to RSerPool, but open to any other solutions, although no 
> decision on protocols will be made in this phase;**
>
> 4)State that the linkage between SFC and VNF Pool is just like a pool 
> user and a pool – nothing specified (yet);**
>
> 5)Update bullet #4 under “Questions that are raised…”, to keep it 
> consistent with the idea that pooling is not visible to the service 
> control entity.**
>
> ==========================================================================
>
> 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 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 factors of risk 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 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 
> 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.
>
> 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?
>
> ·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 WGassumesthat 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.
>
> 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 Pooland 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 maintenancesolely 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).
>
> ==========================================================================
>
> Your comments and suggestions to the charter are ALWAYS highly 
> appreciated!
>
> Thanks.
>
> -Ning
>
>
>
> _______________________________________________
> vnfpool mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vnfpool