CTO PoV: Enterprise Networks (Part 1)

Rapidly changing enterprise application requirements, the cloud, and mobile computing are placing stress on traditional wide area networks (WANs). Enterprises are being challenged to rethink network architectures to meet present and future business requirements.

Khalid Raza, CTO and Co-Founder at Viptela, shares his Point of View why current WAN infrastructures are not designed to support new enterprise traffic patterns, and how emerging approaches can help organizations adapt to these changes.

In this webinar, we will cover:

  • Key applications molding enterprise network requirements
  • Impact on current WAN architectures & shift in present and future business needs
  • How enterprise network teams and service providers can adapt the traditional WAN to support new traffic patterns

Download slides here

Presenter

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.

Transcript

Khalid: Good morning, everybody. Welcome to the webinar on point of view SD-WAN and the architectural benefits. My name is Khalid Raza. I am the CTO and co-founder of Viptela. With me is [Mussadic Faradi], and I’ll have Mussadic introduce himself.

Mussadic: Hello, everyone. This is Mussadic Faradi. I’m the product manager at Viptela. Today we are having this first part of the two part series and webcast. This is about enterprise network architectures. The second part of the webcast will be on March 16. If you have any questions during the presentation, please put the question in the Q&A box and we’ll try to address them at the end of the presentation.

So I would like to start asking Khalid a question. What were your starting assumptions and Viptela approach?

Khalid: So we started Viptela around 2012, but the thought process of this architecture started brewing around 2011. So the buzz words around those days and still continue to be in the marketplace is how do I utilize the commodity space that is created for Cloud. The root of all of these, if you look at it, it’s about connecting application to the user regardless of location.

As the early networks were built, your locations were predictable. So you’re building networks where the data was hosted, service to data centers, your exits were created around DMZs, which at times were near the data center, so you’re moving from an environment which was centered around data centers, to an environment which is going to get distributed into Cloud. So sort of like centers of data. And from that perspective we looked at the complexity and the innovation that needed to be in the wide area space.

So you needed a flexibility, ubiquitous access [unintelligible 0:02:06] connectivity. So those were our starting assumptions. Then we looked at the technologies that were available. So if you look at any traditional [unintelligible 0:02:13] environment, the technologies available was MPLS was dominantly [interrupted] by the enterprise, and in a lot of cases IPsec was used as a backup. Either they were dual MPLS circuits. IPsec was a tertiary for a complete backup.

So the technologies that we looked at that were available to us was IPsec and MPLS. So, but the question is – so a little bit about my background working with the large carriers and large enterprise. MPLS got a very serious adoption and very quickly got adopted. So people were willing to outsource their control plane to the carrier in exchange for the moving complexity of building these complex wide area networks. So the biggest driver for MPSL was you have connectivity and you can bring any on Net site into this infrastructure and the driver was A) ubiquitous access, your traffic pattern mandated that you had a lot of site to site data transfer. It was over a secure network. Your voiceover IP was a driver. Video was a driver. In the case of manufacturing and healthcare, your imaging applications was a big driver, your big manufacturing fight was a big driver.

So enterprise was attracted to MPLS for that ubiquitous access and no need for complexity inside of their network, but they handed over their control planes. So those were our starting assumptions looking at the problem and how do you remove the complexity and making the control plane very flexibility that it can be inside the MPLS carrier, the [unintelligible 0:03:54] service provider. If a larger enterprise wanted a piece of that control plane, they can move that out. So that was our starting assumption that were needed in the network.

Mussadic: What were your thoughts on the software defined networking?

Khalid: So at Viptela we looked at SDN from a slightly different angle. So if you look at what was the beauty of Internet, the beauty of Internet was the PCPIP created a complete abstraction layer which gave you an opportunity to innovate independently at each layer. So that’s why Internet has survived the speed and magnitude to scale, diversity of application. So all you needed to do any kind of new innovation at each layer, you had to have a backward compatibility hook.

Just as similarly we looked at this and said let’s look at this whole problem holistically and each component would have its own independent innovation. So first of all we looked at orchestration layers. The reason is, when we were building networks, we were building networks with defined hardware points, they were part of a defined location, pathology, along comes Cloud. You are now extending any element of your network to any arbitrary point, and those pieces require a very efficient orchestration of Cloud.

