 Good morning. How's everybody? Have a good night? Anybody do anything fun? Well, welcome to Cisco's sponsor track sessions. We've got four sessions for you today. I'm sure you probably all saw them on the schedule. Actually, I'm going to go run down and pick up some more of these. I'll pass some of these out during the rest of the session. Three more sessions after this one, running all the way through just about to the lunch break. We're going to start off today with David Brink and Ravi Chandran from the Cisco Cloud Platforms and Solutions Group. And we're going to go into the what, why, and wheres or whens, because the where is everywhere, right, of the telco stack. So David, take it away. Thanks, Gary. Good morning, everybody. So as Gary said, my name's David Brink. And what we're going to cover today in a session with myself and Ravi is what is telco cloud, building the telco cloud, and then what can I do today? So what is the telco cloud? And this notion of building telco services on the cloud-based technology, the challenge is that the way that telco networks are built and the way that cloud networks are built are very different. The practices involved are very different between telco networks and the way the cloud networks are built. Telco networks typically have to comply with SLAs. There's often regulatory and policy compliance with telco networks. There's a lot of process around change management. And the applications that are stood up in the telco space are typically very bespoke. They long lived using an energy of pets and cattle. This would be pet-like. So as I said, the applications are very long lived. They have a lot of bespoke characteristics, like IP addressing, that has to be set in the applications. Whereas cloud is kind of the exact opposite. So in the cloud space, the applications are catalyzed. So you basically bring up the application for as long as you need the application to be running. And then you knock it down at the end of that session. So it's a very different approach to how you build networks and how you run applications. Cloud apps typically, you spin them up. If you want to make a change, you knock the app down and you re-spin it in a containerized fashion. So the idea is that you want to be able to launch new services really quickly in this space. So what is forcing providers to move into this telco cloud space? What is the forcing function? As all of us in the room know, it's 5G. So if you look at the quotes up on the right around the world from Telstra in Australia, I've got a plane here in Shanghai. And I just see all the carriers here have launched different 5G services in North America. We have Timo and Sprint, Timoble and Sprint, building out 5G networks there, BT in the UK. So around the world, carriers know they need to build out with 5G networks. They're looking for driving new revenue streams with additional ARPU. And some of the comments from some of the analysts is these 5G networks are going to amplify the strengths and weaknesses of telcos in this space. So if telcos are able to deploy services in an agile manner, then they're in good shape. But telco services who are still very process bound in the old way that they stood services up, they're going to really struggle in this new paradigm. So looking at some of the common challenges of telcos building a cloud in this space is the integration complexity. So their typical deployment model doesn't, as I've said before, match with the cloud deployment model. And how do you marry this cloud deployment model into their existing processes is the challenge. Also the operational readiness. So how the operations functions are structured within carriers today. One part of it is training the operational staff. How do I operate a cloud environment? That's one piece of the problem. The other side of it is just how the organization is structured, how the org structure matches or doesn't match a cloud deployment model. So basically one is the training problem and the other is the org alignment problem. And if I use a very simple example that I ran into at a service provider, was I was trying to implement zero touch provisioning. Really simple. This is zero touch provisioning for a piece of network hardware, not for a piece of compute hardware. And all I needed was a change to a DNS DHCP server. Now, trying to get that through took days, a matter of days. And the reason was because I was working with the network team and they weren't really aligned with the team that ran DNS DHCP because they were used to setting up DNS DHCP for the server compute community. So you end up with these boundaries and silos that are created within an organization. And that's just one small example of the kind of issues that you run into. So I think just, oh, it's easy. I can stand up zero touch provisioning and do a demo in two hours. And instead it took me three days. And that's pretty common across many providers. So looking at where we've come from. So if we have a look at how three G networks were built, moving to four G and then to five G. So historically back in the three G days, we deployed the applications on a physical piece of hardware. In the Cisco case, we had the ASR 5000, which came from our sterrent acquisition. It was a physical device. We loaded software on it in the same way we do on routers and other devices. And that was how we built the three G networks. And turn up time in that world took years potentially and changes would take months. It was a very slow moving, very centralized process. So then came move to four G. So what we did then is we did what we talked about as a lift and shift. So we took the, excuse me, we took those applications and we virtualized them. So we set them up to run in VNFs and we ran them up as VMs on whatever hypervisor where it's typically open stack, what we're running it on. And we sort of, so we improved things a bit. Turn up, then went to the order of months and changes were down in sort of in the minute type of timeframe. Then we're moving to five G. So now it's not a lift and shift. At this point, all the applications have to be refactored to run inside containerized which run as cloud native network functions. So basically ourselves Cisco and others have had to totally refactor all our applications to run for five G and containerize them. And what this does is now we can spin up in a matter of hours, spin up new applications in a matter of hours and we can make any changes in minutes. But also we can scale up and scale down our applications to run anywhere in the network. So if we wanna run it in the core and we'll spin up applications at the edge, far edge, we can easily do that. And some of the later presentations we're gonna go through sort of how this is done in certainly in Rakuten. So this enables your providers to move now very rapidly into new markets. So there's a lot of benefit there but then it comes to how do we get this to actually to be operated in a way that is better supportable. So in terms of first principles in the telco cloud space, we're looking at automation. So automation is key in a way that there was automation in 3G and 4G networks but now we into the cloud space and containerization. Automation is even more important and even more critical in terms of not just standing up the infrastructure, standing up the applications, skating applications up and down as required and moving them around the network. Also distributed capability, same thing. So the ability to have a single environment where we can move bandwidth around. So like if a provider was wanting to offer say, latency centers of apps, say gaming apps and you would need to move those apps out towards the edge, we could do that easily in a cloud based environment. So there's tremendous business advantage to be doing this but there's a lot of operational process that has to be shifted along within the telcos to be able to support this model. Thank you, David. So morning everyone. My name is Ravi Chandran. I'm a technical marketing engineer with Cisco's cloud platform and solutions group and my focus is on the automation part of the cloud solutions. So in my presentation, what I want to cover is an overview of the entire solution we have for cloud providers so that it can set a context for the next three presentations because in the next three presentations you are going to see all the details and I'm going to set the overview for you. So stop me at any time and ask questions. Otherwise we have a Q and A at the end. Thank you. So what we have for a cloud solution and this is something most of you know because when you want to set up a cloud infrastructure you basically start with the platforms, the hardware, the compute storage networking and then you set up the cloud operating system which is open stack in our case or it could be other wins. So that's the first thing we do to set up the infrastructure and then you build the capacity on top like the services and the specific needs of your customers. So that's the first thing we do, infrastructure and then you look at automation. You can do cloud solutions manually but practically nobody does it because that's not the way to monetize a cloud. Almost all cloud providers give you automation tools and we think it's mandatory for you to augment your infrastructure with automation tools. When we say automation it means many things like there are different standards today for automation but the most well-known standard is the Etsy standards because Etsy came up with this NFV mono solution sometime in 2011 or 2012. So it's fairly standard, now it is in release three. So as per the Etsy standards you have three layers of automation. The first is the NFV orchestration. So the orchestrator is the layer that knows how to orchestrate your services in the bottom layers and below that you have the VNF manager. The VNF manager is the life cycle manager of your VNFs whether it's a Cisco or third party VNF or CNF it should be capable of creating the VMs it should be capable of managing the life cycle of the VMs and the bottom layer you have is the WIM the virtual infrastructure manager which is open stack here. So these three layers must be automated through APIs and through standards if you want to achieve the full benefits of a cloud. The third part is the services and this is again something that we see very commonly because though we have standards there are still service providers specific services we need to do because you may have your own business processes you may have your own customer requirements or rules and regulations specific to country so we need to implement all those specific needs inside the infrastructure with automation. So we provide that tailored solutions on top of the automation infrastructure so our services team usually would end up doing a lot of services for you to make the solution specific to what you want. And lastly you need supporting software because the cloud platform alone doesn't give you everything you need for example good VNF repositories good CNF repositories from multiple vendors you need to have domain controllers you need monitoring you need the testing tools you need security so all those extra software also is in our solution. And we make all these in a loosely coupled way so that you can pick and choose what you want. We don't emphasize that you need to buy everything from Cisco it's not practical. We give you the option to pick and choose but if you want to do it end to end we also have that solution for you. So that's the way we have designed our cloud solution. In the next slide I'm going to talk about specific products and we are going to see more details of that in the next sessions but here I'm giving the overview of the entire suite. So we can divide the entire cloud framework of Cisco into two parts. This is a very very high level division. The bottom layer you see the blue layer is the Cisco NFVI the infrastructure layer. Here we are talking about an enhanced open stack solution which we call Cisco virtualized infrastructure manager or CVIM for short. So the next session we have is a very detailed coverage of CVIM and then we also have another session on the Cisco container platform. So that's the infrastructure layer. In those presentations you can see why we do this. Why can't we take an open source open stack and why we enhance it with our own tools and what are the values you would get we will cover in those sessions. The top layer you see is all the management and orchestration products and this is as per the Etsy standards. We have three main components in this mono layer. The first is what we call NSO which stands for network services orchestrator. So this complies with the Etsy orchestrator layer. And then we have the elastic services controller or ESC for short and this is our VNF manager. So we have Etsy compliant orchestrator and VNF manager and we also have a third component here called NFVO core function pack. We have built it specifically to comply with all the Etsy standards because we see the need that there are situations where you may use our orchestrator but a third party VNF manager or it could be our VNF manager but you may use another orchestrator. So how to achieve the standards in those cases? So with this NFVO core function pack we are creating the Etsy compliant interfaces. So we have also got examples of customers who use this interface to connect Cisco and third party components. So we have an example in the use cases later but this is the value we want to give you. We don't force you to buy a tightly coupled solution because we think that's not practical. You should be able to pick and choose and still get your value. Okay, moving on, let's quickly run through each of these components. So the first is NSO which is the orchestrator solution. NSO is basically a multivander tool. It was designed as a multivander tool. It's a very unique thing because usually Cisco products are designed for Cisco network but we acquired this product as a multivander product. So as of today, NSO supports 170 types of network families. So when I say network family, you can think of Cisco IOS as a family. So inside that family there are a lot of sub models but they're all one family. Juniper, Junos is a family. So we have 170 types of networks that NSO can own both today. That's both physical and virtual. Okay, so the way we use NSO is we give you standard interfaces like NETCON or REST or RESTCON. You can use any of your tools or portals or APIs to trigger a request to NSO. NSO takes that service request. It translates it into the network configs and it will apply it on your physical or virtual networks. So that's the role NSO plays as an orchestrator. You can use it for your physical and virtual and Cisco and third party networks. Moving on, how NSO can do that, right? I mean, what is the architecture behind it? We have these layers here which is called the network element driver or a net for short. So as of today we have like 170 nets for different network families and these elements know how to talk to a particular network family. So it can connect to that device whether it's physical or virtual. It can do the configuration of the device. And on top you have these service managers and device managers and these are the young models that you build and these are the intent that you want to apply to the network. So the service manager takes your intent in the simple young model. It translates it into the device specific request and the device then gets the configs through the network element driver. And once you do that, we also keep a copy of the config in our database. So it becomes a very good backup repository for you. So in case there is a problem on the network if you want to enable the service again, you can always restore from the CDB. So this is a very powerful tool and we have seen a lot of customers using this today in different use cases. If you want to know more about NSO, you can come to our booth in the marketplace. We can show you a demo and also explain more of the features. Moving on the NFVO core function pack. As I said before, this is the HC compliant solution that we have built. And as you know in HC, we have got all these standards like Sol 001 which is a TOSCA definition for the VNFD and NSD. And Sol 006 is a Yang definition of the same. Then we have got Sol 003 which is the interface between a generic orchestrator and VNF manager. So all these standards we have taken and applied inside this function pack. So when you install this in the solution, you get an HC compliant interface. And you can use any HC compliant tool to talk to this solution. For example, a VNF manager that's not Cisco but HC compliant can be interface to this. And lastly, the Elastic Services Controller. This is our VNF manager. And as I mentioned before, it's a tool to create a VNF and manage the life cycle. So it can onboard deploy VMs in our CVM or OpenStack solutions. And then it can monitor the VM. So if the VM dies, ESC can spin it up again. So that's what we call healing. It can do scaling, it can do updates, it can do on deploy. So it's a complete life cycle manager of your VMs. And in the next version of ESC, we are also supporting CNFs, the containers. So you can also spin up containers and you can manage them. So it's a very powerful, HC compliant generic VNF manager. So moving on, we also have different sizes and this is again something we will cover in the next session. So you can have an edge pod which is a small size installation. You can have a micro pod, medium size and a full size. So depending on how big is your implementation, you can pick and choose the size. And this is something more practical, like though people are interested in the next generation solutions like NFV and also containers, they're also, they can't throw away whatever they have today. You have to live with the current and the future. And there'll be a lot of migration that will happen along the way. So the way we have built these solutions is that you should be able to manage the current and the future requirements. So tools like NSO are designed that way. You can provision the current physical network. You can also provision the future VNFs and CNFs. So one tool for you to manage your existing physical network and the futuristic virtual networks. And this is my summary slide. Just to give you an idea, like you can see that a lot of groundbreaking services, innovative services today are possible because we use cloud as a platform. Without cloud, you can't get services like Uber or DD or grab and many more interesting services. And as service providers, you may have a lot of good ideas to use cloud and monetize. And we have the tools to support you. The entire journey right from creating the service to monitoring and then monetizing. If you want to know more details of any of these products, please come to our booth and we are happy to discuss the specific details or give you a demo. With that, I will conclude my session. If you have any questions, David and I will take it now. Thank you. Thanks, Ravi. Thank you, David. We have about eight, 10 minutes for questions from anybody in the audience. Apparently you two have covered everything the group needs to know about building a telco stack. Yes. Yung.model. Yes, yes, please. I can give you a demo later if you come to our booth, but I can tell you briefly what it is. So Yung is an IETF standard and it helps you to define your service intent. It's a modeling language. It's not a database. It's a modeling language. So when you model in Yung, it's very easy for you to do the definitions of your service because Yung is very powerful and it allows you to define a service in different ways. And it's easy to also find the right changes later on. So it's not just a definition language. It's also a good language for lifecycle. So it's basically a standard language and when you use the next generation protocols like Netconf, then they also support the Yung models. So what happens with Netconf is the device itself is defining the Yung models and giving it to you as a consumer. You can simply download those Yung models to your management systems and they will understand the capabilities of the device from the Yung models. Yung is just a language. Yung is a way of defining what you want to do and the management systems understand and implement that requirement on the network. Netconf is a protocol. Netconf is a protocol. Today when you connect to a device, typically you use protocols like CLI. You connect with SSH or XML SOAP. But those are a translation layer because the device basically understands the CLI. So you translate your requirement to a CLI. When you use the Netconf, the language that the management system speaks and the language that the device understands can be the same, which is Yung. So that way it speeds up the way you implement new services. Yeah. Any other questions? Here we go. When we move from the VCF to the CNF, do we mean that we need the terminal to have the virtualization functionality or we will move the functionality to the cloud side? When you move from VNF to CNF, I think it's not really a migration you would do. You basically would take that function and implement it in a different platform. Like when you implement a VNF, they're basically installing that in a virtual infrastructure like OpenStack. But when you do it in containers, you are putting it in a different platform. But the function inside is the same. Like you have a router. The router can be a CNF or VNF. Yeah. Any other questions? Here we go. You explained the NSO and the Cisco manual is much better. Have you connected the other VNF or VNF manager or NFBO to the Cisco product? Yes, we have done both types of solutions. Like we have connected NSO to third-party VNF managers and we have also connected our VNF manager to third-party orchestrators. I think we have one use case today to explain that in the third session. Thank you. Anybody else? We'll talk about the legacy of, do you put the containers into VM or do you add today to the bare metal? Today we are putting it inside the VM. Is that correct? Yeah, so the reality is today it's in the VM, but we already have a plan to put it in bare metal. The main challenge is persistence storage when we go to bare metal. The fourth talk, we'll talk about what we are doing today in containers in VM and where we are evolving to that. Yeah, the thing I would add to that is you can divide particularly VNFs into two categories. One is the sort of category that you use to control the network and one is the category of things that forward traffic within the network. They're fairly broad categories. What controls the network works perfectly happily in virtual machines. The performance and the manage, that you get a slight degradation of performance for using a virtual machine which doesn't matter terribly much in those circumstances and you get better manageability which is actually helpful in those circumstances. The forwarding elements, that's an area where Kubernetes currently falls a bit short in terms of its networking ability and that's something we're looking to address. By the way, Ian and Chandra who've been helping out here are actually our next presenters. So I think the best way to describe our day is just we're starting at a very high altitude and digging deeper and deeper and deeper with each of our sessions. So Ian and Chandra will be up next. Any other questions for David and Ravi? Well, thank you very much. Our next session is gonna start in about 12 minutes at 9.50 and Ian, your part title is Virtualized Mobile Networking Using OpenStack. So I hope you can stay around for that session and as Ravi mentioned, all of the stuff that you're seeing here today is down in our booth in the marketplace. So if you wanna go down, ask some more questions, get a demo, please come down and visit us at the Cisco booth. So thank you for coming and we hope we'll see you at the next session. And obviously, if there's anyone you want to seriously approach, we usually can stand around the booth or on the show for a minute or two.