Three Case Studies in SD-WAN Deployments

This webinar will cover three mature SD-WAN deployments. Customers in multiple industries face a common theme of problems in the WAN. We will walk through these problems and why SD-WAN passed the requirement test. Taking the example of three advanced SD-WAN deployments from different industries we will cover how the migrations were planned, and, how the user experience changed before and after the migration.

The Viptela Software-Defined WAN (SD-WAN) platform delivers an agile, cloud-ready network infrastructure. The major benefits of the SD-WAN technology is a single overlay architecture with centralized policy & management. Viptela SD-WAN has been deployed by the largest banks, retailers, conglomerates, healthcare providers and insurance companies.

Webinar Highlights

  • Key WAN problems for three customers in financial, healthcare and retail
  • Different drivers for SD-WAN: M&A, Bandwidth shortage, long times for change control, lack of app visibility
  • Difference in choices of Hybrid WAN architecture
  • Walking through the testing process, pilots and full deployments

Download Slides Here

Presenters

Lloyd Noronha
Lloyd Noronha Head of Global Marketing, Viptela

Lloyd heads the Global Marketing team at Viptela. He brings 20+ years of experience in technology and business practices to drive cutting-edge marketing strategies in B2B environments.

David Klebanov Director of Technical Marketing, Viptela

David has more than 15 years of diverse industry experience architecting and deploying complex network environments. David sets strategic direction for industry-leading network platforms, which transform the world of wide area communications for enterprises and service providers alike.

Transcript

Lloyd: Hello everybody, this is Lloyd Noronha. I head the global marketing at Viptela, and I really want to thank all of you for joining this webinar. I see people who called in from all parts of the world. This has been our largest registration yet, and I really, really want to thank everyone for joining in. Keeping with our past tradition, we are going to make this a short webinar. We’ll be talking for about 20 or 25 minutes.

We’ll be looking at your questions as we present and take on and answer some of those questions towards the end. With that, I want to get started. As you know, this webinar is being recorded, and I’m joined with my co-presenter, David Klebanov, who is the Director of Technical Marketing at Viptela.

Regarding this particular webinar, we’ve gotten themes of questions repeatedly from our customers on talking about our existing deployments and what learning there are from that. If we look at the Viptela product line, we have been shipping for the last two years. We launched our product in May of 2014, and we’ve been shipping for a little more than 2 years now. In that time, we have deployed about 15,000 production sites across a wide range of verticals, mostly focused on the Fortune 500 or Fortune 2000 space.

We want to use this webinar to kind of talk about some of those verticals, the learnings from that, and focus on two or three of these verticals and specific case studies along those lines. These deployments, when we look at these 15,000 production deployments, some characteristics of them are that they have been across the world, so in almost all continents of the world, I think exceeding about 20 to 30 countries right now. Also, the deployment methodology has been different. In some cases it has been direct, operated by in-house IT teams. In many other cases it’s been with our system integrator or managed services provider partners.

We have about 10 or more really large MSPs or SIs that are our partners. Some of the public ones that you know of our Verizon and SingTel, but there are other significantly large ones as well who we are working with. Deployments in different verticals, if you can see the slide, has been in retail, hospitality, financial, transportation, healthcare, manufacturing, government, technology and more. If you look at the deployment themes of these verticals, on the one hand, we have the retail, banks, transportation, which are very franchise-like operations where each site looks like every other site and it’s essentially a cookie-cutter approach to deploying a network.

In most of these cases, the biggest requirements of the business priorities that drive some of these decisions are grounded in operational expense and the capacity that they need for new applications on the network. On the other hand, we have companies in the healthcare and the hospitality space which have, if you characterize these deployments, there are a few large, headquarter -like buildings which have very sophisticated operations in them, and then many satellite operations that are spanning all over the place, whether those are small clinics or whether they are small distribution centers or small retail centers spread across different geographies.

