cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salvatore Orlando <Salvatore.Orla...@eu.citrix.com>
Subject Open vSwitch tunnel Manager (aka Cloudstack SDN) - community feedback required!
Date Tue, 08 May 2012 14:37:46 GMT
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

Mime
View raw message