On Mon, Oct 6, 2014 at 4:16 PM, Tom Herbert <[email protected]> wrote: > On Mon, Oct 6, 2014 at 1:43 PM, Behcet Sarikaya <[email protected]> > wrote: >> On Mon, Oct 6, 2014 at 3:00 PM, Tom Herbert <[email protected]> wrote: >>> On Mon, Oct 6, 2014 at 12:41 PM, Linda Dunbar <[email protected]> >>> 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) >> >> >> Is this a comment on draft-sarikaya-nvo3-vmm-dmm-pmip-03.txt? >> > > i don't know... > > Consider in Iast week's Interim meeting I described the "virtualizing > existing jobs" use case of networking virtualization. In this model, > we would like to be able to migrate existing jobs between servers. For > the networking part of this, we need to migrate addresses and and > connection state. These jobs don't run in VMs, they run in the host's > stack with some sort of containerization. While job is not migrating > there is no impact, performance and behavior are unchanged. At most we > need to perform encapsulation, but we may even be able to obviate that > with some create use of IPv6 addressing (Identifier/Locator). > > Is this use case considered in your draft?
Has this problem been addressed in PS draft (draft-ietf-nvo3-overlay-problem-statement)? VM mobility is addressed there. Do not worry about the acronyms pmip, dmip, etc. in the draft. If I understand what you are talking about I can better provide an opinion. To me address mobility is vm mobility, what is the difference? Is there a draft? > > Side note on your draft: From the introduction "Currently these > networks are organized as one large Layer 2 network in a single > building". I don't believe this is universally true and I hope it's > not a fundamental design point, there are Layer 3 switched data center > networks. Yes, you are right. Regards, Behcet > > Thanks, > Tom > >> Regards, >> >> Behcet >>> >>> Tom >>> >>>> >>>> >>>> Linda >>>> >>>> >>>> >>>> From: nvo3 [mailto:[email protected]] 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:[email protected]] On Behalf Of Black, David >>>>> Sent: Friday, October 03, 2014 8:15 PM >>>>> To: Tom Herbert >>>>> Cc: [email protected] >>>>> 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:[email protected]] >>>>>> Sent: Friday, October 03, 2014 9:04 PM >>>>>> To: Linda Dunbar >>>>>> Cc: [email protected]; 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 <[email protected]> >>>>>> 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: [email protected] [mailto:[email protected]] >>>>>> > 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 >>>>>> > [email protected] >>>>>> > https://www.ietf.org/mailman/listinfo/nvo3 >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> _______________________________________________ >>> nvo3 mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