In this case, the network requires a lot of sophistication at those big locations, and then support for the satellite locations after that. If you look at the manufacturing companies and the other holding company kind of pattern. The big requirements there are there are centralized IT operations where they’re rolling out a WAN, so it’s not only to their multiple holding companies, but they’re also wanting the WAN to be completely separated across these holding companies, as well as they want to be able to support their business partners on the network. There are multiple themes along these lines. Of course, when you go into government, you are looking at very sophisticated deployments and security tends to be the largest discussion point of this deployment.

Across the board, what we want to talk about is some of the case studies. We, of course, cannot talk about all three, but today we’ll be focusing on a couple, about three, which is manufacturing, healthcare, and financials. We’ll be diving down deeper into what drove them, what are the specific applications that drove them to make the change, and once they decided to make the change, how did they go about it? As with previous webinars, we’re going to jump directly into it and we can take any of your questions as you have them. Please use your chat window and your Q&A window. I want to turn it over at this point to David. David, do you want to take it away?

David: Yeah, sure. Thank you very much, Lloyd. As you mentioned, there’s pretty much deployments that span across every possible vertical. They have a different care-abouts, and in this specific webinar, we decided to really focus on just three of them. When we’re talking about those three, the way that we wanted to position that is to give you a glimpse into what is the main driver that was the trigger for the organization to look more significantly into technology such as SD-WAN. Of course, SD-WAN comes with a variety of advantages, but there’s always a handful of triggers that really take that company, that organization over the edge, so to speak, to really pull the trigger and look at that and go for deploying that.

Does exactly what we wanted to look at, to give you concrete examples of what was their trigger for those organizations? The first one, let’s look at the financial. It’s a 1,500-site bank. The ask that they were after was a rollout of a high-bandwidth video application across 1,500 site. Now, the target for the rollout of the application was to increase the revenue for the line of business responsible for that application for $1 billion. It’s a very strong business driver behind deploying an ST-WAN technology.

As the organization sort of looked around and evaluated different SD-WAN solutions and eventually deployed Viptela SD-WAN, there’s a few things that Viptela SD-WAN solutions was able to provide to them that made the task of deploying this high-bandwidth video application an easier one to carry out. The first thing that allowed that, and I’m really going to touch on the three points, three main points that allowed that video application to be successfully deployed to reach the business target that that bank was going after.

The first one is since this was a high-bandwidth application, a high-bandwidth video application relying solely on the MPLS network, which was the primary means of transport for that bank, was something that was not sufficient. Viptela offered more capacity, more bandwidth capacity that was used in active-active fashion. Some were by replacing MPLS circuits with two broadband circuits. Some were augmenting MPLS circuits with additional broadband circuits. It’s a variety of the means to deliver capacity in the active-active fashion to allow the sufficient bandwidth for that video application to be rolled out.

Now, when the application is rolling out, and of course there’s a consideration for providing an adequate quality of service for the application, especially if this is a high-bandwidth and high-quality applications, you want to make sure that after you have gone through the expense of procuring the infrastructure, you want to make sure that your video application quality is adequate for your use case.

In that case, Viptela offered two main differentiators in the form of application and rerouting, which is the ability to intelligently reroute around a path brownout conditions and make sure that, should any of the circuits or anywhere on the path between the two locations within that bank experience any degradation of service, otherwise known as a brownout, then application rerouting functionality would kick in and make sure that the traffic is rerouted over the circuits that do not experience any degraded service.

They were able to set the specific SLA characteristics for that application of interest to make sure that the system always abide by those SLA definitions. The second one from the application awareness is the application-aware topology. It’s to make sure that not only is the application forwarded across the best-performing path, but it’s also forwarded across the shortest path. The combination of the shortest path and the best-performing path gives you the utmost flexibility to deploy a high-quality application.

By application-aware topology, I mean the ability to deploy simultaneously over the single virtual fabric and ability to deploy a hub and spoke, full-mesh topology or original mesh topology. The ability to influence the path that the traffic takes, coupled with the application of a routing to reroute around brownout conditions, both of those deliver the adequate service. At the end of the day, being a bank, security is top of mind, so the ability to ubiquitously encrypt across all the transports, and I’m not just talking about encryption in the form of doing IPSec, but actually an intelligent system for being rolled out across 1,600 sites, which is really not an easy task to achieve through a traditional point-to-point IPSec means.

