The Cloudification of Service Providers

The next time you're in a data center working on some big iron routers or some core switches, I want you to do something for me. I want you to just swap out one of the line cards, upgrade it for me on the fly to a newer one. You know, super quick, no one realizing it. And that's a pretty ridiculous thing to say, isn't it? But I wonder if that's the kind of agility and speed, speed of upgrade, speed of change that we're heading toward in the service provider networking space.

In fact, some say the telecom industry is going through a major transformation right now referred to as cloudification, and it's not just a buzzword.

It actually represents a fundamental shift in how telecom services are delivered and managed.

So with me today is Nina Bargisen, returning guest, an experienced network engineer and architect having worked on some of the largest provider networks and content delivery networks in the world.

Her recent blog post, "The Cloudification of Telcos and the Evolution of the Telecom Ecosystem" appeared on the Kentik blog just a few months ago. And in today's episode, we'll be unpacking some terminology and discussing exactly what cloudification in the telco industry is all about.

My name is Phillip Gervasi, and this is Telemetry Now.

Nina, welcome back to the podcast. It's been, I think, months since we've had you on, so long overdue. Thank you for joining today.

Although I talk to you every single day personally because we work together, so we're in the same Slack channels, and we're in about seven hundred and twelve Zoom meetings per week together. But for our audience's sake, would you mind giving, us a little bit of an introduction of who you are, your background, especially in the context of what we're gonna be talking about today on today's episode.

Okay. Hi. I am I'm Nina. I work with Phil here at Kentik.

But before that before I joined Kentik, I was building networks. I was building the Internet.

Always worked on in that specific area between connecting the in the networks that create the Internet.

It's the peering parts. It was dealing with traffic, and I've done that for ISPs, Internet service providers, and I've done it for, content.

Latest, I I, I worked with Netflix when they were doing their global expansion and building the network in Europe and working with all the ISPs about getting the, servers into into the network. So the telco and Internet industry has been my home for the past twenty years.

So, so that's, that's what we're gonna talk about today.

Well, not not my year there, but what's going on right now.

I Yeah.

You know, in those twenty years of experience, that's what's so valuable to me in talking to you today and also just learning from you, at work every day. You're not coming at this as like an analyst looking at industry trends. Not that there's anything wrong with that per se, but you're coming at this from the perspective of somebody who's built the networks that we all are familiar with. You mentioned Netflix and and then, of course, if you drop the names of several service providers that you've worked with, I'm sure we'd recognize those as well.

And so rather than kind of looking at the latest trends, you've seen the evolution over the past couple decades or so of how the Internet has changed, how, network operations has changed from a service provider's, perspective.

Now I say that because my background is predominantly almost exclusively in enterprise networking. And so when I think of cloud, public cloud, cloudification, and we're gonna define that in a little bit, I am thinking in terms of, like, just lifting and shifting resources to the cloud, getting my workloads into AWS or whatever, and, and then maybe, you know, kind of configuring some sort of connectivity between the two.

But that's not exactly what you mean. So let's start off by defining that term cloudification in the context of service providers.

Well, my definition is that that when you when you take, some functions or some systems that used to be something like, you know, if you take a telco, like, say, the cost the BSS system.

In in many telcos, when when I was working at telcos, that was a system that was, you know, the the the first code was written in, like, nineteen seventy two in Fortran, and it was running on big mainframes.

And and then they're probably still using parts of that system now at that company. Right? But it's when you take either that kind of systems or actual network functions and you put them into a cloud structure, not necessarily the public clouds. It could be the public clouds. Like, when we call call it public clouds, we talk about the cloud providers like AWS and Google and and those guys.

IBM, Oracle, they're out they're all out there now.

Or or on on a new system or a software that is built like a cloud that might be on-prem or might be outside. Doesn't really matter where it is because it's just running on the cloud technology or the cloud foundation.

And then the software that's building the system can run on that. That's kind of, like, very abstract way of thinking about it, but but it's so it's in in general, it's this software architecture, which by the way, I'm not a software architect at all, but this is this, you know, the foundation of it.

