 Hi, everyone. I'm Charles Echoll, I'm a Principal Engineer in the Global Technology Standards Group at Cisco, and I'm here to talk to you today about network services as code. And more specifically, network services as code is enabled by collaboration by across standards organizations and open source communities. So the way we'll be demonstrating this is using Unimanager. It's a project within the larger Open Daylight project. And the network services that we'll be automating, those are Kerri Ethernet services as defined by Math. And so we'll give you a little bit of background on Math for those of you who aren't familiar with Math. Math is a standards organization. Then throughout this whole presentation, you'll see the collaboration across standards organizations and specifically Math and IHTF on the definition of these standard Yang models that are being used here. And then you'll see enhancements to Unimanager that really enable this talk that I'm giving today where we're able to enable network services on iOS XR devices and to do those using a sandbox that has two iOS XR devices. So I can do the demonstration and you will be able to go off and do all of it on your own afterwards too. So you can get familiar with Open Daylight and with Unimanager. So first of all, Math. Math is a standards organization focused on network service standardization. And these are network services that are typically offered by a service provider to a subscriber, typically an enterprise. And the digital transformation is happening around all of us. We're all a part of it. Math also develops APIs that are needed as part of this digital transformation to be able to automate the set up, tear down and interaction of these network services and thus the network services code. So looking at Math in a little more detail, top left, you see services and that's really what Math has done for a number of years. We'll be looking among the standard services that Math has defined focusing on carrier Ethernet services. That's one class of network services. And we'll be looking at how we can automate those across multiple different network topology domains. And we'll do that using APIs that have also been defined by Math. And this is all enabled by a community, which Math realizes is a very important thing. Defining service standards and APIs is great, but it doesn't really get you very far unless you engage with other communities, working with other SDOs that are working in this space, working with the open source communities that are active in this space as well. And so that's exactly what's happening here. Now subscriber Ethernet service, this is probably the most common carrier Ethernet service. You get internet access through your service provider at home. But what we're depicting in the typical subscriber Ethernet service here, probably the most common type, is the E-Line service. There's also an E-LAN and an E-Tree. But the E-Line, what it effectively does is take two different subscriber sites and give it the illusion of being direct connected by an Ethernet wire. When really what's happening is they're getting routed over a service provider network. So we're going to demonstrate this and the way that this can be set up automatically or as code by the service provider within their network. Looking at the APIs that we'll use to do that, this is the overall Math life cycle service orchestration architecture. And you see APIs defined at various reference points. Starting from the left, a subscriber can interact with their service provider programmatically using the Contata and the Allegro APIs. And then one service provider can interact with another partner service provider to kind of expand the reach of their network using APIs as well. But what we'll really be focusing on are those APIs that are north-south within the service provider stack. And this is so that equipment and components from different vendors can interact with each other in a standard way. So the business applications using the Legato API to talk to the service orchestration functionality. And then that using the Presco API to talk to the infrastructure control and management. The Uni Manager project in Open Daylight supports the Legato and the Presto APIs. And so that's how we'll be doing that part. And then lastly is the Adagio APIs. That brings you all the way down to the element control and management. That'll let you talk to your routers and switches. And in our case, in MF's case, what has happened here is adopting NetConf as one of many standard protocols that are supported at the Adagio level. And you'll see that NetConf is also supported by Open Daylight. And so again, this collaboration across STOs and open source communities is really important in making this all happen. So let's see. Taking a look at Open Daylight. For those of you not familiar with Open Daylight, it's really a platform for the orchestration of network services. So it's ideal for us to use here to demonstrate our network services as code. And so you can see various parts of Open Daylight. Let me light up in green the ones that are important to us here and that we'll be using. First of all, Open Daylight's northbound API. You can see here it supports REST, RESTconf. Now RESTconf is an IATF standard that looks a lot like REST that you can use to interact in this case with Open Daylight. And so we'll be using that. Now within Open Daylight, there's a lot of enhanced network services. The one that we care about is the User Network Interface Manager, or Unimanager for short. And so we'll be using that. At the Adagio level, we mentioned Netconf. That comes built into Open Daylight. We'll be using that to talk to our network infrastructure, which is shown in the bottom right here, which for us will be iOS XR devices. Now taking a closer look at Unimanager. Now Unimanager supports Yang models, which have been defined by METH at the Legado and Presto API layers. The IATF defined Yang, so it's an IATF standard, and then METH has adopted that and used it as the way for it to define its Legado and Presto APIs. And this is great because Open Daylight has built-in support for these Yang models and for the Netconf and Resconf protocols that are used at the northbound and southbound interfaces here. Now Unimanager, in order to work with different network devices, there's this concept of a driver. And so you can load and use individual drivers to work with different network equipment. So in our case, we'll be using the Cisco XR driver. And what's been done recently is to update that driver to support newer versions of iOS XR, and specifically those versions that are supported by the sandbox, a sandbox that we will use to demonstrate this functionality of network services as code. So let's take a look at that sandbox. Here's what's in it. It has two XR devices, R1 and R2, and they're direct connected wired to each other. And you can reserve it, and then it's free for you to use. And you can see there's the dev box. You can run Open Daylight on it if you want to. I actually prefer to run it on my laptop. And other than my fans spinning and making a lot of noise now, that's the way I kind of prefer to do it. So we're going to use this to create our EPL service. So you can envision, here's the same R1 and R2 that are in the sandbox, plopped into the EPL diagram that I showed before. Now, R1 we will use to connect to the development center of the subscriber, R2 to connect to the data center of the subscriber. And then we'll set up an EPL service across it. Now, unfortunately, we don't have a bunch of other devices to create the larger service provider network. So we're just going to make do with R1 and R2. But rather than use the direct wired connection between them, because that kind of feels a little bit like cheating, we're going to disable all those. And then just enable specific functionality as we would if R1 and R2 were really participating in a larger service provider network. So let's take a look at what that would look like. So here's R1 and R2. Again, all of their interfaces connected. We're going to disable those. And whoops, it advanced twice. Okay, we're going to disable all those interfaces. And then we're going to enable a loopback interface that is used for us to route within those devices. And it's important for us to participate in the routed network of the service provider. How do we participate in that? Well, we enable Gigabit Ethernet 0 on both R1 and R2. And then we run OSPF and MPLS across that. So here we're actually having R1 talk to R2 and exchange routing information. But imagine each of R1 and R2 talking to other routers within the larger service provider network, other, say, core routers that are in there. And they're just participating in that. So next we want to set up our UPL service. And again, I said we're not going to cheat by just using those direct wire connections. But instead, we're going to build on top of what we call here the day zero configuration. And this configuration is what you will see when I switch into demo mode and start to work with creating the EPL service. And that's also what you can think of that the service provider would be operating in their network in steady state. They'll have all their devices there. They'll all be participating in a larger routed network. And now a subscriber comes along and says, hey, I want to connect my sites. Can you do that? And I want to order this Ethernet private line service. So what we're going to do here is we're going to enable Gigabit Ethernet 1 on R1, Gigabit Ethernet 2 on R2. So we're not just doing the direct connect. Instead, we're routing across the network using OSPF and MPLS to connect these two together instead of using the direct wired connection that you saw before. So again, Gigabit is as close as we can to simulating a real service provider network when we only have two devices. Okay. So we take that. And now we go and we use Open Daylight. And R1 and R2 you now see at the bottom. They aren't connected to Open Daylight yet. We're going to use Postman to drive the automation here. And so using Postman, we will interconnect, interact with the REST conf interface that comes built into Open Daylight. So we make a put request to add R1. Open Daylight reaches out through its southbound net conf interface to R1. It connects to it, adds it into its node inventory, learns all the Yang models that R1 supports, and adds those into its model cache. So now Open Daylight has discovered and learned how to interact with all of the APIs that are supported on R1. And that's thanks to the Yang models and again, the standards that we have there. Now we can do another put to add R2. So now Open Daylight connects to R2, adds it into the node inventory. This supports the same set of Yang models. So there's actually nothing new to add into the cache. Now Open Daylight's ready to go and talk to both of them. Now I'm going to, I know I'm going through all this very quickly in the interest of time, but let me just tell you that this is the GitHub repo that has all the directions you need to to build Open Daylight to end the Uni Manager project, to run it, to enable the feature set that you need on Open Daylight, to connect to the sandbox, to get it into the day zero configuration, and then of course to do the rest of the steps I'm doing in this demo from here on out. So at this point I'm going to switch out of doing the slides and go into demo mode. So okay, and let's hope the demo gods are friendly here. So what I have here, this is my Open Daylight. So it's up and running already. And let me just show you what I've done. I've enabled the Uni Manager feature set on it. So that's what you see here. Uni Manager with the Legato API, the Presto APIs built into it. And I'm using specifically the, I loaded the Cisco XR drivers because those are the devices I want to connect with. And then what I have down here, they've timed out, but I have R1 and R2 in the sandbox. Whoops, I need to connect to both of these. Let's see if I can type the password correctly. Yes. So I'm into R1. And let me show you, whoops, IP interface brief. You can see here I have the loopback interface. I have the management interface. Of course, I have Gigabit Ethernet zero up and running with OSPF and MPLS. And I have Gigabit Ethernet one up and ready for me to create my EPL. Now over here, I have R2. Let's connect to it. Do the same thing. Let's show IP interface brief. And you can see that here it's very similar except Gigabit Ethernet one is shut down because remember, we don't want to cheat. Not if we don't have to. And Gigabit Ethernet two is what we're going to use as part of our EPL service. Okay. So this is the day zero configuration up and running and we're ready to go with that. Now the fun part, we're going to use Postman to drive the automation. And what is here is a environment with all the variables defined that I need to connect to the sandbox. And then I have a collection here that allows me to interact with Open Daylight. You can see I can work with the network topology that we saw before to put R1 and R2 into the topology. And I can then check that topology, make sure it's there. I can of course remove them from the topology. And then these are my EPL services. I can check to see if I have any running. I can put a new one and I can delete one. So let's take a look at this. Let's start by checking our topology. And you can see I get back a response telling me I have an empty netconf topology. There's no devices connected to it. So let's go ahead and let's add R1. You can see I do a put to here's the URL here, adding R1 into the netconf topology. You can see I got back a 201 saying it was created so that looks like it was probably successful. Now R1's getting added. We're building out the model cache. I should be able to do a get and now I should be able to see it. And sure enough, here's R1. And here are all the capabilities that we learned from the Yang models. Now I can similarly go and let's do the same thing but with R2, adding R2 in. We do a put. We get back a 201. This should be even faster because we just add to the inventory. We don't have to build the model cache. So now I can check and see if R2 is there as well. And sure enough, it is. Here's R2, all the devices. And if I check the topology, the overall topology, I can see it's not empty anymore. I have R1 and if I scroll down, there's a lot of capabilities in those Yang models. I'll eventually get to R2, which let me cheat and move this down a little bit. You can see I'm connected to R2 as well. So I have both R1 and R2 ready now. And now I'm ready to create my EPL service. So I'm going to do a put to create a new one. And here's the URL. This is basically derived from the Yang model. I'm creating a carrier ethernet service and it's an ethernet. It's a subscriber service as we saw in the slides before. I give it a unique ID. If I look at the payload here, I'm creating an EPL service. And I'm connecting it to a gigabit ethernet one of R1. A bunch of other parameters as well, of course, connecting to gigabit ethernet two of R2. And the rest of the payload is as specified in the Yang model and the API, all the characteristics of the EPL service. So let me go ahead and send that and cross my fingers. It looks promising. I got a 201 back. That's a successful code. What's happening now is Open Daylight should be configuring both routers with what they need for the EPL service. And now I can do a get to see if they're really there. And it looks like yes, the configuration is really there. So I should have my EPL service up and running. But we better go check just to make sure. So let's look on R1 and let's do a show running config L2 VPN. L2 VPN is how the EPL is implemented on XR. And I can see one got created here. And here's my neighbor, which is the loopback IP on R2. And if I go over here and I do a show running config L2 VPN, I can see it's up and running here. And here's the loopback interface on R1. So it looks like they're up and running. Let's look a little bit more closely. Let's check the status. I can check that this way. Show L2 VPN X Connect. The status is up. Now let's try on this one too. Show L2 VPN X Connect. Okay. That looks good. It's up also. Now the final test, can I do a ping across it? And so I'm going to do the pseudo wire ping to ping from one interface to the other interface. So as if traffic was coming in and I want to see, will it make it across? So let me go to, I need to go over to segment two here. So 200, 200, 200, 200, 204. And fingers cross. And it's successful. All five packets made it. That gives me pretty good confidence. But let me just run the ping on this side too. Ping if I can type pseudo wire. There we go. So here I need to go to this IP address 100, 100, 100, 100, 204. And that's good too. So the demo gods were friendly. My EPL got set up across the devices. Now just to make sure this works, I should be able to delete that service too. And so let me go ahead and do that and check. Did it really get deleted? Okay. It looks like it's not there anymore. Let me try my ping just to make sure that it went away. And you can see my success rate now is zero because my EPL is not there anymore. So now they're very quickly got torn down through really just one request, right? The put to add it and the delete to get rid of it. Okay. Let me go back to my slides briefly here to wrap this up. So again, everything I've done is in this GitHub repo. You're welcome to check it out and get this up and running for yourself. Here is how to get to that GitHub repo. The first one is the link to the GitHub repo. That's the instructions to do what I did. The second one, unimanager code. That is the stable version of the unimanager code. And then the third one, these are the recent changes that I've made to add support for the newer versions of iOS XR sandbox. The newer versions that are supported by the sandbox, I should say. So at the time I recorded this, it submitted, the pull request is in. It's being reviewed. Hopefully by the time you watch this, they will have been merged in, but in either case, you have the links to both so you can access them. So thanks for joining. I hope you enjoyed this. I hope you do try it out for yourself. I'll stick around and be here for questions and enjoy the rest of the conference.