This is where Viptela brought the intelligence of the SDM solution and the coupling of control plane and data planes into that environment that allowed the system to easily scale to 1,500 sites. As that bank continues to grow and add more locations where that high-bandwidth video location is deployed, it’s an ability to just continue growing as your needs grow. This is about the financial customer.

The next one is a 400-site manufacturer. What were the triggers for that company to look at the SD-WAN adoption? The triggers for them were primarily around segmentation of different lines of business at scale. When we’re talking about segmentation, we are really talking about dozens of virtual segments that are deployed over a single, unified virtual fabric. The ability to do the line of business segmentation and scale was an imperative trigger for that organization and to explore an SD-WAN technology.

At the same time, the manufacturer had business relationships with numerous partners that had to be accommodated as far as having access into the manufacturing floor or the systems that that manufacturer operated. The ability to securely bring a partner connectivity into the environment was also top of mind. What are the three things that Viptela enabled for that customer? As I mentioned, a single virtual fabric, to be able to deliver that highly segmented environment for lines of business, while diversifying the last-mile technology.

As those lines of businesses spread around the world, the last-mile technology is not something that can be set in stone, so the decisions are taking on a site-by-site basis as far as what is the most optimal last-mile technology that should be utilized for that site. That could be broadband DSL or cable, or in some cases in rural areas, it could also be 4G or 3G cellular technologies to provide connectivity into the fabric. It’s a single virtual fabric with diversified last-mile. The end to end segmentation is really allowed to compartmentalize those lines of business and to make sure that there is a clear segmentation between them and running, as I mentioned, dozens of those lines of businesses across a single, virtualized fabric.

Now, for the partner access, that could get a little bit tricky. You want to provide business partners or technology partners access into the system, and those could be just resource planning systems or just the manufacturing floor environment. Yet at the same time, you want to make sure that is done in a controlled fashion. In this case, Viptela was able to provide an extranet service to be able to bring the customer into the virtualized environment while keeping the boundary between the segments that the partners were brought in, and the rest of the segments that were for the purpose of line of business use, those were segmented through a stateful inspection such as firewalls or intrusion detection/intrusion prevention means.

Lloyd: Just to add to what David said, if you look at the before/after picture in this network. Before Viptela deployed the SD-WAN, the company had, the manufacturer had about 18 VRFs in their network on a single MPLS link, and another 18 VRFs on a backup link. They had no segmentation, really, for their business partner network. It was a very security-risky network in that sense, a risk-prone network in that sense. Along those lines, after the transition, they were able to move to 18 or more VRFs across a hybrid network, so it was a network consisting of MPLS and broadband.

They could maintain their 18 VRFs, but the VRFs were on the SD-WAN network and not on the MPLS network. It was much easier to deploy and manage those VRFs because the same segmentation was being maintained across MPLS broadband, and in some cases the LTE links they had on the network as well. In addition to that, they were able to roll out a large number of the RFs for their segments, for their business partners, and keep each of them completely isolated from each other.

As you know, in manufacturing, the protection needed for each of the business partners – each of them is working on a secret product which they are not ready to launch yet, etc. – is highly critical. These aspects were very important for the manufacturer.

David: Yeah, that’s a very good point, Lloyd. It’s really the ability to deliver a transparent, independent fabric across any set of transports; MPLS, broadband, 4G LTE and point-to-point links. The ability to deliver that fabric and be able to segmented that traffic was an extremely important thing. Before, that manufacturer basically use the services provided by the service provider, so of course segmentation is not something that was created just for that project. Of course, it’s a technology that could have been deployed before, but it required a cooperation from the service provider.