Okay. So when you're talking about cloudification in the context of service providers, you're not really talking about just lifting and shifting whatever applications I have sitting in my on-prem data centers and chucking it up into AWS or Azure. Now I'm sure service providers and telcos and CDNs, they they do that and they have done that, for whatever reasons. But really, what you're talking about are network functions that typically traditionally exist only on-premises, but for whatever reason, we're gonna migrate them to private or public cloud and hopefully reap some some benefits, some rewards.

But, but, Nina, public cloud is not a new thing, public or private for that matter.

So why is it that service providers, telcos, why are they kind of late to the game in adopting a cloud strategy for network functions?

No. It's it's not a new thing. I think it's because well, I think it's because, basically, a lot of the software they're using anyways have have been redesigned to support the run-in the cloud. So, I mean, it goes away all the way back to the vendors. I was talking, some, you know, some months ago, I was at a dinner, and I was talking to some friends who who worked, for Ericsson, like, ten years ago.

And they were working on actually cloudification cloudifying some of their, some of the software that that we use for building mobile networks.

So so back then so my friend was like I was talking about my blog, and she was like, why is this even a thing? I mean, we did this ten years ago. What what are you talking about? Why why is that why is that interesting right now?

It's it's over and done. And I was like, yeah. Well, you it's over and done for you because you did the software architecture change back then. But now we get the benefit of it.

So it seems like the the the network and maybe in particular, mobile networks becomes more modular, and you can have some running somewhere and some running somewhere else instead of having these, these hardware that you put together in in a back end that, you know, is run and need to to be very fixed.

Okay. Well, I I understand that you're not a software engineer or a software developer, but what do you mean that software architectures changed that allowed certain network functions to be able to move to the to the cloud?

Well, for one is that it can run on on, you know, on if it can run on a cloud, it can run on some other guy's computer because that's basically what a cloud is. Right? It's just some other guy's computer and not your computer, or it could be your computer, but doesn't really matter. That's the whole point of it.

So in the enterprise world, some of the reasons that folks are going to migrate applications and workloads to public cloud well, I mean, there's a variety of reasons. It really depends on the organization. But it could be it could be for fault tolerance, you know, hosting, applications out of multiple regions so you have that that increased resiliency. There could be, you know, the accountants getting involved and they wanna see more of an opex model rather than a capex model and just buying hardware and depreciating it over time.

It could be to make delivery of services faster. So, you know, in expediting the development life cycle and, and the release life cycle, that's a very common reason. But are those the same reasons and motivations for telcos and service providers, or is there a different reason? Is there a different motivation to move network functions from on-prem to the cloud?

I think it's it's a little bit the same, but I think the most important thing is that you get you get things divided into more modular in a more modular design, where you can pick and choose to run a model from one vendor maybe and then a model for another vendor so you get some more flexibility on on your actual functions.

And then yeah. So everything is not so so tidly tight around the same system. That why my experience in working in telco was that, you know, well, there were a hundred thousand systems, but there was there was one system that could not be changed, and that was sort of the the the the the backbone of it all, not the back not the backbone network, but the backbone IT system that came from that nineteen seventy two Fortran code and, you know, we you know, we've been added on and added on, and they have added, like, all the business and the operational functionality into the same system. And it was it was it ended up being a crazy monster that was very difficult to move away from. So that that that sort of what I see now is that that people can oh, I run, so I run my, my, I can run some of my my provisioning system in a cloud, and then I can still have my old fashioned customer system, and I can have an API between them, or you can do you can do match and match once more.

Okay. It sounds like the goal there was to improve, operations, operational practices, service delivery. So getting some of those applications that don't need to live on-prem into the cloud so they can be, I guess, utilized by multiple teams. You know, just making operations faster, more efficient, because there's certainly a lot of network functions that can't move to the cloud. So I'd love to talk about which ones can and and why, of course.

But I do know in the enterprise, you know, we when we think of modularity, as far as network modularity, we think of different systems.

A lot of the time, you know, I I I can recall studying for the CCNA, like, decades ago and and you have the three tier architecture.

We have WAN, we have campus, we have data center.

You have your access layer, distribution layer, coral, that kind of stuff. You're not talking about that kind of modularity though, are you?

