Discussion:
[vnfpool] Follow-up question from the BOF
Martin Stiemerling
2014-07-22 20:14:18 UTC
Permalink
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
Y. Richard Yang
2014-07-22 21:34:40 UTC
Permalink
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
Post by Martin Stiemerling
Dear all,
This is a follow-up question from your responsible AD about the first hum
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.
Why do people are not convinced that the technical problem is solveable?
So, enlight me :)
Thanks,
Martin
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool
--
--
=====================================
| Y. Richard Yang <***@cs.yale.edu> |
| Professor of Computer Science |
| http://www.cs.yale.edu/~yry/ |
=====================================
Martin Stiemerling
2014-07-24 10:54:41 UTC
Permalink
Hi Richard,
Post by 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
Michael Tuexen
2014-07-24 11:09:42 UTC
Permalink
Post by Martin Stiemerling
Hi Richard,
Post by 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.
... 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
Post by Martin Stiemerling
Martin
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool
Y. Richard Yang
2014-07-24 11:47:41 UTC
Permalink
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
Post by Y. Richard Yang
Post by Martin Stiemerling
Hi Richard,
Post by 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
).
Post by Martin Stiemerling
Post by Y. Richard Yang
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.
... 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
Post by Martin Stiemerling
Martin
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool
DIEGO LOPEZ GARCIA
2014-07-24 14:05:57 UTC
Permalink
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 <***@cs.yale.edu<mailto:***@cs.yale.edu>> 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
Post by Martin Stiemerling
Hi Richard,
Post by 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.
... 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
Post by Martin Stiemerling
Martin
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool
_______________________________________________
vnfpool mailing list
***@ietf.org<mailto:***@ietf.org>
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: ***@telefonica.com
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
Jamal Hadi Salim
2014-07-24 14:08:59 UTC
Permalink
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
Post by DIEGO LOPEZ GARCIA
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,
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
Post by Michael Tuexen
Post by Martin Stiemerling
Hi Richard,
Post by 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.
... 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
Post by Martin Stiemerling
Martin
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool
_______________________________________________
vnfpool mailing list
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/
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
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool
Susan Hares
2014-07-24 14:15:11 UTC
Permalink
Diego and Richard:



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



Sue



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



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 <***@cs.yale.edu> 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
Post by Martin Stiemerling
Hi Richard,
Post by 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.
... 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
Post by Martin Stiemerling
Martin
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool
_______________________________________________
vnfpool mailing list
***@ietf.org
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: ***@telefonica.com
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
Melinda Shore
2014-07-24 14:45:10 UTC
Permalink
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
Zongning
2014-07-24 15:11:00 UTC
Permalink
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:vnfpool-***@ietf.org] 代表 Melinda Shore
发送时间: 2014年7月24日 10:45
收件人: Y. Richard Yang
抄送: ***@ietf.org; ***@gmail.com
主题: 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

_______________________________________________
vnfpool mailing list
***@ietf.org
ht
Y. Richard Yang
2014-07-24 17:11:08 UTC
Permalink
Hi Melinda,
Post by Melinda Shore
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.
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.
Post by Melinda Shore
That is to say,
I think we're in good shape in terms of not closing off the
possibility of future work.
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
Post by Melinda Shore
Melinda
Loading...