It was also very much bound to a specific type of technology. Of course, technology such as in MPLS provides significant means of segmentation into the private VPNs, but first it had to be negotiated with the service provider to make sure that the traffic is mapped to the proper VPN. Second, that approach was only applicable to an MPLS network. As a manufacturer looked to diversify the last-mile connectivity and start employing additional means to get people basically connected to the fabric, the ability to segment while using, let’s say, broadband last-mile is possible, yet it’s very operationally cumbersome.

The needed advantage that the manufacturer drew from the deployment is the ability to highly segment their network for either line of business or business partner access, without the reliance on characteristics of a specific transfer, such as an MPLS segment, and diversify last-mile.

The last one that we wanted to touch upon is the healthcare. The biggest trigger, or the most significant trigger for the healthcare provider was the ability to deploy a highly available and highly resilient network. Just to kind of ponder on that for second, when we are talking about high availability and high resiliency, we mostly define things in a matter of off-time. Is it three nines, is it five nines, and it’s really measuring the minutes that is acceptable for the network to be down.

If you think about a healthcare provider environment, such as operating rooms and surgery rooms, things of that nature, really talking about life-critical environments where the high availability and resilience of the environment takes a completely different shape. We are not measuring downtime in a matter of minutes, but we are literally measuring downtimes in lives that could be impacted if, during the surgery, there is a delay or inaccessibility to critical patient data, for example. Or, maybe collecting a reading for specific sort of function from a monitor.

Network characteristic as far as high availability and resiliency come in a very significant light when you’re talking about a critical healthcare provider system. In this case, but we were able to deliver to support those high availability and resilience environment in a life-critical environment, is to make sure that the system is highly resilient with no single point of failure in any single element of the system, and that extends from the device level, the circuit level, the path level, the entire fabric level, control plane redundancy, and really taking that no single point of failure approach to every single element across thousands of hospitals and clinics that that healthcare provider operates.

That’s definitely an extreme top of mind. At the same time, as I mentioned earlier, some types of traffic that are being sent across the network, it is not sufficient for just the network to be up all the time or to be able to quickly recover from brownout conditions, but it’s also very important to prioritize specific types of traffic that could be leveraged during a life critical situation where doctors are trying to access that information, and to make sure that that access is done in the most efficient and expedited way.

For that, we have to offer a pretty extensive set of quality service, prioritization mechanisms across the entire solution from a device level to circuit level to path level to an entire fabric level to make sure that that traffic of interest, the one that is used in those life-critical environments, is always given the most preferential treatment and make sure that that healthcare provider enjoys the benefits of that.

As you can see, we kind of talked about the three different case studies or mini case studies. In this short webinar, of course, we’re short on time so we can’t just dive into all the intricacies of that. You’re more than welcome to reach out to us and to get more details, but as you can see, and as Lloyd has mentioned in the beginning, it’s a different environment with different requirements and a different approach that was taken for each one of them. That’s really the power of diversity and to be able to accommodate those environments which made Viptela a natural choice for those organizations.

Lloyd: Thank you, David. If I were to bring David’s examples together in one picture, this would be that picture, where it really talks about the entire area of focus of SD-WAN, the set of challenges that SD-WAN is tackling right now. Whether that’s something related to adding cost-effective bandwidth, whether it’s related to security either in terms of encryption, authentication, segmentation and the like, or if it’s related to cloud-readiness. Or, simply dropping operation complexity, right?

To give you an example, one of the retailers that have deployed our solutions was able to do a 1,000-device upgrade in an overnight operation. A software upgrade on 1,000 devices. Now, comparing it from the previous mode of operation, where it would take easily three to four months to implement something similar, we were able to do it in an overnight fashion without any outages. Now, those are the kind of value propositions we have seen across SD-WAN. Those are the kind of reasons why the customer is approaching us for this kind of solution. What we didn’t covered today was something that was very obvious, but we didn’t find time to cover, and that is how do we maintain the current set of priorities when we make that transition.

