Hi all! As some of you already know, a feature for creating L2-in-L3 guest networks was recently pushed in the master branch. For more information on this feature, please check the specification: http://wiki.cloudstack.org/display/QA/Open+vSwitch+Tunnel+Manager
I would like to ask your feedback on some topics in order to improve the way in which Cloudstack manages this feature. As we are now using GRE keys instead of VLAN identifiers, we have widened the potential vnet space to up to 2^32-1. However, the APIs still ask the user for a range, and the zone GUI wizard also asks for a range, which is used to size the vnet space. 1) Does it make sense to specify a range at all? With VLANs, user might want to use only a part of the VLAN ID space, as some VLANs might be reserved for other purposes, or physical switches might have limitations on the maximum number of VLANs. However, this might not be true for GRE keys. What's your opinion? 2) Does it still make sense to use vnets? Currently, we randomly pick a vnet and use its identifiers as the GRE key. Would it be simpler to just use the internal network id, which is a Java long, as the GRE key? After all we probably don't want to handle a vnet table which can in theory have more than 4 billion records. 3) We currently allow users to specify the isolation method for a physical network both in the GUI and the API. If the isolation method is GRE, we then allow users to specify vnet IDs > 4096. If you think vNets should not be used at all, then probably this question is pointless. But otherwise, do you think this is a bit confusing, as you might already think that that choice was implicitly made when you enabled/disabled the vSwitch controller? Apologies in advance if I forgot to respect any mailing list guidelines, Salvatore