Yeah. So this is this is this is just an observation I made when I did the research for this block was that it struck me that because because the software systems and the network, you know, the back end systems and everything has sort of been been more modular constructed, it would it was easier now to to separate not in in verticals because before you had a vertical where you would have, you know, the network in the bottom and then systems going upwards, and then you would have the products designed on the network, and then you would have the customer management, and then you would have the customer support. And then you would have salespeople, and it was all being in a vertical.

And what's happening right now and at least part of the telco industry in particular in Europe is that they're sort of going, we wanna cut it the other way. So they wanna build an infrastructure company, and then they wanna build a sort of like a product services definition company, or or they would just do service definition and customer ownership company, which is then the Servco, and then the Netco is the and the Netco can even be divided into a Towerco and a Fiberco co and then the network co as net co.

Okay. I see. So you're not necessarily talking about those, big components of the network. You're not talking about modularity in that sense, but more in, the functions of the network, like the underlay, the services that we run on top of it.

You even made a distinction between, fiber, you know, so, like, the layer one infrastructure that sense. That that makes sense. But, of course, for me, it begs the question why? Why why do we wanna But of course, for me, it begs the question why?

Why why do we wanna do that?

So then each of those companies can focus on running and building that company the best way because at least what have happens in in in some of the companies I know is that the the focus on running a really efficient network and do investments into the network to make sure that it's also ready for tomorrow, It's very different mindset that you have to do to create the services that people will wanna buy and run and and manage, like, gazillion end user customers.

So so the idea is to create the infrastructure that runs on the physical infrastructure as as one set of companies, which will then operate on a wholesale base basis. So they will have a few customers, which will be the Servcos.

And then the Servcos have all the customer relationships with the consumers and also maybe with business customers, anything with volume. And then they will have the ability to create new services as the market, sort of, starts to, ask for for the new services.

And they were less tied down to having what type of network they have because they can just go and buy the type of network they need from, from the different NetCos there.

And the point also be they don't have to worry about selling to, you know, customer a over in that town.

They don't have to worry about, wait. Do we have a fiber, or do we have a connect do we have a pipe into that customer so I can sell him anything? They don't have to worry about that because they will just buy that pipe from that network that has the pipe if they have if if if they don't have it themselves.

So it's sort of a simplification about what's going on on the infrastructure CIDR, so you're not building more than one pipe into consumers.

And then, you know, making sure that the the agility goes on because you don't have to think about the the the big and heavy changes you might need to do in a network if you wanted to create new services because it is now designed in a way that you can easily create new services without worrying about the network because you just buy the pipes.

Yeah. Right. And, I mean, isn't that the ideal for any network engineer?

I assume in the service provider space, but certainly in the enterprise space, is to be concerned with, you know, speeds and feeds and, just configuring, setting up, and building fat, dumb pipes. So they just get packets in and out super fast. You can put your applications on top of it and there's, there's no reliance. It's just the transport mechanism.

But that's not really the reality, especially in the enterprise. When we're talking about security concerns and regulatory bodies being involved and, various points of inspection and CASBs and overlays and underlays and tunneling, it's it's it's a little bit more complex than that, I think.

Yeah. But wouldn't it wouldn't you say then, without I'm not completely understanding enterprise, infrastructure that that much, but when you talk about that, you talk a lot about underlay and overlay. Right?

So I think the net codes is so much, you know, those are the underlay providers.

And there might even be a layer of in the in in in the serve code that they will be sort of like, we have an underlay product here.

And then, oh, and then you can buy this this thing or somebody else can sell you this thing to do to create your overlay.

Oh, yeah. And, I mean, before I left, field engineering, if you wanna call it that, I was selling and and building SD WANs all the time. That was the hot ticket five, six, seven years ago. And what I was doing essentially was selling you, the overlay network, the control plane, the tunneling protocols, whatever we were using to pass your traffic over an underlay. And it was just whatever service providers were in the area, usually who were the cheapest.

And all I really cared about were things like reliability.

I cared about bandwidth and I cared about latency. Beyond that, I really didn't care who you were.

I mean, I I would do my due diligence from sometimes to make sure that, you know, my three or four last mile providers didn't all converge in the same c o three miles up the road. That's a problem. But, otherwise, I I just didn't care.

And then maybe you would get an SLA. Right?

You know, so, like, you can't have delay here and there and, you know So then the modularity that you've been talking about, and, ultimately, the, the reason for clarification of telcos and service providers is really it's it's operations focused.

