Subject: Re: [vnfpool] VNF Pool Problem Statement

From: lingli deng <[email-masked]>
Date: Thu, 28 Nov 2013 14:40:41 +0800

Hi Ning,

Thank you for the providing such a great starting point.

Following Mukhtia’s question about VNF replacement across different pools,
I have a further question:
By different pools, do you mean logical VNF pools managed by a single
manager, or do you mean physically separated resource pools at the same
time?

In other words, I would like to know if you are also considering the case
where different types of VNF instances are running on a single physical
device.

BR

Lingli

发件人: vnfpool [mailto:[email-masked]
<[email-masked]>] 代表Mukhtiar Shaikh
发送时间: 2013年11月27日 10:24
收件人: Zongning; [email-masked]
主题: Re: [vnfpool] VNF Pool Problem Statement

Hi Ning,

Sorry for the delay..please see my comments inline:

Thanks,

-Mukhtiar

From: Zongning <[email-masked]>
Date: Sunday, November 24, 2013 7:54 PM
To: Mukhtiar Shaikh <[email-masked]>, "[email-masked]" <
[email-masked]>
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi, Mukhtiar,

Please see inline.

From: Mukhtiar Shaikh [mailto:[email-masked] <[email-masked]>]
Sent: Saturday, November 23, 2013 9:50 AM
To: Zongning; [email-masked]
Subject: Re: [vnfpool] VNF Pool Problem Statement

Thanks Ning. I think this is a good start and captures most of the points
we have discussed so far. Just a few comments for clarity..

I think there is a subtle difference between reliability and availability
of a system or in this case VNF. I am just wondering if the problem we are
after is reliability of VNF or the availability of VNF and the service it
delivers. Considering basic assumption in NFV environment that is to ensure
service continuity of a network function running on general purpose servers
which by design are not as "reliable" as hardware based systems. This to me
implies service availability to be more relevant than reliability. We also
discussed this briefly during the Bar BoF ..not sure what the feedback was
on this. Either way, it may be in the semantics but want to make sure we
are stating reliability in the right context.

[Ning] I agree with you that there is difference between these two goals. I
am little bit conservative on addressing whole service availability as it’s
affected by too many factors covering elements of many layers – from
hardware to application. My personal idea is to keep our problem narrowed
on the reliability of VNF chain itself (as building block of service) to
get this piece of work chartered. Actually we have considered state
synchronization in proposal. But I am not sure how many further gaps
towards real service availability need to be verified as suitable IETF
work, at this moment of time. Maybe we could put them as future work?

I am ok with keeping the scope narrow and limiting it to reliability
aspects at this time.

Also, I am not too clear on what is meant by "…replace the instance of
VNF#2…" in the following text. Are we assuming that VNF#2 is pre-designated
as backup for VNF#1 and when a component or instance within VNF#1 cluster
fails, it needs to be replaced by a component within VNF#2? If that's the
case, we should state something like.."Multiple pools for multiple VNFs
backing up each other or sharing load.."

[Ning] VNF#1 and VNF#2 are different functions like vFW and vLB. We assume
they are executed one after another, so a certain instance of VNF#1
actually connects to a certain instance of VNF#2, in a specific session.
The backup instance and the instance to be backup (or replaced) are in the
same pool (i.e. belong to same function). Please refer to the good picture
posted by Linda J. Anyway, sorry for the confusion. I would reword the
examples to make them more clear.

Ok I see..If the two VNFs are different functions that means one is not
going to be replaced with the other..I think the text is a bit
confusing…thanks for the clarification.

"For example, how does an instance of VNF#1 know which instance in the pool
of VNF#2 will replace the instance of VNF#2 it connects to?  How does an
instance of VNF#1 know the state of instance of VNF#2 that it connects to
in order to enforce policy for reliability like load sharing, switch before
break? How is the service state of an instance held and accessed for
efficient synchronization with backup instances?"

Thanks,

-Mukhtiar

From: Zongning <[email-masked]>
Date: Thursday, November 21, 2013 1:11 AM
To: "[email-masked]" <[email-masked]>
Subject: [vnfpool] VNF Pool Problem Statement

Hi,

