Thank you, thanks for having me, so I'm Quentin, my name, I've been working a lot
around EEPF, but I'm not here to talk about BFF today, I've got the wrong t-shirt, sorry.
I'm here to talk about the open network fabric and how to build your cloud infrastructure
at home, not really at home, but on your lab, on your hardware.
So, in short, what this project does is to make on-premises cloud infrastructure easy
to set up and to run by sort of obstructing all the network part away.
So, we see about that.
So, can I first have a cloud at home and before we even see what we would need a cloud
for, let's go back to the origins of the cloud in a way.
So, initially, in the beginning, we had a lot of panories, libraries.
It was all of the glorious mess in terms of dependencies, right?
And people came up and said, let the be virtualization.
So, we got machines in machines, great.
But it uses a lot of resources, and it's slow sometimes.
So, people say, let there be containers, and we got the way.
The way it works great, but how do we orchestrate all these containers that we have?
So, people continue and said, what we need is a relationship with 700.
And everything that comes with it.
And we pretty much all know how it goes from here.
Everything got swayed simpler.
Good.
So, we've got all these projects from CNC.
That's the CNC influence, okay?
And the good part is that it's mostly software appliances,
and there are solutions to help in the sense that there are cloud providers that you can use
to run this infrastructure for you.
So, you get the tip of the iceberg, which is nice.
You can run your applications, relatively easy.
And everything that's underwater is, yeah, that's good.
That's someone else's magic, really.
You don't have to care about that too much.
So, what you get from these cloud providers, typically, is that the virtual private cloud,
in which you have your nodes, and then containers.
And you can run your applications in these containers.
You can run everything you want.
You've got some isolation on the layer of freedom, like your cluster,
is not directly connected to the other tenants cluster, which is usually a good thing.
And you start to build your applications,
drilling with these virtual private clouds, the VPCs,
and then sort of they constitute the basic building blocks
for a modern cloud infrastructure in a way.
So, now, what if I want to run these sort of lectures on my lab on premises?
What would you do that? Well, that can be a matter of course.
If you realize that actually buying your hardware, your GPUs, or whatever else,
is in fact cheaper than rent ticket from Amazon on the few months,
maybe it's just paid for.
So, maybe you want to get on course, maybe you want to reduce latency for your applications.
If you got some hard constraints on latency,
if you had some requirements in terms of compliance,
you really need to process your data on the site.
Well, in that case, you may need to get everything back to your company's hardware.
So, some use cases, everything where you have some very specialized cloud application,
everything, smart cities, IoT, what did that for?
Let me see. Ah, this one.
If you want to do some modern training, inference,
closer to the source of data, that makes sense to have something maybe not with a cloud provider,
but something you get a hand on.
So, we're back to the previous diagram, but this time,
you don't have just the tip of the iceberg,
with the whole iceberg just for you how lucky you are.
And it has to become, not someone else's magic, but pure magic.
Either you are a good magician, and that's right.
I see plenty of good networking magicians in this room.
That's awesome.
But it's not a case of everybody, right?
And you can be a good magician, or your life is going to be much more difficult.
Fortunately, there is a third option coming to the topic at this talk,
which is to turn to the open network fabric.
So, what do we do?
We try to deploy this cloud infrastructure, just like we had at the cloud providers,
on community hardware.
And so, we consider branded all white box switches and servers.
We've got a hardware really.
On top of that, we want to handle everything that you need to network.
So, the connectivity, getting also some observability in terms of the flows that come and go.
Some services, some basic things, something to DHCP, firewalling, everything that comes around,
and network fabric, really.
And on top of that, we also want to provide a way for users to really create,
and use their virtual private clouds directly on their hardware,
just like they would be able to do with AWS or GKE or Google Cloud or whatever.
So, what do we use to reach that opportunity?
So, first we've got the community hardware.
So, the open network fabric today,
spot switches from the Risticia, Dell, EdgeCourse, the Micro,
there are more to come, that's a few brands that we spot right now.
And we start by deploying a network operating system on the switches.
And then we use this Sonic, which is open source,
it was based on Tibian, it was initiated by Microsoft,
but now it's hosted by the Linux Foundation.
So, there's no vendor looking.
It's minimalist, modular, hard.
And so, pretty much everything that you need to do the job.
And you get your switch with this operating system that can do pretty much everything you need.
And to handle these several switches once they are set up,
we are using Kubernetes as a control plane so that your infrastructure looks like.
And it feels like a Kubernetes cluster,
with which many people nowadays are pretty familiar.
So, you got your email files, good old email to do,
get out to do infrastructure as a cloud.
It integrates very easily into any cloud,
native type that you might have.
So, really, you can stream to Grafana or the classics in a way.
And the reason that we get is this fabric and top of the community hardware.
And also, the VPC API offered by the open network fabric,
which you're able to create directly your own virtual private clouds.
And you're able to just, to split your hardware, not physically, I mean,
to split the use of your hardware for different applications,
or for different VPCs to different tenants.
And just the way you would do that with another bigger public cloud provider.
So, in the other hood, we're using a VXDand-based BGPE VPN.
And we've got this VPC API coming with policies and services.
So, we've got some simple peering API if you want to connect different VPCs
to allow the VPCs from one to connect with the other.
We've got IPAM, DHCP, DHCP relay.
More things will come in the future.
That's more as what we have today.
And the workflow looks like this.
So, first, you need to get your hardware.
And to why you're switching and servers,
I'm sorry, the software doesn't handle that part for you yet.
So, you've got to still plug the cables.
This is an example of a closed network typology.
So, you've got the spines, which are the top leaf switches and the servers.
And you need to write some wiring diagrams,
which are actually partly generated for you,
but you've got to complete it to make it match your typology.
And you've got to write some metadata, which is mostly the description of the switches.
So, for example, describing the list of the ports at L and your switches.
Then you want the fabric, you know, the fabric.
And all of the switches are automatically bootstrapped for you.
The image is the switches.
It's configured in a way that the connectivity is enabled between the different machines on your network.
And I think the marketing term is zero touch provisioning updates,
maintenance of the switches once the fabric prints.
So, you don't have to really touch anything on the switches.
You don't have to configure the switches manually.
And that's great because you get your VPCs with nearly zero network knowledge required.
And that's what we want, that's good.
In addition to the fabric itself,
so part of the project is the gate where as well,
which is so it's written work in progress,
which means that we're getting started with implementation.
I think it compiles.
I'm not sure if you want to see it.
It's getting there.
So, that's the same idea.
We're using community hardware, X86, ARM servers.
We use flat car as a base digital to run the fabric.
DPK on top of that.
And we're using a rust to implement,
so we've got a set of rust bindings on top of the DPK library to implement our packet processing.
The idea is to get something to connect the fabric with everything outside very fast, very quick,
leveraging hardware flows, getting a good throughput,
and also getting a number of services in the future.
So, everything you can imagine on that,
can be not, can be QOS, can be fire warnings,
so maybe it's a recap, I want day, who knows.
So, a lot of things that we want to do,
and that we come, some of them this year, some of them maybe later.
So, what does it look like?
So, this is a demo, not interactive, just screenshot, sorry.
But before that, I'm afraid we need to talk about the elephant in the room.
The project is open source, not 100% open source yets.
In the sense that we do not support as of today,
the upstream version of Sonic.
So, we don't work on Sonic ourselves,
but we shift a Sonic image with a project.
If you want to test it, you need to register with hhhh,
which is the company behind the project,
and not because we want your details,
where, for example, when the company are happy to get them,
mostly because we need to give you credentials to get the broad commitment,
which is the one we support,
and the reason is that the first potential customers
who are interested in both come,
and we haven't spent the time on sporting upstream Sonic yets.
But this is definitely something that we want to do in the future.
And also, because not everybody yet in the company is super familiar
with the open source aspects.
There's a bit of confusion if you look at the docs,
there's hhhhhhh fabric everywhere,
not everywhere, but in a good number of places.
That's actually the same thing as the open network fabric today.
So, there's a bit of confusion,
but we're going to clear that in time,
as soon as we can, I hope.
So, this is some part of the pleasure for the demo.
We've got two switches.
And the number of servers,
we really care about the first two ones.
And we want to be part of the fabric on that,
and create some VPCs and connect them.
We first need to install everything and deploy a Fabric.
So we registered the package repository with the credentials
we got because we didn't need this vote come so
they can manage today.
Winstall, can you see Microsoft, yes, we install this.
We don't load the installer for the Fabric.
And we initialized the Fabric what we get is a Fab.jml file
that contains information about the Fabric that you want
launched like the base template for the topology
for these sort of things.
And then you generate the wiring diagram so
you get the template for a wiring diagram that you
may need to edit to adjust the topology in that case.
That's the virtual lab that I've been running.
So it's already with no additional edits required.
And then you launch HHFard, V-Lab, and then it downloads
all the different components to install the switches.
It download the images.
It feeds the switches images, push it everything
to the hardware, boots, the switches, and runs the Fabric.
And once this finishes, you're all done.
So in that case, in the virtual lab,
you get several virtual machines for the switches and servers.
But it's all set up, basically.
So you can connect to one special node,
which is the control node that connects
to the different pieces of hardware.
And we should can SSH, and for example,
the list information about the switches.
So I won't go through the details here.
So we are picking up a bit short on time.
So the next step is just to create your VPCs.
So not that we're using cube control for that.
We've got a cube control plugins.
So just cube control for Fabric, VPC,
create the name of your VPC, the subnet
that you're using with DHCP.
Sorry, not the subnet you're using.
And also the DHCP starts address, and the VLAN ID.
And your VPC is creating, and that's it.
And then you need to attach it to a connection
to the connection is a bit of a object
that represents more or less a wire on your topology.
And you still need to connect to the servers
to make sure that the server is a connected to.
So we've got a small utility here to do the bone connection
between the different interfaces that we're using,
because these two servers, it was maybe not clear,
are multi-homed in that example.
And then we can ping one VPC from the other.
And we know actually it doesn't work yet.
There is a very less than that is required.
We need to p-the two VPCs together.
And once you p-them, you can ping them.
VPCs are connected, and we have our magic.
So amount of times.
So thank you.
Do check out the project if you like,
and contributions are welcome, obviously.
And thanks for our attention.
Thank you so much.
APPLAUSE
Any questions?
You mentioned your work on BPS, but the gateway
is running DPDK.
Can you explain what you didn't choose DTP, for example?
Oh.
So I used to work on BPS.
I'm still doing BPS on the side, but I'm no longer working on BPS
for work.
So this has nothing to do with BPS.
I've got a wrong shot.
Sorry.
It's that way, why did you choose DPDK over something like
extra important?
Why did you choose DPDK, because we want to do some hardware
of loads at some points for the gateway.
So I'm working mostly on the gateway,
naturally, on the fabric myself.
And we're interested in hardware of loads,
and that's not something that you really get today
with BPS and BPS and BPS.
Can you please wait for a second to be fair
and have other people ask questions then?
OK, so in one of the last slides,
you show that you control this fabric from Kubernetes
and so on, and you have CRDs for that.
So that means in this whole picture,
you have somewhere a separate Kubernetes
cluster that has flat connectivity to your whole infrastructure
so that you can control it, or do your control it from the inside,
but then my question is, how do you deal with this separation?
If you have a Kubernetes cluster that needs to have a flat access
to the switches, so is there something, you know?
So where is the part that you are not showing us?
Is it some infrared outside, or is there some magic
from the inside and it does to complex the server?
So I think, I'm not sure, I understand the question.
So my question is, you have QCTL fabric
to control the fabric.
So where is this Kubernetes cluster that controls the infra?
It's running, that's part of the fabric.
So that's not the Kubernetes cluster that you might end up
working with for your application, that makes sense.
So it's one of those servers that is in the picture that belongs,
it controls the fabric.
And one of the servers that you get in the end
where you run your VPC, you can deploy
another instance of Kubernetes, high-level instance of Kubernetes
that makes sense to run your traditional Kubernetes workflow.
So you go, OK, so that would be then Kubernetes
that I deploy on the server that we deploy the Sparkle with.
Exactly.
OK, sorry, we're out of time.
But I'm sure you can see it all the way.
Thank you.