>> Okay, great. We are talking with you Mash Christian Swami who's principle Deblin in the actual networking group at Microsoft. He's working on a STN Gwen, such of things, and we are going to talk today with Mash about STN Gwen, so this is pretty cool. Thanks Mash. >> Thank you. Hey, how are you? >> Great. So so yeah, let's, let's talk a bit about [INAUDIBLE]. This is, this is definitely something that has come up, really, in the past year has become a, you know, a lot of things have started to happen just in the past year. I'm wondering sort of you know where this is all coming from all of a sudden. I mean, are there, are there problems that people are facing in in when setting that just current protocols are not well suited to solve that are, are forcing you and other to kind of look at STN for better solutions? >> So protocols is are is probably one dimension I think the bigger one is in terms of if you look at today's [UNKNOWN] networks as used within Cloud providers like Microsoft. They have you know, they have there are high operational costs to such to such, to such wide area networks. You know, if you have the historically it has been, you build these wide air networks using these extremely expensive devices that are with like a huge amount if control plates intelligence in it. A lot of distributive and logic and so on and so forth and then just ask the operational cost. Now and then afterwards when it comes to maintaining them troubleshooting incidents they take time and time results are what we call like, the cause of these kinds of things that take a long time to fix. Actually adds to the cost of the whole thing. So, and as we and we're looking at our trajectory you know, traffic keeps on growing. These networks become kind of, you know, we can do, we can do better than these networks and that's probably the reason that will make us look at different ways of building the run and STN is one you know is one way of tackling different problem. >> Yeah, you mentioned them like trouble shooting for example, and has certainly, you know, BGP in particular has a lot of, I would say, known problems with convergence, speed, stability, security, you know, the list goes on and on like I mean, in your experience thus far with STN and the WAN have you faced you know, do you face problems like this. I mean, you mentioned trouble shooting specifically but other kinds of things were I mean, do you think STN will provide a solution to having this things that, that people have been sort of complaining about with wide area network protocols for so long? >> Yeah. I think you know, in the case of we've had good experience of BGP, we use BGP extensively and the thing is this at its it, so you have, BGP is actually fine, and you actually need something like BGP when you're like, you know, you talk about this. You've got, you've got to use something to be able to exchange routes, and BGP works perfectly well for that. It's a matter of and you know there's a it's, you can easily, it's very, well understood how to design networks using BGP. The problem comes around comes around [UNKNOWN] when people start doing traffic engineering using NPLS. When traffic engineering is done using NPLS. That's where it becomes like, you know, the software becomes it now, it's only provided by a very small number of providers. That's when kin of specialization really increases and that's where you know when we do imperialist based traffic engineering, you have things the network works in ways that are hard for us, for us to control. Such as for example parts in the area you'll have, the traffic engineering being done with say local information and will show in the Swan paper, you know that you have global information you can do better. There's lack of application information that comes into traffic engineering. All of those kinds of things, it's that piece of the problem on the WAN that is DNS is good to solve. And the point is this, that you need, and I like BGP from the perspective if you want to bring up a network with absolutely no controller, you need a distributor protocol, you need a way for these things to copy, BGP's a perfectly fine thing to use. >> Yeah. That's very interesting because I, I think that like, I mean, I remember kind of like when SDN was, was sort of first catching on, or you know, when people first started talking about it in industry, and people were saying, like, I mean at least some people I remember talking to were saying like, MPLS auto bandwidth will basically, you know, that, that's going to solve all your problems. I don't need open flow or SDN and, and it seems to me like that, that maybe that, that the, I mean maybe auto bandwidth isn't necessarily quite as auto as, as one might hope, is that, is that kind of what you're saying? >> [SOUND] yeah. There are that is the the way auto bandwidth this used you know, it had [INAUDIBLE] I don't see an article [INAUDIBLE] and yeah, it has its it has its challenges and so on. So that is certainly a one aspect of it. Yes. All of the problems that come about with MPLST. But, it's possible, probably, to build these kinds of networks without it. Then afterwards, you gotta, without using auto bandwidth, too. Then afterwards, you gotta have the. It, it, it kind of, it tried. Auto bandwidth came along to sim, simplify the configuration. Is that when nobody can say what exactly are the bandwidth demand and no body knows how to size these N-P-L-S-L-S-P's so auto-bandwidth is a nice thing the vendor provide us say hey we will solve it for you because we know exactly what is the bandwidth coming in. We will use that in our traffic insuring database to figure out new patch and then after it's singled automatically and so on. What then causes this is it's now every MPLS device is doing this on its own. And it kind of you know its, there isn't any, it doesn't take on an application and put as a second part of it, so the first part is doing it on its own, so there isn't any global coordination and so, auto bandwidth can sometimes create may not find patch, may not you know it will find the choose a path is just not quite right. Then after the factor doesn't take application and put it to account, so what happens then is that you've got auto bandwidth doing something but then afterwards the application characteristics the bandwidth usage are slightly different and that causes the two to kind of be totally mismatched and that again costs profits so those, those are the few things. >> interesting. Yeah, so I mean, I guess going back to what you were saying before about BGP working just fine. I mean like, could you imagine this setting where like BGP is just like the the dissemination protocol for routes, but then you'd have like more intelligent control systems like actually, you know, applying logic that affects forwarding. >> Yes, that is right. >> Okay. >> Yeah. that's, that's pretty much it. And if you go to, actually, if you go to crack open an MPLS device, what you see in it is, a BGP component, which is exchanging IP forwarding and resolving routes over an IP, over a next stuff. And then, after that you're going to MPLS. And that's where, that is setting up these circuits or tunnels, and the two of them are unique. They're these two parts that are brought together inside of the device. All I'm saying is that we are fine on the IP side of it, but the BGP piece, it's this other stuff, which is over there, which is the MPLS piece that I think if you can think of it as take that off and basically have a SDN control plane that does the traffic engineering and tells the the switches what should be the TE fib that's a that would be a way of simplifying, solving the traffic engineering problem, but still retaining the nice properties of a like a you know, of off of a BGP based network or just an IP network which is, kind of which is, what you need even any of this if you want to bring up an SDN network you need to boot it up. To boot it up you need unit, there won't be any controller or anything like that. How do you boot up an SDN network? Use you can use BGP to boot it up. And then afterwards have the TA rules come in, and then after his traffic follows those parts, something catastrophic happens and you don't have a controller and all of those things and you need to do something, you can again go back to this one state. True, there'll be like congestion, and all of those kinds of things. But that would you know, there are. But that's okay. That's the nice- - >> [CROSSTALK] or something, yeah. [LAUGH]. >> That's a nice, that's a nice [LAUGH]. >> Yeah, exactly. >> So yeah. It's, it's interesting. I mean, trapping engineering something I actually worked on myself like inter domain TE in the context of BGP, quite a bit. And I think like we encountered a whole bunch of problems. I mean like. One is basically predictability, right? So like, it's sort of like you tweak a local preference and you can't, you gotta figure out, like that's going to effect that route over here and that's going to effect these other routes. So you run into like protocol simulation or at least immulation kind of issues. That's one thing, predictability. Another thing is sort of like the knobs that you have or sort of a prefix space and you sort of figure out well if I want to move this chunk of traffic or like, I need to figure out the right prefixes to do it, There, there are other problems maybe, you know, with stability, and so forth. The other it certainly comes up [unknown] setting is like if you do something with in effects what my neighbors choices are. And that could affect my traffic matrix so. Those kind of issues as well, I mean. I'm wondering like, you know, kind of in Europe, in your experience, like, where do you think, I mean, do you, do you see similar kinds of pain points and where do you see with with STN like which of these problems do you think it, it's like most well suited to solve? Like for example. You know, c, could, could it be the case that it just makes things more predictable? Or is it going to be, like, the granularity can operate on this better? Or it's easier to troubleshoot? Or what, what do you think it is? >> Yeah, no. There is a. When it comes to inter-domain yeah, that's whole different level of a problem. I, I don't think its DNS is mature enough to tackle inter-domain and you know via For example if you look at when you got. And MPLS initially and after that all the single domain where people would traffic engineering and then after so you got inter domain or inter As, okay based MPLS and then problems become kind of harder, right, and you're absolutely right that all of the different nobs that are there which I use today when it is when you do interfacing, route selection, and all of those kinds of things they are you know you have to. They make do with a lot of, it is, it tends to be a bit involved. One of the things is this is, it is if one simplifies the sort of [INAUDIBLE] I think one models for BGP and so we say these are the kinds of things that we're going to do and you can model the network and then afterwards restrict yourself to a few set of knobs that you play around with, you can kind of make the. Make the network easier to manage and maintain. And so, that is a different aspect of SDN. That aspect of SDN is kind of, more like, you can think of it as more like Configuration and policy and those kinds of things. As you, but I don't think it should be called SDN because that stuff is already there. In the sense of what we do is just that any large provider thinks of the network and models it in some fashion, and then afterwards, and that's where they you know, they get into all kinds of details to how they want the network. And then after they spit out various kinds of. Configurations. Then afterwards they get pushed onto these devices and you can call that as, also as DM, but it's really doing network management [UNKNOWN]. Now with that, what you could do is that. You can really code all of your route maps, or your route policy, and all of those things in this model, in this model, and then afterwards [UNKNOWN] out configuration which then gets pushed on devices. And when you can think in terms of the model, you can do simulations with the model probably, you can do prefix compaction. Anything you want to try, you can do it with that. Then you can kind of make, restrict yourself to a small sub set of the BGB features and kind of get a bit more method into this whole thing. When somebody just goes, directly goes and touches devices, directly goes and does things, their in for some trouble. And I don't believe people do that. Even before there was this word contest, he and Dave were already doing this well. So now I'm saying is he and his Memphis configuration I think is a bit overloading of stn. One could say, that's network management and with that one could get a bit more order when dealing with pgp. Within the domain or across domains. >> How do you sort of separate the notion of this sort of configuration or management as you're calling it, from these questions of like, traffic engineering and control, I mean it seems like you say on one hand you say SDN is quite useful for TE, and on the other hand, like, okay, well, we already knew how to do certain types of network to network manual tasks, so how do you kind of like... Partition or separate those, those two. How do we think about that? >> We think of them as a federation of controllers, you can think of a federation of entities that are, doing, various, global activities, now the kind of global activities which is involved in configuration generation, or network management, so to say, is one kind of a controller or a set of controller services. And they tend to operate at a slower scale in the sense that you need to do them only when you are bringing in new devices into the network. You are going to make a major change to the configuration and all of those things. You exercise that [UNKNOWN], of controller capabilities. Now, there is a different controller which would do, say monitoring of a whole network. And that handles all kinds of analytics [UNKNOWN] Network data collection, analytics, and all of those kind of things. Then after the, the third class of a controller, which is doing traffic engineering, and that really is taking various kinds of inputs about the network, doing an optimization of the how traffic should be placed on the network, and then afterwards programming off the te fib. On to the next one. It is, you know, what happens outside, I think there's this whole thing about trying to think about god controller, like one controller that does everything is, that's mistaken. I, doesn't exist, doesn't, it's not needed. because, naturally, if you were to see it too, these are all like, they're different, they're different classes of problems and it's better to build. What is called a controller, that framework is completely different for each one of these class of problems and best to take it separately, and so that's how we have it do, we have a federation of controllers. >> Do you, do you do you think that there are maybe, I mean one of the things that like the researchers have looked at certainly is how to like compose control programs? That's something also that students are looking at as well. >> Yep. >> And, do you think that when you have a federation like that, that you have to think about well, this controller's doing T-E, but this one's doing, you know, other kinds of management tasks, security, or [UNKNOWN] control like? Do we need to think about how those two things compose, or interact, like if you have these different controllers talking to the same set of switches like. Do you face you know potential conflicts or, or other things? Or how, how does that play out? >> Yeah, that does that can happen in the sense that you'd have [UNKNOWN] you know there's this work that we've been doing in this thing called called statesman. Where you have, you talk about this thing, you got like state that you want to put on to the network devices. And you have, think of it as, what is the current observed state on the network, and it offers you, what is a. People were to say [INAUDIBLE] there's a change that we would like to do and there's a proposed state and after those you can have these things that will check that yes, this is something that's valid and then afterwards take it from the proposed, to what is it, target states. You can do these kinds of, you can, you, you, so you can kind of bring it down to where there's going to be conflict in the things that are going to be done on the network, you can kind of use, [UNKNOWN] like statesmen, which, nothing but a state database, and that has got state. Which is what's [UNKNOWN] the network. What is, what we want to take it to and how do we get there? And build that. So it's possible to build it like that. We have, we have slowly started to use as, you know, this kind of thing for, within our data center, actually. And we are starting to explore it on for the wider network, too. That's interesting. So in other words you sort of, like, look at the state that's in the network. You try to basically detect things that are inconsistent or, or otherwise undesirable and then you kind of go back and like, cor, like correct them after the fact. To say? >> Yeah, I, that' s right. Now one thing is [INAUDIBLE] when it comes to the t, to traffic engineering, which is the one where I've been spending more of the time. There the only, the kind of state interactions with regards to hey, is the switch up or down and all of those kinds of things. Or is the switch going through some kind of configuration. You know, there are very few kind of interactions. The amount of stuff that see, a traffic engineer controller pushes is really a fib. And they are, that's, that is the order, of operations. Should a switch be, in the process of being programmed, re-programmed, and, or like something else, it will just show up as a topology change to the traffic engineering controller, and the traffic engineering controller will just address that. So. Sometimes, I think the TEP's controller tends to work at a level of, of fib, and these other kinds of events that are like, you know, that are like a switch level event or a maintenance event. They don't get modeled as oh, here's a link that I should not use when I'm trying to put. I should not put traffic on it. So, the interactions between these, they're kind of like the network management controller, and the traffic engineering controller. They really come down to basically topology events that are there. It's like, Hey. There's a topology event because somebody is going in and bringing down an interface to do maintenance on that interface. Or somebody is going to take the switch down because they want to replace that switch with something else. That just shows up as a topology change and then the traffic [UNKNOWN]. So yeah, I guess. I mean you talk a lot of traffic engineering, it seemed. Another thing I guess about in that area that works a little bit is. Sort of, you know, trying to automate certain, certain parts of this process. Right? Sort of, and I think, you know, certainly not new to that problem. That's like a twenty, or thirty year old problem. This probably will were. Traffic load balance, or traffic, traffic engineering. This has been like, I guess for a long time, thought to be unsolvable, right? I mean like, they often have had, had sort of motive where traff, traffic engineering are linked to an, you might say, you know, people try to solve this in variance, various settings. You know, it's I think there's been some warp, you know, that's done this with, with tunnels like tech CP, but by and large, like, there's been, like, like lots of stability questions. Do you think that like, do you think that I mean, how serious are these stability questions in practice and, and. And like do you see SDN playing a role in solving these problems. If they are even, you know, if these are even things to worry about? Do you think that [UNKNOWN] can provide some help? >> They are, so yeah. It's it's a case that traffic engineering software. That's the sophistication that goes, needs to go into traffic engineering software. To be aware of, say the, of, of various kinds of of various kinds of parameters be the load that was that is like, and I, and I, look at lord of varies, knowing certain char, characteristics about the application demands and being able to influence that. Now, there is a, now there, certainly with with SDN, you have the ability to take all of these inputs and do more, put more compute cycles into it and do more sophisticated computation of that the TE schedule should be. That is it, but I think there is a, how to make, these guys work at scale, and, you know, those are probably, I think they're still open problems. We have, if you notice, you know if you look at SDN for the ram, you've kind of taken on simpler networks. To use, to do SDN for the RAM. A simpler network, by that, I mean, like inter data [UNKNOWN] network. That's a simpler network. Using it. >> Get a sense that like the traffic loads are moe predictable or the topology is, is, is more regular or all of the above. >> All of the above. It's a, it's, it's, it's a it's, you've got traffic is Not unruly. You got like, it's not like the wild, wild internet. And you got a scale in terms of the number of prefixes you're dealing with. A scale in terms of the number of panels you're dealing with. And yeah you have, one of the things we've talked about in the swan paper is that a lot of traffic engineering is you can. How you can get great benefits of traffic entering is twofold. One is global knowledge and the second one is being able to influence the applications spurring traffic on it in some way, by bandwidth control so that they don't stomp on each other and that has also shown us to be able to run the network hotter. And basically to get higher utilization. So, in an inner data center network, you know, those are things that are easier to, they are like you're able to be, we know how to control those kinds of things. When it comes to a network which is going towards more on the peering side, you got a, the scale completely goes up, you got and that's fair, I think there are, so, that's, that's that's why I call it a more complex network. A SDN for that. I think of and that's where I think one should try and solve that problem too. In that SDN folder. Internet facing lan, or the peering side, or the peering rule as opposed to an inter data center rule. It's >> It seems like there are a bunch of challenges and opportunities there, I mean, like, you mentioned a couple, like, scale being, being one of them. I guess the unruliness of traffic being another. Do you think there are other challenges, you know, as, you know, we were to moo, if we were to move SEN towards the interdomain, or peering kind of settings, like, what other challenges come up then? The other one is bandwidth control. How do you like, how do you recognize, what are the different applications and what are the bandwidth needs? And then afterwards is there and then afterwards is it possible to not just like add a, and a, and being able to kind of control their bandwidth in some fashion. And I think when [UNKNOWN] application basis And said, you can't do that. [UNKNOWN] side, you're not looking at applications. The bandwidth control probably becomes a, is another problem, beyond the two points which are the scale and so on. And I think one of the things [UNKNOWN] you try and build these kinds of devices when the switches that you're trying to, they're like. There's also the kind of, The capabilities of those switches at the data play level to scale to what is needed on the internet facing rule. Then after you got the other part, it, it again becomes how do you get software that is going to scale, to internet facing side, And that's the [INAUDIBLE] you go to control plane software, you go to data plane itself needs to be able to do it, and then [INAUDIBLE] traffic engineering, it is these aspects of the bandwidth control. >> Yeah, yeah, absolutely it's, and, and I guess like, I mean the challenges are certainly significant, what about opportunities? I mean it's. You mentioned a little bit like, I mean we've talked about peering and things like that, but what do you think are the like, the biggest opportunities as you move like SDM to an, to an interdomain or peerings type of setting. I mean, do you see potential for new business relationships? I mean, it's you know, there could be peering of certain kinds. There could be more, you know more dynamic things, more direct. There could even be remote control types of things. I mean, what do you see as like the, you know, if there is a driving, application, or, a driving factor in a, in a STN in an inner domain setting what do you think it would be? >> It could be, I think it could be, the opportunities are also good care to fly know with this three challenges that you mention. But I think it would be, what could be taken in the opportunities on the TE side, is how to build a very scalable TE server. When it is dealing with really large networks. And the second one would be around the bandwidth control. How do you do, how do you, rather when I say bandwidth control, how do you deal with the application to network interplay, that is, you kind of take it as something you're given in a data center band? But that's not a given in this one. So knowing about, being able to, so that goes to a bit about how one can, opportunities are in the area of how one can take of areas. You know, like, like IP fix and net flow and [UNKNOWN] and all of those kind of ways of getting information about the flows and then afterwards, extracting that to say okay this is what [UNKNOWN] applications and then afterwards being able to do something in terms of relaying some information back to the, to the other domain. But hey, this is what can you hold back on this. Establishing of contracts between, application contracts between the network provider and the application user for bandwidth could be an opportunity so that, you know, that can. You've got to kind of simplify the problem a bit. You know, you can't, like say hey I'm not going to, I'm going to be exactly how I was before and still expect [UNKNOWN] to do magic. It won't be the case. One has to kind of create some kind of these bandwidth contracts may be in it. Do that. The afterwards, if somebody's more like a, a hardware person, then really thinking about switches which can do, can scale, I would tell you like to say. White box switches can really scare to internet kind of loads. That will be a good one. Certainly around like table sizes that supporting the standard encapsulations that they need for the van. The control name probably is there, Or probably not, I'm not sure, but it's really around, that's probably an engineering exercise. >> That's very interesting, I mean, supposing we had this I mean, it's really interesting what you had to say about the sort of application interplay contracts with the, with, with the network. Supposing we had that, like, what do you, what do you think would be possible? I mean, are we moving toward like inserve kind of stuff. I mean, you know, end to end QoS for certain kinds of applications. Do you think there are other kinds of things that, that, that may become possible? >> I, I think what'll happen is that we'll be able to, beyond the app, the applications are going to be the way they are going to be. It's just that when it's able to build, the infrastructure with lesser, is able to run the infrastructure more efficiently. and, and, it's, you could probably do a few of these kinds of interesting applications more on the back end side of probably, for example. If you had, now, so one is just decreasing of the costs of the applications stay core. If they're going to be new applications, you know, I'm not too sure what are the applications one could think of. But I'll let the application guys, do, probably they could just be able to do a few things. Right now applications are return by just purely running on a, in a single region right? If you had kind of contracts and you could kind of do various you could probably run inter region applications more easily. You can think of it as say I've got a private I want to build a hybrid cloud and I want to have some stuff running in an enterprise data center some stuff in the cloud data center. and, then afterwards, if there was some kind of contracts on the whole thing, then it may be possible for, these applications to most seamlessly extend into the cloud, and then after be served from either place, because there are some kind of guarantees that you, you're able to get from the network, and so on. So, this is where it really depends on the class of application, because you can't do that with interactive but you could do that with like the other kinds of application. So it, goes on like that. >> That seems very interesting. I mean, the, the sort of, coupling of, of private cloud with, with, with, public cloud settings also seems to bring up. Not only you know performance questions, but also security questions, like, how do I make sure the data that, you know, is on my private cloud, that shouldn't ever go to the public cloud, you know, not go there? I mean, you think that there are, you know security questions like that, with, with the, with the WAN in general? And, what do you think one of the big security questions and do you think SDN has anything to say about you know security in [UNKNOWN]? >> You know, the security is applies even before there was [UNKNOWN]. I'm not a, I'm not a security expert but I would say that I think. yeah, this is where, you know, we can't have, the security is a problem that needs to be solved either way, wheter it's, it's a ban that is based on SDN or a ban that's not based on SDN, and you do have these security questions that do show up when it is using [UNKNOWN]. >> Somebody's using the cloud, versus the internal stuff. But I would say, I think when you break it down you know, you have these problems stay the same. they're, they're already there, and probably, and I'm not sure what, how SDN would help, and how it should group, because I'm not spent much time thinking about it. >> You have certainly I mean I guess other things you've thought about though like you know, not more specifically to security but I guess you had other experiences even before you came to Microsoft SDN and IP and I'm wondering if, if you're I'm, I'm just wondering how some of that work that you, that you did in the past, like in lab, for example on SDN and IP, how did that kind of shape your thinking about just SDN and the WAN. >> Yeah. >> I don't know what is still going on. But certainly there are other people trying to, ourselves included, trying to couple you know, IT routers with SDN controllers. Curious like how that shaped your thinking. >> Yeah, at first, it was, I think the lab doing some really great work, in fact they've, since I, they've, of, I was there, doing, doing work, working on a couple of projects. One was the, the one that you mentioned which was basically have an SDN, a software defined network. inter, interconnect. Basically can have SDN Ions over an IP network. So, basically have use BGP protocol that and SDN software define that protocol on the IP network. And, and that really makes, kind of create, because release was not there like you have thesis the Island and all of this thesis for campuses and you could of can [INAUDIBLE] there's probably an L2 circuit and that's about it. But now with this you can kind of have it and you can peer at L3. And I believe now that is being folded in as an application on top of this other one which is controller work which I did [INAUDIBLE] and that's really being it's still on. It's ongoing work at Owen Labs, just on, or open network operating system. And that, that's really meant to be a distributed controller as opposed to a controller that runs on a single server. And but, it's meant to be a distributed controller that can actually be either geographically distributed, either distributed within a data center or distributed across data centers, and so we were really building distributed frameworks for that and we had it as SDN and IP app as an application that would run on top of that. So, both those are pieces that I think. How they influenced, is, I think, in terms of, got to, really step back from, you know, because I, I came from Juniper. So it was, like, a step away from, like, doing things on a device, to doing things, externally and to start playing with these things. A few things that shaped my, thinking were really around, What were the capabilities of open flow? What were the limitations of open flow? What would be the way and I can, nobody try and build that controller I think they would what its, they build a controller that can do any application or make it more targeted to an application, and as you can see what I've been telling you, you if you have what I said earlier, been kind of those are my, I got, to play around with these things and they influenced what they're doing now. I think at Microsoft the point is, has been eye-opening in the sense that you're operating at a scale which is tremendous. This is actually like, you know, when you're in, I think when somebody is, when you're in a place like this, you're going to see, we're actually a DevOps Organization. So we do development and we do operations, and combine teams and do this. So, a lot of understanding of what works, what doesn't work. What is important, what is not. All of those things kind of shape, the thinking and so it's still a evolution. It's still a, still a learning process. >> That's very interesting actually, you, you mentioned, you touched on one thing, that shaped your thinking which is sort of the importance of IP or layer three pairing between this SDN Ions as oppose to just serve out to circuits. and, I'm curios what our talks are on that, because, that seems to be a very hot topic of debate in, at least in the academic research community right now is like, how do we pair these SDN Ions, L2, L3s discussions are sort of right at the forefront, so. What's your thought, I mean like, when you were doing these L3 pairings, like what kind of you know, what kind of value did that bring to the table? >> You know actually I'm surprised that that kind of discussion is going on in an academic world because I think decided long time ago that layer two just doesn't scale. You know you're got and for example, within our data center in every, we don't we limit our user fail too because, you know, you got spanning L3 protocol issues, spanning L3 scroll that can all happen. So that's a but the thing is this it's really easy to bring up an L2 network. You don't have to, you don't have to do a whole lot and you can bring a network up. >> Yeah. >> When you have to bring up an L3 network, it is hard. Like, you know, you gotta have the software that will do it. You gotta have the other things that will, you gotta have people to, you need to help protocol support. That is why, the very first, you know, sample programs somebody writes on a controller, is an L2 switch. But I think if you know, you're past those times when, you know, you can, they are for, like when you try to build large networks, one has to be having a basic set of [INAUDIBLE] So, this thing about, and it is possible to build that on top of the control pro, protocol suite where we have an, and you know you can use, our open source work like [INAUDIBLE] and all of those things that have got like region, they have been rejuvenated with more interest and more development as things that can run on top of a, on top of an SDN control plane. And the SDN I've, that, I've talked about earlier, really was using, a version of Kwaga, not because we were partnering with a, with the same folks who were, with a different company who gave us, The piece, but of course the, so in having all of those things come on often is the control plane. It kind of makes, let's us create an L3 networks that are under SDN control talking to others L3 networks which is the int how the internet works. >> Absolutely, so, why not. Basically right. I mean, if you have the ability to do the IP. Yeah, the IP pairing with an SDN controller, as you do now, you know, only helps you, right? >> Yup. Exactly. >> Yeah. One other thing I wanted to touch on that you talked about was like, you talked about sort of the challenges of possibly scaling a white box switch? And that's something that certainly is coming, like you know, like getting a lot more attention in the past year or so as well and, What do you see as you know? What do you see as the opportunities there? because, I mean, certainly, I think, some of the things we're looking at, as we sort of like, put switches into exchange points. So, you're starting with, like, open flow style form ware. But it sounds to me like you think, you know? Maybe that's not what we should be doing. Maybe we should, take a white box switch, and put it there. And, and, and, but, what do you, what's your opinion on that? I mean, >> [CROSSTALK] So here's the thing what's happened with the, so, these, the original open plus switchers were built using, you know, in a broad concepts where like in any one of these kinds of ops in like chipsets, Broadcom, Intel, all of them where. And you have because open flow was such a flexible had a set of flexible flow specification, the only wavers mapped on could be mapped onto the chips was to use the resources and the chips that, that do ECL's or access control lists. That is a very powerful engine and it should but that's got very limited amount of space. Most the chip is devoted to doing L2 these are the chips, are you know they tend to be used on the data centers, so they got like exact match tables. They also have longest prefix match tables. Those are much larger but open flow would not be using them because open flor rules were supposed to be so flexible. So I think the thing is it's just so, when we try and use these so. So you try and use these devices so that is one aspect of it. Trying to use the ramp direct using of just open flow will not quite cut it because you've got to be able to kind of restrict what it is and then afterwards implement the agent on the switch that really implements what is called like that will program those resources. So, one of that we've done is this thing called to find a switch API. That is most suited for programming fibs that are for, that have the ram kind of skill and they map directly to the LPM and exact tables and, exact match tables. Now a wide box which can do this the thing is this said the agent that needs to implement now needs to take a switch API that I just talked about and compile it into those kinds of things. The other aspect of it is that. Is, is, delay-banded buffers. These chips have got packet buffers that are inside the chip so when they're inside the chip they're much smaller and when you're trying to be used and so which is perfectly fine for a in data center application when one goes to a wider network application the delays are much larger, right? They're all the order of I want to say, 50 milliseconds across the country. You gotta have, you gotta be able to support a certain amount of bandwidth. You need to have a larger delay bandwidth buffers. That means, that one tries to build a wide box switch, one has to have a chip that has got larger delay bandwidth buffers. Either that or one must be focused on applications where you know there's been all of the up in seller work that was done about how you do TCP bandwidth study scaling, That, one can, one could kind of do, make use of the application and the count of the number of TCP connections and all of those things and trying to make do with small delay of bandwidth. So when it comes to using a white box switch. One aspect of it is agent work that needs to change a bit so that one uses more, the chip more efficiently and the other one would be in figuring out for a wider network the right kind of switching chip would be [INAUDIBLE] giving investigation an opportunity. >> ver, very interesting. I guess along these lines too, like what, I mean, are, have you taken much interest or, or paid much attention to the, to the sort of custom chip sets that are, open flow specific, or SDN specific chip sets that are being sort of tossed about? Like the RMT stuff or protocol oblivious forwarding. These are some things that, students are working on as well. But, certainly it seems like, you know, that gives you a place to start. I don't know it's, you know, what's your opinion on that versus sort of like a, you know, a white box switch type of model? >> Yeah, those look interesting, and they're certainly worth, looking at. Given that, you know, the, you know, for I know that there are also like startups that are building new switches, chipsets that are more tuned for new open flow ends. I think it is a Yes, so those do look very interesting. Maybe sometimes we have to think about now you know, you start with a chip then often times you put in a, you know, in a system and then afterwards you have the software on the system that needs to be of some stability for us to be able to then afterwards use it in our network. So given that I certainly believe, like, maybe right now looking at certain kinds of things that are out there today, but it is certainly I would love to, look further into the things that you have mentioned. >> Very cool. >> I guess just one, one, one final question, I mean, just kind of going back to the WAN stuff. All right. I guess some of this, some of the things we've encountered in, in, some of our SDN exchange work, were, you know, we'll say, hey, you can do this, you can do application specific pairing, or you can do time of day pairing or you could do, you know, inbound TE based on, you know, based on flow space, and you know, sometimes we get we get these retorts like, oh, yeah, but you can do that with BGP, you know? You can use communities or you can use you know, BGP flows back or, or, or, you know, pick your you know, pick your protocol tweak of the day. Do you, do you face that kind of tension? I mean like, do you see there are things where it's like, well actually we could just do this with BGP? Or are there things, that actually no you can't do it with BGP. And, or, or, they are so hard to do with BGP that you do, you do need some kind of the flexibility SDN gives you, or is there's a case that, everything's pretty fine! >> No, it's obvious there, that you know, there'll be things that can't be done with BGP. And yeah, BGPs got like a really rich set of capabilities. And the things that you mentioned, absolutely [LAUGH] I can, I've gone through those, I've heard very similar conversations. But yes, it can be done with this. But I believe do you know, when it come to the, when it It is not that it cannot be done with word BGP. It really comes down to which one is easier to to build on. It's easier to build a service that is easy to operate, easy to configure, easy to troubleshoot easy to monitor and has got like an ends that next set of capabilities that need to be added. How easy is it to add them on? To a, a, a implementation that uses BGP alone or an implementation that is done differently, say using SDN with some other kinds of things. You will find that, when, one looks at it that way, internally at least, you're able to rationalize yes we would use, Let's do this with BGP or let's do that with something else. When, and, and in Microsoft they're not like, they're really about like, trying to be able to build a service that is that has got a certain level of isolate, that has got a certain, be able to scale it up with a small number of people and when you have a service mind set, What happens then is the person who is developing the service is also the person who's offering the service. So then, they are not like, it's not like a group which is developing software that is giving it up to somebody else who is supposed to operate it. It is one in the same group. So, it gives freedom to the person who is offering the service to implement it the way they think is right because at the end of it. The other ones are going to be handling customer calls. So if that person were to say hey, you know what? I can do it with BGP. Well, go ahead. If they say hey, I'm going to do this with this kind of a new software that I would like to write. Feel free to do that. So it's the >> Yeah, that's, that's a good situation to be in. >> Yes. >> That's a very good situation to be in. Oh this is very enlightening, thanks for your time. And I'm sure we'll have lots of more to talk about with SDN and the WAN in the future as well. It's a very exciting. >> That's okay, like wise, I'd like to help. >> Thanks.
