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 discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