It's operationally focused in the sense that it allows kinda like a division of labor. And so now, a telco can just focus on just getting packets in and out really fast and not being concerned with things like fragments and TCP resets and and things like that. They're just gonna focus on that underlay and then say, hey, mister customer, here's the pipe. Go for it. Right? I mean, that's really the whole point of modularity is to divide up the labor, focus on that component, and then sell it as a commodity.

So one of the analogies that I make, I think, like every other podcast that I'm on, and I'm sorry to the audience for doing this to you again, but I I mean, I like in the network or at least the the the underlay network, the the speeds and feeds component of our network to, like, the the plumbing in our house, in my house at least. I don't really care that much about the plumbing. I care about what it does, which is provide water to my shower, into my dishwasher, into the sinks, and things like that.

But I'm not so concerned necessarily with the plumbing. However, if the plumbing doesn't work right, well, then, you know, we have a major problem.

But, certainly modularity in this entire thing is about I mean, it's these are typically for profit companies. So there's gotta be, money at stake in the sense that this makes them, better suited to meet the demands of the market and therefore turn a profit better.

I mean, I imagine that's ultimately the goal here.

Right? Investors.

I I don't understand. What do you mean?

Investors. Like, I I think another big part of the of the of the split of the different companies is to make the the the network comp the infrastructure companies more attractive for long term investments, like private equity people buying up. Yeah. And and putting their money into something they will get their money back, but it might be a longer investment because we're talking about really expensive gear here. We're talking about, you know, big routers. We're talking about fiber in the ground, which is when you when you invest in that and you look at that and you built that, you're looking at, like, twenty or thirty years, you know, lifespan of of the of that infrastructure. Right?

Sure. And, you know, typically, very long term investments, like that, especially in a commodity market, especially when there's a huge asset investment. I mean, they tend to be a little bit more stable. I'm not an investor. I'm not an expert in that, but, that's my understanding.

Now what about Servco's? We've been talking about, the Netco. Right? Differentiating between Servco's and Netco's, in the broader service provider world. What does a Servco do? What is their focus?

Well, they are focused on then on on gaining customers and getting the customers and serving them and and creating the products that the customer on in in particular for consumer, Internet access over the past ten years have been, you know well, we don't wanna just be the dump pipe. We we need to add content. And if you look at the, if you look at, like, the US market, the big Internet access providers in the US, they're they're also producing content. Right? They're also big media companies at the same time.

And I think in Europe, the thought have been the same. And first, they wanted to try and create their own content pipe somehow to keep keep the American folks out. But then, you know, that that was not really, successful. Like, every ten years ago, every telco had their own video service, but they don't anymore. Now now they're bundling their their their pipes with, with with the the content that everybody wanna watch, like Netflix and Disney and, Prime.

So instead of having a cable TV company, you now have you can buckle your your Internet access with all these streaming services instead, and you still sell some TV for people.

So that that's creating, like, one.

That's at least one one way way of doing it. Right? And then also combining even in the US, if you're a cable company, you will you will then use somebody else to, provide the mobile phone mobile phone subscription so everybody can have, like, your phone or your entertainment in the same in the same subscription.

Do you think that separating, services like that in the way that you described poses enough problems or sufficient problems, big enough problems that it maybe doesn't make it worth it? Is this really the right direction?

I think in order to do the focus and to avoid internal struggle, I think, actually, the separation is is a good is a good thing, and particularly when when dealing with, the the the big content providers who would want access to to the network in order to make the other kind of deals.

So let's go back to this idea of the modularity that service providers are embracing is partly in as a result of, the changes in software architecture that we're seeing today. And what I I assume you mean by that is the way that software is written today and how it's distributed and disseminated, how people consume it, whether it be over a network, via cloud, that sort of thing. What is it about software architecture that has changed that you believe is instigating or has become one of the catalysts for this change in the service provider space?

Well, I think I think, the the modularity is is the keyword that we're talking about and then the scalability. Right? So if you have a lot of workloads and you just need to build your own monster system at home to make sure if you can do that, if you can distribute that or you can spin up and spin down as a as if you have a non constant load, which is one of the one of the the the big, one of the big things about cloud. Right? You know, you can spin spin the workload up and and use that. I mean, I remember we doing that. So, actually, Netflix is a is a is a brilliant example of a if you look at the network part of it, not the content production, but the but the the the the network the the the content distribution network is, is a brilliant example of a cloud based, service provider.

