Viptela is now part of Cisco.

CTO PoV: Enterprise Networks (Part 2)

VerizonIn Part 2, the CTO PoV will focus on Security for IoT and Cloud in Enterprise Networks.

IoT, Cloud and Mobile devices are stretching the traditional limits of IT security. As enterprise applications change and technology advances, the fundamental network infrastructure needs to support a robust security framework.

Khalid Raza, CTO & Co-Founder at Viptela, shares his Point of View on why current WAN infrastructures are not designed to support new enterprise traffic patterns, and how emerging security approaches designed around segmentation and policy can help organizations adapt to these changes. Enterprises can protect their Cloud and enterprise against attacks and data leaks while migrating to a cost-effective Hybrid architecture.

In this webinar, we will cover:

  • The security threats around Cloud and IoT
  • Applications that are stressing enterprise network security requirements

View Part 1 On-Demand:

Download Slides Here


Khalid Raza, CTO and co-founder, Viptela
Khalid Raza Chief Technical Officer & Co-Founder, Viptela

Khalid is a former Distinguished Engineer at Cisco and widely regarded as a visionary in routing protocols. In a career spanning over 20 years, Khalid has played an instrumental role in architecting networks for Global Tier-1 carriers and Fortune 100 companies, and defining innovative grid solutions for the healthcare industry.

Danny Johnson Director, Product Marketing: Network Services, Verizon Enterprise Solutions

Responsible for product/solutions development, messaging, and go-to-market strategy driving profitable revenue growth for a $4.4 billion revenue stream in Public Sector.


Courtney: Hello, everyone. Thank you for joining us today. We are presenting the “CTO Point of View: Enterprise Networks (Part 2)”. We have the “Security for IoT & Cloud”. Today’s presenters are Khalid Raza with the Viptela organization, and as well we have Danny Johnson joining from Verizon. Khalid is our Distinguished Engineer from Cisco, as well as our founder here, and then Danny Johnson is the Director of Product Marketing: Network Services, at Enterprise Solutions. The two of them are going to have an active conversation around our security for IoT and the cloud discussion. And I’ll let Khalid go ahead and take it from there.

Khalid: Good morning, everyone. Welcome back to the part two of the PoV of CTO, and I’m very grateful for Danny from Verizon to join this session. Because Verizon has been a great partner. They are a partner with one of the largest deployments that we have.

So let’s pick this back up from the previous discussion we had. I mentioned about software-defined networking is about very clear abstraction. So when we looked at Viptela from a security angle, a few things are very, very critical for security. From a security perspective, confidentiality is very important. Integrity is very important. Anything without authentication has no value. So authentication, integrity, confidentiality. And with the advent of cloud, one thing – and very large connected, site-to-site connectivity, scalability has become as equally important in these type of environments, especially if you’re saying I’m going to augment your MPLS VPN with any other kind of transport.

So, in the days of – especially infrastructure as a service, platform as a service, and with the rise of IoT, the dimension, scale is important, and then you have to embed a very large scale layer three network, which has to be secure. Especially with the amount of virtualization that happened at the data enter. The problem in wide area is much bigger than as compared to data center, because, a, you’re coming from a unknown site, unauthenticated devices have to be properly authenticated, and brought into the network. So it’s a much bigger problem, security point of view, [arbitrary measures], arbitrary point connectivity. So from that perspective, the device that shows up in the infrastructure-as-a-service [unintelligible 00:02:38], you as an IT security guy, you have to make sure that your network is also following all the compliance. And hence, your security footprint, your network transport security footprint, becomes a much larger element than previously.

So, moving on. When we looked at this problem, we looked at this and said, so security, IPsec was traditionally a network security protocol that was used. And it was pretty much structured for a point-to-point connectivity. People had tried to solve this problem through [GUI], but GUI obviously had some interesting challenges. Number one, it was designed for a trusted third party network like MPLS. So you had a group key, all the members of that [unintelligible 00:03:31] had a common group key. So when you move this concept of the internet, the single group key can compromise your entire network.

