Networks Need Telemetry – BT's McRae

With increasingly complex networks, service providers would do well to focus more on telemetry, according to BT's Neil McRae.

In this third Q&A, McRae, chief network architect for BT, spoke about the important role that telemetry plays in giving service providers visibility into their use of SDN and automation to control their networks, as well as his thoughts on SD-WAN, containers and microservices.

Previously, in Part I, McRae spoke about how SDN and automation were making networks and services more agile and more secure. In Part II, McRae discussed BT's use of common service models. (See BT's McRae: SDN Is All About Automation and BT's McRae: Common Service Models Aid Automation.)

Telco Transformation: We've covered how important automation, SDN and common service models are for BT. Are there any other technologies that are also of note going forward?

Neil McRae: Yeah, there's one other thing I want to mention and I think the snowball is starting to move on this. One of the things that is increasingly important in networks -- in fact has always been important in networks, but we've not done a great job of responding to it -- is control of networks. This is very much focused towards SDN, automation and network technologies of the future, and network products and capabilities of the future. What will make those technologies very successful is the visibility of what's going on in the network, and SDN gives us some of that visibility and signaling.

The other part that will bring a huge amount of benefit for service providers, and I don't think enough service providers are working on this, is the whole telemetry piece. So you see Nokia, Juniper, Huawei and Cisco are all starting to build telemetry solutions into their products. I believe that this will be in every network technology. I believe that what telemetry gives us is a level of visibility that we could only have dreamed of 10 or 15 years ago. That visibility allows us to then use SDN and automation to control the network. I think many of us -- many of my peers all kind of have a similar view about it -- agree that we need more visibility.

I personally believe telemetry is as revolutionary as NFV or SDN. It requires a lot of work. It requires a lot for us to learn about it. We need that visibility of what's happening on the network as networking gets ever more complex with 5G coming in, and we need telemetry for managing radios, different types of data, sub-6 gigahertz millimeter waves and WiFi. As all of that technology starts to come together in a converged world, telemetry is going to be critical.

So that's another area where we're investing a lot of time and effort in; to build solutions that can benefit from telemetry. We can use it with automation and with machine learning as well. We're starting to investigate all of this. That's the other piece that needs to be slotted into SDN.

You link telemetry to service models, and then you can use that telemetry for greater visibility. If the telemetry is telling you "X" about the service model, then I can automate "Y" on that service model. I think that greater visibility -- together with service models, together with SDN automation, together with YANG -- can change the way that we build networks today.

TT: We hear a lot of talk about SD-WAN and other SDN applications becoming VNFs. What's your take on that?

NM: I think, yeah, why not? One service we offer today is around VPN remote access. In effect, it's a server that runs a bunch of TCP-IPSec and software that you connect to. In many respects, that's equivalent to where SDN is heading towards, in my mind. In some ways, and probably in some sad ways, we have a lot of that technology already for the network side, but what we haven't done is put a controller in there, which is what SDN will give us. I absolutely foresee VNFs running in a cloud provider or on prem [customer premise], and SD-WAN would be part of that.

TT: Are there any potential problems or workarounds for using VNFs?

NM: I do think we need to be slightly cautious, though, because from a service provider point of view one of the challenges you see with a virtual CPE, or a customer premise running VNFs, is that you have to be really clear about what are the values for the root VNF, the one that's really controlling the underlying connectivity.

If you imagine a network today, if you want to debug it, you get out your pen and you can trace the cables along one corridor, along a cable tray, point-to-point. In the world of virtualization, we're going to have huge networks that are all cloud, that are actually completely invisible to us. In the data center space, they already have that today.

That's going to expand out of the data center into wide area networks, which means that automation is all the more critical, in my mind. It means that the complexity, and our ability to manage customer networks, has to improve because customers are going to demand it, and the demands of customers on products will be more and more complex.

So yes, I see that being more VNFs. I see it [SD-WAN VNF] being an app on an iPhone. You hear this all the time, but the longest pole in that tent is the connectivity. But imagine a world where you just run the SD-WAN client on a phone, and you're in the SD-WAN. So I think you'll see SD-WAN end points in various places, including VNFs, including in the clouds. You might even imagine it in trucks where someone like UPS may want to connect its trucks to the network in a controlled way. So I think the use cases for SD-WAN end points are unlimited, actually.

TT: What about using containers and microservices?

NM: We're using containers today, actually, on our TV servers. So, that's delivering the TV platform BT Sport on BTTV to many customers. Containers are just a reality. Microservices are just a reality. Anyone, in my mind, that doubts the need for those is either a very niche person that doesn't do volume, or is about to have a nasty surprise. There are several big benefits for those.

One is scale. With microservices, it's not just the scale of the platform; it's the scale of your ability to work on the platform. We all have this notion of how many engineers can you get around the engine of a car? Even in a virtualized world, that's still a difficult thing to do. But with microservices and containers, I believe that that makes life easier for you to allocate what package you get out to your development teams. I've seen it in action at a couple of companies where they're just able to get more done because of the capability that microservices brings. You could have five guys working on one microservice, another five on another, another five on another and you ball them together. You need some alignment to bring all of that together, but that's kind of a nice problem to have in some respects.

The other benefit is that you get much more out of the hardware. We see a 10% to 15% improvement in hardware utilization because of microservices just being able to do more. Also, this probably isn't quite there today, but I really believe where we're heading as an industry will require us to be much more specific about thinks like "How much CPU does this app need? How much disc drive space, how much memory, how much network?" Over time, the more we can manage that, the more we have visibility on it, and the more that we can get out of it.

Microservices take you on that path. It's a long way to go, but I genuinely believe that's the path it takes us on. I believe it's the path we will end up on in the next 10 to 15 years, maybe sooner.

— Mike Robuck, Editor, Telco Transformation