[ovs-discuss] Scalability Questions in High-Density Virtualisation Environments
casado at nicira.com
Thu Sep 8 05:17:56 UTC 2011
Yeah, I think that's right. Of course, Open vSwitch will be able to
support both eventually. But for large deployments, managing the edge
MAC tables, as well as tunneling and tagging rules (and any other
filtering or QoS policy) will almost certainly require a centralized
component. Also, as you point out, multicast is a non-trivial
deployment hurdle. There are table sizing concerns, and performance
issues on group joins in many implementations. But perhaps more
significantly are the operational risks that have bitten must of us in
the past (and are the reason multicast is often shunned in large
> Yes, VXLAN tunnel header is a good proposal, but for control plane
> there is serve limitation: it depend on physical network multicast for
> MAC learning. In OVS, central ovsdb controlled MAC address propagation
> is a better choice.
> On Wed, Sep 7, 2011 at 9:09 AM, Justin Pettit<jpettit at nicira.com> wrote:
>> On Sep 7, 2011, at 9:01 AM, Nicky Fatr wrote:
>>> I don't think that TRILL/802.1AQ L2 over L2 is a good option for large
>>> scale deployment. L2 over L3 instead is more scalable, eliminating
>>> comlexity of physical network.
>>> maybe we can expect L2 over UDP in some future release, for UDP is
>>> more friendly than GRE in some networking configuration.
>> You can already do L2-over-L3 with CAPWAP. It doesn't support a configurable context identifier (key), but a patch has been provided by Valient Gough and Simon Horman that adds it. We're also looking at supporting VXLAN, which was recently announced:
> discuss mailing list
> discuss at openvswitch.org
Nicira Networks, Inc.
www.nicira.com | www.openvswitch.org
More information about the discuss