The second issue was that your IPsec [ASAs] were not synched with your routing, so you were relying on the underlying routing. So any out of synch models that your routing is working in, your IB – you don’t have your ASA or you have the ASA and not the routing, because those are two independent control sessions, you can get out of synch problems. So what we looked at this is, how can we make this as a massively scalable problem? And, again, I’ve noticed a lot of people coming in and talking about SDN. They’re not taking a very crystal clear view on the network security angle. How do you build these large, huge meshes?

So when we looked at IPsec, if you look at IPsec, IPsec was traditionally designed for a very predictable hub-and-spoke type typology, because your data was residing in your data center, all your access was in the data center, and even your internet access were, in a lot of cases, from the data center. Even the infrastructure-as-a-service was considered part of extending, extension of your data center. So, again, the problem people had always tromboning from data center is I might have an infrastructure-as-a-service point right next to me, but I’m tromboning through East Coast just to go to that infrastructure-as-a-service point.

So the change was that any element has to become part of your infrastructure, not a defined exit point. So from that perspective, IPsec, when you go to [en-mesh], and you create a full mesh problem, in control plane, we, the large scale routing guys, had suffered from it in the early nineties. In the early nineties I clearly remember we had a very large service provider who had a meltdown because of the full BGP mesh. Hence, route reflector was invented. So, again, you had a client that is connecting to a server, and that server is reflecting. So from that perspective, this was obvious to us that we needed to solve an O(Nˆ2) complexity, and turned it to O(N).

So when we looked at this problems, how can we do efficient key distribution? Security is about authentication and efficient key distribution. So if you do a true separation, if you look at the control plane mesh, control plane mesh is a very complex problem from a control plane perspective. You have N square mesh, every [peer] has to be brought up, and a single outage from a peer, it has to disrupt all other peers. [Make that] to a true SDN. In true SDN case, a device coming into the system from control plane perspective.

Now, this is very important, because if you did proper control and data plane separation, from control plane perspective any data plane element coming into my network just has to connect to a few controllers And then, it’s not a control plane scale problem, it is some kind of a data plane [unintelligible 00:06:47] detection problem, which is always a very lightweight protocol. You don’t have that heaviness of a control plane. So I can build any arbitrary mesh, or any type of mesh that business requires. And this whole idea of on-demand connectivity is, again, you’re building a second control plane just because you haven’t solved the proper IPsec [control and data] plane separation.

So from talking to our customers, it was then very obvious the next generation network required ubiquitous connectivity, regardless of the type of transport. MPLS was very, very attractive, and they took MPLS to the next level, because the enterprise gave away the complexity, [unintelligible 00:07:35] the control plane to the carrier, but got a full mesh – whatever mesh they needed – ubiquitous data plane. Now, if I go take internet or any LTE connection, expectation from the enterprise is, great, you’re giving me a higher bandwidth connection, I want the same ubiquitous connectivity. Because if you look at the growth in my network, video is one of the fastest growing site-to-site connectivity. So if I want to do video, if I’m increasing my bandwidth over the internet as an alternate circuit, I need to have the exact same connectivity model that I had in the MPLS.

The second piece of it was segmentation. The partner access is becoming a very critical piece of your network, and it’s going to continue to grow. So if that continues to grow, I might be sending data to a third party system for video surveillance, building management, digital signage, and in future a lot of this IoT data, again, goes to a partner which is doing large scale analytics for me. So if you continue to keep on putting point-to-point circuits, you will run into problems, scale problems. So when we at Viptela looked at this and said, if we solve efficient key distribution, [unintelligible 00:08:55] to the actual destination, which is transmitting data, then you can solve this massively scalable key distribution problem.

Along the way, we looked at so many different variables. When you’re in an MPLS environment, you know the destination [prefectures] that you’ll be connecting into. Turn that into an internet connectivity. What happens in the internet connectivity, [unintelligible 00:09:20] solves the [net hole] problems. So you can connect site-to-site around – for netting, so you open up 4,500 for net connectivity. But what happens is, when you’re doing these site-to-site [hole poking], every element, every data plane [unintelligible 00:09:44] connection to your network is a server. So you will have thousands and hundreds – let’s say hundreds and hundreds of connections, which are server-to-server. So you have to understand and put your security in place properly. Now, change that to a [unintelligible] SD N model. One of the [elegance] of SDN model is the data plane device is a client. And that connection [unintelligible], which the server.

