Hi Cao Zhen, See inline.
-----Original Message----- From: Cao,Zhen [mailto:[email protected]] Sent: Monday, September 16, 2013 10:21 AM To: Songhaibin (A) Cc: [email protected] Subject: Re: [OPSAWG] FW: New Version Notification for draft-song-opsawg-virtual-network-function-config-00.txt More comments inline below. > Comments for section 3 about service configuration problems. > > some more problems from my understanding > 1. service chain requirement could be submitted by the user to the > Controller > > [Haibin] I agree! A user can directly establish a service chain or service > chains. For the service graph, there can be two layers IMO, one is the stable > virtual link layer, and the other is conditional/stable service forwarding > layer. I also noticed that there was a network service chain BOF at last IETF > meeting. But they are focusing on how to identify a service chain and how to > do the forwarding in the service chain. But for the requirement here, we only > want the user the send the description to the controller. > [cz] NSC may have further impacts on the configuration, for example, some functions may be implemented by chaining existing 'atom functions'. What's I am not sure right now the granularity of the vNF configuration, a) user specifies the detailed function, e.g., fw, lb, etc.. b) user specifies the high layer vNF objectives that need chaining of several vNFs... [Haibin] I think both a) and b) should be supported. Different users have different expertise level. And it is also service related. Different VNF providers may have their own policy about whether to allow the users to specifies what you mentioned "atom functions" and to what level. But this is a good point that should be reflected when the document is updated. > 2. service elasticity requirements should be specified by the user > [Haibin] I have some description of this use case in the last paragraph of > Section 1. Just like that the user tells the controller, "allocate resources > on-demand for me". Do you have some good idea in-mind on what are the > elasticity requirements? [cz] there should be some metrics for the "on-demand", because the vNF resource could never be enough based on the available infrastructure. For example, the vFW could be handling 100K transactions at most, sth like this. > > There are also resource requirements for the remote software > installation, which are complement to the software components > selection. There is lack of a standard for a user to tell the > controller how much bandwidth, storage, CPU, memory are allocated to > a specific software in the provider's network (perhaps there is > existing standard for the virtual machine or host level resources), > > [cz] but the Openstack-Neutron have such APIs to specify the user's > request , better to notice the difference here. > > [Haibin] VNF level and VM level are different. Because one VM might be > holding multiple VNFs. That interface you mentioned is combined with a VM IMO > and are not easy to make a change. But here when the resource is combined > with a VNF. It is much easier to change it. Any thoughts? [cz] that's clarifies the difference, i think we should make it clearer how the the configuration differ from the cloud OS interface. Such description above should be stressed. [Haibin] OK. > ==quote > 4. Scope for Standardization > [cz] Envision a picture here. and what's the operator's role in the picture, > i believe the operator-controller interface should also be specified , > maybe add a (3). > > [Haibin] IMO, operator owns the controller. OSS/BSS for the NFV service is > part of the controller. But the network administrator from the operator can > also act as a user to install and configure VNFs in the provider's > (operator's) network for the customers or for himself. This is the picture in > my mind. Is it consistent with what you have in mind? [cz] I believe the controller could be third party SP selling software components for NFV, in this case, there should be the interface for the operator to configure the controller in this architecture. [Haibin] I agree with your point, but I would assume that the controller has already be configured for the problem statement in this draft. Thanks again, -Haibin _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
