[vnfpool] 答复: Updated VNFPool Charter

[Zongning <[e-mail]>]

Hi, Adrian,

Thank you for kindly review. I appreciate the nits correction, and see inline for minor comments.

-----邮件原件-----
发件人: Adrian Farrel [mailto:[e-mail]] 
发送时间: 2014年6月24日 23:27
收件人: Zongning; [e-mail]
主题: RE: [vnfpool] Updated VNFPool Charter

Hi Ning,

I know that there have been some discussions on the list about the draft charter, but I am returning to your clean copy from 12th June.

The charter looks good to me (at least from an RTG perspective). I have some nits and a minor comment below.

Thanks,
Adrian


> with a service control entity. Such a service control entity is an 
> entity that orchestrates a set of network functions to build network services.
> The major benefit of using VNF Pool is that reliability mechanisms 
> such as redundancy model are achieved by the VNF Pool inside the VNF 
> and thus not visible to the service control entity. A VNF Pool-enabled 
> VNF still appears as a normal VNF when orchestrated by a service 
> control entity.

Is this completely how you want it? Isn't there some benefit to a service control entity in knowing that a VNF is protected through a pool compared to unprotected? That is, when a service control entity is selecting between NFV instances it may select according to various factors (such as path length between functions in a chain, and loading of VNF instances) and the knowledge that one VNF instance is protected through an VNV pool may be significant.

So, I think that it is the operation of the VNF pool reliability mechanism that is unknown to the service control entity, but not the fact of reliability.

[Ning] Yes, you are right. A VNF could tell a service control entity that it is protected by a pool for better service orchestration. But this should be based on the negotiation between VNF pool and service control entity. Some control entity may only wants to know if a VNF is reliable or less reliable, without knowing too much about if there is a pool ... Anyway, thank you for suggestion, and we will keep this as an important case during requirement study. :)


> The WG initially focuses on several reliability mechanisms that are 
> mainly associated with a redundancy model based on a VNF Pool.
> Additional mechanisms may include pool state maintenance only for 
> pooling purpose. Service state synchronization is out of scope for 
> this phase. The WG assumes that a VNF Pool contains redundant VNF 
> instances of same functional type. Different types of VNFs are 
> envisioned to be held in separate VNF Pools. VNF Pool composed by both 
> virtualized and non-virtualized functional instances may be included 
> after further use case and requirements study. The WG will address the 
> reliability of an individual VNF, but not the reliability related to 
> the control or the routing between adjacent VNFs that can form a 
> network service.

I wonder whether the charter should be clearer that the VNF pool appears as an instance and that only one instance in a pool is really active. The point here is that the pool is not a set for load balancing across and does not increase the load capacity of the VNF that the service control function can see.

[Ning] You are right that a VNF pool appears as a single instance to outside entity such as service control entity. Regarding the internal model to a VNF pool, I do agree with Lac Chidung that we would not constrain a VNF pool's internal model to have only one active instance. Redundancy model with more than one active instance (e.g. n+k, n:m) is inherent to pooling methodology and will benefit a VNF pool with good flexibility & reliability.


Please let me know your further comments & suggestions.
Thanks.

-Ning