For example, when you look at a bank, we only cover the fact of how are we going to roll out this new video application? Of course, [cable stasis], how do we maintain the criticality of all the existing applications? How do we interface with the existing routers, with the existing MPLS or traditional deployments as we are making the migration? After the migration, what kind of policies ensure that the critical applications are up and running in a manner that is either equal to or better than it was before? That is, without solving that piece of the problem, we do not have a conversation to begin with.

We didn’t spend time on that today, but rest assured those are the kind of things we have to address to even attempt to solve the problem, especially in the Fortune 500 to Fortune 2000 league of companies. With that, I want to say that we are going to continue our tradition of focusing our webinars on actual deployments and actual user stories, and also bringing more of our partners into these discussions so that we can talk about some of our joint deployments. In the next 30 days, we’re going to do a webinar with Verizon where we will talk about our success stories across multiple verticals we are working with, together with Verizon.

Also, how we have operationalized something as new as SD-WAN in the period of months where a typical time for a carrier to operationalize new technology is typically in the 9 to 18-month timeframe. We were able to do it in about 3 to 6 months. Even before operationalizing it, we were able to onboard a whole bunch of customers, so we’re going to talk about stories with Verizon. With Zscaler, the story is going to be completely around how two independent solutions are really completely changing the architecture and customer network.

As you know, Zscaler takes care of all the Layer 4 to 7 security, so it provides the entire solution in the cloud. Viptela completely handles the transport connection pieces of the customer network. If you look at networking security, how are these two solutions completely integrated today, we have joint policies that that can actually integrate and deploy into a customer network today. We have multiple deployments in extremely large environments, and that’s what we’re going to talk about in our joint webinar with Zscaler in a month’s time.

Look out for that email. I’ll be sending it soon. With that, I want to turn it over to you for some questions. I know we’ve gone a couple of minutes over, so if you have any questions, I’d like to take it up. I see a few coming up, so the first one is for you, David. On the segmentation, the question of segmentation with regards to the manufacturer, how is Viptela able to maintain segmentation across the multiple transports in the network, or is the segmentation restricted to only some transports?

David: The segmentation approach is built upon the foundational principle of our solution, which is abstraction. The first thing that Viptela technology does is it abstracts an existing transport. We can abstract the specific and unique characteristics of those transports and elevate those into an entire fabric level. The segmentation is something that is available in an MPLS network and had been available in the MPLS network for the past decade and a half. We are abstracting the segmentation and we are making the segmentation available to the types of transport, such as broadband or 4G LTE, that that segmentation is not inherently built into those.

It could be deployed through an IPSec VPN running separately over those transfers, but the transfers themselves have no characteristics of segmentation. What we’re doing is we’re stepping away from segmentation principles that are bound to specific technology and elevating that into an entire fabric level. As you deploy diverse transports, you are able to configure, basically, policies through Viptela V-Manage system, which is a single pane of glass for all the managements and operational troubleshooting tasks that you can perform on the Viptela fabric.

Through the V-Manage policies you can define segmentation rules that would allow you to segment your traffic irrespective of which one of the transports that that traffic is set to cross. In case of the manufacturer, that’s how we were able to accommodate dozens of virtual segments in a completely isolated fashion across the diverse set of transports. Now, the communication between the segments, you may want to allow the committee case in between the segments in a controlled fashion. Sometimes, you want the isolation to just be maintained and be sort of complete isolations.

Sometimes, you want to make sure that the isolation is only partial, so you want to make sure that one segment is able to go to the other segment, yet pass through a stateful inspection device. We have a couple of ways we can accommodate that, either for extranet methodology or some other means. That’s a deeper topic that we can dive in. If somebody has a specific interest about segmentation and how we can accommodate segmentation within the network, or segmentation for M&As or segmentation for business partner connectivity, we would love to, if you would reach out to us, we will talk more details how that is possible.

It’s not an easy task to achieve, because there are some sort of competitions that are required by, especially interacting with existing environment, with existing brown fields, but it’s absolutely something that we’ve been doing for quite some time now.

