 All right, welcome to the marketplace session about glue on we're going to talk today about why and what it is So why is glue on needed? So my name is Toby Ford and I work at AT&T and my partner here been who he also works at AT&T So we're a little biased toward the NFV workloads, but I believe what we're going to talk about is applicable even broader than that Certainly the impetus to do glue on came from the NFV space and what we're having to deal with So at a very simple level the difference between an enterprise or a public cloud or a typical cloud environment to what we're doing is that typically the clouds that had been built before Were ones that were endpoint oriented whereas what we're building has a lot to do with moving packets from one place to another and Processing those packets as they go Certainly the cloud had been doing that but not at the scale or at the distribution that we're talking about so in a specific cases when we think of Networking we often talk about the OSI model layer 2 layer 3 and such In a data center, you know in a cloud data centers that we built before Often that that boundary was at the edge of the building so we did a lot of L2 stuff in the building and then we sent it to routers and routers would deal with the WAN and whatever was happening in In a in our implementation of NFV. We've shifted that boundary Where does that L3 happen and we've moved that into? Possibly into the VNF itself into the VM or into the hypervisor or in the container management scheme Move it all the way into that layer And we did that because in our belief is that In order to scale and to provide the same Reservation and separation end-to-end from one building to another from your house to our data center from your house to let's say Sony's content management system We want to make sure we can provide consistent connectivity and again separation and reservation So when we've looked tried to implement this concept in open stack And with neutron, you know We got made some progress and then not only us but others in the space orange and such have made progress in making What the way that we think of networking in their use cases map to neutron and kind of contort neutron to our needs But it's as we've gone along and tried to increase the number of use cases and increase the career You know the sort of creative ways that we're doing networking it's starting to show some issues and it one of the issues is a central concept of getting trying to get to a standard API and You know convinced that there's only a simple API that can define networking versus one that is Extensible enough to even to the point where if I made a new service tomorrow that the networking API would change and that's really not what what is intended by the the networking design in open stack today, so So beyond that even if I extend and I keep going in that direction I want to make it so that when I do make that API a multitude of vendors and backends can actually service it very much like ML 2 does today But but even broader and even broader in that it's not just about moving the packets It's also about processing them and this is where service function chaining comes in and service function changing also has the same dynamic of in some Models, it's L2 oriented in others. It's L3 oriented Unfortunately, the existing implementation of of SFC in neutron is very L2 oriented So this is an example where you know, we want more flexibility and more Extensibility so this is an in many other dimensions You know if we think of networking changing just look at the attack that happened last week It's inevitable that networking is going to evolve in new ways with regard to encryption or authorization whether it's me being authorized or a token or if it's going to be content based routing whatever it is It's got to evolve so we have to make an environment networking scheme that Evolves along with these changes and our our view is that You know, we wanted to test this area and try to come up with a way to make it work That allowed to meet us meet our needs So we created this glue-on project You know some of the side effects after the fact we didn't really go into it thinking this But some of the side effects that we've we've realized and our benefits of glue on it as well are about how it's possible to Change out networking constructs have multiple more than two Network constructs SDN controller data plane combinations Have different versions have them all within one environment and be able to maintain that and keep the VMs running and change them between Network constructs so an additional benefit came along from this this work So we didn't really intend necessarily to replace neutron Just demonstrate what's possible and then over time figure out an appropriate place to integrate so I'll pass it to now to To bin to for him to describe what it what it is Thank You Toby So let me give a brief overview of the high-level design of glue on and The glue on basically composed of a two major components one is the ground framework which includes a particle generator and the glue on maintains the mapping of port and a different back ends in the database and Forward the port related request and to the correct the back end and There's a second component of the proton of glue on is called a proton So basically that's a networking API's and it will give the name of proton So different type of network APIs are different of protons and how proton was generated is that there's networking services Was modeled in the model file? So now we implemented the model in a YAML file But it really doesn't matter which type of the model and we are using for example We may also use a yam model We can also use a toss come model or different type of model the key concept here is a model right and the actual model that models the actual networking services and The glue on framework has a component also called a particle generator The particle generator will read the YAML file and generate the API and points and a database schema and for the for the API and the services itself and so the only requirement here is a concept of port and so that the Compute services right can request and start a virtual machines and bind the port to the different back ends and with those networking services and so that it gives the flexibility and Extendability of the new networking API's and based on the model and that's be Created at a design time and also executing those the services at the execution time And of course it's the concept of the highlight of architecture design and that it may be implemented in different ways And so we have implemented the proof concept four months ago and in the open way summit And so here the picture gives the implementation at that time and that time we implement glue on as a stand-alone server and The server will be basically be configured as a network API class and and work with a nobody directly and The glue on server has a logic to determine whether or not the port is from The prutam or the port is for neutral and then if the port is from the prutam And it gives back and the port finding request to the different network API's in the prutam part and the prutam will work with The different editing and controllers at back end if the port is a regular Neutral port and it just give the port to neutral and the neutral will handle it in a conventional way so that all the happy users will be happy And so you can see from the typical the workflow perspective, right? And that prerequisite the users will be able to find those API and points through for example the keystone or some other service discovery mechanism and then the users will be able to use the Prutams all the neutrons to create the port and the network services and then the user will be able to Launch the virtual machines and with the port as a parameter and Nova will talk to the glue on and give the port Information and so that grew on will handle those posts respectively whether or not is be handled by the prutam and its back end all by the neutral in a regular way and for The network API class in the Nova was deprecated and because of the Interoperability concerns and the deprecating of the Nova Networking part and so for this the Open stack summit and we implemented in the temporary using the neutral plugging method so basically we extended subclassing the ML2 plugging and class and We created dummy network and subnets and for the port creation and also using the separate database and from the neutral database and the extended code for the last rappers the The call plug-in will be able to determine whether or not the port is for the ground port or it's a regular the Neutral port if the ground port it'll give back to the proton server and Let put on the handle that and with a network in the back as differentiating controllers And if it's a regular the neutral port it back to the regular the call plugging and let L2 agent handle it So that's where how we implemented at this time And the glue on of course glue on plug-in rappers will have the port arbiter functions in a put on servers at API server And the shim layers will handle all the different ds in controller configurations and make sure that all the back ends will interoperable with each other and it will handle all the related functions and at the back end and it can support a different type of acting controllers as well So here's the example about the model that we of those APIs and in the YAML file then so we use the L3 the VPI as example and you can see that the Any network services can be modeled in this way and it can be read by that particle generator in order to generate the address for API and points and Validate these endpoints and the database schema and the back end communication method and and store those informations in the ETCD of course and The model here the key word is a model It doesn't have to be in the Miamo right and as long as we have tool and we can be modeled in the Yang You have me modeled in the atosca or different about modeling the languages and models, right? And so that's kind of flexible in the back end and the proton will be able to communicate to different the acting controllers through the ETCD and Using the pop-up model, right? And that's you it's a distributed a key value store in the ETCD and shim layer will listen to the update and from proton server and to be able to act upon those requests Accordingly and work with the different acting controllers So the benefits you need made a need of the plug-ins and supports multi wasting controller back end and so any acting controllers can be plugged into the The picture at a runtime and just listen to the ETCD for the different the updates and ETCD died and also the model is a key value. So the any kind of the Jason model it can be supported and as a value of the Models in the ETCD database So the main benefits more simplicity so individual API get any points It's a much simpler because they only have to do one thing, right? And the one back end if as in controller a it's good at doing the service a as in controller B It's good at doing service B and they can do it and it's in its own way and in a mass simpler way And the more choices right and I don't have to find the a one-two of this everything I want And I choose the tool that's best fits my need for this particular service, right? More innovation, right? And we can have them basically unlimited innovation of new network and services and to be created design time and to be launched and Quickly launched and that deployed to our customers and that we fail fast, right? And that as a agile method and to enable users in the technical market and to serve us customers in the more elegant way and in a more rapid way and Accelerate how to market of launching the new services to our telco customers and so Toby will be Wrapping up the talk. Yeah, so then We've actually worked very closely with a number of vendors. It's a rare opportunity to actually have What do we have Juniper Ericsson Nokia Cisco and now Huawei all helping us to make glue on work So if you search around here At least three of them have a demonstration of of glue on as well as at our booth We have a demonstration of of what's glue on looks like So I think this is a good example of a group of community members working together to actually make something work now the real trick is how do we take it the next step and Make it make it real and make it implemented in a release of open stack all right, so like to ask There's any questions about this and feel free Don't want to get in your way between Whatever you have coming next Any questions? All right. Thank you very much. Oh, hey So right today You want to talk about that is what where is it now in terms of being an ml2 plug-in or where is it in the process? yeah, so working and actively working with Nova team the new team and to determine what's the best approach and to move forward in terms of working and integrating with open stack and so We have different implementations and the both implementations Proved to be practical and to be working and we wanted to do it in the right way Ultimately and they have the right architecture and moving forward and ultimately benefit the open stack and the whole ecosystem Yeah Yeah, so we need more supporters from the community, right? And that's to support us to work within the open stack community Hey, can you get this guy out of here? Heckler, all right. Thank you everybody. Have a good evening. Thank you