David, Thanks for the comments. Replies are inserted below in Maroon.
From: David Allan I [mailto:[email protected]] Sent: Monday, October 06, 2014 3:53 PM To: Linda Dunbar; Tom Herbert Cc: Black, David Subject: RE: [nvo3] Poll for a better name for draft-merged-nvo3-vm-mobility-scheme-00.txt Point taken, given multiple solutions are presented even for a single technology, I still think “framework” would be appropriate. As for VLAN ID conflict, VLAN uniqueness in a given administrative domain, and VID translation between domains is so well understood I’m surprised it is an issue that needs more than a couple of sentences. It would be table stakes for any approach. [Linda] VID translation is not an issue. The draft describes a way for NVA to notify NVEs how to map a given VN to a local VID, when to free a VID, etc. The local VID for a given VN can be changing. NVE needs to free up VIDs when there is no VMs underneath under the VIDs.. When the VN is re-connected to the NVE, a different available VID is assigned. To support tens of thousands of virtual networks, the local VID associated with client payload under each NVE has to be locally significant. Therefore, the same L2-based VN MAY have either the same or different VLAN-IDs under different NVEs. I know it is also bleedingly obvious, but the document never says addresses cannot be in two places at once. At least not that I could find ;-) [Linda] Thank you very much for pointing out this. Are you saying that we should have a requirement/assumption that one address can only be attached to one NVE? Do you think adding one assumption at the beginning of the draft to state “we assume that one host can only be attached to one NVE” is good enough? Or are you suggesting that the draft needs to address detecting duplicated addresses under different NVEs? And one last thing… The sentence in 5.2 “When a VM of a given VN is moved into a NVE for the first time (i.e. the NVE didn't have any VMs belonging to this VN yet), the NVA will notify the NVE for it to be connected to VN. IMO is a problem. As phrased seems to explicitly couple things that do not have to be coupled as well as treating migration as some sort of special case. “When an NVE needs to support connectivity to a VN not currently supported (as a result of VM turn up, or VM migration), the NVA will push the necessary VN information into the NVE.” Seems to cover the waterfront… [Linda] Thank you very much for the suggestion. Your suggested wording is definitely much more clear. I will take your suggested wording. Cheers Dave From: Linda Dunbar [mailto:[email protected]] Sent: Monday, October 06, 2014 1:22 PM To: David Allan I; Tom Herbert Cc: Black, David; [email protected]<mailto:[email protected]> Subject: RE: [nvo3] Poll for a better name for draft-merged-nvo3-vm-mobility-scheme-00.txt Dave, Thank you very much for the suggestion. I thought about a title along the line with what you suggested, but then realized it wasn’t accurate for the following reasons: · For those three issues: Default Gateway, Triangular routing, and Layer 2 extension, both NVA based solution and E-VPN based solution are feasible (and are described by the draft). · For VLAN-ID conflict issue in multiple L2 access domains, only NVA based solution is described. · Based on what Tom suggested, we are adding L3 address mobility, which will not be based on E-VPN. Linda From: David Allan I [mailto:[email protected]] Sent: Monday, October 06, 2014 2:59 PM To: Linda Dunbar; Tom Herbert Cc: Black, David; [email protected]<mailto:[email protected]> Subject: RE: [nvo3] Poll for a better name for draft-merged-nvo3-vm-mobility-scheme-00.txt IMO “EVPN VM mobility framework” would be a significantly more accurate title… Cheers Dave From: nvo3 [mailto:[email protected]] On Behalf Of Linda Dunbar Sent: Monday, October 06, 2014 12:41 PM To: Tom Herbert Cc: Black, David; [email protected]<mailto:[email protected]> Subject: Re: [nvo3] Poll for a better name for draft-merged-nvo3-vm-mobility-scheme-00.txt 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? 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]<mailto:[email protected]>] On > Behalf Of Black, David > Sent: Friday, October 03, 2014 8:15 PM > To: Tom Herbert > Cc: [email protected]<mailto:[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]<mailto:[email protected]>] >> Sent: Friday, October 03, 2014 9:04 PM >> To: Linda Dunbar >> Cc: [email protected]<mailto:[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]<mailto:[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]> >> > [mailto:[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<http://tools.ietf.org>. >> > >> > The IETF Secretariat >> > >> > _______________________________________________ >> > nvo3 mailing list >> > [email protected]<mailto:[email protected]> >> > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
