Re: [vnfpool] comment on draft-zong-vnfpool-problem-statement

[Marco Liebsch <[e-mail]>]

Hi Ning,

thanks a lot for your fast response. Please see inline.

From: Zongning [mailto:[e-mail]]
Sent: Freitag, 25. April 2014 08:31
To: Marco Liebsch; [e-mail]
Subject: 答复: comment on draft-zong-vnfpool-problem-statement

Hi, Marco,

Please see inline my reply.
Considering the list feedback, I will update 4th version to 5th version (with trivial changes) by early next week, to make our scope more clear.



Hi Ning, all,



please find some more feedback to the 4th revision of the VNFPool PS draft below. It's more
about a clarification before I can send more detailed comments on the draft.





The draft clarifies about the technical scope, which I understand is limited to redundancy management
and failover handling within a group of VNFs of the same type, the VNF set.



[Ning] Yes, our current scope is intended to a VNF pool including group of VNF instances of the same type. VNF set is the overall set of VNF instances that can be grouped into multiple VNF pools, with each VNF pool providing a different network function. Another word, our scope is mainly a part of VNF set (a VNF pool), not the whole VNF set.



To coordinate between functions of different pools, the draft introduces the Service Control Entity.

[Ning] Correct.

Does the Service Control Entity play a role in building a single network function, e.g. a firewall,
from function instances of different pools?



[Ning] We assume that Service Control Entity builds a network service composed of different network functions (e.g. firewall, DPI, load balancer) provided by different pools. So, each VNF pool provides different network function. Note that this assumption is mainly to drive general pooling architecture and charter scope. We will consider general solution by releasing such assumption if we identify reasonable use cases. For example, we may consider solution that covers the case that a pool can also provide VNFCs…



[marco] I understand and agree that it’s a good approach to start with a limited scope and consider
VNFPool to operate solely inside a pool. But I have difficulties in seeing how the general solution
can be broadened and associated assumptions are released, as you write, to support a deployment, which
builds a single function from instances of multiple pools. There are associated use cases, e.g. the EPC virtualization.





It does not play a role if the complete firewall functionality is provided by a single VNF of a single Pool.

Is this the assumption for VNFPool?



[Ning] Please see above.



[marco] So, I conclude from above description is does not, since it orchestrates mainly standalone functions
from multiple pools and builds a service package from these functions.



From Fig. 1 of the draft I understand that the complete function (e.g. the firewall), is provided by a single box
above the Virtualization Platform layer. And each box seems to be a virtual machine.



[Ning] One or more VNF instances could be hosted by a single VM. So the box in Fig.1 is not necessarily a VM, although it likely to be true in practice.



This would mean that each VNFPool provides a self-contained function, e.g. firewall, web-service, etc.

There is no functional dependency between VNFs of different Pools. Is this understanding correct?



[Ning] It is correct anyway that there is no functional dependency between VNFs of different pools.



[marco] ok, understood.



My understanding of how a virtualized network function vNF is built is that it comprises multiple

vNF Components (vNFC) of the same (for function-internal load balancing) and of different types.

Each vNFC is instantiated in a separate virtual machine.



[Ning] Yes, I agree with your view on how a VNF is built. As said, we currently assume that a VNF pool contains a number of VNF instances of same functional type (e.g. firewall). We describe general pooling architecture and scope our work based on this assumption.



I am still not sure how to reflect this in VNFPool: It may be details that hide inside a VNF as e.g. depicted in
Fig. 1. In such case, the function-internal architecture made from different vNFCs is not visible to VNFPool.



[Ning] You are right that the VNF-internal architecture about different VNFCs is currently hidden inside a VNF. We choose to start from a single level (VNF level), rather than a hierarchical level including both VNF and VNFCs inside VNF. We will develop general solution to cover both as next step of work, based on further use case study. I hope this is reasonable. :)







I hope my reply helps!





[marco] yes, they help :) Thanks again for your feedback.



marco



Thanks.



-Ning