Subject: [vnfpool] Follow-up question from the BOF

From: Martin Stiemerling <[email-masked]>
Date: Tue, 22 Jul 2014 16:14:18 -0400

Dear all,

This is a follow-up question from your responsible AD about the first 
hum we did take in the BOF @ IETF-90.

The questions asked was if the technical problem to be worked on is clear?
A majority on the session did hum against that the technical problem to 
be solved is clear.

However, from the discussion during the BOF session it is not clear to 
me that the technical problem isn't understood.

So now the question:
Why do people are not convinced that the technical problem is solveable?

So, enlight me :)

Thanks,

   Martin

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 22 Jul 2014 17:34:40 -0400

Hi Martin,

Here is one point. One constraint of the proposed work, in my view, is that
the scope does not consider state management. Most useful NFs are stateful.
Hence, removing state management from the scope is not ideal, and hence is
a limit. There is interesting recent progress in generic, reusable NF state
management, such as Merge/Split (
https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final205.pdf).
If this is included, I believe that the group can develop a lot more more
solutions.

Richard

On Tue, Jul 22, 2014 at 4:14 PM, Martin Stiemerling <[email-masked]>
wrote:

> Dear all,
>
> This is a follow-up question from your responsible AD about the first hum
> we did take in the BOF @ IETF-90.
>
> A majority on the session did hum against that the technical problem to be
> solved is clear.
>
> However, from the discussion during the BOF session it is not clear to me
> that the technical problem isn't understood.
>
> So now the question:
> _______________________________________________
> vnfpool mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vnfpool
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 24 Jul 2014 06:54:41 -0400

Hi Richard,

Am 22.07.14 um 17:34 schrieb Y. Richard Yang:
> Hi Martin,
>
> Here is one point. One constraint of the proposed work, in my view, is
> that the scope does not consider state management. Most useful NFs are
> stateful. Hence, removing state management from the scope is not ideal,
> and hence is a limit. There is interesting recent progress in generic,
> reusable NF state management, such as Merge/Split
> (https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final205.pdf).
> If this is included, I believe that the group can develop a lot more
> more solutions.

state management is an interesting topic, but there has been explicit 
community feedback during the first bof that this is not something the 
potential wg should be working on, as this is very vendor specific.

   Martin

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 24 Jul 2014 07:09:42 -0400

On 24 Jul 2014, at 06:54, Martin Stiemerling <[email-masked]> wrote:

> state management is an interesting topic, but there has been explicit community feedback during the first bof that this is not something the potential wg should be working on, as this is very vendor specific.
... and there are most likely a lot IPRs... That was one of the reasons
state sharing was excluded from the scope of RSerPool...

Best regards
Michael

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 24 Jul 2014 07:47:41 -0400

Martin, Michael,

IPR concerns are valid, but if they are crucial to solve the problem, and
the solution provides higher benefit, they could be addressed, right?

Regarding vendor specific solution, this is a very good point! Please take
a look at approaches such as merge/split. They allow vendor specific
packaging of NF state. Hence, transfers of state can be only among NFs of
the same vendor. The advance, however, is that at least the controller can
be different from the NF vendors. This is a good progress, in my view. Make
sense?

Richard
On Jul 24, 2014 7:09 AM, "Michael Tuexen" <[email-masked]>
wrote:

