Hi, Georgios,
>> VNF Set: a general set of VNF instances that can be grouped into multiple VNF pools, where each of these pools provide a different network function.
[Ning]: Yes, we will update PS draft in next revision!
>> The reason of this is that in this way the reliability mechanisms/protocols that will be specified by this WG will be applicable to any type of VNFpool.
[Ning]: We will certainly consider general mechanisms/protocols to cover more cases and types of VNF pool. We can reflect this point in PS draft, but leave the details of solution to next step of work, based on use cases & requirements.
>> You mean that the the reliability mechanims/protocols specified in the VNFpool WG will only have an impact inside a VNFpool and sometimes on the adjacent VNFpools. This is also the reason that the solution scope of this WG is different than other IETF WGs, like the SCF WG.
[Ning] Exactly!
Thanks.
-Ning
·¢ŒþÈË: ***@cs.utwente.nl [mailto:***@cs.utwente.nl]
·¢ËÍʱŒä: 2014Äê4ÔÂ23ÈÕ 14:26
ÊÕŒþÈË: Zongning
³ËÍ: ***@ietf.org
Ö÷Ìâ: RE: Comments on draft-zong-vnfpool-problem-statement-04
Hi Ning,
Thanks for your answers!
Please see in line!
>
________________________________
> Van: Zongning [***@huawei.com]
> Verzonden: dinsdag 15 april 2014 5:56
> Aan: Karagiannis, G. (EWI)
> CC: ***@ietf.org<mailto:***@ietf.org>
> Onderwerp: ŽðžŽ: Comments on draft-zong-vnfpool-problem-statement-04
> Hi, Georgios,
> Appreciate your comments!
> Firstly, let me try to clarify the difference between VNF set and VNF pool. VNF set is just a general set of all the VNF instances. In VNF Pool architecture, all these VNF instances are actually grouped into multiple pools, based on the functions they provided. For example, a VNF set {vFW#1, vFW#2, vLB#1, vLB#2, vLB#3} can be grouped into two VNF pools šC one pool is {vFW#1, vFW#2}, another is {vLB#1, vLB#2, vLB#3}. So, maybe the following definition is better:
> VNF Pool: a group of VNF instances providing the same network function.
> VNF Set: a general set of VNF instances that can be grouped into multiple VNF pools where different pools provide different functions.
Georgios: Okay, I understand! So you mean that a VNF set is always composed of a group of VNF pools. Is it then possible to provide the following small modifictaion to the VNF set definition. Please change to:
VNF Set: a general set of VNF instances that can be grouped into multiple VNF pools, where each of these pools provide a different network function.
> Comment_2 is more interesting (indeed! :)) and related to VNF instance implementation. At this point of time, how about just limiting ourselves to your former case, i.e., VNF instances are identical in a pool. The latter case is actually about further decomposition of VNF instance to more VNF components (VNFCs). I would guess this is more complicated (hierarchical) pooling architecture to be studied later.
Georgios: Okay, but I am in favour of the latter case. The reason of this is that in this way the reliability mechanisms/protocols that will be specified by this WG will be applicable to any type of VNFpool.
> Comment_3 & 4 is about our scope. As emphasized in draft, we mostly consider the reliability (or pooling) inside a VNF. Our scope is still intended on VNF set, but *only* to the extent that it involves reliability impact on adjacent VNF instances in different VNF pools. The coordination traffic between VNFs dealing with reliability can be still invisible to the Service Control Entity, if these messages are directly transferred between adjacent VNF pools. Some use cases in our Use Case I-Ds have shown the benefits of direct communication between pools. You are right in the sense that if such coordination is explicitly managed by the Service Control Entity, other WG(s) could be able to handle it - this will depend on more case study.
> Sorry, but I am not sure I fully understand your first bullet in Comment_3.
Georgios: Okay, I understand!
You mean that the the reliability mechanims/protocols specified in the VNFpool WG will only have an impact inside a VNFpool and sometimes on the adjacent VNFpools. This is also the reason that the solution scope of this WG is different than other IETF WGs, like the SCF WG.
> Comment_5 & 6: Yes, we will improve as much as we could in future revision.
Georgios: Thank you!
Best regards,
Georgios
> Hope my reply helps a little bit. :)
> Please do let me know your further questions/comments.
> -Ning
·¢ŒþÈË: ***@cs.utwente.nl<mailto:***@cs.utwente.nl> [mailto:***@cs.utwente.nl]
·¢ËÍʱŒä: 2014Äê4ÔÂ14ÈÕ 18:41
ÊÕŒþÈË: Zongning
³ËÍ: ***@ietf.org<mailto:***@ietf.org>
Ö÷Ìâ: Comments on draft-zong-vnfpool-problem-statement-04
Hi Ning,
Please note that I have read the current version of the draft.
This version clearer than the previous version of the draft, but IMHO it is still not clear enough.
The main comments that I have are:
Comment_1: It is not clear what are the main differences between a VNF set and a VNFpool.
From what I can assume is that the VNFpool is a group of VNF instances that are providing the same network function and that the VNF set is a group of VNF instances, each providing a different network function, which can be used to build network services. Is this correct?
In the Terminology section you provide the following definitions:
VNF Pool: a group of VNF instances providing the same network
function.
VNF Set: a group of VNF instances that can be used to build network
services.
Maybe the following definitions might provide a clearer view:
VNF Pool: a group of VNF instances providing the same network
function.
VNF Set: a group of VNF instances, each providing a different network function,
which can be used to build network services.
Comment_2: This comment is related to VNFpool and in particular what is meant by: VNF instances providing the same network function? Are you referring to identical VNF instances that are providing the same network function, i.e., virtualized instances of the same network function, or does this definition allow to use VNF instances that are not identical, but when they are used together they form one virtualized network function.
An example of the latter will be to virtualise a server, where the VNF of this server will be composed by a virtualized instance of the used protocol stack, a second virtualized instance of the application running on the server and a third virtualized instance of the data base used by the server. Are you considering this composition of this VNF also a VNF pool?
Comment_3: The problem statement is IMHO not clear. One of the reasons of this fact is that the definition of the VNF pool and the VNF set is not clear enough, see previous two comments. Other reasons are related to the fact that the draft does not clearly explain:
o) why is the reliability challenge mentioned in this draft different than the reliability challenges and their solutions used for the physical devices that are providing the same network function(s) as the mentioned VNF(s), in this draft, are providing.
o) why is the reliability challenge that needs to be solved by the VNFpool (future) WG cannot be solved by the currently existing IETF WGs, such as SFC. The reasons given in Section 6.3 are a bit contradictory. One of the reasons provided in that section is is that the reliability mechanisms in VNFpool are mostly internal to VNF, while another reason, given in the same section, is that the reliability mechanism deals with adjacencies in the VNF set. The latter shows that the mechanisms are not internal to a VNFpool. Please clarify!
Comment_4: Please clarify whether the scope of the reliability solution is only limited within a VNF pool, or is it limited within a VNF set? If the scope is limited to a VNF set, then why are you emphasizing that the reliability mechanisms will not be visible to an SFC like control entity, since a VNF set could form a service function chain, see Figure 2 of the draft.
Comment_5: The draft needs to be more consistent on when the VNF set is used and when the VNF pool is used.
Comment_6: There are also some editorial which need to be worked out in a next version of the draft.
Best regards,
Georgios
________________________________
Van: vnfpool [vnfpool-***@ietf.org] namens Zongning [***@huawei.com]
Verzonden: donderdag 10 april 2014 5:21
Aan: ***@ietf.org<mailto:***@ietf.org>
Onderwerp: [vnfpool] New revision of VNFPool Problem Statement posted
Hi, folks,
The new revision (-04) of VNFPool Problem Statement I-D is available on the below page.
https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/
Here are the major changes:
1) Clarify VNFPool architecture and intended scope.
1. Add new section of VNF Pools before the section of Problem. This new section is mainly to outline our scope based on high level description of VNF Pools architecture.
2. Add text to clarify that we are specifically concerned with reliability (e.g. redundancy model, state sharing) that is managed inside the VNF. We are only concerned with the whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of different VNFs.
3. We focus on reliability mechanisms based on VNF pool. Other VNF management aspects such as scaling, load balancing are out of scope.
2) Update terminologies to define Service Control Entity, and delete Pool User as the pool will be internal to VNF only.
3) Re-arrange the text in section of Problems.
4) Update text of VNF instance performance degradation in section of Problems.
5) Update text of Reliable Transport in section of Problems.
6) Add text to explain why service availability is not in scope in section of Problems.
7) Re-write the section describing the relationship of VNFPool and SFC.
8) Add text of transfer of security states in section of Security Consideration.
We hope that the changes have addressed most of the comments, and reflected most of the suggestions during London BoF.
Please review this new revision. Your further comments and suggestions are highly appreciated!
Thanks.
-Ning