Re: [vnfpool] Overlap with SFC?

[Qin Wu <[e-mail]>]

Good clarification.
I think SFC and NFVPool may share some common components, e.g., service function discovery, service function identifier, service function locator,
As for auto provision, SFC focuses on how to provision service function and setup service function path while NFVPool focuses on how to replace the
Failing one with the same class service function, irrespective the failing service node is in the service chain or not.

As for proposed work, I am not sure obtaining underlying network information is enough, service function is build on top of underlying network.The underlying network information should be abstracted and form service topology for service function.

Regards!
-Qin
-----Original Message-----
From: vnfpool [mailto:[e-mail]] On Behalf Of King, Daniel
Sent: Wednesday, January 22, 2014 3:24 AM
To: Melinda Shore; [e-mail]
Cc: [e-mail]
Subject: Re: [vnfpool] Overlap with SFC?

Hi Again,  

Thanks Melinda, you are far more succinct than I have been. However, seeing as we may have some additional interest in the vnfpool work, it may be worth summarizing our problem space and some of our discussion thus far for anyone peeking at the list for the first time:

A Virtualized Network Function (VNF) (e.g. vBRAS vFirewall, vLoadbalancer) provides the equivalent function as a dedicated hardware platform. These VNF instances are typically instantiated in clusters running on general purpose servers via a variety of virtualization platforms. As per discussions within the SFC Working Group (WG), a user/network service is typically realized by a chain of VNFs (also known as a VNF Forwarding Graph -VNFG)  to deliver function in a deterministic sequence. Whereas SFC WG is tasked with investigating and documenting SFC architecture, and  SFC protocol mechanisms (new or extensions to existing solutions) in order to encapsulate and steer traffic, and convey SFC and Service Function Path (SFP) information to function nodes, both virtual and physical.

The vnfpool list was initiated to investigate the resilience requirements and solutions  for virtual network functions, running as single, or pools (sets) of VNFs. So clearly some of the vnfpool work may be complimentary to the SFC WG, but I think the majority of work will be in parallel to the SFC WG. Initially this list has scoped the vnfpool work into a problem statement, use cases, architecture and signalling to deploy and manage VNF pool resilience (reliability, redundancy, availability, failover), these discussions have included:

- Signalling between VNF pools for transition (e.g. state change, scaling, moving) management, notification, backup, performance monitoring and announcements;

- Service state management (e.g. synchronizing method, state data format, location and mechanism to access state data);

- Obtaining underlying network information (e.g., this is where we expect cooperation with existing working groups - ALTO, I2RS);

- Mechanisms for instance deployment reflecting resilience requirements (e.g. distribution of instances across different VMs or hypervisors);

- Explore and document requirements for reliable transport of traffic and security mechanisms between VNF pools, and reliable and secure control of VNF pools.

We have established that for some use cases (Virtualisation of Mobile Core Network and IMS (vEPC & vIMS), Virtualisation of the Home Environment (vHome), Virtualisation of Content Distribution Network (vCDN)) there will also be specific resilience requirements, when relevant to the SFC WG, i.e., traffic steering between (virtual) network function nodes, these application specific requirements may require co-operation (via requirements or problem statement I-Ds between vnfpool and SFC WG). 

Br, Dan. 

-----Original Message-----
From: vnfpool [mailto:[e-mail]] On Behalf Of Melinda Shore
Sent: 21 January 2014 18:39
To: [e-mail]
Cc: [e-mail]
Subject: Re: [vnfpool] Overlap with SFC?

Hi, Adrian:

The vnfpool proposal is quite narrowly focused on redundancy mechanisms for virtualized network functions.

Melinda


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

"Software longa, hardware brevis."
_______________________________________________
vnfpool mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/vnfpool
_______________________________________________
vnfpool mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/vnfpool