Transcript from TELoIP presentation at the Networking Field Day 15 event in Silicon Valley on April 6, 2016.
Pat: Before we go on that journey, you know, this is our Rosetta Stone. I’m not going to do it, but if I ask three of you, “What is SDN?” you’re all going to have a different answer. If you ask three of our competitors, they’re going to have a different answer. I’m not here to socialize what SDN is. I’m here to socialize what TELoIP’s technology is and how it works. But without this Rosetta Stone, we couldn’t get there ourselves. Okay, we all know the IP networking column, and the layers. This is my attempt to separating the SDN parts. I believe control and data planes should be separate, completely. A VPN from one end to another does not, in my opinion, separate those two.
So, the next column is SD-Internet. For both our SD-Internet and our SD-WAN products, VINO Internet, Virtual Intelligent Network Overlays, orchestration happens in the management plane. Single Pane of Glass, you are now controlling everything, from controllers, web servers, to your CPE devices at the Edge, at the customer branch. The forwarding plane happens between points of entry, or PoPs. But listen, we’re heavily inspired by MPLS.
I have a little story for you guys. So, we’re a tech company, we make software. That’s what we do. That’s why we bring on partners, because, you know, we might not be the best… Well, until Kevin showed up, we didn’t have that much marketing at all. Now you might know who TELoIP is in a Google search.
So, looking at MPLS and looking to displace MPLS, one really has to learn to appreciate what MPLS actually does have, and you gotta respect it. And I totally respect MPLS. I just think there’s a better way to MPLS out there. So we actually received a patent about two years ago for something called MPLS Edge. And what that is, when I talk about our ANA technology and our failover technology and our Intelligent Packet Distribution Engine, we were gonna package all of that up to extend MPLS and deliver real labels to the branch. Why didn’t we do that?
Well, I’ll tell you, we borrowed from some of that in our architecture. But we didn’t do it because this tsunami of an SD-WAN market showed up. There was no need.
Phil: Can I interrupt?
Phil: So you’re saying that you were around developing this before the SD-WAN market blew up?
Phil: Okay. And that’s something that I think some of us were thinking, because we haven’t heard of you guys. We’re familiar with SD-WAN. So we’re like, “Okay, is this a company that’s jumping on the bandwagon?” And you’re saying it’s not at all the case.
Pat: No. No, I was gonna deliver a label right to the branch. That was the vision. And then it was, “Wait a minute. We don’t have to do that.” There was something else that changed the course. We just had to… It’s not a big ship but it’s not that easy to switch gears once you’re in this deep.
Justin: One of the things that people said about managed SD-WAN providers, is sometimes they’re rather abusive or they’re not very nice to their customers and people feel like they have lock in. So a lot of people say, “You know, I can go out and buy iWAN from Cisco or whatever SD-WAN product, CloudBridge, and I can manage it myself now and I’m not beholden to a managed solution.” So how do you guys combat that kind of a mindset where some of the managed guys are getting a bad rap?
Pat: Well, I think we’re partner-centric. It’s all about adapting to their needs. And we have different partners with different needs, right? Us adapting to SD-WAN was us adapting to their needs as well, just to sort of get back on that track. Not to not answer your question. Our service is flexible. You’re not locked into a contract and all of that. And I’m speaking to you as a partner if you’re consuming our service, because we don’t sell to that end-user, okay? Now, there are some partners who will take that service, which they can get out of in one month if they didn’t… You didn’t like me yesterday, you change me tomorrow. We give them that flexibility.
Justin: When you say partners, you mean like VARs, just to be clear?
Pat: Yeah, Tier 2 ISPs, managed service providers, CSPs, that’s who sells this product. Hosted voice providers as well. Because they’ll package it up and I’m giving them an unbreakable voice tether on public cloud. They take that and they package it up. So they might lock you in for a year or whatever, but they might have to because, you see, that’s a triple play for them. They’re not just giving you an Internet… an SD-WAN as a service or SD-Internet as a service. But us, we are flexible. I hope that answers your question.
Okay, let me get back to this, you know, turning of the ship. There was one more thing – and I love these debates – the larger the carrier, the more interesting their need for layer 3. And it just hit me one day. I’m not gonna tell you which carrier I was talking to, but I said, “Okay. I get it’s important, but I happen to think we live in a layer 3 world.” So I just asked, I said, “Out of all these MPLS solutions that you’re putting out there, this layer 2 that I’ve got to jump through that layer 2 hoop now. What percentage of them at a branch have to actually cross a gateway to get to something, even one of their own, at another branch?” The answer was 90. Layer 2 wasn’t that important anymore.
So SD-WAN allowed us to focus on a Layer 3-based solution. It allowed us to take advantage of the actual market needs that… And again, we did this with feedback from our partners as well, and build their solution.
Back to architecture. So here you can see, in the control plane that’s between our points of entry, I’m going to talk about our control plane, how we chose VXLAN, how we modified the VXLAN source code to allow us to do point to multi-point over Unicast, which is the Internet. Because if I could do it over multicast, to me that meant I need MPLS again. Wait a minute, how am I going to get somebody to a broadband per megabyte price point, end-to-end, if that’s a dependency? That didn’t work for our model at least, not us. So that’s our control plane. You have full mesh, etc. I’ll talk about it.
Then there’s the Data Plane. So for us, the Data Plane is the device at the point of entry, between that device and the branch. What happens between there? I’m going to reference this a lot, often, as the battleground, because that’s where things go wrong. They don’t go wrong on multiple ten gig uplinks between points of entry. They go wrong there. That’s where a customer may or may not be able to service as MPLS because of either price or distance, or other. That’s where it goes wrong. And that’s where we started life. We perfected that. Eighteen patents. And I’ll talk about that today. So that’s the Data Plane.
Underneath all of that, okay, yeah, we’ve got IPSec encryption, but it could just easily be as any other type of encryption. We chose IPSec so that…because it was familiar with everybody else. There are other encryption protocols and methods that one could run just as secure or more secure. We do it in a different way. We do it how carriers IPSec between each other. Considering that we’re an overlay technology, so how would one encrypt underlays? We do it in transport mode for our underlay protocol. It’s our own protocol. And beyond that, you start to get into, “Well, how does the backbone happen between PoPs and…” etc., etc., and that’s what these other rows cover. Next slide, please.
Okay. I’m hoping this is our money slide. I’m going to talk…leave this slide here, answer any questions I can about how you build our solution. I want to build one here with you. The slides that follow start to teach every point of it. So let’s build it. We start at the bottom. You’ve got to connect to your nearest point of entry. Would you believe that if I told you we had a patent on that part as well, the fact that you’ve got to connect to the nearest point of entry? It’s called Proximal Aggregation.
During our travels here and our history, we discovered that the art of aggregation at a distance, presents a problem not that dissimilar to the fact that speed is a factor of both bandwidth and time. Time’s not on your side. If you’ve got a site in New York and a site in LA, and you’re trying to aggregate between them, there’s a crossover point where things start to go wrong. Well, we knew that. That’s why we have multiple points of entry. Not everybody can build that overnight, but anybody can use it overnight as a partner. So you connect to your nearest point of entry, whatever’s there. They can bring their own broadband, it could be existing connections, new broadband connections, 4G, LTE, you name it.
Once it’s connected and authenticated, if it’s an SD-WAN service, it’s encrypted. If they subscribe to an SD-Internet license, it’s not. But even if they subscribe to an SD-WAN license or they’re 70% public cloud pull, they hang a left right there. I’m not tromboning anywhere, I don’t have to go to another SD-WAN site in order for this to happen. Why is that important? I’ll tell you why it’s important. That was a great question earlier, and I’m going to go back to that question about being locked in. Okay, so I got an SD-WAN and I’m reaping the benefits of my SD-WAN. I have multiple connections. I can failover. I can do all that stuff. But, man, did my host of voice provider really do a terrible job the last couple of months. I don’t like them. I’m going to switch tomorrow.
With this, you can. You literally just point to your new hosted voice provider and you’re there. And you take comfort that that voice call is not going to drop on the transition between the red and the green. Or, am I going to lose a word. And we’re going to show that today, if everything works out here, as this remote demo. And I certainly wouldn’t take Office 365 and drop it into the middle of an MPLS private cloud. I don’t have that worry here. We don’t believe in breaking out at the actual branch itself as the solution because now you have other points of security to deal with. But you don’t have bi-directional control. This gives us bi-directional control, so we break out at the point of entry.
Once I’m connected and authenticated as a branch, I’m fully meshed. Everybody can see everybody. We can now start to take away from that. I have a customer protected route domain as a corporation. And I can policy base route to manage that, I can eBGP or OSPF, or others, to come in the future. But I’m in control of it as the customer, or the partner managing it for that customer as a managed service.
Nicolas: Are you going to support iBGP as well or…?
Pat: Yes, we can. Yeah.
Nicolas: Is it available?
Pat: Full BGP stacked on there, yes. It just happens to be eBGP within the control plane.
Pat: So you’re fully meshed. Everybody could see everybody, unless you don’t want to. We can trombone traffic for somebody if they have a centralized firewall. Near the end of the presentation, I’m going to tell you about a single pane of glass on a templated system that manages our firewall at a thousand sites at a time. But, let’s trombone it, for argument’s sake. Kevin touched on remote access. This is an exciting area for me because I do see it as an interesting vehicle both in differentiation and also for IoT. Whether it’s an Android phone, an iPhone, or a Windows mobile device, you can connect as a customer to any of our points of entry wherever you are, across North America, and get bridged on to your customer-protected route domain.
All right, so RAS (remote access service). We got RAS. As IoT, where it gets interesting is, what’s under the hood on those embedded devices is not that much different than what’s under the hood on that Android device. The mechanisms they’re all talking about using to connect and all of that, they’re rather interesting but they’re similar. So, just imagine, corporations are starting to look for this now. We’re getting that through our partners.
So I’m a business, I’ve got 100 sites, I’ve got vending machines all over the place or whatever. What to do? So many strategies. I believe those are SD-WANs. They can be personalized SD-WANs for your home, they could be corporate SD-WANs, you could put them on a separate SD-WAN, just an SD-WAN. That’s not the issue. The issue is, how am I going to protect that device? I need some kind of perimeter defense system to deal with that.
What if I told you that our strategy is about imagining that IoT device, its sole purpose in life on the internet was to get to our nearest point of entry. And that’s it. It didn’t even know how to get to the rest of the internet. It picks up an IP address, boom, finds the nearest point of entry. You can’t even ping it from a remote country or remote competitor or whatever. It can’t respond to you. But once it’s on that SD-WAN, it can get through your customer-protected route domain. So, kind of security through office space and all that.
Keith: And then for IoT in general, I’m assuming you guys are today looking in…working or integrating well with wireless carriers?
Pat: Yeah, we are. But, again, Layer 3 world…
Keith: Mm-hmm. Makes no difference.
Pat: Yeah. Just like hand-offs. Give us an Ethernet port, we’ll take your traffic.
Keith: What delivers the Layer 2 connectivity to your device itself, to your appliance?
Pat: It’s 100% Layer 3. We hand off layer 3 at the branch. We hand off… we take in Layer 3 at the remote sites, at the data center, all that. Now, I can give you an SD-WAN at your data center, on this VLAN, if you wanted to separate it that way. But there’s still some routing that has to happen.
Nicolas: So your hardware is purely Layer 3 devices?
Pat: Well, it does Layer 2 but the SD-WAN is built on Layer 3.
Nicolas: Okay. So how can I integrate that with a regular Cisco hardware that runs OSPF or something like that? How can I migrate my legacy DMVPN or my IPSec infrastructure to your SD-WAN solution?
Pat: So each of our devices also have a full BGP and OSPF stack on them as well.
Nicolas: Okay. So I can do OSPF between my Cisco boxes or my existing boxes?
Pat: Our device and make it part of your…
Nicolas: To you.
Nicolas: And I will send my traffic to all the remote sites that are SD-WAN enabled. Is that correct? Okay.
Pat: Out of the gate, if we become your default gateway, you can see everybody, and you can get to the Internet based on the design that you chose for your model as a customer, if you wanted to trombone through headquarters or you wanted to come out of the CPE. We give you a real IP address at the branch. It never changes throughout the exchange of one carrier to another.
Phil: So you have regional PoPs already built out, your infrastructure’s built out. And you mentioned kind of casually that there’s stuff going on to connect your PoPs that gives us the SD-WAN component. I’m assuming some WAN Op. The regional PoPs are enough where if I’m in… I live in Upstate New York, a couple of hours north of New York City. Where am I terminating the other end of that? Is that just an IPSec VPN?
Pat: There might be some IPSec activity on the underlays to encrypt it.
Pat: But you’re running our protocols to our point of entry, where we encapsulate absolutely everything.
Keith: I might have missed that. Is the SD-WAN just for the control plane network itself or is that control and…?
Pat: And Data Plane.
Keith: Data Plane.
Pat: Both. We separate… So data plane is down here on the Edge, right?
Pat: And then the Control Plane is between the points of entry. They get bridged onto their own FIB or VRF, let’s say. And you can run eBGP or do policy-based routing or OSPF to manage that and tie into the end customer if you needed to at the branch.
Keith: So, overall capacity. What’s the overall backbone of that SD-WAN?
Pat: So, our backbone’s interesting. When we virtualized back in 2011, we knew that scale up wasn’t going to work for us. We had to scale out. That was a given. We just light up these controllers as needed. They’re each multi-tenant as well. They can each handle gigabits on their own. But, you know, between compression, encryption, speed, and other things you might turn on, there’s a certain way to rate their performance. You just start spinning out more controllers. That all happens automatically behind the scenes.
Justin: So you own all of the network on the back-end of your solution?
Pat: Well, we did not string wires between them. Like, it’s not private.
Pat: But it’s as close as you can get. We’ve got multiple 10 gig upstream. We are a provider. We have two ASNs we advertise. We’ve got our own IP space and we advertise some partners’ IP space as well, if they want that IP address to be theirs. It could be a TELoIP one, we’re okay with that.
Justin: So you handle all the last mile, is my point.
Pat: No. The last mile down to the branch, we leave that to the customer, the partner, or whoever.
Drew: But it could be anything. It could be cellular, it could be Ethernet, it could be fiber, it could be wireless?
Pat: That’s right, anything. It could be your existing MPLS.
Drew: Well, it could be a combination of all of them also, right?
Kevin: It’s your job to get to their PoP. From that point, they take it.
Pat: Great point.
Keith: Well, you say “your job” it’s the managed-service provider’s job to get to the…
Pat: Yeah, or the partner.
Justin: Yeah, whoever it would be in that.
Phil: Doesn’t that preclude that I’m able to do some kind of SD-WAN, some kind of like path selection, intelligent in something, from my customer Edge to the PoP?
Phil: What if there’s a garbage latent state?
Pat: No. I’m about to get into how all of that works, in the next few slides. And this is a “know now but hit me again with that,” okay? I love what you just said. Because you know what? Whatever you plug into that branch, as long as it can reach the controller, we’re in business. You want to make it a private connection? Make sure it can reach that controller somehow. It’s a matter of engineering and design at that point.
Tony: Real quick, I don’t think you fully addressed Justin’s question about your backbone, though.
Pat: Okay. I’m going to get to that.
Tony: Is your backbone like a leased traffic-engineered path or is it like dark fiber that you’ve leased between sites?
Pat: Imagine we’re a provider of providers.
Drew: Yeah, but do you have your own…do you have your own fiber… I mean, not your own fiber. You’re riding someone else’s fiber. From New York to LA, New York to Dallas, for example.
Pat: Yeah, okay. At each PoP, we have…
Drew: You can have leased fiber in between those two locations?
Drew: Okay, so you just…
Pat: That would defeat the purpose.
Drew: You’re just at a PoP?
Pat: We have carrier neutral facilities, with our equipment, fully redundant and everything. We have multiple upstream peers that we go with.
Drew: At each one of your PoPs there’s six providers that feed that PoP.
Pat: Ten gigs at a minimum each, right? However, we do have special relationships with some that should I send traffic down them, it won’t leave their network until it gets to me.
Drew: But you don’t have fiber from Dallas to New York?
Drew: And you don’t ride someone’s fiber from Dallas to New York. Once you get to Dallas, it’s out in 10 different directions.
Pat: But the guy I ride on, that is his fiber from Dallas to New York.
Drew: Yeah, they’re level 3 or another.
Tony: So you’re riding public Internet on a traffic-engineered path between the two sites.
Pat: That is correct.
Pat: We want it to be 100% Internet, end to end. Now, you can change that. You can make it a private backbone. Why not? What value we would bring to someone with a private backbone? Because the battleground is still the Edge.