Re: [vnfpool] new VNFPool draft charter

[Melinda Shore <[e-mail]>]

On 6/6/14 10:40 AM, Zu Qiang wrote:
> -          It is good to narrow down the scope to redundancy module
> only. I’m assuming that a transparent redundancy module is the
> preferable solution of this WG. With transparent solutions, no impacts
> are expected on the pool user. Therefore, I would avoid any linkage with
> SFC.

We tried that!  There's some fairly deep concern about
overlap, and about whether or not some of this might encroach
on sfc turf - that was probably the main issue raised at
the BOF at IETF 89.  Because of that it's necessary to highlight
the differences between the work and clarify the relationship
between what sfc is doing and what vnfpool would do.

> -          I also don’t understand the statement “When a live VNF
> instance goes out of service, how does the service control entity learn
> which instance in a VNF Pool will replace it, and learn the
> characteristics of the new instance?” If transparent solutions are
> expected, why SCE needs to learn the failover?

That's a good point.

> -          My assumption is that the output from this proposed WG is one
> or more generic HA solutions. As we are in the early stage of the
> discussion, I don’t think we shall limit the solution to a specific one.
> I do have a hard time to understand why the Applicability and Gap
> Analysis shall be done based on a specific protocol?

IETF work tends to be bottom-up - specific, discrete, concrete
pieces of work are identified and scoped.  We don't solve A Big
Problem and assume it's generally applicable, but rather do work
of the nature of "Here's how to use <x> to do <y>."  It may in
fact turn out that there's interest in developing an availability
mechanism based on a different architectural model, and that's
okay.

> -          Reading the charter, it is not very clear that what the scope
> of the VNF is. Is it the service/function, or the entities providing
> this service/function? 

I think this is the question that "service state synchronization is
out of scope" answers.

Melinda


-- 
Melinda Shore
No Mountain Software
[e-mail]

"Software longa, hardware brevis."