 Good morning. Good. Yeah. Thank you. And so we'll start for the next session. And the title is GluWang, the enableable energy. So I've been for AT&T and we'll talk with Yidako from Ericsson and Yan from Cisco about what's the telcos requirement here and also what about what's the GluWang and follow up with the how we can make it a community effort and so that we can make it more success. Thank you. And let me get started. So let's start with the use case, simple use case here. And from the diagram and so that's how AT&T is in the future in the for the D2 network functionalization and how we are thinking of the architecting on the overall the network in terms of the using different the sdn controllers on the one open stack the cloud and orchestrated by a global and we call the master service orchestrator. Okay. And so you can see from the diagram and you can see we in this architecture and we will have the one global sdn controller. We have several or multiple the sdn local controllers which manage different virtual routers. And the reason that we are doing this architect is that our network is quite heterogeneous right and we have access we have core network back long haul and so there's no one shoe that fits the every foot and so so we in order to support the best performance of our with the different type of networks and we need different types of sdn controllers that can manage the different network segments different administration demands from mobility to the enterprise and so that network architect will give us more flexibility and in terms of having different solutions and to serve our customers in the best way and there are some that's my bad yeah so from so from the overall the architecture perspective right and you can see there are several kind of maybe more general kind of the requirement that's being derived from the global architecture includes we need a common data plan in which for example the MPS over GRE or MPS over you do here or VXLAM and we need a common control plan which based on the VVPN or 3VPN and as in the last talk we also talked about that all different the data plan control plan in terms of service functioning right and we need all the common the configuration parameters and that can configure the all the different controllers and we also need a common open stack controller interface right and so that we can have uniformed the application API and to control and create all the different top of the networks for example L3VPN that we managed by different type of sdn controllers under one cloud and so that's the kind of a common requirement derived from the overall architecture so here are some example use case so I'm not focused on those use case but just use case that be coming from and for now and but more importantly those use case indicates that we will have a more use case and which serves our rapidly changing the custom requirement in the future so what we need and from use use case so that's a simple use case and for for example for the one the common L3VPN IPVPN that be managed by different sdn controllers and on the one cloud and from the diagram you can see that with the VPN the blue and VPN red and they will be served by two different sdn controllers and which managed the different virtual routers right and by all those sdn controllers working together and we create on the subnates and of the VPN and on the different nodes and it will be interact and with and managed by the different controllers and on top of this use case right and we can extend use case to another new use case on top of that which basically the equal cost multi-path and basically you can see the traffic will be from either the external the global gateway or from the internal another different VNF and by creating the different instances of the different VNFs and it can do the load balancing and the splitting the traffic and to the different end points and the scheduling here is not the is not the focusing point here right and but the important here is that we need to have a way and to basically and support the splitting of those uses of the different traffics and to have this ECMP top of the use case to be supported and the third use case is basically it's simply the service function chain I would say yeah it's called the hub and spoke and so basically you have a firewall right which is hub and the best all the traffic is to go to firewall first and then you will have the different the VNFs could be a web server could be some other services and all the things and use the chain together and using the VPN best approach and to create and there was the use cases and so servers customers right and in more meaningful way and from those use cases specific use cases and you can see some more commonalities here right and you need to have a different multiple service based on multiple computer known multiple hosts that's running on different vendor controllers as in controllers and the overlay routing and software and for the L2F3 different of VPNs and and MPHC VRF the virtual routers and you have a multiple vendor routers in a one subnet and you have the sharing of common control plan and the parameters using the BGP and to exchange those information and including the route targets and across different multi vendor controllers and you have control and routers communicate directly and without going through the gateway and for the east-west bound traffic so you don't need to go to the gateway router in the data center but instead you have a direct communication and connection between the different extant controllers and direct the BGP pairing for those the controllers okay don't have time and so more importantly is the key categories here is those use case above right is just for the example purposes and what we wanted to emphasize here is that the telco and SCAP is rapidly changing and we need to have an agile method to enable all the different new use cases in the telco market we needed to have the accelerate time to market of launching new services to serve our own customers and including everybody here right and hopefully everybody's getting this customer and we need to have the enhanced agility business agility to benefit the whole ecosystem and you have flexibility of different technologies in the in terms of back end implementations implement new use cases and to have the diversified and the back end and last but not least the common APIs with diverse back end implementations right and we allow for the different type of innovations in terms of implementing the use case and by saying that and hand over to Ian and talk about the how he proposed and the things his best way and to help us in the to implement and those the new challenges we're facing okay so yeah what I basically took this and tried to lay down a set of requirements you might need for software as opposed to you know the high-level requirements as they were coming from a service provider we're trying to solve a problem here that the service provider networking is very different generally speaking from what you find in a data center and data center networking is largely what Neutron in OpenStack has focused on to date and it does a very good job of what it does but but then when we start doing the weird things then then we drift further and further off track from what it was originally intended to do so in our software grounds we still do actually want to use Neutron Neutron is fantastic code for what it does and I'll give you an example in a future slide of how we use it but we also want to use API's that are increasingly unlike Neutron we've got some of those today and they've been incorporated into Neutron as extensions like there is indeed an L3 VPN API in Neutron but it's an L3 VPN API kind of catering to the way that Neutron thinks about networks as layer 2 networks with or at least networks with a common subnet we can play more games with MPLS if we if we allowed to break that model and move on to something slightly slightly different we'd like clear water between the API in the back end so as an example Neutron's an interestingly bad example here Neutron folds a network controller the ones you usually use when you're using the open source versions are actually incorporated into Neutron but Cinder might be a better one Cinder your your front end is very straightforward and it just offers the API and the back end is internally independent and offers the storage itself so what we want to do here is you want the API to do what API's are good for and we want an SCN controller to deal with the networking components which is a different job with different requirements we want to experiment we want to try new things fast now I'm gonna leave you to think about how long it takes to write a new API and get it into OpenStack we're not talking about API's that we get into OpenStack here we're just talking about API's that we want to try in the lab to see if they're right API for us and if it turns out they're not the right API then we want no guilty in throwing them away and trying something different so this wants to be a fast development process for us to experiment and for everyone else who wants to to experiment and we want to use multiple API's and multiple back end simultaneously and this comes back to Bin's point that there's lots of different kinds of networking in a service provider network and there's different ways of controlling it for different purposes so when we're talking about a different purpose we want to put an API that's purpose or at least use case specific has relation to what you're trying to do to the network but the back end also wants to be least potentially independent because we have different network controllers AT&T have more than one kind of network controller in their network but also and I come on this point again in a further slide is it's nice to be able to do a bit of feature shopping so if I can find different SCN controllers to deliver different features I can use both of them at the same time so the core concept of glue on is to connect a network service provider with virtual machines now and Neutron provides network services it doesn't have to be the only thing that provides network services I'm doing something different then I can provide network services from a different SCN controller with a different API to do a different job and so I write a new API endpoint for my new networking concept whatever it happens to be and as long as it understands that it's dropping packets off at a port that then I plug a virtual machine into then we're all good it fits in with the same model that Neutron currently offers today so as long as we have that common idea of a port across the board between Nova and Neutron and anything else that comes along and we can bind that port to connect the two ends together then we're good basically the rest of the structure however can be completely different so I can use verfs as in you know routing tables instead of networks I can avoid using subnet so I can use different addressing systems I can basically move my packets hither and yarn however I choose as long as I can describe it with an API that I get to define and so glue on's role in this is it's a tiny tiny piece of code that sits in the middle when a network controller creates a port it tells glue on here's a port it's mine when Nova ever wants to bind to that port it says here's the port number I've been given that I'm going to bind to glue on will find the network controller and tell it that the binding is happening that's it it's it's a little arbitrator if you like in the middle of the process so and again here is a typical very boring NFV setup I'm just trying to emphasize that there are different kinds of networking here and they usually break into two factions one is the control network is generally you're in a normal application it's not quite a web app or the normal sort of app you would run in a cloud but it's an application there's in this instance I put an element manager which is a block out of the Etsy diagram something's talking to the virtual machine to tell it what to do it's probably monitoring it it might be restarting it if it fails that kind of thing the application functionality that that lives behind the scenes in an NFV app the virtual machine moves packets around and does things to those packets typically much more high bandwidth stuff but it's the APIs you want to generally bringing traffic in for certain places like for instance an MPLS overlay in a service provider network so there we're looking at strange strange new APIs to do service provider specific tasks and as you can see the top end half of that I would normally use new in fact I do today use neutron to do this it's basically nothing different from any other application that you would find in a cloud so again I was saying glue on sits in the middle here glue on basically receives information about new ports that are created the these APIs are API endpoints that your application talked to or you use a command line interface to as normal so in much the same way as you create port in neutron today you will create a port on a VL3 VPN in in another API tomorrow every time one of those ports is created glue on stole that the port exists just in case it needs to know later and then when Nova starts a virtual machine it will talk to glue on saying I've been handed this port and I want the traffic for this port and the binding will happen important to note again on this one here that I'm using different kinds of port from different kinds of network provider within the same virtual machine so I can use neutron and something else at the same time because it's all made a decision on a per port basis so that's the rough workflow I said to give me the networking set up that I want to however many APIs I choose to use and then make me virtual machines to Nova which will then bind the ports one by one and again the API in the controller are entirely independent of each other so I can have if I use open daylight for instance I can run both neutron and other function like service chaining within open daylight and it will service both kinds of API or alternatively I can use something else for my layer 2 I can use say the standard neutron OBS plug-in for layer 2 so I'm using neutron as the API then I can tack on a second kind of networking completely independently without affecting touching or in any way changing neutron so two advantages here to me I've got two things that that are independently simpler and they're much more likely to work and be easy to test and anyone who's using neutron alone because they're standard enterprise guy is not affected by me wanting the weirdest thing in the world in networking doesn't bother them in the slightest I don't have to change the neutron code doesn't get more fragile for them so what did we change Nova we in Nova there is a plug-in at the bottom end it's where Nova network used to plug-in it got replaced by or you can also add a neutron net and plug network plug-in down at the bottom there and so what I did is I changed that code out for a glue-on plug-in so instead of talking to neutron it talks to to my new bit of code in neutron I went I fixed a minor bug because it has strange opinions about whether it's running neutron or Nova network and the logic's a bit confused but never mind in neutron added two lines of code to register reports so every time a port is created it just tells glue on that something's just happened the glue on code is the version one of the code at least is an embarrassingly small less than a thousand line chunk of code that basically sits as that arbiter in the middle and then wrote a new API for networking so the implications of what this drives because obviously the little bit of coding glue on is the boring bit of this the interesting bit is everything that lies around so your API is a simple rest models the same as you get with neutron Nova and friends today that code has to be a web service its job is to receive a request store it and not necessarily immediately do anything about it all bits of open stack work like this today they store what you want and they will eventually the thing becomes active but in general they're just storing what you're looking for they're not trying to do it on the spot and so we we store into a database same as you would expect in neutron and friends there's a protocol at the back because we've got an SDN controller living separate this protocol exists in various forms within neutron today you need to tell the back-end network controller that the demanded state of the network has changed and it's got work to do that code exists in its various different forms but the same logic is there for every single external network controller that exists behind neutron if you're interested in reading the code I would recommend the open daylight one because I think it's got a good handle on the synchronization problems you run into it can be a problem with things like fault tolerance if your network controller reboots or if you want to for instance upgrade or restart the front-end service getting that network synchronization to pick up where it left off that network database synchronization to pick up where it left off is a bit of an art and then the back-end the controller is a choice your choice depending on what you're trying to do what your preferences what your testing demonstrates for your use case it's event driven it does a hundred and one things at once it's talking to lots of either hardware or software devices and it needs to be asynchronous to do that it's a very different code pattern from from an API in general so it actually also in that regard makes sense for it to be a separate thing also SCN controllers across again open daylight you have a structure open daylight is a nice framework on which to build network control code so you can go out and use something that's done a lot of the hard work for you and then build your network control code on top now on network API is there the interesting thing here really we called them protons because we got a bit carried away frankly so we have these protons where we can add new API's but obviously if it takes so long to write an API today why is it going to be any different tomorrow why is it going to why is this going to speed up my development at all well the answer to as I said we went a little far on the naming thing we came up with this idea of a particle generator so what we do is is we wrote a little bit of code which it basically takes a configuration file and that is a real configuration file on the right that really parses in fact that describes an L3 VPN a fairly simple L3 VPN service and by reading that we can generate the rest API with some validation on top we can generate the database schema which is normally hand coded by a bunch of SQL alchemy files in in your average open-stat code and we can generate a back-end communication system that's that's standard across everything so that saves us some jobs and it gets us the work done much faster and again to recap and at the point that bin was making earlier on multiple SCN controllers we do want multiple SCN controllers in this to do different tasks in the network so our aim here is to make sure that we're enabling more than one SCN controller to give you that option to shop for features among the SCN controllers you might lay hands on and also to make sure that if you want to do it this way and again it's your choice but you can make your SCN controls a little bit simpler because they focus on one task and do the one task well so our hopes here are that we get a bit more well a lot more hopefully innovation in the kind of networking APIs that we need specifically for NFV where there are a lot of odd little use cases you don't generally have a you know a metropolitan or a wide area network sitting at home that you're all in your data center that you can play with bin has one he gets to play with them so he needs code that's specific to the way his network is set up and service providers are all different they don't they use consistent tools and protocols but they don't consistently deploy their network in the same way so so API's that suit bin for his use of MPLS may not be a good API model for someone else using a different usage of MPLS so if they need to experiment this enables that possibility for them and it gives you more choice so I don't have to find one tool that does everything I want already I can go and shop between two tools one to another so and there are risks that we run in doing this right the obvious one I've just said it is that if I can make an API so easily why don't I just make an API that's completely different and special and then argue that mine is better than everybody else's well funnily enough that's that's a problem we've had since the year doped quite honestly and the IETF and I put in here as a point the IETF has an approach here everybody writes their own network protocols and they're all different and then they get together and they try and pick the common elements and try and standardize on it the aim here that we need to achieve is to build a working community around this kind of ecosystem so that when everybody comes up with their magical and special and different API then we don't start just having 16 different API is doing the same thing and then you know you buy a VNF and it won't work the API you're using because it's different and special then we want to make sure we standardize so building a community from the network side of the fence to make sure they understand how to what APIs are going to work best for them for all of them together is key to this and less quality because potentially these APIs again have different back end SDN controller implementations and since there's no one implementation everybody is working on there's a risk that they're all kind of shabby and none of no one of them is good enough for your purposes that again it is a risk since the year dot we all do it if we didn't have this kind of divided thing we wouldn't end up with different companies selling different products the same area what we can do there is at least on the open source side of things we can collaborate with an opn a fee and make sure that we're building network controllers to spec to purpose and bringing our bringing all of our expertise together if we do it independently I'm a vendor right so I guarantee you somebody in Cisco will write somebody to write a network controller to do something that's so much better than everybody else's if you just pay us money and I'm sure I'll deco will say the same very quick and if it comes down to it and I'm fairly sure we've got other friends in the audience who would say exactly the same but that's our option right we will build a network controller we will spend our money to build a network controller you will look at the network controller you will say I don't like that and I'm not paying that money for it or you'll say that's fantastic and I will take it it solves all my problems so much better than what I'm using today your choice a little bit of competition is not such a bad thing we just don't need to get it to complete proliferation and with that I will leave you with Ildiko who is going to tell me off for coming in a bit too short but there you go yeah thank you all right oh we have still plenty of time left so I would like to share you how we would like to actually make this happen and how we would like to involve all of you in the room and all the players that we have in this industry to make this as a common effort and a common vision and a common success because we started these discussions about these use cases that how we could implement them a while ago and then we had to realize that we will not be able to do this behind closed doors because basically it's not the use case itself that makes it so difficult but we had to realize that our current cloud platforms are not really NFV ready yet and this is what makes the whole situation tricky and as just Ian pointed out we all need to focus on this homework and fix those dependencies first before being able to implement for example these use cases that been described you at the beginning of the talk in an efficient and flexible way and in a way how we would like to do that first of all we are currently still in the stage of experimenting that what exactly we need what exactly we would like to do because you must have realized that we explained your use cases and we explained you architecture but the architecture itself does not address the use cases directly it just provides you a framework where you will be able to implement your own use case is a way in a way how you would like to by the end of the day of course we would not want to stop at the requirements definition phase and you know just collect use cases draw nice diagrams and put it into a standardization body and then just we did our homework we are good we can go home because this is how tackle does their things this is the 21st century so these things are changing and we are rather implementing defective standards and we are trying to ensure that what we came up with as ideas we have the implementation in place as well we have the prototypes we tried how it works and we enhanced it further as much as we could so we decided to step out of the door and bring all this effort into public and we chose opnfv and maybe a few of you would ask that why we didn't just come to open stack and solve the problem here exactly we wanted to first provide the synchronization point for the telecom industry we wanted to gather all the vendors and service providers together and discuss with them that what we would like to do because one of the the biggest pain points when you try to move to the implementation phase is that you are not always able to describe clearly enough what you would like to do and this is one of the feedbacks as well we just got this week from the open stack community for example that it is good that we are trying to do things and they see that we are trying to do actually good things which will be beneficial for for all of us including really all parts of the industry but they don't always understand the purpose of our requirements our needs so we need a bit better communication format so this is why we we chose opnfv to really discuss and make each other understand that what and why we would like to do what we want to all achieve and then we can we can go for example join to open stack and do the implementation phase here like how we already started as you could hear yens description about it the the other cool part in in opnfv just as you can see on the figure that it is way much more than just a forum for communication because we are in this community we are building together a full cloud platform end-to-end integration and we are providing tests verification and validation tests on the integrated platform so this way we have feedback on whether our implementation really works whether it really serves the purpose that we designed it for and whether it really fulfills all our requirements that we have what one more thing about opnfv which is important for us is standardization because I just said a few minutes ago that that we don't do that anymore it's it's not true in hundred percent it is still still important so in opnfv we are also working together with standardization bodies like etsy or or IETF and we are trying to be a bridge between standardization and the open source communities and upstream communities to speed up the process that we had in the past I don't know 20 30 years to really bring you implementation and solutions way faster than how it worked previously so we created a project it is called network readiness and we gave it the nice and cute nickname net ready it is a very brand new fresh and crispy opnfv project it was created a month ago we are already having weekly meetings where each each of you all of you any of you can join and I would like to encourage all of you to come and share with us your pain points your ideas how you try to solve those pain points how you manage to to solve them give us feedback whether we are investigating in a good direction or not and let's let's try to make this as a real community effort and also what is really important this project can also be a really good forum to synchronize on on our APIs that we are using because even if we have now a sandbox where we can play when we can experiment where we can have our prototype implementations once the APIs will be mature enough to be ready to be production ones and we would like to be able to provide an interoperable platform by the end of the day and for this it is very important to have this synchronization point and come up with all those solutions that that serves our purpose in a flexible and efficient and good enough way and mainly this was what I wanted to say and I would like to invite back Ian and bin to stage because I'm sure that we have a few more minutes for questions we have mics on both sides so please come and grill us with questions nice presentation one question my first impression was the the port abstraction could have been a subtype or a subclass of the neutron port which is kind of evacuated out made really lightweight I'm sure you explored that path I want to know what were your top two three blockers or you know what came in your I'm curious so you're right you're absolutely right in the actual fact that the the template that I showed on the screen there as an input to the particle generator what you don't know is there's a line at the top with a very sarcastic comment saying this should be a subclass of a neutral ever glue on in this instance port but the second part of that we yes basically we've taken neutrons model of a port and trimmed it very slightly down there's a few things that they're very neutron specific that come out of it many of the things to do with binding should stay in MTU management VLAN transparency should stay in but a lot of it is just well not necessary and I think one of the rules will find we have to change that exists within neutron today is when a port is created in neutron it immediately gets an address whereas in general you can do better work if you give it an address when the port has found a home on a specific server in a cloud so we might want to leave that's that option open to ourselves why is it that we're talking new APIs and not simply adding to neutron the answer to that is that ports in neutron are tied very closely to network ports are always on a network networks always have a subnet subnet's pretty much describe how the addressing is going to work that model is constricting when you're trying to do something a little bit out of the ordinary and that that's true enough for L3 VPN we've kind of worked around it with the interface that's in open stack today by saying well each of these will actually be they'll think they're in the same subnet but actually they're not really something weird is happening just like the upstream it's likely more thrown away in the service chaining API honestly but I'm fairly sure as we come and we work on this in the future we're going to find that that model is too constricting and we want to we want to do more interesting things than that so I'm trying to get away from the thought that every port lives on a network and to the idea that a port you know all I care about a port is that both sides recognize that it's a drop point for traffic nothing more than that thank you hi presentation and I get the difference between the carrier networks and the data center networks looking at presentation I see a lot of similarities being this and OVN do you want to sort of compare contrast what your thoughts are and I'm going to admit that I'm not very well educated on OVN I have to say but the thing about this is it's really describing the clouds interface to networking now if you're hiding OVN underneath that that's just fine and and I wouldn't stop you and you go for it but the clouds interface offering is almost exactly the same as the SDN controllers interface and OVN is in a form an SDN controller but it's just taking away a couple of bits and pieces it's taking away that that kind of the asynchronous nature of a back end from from the asynchronous nature of the the application so the application tells you what to want what it wants you to do then might be polling or so on to to get things to work it takes away the role-based access control as well that you would expect to open stack but the SDN controller really doesn't care about for the most part SDN controllers and this is a personal opinion I grant you but my opinion is that SDN controllers shouldn't know about users shouldn't know about tenants these are not things that SDN controllers should care about should care about putting the network in place so so it's it's only a level difference yes you're right OVN probably does do a lot of similar things but it's the SDN controller component I think you should look at it could be it's a very logical model it's a logical model of the other network so it a lot of the similarity you're talking about and also having ports not tied to a particular host you have around yeah there's a lot of even even the code generation factor it's slightly similar in some ways but there's some really interesting parts there that yeah it's worth it no it's thank you for the tip actually I will go and explore that could you please comment on the state of glion as a project in the open-stack crowd map wise as well as kind of separate question but what amount would be in work would be involved in an SDN controller itself like open daylight for example to work well with okay so in terms of a project it currently lives in my github I have to admit it's not an open-stack project but for what it's worth it's more than just me working on it so at least there's that much we want to make it an open-stack project what's in there at the moment is firstly the original demonstrator to say that we could do this and it does actually work that code works today you can actually go there you can read the documentation deploy it via dev stack and what we're working on right now is a rather more tidy implementation along with the the particle generator stuff which is coming along nicely but is going to take a little while longer what we wanted is something that was basically functional so you can see the intent of it before we brought it along to open stack so we're not we're not trying to not have it as an open-stack project it's just that it feels a little embarrassing to kind of create an empty repo and say you know I'm thinking of writing stuff in it I'd sooner bring something that was at least halfway there to show that we've actually got plans and intent and before we open it up to the you know everybody to try and make it better if we open it up to the world half finished really half finished at this point in time then I'm not sure that it will pick a direction and that would be a problem sorry I think there's another half to your question as well I forget second question was about potential amount of work involved in a particular is the end controller like open daylight as an example we've been looking at that back-end synchronization and then distribution question and we found a model that we think will let us work with the API's that exist on for instance or the API's as for instance open daylight publishes them today it would require a little bit of coding it wouldn't require a huge amount of coding to get something that's functional but maybe more moving parts than you might like at least you'd be able to work with it and in an ideal world we would change the northbound or replace the northbound in in open daylight to to communicate in a slightly different way but I think we can get to something working before we try and refine it and that's what I'd like to see here I'm trying not to make this thing perfect from the outset for the simple reason will take us forever I'd sooner get us to something that we can see how to improve okay are we done with questions everybody happy okay then I hope you will actually go out and give the code a look over give it a try or at least forward as with your opinions as you've done and obviously we're we're around to be chatted to us during the conference so please do come find us and thank you very much one last project the github location you mentioned yes sorry github.com slash I a wells slash glue on okay thanks and look at the wiki because everybody misses this but the wiki has a document that tells you how to deploy it