So when client opens up the hole, it is connecting as if it’s connecting to any server that traditionally a user connects to. So you have a [unintelligible 00:10:21] that’s a properly opened up net hole. So one of the things that we advise our customers in Viptela, is we don’t care where your controller is sitting. In fact, we promote your controllers to be sitting behind a net. And we expect all the remote ends to be sitting behind the net, because then, [if it’s an intelligent system], you get that information across controllers, and you can easily open site-to-site using some predefined ports that have been opened from a client, and now site-to-site communication can happen across any kind of net. And I’ll touch this little bit more at a later point.

So with that, I have Danny with me, as I had mentioned. Danny’s team is responsible for deploying one of the largest SD-WAN networks Viptela has. Over 6,000 sites And I would love for Danny to give his input on how the deployment went, and… When they were saying that, okay, [to the] customer, you can do away with the second MPLS, get a complete service from Verizon, Verizon provided MPLS, broadband and LTE. But the customer requirement was, okay, you have to duplicate the way MPLS working over any kind of transport. In [worst] case the tertiary transport, which is LTE as well. So I want to get Danny’s take on how was the deployment, and what’s his take on this new way of using the transports.

Danny: Yes, thank you, Khalid. And with this particular deployment – and we’re finding this to be the case on really any large scale deployment, or even midsized deployment – it really starts with some of the customer challenges. So let me just start there, because to understand the customer challenges and application needs, it really wires to the ground the importance of some of the key areas that Khalid just talked about, which essentially are scale, security, compliance and segmentation, which all are really met with this joint solution with Verizon and Viptela.

But to start with the application, this particular use case, with this particular customer, the customer really needed to accomplish a few things. One, they needed to open new branches, not only on time, but also in a quicker fashion. They needed to increase the network stability and decrease the time to repair, and then also reduce network complexity. I mean, I think all of us can agree, we are in a paradigm shift in how networks are actually being orchestrated today. Hybrid options are becoming more prevalent because of the introduction of just the price compression on price for bandwidth. So public bandwidth type of network connectivity options, whether that be public internet or broadband, are really coming to bear. And then the increase of bandwidth really to drive new applications to the [unintelligible 00:13:13] branches. However, more bandwidth doesn’t necessarily equate to better quality.

Now, some of the challenges, really, that existed with this particular client were they had an ageing [unintelligible] CPE within their environment. They did have insufficient bandwidth to improve their customer experience. And this is very critical. They needed the appropriate level of application availability to help reduce the impact from extended [unintelligible 00:13:40] to their client base, because this particular client is really moving to very much content-rich, integrated application service to their client base. All right? So not only are they deploying new applications out to their client base, but they’re also wanting to converge on video and voice-based applications as well.

All right. So essentially what did this solution offer? It offered all the components around scale. Right? So let me touch on that for a minute. Being able to scale across a hybrid network environment, that is very critical. Being able to deploy new retail locations faster than they ever had before. However, in this particular segment, it goes without saying that security is paramount. Both security and compliance. So what Khalid is really talking about in terms of the implementation of the security layer within a control plane abstraction is critical, because that allows this particular client to scale. You’re looking at 1,200 plus sites, globally, as well as, at the same time, meeting security and compliance requirements.

And then lastly, you see here… I mean, there are… Our clients are working with other partners as well. And being able to provide not only an agile infrastructure, but also the security implementation to ensure that there’s end-to-end visibility into their applications, in this particular case being hosted by third party providers, we’re able to jointly provide end-to-end visibility into their application domain from mobile to cloud, leveraging quality of service, enabling the applications to have the appropriate level of treatment within a very highly secure environment.

So this is a very compelling solution, and the strength of Verizon and Viptela really, really was able to nail the customer challenges, and really help this particular client in all of their strategic goals.