Please review the below brief version of VNF Pool Problem Statement, and
feedback with your comments. I hope this text can serve as a base of VNF
Pool Charter, bycarving out real problems and work items.

===========================================================================================

A virtualized network function (VNF) (e.g. vFW, vLB) provides the same
function as the equivalent network function (e.g. FW, LB), but is usually
instantiated as a cluster of software instances running on general purpose
servers via virtualization platform. In an environment based on VNFs, a
network service is typically realized by a chain of VNFs where the
instances of adjacent VNFs are preferably directly connected.

A VNF chain introduces additional points of failure beyond those inherent
in a single dedicated server, and therefore additional challenges on
reliability. By reliability, we mean the ability of a VNF chain to continue
function when having transition or failure within the chain. For example,
there are more factors such as software failure, server over-utilization,
instance migration that potentially cause VNF instance transition or
failure. Although a general pooling mechanism can be applied to address the
reliability of a single VNF, there are still problems when addressing the
reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For
example, how does an instance of VNF#1 know which instance in the pool of
VNF#2 will replace the instance of VNF#2 it connects to? How does an
instance of VNF#1 know the state of instance of VNF#2 that it connects to
in order to enforce policy for reliability like load sharing, switch before
break? How is the service state of an instance held and accessed for
efficient synchronization with backup instances?

The overall problem space can be further breakdown to the following study
items:

Signalling to handle reliability and instance transition requirements

Signalling between VNF pools for transition (e.g. state change, scaling,
moving) notification, backup announcement;

Service state management (e.g. synchronizing method, state data format,
location and mechanism to access state data) within VNF pool;

Obtaining underlying network information (e.g. ALTO, I2RS);

Signalling to CMS for instance deployment reflecting reliability
requirements (e.g. distribution of instances on different VMs or
hypervisors);

Transport characteristics

Identify and analyze reliable transport characteristics for control plane
traffic;

Analysis of transport security characteristics to provide protection
against known threats, and identification of an appropriate trust model;

===========================================================================================

Thanks.

-Ning

-- 
邓灵莉/Lingli Deng
中国移动通信研究院/China Mobile Research Institute
e-mail: [email-masked]
tel: 15801696688-3367
mobile: 13810597148

---

From: Zongning <[email-masked]>
Date: Thu, 28 Nov 2013 07:26:08 +0000

Hi, Lingli,

I think we cannot preclude the case where different types of VNF instances are running on same physical server – which is a deployment option.
You are right that the pool is logical.
Thanks.

-Ning

From: vnfpool [mailto:[email-masked]] On Behalf Of lingli deng
Sent: Thursday, November 28, 2013 2:41 PM
To: Zongning; [email-masked]; [email-masked]
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi Ning,

Following Mukhtia’s question about VNF replacement across different pools, I have a further question:
By different pools, do you mean logical VNF pools managed by a single manager, or do you mean physically separated resource pools at the same time?

In other words, I would like to know if you are also considering the case where different types of VNF instances are running on a single physical device.

BR
Lingli

发件人: vnfpool [mailto:[email-masked]] 代表 Mukhtiar Shaikh
发送时间: 2013年11月27日 10:24
收件人: Zongning; [email-masked]<mailto:[email-masked]>
主题: Re: [vnfpool] VNF Pool Problem Statement

Hi Ning,

Thanks,
-Mukhtiar

From: Zongning <[email-masked]<mailto:[email-masked]>>
Date: Sunday, November 24, 2013 7:54 PM
To: Mukhtiar Shaikh <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi, Mukhtiar,

Please see inline.

From: Mukhtiar Shaikh [mailto:[email-masked]]
Sent: Saturday, November 23, 2013 9:50 AM
To: Zongning; [email-masked]<mailto:[email-masked]>
Subject: Re: [vnfpool] VNF Pool Problem Statement

Thanks Ning. I think this is a good start and captures most of the points we have discussed so far. Just a few comments for clarity..

