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

From: Marco Liebsch <[email-masked]>
Date: Thu, 24 Apr 2014 09:54:29 +0000

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.
To coordinate between functions of different pools, the draft introduces the Service Control Entity.

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

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?

>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.

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?

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.

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.

In case VNFPool is concerned with the function-internal architecture made from different vNFCs, Section 3.2
may include such figure:

                  +---------+

                  | VNF-C#z |

                  |         |

                  +---------+

                      ^ |

                      | |

                      | |

                      | v

+---------+       +---------+

| VNF-A#x |<------| VNF-B#y |

|         |------>|         |

+---------+       +---------+

                       ^

                       |

                       |

                       |

                       v

                  +---------+

                  | Client  |

                  +---------+

Sorry that I come up with this request for clarification again.

Best regards,

marco

---

From: Zongning <[email-masked]>
Date: Fri, 25 Apr 2014 06:31:12 +0000

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,

[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.

[Ning] Correct.

[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…

[Ning] Please see above.

[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.

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

[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.

[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!

Thanks.

-Ning

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 28 Apr 2014 09:22:10 +0000

Hi Ning,

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

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

Hi, Marco,

Hi Ning, all,

[Ning] Correct.

[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.

[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.

[marco] ok, understood.

I hope my reply helps!

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

marco

Thanks.

-Ning

---

From: Zongning <[email-masked]>
Date: Wed, 30 Apr 2014 08:43:35 +0000

Hi, Marco,

[marco] 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.

[Ning] By looking at the EPC architecture, I don’t see why VNF pool including identical VNF instances cannot be applied. For example, we can use multiple VNF pools – say, one pool for vP-GW instances, one pool for vS-GW instances, another pool for vMME instances, and so on. Another word, vP-GW, vS-GW, vMME, etc. can be VNFs to compose the whole service of vEPC. There is no restriction on how the NFV operator defines VNFs. We will not assume that vEPC is in VNF-level, and P-GW/S-GW/MME are in VNFC-level. On the contrary, by reading the ETSI NFV SWA specification, I believe VNFCs refer to the various software packages implementing (or inside) vP-GW, implementing (inside) vMME, etc. These VNFCs are usually VNF vendor/developer specific, and (to my best knowledge) even ETSI NFV SWA will NOT study details of VNFCs and the interfaces between VNFCs. :)

Maybe we still have some misalignment on the levels of VNF, and VNFC… :)

But anyway, I definitely encourage you and other co-authors to bring various NFV use cases.

Thanks.

-Ning

发件人: Marco Liebsch [mailto:[email-masked]]
发送时间: 2014年4月28日 17:22
收件人: Zongning; [email-masked]
主题: RE: comment on draft-zong-vnfpool-problem-statement

Hi Ning,

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

Hi, Marco,

Hi Ning, all,

[Ning] Correct.

[Ning] Please see above.

[marco] ok, understood.

I hope my reply helps!

marco

Thanks.

-Ning