Khalid: Thank you, Danny. So as Danny had mentioned, the customer that we had jointly [went into], they were kind to bring up their sites in a very quick fashion, and any location they would come they wanted to get any type of circuit available, and bring that secure ubiquitous connectivity. But if you look at this concept, we’re literally making IP as the transport. As long as sites have an IP connectivity, even if one site is on internet and the other site is on MPLS, as long as there is an IP connection between them, they will be able to build that ubiquitous data plane.

So from our perspective, as Danny had mentioned, you cannot continue to send truck rolls. So for any site you bring up, zero touch provisioning was a very key piece of Viptela’s solution. It’s zero touch provision, you can connect to the controller, and before you connect to the controller there is an element that authenticates [you]. That’s the only element that is required to have a public IP address. So we authenticate through a certificate, and then we let you establish a DTLS connection with the controller.

And during this process, the system has intelligence to figure out the type of net that is there. Because Viptela can actually form connection between site to site. Remember, the controller is at a central location, sites require a ubiquitous data connectivity. So how do you connect those site-to-site across any kind of net? In fact, one of the things that we are very proud of is Viptela can connect sites even across the metric nets. And interestingly, when you’re connecting sites through netting, you cannot integrity protect the data. Again, if you do solve these problems elegantly, we actually can integrity protect, even if the IP addresses along the net changes.

In fact, this is an interesting security tool for us. That man in the middle doesn’t know what elements have been integrity protected. So even if the addresses are changed, it doesn’t matter to us. The true integrity protection happens between the two data plane points, and intermediate points have no visibility of that integrity protection, even through a net. So for us, it was very, very important to build the capability to build ubiquitous network across all data planes. As I had mentioned, one is MPLS, the other is IP. [We didn’t care].

So from the perspective of large meshes, if you look at the scale problem – again, I had mentioned – say I have 1,250 sites. Now, any device failure, say one site goes away, it has to – during the reboot, it has to reconnect with about 1,250 sites from a control plane perspective. So you have to figure out how you… [Unintelligible 00:18:30] the system, how… Whether it’s a true connectivity or a DOS attack. Compare that to a proper SDN connection. That is why Viptela never advises its customers, okay, you want full mesh, you want mesh connectivity, please do it on demand. We say we do not dictate how your network should build. The networks were always [unintelligible 00:18:49] on typology. Tomorrow’s elegant networks has to be built on policies. So you as the customer decide your policy, we don’t decide your policy.

If you have that requirement – in fact, one of the most interesting things… We were working with a healthcare provider. Now, healthcare providers have very, very stringent requirements of latency, both healthcare and manufacturing. So a lot of architectures that gear towards pure retail, it’s a slightly different requirement, but those requirements, if you start to talk to retail guys, they’re also changing because for Skype for Business I want site-to-site video. So the healthcare provider clearly told us I have a full mesh MPLS as my primary. During migration – just think about it – even during migration, site-to-site I want ubiquitous connectivity. If you’ve architected it properly, that should not be a problem. So half of the sites that were not migrated from the MPLS were going through MPLS, the other half that had migrated to Viptela were using primary as Viptela and secondary as MPLS.

So we did not disrupt that full mesh connection, because the requirement they clearly told us, hey, guys, we have a 19 millisecond latency requirement from these sites, which our imaging application requires. So you can’t backhaul it to a data center point which might introduce another 30 milliseconds of latency. So for us, that was the key. And again, imagine 1,200 sites rebooting. You will have issue rebuilding your control plane. Believe me, anybody who’s played with big networks, have worked on big networks, have seen those outages, have understood how the scaling happens, how these control planes start to get out of control when you have these very large meshes – or even on-demand.

You can’t tell a customer that, okay, your MPLS is full mesh, take the second circuit out, and put my second on-demand [unintelligible 00:20:42]. Imagine healthcare. I have a 19 millisecond requirement. I have site-to-site connectivity. Should I wait while you’re building your IPsec tunnel? That does not scale. So these are questions that you have to ask, that if somebody has done property management, have understood scale well, will always be able to build any arbitrary points. So… Requirements by the customer.

