Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of fozzielumpkins@gmail.com
 designates 209.85.212.176 as permitted sender)
Sender: Funs Kessen <fozzielumpkins@gmail.com>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Subject: Re: Third party VR / L2 support
From: Funs Kessen <funs@barred.org>
In-Reply-To: 
 <AM2PR07MB05629028D585F524E2F61B688CBE0@AM2PR07MB0562.eurprd07.prod.outlook.com>
Date: Tue, 9 Jun 2015 11:55:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F736A317-7134-4290-8DEC-128828C726F2@barred.org>
References: <D1920424.25240%christian@bt.net>
 <AM2PR07MB05629028D585F524E2F61B688CBE0@AM2PR07MB0562.eurprd07.prod.outlook.com>
To: dev@cloudstack.apache.org

Hi Christian and Paul,

I agree that the VR/VPC construct could do with some improvements, the =
biggest being that it should actually be api driven and allow for more =
flexible networking/services combined with scale out itself (we=E2=80=99re=
 looking into this actually). All of these things bring along their own =
problems and should be tackled piece by piece, if we=E2=80=99d want to =
be efficient we should first blot out the API and then start pushing =
services in, which is difficult at the speed it is moving at.

The driver model in Cloudstack already supports the decoupling of =
services via "network service providers" (plugins) and ties in with the =
way the =E2=80=9Cnetwork service offerings" work with "service =
capabilities" and "supported services". At SBP we use NSX-mh for the =
service =E2=80=9CConnectivity=E2=80=9D, we could add =E2=80=9CSourceNat=E2=
=80=9D, =E2=80=9CStaticNat=E2=80=9D and =E2=80=9CPort Forwarding=E2=80=9D =
to this for NSX if we want to, but decided to leave that in the VR back =
then as these services were rather new in NSX. My point being that you =
can already mix and match things and are not stuck with the VR/VPC, and =
you can actually use devices on that level if need be, if you create the =
service offerings for them.
At the moment anyone can already create a plugin that exposes a single =
functionality or multiple, and expose that as a service that is offered, =
examples of these are the Palo-Alto, SRX, F5, Netscaler, Cisco VNMC, NSX =
and Nuage. I=E2=80=99m not saying it=E2=80=99s simple or easy, but if =
you know the API of what you want to integrate with you can.=20
The construction of the plugin module has its own unique challenges, and =
I agree with John Burwell (Shape Blue) and Paul that we need to change =
the way this all hangs together if we want more flexibility and ease of =
integration in the future.

BGP is brought in for use with IPv6,  the first code for that has just =
gone in from Suresh via Wilder. As that runs on top of Quagga you could =
do OSPF with that too. This again leads me to believe we really need to =
change the way the RV/VPC receives configuration, I=E2=80=99ve spoken to =
a big Cloudstack user, whom also contributes, that wants to be able to =
do more with HaProxy, read full configuration freedom, and after hearing =
this and bumping my head against it in the past it made perfect sense to =
me.

On the topic of L2 networking we=E2=80=99re bridging in and out a lot of =
networks at the moment for =E2=80=9CEnterprise=E2=80=9D production =
customers. Ranging from legacy environments to cloud environments or =
environments where we have full cloud workloads but also need physical =
iron due to =E2=80=9Cregulatory requirements=E2=80=9D or because there =
is no viable alternative yet (or we haven=E2=80=99t made a plugin that =
exposes that functionality from another device/VM/container that can be =
placed in a service offering etc). I think in our case L2 is not always =
a requirement for all areas as such and I=E2=80=99d prefer L3 in most =
cases where viable. We solved things that way, the L2 way, because that =
was our frame of mind, although it may be a requirement in your case.

Cheers,

Funs

