David, Questions inserted below:
From: Black, David [mailto:[email protected]] Sent: Monday, September 22, 2014 7:06 PM To: Linda Dunbar; Larry Kreeger (kreeger); [email protected] Subject: RE: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues Linda, > If a VN is spread across multiple DCBRs and all those DCBRs announce the same > IP prefix for the VN, there could be many issues, including: - > Traffic could go to DCBR A where target is in DCBR B. and DCBR "A" is connected to DCBR "B" via WAN Note that "via WAN" makes a specific solution assumption. [Linda] it is only to describe the issues associated with the two DCBRs not directly connected by one single link. It is much less a "solution" than NVO3 general problem statement describing "Overlay" to hide VMs addresses. > If all those DCBRs announce individual IPs that are directly attached and > those IPs are not segmented well, then all the VMs IP > addresses have to be exposed to the WAN. Sure, that may happen, but that description assumes a) that DCBRs exist and b) that they advertise individual IP addresses, both of which are specific solution assumptions. [Linda] The draft is only to describe the issues associated with common IP routing practices (i.e. with or without advertising individual IP addresses ). > All those issues haven't been properly addressed by NVO3 problem statement. Those issues appear to be solution-specific issues with alternative routing structures for external traffic. IMHO it was not the job of the problem statement to survey solution approaches and discuss issues with each of them, so this material does not belong there. [Linda] Based on your definition, the NVO3 general problem statement draft describing using "overlay" to hide individual VM addresses should also be considered as solution, correct? As solution material, it would belong in solution drafts, but the vm-mobility-issues draft is supposed to be a general draft that isn't solution-specific. As long as the draft assumes the existence of a DCBR, it's probably in solution-space. If the current VM mobility draft is evolved into a design draft that assumes DCBRs, no multi-homing on the WAN and no software network switches in hypervisors (all of which the current draft assumes as I understand it), that could be considered as a solution draft, but it would not be a general (solution-independent) VM issues draft. Thanks, --David From: nvo3 [mailto:[email protected]] On Behalf Of Linda Dunbar Sent: Monday, September 22, 2014 5:40 PM To: Black, David; Larry Kreeger (kreeger); [email protected]<mailto:[email protected]> Subject: Re: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues David, Indeed we have different interpretations of "Optimal routing". In "vm-mobility" draft, the "Optimal routing" is to avoid "triangular routing" (or what you stated "hot potato" route). If a VN is spread across multiple DCBRs and all those DCBRs announce the same IP prefix for the VN, there could be many issues, including: - Traffic could go to DCBR A where target is in DCBR B. and DCBR "A" is connected to DCBR "B" via WAN - If majority of one VN members are under DCBR "A" and rest are spread across X number of DCBRs. Will DCBR "A" have same weight as DCBR "B", "C", etc? If all those DCBRs announce individual IPs that are directly attached and those IPs are not segmented well, then all the VMs IP addresses have to be exposed to the WAN. So overlay hides the VMs IP from the core switches in one DC or one POD, but exposes them to the WAN. There are more routers in the WAN than the number of core switches in one DC/POD. All those issues haven't been properly addressed by NVO3 problem statement. Linda From: Black, David [mailto:[email protected]] Sent: Monday, September 22, 2014 11:23 AM To: Linda Dunbar; Larry Kreeger (kreeger); [email protected]<mailto:[email protected]> Subject: RE: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues I don't think it's that simple, as I think this makes an assumption about routing structure and what "optimal" means, specifically that it's not "optimal" for inbound external traffic to a VN at site A to show up at the DCBR at site B. If so, I disagree, as this ignores the possibility of multi-homing the VNs entire IP address block. It's quite reasonable for DCBRs at two different data centers to both announce the entire IP address block for the VN and forward inbound traffic that arrives at the wrong place to the other data center. Under that structure, the external WAN routers still see a single IP address block. This can result in asymmetric "hot potato" routes where inbound traffic shows up at the site B DCBR, but outbound traffic leaves via the site A DCBR, which may still be "optimal". Thanks, --David From: Linda Dunbar [mailto:[email protected]] Sent: Monday, September 22, 2014 11:59 AM To: Black, David; Larry Kreeger (kreeger); [email protected]<mailto:[email protected]> Subject: RE: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues David, I see what you mean now. How about this updated wording: In order to achieve the optimal routing, routers in the Wide Area Network have to be aware which DCBRs can reach the designated VMs. When VMs in a single VN are spread across many different DCBRs, all individual VMs' addresses have to be visible to those routers, which can dramatically increase the number of routes in those routers. Linda From: Black, David [mailto:[email protected]] Sent: Monday, September 22, 2014 10:46 AM To: Linda Dunbar; Larry Kreeger (kreeger); [email protected]<mailto:[email protected]> Subject: RE: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues Linda, I used BGP as an example to indicate that the "have to announce" statement is not correct. There's no need to describe what BGP does, but stating that something cannot currently be done (i.e., needs WG attention) when BGP already does that something is not a good idea. Thanks, --David From: Linda Dunbar [mailto:[email protected]] Sent: Monday, September 22, 2014 11:32 AM To: Black, David; Larry Kreeger (kreeger); [email protected]<mailto:[email protected]> Subject: RE: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues David, See comment in line below From: Black, David [mailto:[email protected]] Sent: Friday, September 19, 2014 7:02 PM To: Linda Dunbar; Larry Kreeger (kreeger); [email protected]<mailto:[email protected]> Subject: RE: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues Butting in w/one comment ... > [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. I think that comment is in solution-space, not problem-space or issue-space (where this draft is supposed to be), as the comment appears to be based on specific assumptions about DCBR existence and functionality that aren't true in general. For example, I'm sure Yakov can explain how BGP can do better than that ;-). [Linda-3] "How BGP can do better" is actually a solution. What described is a problem. Linda Thanks, --David From: nvo3 [mailto:[email protected]] On Behalf Of Linda Dunbar Sent: Friday, September 19, 2014 6:54 PM To: Larry Kreeger (kreeger); Benson Schliesser; [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