Because you might hosting summit, as your summit, Amazon summit, Google Cloud. So that flexibility of moving at the orchestration layer was the first piece of it. So there are a lot of vendors out there that are already doing it. You have tools out there like open stack, in open stack the [unintelligible 0:05:38] doing that orchestration layer. You have public Cloud sites like I think ADW Cloud Foundation. We have our own tools that you can orchestrate across Clouds.

So that was the orchestration layer you can continue to innovate and continue to use tools out there that are available to you. The second piece was the management layer. So from management perspective we went into management being management, monitoring, provisioning and trouble shooting. So from monitoring perspective, MPLS links were on the higher engineer, the cost per bit was a little high, so you wanted the visibility but in our cases you don’t want to utilize your resources or an MPLS link to get intact, how fast, high speed real time visibility.

So for monitoring purposes, people were [unintelligible 0:06:33] band width utilizations, and as networks are becoming more intelligent, you want more of it. You want for more analytics, you need to understand who’s utilizing more applications, you need to understand who’s going what application is where in the Cloud. So you are getting more deeper into the visibility of the application so you don’t need to collect more data.

And one of the interesting aspects of if you start using commodity Internet as an alternative circuit, as a second path to your existing MPLS, you can get a lot more real time data collected for it, and then you can do a lot more analytics, make some intelligent decision, make some capacity planning provisioning. The next piece that comes in is provisioning.

One of the beauties of SDN in my mind was you have a center of policy orchestration point, and then that policy in another segment becomes reusable. So regardless of my location, if that is a retail customer that I have, if they have an ATM, regardless of where the ATM is, that policy [unintelligible 0:07:39] throughout. So that’s a reusable policy. And the benefit of that is you have a vendor verification of your regular [unintelligible 0:07:47] compliance. So you’re saying I can verify to a central point that my policy is consistent.

So it gives a little better feel of security. You can monitor your compliance [unintelligible 0:08:00] application systems very well. [Unintelligible] troubleshooting. So we looked at it and says [Net Ops] needs to become more proactive. If you look at Net Ops today, it is more reactive. For example, you can profile your applications. You have a certain profile. You say I am – is it time to increase my bandwidth? Because you want your users to be complaining that my performance is going south, the number of users have increased in a location.

So this application is utilization this much amount of bandwidth. So you can do some interesting capacity planning issue. Next thing is, if you start to notice that at a certain site there are users who are consuming way too much amount of bandwidth are going to some sites which have to be quarantined, you have that ability, collecting data in real time, getting more visibility and becoming a lot more proactive. So those for us was the management layer.

Then comes one of the main things the MPLS came to solve, is the control plane and data plane separation. So if we look at the control plane, look at the control plane and say, what has caused rigidity? The biggest rigidity was caused by the control plane. Why? Because all the routing algorithms are very distributed. So if I wanted to make a change, if I wanted to alter any policy, and I wanted to implement my policy goals, I had to come between the adjacency of those routing elements. So your policy and configuration was very distributed and every element that was communicating to each other at that policy has to be implemented in the routing plane. So any ACL I wanted to do, any firewalling or any service chaining I want to do, I had to come in between on those distributed elements.

So, and then control plane, was decided how to build your data plane, but that was local to the box. So one of the bad things about an SDN is about network should not connect with any element without a policy. So your policy puts the network elements in place before it actually connects. So those were primary assumption, then transport independent comes in. Then flexibility of the control [unintelligible 0:10:16] movement comes in because the policy interface has to be defined into any, every element of the network before the network connected.

Those were things that were very obvious to us. And then the application drivers and the customers asking for those application drivers. And we’ll talk about it a little bit more on that.

Mussadic: So what are the key applications that are molding enterprise network requirements?

Khalid: So the key applications that we heard from our enterprise customers, so we started to do this discovery around 2011, ’12, we were consulting to a major financial. [Ahmed 0:11:00] and I were paying our bills to consulting some major financial company. One of the interesting conversation were in that, the comment was made, I wanted to do site to site video. And the bandwidth requirements were on the higher end. And how do I do a site to site with your very interesting example for the brand of the future, and any location does not have a mortgage broker, I should be able to bring that mortgage broker from any close proximity and start to provide the service.

Because I don’t want that customer to walk out of my environment. So a lot of site to site high bandwidth connections. With real time voice, real time video. Healthcare. There is a lot of imaging transfer that happen. So those guys are very sensitive to latency. So again, [unintelligible 0:11:50] should be able to build on a per segment [unintelligible] topology based on my policies. The only network that was giving me that freedom was MPLS. But I want that similarity over any kind of transport.