> On 09 Jun 2015, at 10:27, Paul Angus <paul.angus@shapeblue.com> wrote:
>=20
> Hi Christian,
>=20
> This is a feature put forward by myself.  As a non-developer I can =
come up with these things and throw them over the wall to the developers =
and pretend I don't know how complicated it is :)
>=20
> In summary, it requires a few other pieces of the roadmap to be in =
place. The high level plan is to move ever closer to a driver/plugin =
model for CloudStack.  For this feature we need to fully separate the VR =
plugin code from the 'core' code and create strong contracts for VR =
commands/responses.  Then 'anyone' can create and maintain drivers for =
any type of router/firewall/vpn endpoint/loadbalancer. The CloudStack =
community would then continue to maintain the 'standard' VR/VPC.
>=20
> We're also developing OSPF capable and a routing-mode VPC offerings =
which we hope will be in 4.6
>=20
> I'd be interested to hear how you're using  the L2 devices to see =
where if we can fit it in to our 'Enterprise use' enhancements.
>=20
> Regards,
>=20
> Paul Angus
> Cloud Architect
> D: +44 20 3468 5163 |S: +44 20 3603 0540 | M: +44 7711 418 784 | T: =
@CloudyAngus
> paul.angus@shapeblue.com
>=20
> -----Original Message-----
> From: Christian [mailto:christian@bt.net]
> Sent: 01 June 2015 13:26
> To: dev@cloudstack.apache.org
> Subject: Third party VR / L2 support
>=20
> Hi Sebastien,
>=20
> Thank you for publishing the roadmap.
>=20
>=20
>> Replace VR with h/w (srx, asa etc)
>=20
>=20
> A question for all - What are the implications of expanding this =
feature to support s/w appliances, such as the ASA/CSR 1000V ?
>=20
>=20
> This is something that I have been implementing manually to date =
because:
>=20
>> Improve VR, VR agent, API for VR   :)
>=20
>=20
>=20
> It involves a little bit of 'creative networking' in order to suppress =
the CS virtual router. Any improvements in this area would be very =
useful.
> Even a QuickCloudNoServices-like offering for isolated networks would =
be great. I=C2=B9m aware that this can be created manually, but I=C2=B9m =
not convinced that this is a supported configuration.
>=20
>=20
> Pushing this concept further, I=C2=B9d like to see support for Layer 2 =
isolated networks. I use these for running virtual L2 devices under CS =
simply by creating dummy IP address ranges and ignoring them. Again, I =
have to suppress the VR, because it=C2=B9s not needed at L2.
>=20
>=20
> I=C2=B9ve been doing a fair bit to push the limits of networking in =
CloudStack over the last year using just VLANs and the standard API =
calls . I=C2=B9m happy to answer any questions anyone may have.
>=20
>=20
> Best regards,
>=20
> -Christian
>=20
> --
> Christian Lafferty
> <christian@bt.net>
>=20
>=20
>=20
> On 31/05/2015 05:08, "Sebastien Goasguen" <runseb@gmail.com> wrote:
>=20
>> Hi folks,
>>=20
>> Several folks on this list representing their company=C2=B9s interest =
shared
>> with me their fixes/features plans and hopes.
>>=20
>> I believe we can use this to build a solid roadmap for our project,
>> something that we have never had.
>>=20
>> I captured a lot of bullet items and tried to categorize them to =
start
>> building a roadmap.
>>=20
>> You can see the document on our wiki at:
>>=20
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap
>>=20
>> I would like to call everyone to make this page a great living =
document
>> that will be up to date and help us drive cloudstack forward.
>>=20
>> First order of business would be to add description to each item and =
if
>> you are working on it or would like to help out, write your name down =
!
>>=20
>>=20
>> Cheers,
>>=20
>>=20
>> -Sebastien
>=20
>=20
> Find out more about ShapeBlue and our range of CloudStack related =
services
>=20
> IaaS Cloud Design & =
Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge =E2=80=93 rapid IaaS deployment =
framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Software =
Engineering<http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure =
Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training =
Courses<http://shapeblue.com/cloudstack-training/>
>=20
> This email and any attachments to it may be confidential and are =
intended solely for the use of the individual to whom it is addressed. =
Any views or opinions expressed are solely those of the author and do =
not necessarily represent those of Shape Blue Ltd or related companies. =
If you are not the intended recipient of this email, you must neither =
take any action based upon its contents, nor copy or show it to anyone. =
Please contact the sender if you believe you have received this email in =
error. Shape Blue Ltd is a company incorporated in England & Wales. =
ShapeBlue Services India LLP is a company incorporated in India and is =
operated under license from Shape Blue Ltd. Shape Blue Brasil =
Consultoria Ltda is a company incorporated in Brasil and is operated =
under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company =
registered by The Republic of South Africa and is traded under license =
from Shape Blue Ltd. ShapeBlue is a registered trademark.

=E2=80=94=20
	=3DFuns