Subject: [vnfpool] Starting discussion

From: Melinda Shore <[email-masked]>
Date: Mon, 09 Sep 2013 10:13:08 -0800

Welcome to the reliable VNF mailing list.  We've laid out an
initial description of the problem in
https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/
and are looking for discussion and feedback, as well as looking
ahead towards a BOF proposal for the November meeting.

Background:

Virtualization technologies, including server virtualization,
network virtualization, and network function virtualization, are
getting wider industry adoption by both network operators and data
center providers.  Events over the lifetime of a virtualized instance
can impact reliability, much as they can with physical instances, but
there are additional events, such as elasticity in a running instance
and migration, that are peculiar to virtualized functions.  Our concern
is the reliability of virtualized network functions (VNFs) and how to
achieve VNF reliability both during a live event and during a VNF
failure.

An initial set of problems include:

1) VNF instance selection and status monitoring
One basic goal of reliable VNF is to select a suitable VNF instance
from a group of candidates and replace the VNF instance in case of
instance failure.

2) Backup instance selection and announcement
Before a VNF instance fails, one or more backup instances of the same
network function have to be selected and notified to the directly
connected instances in the adjacent VNFs.

3) Service state synchronization
The service state of the VNF instance should also be synchronized
between the VNF instance and its backup instances for stateful network
function.

4) VNF instance transition handling
Who is responsible and how to notify the VNF instance transition to the
directly connected instances in the adjacent VNFs? How to re-establish
the network connection and session between a new VNF instance and the
directly connected instances with an acceptable level of service
continuity?

5) VNF instance deployment policy enforcement
There can be some policies reflecting the different reliability class
of the service and hence affecting the selection of VNF instances.
Examples would include isolation policies requiring that VNF instances
be placed on separate physical servers or separate DC sites.
The above set of problems only serves as straw man proposal at this
moment. We are looking for more feedback from more folks to further
tune the problems - that's exactly the reason why we asked for this
mailing list to be created.

Next step and target:

The next steps in this work are to have a more open discussion on the
reliability and high availability problems related to VNF and to try to
converge to a reasonable set of problems fitting into an appropriate
IETF scope. Our current target is to have a BoF in Vancouver. The
nature of the intended BoF will depend on the progress we can make on
the list over the next few weeks. That is, if we can converge to an
appropriate set of problems, we can apply for a WG-forming BoF in
Vancouver. Otherwise, we can apply for an Information-gathering BoF in
Vancouver to have more discussion as well as hear more opinions from a
broader audience.

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Sep 2013 02:06:25 +0000

Hi,Melinda:
Interesting proposal. A few comments below:

a.Have you considered the relationship between the tenant and VNF instance?
I think usually vNF instance may be allocated to one or multiple tenants.
The association between vNF instance and tenant before one vNF instance is used
to manager user traffic.

b.Have you considered managing vNF instances cluster, in cluster, some instances play the active roles, the other play the standby roles?
How do you adapt to the role change at any time in case of failure?

c.Do you believe announcement is the only mechanism that can be used to discover or select backup vNF?
If announcement is used, how frequent one announcement is sent? How many announcement do we need if we
Manage thousands of vNF instances? What trigger announcement to be sent? Is VNF instance failure the 
Only reason to trigger announcement to be sent? How about vNF instance overloading or status change of vNF instance?
It looks to me it is very challenge to rely on traditional announcement mechanism to discover vNF instance since
vNF instance status may change at any time including replacing, transition you mentioned,etc and vNF instance can
be at any place, the number of vNF instances that need to be managed can be very large.

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Tuesday, September 10, 2013 2:13 AM
To: [email-masked]
Subject: [vnfpool] Starting discussion

Background:

Next step and target:

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 10 Sep 2013 10:12:41 -0800

On 9/9/2013 6:06 PM, Qin Wu wrote:
> a.Have you considered the relationship between the tenant and VNF
> instance? I think usually vNF instance may be allocated to one or
> multiple tenants. The association between vNF instance and tenant
> before one vNF instance is used to manager user traffic.

We really haven't, but it seems to me that the question of
tenancy is orthogonal to the question of reliability.  That
is to say, if a virtualized network function "fails over"
the state associated with it, including tenancy, fails
over as well.  It's definitely something that merits further
consideration but as I said I think that's probably
orthogonal.

> b.Have you considered managing vNF instances cluster, in cluster,
> some instances play the active roles, the other play the standby
> roles? How do you adapt to the role change at any time in case of
> failure?

Yes, exactly - those are prominent among the questions that
we believe must be addressed.

> c.Do you believe announcement is the only mechanism that can be used
> to discover or select backup vNF? If announcement is used, how
> frequent one announcement is sent? How many announcement do we need
> if we Manage thousands of vNF instances? What trigger announcement to
> be sent? Is VNF instance failure the Only reason to trigger
> announcement to be sent? How about vNF instance overloading or status
> change of vNF instance? It looks to me it is very challenge to rely
> on traditional announcement mechanism to discover vNF instance since 
> vNF instance status may change at any time including replacing,
> transition you mentioned,etc and vNF instance can be at any place,
> the number of vNF instances that need to be managed can be very
> large.

These are also very good points.  There's definitely a scaling
issue that needs to be considered and accommodated.  It may be
sufficient for a pool manager to have knowledge of available
instances and to arbitrate their allocation.  Again, this is a
question that would need to be addressed in any future work.

Thanks very much for your excellent questions.

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 10 Sep 2013 19:19:06 +0000

> we believe must be addressed.

[Linda] In NFV environment, the VNF instances within one cluster can spread over multiple locations for optimal bandwidth utilization purpose. Most data flows traverse through instances of different clusters. Like, Data centers flows go through WebServer instance, followed by AppServer Instance, and then followed by DB Server instances.

---

From: Qin Wu <[email-masked]>
Date: Wed, 11 Sep 2013 03:23:14 +0000

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Wednesday, September 11, 2013 2:13 AM
To: Qin Wu
Cc: Melinda Shore; [email-masked]
Subject: Re: [vnfpool] Starting discussion

[Qin]: I agree tenancy has nothing to do with reliability. The reason I raise this question is
I am more interested to know whether multi-tenancy is applied to the problem we are discussing.
I would like to see tenancy as some kind of constraint that is applied. 

Suppose subscriber traffic passes through several vNF instances that act as Firewall, Load balancer.
Do we care about which subscriber these traffic belong to or we only care about the performance or 
Status change of vNF instances?

When a set of vNF instances are created and selected, do we care about who owns these vNF instances or who uses these vNF instances?

Besides tenancy, I think there are something more we may need to think about.
When we ask for a set of vNF instances, do we care about the different service type(e.g., Firewall, LB) the vNF instances are going to provide,
Do we care about the number of vNF instances, do we care about the order of vNF instances? Do we care about the location of these vNF instances?
I think some of them may not directly related to reliability or resilience. However when we select the vNFs, we may have various service requirements
Or constraints or criteria that help us to select the matched vNF instance. 

The reliability level may be measured using location of these vNF instances, number of backup vNF instances.