So I should have the freedom to build that transport so traffic engineering, if I feel that my network is having some attacks, some point in my network, I should be able to quickly divert my topology and take that to a service chain point. Then Cloud. So for different people Cloud has different feeling around this 2011, ’12, I think [unintelligible 0:12:31] we looked at the aspect of [unintelligible] we looked at the aspect of infrastructure as a service, [unintelligible], so I’ll go over those discussions a little bit more.

But let me come back to the video. So one of the things that from video, where the branch of the future was we were talking to our financial customer who we were consulting, they said, look, I do not want this video traffic to [unintelligible 0:12:57] to any point instead of a connection between those two sites. It should go direct. The way my MPLS goes. So all the transport should get their direction is there is an IP connectivity between them.

So your IP lately becomes a transport. So if I [unintelligible 0:13:14] to any gateway point, the biggest issue with that is people always point out, is latency. Latency is one of the issues. [Unintelligible] an issue for capacity planning. So this financial customer we were talking to, they had about 5,000 sites. 5,000 branches just to imagine 8 or 10 percent of them are having a video conference or a video conversation. You’ve just unnecessarily burdened your [unintelligible] just because you’ve put a gateway to take your traffic through those points.

Again, the beauty of MPLS was ubiquitous data plane. And for us that was [unintelligible 0:13:48]. Ubiquitous data plane over an untrusted third party network, which is Internet. So it should be seamless segmented topology, and all they wanted was only voice, video should go peer to peer? But the data should be how they spoke? So [unintelligible 0:14:06] application profile then comes in. So that was obvious to us that people wanted a lot more flexibility than what they had today. Then in one of the biggest [unintelligible 0:14:18] is a retail customer.

There again, they had a [unintelligible 0:14:24] which was on video surveillance. So when you have video surveillance [unintelligible] lost and found or [unintelligible] in one of the sites in San Jose, they never wanted their San Jose site video to be going to everybody in every location. They wanted to send that video to a 25 mile radius, so [unintelligible] created a match, we’ve created that segment that only those 25 mile radius branches got the identity of the individual who was involved in that event.

So what was obvious to us is the way we’ve built networks, we’ve defined policies. Policies are going to get very, very dynamic. And people would like to change them from a central policy point and as quickly to handle their network requirements or policy requirements, what is needed. The other interesting piece was, the IT is consistently under pressure from line of business, that hey, I am doing a lot more work in the public sphere, I want to have my team start to utilize this new tool. But IT is under pressure [unintelligible 0:15:36] this new company that you’re bringing in, this new tool you’re bringing, are they following compliance? Right?

So if you’re an IT guy, you want them to follow compliance. But you want only that group of people who’ve taken the permission to use that particular application in the cloud. So again, through segmented topology, segmented lockdown topology, you should be able to give them their freedom, that okay, until the compliance is happening, I’m going to [unintelligible 0:16:03] I’ll verify if this application passes all our checks, compliance checks, or this [unintelligible] application that you’ve taken from the Cloud.

Once that is done, I can give you a DIA. But that’s just a one click, all your user will [unintelligible 0:16:18] you want them to follow compliance but you want only [sounds drops out]…so the traffic engineer packs, in a lot of cases I want [unintelligible] traffic to certain points. If I want to do a [unintelligible] certain segments in my network should not be permitted to go directly. And a lot of this is done on a common circuit, so I can have Internet, MPLS, and LTE for [unintelligible] reasons, but then topology should remain the same consistently over any kind of network.

Then comes the application profiling. Traditionally, how we’ve used the load balance thing, ECMP path, usually on IT destination basis. Now if you have through DPI, you have visibility, you want to move a certain SLA based application on a certain path, you can say, okay, my SLA requirements for voice is X. I’m okay if there is a high end data transfer going on. I can use Internet. But as long as the [unintelligible 0:17:30] is available, I want to use voice to use MPLS. I can go deeper and say based on the requirements that I’m getting on that circuit, that circuit, if it fulfills my requirement, in certain cases if my MPLS is having issues, I should seamlessly move that connection to any circuit I want to.