So from that perspective, we can scale any type of IPsec mesh over any kind of transport, without requiring or without asking you to abide by my rules. We don’t tell you rules, you tell us the rules. That this is what I want in the network. So the next question that we looked at is: How elegant DDoS mitigation should be? Because some of these Edge routers are exposed to the internet. So we have this element, I had mentioned, a vBond, which is the first element which authenticates these devices. So now we have – once we establish our connections to the controller, we only allow [known flows]. So only known flows are allowed to go to the control plane. So nothing more. And in case of a control plane on an Edge device, you might have four, five control plane connections. And on top of it, you can put an implicit ACL.

So only these five, six guys I know are allowed to connect to my control plane. So anybody who tries to attack on top of it, we throttle those connections. So [through the] CPU, we know that we have… we throttle how many packets can go to the CPU. So from control plane perspective, we know the known flows, we can put an implicit ACL, any unknown flow does not connect. Soo this data plane element, which has only few connection to the control plane, can seriously scale. Now, coming to the data plane, data plane is on the fast [path]. So you can… That’s a simpler problem to solve. So, again, as I had mentioned, always keep that in mind. A full plane IPsec, full mesh IPsec control plane. And that’s why most people realize that there is a flaw of a second control plane in IPsec with [unintelligible 00:22:54] they’re introducing. They always recommend you, oh, don’t build full mesh, just build based on demand.

One of the reasons is just imagine one site has 1,000 IPsec connections, [unintelligible], at one time you will not be able to differentiate whether it’s a DOS attack or it’s a reboot. So… Plus, your control plane also has the view of the entire network. So if anything happens at any point in the network, you can take that element out, even within a site. If that is an element that is misbehaving, you can [service chain] through a segmented path. So that was… For us, that was a very key part of it.

The second piece of it is –

Danny: Hey, Khalid? Could I just inject a question really quick on your last slide?

Khalid: Sure.

Danny: So what if I’m interested in moving my control plane to an MPLS-only environment, as you just described in terms of the capabilities? Is that feasible?

Khalid: That’s a very interesting question, Danny. And we’ve had this discussion with your federal guys, and we’ve talked to other federal organizations. So having control plane on both is a high availability thing. So regardless of the type of circuit going down, it’s perfectly fine that you build control plane on internet and also build a control plane on MPLS. As we moved into the federal space, this is one of the questions which a lot of federal guys, they like the elegance of our solution. So you providing service that says I just want to build my control plane on a private environment – could be MPLS in case of a lot of agencies – it’s only over satellite.

So that control plane over one infrastructure is only accessible to me, which I have [unintelligible 00:24:42] visibility, but the data plane I can build over the internet. So if you think about this, you’re not sending a single packet, and you’re showing up in a deployment at any location any hostile environment, you’re showing up at any hostile environment, you can get an internet circuit, you do not build a control plane on that, but you’ll still be able to pass the data plane between those two points. From commercial point of view, the customers are completely comfortable building it over both. From federal we’ve heard this very specifically, I should have the flexibility to build my control plane over any kind of transport. And, again, that’s the elegance of a proper SDN solution.

Thanks for the question, Danny.

Danny: You got it, thank you.

Khalid: So another thing that Viptela focuses is on deep packet inspection. So if you look at how we use these deep packet inspection, we have individually 3,000 flows. And we recognize those applications, we profile those applications, and on top of it, if… One of the things that we’ve heard from IT leaders, that their line of business says, hey, I want flexibility. My marketing team wants complete freedom to pick an application. Now, put that in the context of a financial environment. You have a compliance regulation, so you’re saying I’ll permit these applications, just make sure that they’re compliant by my system.

So in that case, if I’m permitting the marketing team to have access to a certain application, hey, I’ll profile that. And I’ll look into it and said, these are the application which were permitted, or any other element, say investment banking. You’re not allowed to use that application from a local exit while you’re allowed to use it backhaul through a compliance point. So you should have the flexibility to identify application, to control application, and if any of these application does not match, which is out of profile, you should be able to drop those application on per segment basis.

Danny: Hey, Khalid? A quick question on this one as well. So Verizon has deployed our virtual services model, that service chains VNS or other applications within a virtual environment. Is this something that could also be deployed in a service chained architecture?