Lloyd: The next question is around security and concerns around security. To read the question, “Trading out MPLS private circuits for broadband DIA circuits changes the attack surface. SD-WAN devices do not provide the best of read from a firewall perspective. What is being done to improve Viptela’s firewall capabilities, something that’s similar to a checkpoint?” Essentially, how do we handle security?

David: Yeah, security is very fundamental to our solution. It’s an excellent question, thank you for the question. Security is something which we hold very dear and it’s basically across the entire stack of our solution. We employ several methodologies within our product that would make sure that you are not increasing an attack surface on your environment even when you are connecting directly into broadband circuits without placing any firewalls in front of us. In fact, we do not advocate placing a firewall in front of the VH router when it’s connected directly to the broadband or 4G LTE circuits, which are non-private circuits.

Now, why are we so bullish about this? The way that we designed our product, the product is employing a zero-trust philosophy. The zero-trust philosophy means that everything is denied, basically. Nothing is allowed to communicate to the device unless it’s been, the device, basically, over every element of the system, it’s not just the VH routers themselves, but the same philosophy applies to the controllers and the management system. The system is trusting nobody to begin with, so when you put it in, turn on the power and plug it in to the circuit, those elements deny everything; every single piece of traffic that is targeted at them.

Now, as they start the bring-up process, and they start discovering the rest of the infrastructure elements, they start allowing the responses to the requests that they’re sending out to be allowed inside to reach the device. As the VH router, for example, discovers its controllers and discovers its management system, it’s going to dynamically allow the return traffic from those elements to come back to the VH router. The VH router, if you’re trying to launch a denial of service attack against that device from an unauthorized source, that basically will be prevented, right? There’s no way that you can do that.

The traffic that is destined to the control plane of the device, if somebody is trying to flood the device with control point traffic, we have mechanisms for control point policing that would prevent that traffic from reaching the device control plane and compromising the integrity of the device. It is not a checkpoint firewall, as you have mentioned, but the device provides security for making sure that the device itself is secure when it’s connecting to an unsecure transport.

After the devices have been brought up, you can of course deploy a multitude of security policies, such as blocking traffic, allowing traffic based on application signature with deep packet inspections or just based on 5,6 topo-matching. Those are all policy-level decisions for the traffic that goes over the secure channels, over the secure fabric. The fabric itself is zero-trust. All of the elements are trusted. Every conversation within the two devices in the system is security. If the certificate authenticated and predicated on a mutual trust between devices through the certificate of trust. Very significant thought has gone to make sure that the denial of service attacks against the infrastructure are mitigated, that the trust that is established is secure. Quite a lot of hoops into that.

Lloyd: Yes. Also, to complete the checkpoint angle into this, for anything that’s internet-bound, that we either support existing security devices. We directly interface into those devices, whether that’s Zscaler or Palo Alto network devices. And, we have the ability to set centralized policy on our engine to direct the right traffic to those devices. For example, you can send a certain set of social media traffic to go through, for example, an IPS IDS engine, a firewall engine, a UTM engine, before it either goes in and out of the network. You can set all this policy centrally and then monitor it from the central dashboard of your security provider, which could be Zscaler or others.

Moving on to the next question, “Has your segmentation solution been independently tested to prove it is robust?”

David: Yeah, absolutely. Yeah, I see quite a lot of interest in security and segmentation in here. Yes, we take great pride in doing pen testing for our features and for our technology. Segmentation is definitely one of those things that we subject to the pen testing. It’s been proven and deployed in quite a few environments now.

Lloyd: For example, it’s also the mechanism in which we achieve PCI compliance, so when we are talking about banks, retailers that want to isolate regulated portions of their network, they achieve that using segmentation. POS transactions of a retailer or any financial transactions within a bank isolated using segmentation, and these are being tested by them and by independent parties and we are compliant. The next question is related. Let me just pull this up here. The next question is, “How does Viptela achieve topology awareness if we are transport-agnostic?”

David: The Viptela solution is actually related to the segmentation. Think about if you have your virtual fabric and if you are able to segment your virtual fabric into multiple workshop segments, what Viptela solutions does is it allows you to deploy through policies that are configured in our main, in a V-Manage system. It allows you to deploy different topologists, making sure that each one of the segments that you have created can have its own topology.

