Subject: [OPSAWG] To continue the discuusion on DC management problem with VM hot migrates.

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Thu, 26 May 2011 18:29:08 +0800

Hi all,
After IETF 80 meeting, I presented some challenges to DC management raised by VM Migration. The draft was post at http://datatracker.ietf.org/doc/draft-gu-dc-management-problem-statement/

I have updated the draft according to meeting comments and answers questions raised at meeting. 

You can refer to the slides for quick understanding of the problem.

In order to remind you about the presentation, here is the brief introduction.
"One important feature of VM hot migration is no disruption to running service. When VM in Data Center migrates from one location to another location, not only the OS and software resource on server need to be migrated to new location, but also the polices and dynamic information on network devices need to be migrated. The dynamic information refers to the rules, table items or mapping items, that is generated on network devices when service is running on VM. Examples of dynamic information could be DHCP snooping table items on bridges, dynamic ACLs on firewall and TCP connection table items on proxies. Refer to attached draft for more detail examples and explanation. Without the dynamic information migration, running service on VM will be disrupted. "

Melinda asked, at the meeting, why VM's IP address needs to be kept unchanged, here is my personal understanding:
One requirement of VM hot migration is that the running service should not be disrupted. If IP address changed, the external client who is communicating with this VM won't connect to it any more. So IP address must be kept unchanged. In order to make this possible, most of the VM migration is limited into one subnet. In scenarios of VM migration within a subnet, we may encounter most of the problem presented in the draft.

However, VM could migrate between subnets if we can resolve IP address problem. The benefit of migration between subnets is obvious. It can help to reduce the volume of a single subnet. (Since we can migrate VMs out of or in the subnet, it's not necessary to make a data center with a huge single subnet. A huge subnet implies more challenging management and potential risk.) It can also improve the feasibility of service deployment and can even encourage brand new services in the future. In scenarios of VM migration between a subnet, we may encounter all the problems presented in the draft.

I presented the problem at IEEE 802.1 DCB too, named as 'Dynamic information migration'. The response is quite positive. IEEE 802.1 DCB Task Group would extend VDP protocol to enable hypervisor to notify network side about VM's stop and start status, which will help network devices know when is suitable time to migrate the dynamic information generate on them. And DCB Task Group would like to see further progress at IETF. I was asked to let DCB know further progress at IETF.

We have composed Gap analysis to analyze how we can reuse existing IETF protocols (mainly compare with MIDCOM), will post to IETF. 

I would like to answer any questions and appreciate your comments. 

Best regards
Yingjie

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 May 2011 14:36:30 +0200

Hi Yingjie, 

You wrote that 

> questions raised at meeting.

Was this update posted? What can be seen at http://datatracker.ietf.org/doc/draft-gu-dc-management-problem-statement/ is still the version 00 dated March 7, so before IETF-80.

Thanks and Regards,

Dan 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Yingjie Gu(yingjie)
> Sent: Thursday, May 26, 2011 1:29 PM
> To: [email-masked]
> Subject: [OPSAWG] To continue the discuusion on DC management problem
> with VM hot migrates.
> 
> Hi all,
> After IETF 80 meeting, I presented some challenges to DC management
> raised by VM Migration. The draft was post at
> http://datatracker.ietf.org/doc/draft-gu-dc-management-problem-
> statement/
> 
> "One important feature of VM hot migration is no disruption to running
> service. When VM in Data Center migrates from one location to another
> location, not only the OS and software resource on server need to be
> migrated to new location, but also the polices and dynamic information
> on network devices need to be migrated. The dynamic information refers
> to the rules, table items or mapping items, that is generated on
> network devices when service is running on VM. Examples of dynamic
> information could be DHCP snooping table items on bridges, dynamic ACLs
> on firewall and TCP connection table items on proxies. Refer to
> attached draft for more detail examples and explanation. Without the
> dynamic information migration, running service on VM will be disrupted.
> "
> 
> Melinda asked, at the meeting, why VM's IP address needs to be kept
> unchanged, here is my personal understanding:
> One requirement of VM hot migration is that the running service should
> not be disrupted. If IP address changed, the external client who is
> communicating with this VM won't connect to it any more. So IP address
> must be kept unchanged. In order to make this possible, most of the VM
> migration is limited into one subnet. In scenarios of VM migration
> within a subnet, we may encounter most of the problem presented in the
> draft.
> 
> 
> However, VM could migrate between subnets if we can resolve IP address
> problem. The benefit of migration between subnets is obvious. It can
> help to reduce the volume of a single subnet. (Since we can migrate VMs
> out of or in the subnet, it's not necessary to make a data center with
> a huge single subnet. A huge subnet implies more challenging management
> and potential risk.) It can also improve the feasibility of service
> deployment and can even encourage brand new services in the future. In
> scenarios of VM migration between a subnet, we may encounter all the
> problems presented in the draft.
> 
> I presented the problem at IEEE 802.1 DCB too, named as 'Dynamic
> information migration'. The response is quite positive. IEEE 802.1 DCB
> Task Group would extend VDP protocol to enable hypervisor to notify
> network side about VM's stop and start status, which will help network
> devices know when is suitable time to migrate the dynamic information
> generate on them. And DCB Task Group would like to see further progress
> at IETF. I was asked to let DCB know further progress at IETF.
> 
> We have composed Gap analysis to analyze how we can reuse existing IETF
> protocols (mainly compare with MIDCOM), will post to IETF.
>

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Fri, 27 May 2011 08:58:26 +0800

Hi Dan,
The latest version hasn't be posted. It's under review now and hopefully we can involve more contributors to enrich the draft. 
I attach it to the email just for your information. 

I plan to rename the draft to draft-gu-opsawg-policy-migration-problem-statement-00
so that it could be posted to OPSAWG and can be more consistent with its content. 

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Thursday, May 26, 2011 8:37 PM
> To: Yingjie Gu(yingjie); [email-masked]
> Subject: RE: [OPSAWG] To continue the discuusion on DC management problem
> with VM hot migrates.
> 
> 
> 
> Hi Yingjie,
> 
> You wrote that
> 
> Was this update posted? What can be seen at
> http://datatracker.ietf.org/doc/draft-gu-dc-management-problem-statement/ is still
> the version 00 dated March 7, so before IETF-80.
> 
> Thanks and Regards,
> 
> Dan
>