So I should have that freedom. Now comes the other very big component for us, the driver for SD-WAN or NR implementation, [unintelligible] Cloud. So from Cloud perspective, we looked at Cloud as three elements. You have software as a service, you have infrastructure as a service, you have platform as a service. So if you look at it traditionally, from software as a service point of view, your software service provider, if you’re using Amazon, or if you’re using Office 365 or you’re using sales force, those guys are usually very, very careful about security, compliance, and abiding by all the rules of compliance.

When you move into infrastructure as a service, you want to move your regulatory environment into the infrastructure. Although the [unintelligible 0:18:44] Amazon, those guys provide that layer of security. But in a lot of cases, in a compliance environment, you want that part of your network to be accessible into the infrastructure.

But traditionally a lot of times they [unintelligible 0:18:59] an extension to my data center. If you look at it again, this extension to your data center, you would trombone your traffic though your data center again, introduce latency and performance. Very simple example. If I have taken infrastructure at an Amazon facility in Portland and I’m in San Jose, if I’m taking my traffic through Dallas, I’m introducing latency.

Now if I’m able to simply put my network elements, orchestrate them in the Cloud, and pass that traffic perfectly between the locations to avoid that latency, so infrastructure as a service, I was talking to one of our customers that provides services through the Amazon cloud, it says in certain cases I want my – to simply say that everything that is out there is part of my network and all the compliance rule that have been enforced on me. Then platform as a service [unintelligible 0:20:02] there is so much work that is done in dot net infrastructure [unintelligible] there’s a lot of development that happens.

Your application developers a lot of times are not security guys. But they are putting that application in the Cloud. During [unintelligible] test you want certain branch segments to go there, but you as a network guy can safely say, look, it’s in the public Cloud, I can guarantee that my compliance has been fulfilled. When [unintelligible 0:20:26] segment comes in, until my security application development guys have done all the security checks, my infrastructure will continue to protect this and provide compliance to those pieces of the network.

Mussadic: Hello. So we’re what doing [unintelligible 0:20:48] we want to understand your network environment and we want to know if your video and Cloud application are critical for your network. So you can go to the tab that says [unintelligible 0:20:59] to that question. So Khalid, what impact on current WAN architectures and shift in [unintelligible] happening because of this shift?

Khalid: So if you look at this, people for redundancy in a lot of cases had a primary MPLS [unintelligible 0:21:17] a second MPLS, and they were able to distribute their traffic across that. Internet, in a lot of cases, was used as a complete backup. And there were reasons to it. If I look at the current way the MPLS comes into the network, MPLS is considered as a trusted, secure environment, and they usually end up in your production zones. So the traffic is coming in your production zone, you have these MPLS routes in your network inside data center, you have optimal return paths for it.

Usually Internet does not come into those stressor zones, they end up in the DMZ. When the Internet connection, which are [unintelligible 0:21:53] they end up in the DMZs, what happens then in the back end, then you have complex routing topologies to figure out. You have to figure out how you do load sharing these different segmented environments. So it starts to become a little complex, especially around policy. And a lot of times if you have those alternate circuits, I was just in a meeting with a customer. They were actually raising that issue, that I’m paying a lot of money for my Internet bandwidth but it’s being utilized as a backup. So I want to use a complete, have the freedom and flexibility to use it the way I want to use it, use all of my circuits that are available to me. So now again if the control plane policy is centralized, you would be able to decide that seamlessly, that the control plane policy is there, you decide if it’s the MPLS is the best pack [unintelligible 0:22:46] application. You can put it rather than getting into center complex back end routing [unintelligible].

So another thing is, again, your line of business guy would get flexibility of saying I can break out anywhere, I can, in certain cases your IT guys can say, what if I put these performance [unintelligible 0:23:12] in certain locations where I can hop you off to the Cloud provider. You can go through a direct connect with an MPLS provider. So you again are getting into the space where you will get that flexibility and be able to connect the way you would like to connect, not the way you’re forced to connect.

So again, I have repeated this thing a few times. Connecting network is a policy decision, it should not be a topology decision.

Mussadic: Thanks, Khalid. So a couple of other questions that we have seen in the Q&A section. One question is, without MPLS how do you guarantee efficiency in the wide area network?

