Hi Haibin, Inline please.
On Wed, Sep 18, 2013 at 3:15 PM, Songhaibin (A) <[email protected]> wrote: >> [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. > [cz] it will be a rather complicate architecture for vnf configuration. For ietf, have you figured out what's the gap of protocols that will be needed to support this architecture? > >> 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. > [cz] ok _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
