Subject: [vnfpool] VNF Pool Problem Statement

From: Zongning <[email-masked]>
Date: Thu, 21 Nov 2013 09:11:25 +0000

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, by carving 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

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

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

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

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

-          Transport characteristics

o   Identify and analyze reliable transport characteristics for control plane traffic;

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

Thanks.

-Ning

---

From: Mukhtiar Shaikh <[email-masked]>
Date: Fri, 22 Nov 2013 17:49:30 -0800

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.

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.."

"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.

Thanks.

-Ning

---

From: Zongning <[email-masked]>
Date: Mon, 25 Nov 2013 03:54:03 +0000

Hi, Mukhtiar,

Please see inline.

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

[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?

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 :). Anyway, sorry for the confusion. I would reword the examples to make them more clear.

Thanks,
-Mukhtiar

Hi,

Thanks.

-Ning

---

From: Melinda Shore <[email-masked]>
Date: Mon, 25 Nov 2013 16:58:10 -0900

On 11/22/13 4:49 PM, Mukhtiar Shaikh wrote:
> 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. 

I think this is an issue, as well, although I think that both
"availability" and "reliability" suffer from the same problem
as "secure," "scalable," "simple," etc. - they can mean different
things in different technical contexts and so it's important to
have additional text explaining what that means in this particular
instance.

> "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 latter is one of the as-yet unsolved problems (in the IETF)
that will need to be addressed.  One of the things that's changed
since rserpool was doing its work is that there's now a set of
publicly-available technologies for doing things look very much
like this problem.

The deadline for BOF proposals for the next meeting is rather short
and I think it would be useful over the next few weeks to concentrate
on putting together a successful proposal.

Melinda

-- 
Melinda Shore
No Mountain Software
[email-masked]

"Software longa, hardware brevis."

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 26 Nov 2013 12:00:00 +0900

Hi Ning and all,

The proposed PS is a very good starting point covering major
issues for the goal of VNF pool. One thing that I could add is the
synchronization between the vNF migration/replacement and routing
to make the relevant flows forwarded to the new location. The
challenge is that the VMs/severs in a pool could be deployed over
topologically different networks (in the physical world) and VNF
migration could involve topologically independent routing. There
are multiple ways to do it, but we should first generalize this
issue and specify a common mechanism that may leverage existing
ones.

If this is already covered, that's fine. If some additional text
is useful, the following could be a summary:

o Synchronization between vNF migration and flow forwarding, which
may require topologically independent routing in the physical
transport network;

There is a discussion about "reliability" and "availability" in
another thread and I think this is also an issue in ETSI NFV. We
need to define them either in this group or NFV to share the same
view.

Regards,

--
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:[email-masked]

(2013/11/21 18:11), Zongning wrote:

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, by
carving 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

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

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

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

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

-
Transport
characteristics

o
Identify
and analyze reliable transport
characteristics for control plane traffic;

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

Thanks.

-Ning

_______________________________________________
vnfpool mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vnfpool

---

From: Zongning <[email-masked]>
Date: Tue, 26 Nov 2013 03:47:19 +0000

Hi, Hidetoshi,

Thanks for your comments. Please see inline.

From: vnfpool [mailto:[email-masked]] On Behalf Of Hidetoshi Yokota
Sent: Tuesday, November 26, 2013 11:00 AM
To: [email-masked]
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi Ning and all,

The proposed PS is a very good starting point covering major issues for the goal of VNF pool. One thing that I could add is the synchronization between the vNF migration/replacement and routing to make the relevant flows forwarded to the new location. The challenge is that the VMs/severs in a pool could be deployed over topologically different networks (in the physical world) and VNF migration could involve topologically independent routing. There are multiple ways to do it, but we should first generalize this issue and specify a common mechanism that may leverage existing ones.

If this is already covered, that's fine. If some additional text is useful, the following could be a summary:

o Synchronization between vNF migration and flow forwarding, which may require topologically independent routing in the physical transport network;

[Ning]: Yes, I agree with your point on instance migration. Actually we list service state synchronization in the proposed study items as below.