Khalid: Absolutely, Danny. As I had mentioned, the compliance point. So [whoever is] buying service from you can always put a compliance point, or Verizon can provide that compliance point, so I can put a service chain path. Some of these applications which are permitted can take a [unintelligible 00:27:18], but certain applications will have to go through that compliance [unintelligible] inside of Verizon’s network [and say] if that’s the application, it’s the profile, it’s within that segment, and it will always go through that service chain path.

And rather than all applications being permitted, I can control which applications and which application goes through a Verizon offered or any compliance point. And in certain cases some of our customers are using [vScaler] to backhaul that to a vScaler point. So… But that’s all part of the architecture that was put together to be very dynamic, and what customer wants to do, how they want to profile, how they want to build their policies inside of the network. That became very essential for us.

So let me just touch just briefly on the IoT side of it. So we’ve seen consistently from our customers in the financial space, they were actually building third party networks to bring these different services they were trying to get into the network. They wanted their network to be completely separated, so video surveillance, you had a smart building solution. So on top of it, you might have a PCI compliant site on the same network. If I’m a healthcare industry, I would require HIPAA segment. So each one of those segments are individual, and each one of them have their own independent typologies.

So once I’ve recognized the applications, once I’ve profiled the application, their application is required to use that segment only, no other application can use that segment, and each of these segments have their independent typologies And just imagine, with digitization, your partners, in a lot of cases, would be coming from the internet or from the cloud, to access the data that they are required to use. So if I’m your video surveillance provider, I’ll come from an arbitrary point on the internet.

So me being the network administrator should make sure that point coming into the network has only access to the application or the segment it’s supposed to, and that other [unintelligible 00:29:31] element is, again, applying by my compliance, and no other element should be able to connect to it. So I should have this capability to do [whitelist] typologies. If you’re not following a whitelist typology, something is wrong. And I can pivot your path to the service chain path as an on needed basis.

So if you look at it, as Danny had also mentioned earlier, our customers are ultimately looking for an improved application performance. From stats perspective, from infrastructure-as-a-service perspective, from any cloud point, to do a [unintelligible 00:30:10] path, I need to have my compliance into any element. I cannot continue to ask you to – based on your requirements, to follow my rules. You should tell us a rule that this is how I want my network, this is how many meshes I need, I’m putting a video in place, I’m putting a SAS infrastructure in place, I’m putting a [path] infrastructure in place, and any time a new site comes in, it’s additional to the data plane, not that heavy burden on the control plane.

So for scalability purposes, for the true abstraction of data and control plane, there is some serious innovation what was needed, rather than continuing on the traditional model of point-to-point IPsec [unintelligible 00:30:58] control plane. And Viptela’s solution, one of the biggest thing is been driving our solution successfully in healthcare and retail, and financial, is, a, compliance, b, I dictate how my system should work, and I have the access of the control plane which I need to build in a secure fashion. And as we grow, I expect any arbitrary point, and I should be able to connect it with a [very single] orchestrated policy, and I’ll make sure at the center the policy is compliant, then I let that application go.

With that, I’ll stop, and I’ll open up for questions. Is there any question, Courtney?

Courtney: So we do have one that came in here that says: In a case where separate control planes are dedicated for MPLS and internet, is it possible to have both of them [unintelligible 00:31:54] and exchange routing information for a seamless experience? [Unintelligible].

Khalid: So to answer that question, so one of the things I had mentioned is our control plane runs over both, and routing works seamlessly. We are large scale routing guys. To a point Viptela understands routing [loops] across multiple typologies; if one is MPLS, the other is internet. We’ve taken care of so many things clearly that you will enable underlay and overlay seamlessly, and the routing loops won’t happen. So from that perspective, the control plane is single, over either type of transport. The question Danny was asking is – some of his federal customers have asked him, and some of our federal customers have asked us – is I don’t want to put the control plane purely on internet. Most of our commercial customers are perfectly comfortable, [so either] it’s MPLS ort internet, it’s a single control plane. And then that single control plane interacts with your traditional routing, and interacts very cleanly with your underlay and overlay.

Anymore questions?

Courtney: I see one coming in here. Key server – so this one looks like it’s directed towards Verizon, Danny, there. How does your solution – how is your solution better than the key server model?

