On Mon, Oct 6, 2014 at 12:41 PM, Linda Dunbar <linda.dun...@huawei.com> wrote: > Tom, > > Are you saying that the term “VM” should only be described in motivation and > the proposed scheme should work for address mobility enabled by any methods? > Yes, that is my hope, with the constraint that this solution is for address mobility in realm DC network virtualization (i.e. this should not be reinventing mobile IP for instance)
Tom > > > Linda > > > > From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Tom Herbert > Sent: Monday, October 06, 2014 2:16 PM > > While it's a better title, I think my comment was meant to be more general. > VMs (and hypervisors) are references to specific mechanisms of server > virtualization, but not the only mechanisms that can be deployed (e.g. > container virtualization is not normally a VM and does not have an explicit > hypervisor). VM is really just one use case of network virtualization and > not in itself a networking term, so I think that mechanisms or protocols for > network virtualization really should be described without reference to VMs > unless there really is something VM specific about that. > > > > > > > > > > Tom > > >> Anyone has better suggestions? >> >> >> Thank, Linda >> >> -----Original Message----- >> From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Black, David >> Sent: Friday, October 03, 2014 8:15 PM >> To: Tom Herbert >> Cc: nvo3@ietf.org >> Subject: Re: [nvo3] FW: New Version Notification for >> draft-merged-nvo3-vm-mobility-scheme-00.txt >> >>> I would suggest that "Address mobility scheme" might be a better >>> title. VM migration is one instance of when we need address mobility, >>> but we'll need this in with container migration or when we just want >>> to move an virtual address between servers. >> >> I agree, and I think Larry pointed this out earlier. >> >>> Also, w.r.t. VM or >>> container migration, addresses are not the only networking state we >>> need to consider, we need consider how to move connection state (e.g. >>> open TCP connections bond to the address being moved)-- this seems to >>> be out of scope for this draft. >> >> OTOH, I would caution about getting too involved in this as both ends of >> the spectrum of connection state preservation are reasonable and used in >> practice: >> >> - VM live migration preserves TCP connections and the like. >> - IP address takeover on hardware failure doesn't preserve >> anything whose state was solely on the hardware that's now a >> smoking pile of parts. >> >> Thanks, >> --David >> >>> -----Original Message----- >>> From: Tom Herbert [mailto:therb...@google.com] >>> Sent: Friday, October 03, 2014 9:04 PM >>> To: Linda Dunbar >>> Cc: nvo3@ietf.org; Larry Kreeger (kreeger); Black, David >>> Subject: Re: [nvo3] FW: New Version Notification for >>> draft-merged-nvo3-vm- mobility-scheme-00.txt >>> >>> On Fri, Oct 3, 2014 at 10:22 AM, Linda Dunbar <linda.dun...@huawei.com> >>> wrote: >>> > As NVO3 new charter encourage solutions proposals, we added more >>> comprehensive solutions for the issues described in the >>> draft-ietf-nvo3-vm- mobility-issues. We now call it >>> "draft-merged-nvo3-vm-mobility-scheme-00" >>> > >>> I would suggest that "Address mobility scheme" might be a better >>> title. VM migration is one instance of when we need address mobility, >>> but we'll need this in with container migration or when we just want >>> to move an virtual address between servers. Also, w.r.t. VM or >>> container migration, addresses are not the only networking state we >>> need to consider, we need consider how to move connection state (e.g. >>> open TCP connections bond to the address being moved)-- this seems to >>> be out of scope for this draft. >>> >>> Tom >>> >>> > Comments and suggestions are greatly appreciated. >>> > >>> > Linda >>> > >>> > -----Original Message----- >>> > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] >>> > Sent: Friday, October 03, 2014 12:18 PM >>> > To: Rahul Aggarwal; Wim Henderickx; Ravi Shekhar; Luyuan Fang; Linda >>> > Dunbar; >>> Rahul Aggarwal; Luyuan Fang; Wim Henderickx; Ravi Shekhar; Yakov >>> Rekhter; Yakov Rekhter; Linda Dunbar; Ali Sajassi; Ali Sajassi >>> > Subject: New Version Notification for >>> > draft-merged-nvo3-vm-mobility-scheme- >>> 00.txt >>> > >>> > >>> > A new version of I-D, draft-merged-nvo3-vm-mobility-scheme-00.txt >>> > has been successfully submitted by Linda Dunbar and posted to the >>> > IETF >>> repository. >>> > >>> > Name: draft-merged-nvo3-vm-mobility-scheme >>> > Revision: 00 >>> > Title: NVO3 VM Mobility Scheme >>> > Document date: 2014-10-03 >>> > Group: Individual Submission >>> > Pages: 24 >>> > URL: >>> > http://www.ietf.org/internet-drafts/draft-merged-nvo3-vm- >>> mobility-scheme-00.txt >>> > Status: https://datatracker.ietf.org/doc/draft-merged-nvo3-vm- >>> mobility-scheme/ >>> > Htmlized: >>> > http://tools.ietf.org/html/draft-merged-nvo3-vm-mobility- >>> scheme-00 >>> > >>> > >>> > Abstract: >>> > This document describes the schemes to overcome the network-related >>> > issues to achieve seamless Virtual Machine mobility in the data >>> > center and between data centers. >>> > >>> > >>> > >>> > >>> > 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 >>> > >>> > _______________________________________________ >>> > nvo3 mailing list >>> > nvo3@ietf.org >>> > https://www.ietf.org/mailman/listinfo/nvo3 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
