Season 2 CloudNets
Episode 1 Optics
Let’s about the optics that go into your router. We’re going to talk about ZR and ZR+ and open XR and stuff like that.
So this is what you need to know about optics coming through the router: longer reach, leaner infrastructure, and lockout or the non lock in nonproprietary open system that allows to choose different vendors for your infrastructure.
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi everyone.
And welcome back to CloudNets where networks meet cloud and today we’re going to talk about optics.
Yes, optics.
No, no, don’t go away.
I know you hate optics and we’ll talk about it in a different video.
But today we’re going to talk about the optics that goes into your router.
We’re going to talk about ZR and ZR+ and open XR and stuff like that.
And for that we have the expert for optics and everything that goes into a router… Run.
Hello?
Okay.
So so ZR and the family, you know, other than being an evolution of ERLR, the best range.
What are we talking about?
We’re talking about putting optics into the router.
What’s going on?
What do we need to know?
How many things do we need to know?
3 things.
Yeah, that’s the new 3.
3 things.
The zero optics brings location, location and location to the game.
No, that’s a different, that’s a different video.
Sorry, that’s a different video.
It brings in a longer reach a distance that you can push the optics outbounds is longer with ZR than previous technologies.
Talking about roughly 100 km give or take and that depends on certain variables.
The bandwidth can also change accordingly and the distance can kind of expand according to that.
So that’s a longer reach.
The second is the fact that it’s leaner.
There is one equipment that can be excluded from the network which currently exists as a
DWM device that is connected to the router.
So by plugging in the ZR optic.
Getting this kind of range into the existing router, you can actually dismiss one device altogether.
So instead of having the optics coming out from the router into a terminal, we have everything in a router, all that, all that built into that, that transceiver.
The third item, and that’s perhaps the most interesting when it comes to ZR is the fact that it’s an open standard.
Lock out, yeah, locking out the opposite of lock in, right?
It’s the opposite of lock in.
Typically when you have a transport mechanism, an optical transport mechanism, then you will have optic coming from one vendor on one side of the line and the same vendor on the other side because there is some proprietary coding to the to the line
ZR came and and kind of standardized on this.
So you can put a plug from vendor A and another plug from vendor B on the other side and that will work.
That’s a very big thing and freedom freedom for all, but that’s not all of it because ZR breaks down to three different form factors.
It’s DD QSFP, OSFP and it’s Open XR and these three form factors, all of them are coming from various vendors and all of them are being implemented, it plays an active role into the actual device, their physical machine that you’re plugging the optics into it.
And and when it comes to a standard router, you need to kind of pick and choose.
And some vendors are promoting different technologies when it comes to our Network Cloud solution, which is essentially open, then you can have one ODM building with an OSFP and another one building with DD QSFP.
And another building with Open XR.
And they’re all valid and they can all coexist in that same solution.
Wow, that’s great.
Okay.
So this is what you need to know about optics coming through the router the three L’s, which are not location, location, location.
You need to think about the longer reach.
You get about the leaner infrastructure you have because you eliminate the need for an external ODM optical device outside your router.
And you need to talk about the lockout or the non lock in nonproprietary open system that allows you can choose different vendors for your infrastructure, different vendors, different form factors, different everything.
So thank you very much, Run, for explaining.
Thank you for watching.
See you next time on
Episode 2 Optics 101 for Network Engineers
Let’s talk about optical modulation and some basic features of optics that us networking guys need to know.
We’re talking about wavelengths, frequencies, about different modulations, and DWDM.
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi and welcome back to CloudNets, where networks meet cloud.
Today we’re going to talk about optics again, and no not Run.
I will it’s okay.
I will take you today.
I know.
Yeah, let’s try it to do it alone.
Okay, so today we’re going to talk about optical modulation and some basic features of optics we the networking guys need to know when we talk to the optical guys.
So when we talk about optics, we talk about light and light as we know is a wave.
What’s that?
I know I know light is also a particle but we’re going to talk about light as a wave today.
Okay.
So light is a wave and as any wave it has a wavelength which is basically the the speed of light divided by the frequency of the light and the wavelength in all the communication run from 800 nanometers to 1600 nanometers.
And and it’s important to know because we need to know for an optical device which wavelength it works on.
So other than the wavelength we need to put digital information on top of the wave.
So how do we turn the sinus wave into bits ones and zero.
There are different ways to do it.
The most basic way is NRZ now return to zero in which we take one as a wave and zero as non wave.
So it’s simple that the length or the period of time in which we transmit a bit is either a science wave or nothing.
This is NRZ, one of the non return to zero.
There are also more sophisticated manners like PAM4 in which we also use the amplitude of the wave, the height of the sinus in order to deliver bits.
So there are four heights.
There are four levels of wave and each level divides each level, describes two bits.
So it’s either 00, 01, 10, 11.
And we have four levels and two bits per symbol.
Again, symbol is the time in which we transmit a single wave but when it comes to zero and zero plus we talk about a much more sophisticated optical system.
First we use different wavelengths DWT and dense wavelength division multiplexing inside the model.
So it’s not only a single wave we transmit its multiple waves and each wave use a different wavelength because the light can travel throughout a single fiber in different wavelengths without each wavelength
interfering with the other.
So we get a modification of the data as the number of wavelengths over lambdas we put into the fiber.
So this is the WDM.
Another thing we do in and there are positives coherent optics.
That means we go from PAM4 or NRZ to QAM.
QAM is Quadrature Amplitude Modulation in which we use not only the amplitude of the wave but also the phase, the phase is this shift from the original sinus wave.
We can shift it to the left or to the right in a certain degree that is measured in degrees 0 to 360 in which we return to the same wave.
And if we put the aptitude and the phase, the angle on the graph and say the amplitude is the distance from the zero axis and the phase is the angle from the X axis.
We can paint or we can draw certain symbols.
Each symbols represents a certain amplitude at a certain angle or phase.
And in QAM 16 for instance we put 16 dots or 16 symbols over there.
And those 16 symbols represent 4 bits.
So each symbol, each period of time in which we transfer given information, package transfers 4 bits not 2 bits
like in PAM4 and not a single bit like in NRZ, more than that we use 2 polarizations.
So wave length or a light signal can go like this or it can go like this, figure of speech.
This doubles the amount of capacity we can put in a light.
This is the authorization.
So we use QAM 16 DP for polarization and we can transfer 8 bits per symbol.
So if our symbol rate for instance, for instance is 50 giga symbol per second.
So we can that means that in QAM 16 DP we can transfer 400 gigabit per second which is a lot for this symbol.
Right?
And this is what’s new in ZR and ZR-plus.
So what did we have today?
We talked about wavelengths. We talked about frequencies. We talked about different modulations.
We talked about DWDM and basically this is it.
Thank you for watching.
You should have broken it into three points.
That would have been much, much easier.
Yeah.
I’ll explain.
Thanks.
Thank you.
Next time.
Episode 3 TIP DDBR
We’re going to talk about TIP DDBR, Telecom Infra Project Distributed Disaggregated Backbone Router and the RFI that went out. And hey, we got a ribbon, so we need to talk about it.
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi and welcome back to CloudNets where networks meet cloud.
And today in CloudNets, we’re going to talk about TIP DDBR, Telecom Infra Project, Distributed Disaggregated Backbone Router and the RFI that
went out. And hey, we got a ribbon, so we need to talk about it.
And as always, we have the experts for acronyms, Run.
Thank you for joining Run. Let’s talk about the DDBR process, TIP and everything we need to know about this new vision.
Okay, first off, it’s a process within the DOR, Disaggregated Open Router project.
And there are 3 things which are important to note. Yeah, in this case it’s 3 things.
Usually we have more, 3 this time.
So first step is the TIP has taken the definition of a distributed router, what was previously defined as a distributed disaggregated chassis, coming from the OCP and has taken it a step further. In this case, not talking about the architecture,
how the boxes are connected one to the other, but what kind of functionality is running on top.
So there’s a clear definition of the router and what does the router need to do as a function that
runs on top of that infrastructure.
So, it’s complementary to the Open Compute Project.
Yeah, definitely. A lot of the things that TIP is doing is complementing what OCP has defined put in place.
Okay, second thing, point number 2, TIP has a process and this process comes to define what are the attributes that are needed to be performed. There’s an RFI which is being issued, vendors respond to this RFI.
And who won?
Exactly, the industry, that’s the nice thing about it. The industry wins the game because it’s an open standard.
Win. Win. Win.
It’s a triple win. Obviously it’s a triple win
And then it goes up into a testing stage, after which there is a plug fest. Yeah, kind of a plug fest.
Yeah. The definitions of the testing and the testing themselves. And eventually there is a certification coming from TIP that is being awarded. Same process went to Open RAN as well, right?
In a way back. Yeah, a while back.
DBR has started later than Open RAN. Open RAN is much more
advanced and evolved into this and already in deployment, DDBR is a step behind and now we start
to see actual deployment.
So, DDBR is the next big thing.
It’s very big, it’s very complex and more interesting, at least for our end.
And then the third thing is the operators which are taking part in this, the RFI was defined by KDDI, Vodafone, Telefonica and MTN.
And there is a lot of participation from other operators as well into this. And what we start to see is that the deployment is not necessarily coming from these four, also from these four, but not only. And we start to see more operators worldwide
adopting the model of a DDBR and starting to implement various functions, various routing functions and others on top of that infrastructure.
Cool, cool, cool.
Excellent.
Thank you very much, Run. So the 3 things you need to remember about TIP, about DDBR and about DOR is that a it’s a step further compared to the OCP DDC Distributed Chassis from Open Compute Project.
It describes also the functionality, not only the architecture.
Second, it’s a process that started with an RFI and evolved into something that many operators can leverage from and can use. The operators are the windows of this RFI for that matter.
And third, are the operators themselves. So it’s not only
about the operator that initiated this process. We see that operators are enjoying the fruits of this process and leveraging this open standard architecture from Telecom Infra Project (TIP).
This is it. Thank you very much, Run, for…
My pleasure,
…this insightful input and thank you for watching.
See you next time on CloudNets.
Episode 4 ISSU
We’re going to talk about ISSU, In Service Software Upgrades. What’s new and how actually DriveNets can eventually let you upgrade your network without service interruption.
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi and welcome back to CloudNets, where networks meet cloud. And today we’re going to talk about
ISSU In Service Software Updates. Don’t go away. I know you think there’s no such thing as ISSU, but for you, lucky for you, we have the few experts to tell us. That’s me. What’s new and how actually DriveNets can eventually make you upgrade your network without service.
Let me try to explain, but do it in a few points
But I think I can break it down to three ideas. Okay? Three general ideas that we’re using here.
First is that ISSU, the concept of In Service Software Upgrade, does not work per a single box.
It simply doesn’t work. The industry
has been trying to do that for the last 20 years or even more. Failing?
Yes, failing. It’s always the case that ISSU is supported on this release and not from the previous one. From this one onward,
So it doesn’t work. So that’s pillar number one.
The second topic is that now we are shifting into making this ISSU function work, but towards a cluster. A cluster, an array of devices, CLOS topology, and then per each device, we can upgrade it. But the cluster as a whole is not upgraded at once.
Because the network function actually is not located on a specific box.
It’s located on all boxes. That’s the nice thing. There is no one point of failure
within the entire cluster, so you don’t need to fail it at any point. That’s point number two.
And point number three is what we call the CAL order the distribution of the chassis or the router onto multiple devices.
CAL stands for?
Cluster Abstraction Layer. Okay.
So once you have a software which is divided onto multiple devices and several devices which operate as a unified function, then you can carve out a part of that cluster, upgrade this part, and then bring it back in. So now you have two versions and both are running and you didn’t have any downtime. And then you can upgrade the other part. You can kind of mix and match or break into sub components, and therefore you’re reducing what’s called a blast radius into something which is minimal, hardly affected.
Which sounds familiar, it’s like the cloud?
In a way, yes.
That’s why we call the Network Cloud in a way.
Okay, so this is great. Three things you need to remember about ISSU or the new generation of ISSU.
One is that we no longer talk per box because it’s practically impossible to do it per box not working.
Two is that we talk about a cluster in which the network function does not reside in a specific box, but it’s a cloud shaped virtual container that contains the network function.
And the three, that’s specifically in DriveNets Network Cloud, we use the CAL, the cluster abstraction layer, which is kind of the evolution of the HAL the Hardware Abstraction Layer, which abstracts the entire cluster and
allows you to do stuff inside.
That does not affect.
Kind of a dividend rule.
Yeah, exactly. Okay.
That was fascinating, as usual. Thank you very much. Thank you for watching.
See you next time on CloudNets. Bye. Bye.
Episode 5 DNOS
Let’s talk about DNOS, the DriveNets Network Operating System. Why is DNOS important and how it’s different than just your ordinary network operating system?
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi and welcome to CloudNets where networks meet cloud. And today we are going to talk about DNOS, the DriveNets Network Operating System. And we have the DNOS expert, Run.
Hi Run. Hello, how are you?
I’m wonderful.
And I know why you are wonderful. Very happy. Recently, GigaOm published their GigaOm Radar and the DNOS, the DriveNets Network Operating System came up…well, first.
Kind of, yeah.
So let’s talk a bit about DNOS. Why is DNOS important and how it’s different than just your ordinary network operating?
Okay, it’s going to be three things. It’s going to be three things, but it’s going to be three by three.
Okay.
Because the first item is DNOS is three dimensional.
Okay.
It’s DNOS 3D. Why is it 3D? Because it’s distributed over multiple boxes.
Because it’s disaggregated, meaning it’s decoupling the control plane from the hardware plane. Hardware and software are separated and the third D is its DriveNets.
Okay, so that’s 3D.
Okay, so that’s the first thing about.
The bullet number one. Okay. Bullet number two is that the NOS the network operating system is more than just the protocol stack. Unlike the
iOS, cOS, JUNOS, SROS, you name it, which kind of carries the protocol stack within the NOS, DNOS is a bit more like Windows operating system. It’s an actual operating system, acts like a platform. It also includes the protocol stack, but that’s just one function out of many that can run on that operating system. That’s point number two.
Actually, even third party applications and networking adjacent like security applications can run on this operating system.
Exactly. Just like an operating system.
Okay, just like an operating system which is in the cloud.
Which is acting in the cloud. Now point number three is that DNOS as a network operating system is more than just a protocol stack. Unlike…
Wasn’t that point number two?
Yeah, that was also point number two, but it’s so important that I figured we should say it twice.
Okay, so actually the three things you need to know about the
DNOS, the DriveNets Network Operating system is one, that it’s a 3D system, it’s disaggregated, it’s distributed and it’s DriveNets.
Correct.
Second is that it’s like an operating system, much more than just a protocol stack.
Like a platform. It’s a platform.
It’s a platform. Okay, so three points.
Thank you very much. Run. Now we know everything there is to know. Well, most of it, yeah, about DNOS. And see you next time on CloudNets.
Thank you very much for watching.
Bye.
Episode 6 800 is the new 400
So what do we need to know about this move from 400 to 800? 800 is real. It’s here, you can almost buy it. It’s a fairly smooth transition, having forward compatibility with the stuff you buy today. The Network Cloud, the architecture, is agnostic to the interfaces or form factors.
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi, and welcome back to CloudNets, where networks meet cloud. And today we’re going to talk about
800 gigabits per second because 800 is the new 400
and we have our expert for rates, any number.
Hi, Run. So what do we need to know about this move from 400 to 800?
Well, let’s start with the first thing. Let’s see how many we’re going to get. Okay, maybe three.
But the first thing is that 800 gig is actual it’s real, it’s really coming. We have the new silicon coming from Broadcom, the Jericho 3, the Ramon 3.
So the entire cluster, the entire fabric can be based on 800 gig interfaces.
It’s really actually happening. Okay, point number one.
Point number two is that the upcoming generation of silicon is going to be backwards compatible to the previous generation. So you can actually start with an existing cluster which is running
400 gig and it’s going to be compatible, future compatible to incoming interfaces of 800 gig. So you’re forward compatible and backwards compatible, kind of a future proof type of a solution.
The silicon white boxes you buy now, you will be able to use them in a cluster that is based on 800 gig. It will be like hybrid connectivity.
Yeah, you will have kind of hybrid, a potentially hybrid cluster of both 400 gig interfaces and 800 gig interfaces.
And the third, and perhaps even the most interesting and most important thing is that it’s interface agnostic. We have the
same interfaces that are available today, DDQSFP or OSFP, which are already supporting 800 gig. Those same interfaces and those same interfaces are going to be plugged onto the same boxes as we have today via the same form factor of transceivers.
So the Network Cloud as a platform, as an interface platform, is agnostic to what kind of transceiver is being plugged into it and supporting all of them.
So you don’t have to be religious about OSP versus QSFBD.
It will work.
You can be religious. I’m not against religion.
But you don’t have to. You don’t have to. Okay, great.
So three things you need to remember about
800 or the move from 400 to 800 gigabits per second.
The first is that 800 is real. It’s here, you can almost buy it.
The second one is that it’s a fairly smooth transition. So you have forward compatibility with the stuff you buy today. You will have backwards compatibility with what you will buy in a year or so.
And the third, and maybe the most important, is that the
Network Cloud, the architecture, is agnostic to the interfaces or form factors.
You can mix any and be religious or not.
Thank you very much. Run.
Thank you for watching. See you you next time on CloudNets. Bye.
Episode 7 End of Life
Today we are going to talk about the things we fear the most…End of life…which we, as network engineers, fear the most. So what do we do about end of life? With DriveNets’ Network Cloud you have multiple hardware options, the entire cluster is built upon standard interfaces so it’s very easy to replace or to upgrade the cluster with any box that adheres to those interfaces, and you can repurpose boxes in an exhausted cluster without the need for forklift.
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi and welcome back to CloudNets where networks meet cloud. And today we are going to talk about the things we fear the most…death. Well some of that.
End of life…which we as network engineers fear the most – end of life.
So what do we do about end of life?
We are sad. First off, we are very sad. But let’s try to break it down into 3 things where DriveNets Network Cloud makes a little bit of a difference.
First off, the hardware for Network Cloud is coming from multiple sources. So an end of life from one vendor does not mean the end of life of your network. It just means that one source is drained out but other sources are still active.
So no vendor locking, no vendor locking.
More control for the operators as what they put into the network and when do they put that into the network. Second is that the interfaces of the network cloud are standard.
Therefore an off the shelf device can be plugged in as long as it meets the standard. There is no kind of proprietary nature which only mandates
equipment to come from that same specific vendor and working with that proprietary interface.
So that’s point number two.
So a specific end of life is not the end of life.
It’s not the end of the world as we know it. Right?
And third is the enablement of network cloud takes existing boxes and purposes them for specific use cases.
Repurposing those same boxes onto a different use case is a possibility. So even if you have a cluster which kind of exhausted its life in one location, you can repurpose these boxes and run them as a different function in a different place in the network, thus extending the
lifespan of these devices.
Which is also good for sustainability and the Earth in general. Everything to do with extending the lifespan of your equipment is good for sustainability. It’s to do with the embedded carbon onto the boxes which kind of spans wider as the longevity of the devices extend.
It’s everything good in that sense. Now, it’s not that it cancels end of life, right? End of life is still there but you can call this kind of an afterlife of that end of life. Yeah.
Okay, that’s nice. So three things we need to remember about how DriveNets’ Network Cloud is the end of life. One is that you have multiple hardware options, we have multiple hardware vendors. So an end of life from one vendor means simply that you can buy the same product and same function from another vendor. The second is that there are standard interfaces.
The entire cluster is built upon standard interfaces so it’s very easy to replace or to upgrade the cluster with any box that adheres to those interfaces. And the third is that the end of life is not the end of life in terms of you can repurpose boxes in an exhausted cluster without the need for forklift. You can reallocate boxes to another place in the network or another function in the network and therefore prolong their life and the utilization of your investment.
Correct.
Thank you very much for this optimistic approach and thank you for watching.
See you next time on CloudNets. Bye.
Episode 8 Cloud Not
Today we’re going to talk about the cloud, or specifically why cloud does not matter at all. You don’t need to worry or think about the underlying infrastructure, the hardware, the upgrades, the versions, the connectivity, etc, etc. And these are all transparent to you. This all looks like a cloud, something that you know that is there, but you don’t really care what happens in it. So this is why the cloud does not matter.
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi and welcome back to CloudNets, where networks meet cloud. And today we’re going to talk about
the cloud, or specifically why cloud does not matter at all.
Because if you think about it, where does the cloud come from? Where does the world come from?
It comes from engineers that are too lazy to draw a detailed
explanation of what they want to draw. Back in the days when we wanted to explain
some kind of system or some kind of architecture, we drew the
important parts, like the clients or the servers, but everything that
is in between, everything that connects them, the network, for that matter, was less important
for the understanding of the application. So we put a cloud instead
of all the lines and routers and switches, et cetera. And the cloud
means that this thing does not really matter, does not interest us.
In order to understand the application, what the service we want to provide, this
is exactly what we have today with the cloud or the network cloud.
It enables you to take all the infrastructure, all the underlying hardware and the
abstraction layer and the connectivity, et cetera, et cetera, and put it as a cloud, as something
you do not need to worry about. So you can focus on the applications,
you can focus on the network functions that run on top of it, you can focus on the
application and new services that you want to deploy and to provide your customers.
And you don’t need to worry or think about the underlying infrastructure,
the hardware, the upgrades, the versions, the connectivity, etc, etc. And these are all
transparent to you. This all looks like a cloud, something that you know that is
there, but you don’t really care what happens in it.
So this is why I claim the cloud does not matter.
Network Cloud is something that allows you to focus on what’s important and
neglect everything that lays under it. This is Network Cloud.
And this is CloudNets. And thank you, Run, the expert in drawing
clouds and other stuff, for helping
me in this video. Thank you very much, very much for watching. See you next time on CloudNets.
Bye.
Episode 9 Building a Cluster
How do you build a cluster with Network Cloud? The cluster is granular and built upon multiple boxes, so you can bring them with you, and find vacant places in existing racks to put it into and not have to have a dedicated rack for a new gigantic crowd.
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi, and welcome back to CloudNets, where networks meet cloud. And today we’re going to talk
about building a cluster, building a Network Cloud, which actually sounds like a
cluster headache. But we have Ryan, our new SVP of Infrastructure. Hi, Ryan.
Hi, it’s good to see you. Thanks for having me.
Great to have you on board. Thank you. So Ryan has a vast experience in building
network infrastructure, and he’s going to tell us how is it to build a Network Cloud.
Yeah, it’s a lot of fun. Actually. You know. It’s funny, you sort of come from the world of
monolithic, vertically integrated network hardware, and you come to this world, and I think it actually offers a lot of
really interesting benefits. Right. If you think about it from the beginning, you think about supply chain.
Right.
You think about the fact that if you’re running disaggregated hardware, you can buy it from just about anywhere.
You can make your choice about who you source it from, when you source it regionality. And it
gives you a lot of flexibility in how you populate your supply chain and how you deliver hardware to your colos.
So you’re not locked in to a single vendor. And while you select the solution, you still have
the flexibility to select multiple hardware. ODMs or vendors.
Yes. With supply chain realities being what they are, it’s phenomenally beneficial, especially now.
Okay. On top of supply chain when it comes to procurement and sparing and
building the cluster instead of the installation, do you also find benefits?
Because it sounds a bit messy.
I do, actually. One of the things that people don’t think about is if you’re bringing in a really large
piece of equipment, you have to think about big tractor trailer trucks and liftgates and being able to
get the gear into the physical cage with a white box. It’s coming out of UPS truck,
so that’s a lot simpler. And from racking and stacking gives you more optionality, too. You can
have patch panels and multiple racks, and you have shorter cable runs, and you can kind of
distribute your infrastructure throughout your entire cage or your entire suite, versus
trying to find half a rack or a full rack where you can put in your piece of hardware.
So there’s benefits there, too.
So, in fact, the fact that the cluster is granular and is built upon
multiple boxes is actually a benefit because A, you can bring them with you,
and B, you can find vacant places in existing
racks and put it into and not have to have a dedicated rack for a new
gigantic router. Right?
Yeah. And it makes your cabling simpler too.
Right.
You’re not trying to home run cables or patch cables between racks. You’re potentially terminating cables within a
rack. And that’s always, for me, at least, a lot cleaner.
Okay. And bear in mind, this is coming from someone who has years of experience
with legacy equipment and now has the benefits and
experience with DriveNets Network Cloud solution. So you have the
perspective of old versus new. And at the bottom line,
there are a lot of benefits of building networks like cloud, as we know. But
this is coming from the field. So thank you very much, Ryan, for that.
You’re welcome.
Thank you for watching. We’ll going to talk to Ryan again about the post
installation phase, but this is in another video. Thank you for watching. See you next time. Bye.
Episode 10 Network Cloud Operations
Now that we’ve established that building a Network Cloud cluster is easy, let’s talk about what happens afterwards because the operations guys are the ones that having been doing the hard work all those years, after the engineering plans and installation.
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi and welcome back to CloudNets where networks meet cloud. And today we’re going to talk
about the operational part of the cluster of the Network Cloud. And again we have Ryan.
Hi Ryan, thank you for joining. Do you remember Ryan and our SVP of operations with a lot of experience
in all kinds of operations and now that we’ve established that building a cluster or
building a Network Cloud is easy. Let’s talk about what happens afterwards because between us,
the operations guys, those are the ones that make the hard work
all those years after the engineering plans and installation.
So Ryan, what happens afterwards? How is it to
operate cloud-native networking infrastructure?
It’s different, but I think there are some benefits to doing it right. One of the things that I think
we always underestimate from a design perspective and have to deal with as operators is what
happens when things break. And one of the challenges that I’m sure we’ve all been faced with is
when we have a big vertically integrated chassis and something goes wrong, how do you figure out what part it is that’s broken?
Is it software? Is it hardware? What piece of hardware?
Is it root cause analysis?
Yeah, these things are really hard and not just root cause analysis, but also in the moment, trying to
restore service to your customers. Right. So if I’ve got a big chassis, it could be a line card, it could be an
optic, it could be a cable, it could be a fabric element, it could be a controller card, power supply.
Right.
All these different elements. And the only indicator that I necessarily might have
is there’s something wrong inside this chassis. If I’ve got a disaggregated model I can look at,
it’s probably pretty clear to me that there is a misbehaving box in the fabric someplace and I can just replace
that single box relatively easily versus trying to sort of replace discrete elements all the time.
So operationally, I think that probably speeds time to resolution for us. And I like that.
So basically you can isolate the cause of the fault and deal with
it much easier when everything is distributed than if
it’s a back plane or a card because there you cannot really physically isolate
the cause. What about upgrades and
maintenance windows? We have benefits there, right?
Totally.
Yeah.
I mean, being able to replace a fabric module, for example, right, I can pop out a two U box and pop a new
one in and just drain traffic off that element versus trying to replace a half
a wax chassis that requires a forklift in some cases. Right. That’s not a lot of fun.
So from maintenance perspective and an upgrade perspective, there’s benefits there too.
Okay. And bear in mind that in terms of blast radius, in terms of
the effect of different events in a cluster, this
could be very easily contained in comparison to a big chassis
in which everything is affected whenever something goes wrong.
Yes, definitely. Awesome.
So we are optimistic. Thank you very much, Ryan, for that. You’re welcome.
Thank you for watching. Remember, building a network like cloud brings benefits not
only in terms of innovation and savings, but also in terms of operations from
the planning and installation and throughout the operations the infrastructure.
Thank you for watching. See you next time on CloudNets. Thank you.
Right, bye.
Episode 11 The biggest disaggregated router in the world
For the season finale of CloudNets, we went to see the largest router in the world run by DriveNets. We shared 3 very important things and once you know these 3 things, you’re going to know everything about Network Cloud.
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi, and welcome back to CloudNets. This is CloudNets season two finale and we have our expert for season finale, Run. Hi, Run.
Hello, Run.
And this chapter is especially for you, switch huggers! We’re going to look into the largest router in the world, disaggregated router, right here in the left. Run, what are we going to see there?
We’re going to see three very important things. Once you know these three things, you’re going to know everything about Network Cloud. Top, top secret. And this is why we will need a key.
Okay.
All right. So here we go. Into the lab.
Let’s go into the lab.
Go right in.
It’s a loud lab. Yeah.
So three things we need to know about CloudNets.
This was super exciting. It’s a good season finale.
I’ll try to wrap it up. If you know these three things, you know everything you need to know about Network Cloud.
I hope you pay attention because this will not happen again. We got a one time permit to shoot this. Thank you very much for watching season two.
We’re going to be back with season three and some nice surprises. There’s a big something we’re going to talk about that we cannot talk about today. The other thing, but this is season three. Thank you very much for watching.
There’s a 360 version. We will also upload this so you can look not at us, but at the footage, because this is what you came to see. Thank you, Run, for everything you did for us.
It’s my pleasure.
Thank you for watching. See you in season 3. Bye.
Episode 12 A 360 degree tour of the largest disaggregated router in the world
For the season finale of CloudNets, we went to see the largest router in the world run by DriveNets. We shared 3 very important things and once you know these 3 things, you’re going to know everything about Network Cloud.
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi, and welcome back to CloudNets. This is CloudNets season two finale and we have our expert for season finale, Run. Hi, Run.
Hello, Run.
And this chapter is especially for you, switch huggers! We’re going to look into the largest router in the world, disaggregated router, right here in the left. Run, what are we going to see there?
We’re going to see three very important things. Once you know these three things, you’re going to know everything about Network Cloud. Top, top secret. And this is why we will need a key.
Okay.
All right. So here we go. Into the lab.
Let’s go into the lab.
Go right in.
It’s a loud lab. Yeah.
So three things we need to know about CloudNets.
This was super exciting. It’s a good season finale.
I’ll try to wrap it up. If you know these three things, you know everything you need to know about Network Cloud.
I hope you pay attention because this will not happen again. We got a one time permit to shoot this. Thank you very much for watching season two.
We’re going to be back with season three and some nice surprises. There’s a big something we’re going to talk about that we cannot talk about today. The other thing, but this is season three. Thank you very much for watching.
There’s a 360 version. We will also upload this so you can look not at us, but at the footage, because this is what you came to see. Thank you, Run, for everything you did for us.
It’s my pleasure.
Thank you for watching. See you in season 3. Bye.
Episode 13 Network Cloud, Better for Operations
We’re talking about operations because usually when you talk to operations people about disaggregated and cloud-native systems, they do not like it. Since it’s multiple vendors, it’s multiple building blocks, it’s a new thing to learn. And operations people will love to stick to what we have. But surprisingly enough, bringing the Network Cloud into your network actually means better operations, simpler operations.
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi, and welcome back to CloudNets, where networks meet cloud.
And today we have another off-season special, this time about operations. And we have our operations specialist, Shai. Hello. Hi.
Okay, surprise, Shai. Shai thank you for joining. Welcome to CloudNets. And we’re talking about operations because usually when you talk to operations people about disaggregated and cloud-native systems, they do not like it because it’s multiple vendors, it’s multiple building blocks, it’s a new thing to learn. And operations people will love to stick to what we have. But surprisingly enough, bringing the Network Cloud into your network actually means better operations, simple operation and Shai. How come it’s counterintuitive?
How come? Well, first of all, thank you for having me here. I’m very excited. I think that, as we always do, there are three things, important things to remember. We have high availability, fast recovery, we have fewer network hardware elements and no more forklift.
Okay, let’s talk about it. Let’s talk about the first one. First one is high availability and fast recovery. And because we are using a cluster, that means that every element in our cluster is backed by another one. If it’s software or hardware, regardless of that, if it’s failed, the whole cluster, the whole system will continue to operate seamlessly. And on top of that, you can replace each and every element without doing any scheduling in your network. So no service interruption while maintenance. And also the function does not reside in a specific box. So basically you have unlimited redundancy, unlike systems that call themselves no single point of failure, which actually usually have a single point of failure. Okay, so this is one. Exactly right.
Okay. Number two, fewer, harder elements. So we know when you have traditional networking functions, you usually will have up to 20 different boxes. You have to maintain 20 boxes, and that’s not including the security elements. So you can imagine when those operating system guys are trying to maintain this complex network, it’s a problem. Yeah, it’s a skill set problem, it’s a planning problem, it’s a maintenance problem, it’s a spare part problem, it’s multiple problems. It is an issue, and that’s exactly what we solve. Our Network Cloud uses only two types of white boxes. That means you can build any network function using those two boxes, any network function at any size, at any site. Basically, those are the same boxes that are stacking up and creating different sizes of clusters. So it’s simple, so you can understand it will reduce, as you said, the complexity of the planning, the procurement, and also, of course, operations. Okay, that’s great.
Number three, number three, no more forklift. No more forklift. You can scale your network seamlessly, just add another white box. You don’t need to take the whole chassis and take it out and put in another one in the middle of the night, in the middle of the night, in hours, crazy hours. Just add another white box and that’s it.
Okay. So I think if you’re an operation people and you watch this, it makes sense. There are three things you need to remember about Network Cloud.
One is that it has inherent high, higher availability. So the function does not reside in an actual box. So it can move from box to box and basically it will not fail almost never. So for anyone that suffers from outage anxiety like me, these are great news.
Second is that you have fewer boxes, fewer types of boxes. You need to learn, you need to maintain, you need to spare and plan. This is great news for operations.
And the third, and I think that the most exciting one, is no more forklift upgrades. You don’t need to replace big shots with even bigger chassis. No need for this overnight forklift procedures. So all you have to do now is learn the intrinsics of Network Cloud and move on to your next challenge.
Thank you very much, I for joining. Thank you for watching this additional off-season special. We’ll see you next time. This will be probably season three. Thank you. Bye bye. Thank you.
Episode 14 Why include DriveNets in your next network RFP
DriveNets Network Cloud, changes the operational and economic model of the network, allowing it to scale capacity and services much faster while increasing service provider profitability.
Listen on your favorite podcast platform
Listen on Apple Podcasts
Listen on Spotify
Full Transcript
Hi and welcome back to CloudNets, where networks meet cloud. And today we have a special and off-season special. We’re going to talk about how you can convince your procurement team to include DriveNets in your next RFP. And for that, we have the off-season specialist. Specialist, Run, thank you for joining us from the off season.
So what do we need to know in order to convince the procurement team to include and choose DriveNets in their next RFP?
All right, well, essentially DriveNets is a cloud model, right? And the cloud model means which means nothing to procurement, but it means okay, three things. Three things.
Okay, so the first, the one thing that we’re talking about is that the cloud is a shared resource. The same amount of hardware, the same type of hardware does more than just one thing, which you have in a monolithic model. So you need less hardware. Less hardware, or the same hardware does more bandwidth, more functions.
Okay. The second one is that you have better granularity so you can grow your network at a level that allows you to take the capacity of what you actually need, so you actually pay for what you use. Cost avoidance – AKA pay as you grow. AKA pay as you grow. Okay, that was the second one. That was second one, yeah. Now the first two, now the first 2nd is about having two box types. The same two devices will construct every type of network element that you need. So you don’t need whole inventory of different devices, different hardware, different chassis, different scale, different vendors. All that is avoided. Hardware consistency across, all across the board. That means that it’s simpler to manage. Simpler to manage and costs a lot less to manage a smaller pool of devices. The second two would be the brand price. When you go and get a branded device, regardless of who the brand name is, you pay for the brand, you pay for the sticker. Right. When you take a white label device like the white boxes that we are using, you don’t pay for that. As simple as that. It’s the same hardware underneath the hood, but you don’t pay for the actual logo.
Now can we have the third point? Yeah, now we’re going to have the third point. The third point is about having dual vendor. Dual vendor. Not just that, you have vendor A and vendor B, and they can provide almost similar devices. So you can use this one or this one. You have multiple vendors providing the same device, the exact same device. So you can help with supply chain. Supply chain all over the place in terms of controlling your supply chain. Multiple devices coming from different places. And it’s the exact same functionality. It’s the exact same hardware coming from two different sources. Okay, that was the third.
And then the second third is talking about longevity. When you have a model which is so flexible it can exist in your network for a longer duration. So everything to do with the depreciation of the hardware is extended. If you had hardware that lasts in the network for, I don’t know, five, six years now, you can extend it to ten years. And overall, the depreciation of the hardware is now span over a longer period. So over a year, over year, you pay less. RFP will be. Further down the line. So it’s 123 123.
Okay. The three and three things you need to know in order take me to your procurement team and convince them to select DriveNets or at least include us in the next RFP are
One, it’s a cloud architecture, which means shared resources, which means the same boxes do more. So eventually you need less boxes to do the same.
Two is the granularity of the scale. Basically, you can scale up in very small quantities and you pay as you grow.
Three is the fact that you have hardware consistency across your network. It’s basically two types of white boxes. So management, the procurement and the spares. And the inventory is very simple. Four is you don’t pay for the sticker, no brand premium because you buy white boxes, which are as good as, but without the brand. This was four.
Okay. So five, you have multiple vendors, so you can create competition between them, but you also control the supply chain, which is a big issue nowadays.
And six, five, I don’t know. The last one is that doesn’t matter. It’s almost three. Yeah. Longevity of the system. The system exists more time. So your next RFP is further down the road and the depreciation of the CapEx is longer. So basically less cost. But six things, that’s got to be a special.
Yeah, yeah, it’s a special. It’s off season special. So we took the time, and I hope you are convinced, I hope you can convince your procurement team, and we’ll see you in season three. Season three or in another special, maybe before season three, but season three is also three things. Yeah. Okay. Thank you very much for joining. Thanks you for watching. Happy holidays. Thank you, Run. Let’s go back to our day jobs. Yeah. Okay. Bye, guys.