Re: [vnfpool] new VNFPool draft charter

["Andrew G. Malis" <[e-mail]>]

Georgios,

I support the proposed charter in general, and this proposed change in
particular. This is important work and is a very necessary part of a VNF
implementation. Working on it in the IETF allows us to take advantage of
related experience and expertise and have output that's useful to the work
in the SFC WG.

Cheers,
Andy


On Wed, Jun 4, 2014 at 2:26 PM, <[e-mail]> wrote:

>  Hi Ning,
>
>
>
> The charter looks good to me!
>
>
>
> In order to solve the state synchronisation issue, you may want to modify
> the sentence from:
>
>
>
> Additional mechanisms that may be needed include state maintenance in a
> VNF Pool only for pooling purpose (service state synchronization is out of
> scope).
>
>
>
> INTO:
>
>
>
> Service state synchronization is out of scope. However, state maintenance
> mechanisms required in a VNF pool for pooling purposes are also in scope.
>
>
>
> Diego, Melinda, does the above change address your concerns.
>
>
>
> Best regards,
>
> Georgios
>
>
>
>   ------------------------------
> *Van:* vnfpool [[e-mail]] namens Zongning [
> [e-mail]]
> *Verzonden:* dinsdag 3 juni 2014 11:35
> *Aan:* [e-mail]
> *Onderwerp:* [vnfpool] new VNFPool draft charter
>
>   Hi, folks,
>
>
>
> Please see the below new draft charter of VNFPool. We believe that we have
> updated the charter to address most of the comments from London BoF. Main
> changes are:
>
> 1)       We narrow down our scope to only focus on the redundancy model
> and the related interfaces associated with the VNF Pool in a single VNF.
>
> 2)       Service state synchronization between VNF instances is
> out-of-scope. We may consider how to maintain the pool states in a VNF Pool
> only for pooling purpose.
>
> 3)       We assume that a VNF Pool contains redundant VNF instances of
> same functional type. Different types of VNFs are envisoned to be held in
> separate VNF Pools.
>
> 4)       We do not address reliability related control or routing between
> adjacent VNFs in the service graph. This is also applied to update the
> relation between VNF Pool and SFC WG.
>
>
>
> ==========================================================================
>
> 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 provide a reliable function, a VNF may adopt a pooling
> mechanism by using a number of VNF instances providing the same function,
> which we call a “VNF Pool”. Conceptionally, a Pool Manager is used to
> manage the 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?
>
> ·           When a live VNF instance goes out of service, how does the
> service control entity learn which instance in a VNF Pool will replace it,
> and learn the characteristics of the new instance?
>
> The WG initially focuses on several reliability mechanisms that are mainly
> associated with a redundancy model based on a VNF Pool in a VNF. Additional
> mechanisms that may be needed include state maintenance in a VNF Pool
> only for pooling purpose (service state synchronization is out of scope).
> The WG assumes that a VNF Pool contains redundant VNF instances of same
> functional type. Different types of VNFs are envisoned to be held in
> separate VNF Pools. 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 Pool and the service
> control entity.
>
> ·           Identify and analyze reliable transport protocols, such as
> 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 Pool Manager.
>
> The WG plans to deliver a problem statement, a set of use cases, VNF Pool
> requirements and an architecture covering the aforementioned technical
> aspects, and applicability and gap analysis of existing technologies such
> as RSerPool. 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, state maintenance solely for pooling purposes,
> reliable transport, and trust/security, all of which will need to be
> considered and addressed. The WG will include consideration of the
> manageability of a 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.
> Information exchanged between the VNF Pool and the SFC may include some
> operational information from the VNF Pool including the pool address, pool
> instance characteristic, and so on, as requested by the SFC WG.
>
>
>
> 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 VNFPool Requirements, including the manageability of
> VNF Pool to IESG for publication as Informational
>
> August 2015 - Submit VNFPool Architecture to IESG for publication as
> Proposed Standard
>
> December 2015 - Submit Applicability and Gap Analysis of RSerPool to IESG
> for publication as Informational
>
> ==========================================================================
>
>
>
> Your comments and suggestions to the charter text are highly appreciated!
>
>
>
> Thanks.
>
>
>
> -Ning
>
> _______________________________________________
> vnfpool mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vnfpool
>
>