David, Replies are inserted below:
From: David Allan I [mailto:[email protected]] Sent: Monday, October 06, 2014 6:52 PM To: Linda Dunbar; Tom Herbert Cc: Black, David; [email protected] Subject: RE: Solutions for resolving access domain's VLAN-ID conflict ( was name poll for draft-merged-nvo3-vm-mobility-scheme -00.txt) 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? [Linda] Thanks for the suggested wording. I changed the text to the following. Is it more clear? To describe the solution more clearly, here are the terminologies used: - Customer administered VLAN-IDs (usually hard coded in a TS’s Guest OS and can’t be changed when the TS move from one NVE to another). Some TSs may not have VLAN-ID attached. - Provider administered VLAN-IDs of local significance, and - Provider administered VN-IDs of global significance. In the scenario where there are provider administered VLAN-IDs of local significance (e.g. NVE in a TOR), the value is selected by NVA from the pool of unused VIDs when the first local TS of a VN is being added, and returned by NVA to the unused pool of VLAN-IDs when the last TS leaves. For TSs with hard coded VLAN-ID, it is necessary for an entity, most likely the first switch (virtual or physical) to which the TS is attached, to change the locally administered VLAN-IDs to the TSs’ hard coded VLAN-IDs. For un-tagged TSs, the first switch has to remove the locally administered VLAN-IDs before sending packets to TSs. The section is intended to describe: · NVA manages unused VLAN-IDs pool in each access L2 domain · NVE reports to NVA when first local TS of a VN is reachable, or none of TS in a VN is reachable by the NVE · NVA can push the global VN ID <-> locally administered VID mapping to NVE, or NVE can pull upon detecting a newly attached VN. · NVA manages the first switch to which TS is attached on mapping between TS’s own VLAN-ID and “locally administered VID”. 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. [Linda] When VMs don’t move, the “locally administered VID <-> TS’s VID” mapping is static. With VMs moving around, some VIDs being freed up and reassigned, the mapping becomes dynamic. The entity, most likely the first switch (virtual or physical) to which the TS is attached, need to interface with NVA to get the proper mapping when new VMs is attached. [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. [Linda] Thanks. I added a section on “Managing duplicated addresses” with the following words: This document assumes that during VM migration a given MAC address within a VN can only exist at one TS at a time. As TSs move around NVEs, it is possible that the network state may not be immediately synchronized. It is important for NVEs to report directly attached TSs to NVA on periodically bases so that NVA can generate alarms and fix duplicated address issues. Thank you very much for the suggestions. Linda 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
