Subject: [OPSAWG] Comments and questions on draft-gu-opsawg-policies-migration-00

From: Hidetoshi Yokota <[email-masked]>
Date: Mon, 11 Jul 2011 09:21:57 +0900

Hi Gu,

Policy migration according to the movement of VMs is interesting and
will become more important for flexible operations in Data Center. The
scenarios in the draft such as ACL or VLAN information migration
are all valid for such operations.

One aspect that I would like to point out is that the migration of these
policies needs to be synchronized among devices such as the servers
where VMs are running, switches or routers holding the VLAN tables or
ACLs. I think that there should be a node or device that organizes the
migration of those policies and I guess the "3rd-party device" in the
draft takes that role. My question is how this migration is synchronized
among those devices and how this 3rd-party device is involved e.g., from
the perspective of the protocol to use. Maybe,
"draft-yokota-opsawg-virtnw-service-management-01" could be a
complementary I-D to realize your scenarios.

Another aspect is security among those devices. Do you have any
assumption on what to use to establish and maintain security?

Regards,
-- 
Hidetoshi

---

From: Melinda Shore <[email-masked]>
Date: Sun, 10 Jul 2011 20:42:37 -0800

> are all valid for such operations.

I agree, although I think that one of the key distinctions
being drawn in the document and that really needs to be
underscored is that there's a distinction between the kind
of information that can be provisioned statically (and which
might include ACLs and VLANs) and that which might be more
accurately described as stream-associated state.

Overall I think this is a very strong document.  There are
some language issues but the intent is still very clear.
One area that I think could benefit from more attention in
later revisions is introducing different models for moving
what we'll call "state" associated with a network flow when
the VM migrates.  Possible models including moving the state
directly between the middleboxes, which has some clear
problems around topology and "findability," and routing
it through an intermediary associated with the VM, which
"knows" the VM is being migrated and can do some exploratory/
signaling messaging.  That could be a hypervisor, for
example.  Or, the whole question of runtime state could
be punted and the focus could remain on more static policies.

I think it's useful work, and interesting, and that this
document could form the basis for future work.  I don't
think the fact that there's been some misbehavior around
cloud activities should be held against these authors - this
document describes a real problem and provides a good
start at laying out a framework.

Melinda

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Mon, 11 Jul 2011 16:37:02 +0800

Hi Yokota,
Thank you very much for the comments.
As for synchronization, I agree with you. In section 5.1 of problem
statement draft, we have pointed out that the network side need to know a
key status of VM migration, i.e. the beginning of VM not running on source
location. We need to get the status in order to trigger policies migration
on network devices. 
Your proposal is one way to get the status. Manager node gets the status of
VM, and then the status is distributed to network side. I can also envision
other ways to achieve this goal. Please refer to the solution survey draft
which is at
http://tools.ietf.org/id/draft-gu-opsawg-policies-migration-solution-survey-
00.txt
Hope to hear your comments on the potential solutions.

As for security, it is one of the key issues to solve this problem. It
depends on what kind of solutions, distributed or centralized, we finally
adopt. If it's distributed, we need to establish authentication mechanism
between each pair of migration partners. We may use the authentication
mechanism introduced in MIDCOM, and we need to develop this mechanism in
detail.
If it's centralized or middle solution, introduced in solution survey draft,
what we need to do is establish authentication mechanism between network
devices and the centralized entity (named as COORDINATOR in the draft). We
may use AAA protocols. 
Do you think this is reasonable?

Hope we can work together on this problem.

Best Regards
Gu Yingjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
Hidetoshi Yokota
发送时间: 2011年7月11日 乐乐8:22
收件人: [email-masked]
主题: [OPSAWG] Comments and questions on
draft-gu-opsawg-policies-migration-00

Hi Gu,

Regards,
-- 
Hidetoshi

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Mon, 11 Jul 2011 17:40:49 +0800

Hi Melinda,
Thank you very much for your comments and support.

Your opinion of the distinction between static policies and dynamic state is
right. Static policies are not time-sensitive and, as long as they are
migrated and enabled on destination devices before VM start to run on
destination location, the running services won't be significantly
influenced. But dynamic policies/states are time-sensitive, and they must be
migrated at certain time. So I think it's reasonable to distinct the
solutions for these two kinds of policies. Static and dynamic policies could
be migrated using the same architecture but with different mechanisms. 

The possible models you have mentioned are exactly what we have envisioned
in solution survey drafts, i.e. the distributed solution for moving state
directly between network devices, and the centralized / middle solution take
advantage of a intermediate entity to facilitate topology awareness and
findability. We have conclude the pros and cons of each possible models. 

And thank you for pointing out that our proposal is based on a concrete and
real problem, and we take this proposal to IETF because we think it's
concrete enough and is in IETF's scope. We hope to find out whether more
people would like to work together on it. We really don't want to waste
people's time on identifying possible problems in a wide area. 

Best Regards
Gu Yingjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
Melinda Shore
发送时间: 2011年7月11日 乐乐12:43
收件人: Hidetoshi Yokota
抄送: [email-masked]
主题: Re: [OPSAWG] Comments and questions on
draft-gu-opsawg-policies-migration-00

Melinda