You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Hugo Trippaers <hu...@trippaers.nl> on 2014/03/11 15:12:40 UTC
[PROPOSAL] Bridge functionality
Hey all,
I’ve been working on adding Bridge support to CloudStack. The use case is that with the introduction of SDN there is a need for us to link logical networks to physical hosts or physical networks. A typical use case would be to connect legacy infrastructure to cloud infrastructure, or to support cloud bursting from an existing infrastructure to a network in the cloud.
Routing can sometimes be used to accomplish the same effect (for example the private gateway option in a VPC), but in some cases a L2 connection is preferred.
The functionality would a central bridge manager in CloudStack. The bridge manager would have a number of admin only commands that link a number of networks to a specified domain or account. The user commands would allow an account to link a logical network to an external physical network. This separation is done to ensure users are never able to configure a bridge to a network they shouldn’t have access to. Admins will have to make an external network available as a bridge destination and a user can select it.
The network implementation will consists of a BridgeProvider element extension which elements can implement. It’s up to the elements to configure the particulars of their bridge implementation.
Initial implementation will cover the admin commands, user commands and an implementation in the VMware NSX plugin. UI is out of scope for the first implementation.
Any feedback is welcome :D
Cheers,
Hugo
Re: [PROPOSAL] Bridge functionality
Posted by Nux! <nu...@li.nux.ro>.
On 11.03.2014 14:12, Hugo Trippaers wrote:
> Hey all,
>
> I’ve been working on adding Bridge support to CloudStack. The use
> case is that with the introduction of SDN there is a need for us to
> link logical networks to physical hosts or physical networks. A
> typical use case would be to connect legacy infrastructure to cloud
> infrastructure, or to support cloud bursting from an existing
> infrastructure to a network in the cloud.
Very good idea! I was actually wondering how the heck I could link a
customer's say VXLAN to his physical dedicated servers in his VLAN as
none of our switches can do "SDN"..
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
Re: [PROPOSAL] Bridge functionality
Posted by Nate Gordon <na...@appcore.com>.
I would also like to chime in on this. Our customers routinely make use of
bridging vlans out into dedicated infrastructure, and a way to automate
this with SDN deployments would be welcome. I might even be able to get
some dev resources to assist with the development.
Thanks,
-Nate
On Thu, Mar 13, 2014 at 9:19 AM, Ian Rae <ir...@cloudops.com> wrote:
> Hugo,
>
> This is a common request from our SP customers but most have balked at the
> cost of developing a custom solution. It is an important feature for hybrid
> architectures, let us know how we can help. Certainly we will give feedback
> on the functional spec.
>
> Ian
>
> Ian Rae
> CEO, CloudOps Inc.
> 514-944-4008
> @ianrae | www.linkedin.com/in/ianrae
> www.cloudops.com
>
>
> On Tue, Mar 11, 2014 at 10:12 AM, Hugo Trippaers <hu...@trippaers.nl>
> wrote:
>
> > Hey all,
> >
> > I've been working on adding Bridge support to CloudStack. The use case is
> > that with the introduction of SDN there is a need for us to link logical
> > networks to physical hosts or physical networks. A typical use case would
> > be to connect legacy infrastructure to cloud infrastructure, or to
> support
> > cloud bursting from an existing infrastructure to a network in the cloud.
> >
> > Routing can sometimes be used to accomplish the same effect (for example
> > the private gateway option in a VPC), but in some cases a L2 connection
> is
> > preferred.
> >
> > The functionality would a central bridge manager in CloudStack. The
> bridge
> > manager would have a number of admin only commands that link a number of
> > networks to a specified domain or account. The user commands would allow
> an
> > account to link a logical network to an external physical network. This
> > separation is done to ensure users are never able to configure a bridge
> to
> > a network they shouldn't have access to. Admins will have to make an
> > external network available as a bridge destination and a user can select
> it.
> >
> > The network implementation will consists of a BridgeProvider element
> > extension which elements can implement. It's up to the elements to
> > configure the particulars of their bridge implementation.
> >
> > Initial implementation will cover the admin commands, user commands and
> an
> > implementation in the VMware NSX plugin. UI is out of scope for the
> first
> > implementation.
> >
> > Any feedback is welcome :D
> >
> > Cheers,
> >
> > Hugo
>
--
*Nate Gordon*Director of Technology | Appcore - the business of cloud
computing®
Office +1.800.735.7104 | Direct +1.515.612.7787
nate.gordon@appcore.com | www.appcore.com
----------------------------------------------------------------------
The information in this message is intended for the named recipients only.
It may contain information that is privileged, confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution, or the taking
of any action in reliance on the contents of this message is strictly
prohibited. If you have received this e-mail in error, do not print it or
disseminate it or its contents. In such event, please notify the sender by
return e-mail and delete the e-mail file immediately thereafter. Thank you.
Re: [PROPOSAL] Bridge functionality
Posted by Ian Rae <ir...@cloudops.com>.
Hugo,
This is a common request from our SP customers but most have balked at the
cost of developing a custom solution. It is an important feature for hybrid
architectures, let us know how we can help. Certainly we will give feedback
on the functional spec.
Ian
Ian Rae
CEO, CloudOps Inc.
514-944-4008
@ianrae | www.linkedin.com/in/ianrae
www.cloudops.com
On Tue, Mar 11, 2014 at 10:12 AM, Hugo Trippaers <hu...@trippaers.nl> wrote:
> Hey all,
>
> I've been working on adding Bridge support to CloudStack. The use case is
> that with the introduction of SDN there is a need for us to link logical
> networks to physical hosts or physical networks. A typical use case would
> be to connect legacy infrastructure to cloud infrastructure, or to support
> cloud bursting from an existing infrastructure to a network in the cloud.
>
> Routing can sometimes be used to accomplish the same effect (for example
> the private gateway option in a VPC), but in some cases a L2 connection is
> preferred.
>
> The functionality would a central bridge manager in CloudStack. The bridge
> manager would have a number of admin only commands that link a number of
> networks to a specified domain or account. The user commands would allow an
> account to link a logical network to an external physical network. This
> separation is done to ensure users are never able to configure a bridge to
> a network they shouldn't have access to. Admins will have to make an
> external network available as a bridge destination and a user can select it.
>
> The network implementation will consists of a BridgeProvider element
> extension which elements can implement. It's up to the elements to
> configure the particulars of their bridge implementation.
>
> Initial implementation will cover the admin commands, user commands and an
> implementation in the VMware NSX plugin. UI is out of scope for the first
> implementation.
>
> Any feedback is welcome :D
>
> Cheers,
>
> Hugo
Re: [PROPOSAL] Bridge functionality
Posted by Chiradeep Vittal <Ch...@citrix.com>.
What is the structure of the bridge URI?
I might be interested in specifying the split of IP addresses across the bridge (e.g., 10.1.1.2-10.1.1.100 on the overlay, 10.1.1.101-10.1.1.254 on the VLAN).
Will there be separate DHCP providers for the 2 segments? How about multiple bridged segments?
Are there VMs controlled by CloudStack on the physical network ? (I assume this is a VLAN)
From: Hugo Trippaers <hu...@trippaers.nl>>
Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
Date: Thursday, March 13, 2014 at 2:32 AM
To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
Subject: Re: [PROPOSAL] Bridge functionality
On 11 mrt. 2014, at 21:51, Chiradeep Vittal <Ch...@citrix.com>> wrote:
Is there a more detailed writeup? I am interested in the api and Œflow’
No, no more details at the moment. Still thinking a lot on how i want it to work. I’m trying to get this as generic as possible so other SDN solution can benefit from the framework.
The main components are :
BridgeService (much like the FirewallService) that js responsible for handing the API commands and making sure that users can on attach a bridge to a network that has been whitelisted by an Admin.
BridgeProvider (network element extension) that is responsible for implementing a bridge on a network, either triggered by the api (createBridgeCmd) or by an event (implement()).
The elements would also be responsible for gathering the details for their specific bridge implementations, for example in the VMware NSX environment a bridge would need a gateway service ID. An internal OVS implementation would need an ovs bridge name.
Admin api
========
AddBridgeUri( zone, domain, account, uri) <id>
RemoveBridgeUri ( id) <success>
User api
=======
AddBridge(network, destination uri) <id>
DeleteBridge(id) <success>
Cheers,
Hugo
On 3/11/14, 7:12 AM, "Hugo Trippaers" <hu...@trippaers.nl>> wrote:
Hey all,
I¹ve been working on adding Bridge support to CloudStack. The use case is
that with the introduction of SDN there is a need for us to link logical
networks to physical hosts or physical networks. A typical use case would
be to connect legacy infrastructure to cloud infrastructure, or to
support cloud bursting from an existing infrastructure to a network in
the cloud.
Routing can sometimes be used to accomplish the same effect (for example
the private gateway option in a VPC), but in some cases a L2 connection
is preferred.
The functionality would a central bridge manager in CloudStack. The
bridge manager would have a number of admin only commands that link a
number of networks to a specified domain or account. The user commands
would allow an account to link a logical network to an external physical
network. This separation is done to ensure users are never able to
configure a bridge to a network they shouldn¹t have access to. Admins
will have to make an external network available as a bridge destination
and a user can select it.
The network implementation will consists of a BridgeProvider element
extension which elements can implement. It¹s up to the elements to
configure the particulars of their bridge implementation.
Initial implementation will cover the admin commands, user commands and
an implementation in the VMware NSX plugin. UI is out of scope for the
first implementation.
Any feedback is welcome :D
Cheers,
Hugo
Re: [PROPOSAL] Bridge functionality
Posted by Hugo Trippaers <hu...@trippaers.nl>.
On 11 mrt. 2014, at 21:51, Chiradeep Vittal <Ch...@citrix.com> wrote:
> Is there a more detailed writeup? I am interested in the api and Œflow’
No, no more details at the moment. Still thinking a lot on how i want it to work. I’m trying to get this as generic as possible so other SDN solution can benefit from the framework.
The main components are :
BridgeService (much like the FirewallService) that js responsible for handing the API commands and making sure that users can on attach a bridge to a network that has been whitelisted by an Admin.
BridgeProvider (network element extension) that is responsible for implementing a bridge on a network, either triggered by the api (createBridgeCmd) or by an event (implement()).
The elements would also be responsible for gathering the details for their specific bridge implementations, for example in the VMware NSX environment a bridge would need a gateway service ID. An internal OVS implementation would need an ovs bridge name.
Admin api
========
AddBridgeUri( zone, domain, account, uri) <id>
RemoveBridgeUri ( id) <success>
User api
=======
AddBridge(network, destination uri) <id>
DeleteBridge(id) <success>
Cheers,
Hugo
>
> On 3/11/14, 7:12 AM, "Hugo Trippaers" <hu...@trippaers.nl> wrote:
>
>> Hey all,
>>
>> I¹ve been working on adding Bridge support to CloudStack. The use case is
>> that with the introduction of SDN there is a need for us to link logical
>> networks to physical hosts or physical networks. A typical use case would
>> be to connect legacy infrastructure to cloud infrastructure, or to
>> support cloud bursting from an existing infrastructure to a network in
>> the cloud.
>>
>> Routing can sometimes be used to accomplish the same effect (for example
>> the private gateway option in a VPC), but in some cases a L2 connection
>> is preferred.
>>
>> The functionality would a central bridge manager in CloudStack. The
>> bridge manager would have a number of admin only commands that link a
>> number of networks to a specified domain or account. The user commands
>> would allow an account to link a logical network to an external physical
>> network. This separation is done to ensure users are never able to
>> configure a bridge to a network they shouldn¹t have access to. Admins
>> will have to make an external network available as a bridge destination
>> and a user can select it.
>>
>> The network implementation will consists of a BridgeProvider element
>> extension which elements can implement. It¹s up to the elements to
>> configure the particulars of their bridge implementation.
>>
>> Initial implementation will cover the admin commands, user commands and
>> an implementation in the VMware NSX plugin. UI is out of scope for the
>> first implementation.
>>
>> Any feedback is welcome :D
>>
>> Cheers,
>>
>> Hugo
>
Re: [PROPOSAL] Bridge functionality
Posted by Chiradeep Vittal <Ch...@citrix.com>.
Is there a more detailed writeup? I am interested in the api and Œflow'
On 3/11/14, 7:12 AM, "Hugo Trippaers" <hu...@trippaers.nl> wrote:
>Hey all,
>
>I¹ve been working on adding Bridge support to CloudStack. The use case is
>that with the introduction of SDN there is a need for us to link logical
>networks to physical hosts or physical networks. A typical use case would
>be to connect legacy infrastructure to cloud infrastructure, or to
>support cloud bursting from an existing infrastructure to a network in
>the cloud.
>
>Routing can sometimes be used to accomplish the same effect (for example
>the private gateway option in a VPC), but in some cases a L2 connection
>is preferred.
>
>The functionality would a central bridge manager in CloudStack. The
>bridge manager would have a number of admin only commands that link a
>number of networks to a specified domain or account. The user commands
>would allow an account to link a logical network to an external physical
>network. This separation is done to ensure users are never able to
>configure a bridge to a network they shouldn¹t have access to. Admins
>will have to make an external network available as a bridge destination
>and a user can select it.
>
>The network implementation will consists of a BridgeProvider element
>extension which elements can implement. It¹s up to the elements to
>configure the particulars of their bridge implementation.
>
>Initial implementation will cover the admin commands, user commands and
>an implementation in the VMware NSX plugin. UI is out of scope for the
>first implementation.
>
>Any feedback is welcome :D
>
>Cheers,
>
>Hugo