Oh, wait, you say, but Netflix has their own servers they put out to ISPs, and that's right. That's just the storage of the movies.

All the intelligence and all the customer systems and all the all everything they do that requires any kind of compute takes place in the cloud. And they run they're they're a big AWS customer, I think, or they were. So at least I think they still are.

And, and and one of the things that they are leveraging of that is is the ability to spin up and spin down capacity if they need it, in particular, because they run they run their system in different regions as they fail over.

So when you then start falling over to, you know, another region because you're breaking in one region, well, you need to be able to quickly spin up a lot of capacity to hold everything that goes on. And then when you can distribute all your users again between the two regions, you can spin down in some areas. And that gives a lot of, opportunities that way. Right?

Okay.

So another thing is the APIs because that enables you to specialize very much on a particular function and then create an API, and then, you know, somebody else could specialize in something else and everything's computed is communicating through the APIs. And we've even seen API companies spin up. Right?

So what other network resources are we moving to the cloud? Like, what specifically? I mean, certainly, we can't move ASICs and interface level forwarding decisions and SFPs and fiber optics. That stuff is physical and it has to stay on-premises.

So, you know, you did mention that Netflix operates out of public cloud, and it does push policy, of some sort down to local resources. Is that all we're talking about, or is there any kind of meaningful network function that we're that providers are getting off premises and into whether it's their private cloud or public cloud? Cloud?

Well, interestingly enough, it it it's happening quite a bit in the in the mobile infrastructure.

So you can, some of the some of the controller stuff for for the for the radio network, instead of having that sitting on a box on-prem, you might as well have that on a local cloud. Or you oh, again, we are running it on on a on a on a cloud, maybe a private cloud infrastructure in its inside your own network. I there are some big big companies who do that. We sort of made a a deal with one of the I think it's either Google or AWS or maybe both of them that, you know, well, here's our infrastructure inside.

So and and 5G is a big part of that. Right? So you just, instead of you building up your own edge compute or or control function for 5G, you're just, you're you're you're working with, you're deploying a private cloud, closer to the edge of your network where that can be sort of activated.

This is not existing, cloud, telco functions. I realize that, but it is still a big part of of what we call telco today.

But you also have, again, the customer control systems, business systems, you know, anything that you if you run it on a server, you can run it in the cloud. That's basically what happened with the with the software architecture.

I mean, you can put a lot in the cloud as far as, you know, network functions now that I'm thinking about it. I mean, I'll go back to SD WAN that I mentioned earlier. I mean, when I was putting in SD WAN and designing it and selling it and things like that, I mean, the SD WAN vendors that I worked with and I was with a bar, so I worked with multiple SD WAN vendors. I mean, they hosted all of their controllers, their their orchestrators, all that kind of stuff lived in public cloud and specifically in AWS.

So, the only thing happening locally was local, packet forwarding decisions, but the policy all lived in the cloud. The security policy lived in the cloud. All of our, you know, other components and elements that we use to manage the control plane all live in the cloud. And you think about, like, route servers just lives on an x eighty six server.

Right? And we can push that out and we we, you know, in in traditional networking with route reflectors and and, and things like that. It's not like an unusual thing. So there is quite a bit that we can do.

You can even move you can also move your packets in some of the cloud. The public clouds are offering that, you know, I I read about a 5G experiment that Deutsche Telekom is doing with, I think, Amazon, where they would have, like, a 5G site in the US and one maybe in Germany.

And then used work with network slicing and all that fine thing.

And the communication between those two sites would run inside the AWS network and using their backbone instead of the Internet or some dedicated infrastructure.

So so they're even pulling traffic flows in into the cloud these days. But I think that's that's some of the most extreme things, but it but it but it is sort of like, wait. What?

Deutsche's telecom even have a global network? I mean and then they're using, somebody else's, for this. Well, it is an experiment. Right?

But still Yeah.

