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]> 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]<[email protected]>]

*Sent:* Friday, March 01, 2013 5:30 PM
*To:* Linda Dunbar; [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]> 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

Reply via email to