Subject: [vnfpool] bar BoF summary

From: Zongning <[email-masked]>
Date: Wed, 13 Nov 2013 06:51:42 +0000

Hi,

First of all, thank you guys for attending VNF Pool bar BoF in last IETF week. I believe most of us have understand the general problem aspects. In order to progress our work by carving out a set of detailed problems to be addressed in IETF, I list the following problem bullets. Please review the bullets and let me know your opinions (comments, suggestions, or even simply supports :)).

Summary on Problems:

-          Signalling to handle VNF resiliency and instance transition requirements

o   Signalling from VNF pool manager to CMS for VNF instance deployment reflecting resiliency requirements (e.g. number and distribution of instances running on different VMs or hypervisors);

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

o   State management (e.g. synchronizing service states between active/standby, or multiple actives for load sharing) within VNF pool;

-          Transport characteristics

o   Reliable transport protocols (e.g. MPTCP, SCTP) underlying the above signalling;

o   Security protocols;

-          Better coordination of VNF instance deployment with underlying network information, performed by VNF pool manager

o   ALTO, I2RS;

-          Analyze resiliency mechanisms complimentary to Service Function Chaining (SFC)

As more detailed background, I enclosed a VNF Pool diagram in attachment. For those who has difficulty on opening the attachment, here are major description:

*Multiple pools for multiple VNFs, with each pool containing a group of VNF instances providing same network function;

*Each pool has a manager to facilitate intra-pool resiliency, e.g. backup instance selection, service state synchronization;

*Inter-pool resiliency (e.g. instance transition notification) can be achieved by pool managers and/or instances from adjacent pools.

Thanks.

-Ning

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 14 Nov 2013 16:47:16 +0000

I feel the bullets listed below are more along the line of the needed mechanisms to solve the problem, but not the problem itself.

Here is the real problem:

In a nutshell, NFV Reliability (or VNFpool) is to address higher failure rate of service instances in NFV environment. For Performance reason, it is better for service instances to be directly connected, as shown below.

But, instances can fail, over-utilized, or moved...

*        How do instances of Function-1 know which instance in the pool of Function-2 will be the one replacing the failed instance?

*        Who is responsible for keeping the state of next available instances in the pool of next network function?

*        Who is responsible for keeping the state of the upstream instances?

*        What is the mechanism for each "Service Pool manager" to communicate with each other?

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Zongning
Sent: Wednesday, November 13, 2013 12:52 AM
To: [email-masked]
Subject: [vnfpool] bar BoF summary

Hi,

Summary on Problems:

o   Security protocols;

o   ALTO, I2RS;

Thanks.

-Ning

---

From: Zongning <[email-masked]>
Date: Fri, 15 Nov 2013 01:09:30 +0000

Hi, Linda,

Thank you for the text - which I agree is the more heuristic way to understand real problem. :) The bullets you listed are actually important issues in "signaling part" in the bar BoF summary.
Let's start from this text and see how folks would comment...

-Ning

From: Linda Dunbar
Sent: Friday, November 15, 2013 12:47 AM
To: Zongning; [email-masked]
Cc: Martin Stiemerling
Subject: Real Problem of VNFpool

Linda

Hi,

Summary on Problems:

o   Security protocols;

o   ALTO, I2RS;

Thanks.

-Ning

---

From: "Daniel King" <[email-masked]>
Date: Sun, 24 Nov 2013 13:53:37 -0000

Ning, 

Can I suggest a public wiki, google doc or github text file to capture the
current version of the vnfpool problem statement and subsequent
requirements, including signaling? It would make it easier for new list
members to catch-up with discussions and see the current proposal. 

Br, Dan. 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Zongning
Sent: 15 November 2013 01:10
To: Linda Dunbar; [email-masked]
Cc: Martin Stiemerling
Subject: Re: [vnfpool] Real Problem of VNFpool

Hi, Linda,

Thank you for the text - which I agree is the more heuristic way to
understand real problem. :) The bullets you listed are actually important
issues in "signaling part" in the bar BoF summary.

Let's start from this text and see how folks would comment.

-Ning

From: Linda Dunbar 
Sent: Friday, November 15, 2013 12:47 AM
To: Zongning; [email-masked] <mailto:[email-masked]> 
Cc: Martin Stiemerling
Subject: Real Problem of VNFpool

I feel the bullets listed below are more along the line of the needed
mechanisms to solve the problem, but not the problem itself. 

In a nutshell, NFV Reliability (or VNFpool) is to address higher failure
rate of service instances in NFV environment. For Performance reason, it is
better for service instances to be directly connected, as shown below. 

But, instances can fail, over-utilized, or moved.

.      How do instances of Function-1 know which instance in the pool of
Function-2 will be the one replacing the failed instance? 

.      Who is responsible for keeping the state of next available instances
in the pool of next network function? 

.      Who is responsible for keeping the state of the upstream instances?  

.      What is the mechanism for each "Service Pool manager" to communicate
with each other? 

 

Linda  

 

From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of Zongning
Sent: Wednesday, November 13, 2013 12:52 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [vnfpool] bar BoF summary

Hi,

First of all, thank you guys for attending VNF Pool bar BoF in last IETF
week. I believe most of us have understand the general problem aspects. In
order to progress our work by carving out a set of detailed problems to be
addressed in IETF, I list the following problem bullets. Please review the
bullets and let me know your opinions (comments, suggestions, or even simply
supports :)).

Summary on Problems:

-          Signalling to handle VNF resiliency and instance transition
requirements

o   Signalling from VNF pool manager to CMS for VNF instance deployment
reflecting resiliency requirements (e.g. number and distribution of
instances running on different VMs or hypervisors);

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

o   State management (e.g. synchronizing service states between
active/standby, or multiple actives for load sharing) within VNF pool;

o   Reliable transport protocols (e.g. MPTCP, SCTP) underlying the above
signalling;

o   Security protocols;

-          Better coordination of VNF instance deployment with underlying
network information, performed by VNF pool manager

o   ALTO, I2RS;

-          Analyze resiliency mechanisms complimentary to Service Function
Chaining (SFC)

As more detailed background, I enclosed a VNF Pool diagram in attachment.
For those who has difficulty on opening the attachment, here are major
description:

.Multiple pools for multiple VNFs, with each pool containing a group of VNF
instances providing same network function;

.Each pool has a manager to facilitate intra-pool resiliency, e.g. backup
instance selection, service state synchronization;

.Inter-pool resiliency (e.g. instance transition notification) can be
achieved by pool managers and/or instances from adjacent pools.

Thanks.

-Ning