Khalid: So I can actually [unintelligible 00:33:13].

Danny: So I – yeah, go ahead, yeah.

Khalid: Yeah. So here’s the issue with key server. key server has two interesting problems. A, the key server and the routing can get out of synch. Key servers can have split [vein] problems. So key server, detaches the location you’re trying to protect from the encryption keys. So that’s my take on it, and then I’ll have Danny give his take on it.

Danny: Yeah, no, and I think Viptela’s implementation is critical. Right? Because when you look at the abstraction of how Viptela’s solution is actually handling key exchanges, to be able to do this across a hybrid network environment becomes very, very, complex. Okay? And so I think being able to have a single control plane to manage that entire ecosystem becomes very, very relevant. And so I think at its basic root, that’s the value behind not having the traditional way of key exchanges.

I’ll give you another example. One may not suggest that we may need it for MPLS, but then when you introduce broadband and other public internet strategies, you may have a mix of them. But then when you enter SD-WAN and the implementations for SD-WAN, really are predicated also on encryption, this becomes a very pronounced and compelling value proposition for our clients. It simplifies the network for our clients, and enables them to scale very rapidly.

Courtney: Great. So, yeah, we’ve got a few more questions streaming in here now, and we’re just past the 30-minute mark. So we have: What is your support for third party VNS strategy for the [Edges]?

Khalid: So I think I earlier mentioned in my previous webinar, we have a couple of hardware and we have software. So if you take Viptela software and you can make us work as the routing overlay solution, and you can attach all other third party VNS. We are actually working with the partners in that space for a third party VNS service that we want to provide.

Courtney: kay, and then this one is directed toward Danny. DDos point of view. What does a service provider provide?

Danny: So from a service provider perspective, where we’re going is, and what we’ve deployed, is we’ve deployed a very comprehensive service chain model. And so we… And Viptela is a very critical part of this. And so when you think about how applications are being consumed, we want to be able to serve those applications in a very utility-based model, with an overlay of orchestration that creates an automation end-to-end. So not only can you deploy your security services at the Edge, or consume at the Edge in a virtualized Edge solution, or through the network you could also consume optimization services, or routing services, all within a virtualized context. And you can consume them and deploy them where you need them, so if you need security services and DDos mitigation services at a certain number of your locations, we can deploy them through the network within those particular geographies or within those certain locations.

And so we’ve introduced also a different commercial model. So in other words, we’re not tying service applications or licenses to a particular appliance, per se, but you can consume them in a variety of different ways. We’ve got a large catalogue with even micro features to say, okay, you may need fundamental security images at certain locations, and then need to upgrade them at a certain time. You can do that automatically, and you’re only going to pay for what you actually use. So in other words, we’re going to provide you with a month-to-month license utility-based commercial model to consume services from that perspective as well.

Courtney: Great. There’s definitely a few more questions coming in. Do you see vEdge devices altogether replacing the conventional routing infrastructure being provided by other players? [Unintelligible 00:37:36] the other larger folks.

Khalid: So what we have done is we’ve taken the overlay model and we have simplified the overlay routing functions. But routing has been there for a very long time. If you take underlying infrastructure you can’t show up in a data center which is working and has a complete setup of BGP connectivity or a remote site which is running OSPF and BGP. The intelligent routing system should interact with all of them. I mean, people still want to continue on MPLS path. You can build overlays across it. But within the site you have your existing routing protocols. So those existing routing protocols should seamlessly interact across this.

Replacing BGP [unintelligible 00:38:19] on the internet infrastructure is no trivial job, and BGP is a very elegant protocol to do the [AS Path] construct, and building AS Path connectivity. So I’m not… I don’t think it’s very easy and it’s the right thing to say that routing is gone or you’re going to change routing architecture. BGP will continue to thrive, and it’s a very elegant protocol for MPLS connectivity. But your system should be intelligent enough to understand how to interact with these existing routing protocols through the overlay systems.

Courtney: Great. For handling application-aware routing, path selection management is essential. What’s the logic of Viptela’s solution based on, to be able to enable this? And is it based on a kind of intelligent engine or analytics, or some kind of [heretic]?

