Hi Larry, On Wed, Sep 24, 2014 at 6:56 PM, Larry Kreeger (kreeger) <[email protected]> wrote: > 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: > > There is major overlap with the NVO3 Problem Statement. VM mobility is a > main motivating use case in the problem statement.
I disagree. draft-ietf-nvo3-overlay-problem-statement-04 does not state anywhere that VM mobility was the main motivating use case. The document makes the case that overlay based approach instead of non-overlay approaches is better. Yes it does talk about VM mobility, like in Section 3.2, I think the two paragraphs there make good points. This is in Section 3 on problem areas and 3.2 on VM mobility is just one of the 7! I did not see any other section or subsection devoted to VM mobility in this 24 page document. > Content related to inter-datacenter issues are not within scope for NVO3. > 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). VM mobility issues draft was accepted as WG draft in December 2012 and overlay problem statement draft in June 2012. VM mobility draft was revised several times in the process. Has anyone raised this or similar concerns from that time until revision 03 which was issued in June 2014? > I don't believe the small amount of remaining non-overlapping and in-charter > content will effect the framework, architecture, or intra-datacenter > solutions. > VM mobility issues draft is currently in WG Last Call. I don't think WGLC is the time to make such points. In December 2012 when draft-ietf-nvo3-vm-mobility-issues was undergoing a WG adoption call no one said these issues are covered in draft-ietf-nvo3-overlay-problem-statement? Over the time draft-ietf-nvo3-vm-mobility-issues got revised and no one said this draft should be converted into VM mobility solution draft? First of all it would be out of scope with the previous charter in 2012 which did not include the solutions in its scope. Secondly, isn't it inappropriate to entertain such comments at this stage when a WGLC is being made? To the chairs, I suggest that in view of the fact that WGLC received good support and no comments asking for some specific changes were made, this draft should be moved to IESG. Regards, Behcet > > - Larry > > From: Linda Dunbar <[email protected]> > Date: Friday, September 19, 2014 3:53 PM > To: Larry Kreeger <[email protected]>, Benson Schliesser > <[email protected]>, "[email protected]" <[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]> 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] > >>https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
