Subject: [OPSAWG] FW: New Version Notification for draft-song-opsawg-virtual-network-function-config-00.txt

From: "Songhaibin (A)" <[email-masked]>
Date: Mon, 9 Sep 2013 03:59:32 +0000

Hi guys,

Here is a new draft on virtual network function configuration. Any comments are welcome!

BR,
-Haibin
Huawei Technologies Co., Ltd.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, September 06, 2013 9:29 AM
To: Songhaibin (A)
Subject: New Version Notification for draft-song-opsawg-virtual-network-function-config-00.txt

A new version of I-D, draft-song-opsawg-virtual-network-function-config-00.txt
has been successfully submitted by Haibin Song and posted to the
IETF repository.

Filename:	 draft-song-opsawg-virtual-network-function-config
Revision:	 00
Title:		 The Problems of Virtual Network Function Configuration
Creation date:	 2013-09-06
Group:		 Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-song-opsawg-virtual-network-function-config-00.txt
Status:          http://datatracker.ietf.org/doc/draft-song-opsawg-virtual-network-function-config
Htmlized:        http://tools.ietf.org/html/draft-song-opsawg-virtual-network-function-config-00

Abstract:
   This document describes the problem space of remote service
   installation and configuration in the provider's network through a
   centralized management system.  This is a typical scenario for
   virtual function installation and dynamic configuration in network
   function virtualization (NFV) context.  It is also a typical scenario
   in cloud computing environment where end users do not have to install
   applications in their end hosts, but can install their own featured
   powerful software application in the cloud.  This specification also
   identifies the scope that needs standardization based on the
   problems.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Cao,Zhen" <[email-masked]>
Date: Tue, 10 Sep 2013 10:46:23 -0400

Thanks for the draft. I have some comments as 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
2. service elasticity requirements should be specified by the user
3. in addition to software versions, the user also want to specify the
operating system versions.

   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.

==quote
4.  Scope for Standardization

   (1) A protocol between the user and controller for software
   installation components choices, dynamic service configuration
   through the controller, and the resource requirements for the
   installation.

   (2) A protocol between software vendor and the controller for the
   detailed description of the software components and the recommended
   resource requirements for service instance.

[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).

On Sun, Sep 8, 2013 at 11:59 PM, Songhaibin (A) <[email-masked]> wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Songhaibin (A)" <[email-masked]>
Date: Wed, 11 Sep 2013 02:19:43 +0000

Hi Cao Zhen

Thank you for your excellent comments! Please see my reply inline.

-----Original Message-----
From: Cao,Zhen [mailto:[email-masked]] 
Sent: Tuesday, September 10, 2013 10:46 PM
To: Songhaibin (A)
Cc: [email-masked]
Subject: Re: [OPSAWG] FW: New Version Notification for draft-song-opsawg-virtual-network-function-config-00.txt

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.

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?

[Haibin] I agree. That's part of the installation environment requirement.

[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?

==quote

[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?

Very good feedback, thank you again!

Regards!
-Haibin

---

From: "Cao,Zhen" <[email-masked]>
Date: Sun, 15 Sep 2013 22:21:03 -0400

More comments inline below.

> [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 conditi…

[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 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…

[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.

> [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…

[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] 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 VN…

[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.

---

From: "Songhaibin (A)" <[email-masked]>
Date: Wed, 18 Sep 2013 07:15:12 +0000

Hi Cao Zhen,

See inline.

-----Original Message-----
From: Cao,Zhen [mailto:[email-masked]] 
Sent: Monday, September 16, 2013 10:21 AM
To: Songhaibin (A)
Cc: [email-masked]
Subject: Re: [OPSAWG] FW: New Version Notification for draft-song-opsawg-virtual-network-function-config-00.txt

[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.

[Haibin] OK.

[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

---

From: "Cao,Zhen" <[email-masked]>
Date: Mon, 23 Sep 2013 09:29:32 +0800

Hi Haibin,

Inline please.

> [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…

[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?

> [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