[vnfpool] State management

[Adrian Farrel]

Hi,

I completely understand why people want to work on state management: it is a hugely interesting and hard problem, and a lot of fun. But...

- Learn to walk before you try to run
- Not doing state management in the first pass at IETF work on this topic
does not preclude doing the research in your own labs and bring the
ideas to the IETF
- Draw a distinction between learned/derived state and programmed state.
The former is complex to synchronise. The latter is centrally controlled and
easy to synchronise/manage. I would argue the latter is automagically in
scope, but is not really "synchronisation", just parallel configuration.
- Don't assume that you can derive a generic solution for synchronising
dynamic state across a whole set of different classes of virtual functions.

And lastly, the question Martin asked interests me:

"Why do people are not convinced that the technical problem is solveable?"

The answer so far seems to be to a different question (e.g. "What else would you like to see in scope to make the problem interesting or more applicable to your deployment models?"). It is fine to answer that question and discuss the charter (although in my opinion trying to put state synchronisation in from day one will completely turn this from a real problem for rapid deployment into a research topic for many years). I would *really* like to hear whether there is an answer to Martin's question, or did the people who hummed also hum to the wrong question?

Thanks,
Adrian

[Y. Richard Yang]

Hi Adrian,

In my view, without state management, the vnfpool problem is hardly
solvable, i.e., reaching a usable goal. Hence, it is my attempt to
understand the "puzzle" posted by Martin. IETF prefers real use case droven
design. What is a use case with reasonable SLA but no dynamic state? Static
Web proxies? Even in this case, the controller has dynamic state. Hence, my
view is that we need to consider state management up front, to make sure it
is not the case that we are learning walking on the ground, but the goal
is swimming in the water :-

Regarding considering that state will turn into research. This is a valid
convern. My feeling is that both industry and academia have made good
progress on generic solutions. I support the formation of the proposed WG
so that it checks out solutions such as Zookeeper and merge/split, which
provide good examples of generic mechanisms/abstraction, considering state.
In other words, I am slightly more optimistic here in that IETF can jump
in, adopt the progress already made, and make an impact on a real problem
that IETF has more expertise i.e., VNF.

Just my 2 cents. And I am also looking forward to others sharing aspects.

Richard
Hi,

I completely understand why people want to work on state management: it is
a hugely interesting and hard problem, and a lot of fun. But...

- Learn to walk before you try to run
- Not doing state management in the first pass at IETF work on this topic
does not preclude doing the research in your own labs and bring the
ideas to the IETF
- Draw a distinction between learned/derived state and programmed state.
The former is complex to synchronise. The latter is centrally controlled
and
easy to synchronise/manage. I would argue the latter is automagically in
scope, but is not really "synchronisation", just parallel configuration.
- Don't assume that you can derive a generic solution for synchronising
dynamic state across a whole set of different classes of virtual
functions.

And lastly, the question Martin asked interests me:

"Why do people are not convinced that the technical problem is solveable?"

