Tech Field Day: Network Engineer Roundtable on Deploying SD-WAN
Ten seasoned network engineers will debate on their views and experiences with SD-WAN. This roundtable discussion moderated by Tech Field Day focuses on how network professionals are analyzing and adopting SD-WAN technology, and integrating it into existing network architectures.
SD-WAN has been the most rapidly deployed SDN technology. But major concerns remain on which features are the most fundamental and differentiating, and the maturity of the technology for large scale deployments. The major discussion topics will include:
- Maturity of SD-WAN for prime-time deployment
- Relative importance of features like routing, security, segmentation, vCPE, multi-tenancy, Application steering, SaaS, and Cloud.
- ROI and the Before/After picture
- Most typical use-cases across industries
- Best practices in deploying SD-WAN based on personal experiences
Tom: Hello, and welcome to a special edition of the Gestalt IT Roundtable Discussion. We are here with a group of networking experts, and we are going to be talking about software defined wide area networking today. We’ve got a lot of great topics that we’re going to discuss. I hope you guys are really interested and are ready to ride along for the next 45 minutes with some great in-depth technical discussions.
My name is Tom Hollingsworth. I am an organizer on the Tech Field Day event series. I’m also a networking blogger. You can find my blog at networkingnerd.net. You can read some of my ideas on the Gestalt IT website at gestaltit.com. I’d like to take a moment to introduce our delegate panel.
Aaron: Yes. I’m Aaron Conaway. I’m aconaway on Twitter, and I blog at aconaway.com.
Jody: Hi. I’m Jody Lemoine. I’m ghostinthenet on Twitter, and I blog at ghostinthenet.info and a few other miscellaneous places.
Chris S: Chris [Seborowski]. I am a [unintelligible 00:00:59] aficionado. I can be found at my blog, [cseborowski.com] or [chrisseborowski] on Twitter.
Denise: Denise Donahue. You can find me on Twitter as ladynetworker, and I blog at my company’s website, netcrafstman.com.
Drew: Drew Conry Murray. I’m on Twitter at drew_cm, and I blog at packetpushers.net.
Eyvonne: Eyvonne Sharp. You can find me on Twitter @sharpnetwork, and I blog at esharp.net.
Chris M: I am Chris [Margette], both in real life and on Twitter; and I blog at fragmentationneeded.net.
Eric: I’m Eric Stover. I’m @eric_stover on Twitter, and I blog at [12 Fs dot WordPress dot com].
Kevin: I’m Kevin Meyers at StubArea51, and you can find me on Twitter @stubarea51.
Carl: Carl Fugate. I am carlfugate on Twitter, and I blog at sdpackets.net.
Jordan: I’m Jordan Marin. I’m bcjordo on Twitter, and I blog at jordanmartin.net.
Tom: All right. Thank you all for your time today.
Tom: All right. Thank you all for your time today. It’s greatly appreciated. I’d like to kick off this discussion about SD-WAN by talking about SD-WAN deployments. One of the things we’ve seen over the last couple of years is that the discussion about SD-WAN has really been theoretical. Is this a thing that can actually work? Should I take a chance on this? Now, in the last four or five months, what we’ve really heard is, I’ve done this, and it works, it’s a thing; or, I’m not really looking forward to doing this because of various reasons.
My question for the delegate panel is, has anyone had any experience deploying SD-WAN in real life?
Eyvonne: We’ve got a Viptela deployment. We started early 2016. I had some engineers from Viptela come in. It took us, really, a day to stand up the demo environment. We started with a few sites. We’ve now got 44 sites online with Viptela, and we’re really pleased with the solution and what it’s done for us.
Tom: Were there any hiccups along the way, any kind of issues that you had to work out compared to a traditional networking deployment?
Eyvonne: I would say, you always run into issues. If we’re talking about quantity, there were significantly fewer. We ran into a couple problems that had to go back to the development team, but the scale was days. We had those issues fixed in days, not weeks or months or maybe the next time we release a version of code, we might consider fixing your problem.
Tom: Do you feel that that scale was reduced because of the hardware and software combination they were using; or was it due to support being able to help you through those issues?
Eyvonne: I think it was more in their focus on – their customer focus. They’re just incredibly customer focused, and we had a great experience.
Tom: Anyone else had any experience deploying SD-WAN in the real world?
Carl: So we have a customer that – we have a very minimal deployment. It’s just two sites, and it was for helping out to resolve a specific problem where the endpoints are in Asia and they’re accessing resources back in the United States. So we were able to put in a kind of point solution between those sites in the data center to resolve some Citrix issues that they were having and take advantage of both MPLS and internet based circuits to be able to give them multi-pathing back to the data centers.
Tom: Interesting. For anyone around the table who hasn’t deployed SD-WAN, but has been thinking about it, are there any show stopping features that are preventing you from deploying SD-WAN right now?
Aaron: Other than management not understanding what it is?
Tom: So, why don’t you expand on that a little bit, Aaron, because I’m kind of interested in that. As networking folks, we understand the technology behind it; but of course when you start selling up into layer eight and layer nine, that becomes a much more difficult discussion. So why don’t you expand that a little bit?
Aaron: So, we have an enterprise. It’s fairly large, but we have MPLS most places. That’s fairly expensive, and we don’t really even use it. We just need some bandwidth between sites. So I’ve been trying to get some SD-WAN solutions in place for a while, but anyone that’s outside of our technical operations team doesn’t really understand the benefits, the abstraction, the layers on top – the overlay. Management is stuck in the traditional. I think we had the same experience in compute, the same experience storage, where, we’ve done it this way; why do we want to change now. So I’m really having a hard time emoting [sic] the benefits of cost savings and management savings of the WAN. It’s really the big blocker for me.
Tom: It sounds a lot like a chicken-and-egg problem. I can provide cost savings if I can get it installed; but in order to get it installed, I have to be able to provide cost savings first.
Tom: That’s actually a fairly common thing that I’ve heard quite a bit. In fact, at some of the trade shows that I went to this latter half of last year, a lot of the discussion stopped being about, is it technical enough to work; and it was, well, now I need to find the money to make this happen.
Aaron: Well, I also have an issue, too, with a business priority for this; limited resources on the team. There are only a few of us that can do that in the company, and I’m just one of maybe two that could do that. But I have other priorities. I’ve got migrations. I’ve got data center consolidations that are real, tangible money savers; tens and hundreds of thousands a month that I can save by closing multiple data centers. That’s obviously going to take priority with management over an SD-WAN solution.
Drew: Can I ask a question? So getting back to this cost issue, my assumption would be that if you can walk into management and say, I can save you X amount every month on our WAN bill, that would be an easy sell. Does it have to do with the fact the cost differential isn’t great enough for any potential perceived risks they see, and they can just kind of change?
Aaron: I really don’t think – it’s partially my fault that there are a lot of layers between me and the guy who makes the decision, right? I can get the number and say, I’m going to save you X amount a month; but that really doesn’t translate above him upward. Really, to your point there, it’s not a lot of savings; but it is savings, and it will save money over time. But when you compare my example of closing multiple data centers, that’s not going to be anything they want to do.
Denise: That’s what I see, too. Cost isn’t the only driving factor. Yes, it’s going to cost less; but then you have to balance that against learning a new technology, managing it, which solution do we choose – there are so many ways to go out there; all of them give you some level of vendor lock-in at this point – and then also security and performance. The MPLS cloud they know. They get guaranteed levels of performance. They know how secure it is. So management has to sit there and balance all those things.
Jordan: There definitely is more to the cost discussion than just, it costs less. So when you think about the cost discussion, this cost savings comes from moving from SLA based circuits to non-SLA based circuits. Not everyone is willing to pull that trigger. Not everyone is willing to give up the throat to choke, to say that you’re guaranteeing me this performance, and there’s a penalty if you don’t. So the cost saving is definitely there if you want to move from an SLA circuit to an Ethernet based circuit. But if the backing isn’t there from a management perspective to take that risk, even though the evidence is showing that non-SLA circuits are performing just as well as SLA backed circuits, it still is, somebody is going to end up owning that if and when it doesn’t work. So there’s a level of risk that comes with that cost savings as well.
Denise: Actually, you hit two things that play into it. One: Ethernet based; and not every connection, today, is still Ethernet based. But also, performance is shown today. I’ve heard people say, what about when everybody starts throwing their networks, their WANs, across the internet; where is performance going to go at that point.
Tom: Carl, did you have something you wanted to add here?
Carl: So, obviously we live in a world where cost, TCO, is an important thing. I think in SD-WAN we’re spending a lot of time right now trying to justify it based on the cost, cost savings. But I think in the future – and I think we’re just at the front of this – long-term I think SD-WAN as a cost savings from optimizing circuit prices is a red herring. I think what’s going to happen is, we have an arbitrage in bandwidth pricing today, and that’s going to level out in the future, just like we saw a shift in wireless data. It used to be you could have all you wanted for free. Now it’s the only thing you pay for. You can have your cell phone with minutes and text messages for free. So I think we’ll start to see that in the future.
I think, actually, now, if you get in on the ground floor, you’re actually getting the platform for free, and you get all the operational advantages and the business advantages. I think the business advantages, for me, is the bigger thing. So we’re talking about changing the WAN environment that we have from a network based approach to an application based approach. I think that’s really where SD-WAN shines. It’s no longer looking at, how do I afford packets; it’s, how do I look at my business applications, and how do I optimize them. That’s something that we have a real challenge doing in a routed network today, because we only have things like IP addresses and TCP ports to try to make forwarding decisions on.
So I think for me, that’s the real advantage of moving towards SD-WAN, and less so just that cost optimization.
Jordan: There are a couple good points in there. The first is that cost, as much as it may or may not end up being cost beneficial in the long run, I don’t think is a disadvantage; because there are so many additional features and awareness that happen in an SD-WAN network that we don’t get out of our traditional protocols. We can talk about that forever, but that’s a huge point of that argument.
The application awareness is actually one of the things I’m curious about as we move forward to an encrypted environment. There are some companies out there that are focusing heavily on this application awareness, even down into sub applications – not just Facebook but Facebook chat; not just YouTube but specific YouTube. When everything becomes encrypted, how do you do that? How reliable is that? I just don’t know.
Eyvonne: I can speak to some of that; but to first talk about the justification, a lot of that for us as network engineers is knowing your organization. We were fortunate to be in a place where we were already – we needed a hardware refresh, and we were looking at a new WAN RFP from a connectivity standpoint. So we’re already going to have people in the field. We’re already going to be replacing circuits. So it was good timing, and I think some of that – you just have to look for your opportunities and grab them when they come around, right? But when you talk about application awareness, from my experience, the solution is really smart in how it tunnels. Everything goes across a tunnel. So all of your connections from site to site are encrypted with IPsec, and I’ve done some interesting things with IPsec to make it function a little bit better. I can’t go too deeply on that technically. Then it does all the application awareness and routing before the traffic hits the tunnel. So it’s in a decrypted state when it does that. We all still know the challenges with internet, right, you’re not going to QOS the internet. You just can’t.
Jordan: What I mean by encrypted applications, right, is, just about everything is going over http or https now. We’re abandoning almost every other protocol in front of http and https; and we’re starting to abandon http even for things that don’t necessarily need to be secure, into an https environment. So with that level of encryption, before it ever hits the device, we have, from the source, a piece of traffic that’s going through the device. It has to determine what that application is, and all it’s going to have, unless it breaks the encryption – which none of us want it to do – the only thing it has is a destination IP address; and we’re back to routing the way we always have. We know this is YouTube; so okay, that’s great, but …
Eyvonne: There are a few more pieces of information you can get, though. You can get some certificate information and some certificate issuer information that’s part of that initial conversation before the traffic gets encrypted. So one of the things I would love to hear from an SD-WAN vendor is, what mechanisms do you have in place to look at that level of traffic and help us make shaping decisions; because I don’t think I know that answer.
Tom: I actually think that’s a very key point we’re talking about here. As we talk about the features of SD-WAN, when we originally saw the very original SDN demos, it was talking about trying to add intelligence to the network. We’re like, oh, I don’t know how this is going to work out, because my network doesn’t need to be intelligent; and if you want to watch a network engineer’s blood run cold, just walk up to them and say, PfR, and they will freak out, blood culture that is an intelligent system that nobody can understand. PfR/OER, whatever you want to call it, is what Jordan and Eyvonne have been talking about.
It’s the ability to selectively apply intelligence not just to a traffic load but across a group of non-SLA things. That feature set helps sell more than just cost savings. Yes, it’s going to be cheaper; but guess what: Now I can make sure that all the Facebook traffic goes over the cheapest link, and if it goes down, oh well; but one of the retail companies that I’ve talked to said, oh, all of our critical credit card traffic goes over this guaranteed link, and we can keep paying for it, because we know we’re getting use out of it.
That’s one of the things that people have been talking about for years, is that ability to not only say, here’s a feature that I’m going to use, the link sharing, but also collecting analytics on those links to say, hey, that link has an SLA on it, and it says it’s only going to be down six minutes out of the month; and it was down 10 minutes last month. You can go back, and you can tell the provider, hey, we need to renegotiate this SLA, or you need to give me a discount.
Do you guys feel that the ability to get analytics from those packets, links, things like that, would be a good way to justify SD-WAN deployments to the management layer that just doesn’t get it? Who wants to go first?
Jordan: I’ll go first. To me the killer feature of SD-WAN all has to do with the controller. So when I say that, it relates to the telemetry and the view of the network. Right now our routers have a very – they’re on an island. They have to make a decision with some information they’re collecting from other routers; but typically they’re making unilateral decisions about traffic paths. We, as network engineers, need to make the routers cooperate and make the same decisions, in failure events as well as normal traffic. That’s really what’s been complicate about WAN fail over – then we add something like PfR. We have policy based routing, and now we need to make sure that every router is making the same policy based decisions. It gets really, really complicated really, really fast.
So with the controller in place, we see both ends of the link. We aren’t making a decision about a flow path one my one, but rather as a holistic environment. That makes it easier. The other side of it is, we actually see real-time performance data from the traffic itself rather than an SLA type thing where we’re sending a probe packet. We actually see if we’re dropping traffic for that application across this link, because we know how many we sent from router A and how many router B received.
So if we have a small amount of loss from this link, we now know about it; even if it’s something like UDP, where we’re not seeing TCP session state. We’re no longer relying on the protocol that’s actually transferring it. We can actually see on the network and adjust accordingly.
Carl: And we can do something about it instantly, right? So I think, as we look at adding these aggregated interfaces, for example, I think – I’ve had some discussion with some of the other delegates about this. A lot of us have WAN sites that are in the middle of nowhere. This problem that we’re talking about isn’t a big metro problem. This is, really, a problem for last mile. This is really, I think, where SD-WAN shines – solving that last mile problem. As you can take and add things like wireless back up, LTE, into the mix, we really start to change how we can secure business traffic.
One of the problems that we have today is, in order to add something like wireless into the mix today, it becomes very expensive; because we can either fail over all of the traffic or none of the traffic, or we can try to do some of the traffic; but we really don’t have that granular control. When we fail over to it, it costs us a lot of money. So by being able to look at – if you go into an area that has a lot of broadband providers at $50 or $100 a month, you can afford to buy all of them and bring them in; and then you can determine who’s the best. Then I’ll just get rid of the ones that are underperforming. So I think that’s the value for your question of being able to actually look at all of the providers.
Drew: To play devil’s advocate a little bit, if you’re talking about a branch in a remote location, where maybe you only have one provider, how useful are those metrics that you’re getting if it’s just the one provider, and maybe you’re not even on an SLA link; it’s just best effort, and you’re going to say, hey, how come packets are dropping, and they’re like …
Kevin: Well, but again, you get into – you think even that single homed branch, if that’s going into a larger infrastructure, I think there’s at least a consideration there. I may want to steer that traffic towards this data center or this data center. So I think even in that scenario, there may be a use case there.
Eric: To go along with that, I think having the box at both ends handles TCP packet retransmission and out of order packets. So even if you do have just the one internet service provider, the TCP is not going all the way back to where the packet originated to be retransmitted. So it can be rebuilt at one of the boxes.
Denise: Okay. So, I hear what you guys are saying, but I don’t see why SD-WAN is critical to the benefits that you’re listing. What you’re listing basically has to do with a controller based WAN. Couldn’t that controller based WAN still be using MPLS, direct circuits, T circuits, or whatever, and sell backup without doing an SD WAN arrangement?
Eyvonne: This is where we get into the what-ifs SD-WAN conversation. So I think, for me anyway, the challenge with more traditional network implementations is that it’s just so operationally complex that we can’t make it happen. We just can’t make it happen. So the thing that SD-WAN gets you is, it pulls all those concepts together – policy based routing and intelligence in the network; PBR like functions; and it puts it into a congealed – which is not really a great word, but – solution that, from top to bottom, is made to work together. So at the enterprise level, we just can’t have a [unintelligible 00:22:16] expert and a PfR expert, and then when something breaks, which one is it and who do we walk to when traffic’s not going down the right link? How do we know why it’s not going down the right link, and who figures that out, and what part of the technology owns that problem?
I think that is the biggest challenge that we see with implementing it in a traditional network environment. It takes me two weeks to figure out why we’re dropping packets, and that’s with the high level vendor support engaged. You just can’t live that way.
Denise: That’s kind of my point. We’re assuming we’re defining SD-WAN as tunnels across the internet. But as long as you’ve got the software control of it, it could be any types of LAN.
Tom: Well, let me add a point there. This goes into the next conversation we’re going to have. One of the very first times that I ever saw anyone talk about SD-WAN, it wasn’t just that they were creating tunnels across the internet, because we can do that today. It’s secure, encrypted, certificate based IPsec VPNs that are centrally managed and capable of being torn down on a moment’s notice. Also, you can ship a box to a remote site with the tunnels preconfigured. So as soon as you tell the junior admin at your branch office in Laredo, Texas, plug the yellow cable into the yellow port, plug the orange cable into the orange port, and call me when you’re done. It all comes up without you having to chant the mystical IPsec incantation to the junior admin and hope he doesn’t fat finger something. So secure …
Eyvonne: A 16-character key with all these special characters. You say bang, and the guy’s typing out, B-A-N-G. You know what I’m saying? We’ve all had that conversation.
Kevin: But I think there’s an expansion to that definition, because you think, a lot of SD-WAN plays are this full mesh tunnel architecture. But I’ve seen other SD-WAN plays that are just, I want to mix as many heterogeneous links together as possible and then completely load balance; because if you’re a company where everything is in the cloud, then you don’t have these points that you have to hit. You just maybe have a bunch of remote locations, and all I need to be able to do is be able to use all the bandwidth that I have to get to my stuff in the cloud.
So there is definitely an expanding definition of what is SD-WAN, what are we talking about.
Tom: Hold that thought on cloud, because I actually do want to come back to that in just a minute. I want to talk a little bit about security, because this is one of the things that I keep hearing: Security is a huge deal about SD-WAN now, especially because you’re trying to traverse inherently insecure links. One of the biggest things that we hear about in networking today, especially when it comes to overlays, is micro segmentation. We’re going to microsegment the host to the host to the host to the switch to the host to the router. But what happens after it hits that first network termination point? It’s not micro segmented anymore, right, unless we encapsulate it in some kind of tunnel and hope that something else happens.
But a lot of the used cases that are evolving around that, especially in organizations that are very sensitive to that kind of nature, such as healthcare, retail PCI, government maybe – they’re not talking about that – but how important is security to your organization from that perspective, especially from an auditing perspective? One of the things about analytics is, if I’m collecting information about the link, when the auditors show up to ask, hey, can you prove to me that none of the patient data ever touched any of the guest wireless data, you can produce a report that says, nope, not a single packet. Do you think that’s something important as a selling point? Carl.
Carl: Yes, for sure it is; and I think one of the reasons that people – if you have a lot of branch locations, and you have these segmented zones at different locations, it’s really difficult to manage that. You end up going to your MPLS provider. You say, I need three different VPNs across this circuit. Then I’m going to hand those off to the different areas of the network at that site. Inevitably what happens is, then you want to, maybe, do some bandwidth limitation. Your guest wireless network: I only want to use so much of my MPLS pipe for that.
To manage all of that complexity is very, very difficult. It requires not only configuration on the CE side, it requires interaction with your vendor. Maybe it requires action at your data center location where you’re aggregating that back. By having this all inside of your SD-WAN controller, you can virtually spin these things up. You can dynamically allocate that bandwidth as you see fit. I think for me that’s just another advantage of that centralized management; taking all of the other players out of the equation – who do I need to interact with to make changes as my business changes.
Tom: Anyone else?
Eyvonne: We’re in healthcare. The segmentation thing is huge. For me – and you guys may see it differently, and you should know, but – the word micro segmentation for me is a data center word, not so much a WAN word; because you’ve still got layer two, right, and I’m not aware of any SD-WAN solution out there that segments all the way down to the layer two level right now. But the great thing that we see that we can do now is, you can create a new overlay that’s completely independent from every other segment on your Wan; and you can do it in minutes.
So you acquire a new company, and you want them to sort of kind of be on your WAN. You want to be able to get to them, but you want them in a segment where their stuff that has horrible antirust software and hasn’t been patched in 30 years isn’t going to infect everything else that you’ve got. So you drop an SD-WAN appliance out there; you build a new segment. They’re on their own segment. Any of their stuff that exists in your data center, you segment all the way down; and then any other facility that you’ve got, you drop in another SD-WAN appliance, and bam, they can talk to any network they want to. You can control that by policy, and you can do it in centralized way.
I don’t know of any other way to do that. We could stand up something like that in days, and I’m talking shipping the equipment and everything. With a traditional vendor, it would take months of planning, and hours and hours of time to implement that. So for us, that’s the big win.
One more thing about security: We are now – when we get questions from audit and compliance, it’s not just, is your traffic traversing a private MPLS network. It’s, is that traffic encrypted as it goes across the wire. What we’re seeing now from audit and compliance is, if you don’t own the glass, you’ve got to encrypt it. Even if you own the glass but you don’t own everywhere the glass goes through and touches, you’ve got to encrypt it. That’s not a straightforward thing to do with our networks the way that they have been. So that’s just another huge win for us.
Jody: So basically it used to be that MPLS was seen as a service. You’d have your QOS. You’d have your SLAs. You’d have all of that. Now MPLS is seen as a transport, and it’s seen as a transport that is in an expensive transport. You don’t necessarily need what you’re paying for. So now we’ve got the internet, which has always seemed unreliable; but as things go forward, it’s becoming more and more reliable as a critical service for a lot of content delivery. You’ve got MPLS on this side, so you’re going, why am I doing the expensive versus the cheap, and weighing that off.
But, the other question is, I’ve got my lock-in on the MPLS side. Do I want a vendor lock-in to replace my carrier lock-in? That’s giving people a few bits of cold feet.
Eyvonne: In my world, we’ve got vendor lock-in and carrier lock-in, today, already.
Carl: That’s a really good point, Jody. I think for now, and until we have an open standard for SD-WAN, I would rather trade vendor lock-in for carrier lock-in. If I’m just doing an overlay, I really don’t care who my underlying provider is. I can shop it to everyone. I don’t need any to any cloud based technology if I’ve taken several of those providers together and I’ve taken an internet transport and pulled that together and built an overlay across it. I’m no longer relying on an MPLS carrier’s fabric to do that for me. That saves money.
Jody: Yes, I agree 100 percent. But it’s the sell. I’ve got this lock-in. I’m buying this lock-in. It’s like, yes, but it’s still a good idea.
Eyvonne: Well, and there’s still a place for that. I don’t think we’re ever going to get rid of carrier business class connectivity. It may not use the MPLS technology, but there are always going to be implementations where we need high SLAs, and we need them on private circuits. That’s just fine. SD-WAN doesn’t mean that we completely just forklift MPLS, and we just don’t ever use it again. I think as the technology evolves, we’ll just see that maybe there’s not as much benefit for us there. But SD-WAN, in my mind, doesn’t mean we chuck MPLS.
Chris M: The lock-in you get when you adopt an SD-WAN solution seems like a pretty easy pill to swallow compared to the MPLS carrier lock-in. All of them advertise, look at our zero touch deployment; you’re up and running 50 sites in a day; whatever, this kind of stuff. So if you wanted to throw them away and get another one, eh.
Male Voice: It depends on the deployment and the technology you’re using, whether you’re using virtual endpoints, physical endpoints –
Male Voice: … compared to replacing your carrier? That’s –
Kevin: … thing, too. It really depends. In North America we have a certain makeup of carrier connectivity; but if you go to Africa or South America, everybody has all these different needs. You may only have internet. So being able to take in that entire mix of what carriers are provided to you in the region that you’re in, and then dole it out as you see fit, and be able to tie all that together, I think, is a really huge thing. Network mergers are the things that I’m really interested about with SD-WAN, because you think – you merge two networks. There’s a security aspect of it, where you’re dealing with, is this secure; and then there’s, what are my best paths.
So for me, one thing I’d like to see with SD-WAN is, how do you solve that problem.
Carl: I think one general final point I’d like to make about SD-WAN is, how easy the onramp is. Changing your MPLS carrier today, changing your WAN, is hard. It requires lots of moving parts, orders. Adding an SD-WAN is just adding a couple of devices. You can add one site to your network by deploying two physical or virtual devices and immediately take advantage of that site, having the features, the benefits, of SD-WAN. Then you can easily roll that out as circuit renewals come up, et cetera. It’s something you can start now with just one location and ease into. So I think that, for me, is another reason to overcome the objections of, why shouldn’t I do this.
Tom: A point I want to go back to is one Kevin brought up just a few minutes ago. It’s about cloud, because somebody wrote a report, I guess, a couple of weeks ago, that told me that the cloud is going to take over the entire world, and that I’d better get ready for Amazon to be my new lord and savior. I don’t know that I believe that, of course; but it’s a fact of life that a lot of software that we’re using is starting to go cloud based: Office 365, Adobe Creative Suite, outlook.com. A lot of things we take for granted as running on this device now no longer run on this device, realistically speaking.
But how does that affect SD-WAN? When we look at WAN sites in an organization where we have a bunch of branch offices that talk to one another, that’s one set of traffic. If I have a whole bunch of branches that need to talk to a headquarters, like in a retail organization, that’s something different. What happens when they all have to use the same online CRM application that’s hosted in AWS? Is that a challenge that can be solved by SD-WAN?
Drew: I think the SD-WAN providers would say yes, and it goes back to that issue of the last mile; because you can tunnel some traffic back to your headquarters, but you can also jump off on an internet connection to the nearest instance of that cloud service. They’ll do the encryption. They’ll do the authentication. They’ll say, yes, we can solve that problem for you. I don’t know how entirely accurate that is, but that’s the message coming from …
Jody: The other thing we have to look at is the assumption of metro centers. I get fun discussions with my customers because they talk cloud, and I go, you’ve got 200 people, and you have a six-megabit down and 600K up DSL connection that you’re sharing between them. Yes, cloud’s not going to work for you.
Denise: A solution I’ve seen customers go to, consider going to, involves having a central site like a co-lo data center – Equinix or some other big co-lo data service – that’s well connected to everything. Everybody, SD-WAN or whatever WAN you are is connected to there. Then you jump from there out to get to the cloud providers. So it’s okay if one side has a little DSL and another side with more people has the gig connection, whatever. It still gets you that good, robust connection to the cloud providers.
Drew: I think it was Equinix, recently, that announced a partnership with an SD-WAN company, in which the SD-WAN company is putting their boxes inside the Equinix facility. So you just put on on your branch; and then bang, you’re into Equinix. Then from Equinix you’re into AWS, Azure, or whatever.
Male Voice: That makes a lot of sense, right? You aggregate your connections; and then it’s as simple a cross connect that goes into the public cloud providers; be it a SaaS platform or applications that you’re developing that are running on Amazon or Azure.
Carl: That takes us back to the hub and spoke model, though; and I think in cloud, that’s really what we’re trying to move away from. We don’t want these centralized points of ingress into the network. We want to distribute it to where is the most efficient point in the network to do it. I think it’s a first step. I absolutely agree it’s the right way. I think what we’ll see, though, is, beyond that, there’s no reason that SD-WAN as a service doesn’t have an appliance in AWS, in Azure. So basically it’s just another endpoint on your WAN.
Jordan: That’s already happening, actually.
Carl: MPLS providers have it today.
Jordan: No, I see WAN, actually. SD-WAN – I’m not going to name companies, but there are companies who have virtual SD-WAN appliances that you can roll out in Amazon, who will make the Amazon VPC act just as another endpoint off of your network. So you can tunnel it however you want to accordingly. The really interesting use case for that, at least in my mind, is VPC to VPC. So right now that’s not the simplest of things to make happen, to talk between two different regions within Amazon. But with this particular appliance, it just becomes two tunnel endpoints off your SD-WAN. They just are branches: Amazon, AWS VPC1, VPC2. Talking between them gets treated and controlled the same way the rest of your WAN talks. I really think that’s probably where we land with cloud deployments. You have virtual appliances that handle the networking.
Eyvonne: We’re right in the middle of the Equinix data center connectivity conversation, or do we connect directly into the cloud. I think a lot of times we presume that everything in the cloud should be internet accessible, but when you start looking at building company applications, you may not want those available publicly. You may have certain other requirements. Maybe it’s HIPAA requirements. Maybe it’s PCI requirements. You want to use the same security policies for the rest of your WAN to access those applications. So you spin up a virtual SD-WAN appliance in your cloud of choice. You route your traffic through that, and it’s already on your WAN.
Maybe that’s step one to provisioning circuits. You could turn that up in a few days. Really the actual work would be hours. You turn up that virtual appliance, and you route the traffic that way. Just what Jordan was saying: It’s another node on your WAN. You don’t really have to think about it.
Chris S: It enables us to actually start using the cloud as the utility that it should be. If you’re removing the constraints to enable quick configuration and still provide all of the audit trails to actually get to the devices, now I can move an application regardless of what that application is; as long as it runs somewhere you can move it.
Jody: We have the cloud as generic compute and storage, and then we have the internet as generic transport now. Now it’s just a question of managing the whole thing under one nice umbrella.
Eyvonne: So much of that depends on your particular organization’s requirements. I’m in a world where those requirements are much tighter than a lot of other folks’. But from an audit, compliance, security standpoint, it’s huge for us.
Jordan: That’s a good point, too. When we talk about cloud, of course, there are tons of definitions. We all love to make fun of that, or give that a hard time. But when we talk about software as a service, Office 365, It means some businesses might make the decision, I don’t need to filter that traffic; I trust things that are going to these software as service applications. We can just local off – what Drew was saying earlier – straight out to branch; just go directly there. Maybe more questionable services we bring back and filter.
But I don’t think all environments are going to be able to do that. So if you have a centralized web filter that all web traffic has to go through, we’re still in the hub and spoke model. We don’t really see much advantage from a cloud deployment model. It’s still got to come back through some hub somewhere, unless you start adding cloud based web filtering services on top of it. There are all kinds of potential models. It’s going to depend a lot on the business and what the requirements are from visibility and the flexibility to offload or not.
Tom: So I think it sounds like, from the discussion that we’ve had today, we can all agree that SD-WAN is indeed a thing; it is indeed a thing that has value. Whether or not some people agree with that is up for discussion. But I think realistically, when we say we’ve discussed SD-WAN, we’ve talked about it, I think we’re right on the precipice of getting SD-WAN adoption to become a mainstream thing. Honestly it feels like there are a still a couple of little bits and pieces that are missing, that would make this a slam dunk in most people’s cases. That would be the kind of thing that we all saw when we looked at the iPhone for the first time and said, why didn’t somebody make this 10 years ago.
I’d like to go around the table, starting with Jordan. I’d like for you to tell me the one thing that you think SD-WAN needs to either provide or show to make it something that becomes an instant implementation decision. You only get one thing.
Jordan: I actually think the biggest thing about SD-WAN is the way it’s being sold, in my opinion. The first thing we talked about today was cost and how we’re going to save all this money. I don’t think organizations are going to abandon MPLS. I think we’re going to see a reduction in the use of MPLS. I think SD-WAN needs to focus on the features it adds: The telemetry components, being able to fix brownout conditions in ways that we can’t do now. Those are the real selling points. Our networks will run better on SD-WAN than they do with our traditional methodologies, and that’s the real feature. I don’t know that there’s any one thing I can think of that needs to be added today to make it more …
Tom: Carl, one thing.
Carl: I think for me it’s application identification. It’s making sure that you can prioritize the right applications for your business. As Jordan pointed out, I think it’s going to be a challenge in a world full of encryption. How do we do this? We used to have protocol numbers for every protocol. We don’t have that anymore. So finding a way to be able to look at and identify applications in SD-WAN is going to be important.
Tom: Kevin. One.
Kevin: I think for me it’s integration with traditional routing, because I think when you get to scale, and you get to really large organizations, you at some point are going to leave and SDN enabled network. So how do those things translate into a traditionally routed network, and how do you solve those problems with SD-WAN?
Eric: I think a lot of the SD-WAN vendors – a lot of the features are just table stakes at this point. Across the board they all have similar features. I think one thing to piggyback off of what Carl said is, application identification. In a world where almost nothing, probably in the next five years, is going to be http – we’re abandoning that as quickly as possible – I think it is application identification. I guess secondarily, probably the user interface and how easy the solution is to manage.
Chris M: The network I support is an obvious candidate for SD-WAN deployment, and that environment has discarded just about every offering for one of two reasons: Either the equipment doesn’t act like a router – a solution that acts like a bridge or something else is out; it’s got to speak [unintelligible 00:44:47] to integrate the rest of the environment – and we do a lot of multicast. [Unintelligible] multicast, traffic engineering, and replication control stuff has been lacking in the handful of vendors that support multicast. That’s what’s kept us away. As soon as that’s there, it’s an obvious choice.
Tom: That’s a whole other can of worms you’re talking about.
Chris M: It is a big can of worms.
Tome: Eyvonne, you’ve actually done a lot of SD-WAN deployment. So I think you’re well on the road to getting that adopted. I want you to tell me one thing you wish the SD-WAN did to make your life easier.
Eyvonne: I already thought of my answer.
Tom: Well, you can give me the other answer, then.
Eyvonne: I want to say, first, that I’ve made the iPhone analogy, too; because I really believe that SD-WAN is that kind of technology, where the difference is, with the iPhone, a guy stood on a stage and showed us something. We could all very clearly see that this was something very different than what we had ever experienced before. I think the hardest part with the SD-WAN adoption is finding a way to tell that story that makes people go, wow, because we’re all talking like BGP, and PfR, and using all these letters that most people don’t know.
Now, one of the things that I wish SD-WAN did that it doesn’t do today: I think the templating model is great, but there are always times when you need to do one-offs. How do you manage those templates, and how do you make that flexible enough so that it fits every single use case? I think that’s really a challenge. I think there are always improvements that can be made in user interface and visibility into the data that we have. A lot of times we’ve got analytics data, but it’s not presented in a format that helps us make the best decisions. So I think for me, mostly, it’s gooey.
Tom: Very good. Drew, what are your thoughts?
Drew: I would say visibility, building off what Carl said. You have that application annotation capability, but also performance: How is this link actually performing? Am I seeing packet drops, and so on? So you get that telemetry aspect of it or analytics aspect of it, and then when you bubble all that up through a centralized management console, it’s easy to see branch by branch by branch with that degree of visibility that it brings to the enterprise. I think that’s a compelling feature.
Tom: Good. Denise, what’s your one thing?
Denise: Everything that everybody else just said, and also one other thing that actually the SD-WAN people have no control over. The thing that really needs to change is the mindset and processes within the customers, within companies. You’ve got to – with anything SD, you’ve got to break down the silos. You’ve got to have cross-silo processes. That I see as one of the biggest impediments to its adoption.
Tom: Very good, and Chris.
Chris S: Yes, I 100 percent agree. Transformational technology: How do you sell it? How is it adopted? In this case, it sounds like there are a lot of constraints that are going to be removed. What is the beneficial impact to the business by removing those constraints? So that’s a key to the adoption.
Tom: Very good. Jody.
Jody: It’s got to be a drop-in replacement. It’s got to be one of those things where they’re supporting, basically, the full protocol. Anything IPA should be able to run. Anything V4 or V6, multicast, the whole shaboom; because I don’t want to be in that situation where we’re dropping in a technology to replace MPLS or a WAN or whatever, and oh, by the way, they didn’t think you’d need that right now, because they’re focusing on the 90 percent of what the customer wants. It’s not just SD-WAN that’s doing it. There are a few others that are doing it. But there seems to be a move toward, support what 80 percent of the people want; and if you’re not in that 80 percent, then we really don’t care. That attitude has to change, because if the internet being a generic transport is what’s driving SD-WAN, then SD-WAN similarly needs to be a generic transport.
Tom: Interesting. Aaron, what do you think?
Aaron: Well, you know, the guy who doesn’t have any experience with it – you’re going to make him go last. That’s fantastic.
Tom: Yes. You got material to draw on.
Aaron: True. Well, but see, Denise stole the line: everything everyone else said. I do like the telemetry. I think that’s going to be another argument that I’m going to make: check the health of everything. I think that’s going to be a big seller here. We’re really focusing on organizing our monitoring and being able to alert when things are going awry. This is going to fit right in with that as well.
Tom: Awesome. Yes, I think that in the long run, SD-WAN has a very long life ahead of it. I think it’s going to see a lot more wide adoption, now that people are starting to understand the real benefits; not just cost, but also feature sets and things like that. Because it’s a platform, not just a box, it’s something that can have intelligence and other feature sets added to it as we go along. Of course once you buy the box and you get all the extra features down the road, that just makes the decision that much more apparent to people. You get to stand up and say, see, I told you so – this is the thing we needed to do.
I appreciate the discussion. I appreciate all the thoughts that we had from our panel of delegates. You folks truly are the networking experts, and you’ve taught me a lot about SD-WAN, and I hope the people watching at home learned quite a bit about SD-WAN as well. We thank you for your time. We appreciate your attention, and we look forward to speaking to you again on other networking topics in the future. Thank you.