I mean, we're gonna move what we can off premises into the cloud. So, you know, whatever makes sense, whether it is control plane activity, just business applications and customer management systems, all that kind of stuff, whatever we can. And and, you know, one of the reasons that we're able to do that in my opinion is because we have very, very high bandwidth, cheap bandwidth, low latency bandwidth available to us us now, much more and much more affordably than we ever have before. So it just makes it, a lot easier to carry out those functions, not locally.

And, eventually, you might you know, there there will be definitely be functions that, you know, might as well run-in the hyperscalers network because they have the capacity and they will sell it to you.

Yeah. And if you if you're looking into any SDN stuff where you you have a centralized calculation on what the best routes through your networks are. You you why not put that in the cloud? Why run that on on your own box? Right? It's just a completely local packet forwarding.

You you you kind of need to do that physically where the network is, and and, you know, the fibers are where the fibers should be.

Absolutely. Of course. Of course. And, you know, I really think that the the reasons are to move network functions to the cloud for a provider or even an enterprise are just very compelling. And I and I do understand that there are certain things that we have to consider now that maybe we didn't have to. We have to change the way we approach fault tolerance and resiliency, and we have to think about security differently because some of our resources aren't under our absolute control in, you know, in our, facility.

And so I get that those considerations are there and we have to think through that. That might even prevent certain network functions from being migrated to the cloud. Nevertheless, I think there's just there's just so so much benefit in moving a lot of these components to the cloud. And wasn't that the the promise of SDN from some years ago?

Do you remember? I mean, it was like this idea of disaggregating the control and data plane. And then what we're left is left with are these much dumber boxes because you only need enough intelligence to run the hardware, run the ASICs and do the local, you know, forwarding decision making, that kind of thing. Therefore, resulting in a much cheaper box.

The control plane is somewhere else on the expensive gear. You need less of it because it's just speaking to all my local devices.

And therefore, I have a more composable infrastructure. I can upgrade and replace gear much more quickly and therefore keep up with, market demand, new business initiatives, new applications being delivered, new services, all that stuff. And I have to imagine that for a service provider that has an infrastructure that's so physical and so, you know, I can't really touch something because it'll break everything, that's gotta be a compelling reason to put as much as you can up in the cloud.

Yeah. I think it's it's it's one of the motivations. But then again, it depends on what kind of network you're building and and you're looking for.

There's also highly, highly specialized boxes that in forwarding packets. Right?

So if you if it's important to you that you you can run high really high volume through a box, You know, you might not really wanna go with the white box, but you you might actually wanna buy, the hardware that's dedicated for that.

But if you can then focus your money on on that and then use white boxes for, lesser specialized, functions.

And then you can just, you know, throw your deploy your your your cloud and your yours your cloud software, your cloud first network functions on that, you know, that that might be able to, that might give you some savings in, in in overall. And then you have the money for the specialized gear to make sure that your packets go where they need to go if that is right.

So some functions that we might consider migrating are things like, you know, our our security since we're just pushing policy that ultimately gets carried out by the local hardware. We talked about moving the control plane itself, but maybe also some business applications and things like that, which are not necessarily network functions, but they're related to, you know, security tags and application tags and customer IDs and circuit IDs and all that stuff can live somewhere else, to be pushed out programmatically.

Yep.

But then then I think, like, you know, a carrier grade NAT, you might wanna make sure that you get, you get stuff that has the, the the capabilities to hold on that state and, and switch those packets.

So let's, switch over to talking about Servcos now, and that's a pun was totally intended there.

We we've been talking about NETCOs for a while and, you know, that's more near and dear to my heart for sure. But Servcos are the ones interfacing with the customer, like you said, the end user, the consumer, and, ultimately responsible for delivering the service, probably an application down to them. So what are the benefits of this entire shift to Servco's?

Well, I think it's a, when you're disconnected from a specific network, You know, you you you you sort of get the freedom that you can go and shop for the network and the network types and the network that you you need.

So that I think I believe that is supposed to be one of the focuses. And then also on, you know, focusing your resources on product development and not so much on on on maybe replacing fibers in an area where their fibers are now so old that you have to go dig, and then all your money will go to that one.

So it's you know, by the by focusing by focusing the the the the the the money on different types, you get away from the problem where, oh, my old network is gonna eat all my money, so I don't have time or money to, to do good product I mean, it does sound like the benefits are, in theory, very, very similar.

