Good morning to those in Australia and good evening to those in other parts of the world. Welcome to the investor briefing on Megaport Virtual Edge or MVE. Today, we have presenters located in Brisbane, Sydney, the U.K., San Fran and Austin, Texas. I will just run through some housekeeping at the beginning, and the agenda for the day, and then hand over to Vincent. For those that have followed Megaport, in August 2020, we announced the upcoming release of MVE in collaboration with Cisco. On the March 31, we announced the launch of MVE, available in 11 metros with plans to extend it to 21 metros globally. Megaport and Cisco have also partnered to integrate Cisco SD-WAN Cloud Interconnect with MVE, leveraging Megaport's 740+ locations globally and 227+ cloud on-ramps.
This was followed by a partnership with Fortinet, and we have three more SD-WAN providers in the works. Today, the agenda will involve John Veizades, our VP of Engineering, running through the history of SD-WAN, the addressable market, and the major players. He will also consider some of the challenges faced by customers and the Megaport solution to reaching the cloud. Matt Simpson, our VP of Cloud, will address MVE pricing and some typical SD-WAN use cases. James McElvanna, one of our leading Solutions Architects, will then run through a demonstration of connecting a customer to SD-WAN via MVE. Finally, Rodney Foreman, our Chief Revenue Officer, will address our go-to-market and sales motions. Today's session should run for about 30 minutes and will be followed by Q&A. Please send your questions via email to investor@megaport.com. These can be sent through at any time starting now.
We are recording this webinar and will make a replay available on our website. I will now hand over to Megaport's Chief Executive Officer, Vincent English, to run through MVE in more detail.
Thank you, Steve. Good morning everybody? Thanks for joining our presentation briefing this morning on MVE. Steve just ran down through the agenda. The most important objective here is that we understand that there's been lots of questions from the community about MVE. We wanted to tackle those here in this one forum. It's not a market update or a briefing. This is specifically a product overview and an update on MVE. To that end, we'll just move to the evolution of MVE on the platform for Megaport. Just to recap, we started out in 2014, connecting data centers via our platform, Megaport at the time, connecting using ports and VXCs into public cloud providers and other MSPs.
The idea here, as we all know, is elastic, is to be able to spin up services, connecting at different speeds, different service points, and having the flexibility for the customer, for the enterprise to connect to end services. Over time, that evolved effectively to the first of its kind for Network as a Service, where we were able to address a large global network connecting nearly today over 400 data centers physically connected in. We rolled out MCR, which is our cloud provider, which allowed connectivity between different cloud providers. We kept enhancing the platform. As we announced earlier this year, moving towards a Megaport Connected Edge where we're extending our physical footprint that we've built, the Network as a Service and the global network that we've built by allowing the capability to connect to other buildings outside of that footprint using Megaport Virtual Edge.
In terms of what is MVE, I would try to keep this, to spill this down as succinctly as possible. It's a hybrid network and compute service that hosts Network Function Virtualization on Megaport's software-defined network. As I've explained a couple of times before, what we are really doing here is we're layering over the existing physical network, other forms or other services that we can bring to the market. In this particular case, using MVE on the network element of it, we're allowing connections or point bridging from the public network or public internet to connect to Megaport's on-demand platform. To do that, to get the compute side of it, we're hosting with software services like SD-WAN providers and some of them, as mentioned on the slide, Cisco, Fortinet, VMware, and Versa. These top four account for 48% of the SD-WAN market.
SD-WAN is only one element of Network Function Virtualization that we can roll out across the MVE platform. There are other ones, but today we are focusing on SD-WAN. Looking at the Megaport Virtual Edge overview on the diagram, you can see here we are integrating connecting buildings, and the buildings can be branches in terminology used for SD-WAN providers. The branches can be actually buildings, facilities, other locations where physical hardware or customers CPEs are. They use the internet connecting to an SD-WAN provider to connect to an endpoint or branch to branch.
In this particular case, we're using the Megaport platform through our portal, which is fully integrated, connecting endpoints such as branches using an SD-WAN provider using their public internet to connect to MVE, which then connects into the nearest data center on our network, which then allows the customer to traverse our network to connect to a public service provider or in fact, to another branch on the other side of the network. It extends the reach of our platform. That's the first thing. We're leveraging the platform. We're the first ever to integrate fully with Cisco SD-WAN as the use case. It supports branch-to-branch connections, but more importantly, branch to cloud is the number one use case that we're seeing from customers today. We've built it using our own technology API built for future integrations and extension. It extends the enterprise network edge.
Again, it allows us to activate more demand network devices, and it's completely end-to-end provisioned. I'm going to hand over for the next couple of slides just to go into a little bit more of a deep dive on what exactly SD-WAN is and how does it work, and what's the problem it solves, and how does it complement what we do with Megaport. John, would you like to take it on?
Thanks, Vincent. A little bit about SD-WAN and how Megaport ended up to where it is with MVE. Can you go to the next slide, please? If you think about enterprise networks today and in the past have been very heavily reliant on MPLS technology, and that's technology that has traditionally been delivered by the incumbent telco where the enterprise may purchase many services from that incumbent telco. They purchase these services with term commitments, which have fairly costly walkaway clauses that can take a long time to set up. When you bring on a new branch office, one of the first things you do is set up your network connectivity, because that can take months to fulfill. It worked well for branch to data center connectivity, but not so well for cloud connectivity.
As a result, what happened was a few number of vendors started looking at alternatives to MPLS and came up with a terminology on technology called SD-WAN. This allowed enterprise customers to use their local internet connection to move enterprise-grade traffic over that connection. In fact, many of those connections were as good or better than the MPLS networks they were moving from. The Internet got very good over the years that the telcos have been delivering it, and suddenly became good enough for enterprises to use them. SD-WAN allows an enterprise to use policies to control what traffic goes over those encrypted links, and you can determine whether a specific application, like for instance, a cloud application, can go over that encrypted SD-WAN link or whether traffic like maybe YouTube goes over your traditional internet connection.
SD-WAN also allowed customers to route traffic based on link quality. You can determine whether you want to use your DSL link or your secondary LTE link based on the quality of those networks. Unfortunately, cloud is still a hard thing to do with the current SD-WAN technology. It is complex for an enterprise to set that up in cloud. It's costly. The data charges associated with cloud can be quite costly. You have to think about the applications you have in cloud and how you set up these connections for each one of those applications. The other bit is you see many, many enterprise applications moving to cloud, and as such, the current approach to SD-WAN has been very complex for enterprises to engage in.
What Megaport has done is we are taking the extension that we've had in the data center, the technology we've had in the data center, the concept of the VXC, the concept of cloud connectivity or data center to data center connectivity, and extending that out using that MVE edge so that SD-WAN technology that is sitting in that branch office connect to that edge and provide the same platform that we offer to ports in the data center to SD-WAN links that come for those branch offices. Additionally, what we've done is we've given our APIs to vendors and to our customers so that they can simplify that cloud onboarding. Many of you have seen the time it takes for a customer to onboard in the cloud, and they can do it in just a matter of a few clicks.
We wanted to extend that functionality to the SD-WAN vendors as well. We've done that using APIs to do that extension, and I'll go into that into one of those integrations in just a second. What we've also done is taken our backbone and delivering that to those SD-WAN customers. No longer do you have to use internet connectivity over long-reach distances to connect to other branches. You can now link to the MVE edge that Megaport provides and traverse our enterprise-class backbone to other locations that you may have connected to. Giving a dramatically different experience to those customers on how they get connectivity to branch to branch. That dramatic difference is really about the quality of experience. It's not good enough just to give that quality of experience. You have to help the customer get to that SD-WAN edge as quickly as possible.
As part of that, we've deployed many locations across our platform to be close to that enterprise. What I mean by close is latency close, the number of hops that you go over your internet provider to get to us is reduced. An enterprise can get to that better quality experience quicker. You can't do this without supporting a lot of the incumbent players in the SD-WAN marketplace. Let's talk a little bit about that. If you can move to the next slide, please. What we've done is we realized that we needed to go work with the leaders that enterprises are purchasing and making commitments to. One of that is we've gone and integrated to many of the SD-WAN leaders that you can see in the Gartner Magic Quadrant.
We've gone through and looked at their market share, looked at their presence and capabilities, and chosen some of those top vendors to do that integration with. I think Vincent went through and mentioned some of those, Cisco, VMware, Fortinet, Versa, and eventually some others as well. What we've done by doing that is, first of all, many of our internal customers are very excited with that proposition, so that they can take technology that they're already using, the Megaport technology and other technology they're using, the SD-WAN technology, and integrate them together in one network that they're very familiar with. Additionally, this offers us the ability to go to the tens of thousands of additional businesses that have adopted these technology features as their choice for enterprise connectivity. That gives you a sense of the type of market that is available to Megaport.
Could we go on to the next slide, please? One of those leaders is Cisco. What we've done with Cisco is fairly unique in that we've done a very deep integration with them with a console that they call vManage. vManage is their orchestration console for all their SD-WAN connections. From there, through that single pane of glass, that single management user interface, the customer can provision an MVE edge, that is that connection that is in all the regional metros that may be close to you, as well as provision the VXCs onto those cloud endpoints or even to other branch endpoints. Through that one experience, the customer can go and provision not only the technology that they're using today and the connections they're using today, but the whole Megaport platform connectivity to cloud, to other data centers and other branches.
Additionally, through that whole Cisco vManage console, they can implement traffic and policy controls through that one interface. On top of that, we've taken a lot of the technology that they've used traditionally with MCR and allow them to do that cloud-to-cloud connectivity using their SD-WAN management pane. That's a solution that we've delivered through Cisco today, that technical integration is done. The next bit we're working on is to integrate with the Cisco Price book . That means to have those MVE components available on Cisco's Global Price List and being able to have customers billed by one entity, that would be Cisco, and specifically sold by Cisco's SD-WAN specialists across the globe. Not only a technical integration, but also a billing experience integration for that end user. We believe a very compelling solution for enterprise customers. Thank you. Now I'll hand it over to Matt.
Thanks, John. Hi, everyone. I'm going to be walking you through a couple of real-world use cases for both a small and a large enterprise, and we'll also be outlining the revenue associated with those use cases. Before we do, I'm also going to do a little bit of a recap on the MVE and the pricing and how it actually works and how it's built together, just to give you a little bit of an idea of the revenue associated with that. If we walk from left to right, you've got four different MVE, medium, and large. In the small, you have two CPUs, which is the compute, and included in that is 500 Mb of internet transit. That's the internet to access the MVE from your branch location.
Medium is four CPUs with 1 Gb of transit. The large is eight vCPUs with 5 Gb of transit. What's really important is with the small, medium, and large, it supports up to 4,100 and 500 IPsec VPN connections, which is essentially branch locations. Small can actually connect up to 40 branch locations. When I go through those use cases, you'll see which sort of MVE will suit depending on the number of branch locations an enterprise might have. As I mentioned earlier, we've bundled the transit in. These prices for North America, Europe, Asia, and ANZ include the transit, and they are a little bit different because transit and the cost of transit is quite significantly different depending on the region.
In North America and Europe it's quite reasonably priced, $ 1,545, and then Asia $2,140, and then ANZ AUD 2,670 . We've also just broken out the actual MVE price so that you can actually see the difference between the MVE and the transit price there. With the transit, it is a pure pass-through. We don't mark up the transit, and we also don't provide commissions or discounts on the transit because it is a pass-through cost. In terms of best practices, we associate at least two VXCs to the metro or cloud when an MVE is spun up. When I go through those use cases, I will be providing a little bit more clarification around branch locations and endpoints versus the number of VDCs an enterprise may need in terms of connecting to some of their applications. Next slide, please.
John and Vincent mentioned the locations. There are 21 enabled today. Those 21 locations are sitting on similar infrastructure to MCR. However, our strategy on the rollout of MVE is to ensure that we get closest to the enterprise rather than closest to the cloud or the application. We've already enabled the cloud interconnect points, we now need to get closer to the enterprise. We'll continue to roll out more locations by working very closely with our SD-WAN partners that we've brought on board, and we've already got phase 2 and phase 3 locations coming through over the next 12 months. Next slide, please. Okay. The first use case, small enterprise. This enterprise has seven branch locations in L.A., and with that, they would only need a small MVE. Now that small MVE of course can house up to 40 branch locations.
As the small enterprise is building with Megaport, they can still utilize the small MVE and connect up to 40 branch locations. In this use case, it's only seven. From the MVE, you go from left to right. Up to seven branch locations doesn't mean that they need seven VXCs. They only need two VXCs, and those two VXCs are going to be primary and secondary to their cloud provider, whether it be an AWS or a Microsoft. The VXCs are connecting locally in a cloud region, within that same metro. Similar to how you've seen with our other products, up to 1 Gb is $200 and up to 10 Gb is $ 400. With that in mind, you've got $1,550 for the MVE including the 500 mega transit, and the two VXCs at $200 comes at a total of $1,950.
These are, again, our retail rates. It's not taking into account partner commissions. On to the second use case. This one's a really interesting one. This was an existing Megaport customer. What's really interesting is they had Megaports already with us, but they were actually hairpinning their traffic back to Las Vegas and Reno, as you can see on the left-hand side. This is a Fortune 500 U.S. company. They've got 1,100 branch locations all across the U.S., and they've got 40,000 employees. Those 40,000 employees across those 1,100 branches have got to access some of their databases, some of their applications running on AWS and Microsoft. They had private infrastructure in a co-location in Las Vegas and in Reno on the West Coast of the U.S.
They had Megaport with us, and they were connecting those Megaport to their cloud or their applications, which is great. They were using us. However, if you think about the spread of their branch locations and their employees, that latency or the traffic was going all the way back to Vegas and then going up to Microsoft. With MVE, they can now connect those branch locations locally. If you see on the right-hand side, you can see they don't have any East Coast presence. With MVE, they stood up those MVEs, and now those branch locations or those employees now can actually access the applications and the cloud on the East Coast.
The MVE now connects up to the East Coast cloud region. To give you a bit of an idea of the problem that they're solving, not only are they now accessing the East Coast, they're also reducing some of their latency. By avoiding hairpinning, for instance, to Dallas, their Florida sites can now reduce their latency to AWS by at least 50%. Miami drops from approximately 80 milliseconds to 40 milliseconds. Orlando, all those branch locations drop from 69 milliseconds to 30 milliseconds- 31 milliseconds, and then Miami traffic travels is almost half. It's like Orlando is 2,394 mi. Now with MVE, they're only connecting, and it's hitting 1,000 mi from those branch locations. We know that with this particular company with 1,100 branch locations, they'll need medium MVEs because those medium MVEs can host or connect up to 100 branch locations.
As you can see there, they've got VDCs to not only their ports, to their private infrastructure, but VDCs and redundant VDCs to their cloud and applications. If we look at the table off to the right-hand side, we've got four MVEs, which is one in Atlanta, Chicago, Toronto, and Seattle, the VDCs to the ports of Vegas and Reno. They've got 16 VDCs to their ports and their cloud applications on East and West Coast. The total monthly recurring revenue is just over $15,254 per month, US dollars. That is only just one customer. We're looking at, of course, bringing on many, many more. That is, I believe, oh, no, next slide. What do customers actually get? We want to just make sure everyone's very clear on what Megaport provides and what our SD-WAN partners are providing.
The customer, before they actually come to Megaport, will have an internet connection from their branch location. That's through their provider. They'll have their SD-WAN vendor selected, it's really important that we have all of the rich ecosystem SD-WAN providers out there, as John mentioned. They'll also already have purchased that router or that CPE equipment at the branch location. Megaport won't be responsible for that. They'll also bring some sort of SD-WAN license to use and run that SD-WAN service on our compute. With Cisco, of course, it's integrated, so it's just one easier step. With the other vendors, they'll just enter that, and James will be showing that later on. With Megaport, what are they getting? They're getting a platform [audio distortion] DDoS-protected internet connection at our edge, at our network edge, and they're getting that full Megaport ecosystem.
Those MVEs will hold up to 24 VDCs. That is, of course, separate to the branch location numbers that I mentioned earlier. Of course, the MVE gets access or VDCs to any destination on the Megaport network. That's it. I'll hand it over to James.
Hi, everyone. I'm James McElvanna. I'm a Solutions Architect with Megaport. I'm going to do a very quick demo today. Just jump into the portal. My plan is to show you very briefly three things. One, how quickly customers can spin up a virtual edge. Two, demonstrate how the MVE exists in both the SD-WAN vendor's platform and also in the Megaport portal. Lastly, I want to show how easy it is to build a connection from the MVE to the cloud providers. First step here is I'll go to the normal Megaport portal that our customers use on a daily basis. I'm going to select MVE. I'm going to pick a location, Atlanta. From here, I've got to select the vendor. For the purpose of this demonstration, I'm going to go with Fortinet. You can see here that I've got a couple of different options.
I'm going to pick the small. At this point, it is asking me for an application license. I have to go to the Fortinet Asset Management page and download a Fortinet license. I've already downloaded this, I will add it here. For security access purposes, I need an SSH key. You can see I'm getting the monthly charge down at the bottom. I'm going to add MVE. In the interest of time, while that's deploying, I'm going to jump into the FortiManager, which is the management console for Fortinet. You can see here, I've already added one earlier on this afternoon. For all intents and purposes, this is where the customers will manage this device, and it will appear just like a regular physical SD-WAN hardware appliance in the customer's management console.
All the day-to-day operations are going to be done here, access lists, quality of service. Intrusion detection, BGP. This has got the same for Cisco and VMware. I can even go in and actually configure it from the console if I wanted. Just to jump back to the portal, I'm going to show you that this is another MVE, the MVE that I was just showing there. You can see that it's already got the internet access included. There's the public IP addresses, there's the IP transit. We've got IP version six. Also worth noting that this includes the DDoS protection. Similar to the way our customers are already creating cloud connections via Megaport Cloud Routers, it's the exact same process to add a connection to AWS. I'm going to go here, click on Add Connection. I want to get a cloud connection. Pick AWS.
For speed, I'm just going to pick hosted VIF and you can see here that literally within the space of a few minutes, I've been able to build an MVE and also then build a connection, a one gig private Layer 2 high-speed connection to AWS all within the space of a couple of minutes. That's it from me.
All right. Thanks, James. That was a great demonstration and with a great product, you need an exceptional go-to-market so that we can sell it. That's what I'm going to take you through now. We've put a lot of focus on putting the right team in place to support our selling motion. We've hired a dedicated team of sellers and solution architects to be trusted advisors to our partners that are on the SD-WAN side with Cisco, VMware, Fortinet, and others soon.
We are enabling those salespeople and have started the sales enablement process well before GA and continue to enable the sellers in the field, and providing them sales playbooks and other collateral that I will talk about in a moment so that they are fully enabled to sell our product across the industry and utilize many of the use cases, some of which Matt took you through, so that they understand what the target customer looks like, what their value proposition is, so that they can execute, identify opportunities, and go through the sales cycle as quickly as possible. We are targeting indirect and direct sales, so we are targeting the market using the SD-WAN resellers, distributors, and service providers in an indirect or channel selling motion.
Also we're supporting their direct sales teams, targeting specific industries that fit the profile of the best SD-WAN customer that can utilize and get value from MVE. We are on the Cisco Global Price List and also on the Cisco Commerce Workspace. This is significant because this is how the Cisco sellers get paid and how their partners get paid and obtain benefits from Cisco. It's important that we're on the price list and we're in CCW. If you go to the next slide, please. We have a blended go-to-market here with both leveraging the extensive network of partners from Cisco, Fortinet, and VMware, and our direct sales teams both working in harmony to attack the market and identify opportunities. We are supporting those direct sellers with our solution architects. James is one of those that you just met that is supporting the direct sales teams.
We are making sure that Cisco, Fortinet, and VMware partners are trained, enabled, they understand our solution, and have the ability to identify opportunities to sell. That includes their entire partner ecosystem, those resellers, MSPs, GSIs and the VADs as well. We are already jointly selling Megaport and Cisco together. We are conducting joint presentations together, demos, POCs, targeting existing and potentially new customers together, working together and that joint selling is working very well so far. If you go to the next slide. We have a very good go-to-market plan that I believe is well thought out and is being executed very well to date here 50 days or so into the GA of the MVE product.
We have some very good marketing assets that the team is leveraging to sell in the way of battle cards, demos, and we've got an excellent marketing plan and a lot of marketing activities going on. We have integrated into the management consoles of the SD-WAN solutions, and customers can order through the SD-WAN providers and through Megaport, those panes of glass working together. We have Field enablement, as I said, going on with dedicated resources that are training both the channel partners and the direct sellers. We continue to revise and improve our go-to-market jointly together with those SD-WAN providers, making sure that we have a joint value prop, that we have sales playbooks, demos that apply across industry and attract some of the largest existing customers we have and new customers. Matt showed you a few examples of those.
I think we have a very thorough go-to-market action plan in place and the right selling motion to leverage both the direct and indirect sales channel to win as many opportunities as we possibly can in the market. Next. I believe that's the last slide. I'll turn it over to you, Steve. We can start the Q&A.
Thank you, Rodney. We're now going to turn to the Q&A for the session. Just a quick reminder that anybody can ask questions either via email at investor@megaport.com or alternatively using the Q&A function in Zoom. Whilst perhaps OpenExchange line up some of the questions, I thought I might start with a relatively simple one that's come in via the Q&A function. The question is: why would a customer use SD-WAN over MVE to connect branches versus just directly over the public internet? Matt or John, is this something that either of you can take?
I can take that. If you think about the regular internet, the internet is comprised of many networks connected together in an ad hoc fashion. Now, if you think about what you get when you connect two branches together using different network providers in different geographies, that end-to-end experience is really determined by the quality of those connections between those internet providers. What we've seen, I think there was a very good presentation at Cisco Live, where Cisco used their ThousandEyes product to look at the connectivity between two locations and the bandwidth that could be utilized by a customer connecting those two locations. What they discovered, that when they go to the Megaport network, the connectivity was more consistent, they got better throughput between those two locations and had a better experience when it comes to a facet called Jitter. It's a measure of network quality.
Additionally, when you're moving large workloads, the internet, the fragment of traffic that you're sending over those internet connections is limited to 1,500 bytes. When you're moving large amounts of data, that becomes a significant hurdle. On Megaport's network, you can go to larger Maximum Transmission Units, the size of those packets. It gives you better end-to-end behavior, better end-to-end bandwidth. Those are the major differences between what you get over the internet and what you get over the Megaport backbone.
Thank you, John. Operator, do we have any questions in the waiting room?
Yes. We've got Tim Plumbe coming up right now.
Hi, guys. Can you hear me?
Yes.
Yep.
Hi, it's Tim Plumbe here from UBS. Just a couple, if that's all right, from me. Thanks for walking through that presentation. Just focusing on that use case or the second use case with the Fortune 500 U.S. company. Can you give us a sense, out of that $15,254, how much of that would Megaport get net of those IP transit costs? Are there any other costs that we need to take into account when thinking about that customer?
Hi, Tim. It's Vincent here. Yeah. No, there is no other cost. The IP transit cost, which is in the schedule that you would've seen on the pricing that's included in the overall bundled price for the MVE instance. The VDCs don't have any associated cost because they're already being consumed across our existing network. There is one other additional cost. As Rodney outlined, it depends on where the sales motion comes from. Obviously, if it's a direct sale, we have our own sales team and an inherent commission cost associated with that, whereas if it goes through a third party, there's an external commission on that. That range is anywhere between 15% and 20%, excluding the IP costs.
I should also point out that there is a special revenue share arrangement between ourselves and Cisco due to the extended integration work that we're doing and being included into their Cisco Global Price List, which in turn drives huge volume for the business. That's a separate arrangement.
Got it. The second question is still around that second use case, just in terms of the deployment for that actual company. You showed us how easy it was to set it up on your platform. Can you walk us through the next stages that that company would have to undertake to actually transition their back-end system or their business across onto it? Is that a project that would take a matter of weeks or months, or how challenging is that from their side?
Matt, did you want to take that one? I think you touched on it in terms of what the customer brings to the table. Ordinarily, Tim, the customer would already be, in this particular case, an SD-WAN provider. They would've already had that, so it's a matter of them, it would've been a quicker process. It was very quick for them to set this up. Maybe, Matt, you're closer to this lead customer if you wanted to talk to that.
Sure, Vincent. I think it's similar to our existing products and the customer journey. In that use case, we've gone small. The customer, it only has taken them a matter of weeks to stand up. It will be a long-term migration. We are expecting that customer to grow with us over the course of the next 12 months-24 months as they move some of that legacy infrastructure. As Vincent pointed out, they already have the SD-WAN vendor, they were already using them. It was now just a case of establishing it on our network edge rather than to the cloud providers directly. It only takes a matter of weeks.
Got it. Thanks. I'll jump back into the queue to ask the other questions.
All right. We also have Paul Mason joining us now.
Hey, Paul?
Can you guys hear me?
Oh, yeah. Paul can.
Yeah. Okay, great. The first question I had was just if you could maybe go through the products defined, both in terms of bandwidth and in terms of the number of virtual CPU resources that are allocated to it. Could you maybe give a bit of an explanation about why you need to increase the number of CPUs attached as you scale up the size of the bandwidth on the service and the number of endpoints that are talking to it?
Sure, Paul. Let me answer that. You have to remember that all of the majority of SD-WAN traffic is over encrypted sessions. With current modern technology, every encrypted session typically has a maximum bandwidth of about 1.5 gig. As you increase the number of branches, you and the number of connections that you're making to that MVE, you have to think about encryption overhead, and that's where the number of vCPUs goes up to deal with that decryption task. The decryption task is a pretty heavyweight activity on modern CPUs.
Okay, great. Just in terms of how the SD-WAN orchestrator interacts with Megaport Virtual Edge, so the use cases you guys have provided, I think sort of basically imply that your expectation is that the orchestrator will live on Megaport infrastructure, whenever Megaport Virtual Edge is deployed side by side with an SD-WAN vendor’s solution. Are you ever expecting that to not be the case and for the SD-WAN vendor to sort of build next door instead of just pushing their software onto your infrastructure?
Let me answer that in two bits. The first one is that the SD-WAN orchestrator, the thing that manages all your SD-WAN connections, that's typically a SaaS-based solution by that SD-WAN vendor. In the case of Cisco, it's a technology called vManage, which they host. It allows you to manage not just Megaport deployed SD-WAN edges, but everything you have on a branch or data center footprint as well. Each one of those vendors has technology that they stand up on their own using SaaS technology. Does that clarify your question?
Sort of. In terms of how the virtual edge talks to that, so that the orchestrator can sort of use Megaport's network, is it going to be living in the same data center but in a separate rack, for instance, to Megaport's infrastructure, and then you're going to cross-connect into that? Is it actually, is the better outcome for it to live on Megaport's servers, and you provide the Infrastructure as a Service that's backing up the Software as a Service? Does that make sense?
Yeah. Typically, they're doing a SaaS deployment. That control function is typically located in a cloud provider somewhere or in a data center that's controlled by that SD-WAN vendor. They talk when they do the deep integration with us, that connection is over to our public API endpoints. They talk directly to the APIs that we provide that allow them to control an MVE instance or a VXC on our network. That's the way that Cisco has done the integration. They talk from their SaaS-enabled control function over to our APIs to make and orchestrate those connections.
Okay, great.
I suppose just, Paul, just one other thing to overlay that is not all of the SD-WAN providers are going to continue to build out infrastructure to support. They've got their central hubs. This is where they're relying on partners like ourselves to actually extend that reach. That goes back to what I was talking about the platform at the end of it. There's a huge inherent value in the platform and the network that we've built and all the locations that we're in, and that's what's augmenting this heavy lift and allowing for greater customer reach, both for the SD-WAN provider and for ourselves.
Okay. Last one from me for now, and I'll jump back in the queue. Just on Versa Networks, which is one of your more recently named partners here. My understanding of their business is that they historically have provided customers with their own sort of global map of points of presence and a sort of global backbone of dedicated bandwidth, that in effect had tried to do what you're going to be doing for these solutions themselves in one holistic package, and now they've decided to partner with you. I don't know if you can share anything about why they've gone away from trying to do this themselves and instead partnering with your network in order to provide that solution.
Matt, did you want to take that one? I don't think they're stopping from doing what they're existing doing. I think they're just using us to, again, like I said, it's an extended reach.
Extend. Yeah, it's certainly extend. I think it's not only is it the 21 locations now where their customers connect to. We're seeing that demand from our existing customer base, which they see coming through directly. Also the cloud interconnect points and the reach of those cloud regions and the applications.
Okay, thanks. I'll jump back in the queue.
Great. We have Bob Chen from JPMorgan joining us now.
Hey, guys? Thanks for taking my question. Just thinking about the potential take-up rate of MVE, what's the best way to think about it? Just given Megaport's core product did take a little bit of time to sort of get adoption or you needed to do a bit more education of the customer base, do you think something similar will happen with MVE?
Hi, Bob? Our assumption is, and we can only work off what our partners are doing, and as Rodney has outlined, not just in the last quarterly update, but what we had in our go-to-market motion is about extending our access to the partners and the resellers that actually currently resell SD-WAN today. By doing that, we get a greater reach. It is also solving a problem, as I said, like the Network as a Service element of our platform is lacking as we've talked. I know we can get a bit technical in some of this, but at the end of the day, that is the part that is missing and that we are solving for. We believe that this will be faster than the existing business that we started out with rolling it out. It is a technology that is known and it is understood by enterprise customers.
There is the overwhelming demand to connect to public cloud provider, and as John outlined, that's a difficult process today for both security latency, network performance, cloud application performance over longer distances. In the use cases, you can see how quickly that we were able to deal with that for the customer. We anticipate, and I know I'm talking to Rodney, and this is just on our side of it, not with the reseller side. We already have a pretty strong pipeline building of customers and like I said, proof of concepts that we're finishing out. This use case that we talked about here was a proof of concept that we were talking about three or four weeks back, and it's now come to fruition, and we have a couple of more of those that will be going live during June.
Maybe, Rodney, if you wanted to touch on that a little bit more.
I would just say, early indication as we talk to the top partners from these vendors and to the leaders of the SD-WAN sales teams, there's a definite customer need. The value proposition is very clear, and the value that we provide to customers just extends the value that customers realize from the vendor's SD-WAN solution. As Vincent said, our pipeline is very strong already, and building very rapidly. I believe that the uptake on this product and the knowledge of our product in the market is going to happen pretty quickly. We're already seeing signs of that.
All right, great. Perfect. Just bringing it back to use case two, like Tim earlier, in terms of that $ 15,000 per month number, how would that compare to what that customer was previously spending on Megaport?
I can help answer that. They were roughly, I think, spending from memory around just over $ 2,700 a month. Now they will be reaching about $ 15,000 a month. Of course, a lot of that has to do with the transit, but also the VXCs associated with that now too. Connecting those branch locations back to their private infrastructure that they had with spun up VXCs to those cloud applications as well.
All right, perfect. In terms of your target customer base, do you expect a different sort of customer base to what you're currently targeting? Or more of an expansion, or is there some overlap there as well?
Well, keep in mind that today we're selling very well across every industry. There's not an industry that we're not touching today or have a logo in. I think as we look at those customers that meet the profile that have those branch locations, like the use case example that Matt pointed out, we're looking across our existing customer base and those that meet that profile, we have a set of questions that we're approaching those customers with already proactively to identify the need and to start the selling motion. From a Cisco, Fortinet, VMware perspective, the same thing. Those customers that already have SD-WAN solution or are in the process of buying have identified a need for our solution based on what has been outlined in this call, and we're approaching those customers as well.
There's no shortage cross-industry, be it retail, finance, manufacturing, that have a lot of branch locations that have a need for this product.
All right, brilliant. Thanks, guys.
You bet.
All right. We now have Matthew Dolgin from Morningstar joining us.
Hi, can you hear me?
Yes.
Yes.
Thanks for taking the questions. I guess I'm looking at slide nine and thinking about those customers that already have been on an SD-WAN solution. Is your solution geared mostly towards those that have already had it and it's actually better to go to Megaport also? Or are you targeting mostly towards those that are setting up new SD-WAN networks? I guess I'm just wondering what the value proposition is once you've already gotten that first step of complexity out of the way on a traditional SD-WAN network. My second question is actually just how you guys look at the future of SD-WAN if we end up with a more distributed workforce with more work from home.
Does that lower the need for it just because enterprises, despite how it might be better for the branch office, they have less need for it with fewer workers maybe in the branch offices? Thanks.
Thanks, Matthew. I'll touch on it first, and maybe, Rodney, you can add a bit more color, but look, it's both, right? The reason we've seen most of these providers we're collaborating with in arrangements is that not everybody is using one of those vendors. They pick and choose the same as they pick and choose their cloud vendors. They all see this as a growth vector in their business, these products. I think there's a slide there we had, and Matt, John had the slide. I think it was slide, yeah, slide 10, the one after that, where it talks about the revenue growth over the next couple of years in this space. It's a growing market. That's the first thing. Yes, we are seeing it come from existing customers as well.
As you said, we're looking at profiling those customers that we have today. More importantly, this is seen as a growth engine from the SD-WAN providers. We're seen as an enabler or a fast tracker for customers to get network connectivity using their product to what the customers are looking for, which is to solve for predominantly from branch to cloud. That's basically where it is. It's actually both. It's a growth market, and it's also we're targeting our existing customers. Just to touch on the second part, we're not really seeing that. From what we're seeing in most businesses today, it's as I said, it's a growth pace that people are looking to use SD-WAN to make other things easier for them, whether with existing legacy infrastructure or connectivity or for more diverse or more edge connectivity.
We haven't really come across anything at this stage to say that working from home and less branches and less offices is going to have a diminishing impact. Maybe, Rodney, I'll let you take.
Yeah. One of the beautiful things about this product that every salesperson loves is how easy it is to set up and demo and show the performance advantages very quickly. For existing customers that we're approaching, and Matt showed a few examples there, we can very quickly prove by actually using the product that the performance is better, and that there's a lot of advantages in terms of not only connecting their branch locations, but connecting to the cloud, and avoiding some of the costs that they're paying in egress fees and other things. The value proposition is clear. The ability to demo the product is very easy and quick, and it looks like the sales cycle, is going to be fairly quick, in comparison to our ports, right in the same lines, if not quicker than selling our port product.
Just as far as the network architecture goes, if you do have more employees working from home, do the company still get the benefit of this SD-WAN network or for employees working from home, are they kind of excluded from this?
Let me take that for a second. You have to remember, what are the applications that those employees are going to? These are all private on-network applications. Like in a healthcare setting, it might be cloud-based radiography and imaging, or in a entertainment environment, it could be manipulating assets in cloud that are doing film production. I think we've done a great video with Framestore on how they use that. All those applications are private applications that come over the private enterprise network. As employees move to a more work-from-home environment in those situations, they still need to get to those private applications, and they want to get them over a private link to cloud. They don't want to use the public access, especially when they have applications that are very sensitive, the core IP of companies.
yes, working from home is going to change the enterprise network. SD-WAN will help that in allowing workers to work anywhere, but still have a mechanism for connecting to that enterprise network that gives them private connectivity to cloud. I would say that eventually you're going to see some of the SD-WAN vendors realizing that trend and be able to provide that SD-WAN functionality to a home worker, not just a branch office. Granted, that will mean more connections to those hubs and they might have to change their software architecture to facilitate that. the work from home, yes, it's a change in the way enterprise networks need to be built, but the access to those private applications still needs to go over dedicated private links that SD-WAN facilitates.
That's very helpful. Thank you.
You're welcome.
We now have Nick Harris from Morgans joining us.
Oh, hi, guys. Nick Harris here from Morgans. Can you hear me?
Yes. Hey, good morning, Nick?
Wonderful. Hey, Vinnie. Thanks very much for this. Just a couple questions from me. Just on the MVE sales model within Megaport, are you retraining your existing salespeople to sell MVE, or are you adding new salespeople who will specifically focus on this?
We're training our existing salespeople, and we're adding primarily solution architects that can support, not only our sales team, but also the partner sales teams to identify and progress opportunities. Some of both. We're hiring and we're training our existing team as well.
Thanks very much, Rodney. Just also interested, I guess, from the perspective of your big providers like Cisco, where do you think SD-WAN sits in terms of their sales priorities? Obviously, they're very big beast. They've got a lot of things going on. Is it something there you think they'll actively push, or is it more customer demand that's driving as in pull rather than push?
Well, I can have Mattie chime in on this one as well, but the feedback we're getting from the sales team is that this is one of their fastest-growing areas of their business is SD-WAN. They're getting not only pull from the market, but also push from their partners as well. The feedback we're getting from the partners and the direct sales team is that there's focus here, there's demand, and it's one of the fastest-growing areas in their portfolio. I'll let Matt chime in as well.
Yeah. Thanks, Rodney. We haven't been given sort of a specific number from Cisco. However, we're certainly working with them. Just to recap on what we presented earlier, once we're on the global price list, their sales team are incentivized to sell this. Also, their partners are incentivized to sell this through the Cisco rebate system, through their special incentives. they're certainly seeing the demand coming through, particularly when they're rolling out new router infrastructure. The C8KV, it's sort of established like as a bundled sort of package. When a customer goes and purchases that C8KV, they're going to get access to Megaport services as well. That's how they're sort of driving those sales because they want them to buy it through Cisco direct rather than going and buying this through some of the other partners that they've got this infrastructure hosted on.
That's great. Thanks for that.
Just one other thing to add to that, Nick, as well, and this is public knowledge. Cisco being a public company, they are very much focused on trying to drive monthly recurring revenue streams as opposed to some of their traditional business, which is just selling hardware. Again, value-added services are seen as a high-growth area within Cisco.
Great. Thanks, guys. I might just sneak in two ones which are hopefully a bit quicker as well. Just to clarify, does Megaport pay commission on the Megaport Virtual Edge plus the VDCs, or is it just the virtual edge? the second question was just cybersecurity. Obviously, when you've got a branch out in the wilderness, you've got to protect some of that. Do you guys provide any of that, or how does that work? Just the cybersecurity side attached to the MVE. Thanks.
I'll answer the first part. Maybe John can take the second. Yeah. Commissions are usually on a bundled price, which is the way we've structured it, excluding the IP transit. That's a typical format globally, so it doesn't differ from the way we do things today with the remaining or the existing products. On the cybersecurity piece, John, did you want to take that one?
Sure. We don't do anything specific to the branch. What SD-WAN does allow you to do is take the sensitive workloads and put them over an encrypted pipe to the Megaport Virtual Edge. The other part of most of the SD-WAN vendors' solutions are they do offer a full suite of security functions on that instance that they're running on the Virtual Edge, whether it be firewall, deep packet inspection, application inspection, things like that are all offered on those platforms, and customers may take advantage of those security functions to protect the applications that they may be running in data center and cloud.
Thanks, John. It's more like it's wrapped into the bundle rather than they get a VXC to a security solution?
Yeah. Again, it's another one of those areas that we would see similar to SD-WAN as a suite of security products like that with other partners that we'd have hosting as well. A customer, if they just want those services, they could get them directly too. That's something we talked about is the involvement of SD-WAN as the first set of providers that we're using on MVE, and we talked about other things like IoT, 5G, security, et cetera, as other different buckets of areas where we can host on MVE. Yes, right now, most customers, if they're using an SD-WAN provider, they can actually choose those services via the application or the managed service.
Excellent. That's it from me. Thanks again.
Thanks, Nick.
We now have [Wei Shen] joining us.
Hi, guys. Can you hear me?
Hello, Wei. How are you?
Okay, great. Three quick questions. First one is just in regards to our partnership with Cisco for [MVE]. Do we have any type of performance bonuses related to that if they sell over a certain amount of our product, and at what level would that be set if we do?
You mean with their sales force or ours, or in general?
if they were to sell beyond a certain level of-
No.
Okay.
No, there's not. We've agreed a revenue share with our Cisco partners, and that's set in motion, and we review it periodically, like a 12 months or 18 months period. It's set in a way at the moment to incentivize large volume uptake, which is what we both want. That's why we've set it that way, and obviously, we're going to continue to support it through marketing initiatives as well. That's the whole purpose of that. Other than that, no. Mainly the rest of it is to sell with our partners, so they have resellers, et cetera, or system integrators out there that actually actively sell those SD-WAN products, and they're the ones that we're working closely with, not just to sell SD-WAN products, but to sell our existing products as well, like ports and VDCs.
The second question is when our direct sales, do they also have a function to cross-sell our Cisco for [MVE] products? if so, do we get commission from them if we do that?
Well, no. First of all, we're allowing the customer to choose which SD-WAN provider they want to use, and obviously, you have to have a relationship with the SD-WAN provider to obtain either CPE or the license that they need to use the service. We are not actively engaged in selling that. You're going into an area that's not something that we're core at. It's the same thing, if I bring back here an example. Early days when we started out, we brought on all the cloud providers and fully integrated with them, and we built out all the connectivity with all our cloud providers. The same thing we're going to do with the SD-WAN providers, and we'll do that with other providers as we bring them onto MVE. Their competency is selling their product. We're just facilitating the connectivity to the enterprise customer.
My last question that I've got is just on our slide 14 of the presentation. We talked about the 21 locations that we have right now. How do we see that number expanding over the next few years? Do you have any guidance for that, and what is the cost of expanding our footprint for each location?
Yeah. Matthew, do you want to talk about phase two and phase three in terms of locations?
We can't really confirm phase II and III. It's still in discovery phase, which is-
I'm looking more for if you have numbers. I think not locations though.
Yeah, I can't confirm that.
Yeah. I think it's an additional 20 that we have in for the budget for this next year. That's a different 20 cities. In terms of the cost of what that is, it's typically hardware. We're already in that location physically with our existing equipment. We deploy this compute at each one of those new cities or new sites that we deploy into, and that's mainly hardware cost. Depending on how much we have to deploy, it's fully loaded, it's around $35,000 per location.
Okay, got it. That's all for me. Thanks.
Yeah. All right. We now have Siraj Ahmed from Citi joining us.
Okay. Hello. Can you hear me?
Yes. Hi. Go ahead.
Yeah. Okay, thanks. Just thinking of the target customer. I mean, we spoke about partners, but from your 2,100 customers that you have today, have you just tried to map out how many would be addressable from this new solution?
I don't have the exact number offhand.
Is it like 10%, 20%? Just trying to understand that.
I would say it's at least 25% meet the profile, but it's hard to give an exact number. Plus it's early days. We're still looking at our customer base and approaching customers. The product's only been GA about 50 days. We're still asking the customer questions about their architecture and the number of branch locations and such they have to identify potential customers, which we're still proceeding with. There's a good amount of our customers across industry that meet the profile.
Got it. Thanks. Rodney, just thinking of the target customer to the partners. Should we think of a new to SD-WAN customer would be the typical customer now because the partners would be selling SD-WAN and then this sell on MV. Is that the way we should be thinking about it? It's really future SD-WAN growth that he can tap into mainly.
I think it's both. I think there are existing SD-WAN customers that need this solution. I wouldn't say it's just new. I think the selling motion is more smooth and natural for new customers to include Megaport as part of the total solution. Going back to existing customers, and giving them the advantages and value we can provide is good for existing customers as well. I wouldn't say that just new SD-WAN customers are the ideal target. I believe it's both.
For the existing ones, you'll have to use your sales team, the inside sales team. Is that the way to think about it? Because the incentive-
No
Is a partner. That's the future. Okay.
No. We'll use the partners of the SD-WAN providers and also the direct sales teams of those providers. Keep in mind we retire quota because we are on their price list, and everyone in sales wants to retire quota and reach their targets. Same with taking advantage of the partner, their channel program advantages and benefits by selling more. Because we're on the price list, they can sell our product to take advantage of those benefits. Going back to existing customers and selling is a path of low-hanging fruit. It's always easier to sell to an existing customer than to approach and try to sell to a new customer. I think there's going to be both.
That's certainly what we're targeting in our go-to-market and our selling motion, is to target both existing customers that Cisco, VMware, Fortinet can easily help us to approach as well as their partners, and include Megaport as part of their new solution sales as well.
Got it. That's a good point regarding the quotas. Just last question from me. I mean, we were talking on SD-WAN today, but you're hinting at future functions that may also on MV. Can you just touch on how we should think about that and just give us a flavor of what the future stuff could be?
Maybe John you can take that?
Say that again.
You started future functionality with MVE and SD-WAN. Future functionality on top of MVE?
Wow. That's a really good question. Part of it is a lead from the SD-WAN vendors on where they're headed. It's a fairly mature product, so you don't see any dramatic changes in functionality in that functional space. I think with some of the integrations that we're doing, where we can integrate further with the SD-WAN partner, most likely it's better visibility into our network assets and ability to select paths deep within our network for optimal latency or experience. I don't think that's anytime soon. This is a much longer-term approach.
I think, as you're talking about what I mentioned earlier on about 5G IoT.
Exactly. Yeah, 5G IoT.
Yeah. Okay. Yeah, not necessarily SD-WAN yet. Yeah, look, we do have some conversations heading on, but they're in early stages with certain partners about that capability. Bear in mind, we've just launched MVE. We're really in the middle or the throes of lining up a couple of partners, like we just outlined today, and getting this up and running. I think that's going to be our focus certainly for the next rest of this calendar year, and will continue to be as part of business as usual from that point on. The future development in terms of areas that will sit across MVE, we have a few in each one of those areas that are in their infancy. It's probably going to be post-2021 before we start talking about something like that.
Got it. Thanks. That's helpful.
All right. We now have Paul Mason joining us again.
Hi. Can you guys hear me again?
Yeah, Paul.
Oh, great. Okay, just a couple more from me. Just in terms of redundancy, just in the two use cases you provided, in both examples, the customer only purchases one MVE per city, and then they're purchasing two cross connects, which I think is for redundancy. Can you maybe give a bit more background to why they, first of all, why they have two cross connects per MVE, and then also why they only have one MVE? Because I think historically you'd talk about a lot of customers they would port, so they'll buy a second port for redundancy and why that might not be the case for an MVE.
Let me answer that. First of all, the two VDCs that they're purchasing, the reason they're buying those is to match to the SLA guarantees that cloud providers are offering by requiring those two connections to offer those SLAs.
I think most customers are probably going to purchase either an MVE instance in one metro and another one in another metro to have that redundancy that we've talked about, or they'll do two in one metro. It sort of depends on how they're building their network fabric and what the latency characteristics of that network fabric are going to be. With applications that are tolerant to a little bit more latency, they might do one in one city and one in another. For applications that are not tolerant to that, they'll probably do two in one metro. The other bit that we've done from a redundancy standpoint is, we talked about DDoS, for instance, as a functionality. The other function is that we are selecting routes from multiple transit providers in those metros so that we have transit provider redundancy in those metros.
We're deploying two MVE instances in every metro, so a customer can select redundant MVE instances in those metros. if you think about it, Megaport has always strived to offer an enterprise everything they need to build a bulletproof network, and we're doing that additionally with MVE.
Okay, great.
The other thing, Paul, that use case is the smallest instance that you can come up with, right? Combination or configuration in terms of a customer in one metro, in this illustration, connecting seven branches, connecting to one MVE, you need two VDCs because of the SLA for the cloud provider for redundancy, and that's the smallest. If a customer wants, like what we saw in the larger case, and you've got multiple cities, the connectivity's there. If you want to go branch to branch from, say, somewhere in Sydney connecting to Melbourne, you would have two MVEs and you'd have two, obviously, a customer would have two instances of their SD-WAN on either end connecting to the data centers in each location.
It depends on the application, and you may not need, and obviously the number of VDCs you need is obviously equate, as you saw in the large example, to a bigger footprint and more locations.
Okay, great. Just maybe an extension of this question then. In terms of the latency to the edge, you guys gave some stats about the improvement that, so to speak, Fortune 500 customers experienced. In terms of globally rolling this out, are you thinking about this in terms of maximum path to the edge of 20 milliseconds? Is there a stat like that from a competitive or customer experience perspective you need to build out towards? Sorry, go on.
Yeah, I would say we always think about application latency. That's from where the consumer is using the application to wherever it's hosted. You want the most direct path. What we're trying to do is make sure that we're in that latency path regardless of what cloud region you're using. It's a complicated formula that has to do how quickly can you get to a Megaport Virtual Edge, but then again, what is the latency path to that cloud-based application? Part of our design consideration has always been put MVEs in locations that will help a customer minimize that latency path to their application. Could I say it's 10 milliseconds maximum latency? Yeah, that would be nice, but it's not prescriptive. It depends on the geography, it depends where the cloud region is, and where they want to meet us.
Okay. Yeah. Say like on the East Coast U.S., where you've got New York, Boston, Washington all in relatively close proximity, there could be logic to deploying all three cities instead of just saying like in New York, in the central part of that sort of chain of population, for example, or?
Yeah. what we've done there, if you look at that, we've tried to deploy close to the cloud region. as well as make sure that we cover enough parts of the Eastern East Coast of the United States, so New York, Atlanta, Ashburn, which is in the Washington, D.C. area, as well as up in Toronto in Canada. trying to get all that traffic onto our network and then to the cloud regions regardless of where they're at. in the U.S., we're fairly covering the whole country. even in Australia, we're deployed in both Perth and Sydney because we realize that you don't want to, if you're running a workload in Sydney, you want to get over a quality network to get to it, even if you're in Perth.
Yep. Okay. just the last one from me is more about sort of first-mover advantage, because I think like with Megaport historically and the data center partnerships that you guys have struck, the nature of them has sort of informed that somebody else couldn't come in side by side, like say, with what you guys have done with Digital Realty or Cyxtera or EdgeConneX or others. There was sort of an opportunity for one. With virtual edge, how do you guys think about first-mover advantage? In say, like Cisco vM anage console, I believe there's sort of probably room for another vendor to appear side by side, but probably not that many. Could you sort of frame up sort of how you think about that?
Yeah. Well, I think just to answer the Cisco piece, I think, we were asked this question before, where we want to be exclusive, and the answer to that was no. It's the same on Cisco side because they're obviously looking to use as many partners. That's the way they've set themselves up. They leverage partners, whether anything for to give them reach on sales growth. We're the same. We saw that, and if you look at that chart that John presented on the market where we talked about the quadrants. The VMware, Cisco, Fortinet, and Versa account for 48%, those four alone account for 48% of the market, right? We didn't want to be kind of limiting ourselves to one area or one sliver of that quadrant. The whole idea is to get that reach. Yes, MVE is the first mover.
We're the first ones to do this. The full integration with Cisco is the first of its kind. Both of us have recognized that in what we're doing there. It takes a lot of work to do it. We've been at that, God, more than 18 months, maybe two years since inception, when we first talked about doing that. it's not something easy to do and replicate. It takes time, which is why we've come out with this, and we want to make sure that we make the most amount of noise about it. again, what we're trying to do here as well is leverage the platform, right? like I said before, we've done the physical network. We have all the data centers connected. Now what we're doing is we're layering products over all of this, and this is just one.
Now it's opening up a door for us to bring more providers onto the network so customers have more choices. We're driving customers towards the Megaport platform, so they can either connect in a data center to cloud or from a branch into our network or just use it as networks as service. as we continue to layer over more products and we grow our existing global network with either new markets or new countries, it just continues to self-perpetuate. that's the way we see it. there isn't anything like that today. to build that again, like I said, it's still going to take time and a lot of money and a lot of effort.
What we're trying to do is go further and further deeper and getting closer to where the customer or the enterprise is, using most of the providers and doing the API integrations with those to bring all of that and to make that easy consumption or easy way of consuming and provisioning services. That's the mantra, and that's how we look at it. there isn't anything like that today that's out there.
Okay, great. Thank you.
Operator, I might ask, we've had a bunch of questions come in via email and via the chat channel. I might just ask a few financial ones that John might go through. The first one relates to OpEx and what will happen to OpEx with the, particularly in FY 2022, with the addition of SD-WAN resourcing
The second one, the follow-on to that is does that impact Megaport's ability to achieve EBITDA breakeven on a run rate basis by the end of FY 2021? The third one is what's the cost to expand to additional MV locations beyond the 2021 that have been nominated?
Okay. Just taking the OpEx question first. SD-WAN itself doesn't necessarily add that much OpEx. We are going through a scale-up of our indirect sales channel, and the additional head that we bring on to support SD-WAN will be part of that. In itself, it's not significant or not material step change in terms of our headcount in and of itself for SD-WAN. As part of that, we will be supporting this additional indirect sales build with marketing. As the world returns to normal, we'll hopefully start attending events and start traveling a little bit as well. That adds a little bit more of leverage in our journey to EBITDA breakeven. We're still on target to do it by the end of this year, as most of that additional spend will be ramped up through H1 of next year.
We might be out a little bit of a cost, but our operating leverage is such that even if we do take a backward step for a month or two into FY 2022, we'll be straight back getting towards EBITDA breakeven and EBITDA positivity throughout next financial year. In terms of how much it would cost to expand these MV locations, as Vinnie mentioned it earlier, this is just a CapEx cost for us. We are already in locations. We already have the space. We already have the power and the connectivity. It's just CapEx for the compute that we'll be adding in the locations and about 30 grand a go. It's just a one-off cost. We're not adding any more costs necessarily for this expansion for phase two and phase three.
All right. We now have Tim Plumbe joining us.
Hi, Tim?
Sorry, guys. Can you hear me?
Yep.
Okay. Sorry. Just two follow-up questions for me, if possible, please. Just going back to that second use case that you gave. $ 15,245 cost under the new structure. Can you give us a sense how much it would cost to set up a structure or the operating cost to set up a structure under the old traditional SD method?
That's a complex question. It would have to go not only regional issues, but also network design. To give you a sense of some of the costs that you'd have to incur, depending on where your workload is. In a data center context, if you want to set up SD-WAN, you'd have to purchase the equipment and the transit connections, and assuming that you have rack space in that data center footprint. On the cloud, it's very similar. You have to purchase the virtual instance, the software license that you're running in the cloud, and then rather than transit connectivity, you'd have to pay for the egress costs of data on that public cloud endpoint. Our ROIs on all those situations put Megaport at a cost advantage to most enterprises that are building that.
Now, if you were to look a little bit more traditionally, even before SD-WAN and going to MPLS, that is a substantially more costly solution than anything that we've described to date. I think the best analog is both the data center footprint as well as the cloud footprint. In our analysis, both are more costly than the Megaport solution.
Got it. Just the second question, Vinnie, slightly off topic, but just in terms of ports added. You previously mentioned that momentum was accelerating into the fourth quarter, and that you guys had a number of new initiatives that could potentially further drive ports added. We're kind of two-thirds of the way through the quarter. Are there any comments that you can make about some of those new initiatives or how those ports added are tracking?
I thought I could get through this call without someone asking me that. It's going well. That's what I would say. We're happy with progress. Obviously, we're now into the last month of the quarter. We're doing a lot better this quarter. Yeah, we're happy. I'm keen to get Rodney off this call because he can't get him back selling. No, we're happy with what we've said before and where we're at, and we still have a very strong pipeline. We'll continue to add to that pipeline as well as convert it. Yeah, we're happy. We're confident for outcomes that we're driving for this quarter.
Great. Thanks, guys.
Okay. We're now coming up on an hour and 40 minutes. Steve, is there anything else? Are we about there?
One question, Vinnie, I do think is perhaps worth just touching on, and it relates to the share of revenue and the margins that we're anticipating in each of those. Sean, this is perhaps one for you using a real-life example. This just relates to perhaps we start on use case number one, which is relatively simple, clarifying the ARPU trends and then the types of margins, depending on where it comes through gross margin and EBITDA margin.
Yeah. It all depends really very much. If we took a very small MVE instance, say, if we go back to the use case one, where we have a small MVE at $1,550, of which $550 is transit. We're going to have two VDCs at $ 400. The gross revenue, if that were to be the case, would be $1,950. If that was going through a direct sale, the only cost of sales we would have would be the IP transit that we would have to do. Our gross margin then is obviously $1,400 of the $1,950. If it goes through the partner resale model we talked about, we would have to give off somewhere between 15%-20%, is usually the standard percentages that we give off. That would be of the VDC costs and the MVE costs only. The IP transit would be a cost.
We would be giving away about $280 of the $ 1,400 extra margin. That would give us a margin of about $ 1,120, which is about 57%. In terms where we go through a revenue share model, which is a low touch model for us, where much of the sales function is done through something like the Cisco platform, Cisco sales function. We would be sharing our revenue, and it's typically 50/50 after the reseller cost as well. Again, like we said, none of the revenue share or the discount is given on IP transit, which is just a straight pass-through. The cost to us would be $ 550 for the IP transit, the same $ 280 to the reseller if it was going through a reseller. We would have a revenue share of half of the remaining $ 1,120. It would be $ 560.
The presentation on our accounts will be very much dependent on the commercial model. If we were to show it on a gross presentation, we would be showing a gross margin of $560, where if it was going through the revenue share model with a partner reseller with IP transit.
We may draw today's presentation to a close. Thank you very much for attending our investor briefing on MVE. Today we've run through an overview of both MVE and SD-WAN, some of the MVE pricing and use cases, and then we've seen a demo from James. From the Q&A, there's obviously strong interest in MVE and what it means for Megaport going forward. I don't think we've answered every question today, so please reach out if you have anything further. For those that have missed today's webinar, it'll be made available on our website.
We've included on page 24 of the presentation a bunch of reference materials that might help you get up to speed. In addition, we intend to disclose on a quarterly basis the MVE metrics as we're selling MVEs into customers, something similar to what we disclose on MCRs. If you have any more questions, please reach out at investor@megaport.com. Just a quick reminder that our Q4 global update and Appendix 4C will be due out on Thursday, July 22. Thanks again for attending today, everybody. Thank you.