Re: [vnfpool] VNF Pool Problem Statement

Hi, Zhen and Richard,

Thanks for the comments.
Please allow me to combine your comments to a single one - "we need more descriptive text about VNF, as well as how it would impact reliability?" :-))
I plan to add more sentences as below (or similar) into the problem statement.

A virtualized network function (VNF) provides network functions (e.g. firewalling, load balancing), but typically can be modularized and decomposed as instance running on general server via virtualization layer. This is distinct from monolithic network devices, where a number of different services are provided in the same device... I think ETSI NFV has definitions on VNF, VNFC, etc. which VNF pool can follow upon and use as starting point.
In the context of NFV, network services are typically implemented by a set of sequentially connected VNF instances deployed at different points in the network...
The challenges to reliability would then include: 1) for a single virtual instance, it normally doesn't assume built-in high reliability mechanism implemented by dedicated device on its host (i.e. general server). Therefore redundancy model where the role of active, standby instance are more dynamic...; 2) Virtual instance migration would require standard based, efficient stateful failover especially in the case of multi-vendor VNF deployment...; 3) the topology nature of VNF chain may require additional reliability supports, e.g. failure/status notification between node within the chain...; <we can add more later>

-Ning

> -----Original Message-----
> From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Cao,Zhen
> Sent: Monday, December 02, 2013 4:14 PM
> To: Y. Richard Yang
> Cc: vnfpool@ietf.org; Mukhtiar Shaikh; Zongning
> Subject: Re: [vnfpool] VNF Pool Problem Statement
> 
> I agree the discussion is one of good ones.
> 
> but two more questions to discuss:
> 
> a) Resilience of vnf pool is independent of the service chaining. Even
> without service chain, the problem still exist. I do not know if you
> agree.
> 
> b) The description in the text now seems not highly relevant to the
> NFV context. Some description seems valid even without virtualisation
> basis. Anyway service chain is not only a problem originating from
> virtualisation but more general.  Do we need to find more vnf related
> text, e.g., what's the difference between vnf reliability and none
> virtualized system reliability.
> 
> Regards,
> cz
> 
> On Sun, Dec 1, 2013 at 1:42 PM, Y. Richard Yang <yry@cs.yale.edu> wrote:
> > The discussion regarding FSC is a good one. Overall, I like the Problem
> > Statement. Two concepts stand out: VNF and Service Chain, both are large
> > concepts. The nice drawing by Linda helps, but I believe that this is a
> > simplified illustration, as during the meeting Diego showed that the model
> > can be more complex, if I understand him correctly. Does the intended WG
> > want to build on top of these two specific concepts, or build a more general
> > and hence reusable, modular solution? I see the more general solution
> > approach as one possible way to decouple from the Service Chain definitions
> > WG. To be concrete, the concepts from Chabby and rservpool appear to be
> > general.
> >
> >> During the Vancouver bar BoF, we also discussed the relation between VNF
> >> pool and FSC.
> >
> > Sorry I was not there physically.
> >
> >> We agreed that VNF pool will address different problem space.
> >> Assuming that some chaining mechanism has been defined in FSC regarding
> >> how
> >> to connect/chain the VNF instances, we focus on signaling related to
> >> resiliency, e.g. backup announcement, status notification, etc. So I'd see
> >> these two groups as complementary.
> >
> > Ok, then we need to specify in the charter that the discussion in this
> > working group is orthogonal to the detail chaining header used or
> > chosen by the SFC group, and the way the two potential groups works
> > together.
> >
> >>
> >> You are absolutely right that these two groups are related with each
> >> other.
> >> I can put some text in our proposed working scope to clarify this issue.
> >>
> > _______________________________________________
> > vnfpool mailing list
> > vnfpool@ietf.org
> > https://www.ietf.org/mailman/listinfo/vnfpool
> _______________________________________________
> vnfpool mailing list
> vnfpool@ietf.org
> https://www.ietf.org/mailman/listinfo/vnfpool