Scalability, agility, you know, being able to go to market faster with new services and products, you know, cost.

Thing. Yeah.

Yeah.

The downside, I think, and I fear Mhmm.

Is that the NetCos will end up being monopolies.

Okay.

And that means a lot of the benefit of competitions that we've had, which has benefited the consumers because of getting good products and low prices, in particular low prices Mhmm.

Might go away, because if there's only one network provider in each area or networks, Netco Mhmm.

You know, who's gonna make sure that their price is right.

And then if they have high prices, then the resulting consumer product will be high priced.

If you have if you're going through with that, structure in a market, it takes regulation to make sure that the everybody's opening the net networks for everyone, but also to secure there is some sort of, control on the prices. So you can't go and make a well, okay.

So UNetco and UNetco, we agree the price is this, and both of us are gonna take that. So we're not competing with each other, and we're not building into each other's, areas.

And then you get an artificial high price. Yep. So we need to avoid that. So we need we need some regulatory oversight to make sure that doesn't happen.

Yeah. And then because you have that element of control, it deincentivizes innovation because it's like I'm the only game in town, so I don't care.

Yeah.

Yeah. And that's both for Netcos and Servcos I have to imagine and for anyone involved in this entire chain.

It is. It is. Mhmm. And it and that's, well, at least, you know, that that that's what a lot of the telco regulation is about. Right? It is about, you know, competition regulation, making sure there is enough competition in the market so you would not allow in too much, of a consolidation, to happen.

But you can't you you have to allow some sort of consolidation. Otherwise, know, people will go around and say, well, we are too many people. We compete to each other. Nobody can survive. So that's the balance they have to do.

I mean, the amount of money that a NETCO is gonna need to just get up and running, a brand new one, right, to to enter a new market, to build, infrastructure, physical infrastructure, whether that's like digging trenches and buying an incredible amount of fiber and, the technology and the big iron and the high priced engineers, the amount of money to get up and running as like a Netco startup is tremendous. So I you know, you're not gonna go into some town and have two hundred different Netcos to choose from and have that kind of competition because it's just next to impossible to to to start up in the first place. And it's not gonna be like when I go to the supermarket and there's twelve different bands brands of chocolate or peanut butter on the shelf that I can choose from.

Yeah. But you you can still have, you know, when I when I moved into my not this not the place I live now, but the previous place ten years ago when I bought that.

I had four difficult I had four different physical connections into into the house that it was pretty new house at that time. I fibers to two different fiber providers and coax cable to do two different companies as well. So at that time, it was four different providers I could choose from, to get my Internet connectivity.

A, three of them goes to the same company.

But, you know, but it was super easy. It was great for me. It was sort of like, oh, do I want this guy, or do I want that guy? I'll just go online and go, alright. Yeah. Please enable this one.

Whoever's cheaper. And for me, it just comes down to who's the cheapest. Right? I mean, it's residential Internet connectivity, really. So, yeah. I'm concerned with the quality, of course, because I live on Zoom, and I stream I have, like, eight different streams going on in the house with Spotify and Prime and all the kids and my wife and things like that.

And then, you know, as far as the amount of bandwidth, I know that we're network people and we want all of the bandwidth, but the reality is a few hundred megs and you're probably okay.

So I'm really looking for who's giving me the most reliable connection at the cheapest price. And in my area in New York, I have three providers that I can get a hard line connection whether it's fiber or coax, and then there's a smattering of of local, regional, satellite providers. And then, of course, I can always go to, like, the Starlink and stuff like that if I wanted to. So I don't have a huge, variety of choices from which I can choose.

And, ultimately, like you said, sometimes those those last mile providers are gonna converge in the same c o a couple miles down the road on the back end anyway.

Not to mention that I'm really not buying anything from the providers. I mean, I'm really I guess I'm more interacting with the whole, like, customer service folks and who do I call when there's something wrong and who's fixing what. You know, maybe they're dealing with contractors. What do I know? And so when it comes down to it, I I really am kinda just interacting with the Servcos.

And, and that really is an issue, I guess. I mean, maybe that's one of the one of the challenges of this disaggregation of Netcos and Servcos and others.