Khalid: So I’m not saying without MPLS. I think MPLS is going to be there as a transport. So one of the transports. So your MPLS providers are there to stay. I have a little take how I feel networks can get [unintelligible 0:24:10] which I’ll talk in the end a little bit. But again, MPLS, you can use MPLS as one of the circuits, because one of our partners, Verizon, actually has provided services to a very large financial customer of ours and they’re using MPLS as – and they’re augmenting their MPLS offerings with other kinds of transport, for broadband [unintelligible 0:24:35].

So they’re deploying it for agility reasons. If I, I don’t want my customers to be waiting for a period of time until I have that service there, so you can break up any type of circuit and provide connectivity, so get the business going. I think MPLS will stay there as one of the transports, and you have the freedom to choose any other transport. You can offload some of your traffic on the MPLS, some on the Internet, based on your requirements of the line of business and based on the strict reasons of quality of service, performance [unintelligible 0:25:10].

We feel that these transports, they [unintelligible 0:25:14] transport, and that transport will stay and will be used for providing in certain cases guaranteed [unintelligible] if it’s needed by the application.

Mussadic: One more question. How enterprise and network teams and service providers can adapt the tradition WAN to support new traffic patterns?

Khalid: So to looking at it from slightly different lenses, so how is MPLS providers evolving, like very simple case. We were working in the early days with one of our customers when Hurricane Sandy hit. So what happened is, in certain cases you’d be surprised at carriers lost my circuits [unintelligible 0:26:01] the same, and in that environment people wanted to bring up their sites as quickly as possible. So [unintelligible] became a very important factor of it. Again, your primary provider can use any broadband circuit that’s available to them to create a complete path diversity.

So diversity of the path, yet able to provide that ubiquitous connectivity, if that is an IP circuit between those elements, so that [unintelligible 0:26:29] just imagine, I have sites that are purely MPLS. I’m looking into bringing broadband there, and I have certain locations which I’ve brought up very quickly for it, which expand my service in those locations, over broadband. I should have the capability to connect site to site MPLS to broadband through IP transport, making sure my compliance and security is followed.

So flexibility of any connectivity should not be hampered by what you have over there, what you can get at a location. You can have [unintelligible 0:27:04] you can have MPLS, you can have broadband, as long as there is an IP path between them. And if you look at from [unintelligible] perspective, the ability of SD-WAN to use any transport to have a variety of options used on a backup basis is what an operator desires, that if I have lost a circuit in a hurricane situation, I should be able to bring up anything that provides me connectivity and yet be able to connect to my network seamlessly as it was connecting.

And the other piece of its, the intelligent LSA based routing. I should be able to decide what circuit is available, what capacity is available, what performance is available, and what is the requirement for my application and to get the most optimal path in certain cases, most customizable path. So I should have a complete flexibility in this space. I don’t hear mention that I think MPLS networks are not going to disappear. But I have a slight view on this, which is I think the MPLS networks will transform into more efficient overlays.

But they will become a fast lane private led network for the larger good. So their infrastructure is there. The availability is there. If you start to strike some of this [unintelligible 0:28:29] information from those [PE] devices, you have a complete build out infrastructure that can give you guaranteed SLA across that, and most of these MPLS providers also have those connections into direct connect. So you have Internet circuits which gives you optimal performance. You can MPLS over, built overload. When P.E. starts to become more stateless, and it also moves into the SDN [unintelligible 0:28:56] model, then you can simply connect site to site where MPLS is a guaranteed service, Internet is the best effort, and there are intelligent ways to utilize both circuits in the most optimal fashion.

I’ll stop here and open up for questions.

Mussadic: So we have another question regarding with the hybrid SD-WAN deployments [unintelligible 0:29:27] evolved to answer the security concerns.

Khalid: So actually, you’re leading right into my next webinar, but the digitization is actually going to put even more interesting pressure on the security concern. So if break this security down from different angles, I’m just going to address this briefly, so from a security perspective, you have data transit security from the SD-WAN perspective. So how do you protect your data integrity, confidentiality, non repudiation, and authentication?

That all has to be taken care of from a network point of view. The second is how do you protect your resources coming in, how do you have visibility into application, how you feel that that the application is not behaving a certain way as expected. You will be able to move those flows around. So having deeper visibility, deeper understanding, protecting your resources, protecting your devices and protecting data in transit from transport perspective, is what security is about.

And actually the next webinar that we have on the 16th is about the impact of digitization on security of networks.

Mussadic: One more question. Is the V-Edge the only device on a remote site, basically replacing the existing WAN device in a site?

