Hi Linda, I don't want to respond to proposals for rewording individual sentences at this time because I think it misses the major points of my feedback on the draft which are:
1. There is major overlap with the NVO3 Problem Statement. VM mobility is a main motivating use case in the problem statement. 2. Content related to inter-datacenter issues are not within scope for NVO3. 3. Most if the issues discussed are not specific to VM mobility (they could apply to other types of mobility, such as containers or hot standby switchover of virtual network functions). 4. I don't believe the small amount of remaining non-overlapping and in-charter content will effect the framework, architecture, or intra-datacenter solutions. - Larry From: Linda Dunbar <[email protected]<mailto:[email protected]>> Date: Friday, September 19, 2014 3:53 PM To: Larry Kreeger <[email protected]<mailto:[email protected]>>, Benson Schliesser <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues Larry, Thanks for the feedback. Please let us know if the updated text will address your concerns (marked by [Linda-2]): From: Larry Kreeger (kreeger) [mailto:[email protected]] [Linda] Here are some key points that haven’t been addressed by general NVO3 problem statement: · Optimal routing of a VM's outbound traffic · Optimal routing of VM's inbound traffic LK> Optimal routing (as David pointed out in his comments) is covered in section 3.7 of the problem statement. Can you please re-read that section and let me know the substantial content that is missing from it? [Linda-2] When VMs in a single VN are spread across many different DCBRs, all DCBRs have to announce their directly VMs in order to achieve optimal routing. This approach can dramatically increase the number of routes on routers in the wide area network. · Preserving Policies: allowing VMs migrating across Data Center will require more stringent security enforcement. The traditional placement of security functions, e.g. firewall, at data center gateways is no longer enough. VM mobility will require security functions to enforce policies among east-west traffic among VMs. When VMs move across Data Center, the associated policies have to be updated dynamically and enforced. LK> First, the draft is unclear about what policies need to be preserved. The draft seems to equate policy with a L2 CUG (which you seem to agree is the same as an NVO3 VN), so I'm not clear on what policies are meant beyond the implementation of the VN itself. Also note that section 3.3 of the Framework says "Upon VM mobility, NVE policies that define connectivity among VMs must be maintained." This seems to cover the gist of section 3.5 in the VM mobility issues draft, with the exception that it uses a paragraph to discuss how this is somehow related to the physical L2 domain (which it shouldn't be for an overlay network). [Linda-2] There could be many policies guarding VMs across different VNs, with some being enforced by Firewall, some enforced by NAT/AntiDDOS/IPS/IDS, etc. It is less about NVE polices to be maintained when VMs move, it is more along the line of dynamically changing policies associated with the “middleware” boxes attached to NVEs (if those middle boxes are distributed). · Maintaining Connectivity in the Presence of VM Mobility LK> This seems to be covered in section 3.2 of the problem statement. · Layer 2 Extension LK> The whole motivation of creating an overlay network is to avoid the problems of trying to extend the L2 physical domain, which seems to be the focus of the Layer 2 extension section of this draft. Overcoming the need for L2 extension is covered in section 3.4 of the problem statement. - Larry The document discusses the seamless migration of VMs between two Data Centers. Based on the recent charter discussions, the scope of NVO3 seems to be limited to within a single DC. In that case should discussion of inter-DC VM mobility be removed? [Linda] even within a single DC, you will have problem of VMs migrating across different PODs, which have the same problem of moving across different DCs. LK> I agree, but a significant portion of this document seems to be covering this topic which is out of scope for our charter. [Linda-2] Most large DCs have regular IP interconnecting different PODs. Moving VMs among DCs has same issue of moving VMs among PODs. [Linda] The text is to address issues of today’s L2 network being identified by VLANs. LK> If so, it wasn't clear to me. In that case, it is already covered in section 3.4 of the problem statement. [Linda-2] The Section 3.4 of the problem statement didn’t address scenario when there is a bridged network between NVE and Guest OS (either VM or server) and tenant systems use their own VID (with policies on tenant’s VIDs). Section 3.3 continues this assumption that an L2 CUG is bounded by an L2 physical domain by saying that when a VM moves to a new L2 physical domain "the new L2 physical domain must become interconnected with the other L2 physical domain". Since NVO3 is all about creating an overlay over IP, I don't understand why one would need to extend VLANs from one L2 physical domain to another providing a "Layer 2 Extension". The purpose of using NVO3 overlays is to avoid having to extend L2 physical domains. [Linda] The “L2 physical domain” in the text is about the L2 network attached to NVEs. The overlay is among NVEs. This is another area that hasn’t been covered by the general problem statement. LK> So, then if I understand you, this section is related to the split-NVE case where locally significant VLANs are being used to keep the VN traffic segregated as it flows to an external NVE? If so, that is part of the solution architecture. It also does not seem specific the VM mobility. [Linda- 2] The “split-NVE” is assuming that NVE is directly attached to VMs (Guest OS). When there is a bridged network (virtual switches, blade switch attached to NVE on TOR), additional mechanism is needed for the first hop switch to do the translation (before NVE). Linda On 9/12/14 2:42 PM, "Benson Schliesser" <[email protected]<mailto:[email protected]>> wrote: >Dear NVO3 Contributors - > >This message is to initiate a Working Group Last Call for Comments on >draft-ietf-nvo3-vm-mobility-issues. The chairs believe there is >consensus to submit this draft to the IESG for publication. Please >review it and provide feedback on the mailing list by 19-Sep-2014. > >As a reminder, this is not an opportunity to vote. Please do not post >messages that simply indicate support. Rather, substantial comments and >feedback is encouraged. > >For your convenient reference, the latest version of the draft can be >found at >https://tools.ietf.org/html/draft-ietf-nvo3-vm-mobility-issues-03. > >Thanks, >-Benson & Matthew > >_______________________________________________ >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
