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. On Tue, Sep 6, 2011 at 6:41 PM, Justin Pettit <[email protected]> wrote: > Thanks for the detailed write-up. I agree with what you've said earlier, so > I'll strip this down to your essential questions: > >> • What is the scalability of a large OVS deployment and what >> abstraction measures are taken to avoid the “virtual” domain having CAM >> exhaustion risks on the “physical” infrastructure? > > There shouldn't be much in the way of hard scalability limits in OVS. The > limits we've put in place (e.g., 2K MAC addresses for the learning table in a > bridge) are typically just a #define, so they can be adjusted fairly easily > (although they may not be optimized for radically larger values). However, > OVS is used in very large, high-density virtualized environments without any > source-code modification, so it shouldn't be necessary with the proper > management model. > > There's nothing inherent in OVS that can prevent the CAM exhaustion in > upstream devices that you've described, but it does support primitives that > can be used to help, such as L2-over-L3 tunneling protocols. This does > require some sort of orchestration either through local configuration or a > centralized controller. > >> • What is the scalability of the Ethernet over GRE implementation and >> what measures are taken to avoid loops and/or bottlenecks? > > Once again, there shouldn't be any hard limits in the Ethernet-over-GRE > implementation. In fact, we've jumped through some hoops to prevent them, > such as not actually creating a Linux device for each tunnel. (A large > number of devices cause problems on some hypervisor platforms.) > > As I mentioned earlier, something needs to take care of the orchestration of > the tunnels; this should also be responsible for preventing loops and > bottlenecks. If the network is somewhat modest in size, careful scripting > may be sufficient. At large-scale, you'd probably want a centralized > controller. > >> • Are there any plans potentially to incorporate TRILL and/or RBRIDGE >> features into OVS at some point in the future? > > We don't have this on our current roadmap. We would certainly be open to a > donated clean implementation. > > --Justin > > > _______________________________________________ > discuss mailing list > [email protected] > http://openvswitch.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