> >> (

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Thu, 24 Jul 2014 14:05:57 +0000

Hi,

As one of the supporters of the idea of not leaving state management out of scope, I am glad to see Richard's proposal and happy to support the idea of exploring a solution able to encompass vendor specific approaches.

Be goode,

On 24 Jul 2014, at 07:47 , Y. Richard Yang <[email-masked]<mailto:[email-masked]>> wrote:

Martin, Michael,

IPR concerns are valid, but if they are crucial to solve the problem, and the solution provides higher benefit, they could be addressed, right?

Regarding vendor specific solution, this is a very good point! Please take a look at approaches such as merge/split. They allow vendor specific packaging of NF state. Hence, transfers of state can be only among NFs of the same vendor. The advance, however, is that at least the controller can be different from the NF vendors. This is a good progress, in my view. Make sense?

Richard

On Jul 24, 2014 7:09 AM, "Michael Tuexen" <[email-masked]<mailto:[email-masked]>> wrote:

Best regards
Michael
> [email-masked]<mailto:[email-masked]>

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

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"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 y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Jul 2014 10:08:59 -0400

I am not big on high-five, but i would like to add my +1. I will find
vnfpool appealing
if it does state.

cheers,
jamal

On Thu, Jul 24, 2014 at 10:05 AM, DIEGO LOPEZ GARCIA
<[email-masked]> wrote:
> Hi,
>
> As one of the supporters of the idea of not leaving state management out of
> scope, I am glad to see Richard's proposal and happy to support the idea of
> exploring a solution able to encompass vendor specific approaches.
>
> Be goode,
>
> On 24 Jul 2014, at 07:47 , Y. Richard Yang <[email-masked]> wrote:
>
> Martin, Michael,
>
> Regarding vendor specific solution, this is a very good point! Please take a
> look at approaches such as merge/split. They allow vendor specific packaging
> of NF state. Hence, transfers of state can be only among NFs of the same
> vendor. The advance, however, is that at least the controller can be
> different from the NF vendors. This is a good progress, in my view. Make
> sense?
>
> Richard
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de la
> legislación vigente. Si ha recibido este mensaje por error, le rogamos que
> nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 24 Jul 2014 10:15:11 -0400

Diego and Richard:

As another supporter of including state management in scope, I support Richard’s proposal. 

Sue 

From: vnfpool [mailto:[email-masked]] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Thursday, July 24, 2014 10:06 AM
To: Y. Richard Yang
Cc: [email-masked]; Michael Tuexen; [email-masked]
Subject: Re: [vnfpool] Follow-up question from the BOF

Hi, 

Be goode,

Martin, Michael,

Richard

On Jul 24, 2014 7:09 AM, "Michael Tuexen" <[email-masked]> wrote:

Best regards
Michael

Dr Diego R. Lopez
Telefonica I+D

 

  _____

---

From: Melinda Shore <[email-masked]>
Date: Thu, 24 Jul 2014 10:45:10 -0400

Hi, folks:

We're in complete agreement about interoperability between
pool managers and pool elements from different vendors, and
that's already implicit in the charter (it's why we're
talking about standardizing a pooling protocol).  So, on that
front I think we're good.  It's probably premature to be
talking about protocol specifics but if we assume that the
data being transported between the pool manager and pool
elements are tagged (whether they're TLVs, JSON, ASN.1 -
whatever!) it allows for future extensibility related to
state conveyance, should the need arise.  That is to say,
I think we're in good shape in terms of not closing off the
possibility of future work.

Melinda

---

From: Zongning <[email-masked]>
Date: Thu, 24 Jul 2014 15:11:00 +0000

Just concur to Melinda - we agree to have state management related information to be transported between pool manager and members in a standard way. We have space/options in the protocols, but we need further I-Ds to talk about specification on protocol.
We could put just a few words in our charter to reflect this, if people feel more comfortable. As said, we already have implicit wording, so maybe just a trivial issue.

Thanks.

-Ning

-----邮件原件-----
发件人: vnfpool [mailto:[email-masked]] 代表 Melinda Shore
发送时间: 2014年7月24日 10:45
收件人: Y. Richard Yang
抄送: [email-masked]; [email-masked]
主题: Re: [vnfpool] Follow-up question from the BOF

Hi, folks:

We're in complete agreement about interoperability between pool managers and pool elements from different vendors, and that's already implicit in the charter (it's why we're talking about standardizing a pooling protocol).  So, on that front I think we're good.  It's probably premature to be talking about protocol specifics but if we assume that the data being transported between the pool manager and pool elements are tagged (whether they're TLVs, JSON, ASN.1 -
whatever!) it allows for future extensibility related to state conveyance, should the need arise.  That is to say, I think we're in good shape in terms of not closing off the possibility of future work.

Melinda

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 24 Jul 2014 13:11:08 -0400

Hi Melinda,

On Thu, Jul 24, 2014 at 10:45 AM, Melinda Shore <[email-masked]>
wrote:

> state conveyance, should the need arise.

The road map I see is that the initial tagging of state will be (NF,
vendor) specific, to allow both vendor innovation and more standard
controller-NF interaction. If good progress is made and an
agreement/convergence is achieved, for some NFs, it might become only NF.

> That is to say,
My personal suggestion is to include generic state management in scope. I
see good progress in this space already, and it is time for transfer. This
will substantially increase the usability and timeliness of the proposed
work. The plenary last night talked about more timeliness of IETF work.
This comment is in that spirit.

Cheers,

Richard