You know, who owns what considering that all these components, they they work together in a system, yet the system components are owned by different people, certainly, that's gotta be a challenge.

Yeah. Well, you you as a you as a consumer will always have to call, the guy you pay or the gal you pay.

You know? And then they will have to go and, you know, yell at somebody in the on in the Netco if if it's a network issue or or someone else. So but that is definitely that is that is that is also one of the weaknesses of this one. I mean, what if when when shit goes wrong, where, you know, you have to yell at you is the guy that you're able to yell at, is that the right person to yell at actually? Or they did they have to go and yell at somebody else, and then it will take you longer to get shit fixed.

I mean, we've talked about the, the technical aspect of moving certain network functions to the cloud, what that means, what network functions would be moved, and all that kind of stuff. But I I really feel like this is more of a business initiative and just a kind of a new strategy of of operating this entire system. Compartmentalizing it, getting different people and stakeholders involved in ownership, relationships and things like that. And I I I don't know. I feel like that it's not really driven by the technical side, but it really is driven by the business side. Maybe that's how it always is. I don't know.

What what do you think about that? What's really driving this change here?

I think that's it probably is what leading it. An interesting change, difference that I've noticed I know you were trying to wipe down, but I I'm kinda missing this point.

An interesting difference between Europe and the US that we've noticed as well is that in the US, they're not splitting the companies horizontal, but they're creating there's a there's a there's a there's a there's a infrastructure companies are being created, like, pure more pure. So you have the big four that are everything, and they're producing the content as well. And then you over the years, a lot of a lot of cities have built their own fiber network or some energy companies have added fiber networks to their and then there's some private equity is sort of like buying that up slowly, a little bit under the radar, and creating, sort of a bigger regional, infrastructure companies, that is going to start competing with, with the big four on, on just selling Internet access.

And they just keep the focus on the pipe, which is kind of interesting to see.

Yeah. Yeah. I agree.

So I do wanna wind down now, but before we do, I do have a question for you. Now, I know you personally. I know what you do for a living, of course. I know a little bit about your background.

I know a little bit about your hobbies and and, you know, family and things like that. I wanna ask you, if you could do something for a living other than networking no. No. Let me make that broader.

Not just networking. Something other than technology.

If you could do something for a living other than technology, what would it be?

It's a good question.

I think there are two things that I might be doing.

One one would be that maybe maybe I would have pursued some sort of career at sea, you know, sailing. But, you know, since I have bad eyes, I don't think back then that would have been an option to me. At least I didn't think so when I was, when I was trying to figure out what to do.

But, you know, maybe maybe maybe I could have done that.

You know, navigation, because sailing, big ships.

Uh-huh. Another part, I think might be energy.

Yeah. Because, because yeah. Well, you know, I come from, I come from a windy place, and we we are the ones with the windmills. Like, you know, Vestas, you know, is a is actually a Danish company. I don't know if you knew that.

And, and we had some heavies create, some of the first windmills, you know, back in the early seventies in in and and that's now near that location. We have one of the biggest, test facilities for on land windmills or wind turbines, I think you call it in the US. Right? Wind turbine. Yeah.

So energy in general is is really big. Oh, so now if I was young now, I would go into energy.

Interesting. Okay. I mean, I knew you were gonna say sailing. I knew it, you know, for certain that you were gonna say that.

That's what I expected.

But I didn't know that you were gonna talk about, a career in energy. So that's new to me. Really interesting. Thank you for that. So, let us wrap it up formally now. Nina, if, folks are interested in reaching out to you with a comment or a question, or maybe to, pick your brain a little bit, with regard to your, vast experience working in the service provider space. How can they find you online?

Well, they can find me at nina@kentik.com, obviously, or on LinkedIn.

LinkedIn is probably where I the social network I use the most these days. I'm not really active on on that x thing.

And Facebook, I've always kept, just my private stuff.

Great. And you can find me at network underscore Phil on Twitter. Still very active there. You could search my name on LinkedIn.

Now if you have an idea for a show, an an idea for an episode, or if you'd like to be a guest on the, Telemetry Now, I'd love to hear from you. You can reach out to us at telemetrynow@kentik.com. So for now, thanks very much for listening. Bye bye.