Subject: [OPSAWG] Comments on draft-yokota-opsawg-virtnw-service-management-01

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Mon, 04 Jul 2011 16:50:26 +0800

Hi all,

I go through the draft and I have some comments on the draft.

In general, I think this a good topic in Data Center technologies. What's
interesting is that we have submitted a series of drafts which are also
related to service/applications/VM migration, from Network side's
perspective. In order to perfectly resolve the seamless migration of
service/app/VM, we have to consider both server side and network side.

The following are the comments for the draft.

1.    I think the draft introduces what should be done by communication
between manager and execution nodes, but is lack of why we need to make it a
standard. I guess the communication between these two nodes are similar to
VMWare vCenter and it's virtualization platform. And other virtualization
platforms have their APIs between manager and platform. You may give some
reasons why we need to make a standardized API or protocol.

2.    Should the communication between manager and execution nodes be API or
Protocol? Why you choose protocol instead of API?

3.    Description of Manager Node in section 3: Editor's note: Should the
Manager of managers (hierarchical structure for manager nodes) be included
in the architecture? 

Personally, I would say that we don't need to take this into account, though
I agree that distributed management is possible. The mechanism for
distributed management could be complex, and, no matter distributed or
centralized, it's transparent to users and transparent to execution nodes.
So why bother leading yourself into complex definition of distributed
communication between manager nodes, which is not mandatory

4.    Execution Node ID: You may need to give more consideration to this ID
as well as Function ID. Should this be global unique or unique in a
management domain? 

5.    The management not only apply to Function and session migration, it
also apply to VM migration, with all the functions and sessions on the VM is
migrated. When I read Function and session migration, I imaged a scenario
that Functions are migrated to another VM but the original VM doesn't
migrate. I can't imagine in which situation that we need to migrate
functions from one VM to another. Could you give some examples?

6.    In section 4, bullet 2. You said IP address and/or data-link address
may change. I have some consideration. Currently the IP address of
VM/applications should be remain the same when migration happens, so that
the running services/apps can continue without significant disruption. This
is why most VM migration is limited into one subnet. But I agree that if
protocols like HIP and LISP are applied, IP address and ID are separated,
this is possible. And personally I hope we can find some way to make it
possible, i.e. IP address can change during migration and running services
are not disrupted. 

7.    In section 4, bullet 4: security and reliability. This is very
important, and I suspect you need the cooperation from network side. I mean
this can not be resolved only by communication between manager and
virtualization platform, because the information on network also need to
migrate with the VM/functions. That is part of what I want to resolve in my
drafts.

Please refer to the following drafts to learn what the network side needs to
do for service/app/VM migration. 

 <http://tools.ietf.org/id/draft-gu-opsawg-policies-migration-00.txt>
http://tools.ietf.org/id/draft-gu-opsawg-policies-migration-00.txt

<http://tools.ietf.org/id/draft-gu-opsawg-policies-migration-solution-survey
-00.txt>
http://tools.ietf.org/id/draft-gu-opsawg-policies-migration-solution-survey-
00.txt

<http://tools.ietf.org/id/draft-wang-opsawg-policies-migration-gap-analysis-
00.txt>
http://tools.ietf.org/id/draft-wang-opsawg-policies-migration-gap-analysis-0
0.txt

Hope to hear your comments and suggestion on my drafts.

 

  _____  

Best Regards
Gu Yingjie

---

From: Hidetoshi Yokota <[email-masked]>
Date: Sat, 09 Jul 2011 02:13:13 +0900

Hi Gu,

Thanks a lot for your comments and very sorry for my late response.
Please see inline:

(2011/07/04 17:50), Yingjie Gu(yingjie) wrote:
> In general, I think this a good topic in Data Center technologies. 
> What’s interesting is that we have submitted a series of drafts which 
> are also related to service/applications/VM migration, from Network 
> side’s perspective. In order to perfectly resolve the seamless migration 
> of service/app/VM, we have to consider both server side and network side.

I fully agree with your point. Our draft indeed assumes the situation
where multiple nodes are involved to provide a service and the network
have to cooperate with them for the seamless service mobility.