The answer so far seems to be to a different question (e.g. "What else
would you like to see in scope to make the problem interesting or more
applicable to your deployment models?"). It is fine to answer that question
and discuss the charter (although in my opinion trying to put state
synchronisation in from day one will completely turn this from a real
problem for rapid deployment into a research topic for many years). I would
*really* like to hear whether there is an answer to Martin's question, or
did the people who hummed also hum to the wrong question?

Thanks,
Adrian

[Melinda Shore]

Post by Y. Richard Yang
In my view, without state management, the vnfpool problem is hardly
solvable, i.e., reaching a usable goal. Hence, it is my attempt to
understand the "puzzle" posted by Martin. IETF prefers real use case
droven design.

I'd argue that while it may be the case, the piece that's
missing here, I think, is that the IETF prefers problems
to be broken down into solvable chunks. State management
is necessarily application-specific, while what we've been
trying to work on is a common substrate that can be used
to carry application-specific state. So, for the time being,
the substrate would be in-scope and the application state
would be out-of-scope, whether it would be handled by a
rechartered vnfpool or a separate working group (or
working groups). There's certainly precedent for this
sort of approach - for example nsis, MPLS, and others.
One of the things that concerns me, as someone who'd like
to see the work progress, is that those who are insisting
that this is an atomic problem seem also to effectively be
arguing against a modular approach to designing a solution.
And frankly I'm somewhat dismayed by that.

Melinda

[Y. Richard Yang]

Hi Melinda,

Not sure why you got the impression of these people arguing against a
modular. I do not. I strongly support.

Go back to industry practice. Zookeeper (Google) uses a single unifying
mechanism its special file system abstractionto handle instance
registration, instance keep alive, state sync, etc. A great design!

Given that the initial purpose of the WG appears to be gap analysis,
according to my understanding, I feel that leaving state sync, arguably a
key piece, out of scope, is not ideal. If the concern is that design is
hard, gap analysis may be not. This will make your WG work more valuable.
Make sense?

I am taking off now, and may be quiet for a while. I certainly hope the
proposed work (and adding one more item: state gap analysis) be approved.

Cheers,

Richard

Post by Melinda Shore

Post by Y. Richard Yang
In my view, without state management, the vnfpool problem is hardly
solvable, i.e., reaching a usable goal. Hence, it is my attempt to
understand the "puzzle" posted by Martin. IETF prefers real use case
droven design.

I'd argue that while it may be the case, the piece that's
missing here, I think, is that the IETF prefers problems
to be broken down into solvable chunks. State management
is necessarily application-specific, while what we've been
trying to work on is a common substrate that can be used
to carry application-specific state. So, for the time being,
the substrate would be in-scope and the application state
would be out-of-scope, whether it would be handled by a
rechartered vnfpool or a separate working group (or
working groups). There's certainly precedent for this
sort of approach - for example nsis, MPLS, and others.
One of the things that concerns me, as someone who'd like
to see the work progress, is that those who are insisting
that this is an atomic problem seem also to effectively be
arguing against a modular approach to designing a solution.
And frankly I'm somewhat dismayed by that.
Melinda
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool

[Zongning]

Hi, Richard, and all,

I don’t see a big dispute in your conversation. We don’t exclude state management as a whole. If we agree on a modular approach, we can carry on our work step by step.
Firstly I agree with Adrian that we should draw a distinction between the interface between pool members for state data transfer, and the interface between pool manager and pool member for state management. Although both these two interfaces are called “state management” in general - from many people’s perspective, they are quite different in nature.
The former is vendor specific and obviously needs agreement among multiple vendors in terms of failover (and state data transfer) between VNFs from different vendors. We are not in such situation yet, but will encourage vendors to discuss and bring gap analysis to show their support on interoperability. So your proposed work of gap analysis on state management is a good idea.
The latter is actually implicitly included in the charter, serving as a common substrate for state management. We agree that such standard interface between pool manager and pool members are important for decoupled innovation of different VNF and controller implementations. This issue has been clarified in early email from Melinda.
IMO, the VNF pool is usable and valuable, provided the standard interface between pool manager and pool members are well designed, to allow for interoperability between pool manager, and pool members from different vendors. This is quite different with any proprietary pooling solution based on single vendor implementation, and is the key value we want bring via IETF.

The real concern in my mind is that someone may still think that the whole VNF pool won’t succeed without opening the interface between pool members for state data transfer – which I strongly disagree.

Thanks.

-Ning

发件人: vnfpool [mailto:vnfpool-***@ietf.org] 代衚 Y. Richard Yang
发送时闎: 2014幎7月26日 9:49
收件人: Melinda Shore
抄送: ***@ietf.org; ***@olddog.co.uk
䞻题: Re: [vnfpool] State management


Hi Melinda,

Not sure why you got the impression of these people arguing against a modular. I do not. I strongly support.

Go back to industry practice. Zookeeper (Google) uses a single unifying mechanism its special file system abstractionto handle instance registration, instance keep alive, state sync, etc. A great design!

Given that the initial purpose of the WG appears to be gap analysis, according to my understanding, I feel that leaving state sync, arguably a key piece, out of scope, is not ideal. If the concern is that design is hard, gap analysis may be not. This will make your WG work more valuable. Make sense?

I am taking off now, and may be quiet for a while. I certainly hope the proposed work (and adding one more item: state gap analysis) be approved.

Cheers,

Richard
On Jul 25, 2014 9:26 PM, "Melinda Shore" <***@gmail.com<mailto:***@gmail.com>> wrote:
On 7/25/14, 8:51 PM, Y. Richard Yang wrote:
In my view, without state management, the vnfpool problem is hardly
solvable, i.e., reaching a usable goal. Hence, it is my attempt to
understand the "puzzle" posted by Martin. IETF prefers real use case
droven design.

I'd argue that while it may be the case, the piece that's
missing here, I think, is that the IETF prefers problems
to be broken down into solvable chunks. State management
is necessarily application-specific, while what we've been
trying to work on is a common substrate that can be used
to carry application-specific state. So, for the time being,
the substrate would be in-scope and the application state
would be out-of-scope, whether it would be handled by a
rechartered vnfpool or a separate working group (or
working groups). There's certainly precedent for this
sort of approach - for example nsis, MPLS, and others.
One of the things that concerns me, as someone who'd like
to see the work progress, is that those who are insisting
that this is an atomic problem seem also to effectively be
arguing against a modular approach to designing a solution.
And frankly I'm somewhat dismayed by that.

Melinda

_______________________________________________
vnfpool mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/vnfpool

[Susan Hares]

Melinda:

A modular solution is key to the success of the VNF Pool work. Thank you for
reminding us of this fact.

Sue

-----Original Message-----
From: vnfpool [mailto:vnfpool-***@ietf.org] On Behalf Of Melinda Shore
Sent: Friday, July 25, 2014 9:26 PM
To: Y. Richard Yang; ***@olddog.co.uk
Cc: ***@ietf.org
Subject: Re: [vnfpool] State management

Post by Y. Richard Yang
In my view, without state management, the vnfpool problem is hardly
solvable, i.e., reaching a usable goal. Hence, it is my attempt to
understand the "puzzle" posted by Martin. IETF prefers real use case
droven design.

I'd argue that while it may be the case, the piece that's missing here, I
think, is that the IETF prefers problems to be broken down into solvable
chunks. State management is necessarily application-specific, while what
we've been trying to work on is a common substrate that can be used to carry
application-specific state. So, for the time being, the substrate would be
in-scope and the application state would be out-of-scope, whether it would
be handled by a rechartered vnfpool or a separate working group (or working
groups). There's certainly precedent for this sort of approach - for
example nsis, MPLS, and others.
One of the things that concerns me, as someone who'd like to see the work
progress, is that those who are insisting that this is an atomic problem
seem also to effectively be arguing against a modular approach to designing
a solution.
And frankly I'm somewhat dismayed by that.

Melinda

[PEDRO ANDRES ARANDA GUTIERREZ]

+1
PS: please note my new email address below. Mails to my old emails @tid.es
will only be forwarded for a limited period of time
---
Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation

mailto:***@t <mailto:***@tid.es>elefonica.com
Telefónica, Investigación y Desarrollo
C/ D. Ramón de la Cruz,84
28006 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler

Post by Adrian Farrel
Hi,
I completely understand why people want to work on state management: it
is a hugely interesting and hard problem, and a lot of fun. But...
- Learn to walk before you try to run
- Not doing state management in the first pass at IETF work on this topic
does not preclude doing the research in your own labs and bring the
ideas to the IETF
- Draw a distinction between learned/derived state and programmed state.
The former is complex to synchronise. The latter is centrally controlled and
easy to synchronise/manage. I would argue the latter is automagically in
scope, but is not really "synchronisation", just parallel
configuration.
- Don't assume that you can derive a generic solution for synchronising
dynamic state across a whole set of different classes of virtual functions.
"Why do people are not convinced that the technical problem is solveable?"
The answer so far seems to be to a different question (e.g. "What else
would you like to see in scope to make the problem interesting or more
applicable to your deployment models?"). It is fine to answer that
question and discuss the charter (although in my opinion trying to put
state synchronisation in from day one will completely turn this from a
real problem for rapid deployment into a research topic for many years).
I would *really* like to hear whether there is an answer to Martin's
question, or did the people who hummed also hum to the wrong question?
Thanks,
Adrian
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool

________________________________

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