[vnfpool] 答复: new VNFPool draft charter

[Zongning <[e-mail]>]

Hi, Qiang,

Thanks for the comments. Please see inline.


-          It is good to narrow down the scope to redundancy module only. I’m assuming that a transparent redundancy module is the preferable solution of this WG. With transparent solutions, no impacts are expected on the pool user. Therefore, I would avoid any linkage with SFC.

[Ning] Yes, the pooling mechanism will be transparent to the pool user. But a VNF including a VNF Pool (we call a VNFPool-enabled VNF) will be used as a normal VNF in a service chain to build a network service. Therefore, from the service orchestration point of view, some features (mostly operational, NOT pooling mechanism) of a VNFPool-enabled VNF such as address/location, load capability, etc., are still needed by the service control entity.


-          I also don’t understand the statement “When a live VNF instance goes out of service, how does the service control entity learn which instance in a VNF Pool will replace it, and learn the characteristics of the new instance?” If transparent solutions are expected, why SCE needs to learn the failover?

[Ning] Excellent point! You are right that this sentence is somehow misleading. How about a new sentence like - “After a VNF instance failover, how does the Pool Manager notify the service control entity some characteristic changes of the VNF, but without disclosure of the pooling procedure?”.


-          There was some discussions in the mailing list regarding the virtualized/non-virtualized case where a network application may run on a server with/without a hypervisor. In both cases (with/without a hypervisor), the application may not have any redundancy solutions. Both cases shall be covered by the solutions provided by this WG. However the charter only have virtualized functions covered. Is the non-virtualized use case out of the scope?

[Ning] I agree with you, Nic and Pedro that the solution should be applicable to non-virtualized function, from the pooling perspective. But, consider that we currently don’t describe any specific solution in the charter, how about add a new sentence like – “VNF Pool composed by both virtualized and non-virtualized functional instances will be included after further use case and requirements study”. With this statement, I’d solicit you all to bring use case and requirement for the pooling of non-virtualized function, to help the future solution developed by the WG to cover both. ☺


-          Some statements, such as “Identify and analyze reliable transport protocols”, sounds like we do have a specific solution already. I won’t assume there is always an IP connection between the pool manager and the pool instance. The interface between the two entities can be a TCP based protocol if there is an IP connection, or it can be an API if they both locate in the same server. It is real dependence on the solutions itself. Besides, if HW redundancy is needed that there may be always a “remote” instance. The question is really how the “remote” instance is handled, by whom; what homogeneity is assumed or whether this should be part of the investigation. If it is expected that the VNF instances of a pool come from different vendors then even the state synchronization becomes an issue. If the pools are expected to be built from identical instances then one questions why should the pool manager come from a different vendor. I won’t want to see any solution limitations at this stage of the discussion. And I prefer to keep it open until the solution discussion phase.

[Ning] I think the statement “Identify and analyze reliable transport protocols” is more like a requirement for the reliable delivery of pooling messages. We give examples of existing IETF solution like MPTCP, but this doesn’t mean we have already determined the solution at this stage. You are right that we are open to solutions and solution discussion will be in next phase.


-          My assumption is that the output from this proposed WG is one or more generic HA solutions. As we are in the early stage of the discussion, I don’t think we shall limit the solution to a specific one. I do have a hard time to understand why the Applicability and Gap Analysis shall be done based on a specific protocol?

[Ning] I believe you had misunderstood the Applicability and Gap Analysis I-D (to RSerPool) at this point. ☺ I think anyone (other than RSerPool folks) can bring their I-D about applicability and gap analysis to solution “x”. Currently we have an I-D based on RSerPool. But this doesn’t mean that the WG will start solution based on RSerPool. We will be looking at more reference solutions and find out which parts of them can be reused/extended/referred/etc.


-          Reading the charter, it is not very clear that what the scope of the VNF is. Is it the service/function, or the entities providing this service/function? Some clarification of this use would be good.

[Ning] In  our charter, a VNF includes a pool of VNF instances implementing a certain function (not a whole service), and a manager to interface with the outside service control entity to provide such function. So I assume a VNF has both roles in your question. Does it make sense? Or you have some suggested text to further clarify this issue? ☺


I hope my reply helps to address your concerns. Otherwise please let me know.

-Ning