Subject: Re: [vnfpool] VNF Pool bar BoF follow-up

From: Melinda Shore <[email-masked]>
Date: Wed, 13 Nov 2013 18:55:38 -0900

Thank you again for putting together what I thought was a
useful session, and thank you for the sandwiches and beer!
A couple of points:

I think it's really important to have
a crisp, clear problem statement in a few sentences, what's
sometimes called an "elevator pitch" (i.e. make your case in
the time it takes to ride an elevator, although obviously the
elevators in the Hyatt in Vancouver distort the time
expectations ... ).  An actual charter would be much longer
and more detailed, but I think a simple problem statement is
a good place to start.

One thing that I think is missing but really needs to be
made both explicit and clear is what's meant by "reliable."
It's one of those words, like "scalable" or "secure" that
can mean any one of a number of things and should be explained
both in terms of what's covered and what's not.

In this case an abstract might look something like:
========
A vnfpool working group would focus on the problem of providing
reliable VNF instances and service chains, where by "reliable"
we mean <some text>.  The component problems that would need
to be solved include:
========
and then include your bullet points.  On "transport characteristics"
I'd probably say something along the lines of
. Identify and analyze transport characteristics for control plane
  traffic (reliability, QoS, etc.)
. Detailed analysis of transport security characteristics to provide
  protection against known threats, and identification of an appropriate
  trust model (with an eye towards key management)

I'm not sure I fully understand "Better coordination of VNF instance
deployment with underlying network information, performed in VNF pool
manager" and that may need some wordsmithing.

I believe the most recently chartered working group in the Transport
area is aqm, and it may be worthwhile taking a look at that to get
a feel for what a successful charter looks like these days.

Thanks again!

Melinda

---

From: Zongning <[email-masked]>
Date: Thu, 14 Nov 2013 08:52:45 +0000

Hi, Melinda,

Thanks for your comments and suggestions. Please see inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Melinda Shore
> Sent: Thursday, November 14, 2013 11:56 AM
> To: [email-masked]
> Subject: Re: [vnfpool] VNF Pool bar BoF follow-up
> 
> 

[Ning] I fully agree we need to get agreement on problem statement, before working on the charter.

> both in terms of what's covered and what's not.

[][Ning] Ideally, "reliability" means "the ability of the a system to limit disruption and return to normal when having fault, failure, etc.". But I intend to limit our scope to a pooling architecture that enables self-healing capability of VNF instances distributed in multiple pools in case of instance transition or failure. This VNF pool can be regarded as a underlying layer to support applications that may have various reliability requirements.

>   trust model (with an eye towards key management)

[Ning] Thanks for the suggested text.

> manager" and that may need some wordsmithing.

[Ning] I think the general idea is that network information (e.g. topology, link status, etc.) needs to be considered during virtualized instance deployment. Jan, I suppose you could elaborate a little bit more on this issue? :-)

> a feel for what a successful charter looks like these days.

-Ning

---

From: Zongning <[email-masked]>
Date: Thu, 14 Nov 2013 09:00:33 +0000

Sorry, more precise description on what "reliability" means in our scope.

[Ning] Ideally, "reliability" means "the ability of the a system to limit disruption and return to normal when having fault, failure, etc.". But I intend to limit our scope to a pooling architecture that enables self-healing capability of a set of VNFs where their instances are distributed in multiple pools and subject to transition or failure. This VNF pool can be regarded as a underlying layer to support applications that may have various reliability requirements.

> From: Zongning
> Sent: Thursday, November 14, 2013 4:53 PM
> To: 'Melinda Shore'; [email-masked]
> Subject: RE: [vnfpool] VNF Pool bar BoF follow-up
> 
> Hi, Melinda,
> 
> [][Ning] Ideally, "reliability" means "the ability of the a system to limit
> disruption and return to normal when having fault, failure, etc.". But I intend to
> limit our scope to a pooling architecture that enables self-healing capability of
> VNF instances distributed in multiple pools in case of instance transition or
> failure. This VNF pool can be regarded as a underlying layer to support
> applications that may have various reliability requirements.
> 
> [Ning] I think the general idea is that network information (e.g. topology, link
> status, etc.) needs to be considered during virtualized instance deployment.
> Jan, I suppose you could elaborate a little bit more on this issue? :-)
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 14 Nov 2013 13:54:21 +0000

Hi,

Looking at the definition below I am asking myself whether the pooling mechanisms could be generally applicable to any network function, so we could be talking about applying those mechanisms to the resiliency of the elements in a service graph (or SFC, if you like...)

Be goode,

On 14 Nov 2013, at 10:00 , Zongning wrote:

> _______________________________________________
> vnfpool mailing list
> [email-masked]
> 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: [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: Zongning <[email-masked]>
Date: Fri, 15 Nov 2013 00:41:03 +0000

Hi, Diego,

I think pooling mechanism is applicable, as we are now talking about virtualized instances which could be effectively managed (instantiate, scale up/down, etc.) by virtualization platform.
Thanks.

-Ning

> From: Diego R. Lopez [mailto:[email-masked]]
> Sent: Thursday, November 14, 2013 9:54 PM
> To: Zongning
> Cc: Melinda Shore; [email-masked]
> Looking at the definition below I am asking myself whether the pooling
> mechanisms could be generally applicable to any network function, so we could
> be talking about applying those mechanisms to the resiliency of the elements in
> a service graph (or SFC, if you like...)
> 
> Be goode,
> 
> > [Ning] Ideally, "reliability" means "the ability of the a system to limit
> limit our scope to a pooling architecture that enables self-healing capability of a
> set of VNFs where their instances are distributed in multiple pools and subject
> to transition or failure. This VNF pool can be regarded as a underlying layer to
> support applications that may have various reliability requirements.
> >
> 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:

---

From: Melinda Shore <[email-masked]>
Date: Fri, 15 Nov 2013 18:57:06 -0900

On 11/14/13 4:54 AM, Diego R. Lopez wrote:
> Looking at the definition below I am asking myself whether the
> pooling mechanisms could be generally applicable to any network
> function, so we could be talking about applying those mechanisms to
> the resiliency of the elements in a service graph (or SFC, if you
> like...)

There's existing IETF technology (rserpool) to provide a generalized
pooling mechanism.  Too general, and it's probably been overtaken by
events.

In order to start the work we need to demonstrate that we can finish
the work, and that means (among other things) no ocean-boiling.
Focus is extremely important.

Melinda

---

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

Hi All, 

Just a follow-up comment on Melinda's point. The generalized pooling
mechanism is discussed in an earlier document:

http://tools.ietf.org/html/draft-dreibholz-vnfpool-rserpool-applic-00

"This draft describes the application of Reliable Server Pooling (RSerPool)
for Virtual Network Function Resource Pooling (VNFPOOL)."

Although we should also be careful not to bias the problem statement,
requirements discussion and subsequent architecture, by focusing on solution
work (existing or to be extended) too early. 

Br, Dan. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Melinda Shore
Sent: 16 November 2013 03:57
To: Diego R. Lopez
Cc: [email-masked]; Zongning
Subject: Re: [vnfpool] VNF Pool bar BoF follow-up

On 11/14/13 4:54 AM, Diego R. Lopez wrote:
> mechanisms could be generally applicable to any network function, so 
> we could be talking about applying those mechanisms to the resiliency 
> of the elements in a service graph (or SFC, if you
> like...)

There's existing IETF technology (rserpool) to provide a generalized pooling
mechanism.  Too general, and it's probably been overtaken by events.

In order to start the work we need to demonstrate that we can finish the
work, and that means (among other things) no ocean-boiling.
Focus is extremely important.

Melinda