> 1.I think the draft introduces what should be done by communication 
> between manager and execution nodes, but is lack of why we need to make 
> it a standard. I guess the communication between these two nodes are 
> similar to VMWare vCenter and it’s virtualization platform. And other 
> virtualization platforms have their APIs between manage r and pl reasons 
> why we need to make a standardized API or protocol.

If you look at the client/server model or the manager/managed node
model, the manufacturer of the client and that of the server are often
different (e.g., Web server and browser are provided by different
companies / SNMP manager and routers are provided by different vendors,
etc.). Therefore, it could happen that the manufacturer of the Manager
Node and that of the Execution Node are provided by different vendors.
That situation is more preferable for operators who want to avoid, so
called, "vendor lock-in".

> 2.Should the communication between manager and execution nodes be API or 

That's what the IETF is for. From my understanding, API is more leaning
towards the implementation. Protocol is a common language and is
supposed to be independent of the implementation. This document
specifies the protocol between the Manager and Execution Nodes and
anyone can define the API on his own platform.

> 3.Description of Manager Node in section 3: Editor’s note: Should the 
> Manager of managers (hierarchical structure for manager nodes) be 
> included in the architecture?
> 
> Personally, I would say that we don’t need to take this into account, 
> though I agree that distributed management is possible. The mechanism 
> for distributed management could be complex, and, no matter distributed 
> or centralized, it’s transparent to users and transparent to execution 
> nodes. So why bother leading yourself into complex definition of 
> distributed communication between manager nodes, which is not mandatory

Thanks for your comment. We put it in the editor's note because we want
to hear opinions from the community. So, your comment is very appreciated.

> 4.Execution Node ID: You may need to give more consideration to this ID 

At this point, I would like to say that this ID is unique in the
management domain. But this is still an open issue.

> 5.The management not only apply to Function and session migration, it 
> also apply to VM migration, with all the functions and sessions on the 
> VM is migrated. When I read Functi on and s d a scenario that Functions 
> are migrated to another VM but the original VM doesn’t migrate. I can’t 
> imagine in which situation that we need to migrate functions from one VM 
> to another. Could you give some examples?

VM is one implementation of the Execution Node, but it doesn't have to
be a VM to realize it. As described in Section 3, One use case is IMS,
in which case, the function is CSCF or HSS. If one CSCF is getting
overloaded, you may want to move that CSCF to another Execution Node
with more (computing) resources. You don't need to physically migrate
that CSCF function to the new Execution Node, that is, you can
instantiate a new CSCF at the new Execution Node, but in this case, you
need to migrate all the status from the old Execution Node.

> 6.In section 4, bullet 2. You said IP address and/or data-link address 
> VM/applications should be remain the same when migration happens, so 
> that the running services/apps can continue without significant 
> disruption. This is why most VM migration is limited into one subn 
> rotocols like HIP and LISP are applied, IP address and ID are separated, 
> possible, i.e. IP address can change during migration and running 
> services are not disrupted.

Good point. There are some technologies to preserve the IP address in
use as you mentioned such as HIP or LISP. One important requirement is
that the function doesn't need to be aware of such a protocol. Also, the
ID for the Execution Node should not include the physical address, which
will change if that Execution Node moves to a different physical node.

> 7.In section 4, bullet 4: security and reliability. This is very 
> important, and I suspect you need the cooperation from network side. I 
> mean this can not be resolved only by communication between manager and 
> migrate with the VM/functions. That is part e in my drafts.

Yes, security cannot be provided by itself. Cooperation with the network
or another system such as AAA will definitely be needed. This draft does
not intend to define a new security mechanism, but rather leverages
existing ones.

> Please refer to the following drafts to learn what the network side 
> needs to do for service/app/VM migration.
> 
> <http://tools.ietf.org/id/draft-gu-opsawg-policies-migration-solution-survey-00.txt>
> 
> http://tools.ietf.org/id/draft-wang-opsawg-policies-migration-gap-analysis-00.txt
> 

Thanks for your information. I'll read those drafts and get back to you
as soon as possible.

Regards,
-- 
Hidetoshi

> ------------------------------------------------------------------------
> 
> Best Regards
> Gu Yingjie
>