Khalid: So Viptela, right now, at this stage, has a very intelligent system that looks at loss, latency, jitter, of each of these available circuits. And you can – based on the app-aware policies, you can move those applications around. Long term we are actually looking at introducing our vAnalytics. The analytics will have a much more clear understanding of the circuits, the location, the application profile. In fact, we have some very interesting data for our customers to advise them what carrier works well with what SAS providers in what locations. And in that… What your application profile is, at what point you should consider upgrading your bandwidth, because your application profiles have been kept very well. So in a lot of cases, high profile application traffic [take the tighter SLA paths], in certain cases [unintelligible 00:39:59]. If at a certain point one transport is behaving better, you can seamlessly move it around without any disruption to your system.

Courtney: Okay, and I just want to encourage folks to go ahead and download these slides that are in the attachments and links area. And, again, the recording will be sent out to everybody. We’re down to a couple of more questions, and, again, we’ll send this recording out to everybody.

These are compatible – oh, it’s the last question here, or last couple of questions. These are compatible with all routing protocols, for example, [unintelligible 00:40:28], and you said that the zero touch Edge is – [how is the discovery on the Edge of zero touch?]

Khalid: So when the Edge comes up, it goes in – as I’d mentioned, it authenticates itself, and then you have pre-set up templates in your central management system. Then that gets pushed. And then if your local site is running BGP, you have that [templatized] version of it, it goes, and it’s configured, and then your BGP [unintelligible 00:40:56] starts to work. As I mentioned, we get [peer] across all the other protocols. In fact, as I’d mentioned, we can detect loops – the system is so intelligent that it knows that during underlay, overlay, transition time, when half of your network is running MPLS and the other half is running simple Viptela overlay, and you do want to site-to-sit connectivity, we have that much intelligence to understand that where the source of this OSPF traffic is, that the overlay knows, okay, this [unintelligible 00:41:26] data center, it went through under MPLS, and it came in on this site.

So we will not source that OSPF [prefects], because we know that the intra area route exists on a data center, while this is an external link [site]. So we have put a lot of intelligence into the system. That’s why our customers, when they see this system, they deploy and says that’s a very quick deployment. Because I don’t have to worry about all the complexities, traditional routing loops, the system is intelligent enough to work across three routing protocols, and still interact seamlessly, and building into the overlays.

Courtney: Great. And our last question coming in here, to Khalid: Your thoughts on microsegmentation.

Khalid: Ah. Very interesting question. So microsegmentation, I think, is going to happen in the branch. A, you’d need it for zone-based connectivity. But it really simplifies your policies, because if you look at it, I think of VPNs that we created as segments, as macro segments. And in microsegmentation cases, you need… If you look at what happens to policy, your policy is consistent, but IP is – identity is not, because you’re still tying it to IP identity. What if I tie that identity as consistence as well – consistently as well? So you as a network guy can offer a very clear abstraction to your security guys and say, hey, as long as I follow your classification of the identity, if it’s an ATM machine throughout my 5,000 branches, they all have the same identity, then my policy is consistent, and so is my identity.

Today the identities are not consistent, so you have to – any time you provision or decommission any site you have to have thousands of those ACS provision for each branches, because you won’t like to permit side-to-side ATMs. But with this type of model, Viptela is soon introducing that concept of zone-based, and they’ll take that idea into the larger context in our next releases. But, again, if you solve problems architecturally correct, you will be able to address so many different use cases that are thrown at you, rather than struggling with trying to solve some very basic problems of on-demand control plane connectivity, especially around securities.

Courtney: Great. And with that, it looks like we’ve wrapped up on all the questions. If there’s any further ones, please feel free to reach out to us at, as well Verizon. Danny has put his contact information there;, I believe. Danny, is that the correct contact information for reaching out?

Danny: Yes.

Courtney: Oh, my apologies.

Danny: No problem.

Courtney: And then khalid@verizon –, I’m sorry. We certainly appreciate you joining us today, so it’s been a great, very active conversation. Great, and we’ll get this out to everybody shortly. Thanks so much, everyone.

Khalid: Thank you.

Danny: Thank you.

Watch Now