HI Linda: <snipped> [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. I read the words but cannot quite parse the contents. IMO there are customer administered VIDs (usually hard coded in applications when they exist). Provider administered VIDs of local significance, and provider administered VIDs of global significance. In the scenario where there are provider administered VIDs of local significance (e.g. NVE in a TOR), the value is selected from the pool of unused VIDs when the first local client of a VN is being added, and returned to the unused pool of VIDs when the last client leaves. And as the architecture is defined, the NVA would have a hand in this. Is this what you are referring to? I am curious as to why this figures prominently here, as it is simply normal operation to any VM lifecycle and not unique to VM migration. 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.
Of course… 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? Ethernet does like duplicate MAC addresses in a broadcast domain. So ideally during VM migration a given MAC address within a VN can only exist at one vNIC at a time (the network state may not immediately synchronize, but if the NVEs have a hard and ordered cut over, at least it does not flap). That strikes me as a requirement worth mentioning when discussing solutions for mobility. <snipped to end> 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
