Subject: [OPSAWG] policies migration discussion

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Jul 2011 09:58:24 +0200

Hi,

I have read the three documents discussing the migration of "policies"
of network elements when virtual machines migrate:

draft-gu-opsawg-policies-migration-00.txt
draft-gu-opsawg-policies-migration-solution-survey-00.txt
draft-wang-opsawg-policies-migration-gap-analysis-00.txt

I think the documents describe a problem worth discussing in order to
figure out whether this is something to work on and how a potential
solution might look like. So I support the request to have one time
slot at the Quebec meeting allocated to discuss this topic.

On the technical side, I have a number of terminology issues, perhaps
since my background is different. In the NETCONF/YANG world, we
distinguish configuration from operational state and that seems to be
roughly what you call static policies and dynamic policies. I also
note that we have policy terminology defined in RFC 3198 and we might
want to be consistent with that as well. I am also not happy with the
way "TCP connection table" is used in slightly different meanings and
NAT have bindings etc. But all this is fixable, the technical problem
I think is worth discussing.

In particular, I miss the idea to potentially migrate configuration
state (static policies) differently from operational state (dynamic
policies). If you assume that is a configuration manager translating
policies from a higher abstraction to concrete device configs, then
such a configuration manager must be involved if configuration state
is modified. For the operational state, I would prefer to think about
what can be done so that proper operational state is picked up again
instead of trying to transfer it. Perhaps guidelines can be written
what VMs might want to do after migration in order to play well in
reestablishing operational state - or the hypervisor could do things
on behalf of the VM. The less communication will be needed between
infrastructure devices, the better we might be doing in terms of
robustness.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 14 Jul 2011 13:29:02 -0800

On 07/13/2011 11:58 PM, Juergen Schoenwaelder wrote:
> since my background is different.

I had the same issue and my background is different yet again.
It might be worthwhile to canonicalize the terminology, but
probably not until there's some level of agreement to do the more
substantive work, as well.

Melinda

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Fri, 15 Jul 2011 13:42:42 +0800

Hi Juergen,

Thank you for reading all the drafts and for your comments.

I will learn RFC3198 and try to make the terminologies in my draft to be
consistent with standard terminologies.

Terminology issues hamper people's understanding on this problem. 

Please see inline for my replies.

Best Regards

Gu Yingjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
Juergen Schoenwaelder
发送时间: 2011年7月14日 乐乐15:58
收件人: [email-masked]
主题: [OPSAWG] policies migration discussion

Hi,

policies). 

Gyj: I put both configuration state and operational state in this draft,
however, I also think that these two state should be solved by different
means. I should clarify this in my draft. Thank you for reminding.

If you assume that is a configuration manager translating

is modified.

Gyj: Maybe not a configuration manager to deal with both configuration state
and operational state. For configuration state, it can be dealt with by
configuration manager. 

For the operational state, I would prefer to think about

instead of trying to transfer it. 

Gyj: could you please give more explanation on ‘pick up operational
state’? what’s the meaning and what’s the benefit compared with
‘transfer operational state’?  

Perhaps guidelines can be written

robustness.

Gyj: I will think about it. Currently, I only see the communication between
centralized COORDINATOR and VM Manager can significantly reduce complicity
and improve robustness. But I am not sure what VM can do.

/js

-- 

_______________________________________________

OPSAWG mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/opsawg

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Jul 2011 08:49:42 +0200

> ‘transfer operational state’?  

Lets take an example. I think you mentioned multicast related state
maintained by bridges snooping multicast joins. Instead of transfering
this state between bridges (which requires changes to bridges), one
could solve this by making sure the hypervisor/vm sends another join
message during the migration process so that the new bridge picks up
the needed operational state. This does not require a new protocol or
any changes to infrastructure, just a bit more smartness on the side
of the hypervisor/vm.

/js

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Fri, 15 Jul 2011 18:12:10 +0800

Got it. 	
Yes, some of the state can be reestablished by Hypervisor, e.g. IGMP and DHCP snooping, some can't. We can classify the policies, to find out which can be assisted by Hypervisor, which must be solved by new mechanism. 

Thank you.

Best Regards
Gu Yingjie

-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:[email-masked]] 
发送时间: 2011年7月15日 乐乐14:50
收件人: Yingjie Gu(yingjie)
抄送: [email-masked]
主题: Re: [OPSAWG] policies migration discussion

/js