Hi Linda, I tend to agree with Benson here. I think the potential issues that Linda raises can only be said to be issues if you consider a specific solution or data center architecture. Depending on the choices made, there may be tradeoffs that will expose one or more of the issues raised. Perhaps these belong in the Gap Analysis since the GA analyzes solutions.
- Larry From: Benson Schliesser <[email protected]<mailto:[email protected]>> Date: Friday, March 1, 2013 5:02 PM To: Linda Dunbar <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02 Hi, Linda. To clarify: I described them as solution based because they might not be present in all different solutions. For example, a number of your issues stem from the gateway's location. But some approaches might have distributed gateways. An L3 service in the NVE might not experience any of these gateway issues, for example, depending on the network design. Nevertheless, these are definitely things to consider. Thus my suggestion - I think it would be helpful if these issues were rephrased as requirements. Cheers, -Benson On Mar 1, 2013, at 18:36, Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: Benson, I only point out some Data Center issues not solved by overlay and issues introduced by IP overlay. I think that NV03 as an IETF working group for data centers with large number of mobile virtual machines, the problem statement should have a section describing those points. I really don’t see how those issues are solution based. Can you elaborate why do you see those are solution based? Best regards, Linda From: Benson Schliesser [mailto:[email protected]] Sent: Friday, March 01, 2013 5:30 PM To: Linda Dunbar; [email protected]<mailto:[email protected]> Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02 Hi, Linda. I think the NVO3 Problem Statement is intended to describe the problems that motivate our work, rather than repercussions of a particular approach. Speaking for myself, I observe that these issues are very much solution-dependent, and I think they are more appropriate inputs for the requirements drafts rather than the PS. As chair, I'd be interested in hearing what the authors and other contributors think about this. Cheers, -Benson On Mar 1, 2013, at 18:10, "Linda Dunbar" <[email protected]<mailto:[email protected]>> wrote: Thomas, et al, This draft has done a very good job in describing the motivation for overlay and its potential control/data plane. However, the draft hasn’t described the issues introduced by overlay and large DC issues not solved by overlay. For example: - Multicast issues introduced by overlay: o IP Encapsulation by NVE (or virtual switches on server) means that any layer 2 multicast from or to VMs requires Layer 3 Multicast/broadcast support in the core. o Majority of virtual switches in server won’t have attached VMs participating in any Multicast groups. Therefore, it may not be cost effective for them to support Layer 3 multicast protocol, e.g. PIM, etc. o For virtual switches that do have attached VMs participating in multicast, there are much more dynamic states due to VM moves. o The head end replication will require hypervisor virtual switches to keep up multicast member states, which can change frequently. Therefore, those NVEs, if required to support multicast, have to do more than MPLS (MVPN) multicast supported by PE routers. o - Bottleneck at gateway nodes: o The draft has emphasized greatly on the importance of tenant separation. That means two VMs under the same NVE, if they belong to two different virtual network instances, the communication between them have to go all the way to their default gateway. o Some end stations even have specific default gateway configured. That require all the inter VNI communication to go through their designated gateway nodes. o Many data centers have their FW/LB co- located with GW nodes. That means all the inter VNI communications have to hairpined to those GW nodes. - issues that are not solved by overlay: o The draft is for environment where VMs can move anywhere, which require the Gateway nodes to be aware of individual VM addresses and their corresponding egress NVEs. o Many large Data Centers have small number of gateway nodes interfacing with external network, e.g. 2/4/8/more. Very often, those external facing gateway nodes are the entrance and exit points for all virtual network instances. o Very often each of them can receive traffic for all virtual network instances hosted in the data center. o That means they all need to be aware of individual VMs and their corresponding egress NVEs in the data center. i.e. they may all need host routing. It is true that many routers can handle millions of routes, but the question is if it is necessary for data center gateway nodes to be those high capacity routers. - Therefore, I think that the NV03 problem statement draft should add a new section to describes issues introduced by overlay and issues not solved by overlay. Linda Dunbar
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