When you create a segment that would carry, for example, your unified communications traffic, and you want that unified communications traffic to be isolated and at the same time you want them to be following a full mesh because you know that you’re going to have people doing voice and video calls from site to site, so you may want to have that segment operate as a full mesh environment. At the same time, you can have traffic which has compliancy requirements. That traffic, you may want to swing it through either main data center for firewall inspection, or the regional data center where the firewall service can be inserted and for that traffic to be inspected.

For that segment, for that VPN, if you want to think about that this way, you can deploy either hub-and-spoke or regional mesh, regional hub-and-spoke or regional mesh topology. Think about taking your environment, which is, even though it’s virtualized across any transport, it’s still a single fabric. Allowing you to carve VPNs in that environment, and those VPNs can be used for either purposes of isolation, or those VPNs can be used for purposes of establishing a topology which is friendly to an application that you are trying to run on top of this topology.

Again, you want to make sure that things like application of routing, we’ll make sure that the traffic for that application is rerouted around a brownout. When you have multiple topologists for application of your topology, then you make sure that not only is it best performing, but it’s also the shortest path, or maybe the path that is compliant with what you’re trying to do. The application awareness and segmentation are, many times, a walk together.

Lloyd: The next question, and this is the last question we’ll answer. “What are some of the challenges, if any, you experience during the rollout of the three scenarios?” This is a very good question. I alluded to some of these challenges earlier when I was talking about the bank deployment. Those challenges were the fact that in that particular case, we had to move from a [developed] DLS network to MPLS broadbands and LTE, and ensure that during that transition, all the existing application SLAs were being met.

In addition to that, we had to introduce new applications into the same environment. A lot of that testing was related to making sure that, ensuring the challenges. The challenges were essentially how do the policies map correctly from the old to the new. Oddly enough, we’ve done this many times over, migrating from traditional environments, so we are able to, essentially, templatize most of these things and don’t face a concern there.

On another area, I think the big challenge we face is the diversity of deployment. There is no cookie-cutter approach to this from a deployment perspective, unless it’s in the same vertical. For example, multi-cost is a big requirement for manufacturing verticals, and they are globally distributed, and they have sophisticated policy requirements across the segments, etc. Whereas in healthcare, the requirements are more around how do you not replace the existing network, but how do you augment the network?

In retail and banks, we are directly replacing existing networks. In healthcare, the risk-averse and this is so high that they want to be able to augment for some time, see that it works, and then make the transition. That’s the challenge we face on the healthcare side. The challenge really is to make sure that everything completely interoperates with existing Cisco HP and other devices on the network while the transition happens.

The other element of transitions are all very characteristic to deployment. In case of retailers that move from MPLS to all broadband, the initial challenge is how will VOIP traffic be handled? The concern is mainly around latency. Again, in those cases, we make sure that when people are concerned about the SLA of some applications, we keep MPLS and broadband up for some time. We build the overlay over both, and using our dashboard, you can actually see end-to-end latencies of each and every circuit in your network. For example, we currently have a deployment which is global with multiple sites in Shanghai and Hong Kong talking to the US. The latency, when we looked at the dashboard yesterday was 210 millisecond for broadband and 200 millisecond for MPLS.

Unless a customer sees something like that, they are not willing to take the leap of faith that VOIP traffic and other interactive traffic, which was going on MPLS, can go on broadband. In those cases, we have to make sure that there’s a migration interim step. Those are a few challenges. I’m happy to dive more into challenges for each of those verticals, if you send me an email at Lloyd@Viptela.com.

With that, I think we are at the end of our time. We wanted to wrap up by 9:40. It’s about 9:45 here locally. I really want to thank you for attending this webinar, and I look forward to having you for future webinars. Please register for the Zscaler webinar. We’ll be sending out that email soon, and the Verizon webinar you can register from our site directly. Thank you so much. Bye.

David: Thank you very much.

Watch Now