Re: [vnfpool] new VNFPool draft charter

["Susan Hares" <[e-mail]>]

Ning:

 

This charter is really good.  The focus to a Pool for single VNF of a single
type is a great place to start.  Once we get a working situation we can go
out to important issues like state synchronization.  Like Diego, I agree we
should place the state synchronization “out of scope for this phase”. 

 

Sue Hares

 

From: vnfpool [mailto:[e-mail]] On Behalf Of Diego R. Lopez
Sent: Tuesday, June 03, 2014 6:23 PM
To: Zongning
Cc: [e-mail]
Subject: Re: [vnfpool] new VNFPool draft charter

 

Hi, 

 

It looks really good to me, Ning!

 

I am just wondering whether we could give state synchronization a special
category (of being "out of scope in this phase" or similar) because I think
it is a extremely relevant issue.

 

Be goode,

 

On 3 Jun 2014, at 11:35 , Zongning <[e-mail]> wrote:





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
 <mailto:[e-mail]> [e-mail]
 <https://www.ietf.org/mailman/listinfo/vnfpool>
https://www.ietf.org/mailman/listinfo/vnfpool

 


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

http://people.tid.es/diego.lopez/

e-mail: [e-mail]
Tel:    [phone]
Mobile: [phone]
-----------------------------------------

 

 

  _____  


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx