You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Salvatore Orlando <Sa...@eu.citrix.com> on 2012/05/08 16:37:46 UTC
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.
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
Re: Open vSwitch tunnel Manager (aka Cloudstack SDN) - community
feedback required!
Posted by Chip Childers <ch...@sungard.com>.
> I reckon you mean allowing domain admins/root admins to read GRE keys assigned to guest networks via API/GUI, is that correct?
Yes, exactly.
> Do you think they should also have the ability of assigning specific keys to particular guest networks if needed?
Yes to this as well. Chiradeep's comment is pretty dead on.
Assigning a range would be the minimum level of control, with specific
ID's being assigned per request being both (1) harder to implement
(i.e.: don't allow the selected ID to clash with other in use IDs),
but (2) more powerful / useful under certain use cases.
-chip
RE: Open vSwitch tunnel Manager (aka Cloudstack SDN) - community
feedback required!
Posted by Salvatore Orlando <Sa...@eu.citrix.com>.
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: 08 May 2012 19:04
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Open vSwitch tunnel Manager (aka Cloudstack SDN) -
> community feedback required!
>
> > >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.
>
> It would at least be helpful for the IDs to be visible to provider level
> administrators (hopefully I'm getting the role name correctly) for
> troubleshooting purposes.
>
> -chip
Hi Chip,
Thanks for your feedback!
I reckon you mean allowing domain admins/root admins to read GRE keys assigned to guest networks via API/GUI, is that correct?
Do you think they should also have the ability of assigning specific keys to particular guest networks if needed?
Salvatore
Re: Open vSwitch tunnel Manager (aka Cloudstack SDN) - community
feedback required!
Posted by Chip Childers <ch...@sungard.com>.
> >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.
It would at least be helpful for the IDs to be visible to provider
level administrators (hopefully I'm getting the role name correctly)
for troubleshooting purposes.
-chip
Re: Open vSwitch tunnel Manager (aka Cloudstack SDN) - community
feedback required!
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 5/8/12 10:24 AM, "Kelven Yang" <ke...@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
RE: Open vSwitch tunnel Manager (aka Cloudstack SDN) - community
feedback required!
Posted by Kelven Yang <ke...@citrix.com>.
> -----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.
> 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
Re: Open vSwitch tunnel Manager (aka Cloudstack SDN) - community
feedback required!
Posted by Alex Huang <Al...@citrix.com>.
Absolutely.
--Alex
On May 9, 2012, at 8:22 AM, "Murali Reddy" <Mu...@citrix.com> wrote:
> On 09/05/12 1:48 AM, "Alex Huang" <Al...@citrix.com> wrote:
>>
>> - OVS Manager should expose its own APIs to configure OVS networking so
>> that we don't shoehorn what OVS supports into VLAN range.
>> - OVS should be an entirely separate jar built with dependency on
>> cloud-api.jar only.
>
> As we begin to add more NetworkElements in to CloudStack may be the
> guildeline should be to implement them as PluggableService. Also does it
> make sense to enforce that plugin (NetworkElement and NetworkGuru in this
> case) does not get access to CloudStack core resources (other managers,
> Dao's etc) so that they abide by interface semantics and forced to manage
> their own resources?
>
Re: Open vSwitch tunnel Manager (aka Cloudstack SDN) - community
feedback required!
Posted by Murali Reddy <Mu...@citrix.com>.
On 09/05/12 1:48 AM, "Alex Huang" <Al...@citrix.com> wrote:
>
>- OVS Manager should expose its own APIs to configure OVS networking so
>that we don't shoehorn what OVS supports into VLAN range.
>- OVS should be an entirely separate jar built with dependency on
>cloud-api.jar only.
As we begin to add more NetworkElements in to CloudStack may be the
guildeline should be to implement them as PluggableService. Also does it
make sense to enforce that plugin (NetworkElement and NetworkGuru in this
case) does not get access to CloudStack core resources (other managers,
Dao's etc) so that they abide by interface semantics and forced to manage
their own resources?
RE: Open vSwitch tunnel Manager (aka Cloudstack SDN) - community
feedback required!
Posted by Alex Huang <Al...@citrix.com>.
> 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?
>
Salvatore,
I think this stamps from me not doing a good enough job of explaining our plugin architecture and what's in plan for future use cases. OVS is basically a future use case.
Summary
NetworkGuru understands how virtual networks are mapped to physical networks. Each implementation must deal with three things on that network:
- Isolation Method
- Ip Addressing scheme
- Traffic type carried on the network
NetworkManager is a process engine that simply drives the process of starting up a network to the NetworkGurus and NetworkElements.
Todos:
OVS already implements a NetworkGuru, which is great. However, what's not implemented in CloudStack (deficiency in CloudStack NetworkManager not in the OVS code) is a way for NetworkManager to select the NetworkGuru based on the underlying technology. It wasn't necessary to introduce that before because it was always VLAN and IPv4. For OVS to get to production, I believe we need to do the following things:
- OVS has its own way of managing the IDs. It should avoid the usage of the vnet table. It is not good to share that table to begin with.
- NetworkGuru needs a method for NetworkManager to call to determine the isolation technology, IP addressing scheme, and traffic type that it supports.
- Ovs NetworkGuru, of course, implements that.
- NetworkManager needs to add logic to select the correct NetworkGuru based on the above three things. When it is GRE, then it should select OvsNetworkGuru.
- OVS Manager should expose its own APIs to configure OVS networking so that we don't shoehorn what OVS supports into VLAN range.
- OVS should be an entirely separate jar built with dependency on cloud-api.jar only.
Those are things CloudStack supports today and we can make those changes to make OVS production today.
In the future, when CloudStack supports pluggable UI, then the following things can be done:
- OVS manager exposes a UI fragment such that it can have a separate UI when the network says the underlying isolation technology is OVS.
For now, because we don't have pluggable UI.
- OVS manager have to work it out with the UI so that if it is OVS, it no longer exposes VLAN range as the input to configure the physical network but whatever is appropriate for OVS.
Let me know what you think.
--Alex