BT's Sabey: NFV Drives Automation & Service Agility

Jim Sabey, head of BT connect and compute sales specialists, says that the telco has been a driver of network functions virtualization since it literally on the drawing board, and even before it was named.

It has a name now, of course, and BT still is a big supporter. Sabey, in part one of a conversation with Telco Transformation, links NFV to the type of automation that makes life easier and service delivery quicker and more tailored to end user needs. The ultimate goals of a programmable network are automation and providing customers with more control over the services and applications. (See BT Gears Up for More Virtualization.)

Telco Transformation: BT was one of the seven original service providers that helped forge the European Telecommunications Standards Institute (ETSI) (ETSI) standards group for NFV back in 2013. Where is BT now in regards to NFV?

Jim Sabey: We offer a comprehensive range of virtual network functions. Some of those are deployable on customer edge provided servers, on x86 platforms. BT's deploying this technology in what we call cloud service nodes. Customers are telling us, "BT, we don't want to have all the appliances on our prem. We'd rather have those in your cloud. Just give us an access loop to your POP." In our cloud service node is where we actually have the NFV functionality. It's actually a two-step process. We're developing solutions that will both be on customer edge premise and as well as in our POP, in our node.

TT: There are other service providers in the market. How does BT differentiate itself?

JS: To me what it boils down to, and what differentiates BT in this regard, is we have what we call a network system integrator approach to our solutions. A lot of customers want a mixture of services. They're not just going to overnight swap from a traditional MPLS network to software-defined WAN networking. There's going to be a phased approach. Our SD-WAN solutions are mainly with Cisco and Nokia’s Nuage. We also have some flavors with Riverbed and InfoVista.

BT's approach is to actually understand the business drivers a little bit more so that we actually apply the right service to the right customer need. What I'm seeing in the market today is a lot of our competition has a single solution. If you want to go with that provider, you have that single solution.

TT: What role do SDN, NFV and the cloud play in regards to automation at BT?

JS: When I think of the word automation, that's exactly what customers want: Flexibility and automation. SDN, NFV, cloud, all of these things play a huge role with regards to automation, especially here at BT. The way that BT has built our system architecture is that it’s basically a programmable network.

BT has developed our own orchestrator, it's called SRIMS. Basically SRIMS is the engine that controls the virtual network functions. It also will deploy and run the SDN and SD-WAN services that BT is developing. End users are able to go on to a portal and say, "I have a site in Dallas that I want to bring on to my network." They'll log on to a portal, they'll order the device and the device will be sent out via FedEx or UPS or somebody like that.

Instead of a high priced engineer going out to your site, that device will be sent out. Once it's connected and plugged in, it will actually phone home, if you will, to get its configurations automatically. Again, it's automation down to that box. You're limiting the number of hours for a technician on site, with a phone to his ear, trying to get configurations and all these things.

This is going to give BT the ability to rapidly provision a new site to a customer's existing SD-WAN service. It's going to be huge, the automation, and BT's working towards that. Essentially what BT calls all of our strategy around NFV and SD-WAN and programmable networks, is "dynamic network services." It's really supported by that transformational OSS. We still base it heavily on the basic principles within IT industry in general. Then we bring the BT SRIMS and the orchestrator to our customers to help that automation make things faster. Customers can get circuits and connectivity in a matter of hours or days, not weeks or months.

TT: You're making this whole complex thing as easy as sending a cable modem to a residential customer?

JS: Exactly. One more thing: Amazon really shook up the entire world. Now you don't have to go to the grocery store, you go out to a website. Amazon's doing the same thing for the network. It's really disrupting how customers want to consume things. People now are accustomed to going out to that type of portal and logging in, adding a site, having the box shipped out and making it simpler to plug it in. Even an administrative assistant, or somebody that's not technical at a site, can actually plug in these devices.

Then the configuration is actually downloaded automatically. Then that site's up and running and it's connected to the rest of the sites in its network. That's what customers have been asking for for a long time. The days of waiting 92 days for a circuit, then another ten days after that for a router, and things like that will be eliminated.

TT: How does BT view NETCONF and YANG models?

JS: You need some sort of model to be able to analyze the data to make sure that the packets actually route correctly. At the very highest level, it's essentially a standard. So we've worked heavily with OpenConfig. Again, BT's been one of the leaders and we've driven publication of over 10 draft standards. YANG models specifically are used. If you look at BT in general, our stated policy is really to leverage what's called NETCONF and YANG as the real strategic solution for how this future network is going to play out and its configuration.

TT: So if a particular company had an SLA, the setup and configuration is handled by NETCONF and YANG?

JS: I would say YANG is the data modeling language for NETCONF, which is a protocol that was defined by the IETF to essentially install, manipulate, delete and the configuration of network devices. At a high level YANG is doing the data modeling for application-aware routing. For instances, when we tell the system what port to use for certain traffic, eventually that's the data modeling language, that's YANG. The NETCONF is actually the protocol.

— Carl Weinschenk, Contributing Writer, Telco Transformation