Khalid: So we have multiple flavors of this. And absolutely V-Edge device is the only device. We are a replacement of a router, with much more centralized control. So we have multiple flavors of it. We have a 10 gig, 100 Meg, and we have a virtual software as well. So you can, based on your requirements, you can use any of those available flavors. But yes, V-Edge is a full fledge intelligent router. It talks BGP, OSPF on the local LAN. In fact, we are the, we looked at these issues and during transitions it becomes so critical. As I’d mentioned, a healthcare customer, in a lot of cases when you ask your healthcare customer, say I have a gateway or there is a gateway during transition from your full meshed MPLS to this hybrid WAN, can you go through these gateways.

And the answer was in the healthcare case, was a very, very resounding no. Because I have my medical practitioners who are complaining about a 19 millisecond latency. You’re telling me to go through a gateway? So from our perspective it was very obvious that these customers, manufacturing healthcare, will not accept any latency introduced artificially for your architecture to fulfill that requirement. So then you come into an interesting scenario if you becomes that Edge device building Edge SD-WAN. But here it’s [unintelligible 0:32:24] to a site, which is also doing traditional MPLS.

So there is an overlay, underlay element there. Your system has to be so smart to understand where you can recreate routing loops, how to understand that that this router has traversed MPLS, and [unintelligible 0:32:41] LAN taking it into overlay, how do you take care of [unintelligible] to understand if I’ve received an OSPF route from the data center vs. a local site, you should have the understanding what’s the origin of the route.

So we looked at these problems and says, it’s a problem that needs to be understood, that what is the origin of that prefix, how intelligent [unintelligible 0:33:01] can route around it, I should expect for a good period of time there will be an underlay, overlay interaction, and that should transition, should happen, all transitions should happen seamlessly.

And if you look [Repel 0:33:12] architecture, again, I’ve heard people make statements that routing is dead. If routing is dead, Internet should be dead. You need to understand how these systems will work intelligently and there is a Brownfield environment, there has to be, all those complexities have to be well understood to have that very classic interaction between these traditional routed models of MPLS and hybrid SD-WAN models of routing and intelligent application systems.

Mussadic: So there’s another question. How would you describe Viptela solutions compared to other solutions that are deployed or in the market?

Khalid: So we, I’m, usually I don’t do vendor criticism. I’ll tell you a little bit more about our approach. So there are multiple approaches people are taking. From our perspective, the approach is Cloud is not just SAS. So I’ll give an optimal services into SAS. People, the reason people went to MPLS, as I much earlier mentioned, is the ubiquitous data plane, because that’s what my applications were asking for. So if I wanted put an optimal service SAS, yes, we have concepts of performance hubs, as I mentioned. You can put them out there.

But there’s a lot more to it. Because I want most dynamic site to site connectivity. I want segmentation inside of a network with a single circuit. A very simple use case, I had mentioned earlier that I wanted to have site to site connectivity. And that site to site connectivity should be only permitted between these two segments. Partner enablement and connectivity. Again, we were working with a very big manufacturing guy. They said, look, we do not deal with all this work that is done across partners until they’ve reached a point where the project is finished. So we orchestrate their connectivity, we control their connectivity, we control only those segments that are allowed to connect. We have the visibility of the application and we give them a full [unintelligible 0:35:24] on that setup.

They have a wide list of topologies and those are the element they’ll connect. So those elements that are allowed to connect across partner, earlier they were using MPLS for the circuits. Now they are augmenting it with Internet as an alternate path. So again, you just cannot do away what customer is being utilizing and using, and with the healthcare use case, that I want these segments to go, I want these imaging applications to be shared in a full mesh. I should be able to use whatever is the best performing circuit.

Whatever I was doing earlier, do not disrupt that. Give me capability, or any kind of transport to provide any kind of connectivity. So again, the customer should have the flexibility to decide how they’re going to connect vs. you deciding how you’re going to connect because you’re placing certain elements in the network. So I think for larger enterprise environments, these things are table stakes and this is what they require, that what I want and how I want to connect, you should not change it, augment it, or give me freedom to choose, decide, with flexibility, what I want to do.

Mussadic: All right. Thank you, Khalid. This is the end of the webcast. Thank you all for joining this Web session. The second part of this series, I’ll get it for March 15. You can go to Viptela website to get additional resources. And you can also download this particular presentation [unintelligible 0:36:57]. Thank you all.

Watch Now