incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <Chiradeep.Vit...@citrix.com>
Subject Re: Open vSwitch tunnel Manager (aka Cloudstack SDN) - community feedback required!
Date Tue, 08 May 2012 18:00:00 GMT


On 5/8/12 10:24 AM, "Kelven Yang" <kelven.yang@citrix.com> wrote:

>
>
>> -----Original Message-----
>> From: Salvatore Orlando [mailto:Salvatore.Orlando@eu.citrix.com]
>> Sent: Tuesday, May 08, 2012 7:38 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Open vSwitch tunnel Manager (aka Cloudstack SDN) - community
>> feedback required!
>> 
>> 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.
>
>I think it makes more sense to derive GRE key from internal IDs. Those
>GRE keys are not like VLAN IDs that admins need to use them to configure
>switches, GRE keys are only used internally and there is no need to
>expose them to users/administrators.

The need to be able to specify a specific id or range is to integrate with
external devices. Let's say the Juniper SRX could easily support GRE
tunnels. Then it might be required to be able to specify the exact range.

>
>
>> 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
>
>When isolation method is GRE, it is better for CloudStack system to take
>care of isolation keys entirely. I think there is no need to use or ask
>for vnet range in this case.
>
>Kelven


Mime
View raw message