I think there is a subtle difference between reliability and availability of a system or in this case VNF. I am just wondering if the problem we are after is reliability of VNF or the availability of VNF and the service it delivers. Considering basic assumption in NFV environment that is to ensure service continuity of a network function running on general purpose servers which by design are not as "reliable" as hardware based systems. This to me implies service availability to be more relevant than reliability. We also discussed this briefly during the Bar BoF ..not sure what the feedback was on this. Either way, it may be in the semantics but want to make sure we are stating reliability in the right context.

[Ning] I agree with you that there is difference between these two goals. I am little bit conservative on addressing whole service availability as it’s affected by too many factors covering elements of many layers – from hardware to application. My personal idea is to keep our problem narrowed on the reliability of VNF chain itself (as building block of service) to get this piece of work chartered. Actually we have considered state synchronization in proposal. But I am not sure how many further gaps towards real service availability need to be verified as suitable IETF work, at this moment of time. Maybe we could put them as future work?

I am ok with keeping the scope narrow and limiting it to reliability aspects at this time.

Also, I am not too clear on what is meant by "…replace the instance of VNF#2…" in the following text. Are we assuming that VNF#2 is pre-designated as backup for VNF#1 and when a component or instance within VNF#1 cluster fails, it needs to be replaced by a component within VNF#2? If that's the case, we should state something like.."Multiple pools for multiple VNFs backing up each other or sharing load.."

[Ning] VNF#1 and VNF#2 are different functions like vFW and vLB. We assume they are executed one after another, so a certain instance of VNF#1 actually connects to a certain instance of VNF#2, in a specific session. The backup instance and the instance to be backup (or replaced) are in the same pool (i.e. belong to same function). Please refer to the good picture posted by Linda J. Anyway, sorry for the confusion. I would reword the examples to make them more clear.

Ok I see..If the two VNFs are different functions that means one is not going to be replaced with the other..I think the text is a bit confusing…thanks for the clarification.

"For example, how does an instance of VNF#1 know which instance in the pool of VNF#2 will replace the instance of VNF#2 it connects to?  How does an instance of VNF#1 know the state of instance of VNF#2 that it connects to in order to enforce policy for reliability like load sharing, switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances?"

Thanks,
-Mukhtiar

From: Zongning <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 21, 2013 1:11 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [vnfpool] VNF Pool Problem Statement

Hi,

Please review the below brief version of VNF Pool Problem Statement, and feedback with your comments. I hope this text can serve as a base of VNF Pool Charter, bycarving out real problems and work items.

===========================================================================================
A virtualized network function (VNF) (e.g. vFW, vLB) provides the same function as the equivalent network function (e.g. FW, LB), but is usually instantiated as a cluster of software instances running on general purpose servers via virtualization platform. In an environment based on VNFs, a network service is typically realized by a chain of VNFs where the instances of adjacent VNFs are preferably directly connected.

A VNF chain introduces additional points of failure beyond those inherent in a single dedicated server, and therefore additional challenges on reliability. By reliability, we mean the ability of a VNF chain to continue function when having transition or failure within the chain. For example, there are more factors such as software failure, server over-utilization, instance migration that potentially cause VNF instance transition or failure. Although a general pooling mechanism can be applied to address the reliability of a single VNF, there are still problems when addressing the reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For example, how does an instance of VNF#1 know which instance in the pool of VNF#2 will replace the instance of VNF#2 it connects to? How does an instance of VNF#1 know the state of instance of VNF#2 that it connects to in order to enforce policy for reliability like load sharing, switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances?

The overall problem space can be further breakdown to the following study items:
Signalling to handle reliability and instance transition requirements
Signalling between VNF pools for transition (e.g. state change, scaling, moving) notification, backup announcement;
Service state management (e.g. synchronizing method, state data format, location and mechanism to access state data) within VNF pool;
Obtaining underlying network information (e.g. ALTO, I2RS);
Signalling to CMS for instance deployment reflecting reliability requirements (e.g. distribution of instances on different VMs or hypervisors);
Transport characteristics
Identify and analyze reliable transport characteristics for control plane traffic;
Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model;
===========================================================================================

Thanks.

-Ning

--
邓灵莉/Lingli Deng
中国移动通信研究院/China Mobile Research Institute
e-mail: [email-masked]<mailto:[email-masked]>
tel: 15801696688-3367
mobile: 13810597148