o    Service state management (e.g. synchronizing method, state data format, location and mechanism to access state data) within VNF pool;
Regarding the flow forwarding, as you pointed out, there are existing ways in IETF to do that. We probably need to do more investigation work.

There is a discussion about "reliability" and "availability" in another thread and I think this is also an issue in ETSI NFV. We need to define them either in this group or NFV to share the same view.

Regards,

--

Hidetoshi Yokota

e-mail:[email-masked]<mailto:e-mail:[email-masked]>

Thanks.

-Ning

vnfpool mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 26 Nov 2013 18:06:03 +0000

Hi,

When it comes to the reliability/availability issue I guess providing some (condensed) definition from the NFV REL group would help...

Be goode,

On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote:

Hi Ning and all,

Regards,

--
Hidetoshi Yokota

Thanks.

-Ning

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

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

---

From: Mukhtiar Shaikh <[email-masked]>
Date: Tue, 26 Nov 2013 18:23:56 -0800

Hi Ning,

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

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

[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.

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.

Thanks,
-Mukhtiar

Hi,

Thanks.

-Ning

---

From: "Cao,Zhen" <[email-masked]>
Date: Fri, 29 Nov 2013 17:35:52 +0800

Hi Ning,

Discussion vNF chain here in vNF-Pool has the overlap with the Service
Function Chain group. a) we do not even know what will be the standard
chaining mechanism in IETF, b) how could us discussion reliability of this
chain without the chaining defined first.

Regards,
-cz

On Mon, Nov 25, 2013 at 11:54 AM, Zongning <[email-masked]> wrote:

>
> [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?
>
>
>
> 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.
>
>
>
>

---

From: Zongning <[email-masked]>
Date: Fri, 29 Nov 2013 10:02:51 +0000

Hi, Zhen,

During the Vancouver bar BoF, we also discussed the relation between VNF pool and FSC. We agreed that VNF pool will address different problem space. Assuming that some chaining mechanism has been defined in FSC regarding how to connect/chain the VNF instances, we focus on signaling related to resiliency, e.g. backup announcement, status notification, etc. So I'd see these two groups as complementary.
You are absolutely right that these two groups are related with each other. I can put some text in our proposed working scope to clarify this issue.
Thanks.

-Ning

From: vnfpool [mailto:[email-masked]] On Behalf Of Cao,Zhen
Sent: Friday, November 29, 2013 5:36 PM
To: Zongning
Cc: [email-masked]; Mukhtiar Shaikh
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi Ning,

Discussion vNF chain here in vNF-Pool has the overlap with the Service Function Chain group. a) we do not even know what will be the standard chaining mechanism in IETF, b) how could us discussion reliability of this chain without the chaining defined first.

Regards,
-cz

On Mon, Nov 25, 2013 at 11:54 AM, Zongning <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Cao,Zhen" <[email-masked]>
Date: Fri, 29 Nov 2013 18:17:13 +0800

> During the Vancouver bar BoF, we also discussed the relation between VNF
> pool and FSC.

Sorry I was not there physically.

> We agreed that VNF pool will address different problem space.
> Assuming that some chaining mechanism has been defined in FSC regarding how
> to connect/chain the VNF instances, we focus on signaling related to
> resiliency, e.g. backup announcement, status notification, etc. So I’d see
> these two groups as complementary.

Ok, then we need to specify in the charter that the discussion in this
working group is orthogonal to the detail chaining header used or
chosen by the SFC group, and the way the two potential groups works
together.

>
> You are absolutely right that these two groups are related with each other.
> I can put some text in our proposed working scope to clarify this issue.
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 1 Dec 2013 00:42:30 -0500

The discussion regarding FSC is a good one. Overall, I like the Problem
Statement. Two concepts stand out: VNF and Service Chain, both are large
concepts. The nice drawing by Linda helps, but I believe that this is a
simplified illustration, as during the meeting Diego showed that the model
can be more complex, if I understand him correctly. Does the intended WG
want to build on top of these two specific concepts, or build a more
general and hence reusable, modular solution? I see the more general
solution approach as one possible way to decouple from the Service Chain
definitions WG. To be concrete, the concepts from Chabby and rservpool
appear to be general.