Larry, See my replies inserted below:
-----Original Message----- From: nvo3 [mailto:[email protected]] On Behalf Of Larry Kreeger (kreeger) Sent: Wednesday, September 17, 2014 6:31 PM To: Benson Schliesser; [email protected] Subject: Re: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues Hi Benson, Linda was supposed to have a slot during last interim conference call "to show substantial content in this draft with regard to VM mobility in DC that are not in the NVO3 problem statement". Linda didn't do this, so I'm not sure why this document is being put up for Last Call. [Linda] It turned out that the NVO3 virtual meeting finished by 11am PST (that is when I was able to join due to my other commitment). Benson suggested me to send out my points in respond to the WGLC. The draft addresses the following part of the charter: "Support the placement and migration of VMs anywhere within the data center, without being limited by DC network constraints such as the IP subnet boundaries of the underlying DC network." It highlights how we should support VM mobility in NVO3 and the issues related to such support Those issues haven't been covered in details by "draft-ietf-nvo3-overlay-problem-statement-04 (RFC queue)". This draft shouldn't be merged with general NVo3 framework nor problem statement draft due to: * The draft emphasizes on detailed issues related to VM mobility beyond the general NVo3 problem statement draft * This topic is big enough to deserve its own place. * Merging those detailed issues make the general draft not readable. I just read through the document again after a long long time and came away scratching my head about its value. I have written down some of my impressions below as I read it, but in summary I'm not convinced that this should be published. It seems to spend a lot of time defining terminology (e.g. Trivial vs non-trival L2 Physical domain) that in the end doesn't seem to have anything to do with an overlay virtual network. I would still like to see Linda's presentation on the "substantial content" that I missed in my reading. [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 * 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. * Maintaining Connectivity in the Presence of VM Mobility * Layer 2 Extension - 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. The document uses the term CUG (Closed User Group) extensively. The problem statement and framework use the term VN (Virtual Network). The framework mentions CUG by saying "A VN is also known as a Closed User Group (CUG)." Given this, I think this document should use the consistent term, VN in placed of CUG. [Linda] We can change CUG to VN. Section 3.1 seems to be equating CUGs to VLANs in an L2 physical domain. I'm not sure what this has to do with NVO3 Overlay VNs. It makes "the assumption that within a given L2 physical domain VLANs are used to identify individual L2-based CUGs". Why? [Linda] The text is to address issues of today's L2 network being identified by VLANs. 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. Section 3.4 spends most if its time discussing what "Optimal IP Routing" means, only to go on to say "The ability to deliver optimal routing (as defined above) in the presence of stateful devices is outside the scope of this document.". Why bother spending time to define something which is out of scope? [Linda] This section address the issues, whose solutions are out of the scope of this draft. There will be separate IDs to describe the issues. Section 3.5 discusses "policies that control connectivity between a given VM and its peers", which I understand based on the definition of CUG, to be the VN itself. It then seems to go on to say that these policies (I.e. the VN) must not change whether the VM moves between two different L2 physical domains or stays within the same L2 physical domain. Isn't this section just a complicated way of stating that when a VM moves, it should remain connected to the same VN it was originally connected to? Isn't that trivial and obvious? [Linda] No, it is not trivial at all. With 80% traffic being east-west, the security policies, such as FW policies, zone policies, the AntiDoS policies have to be changed on different segments within a single DC. When VMs move, all the relevant policies have to be moving too! 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
