Into the ether then into the cloud - the vital role of Ethernet
Date: Wed, 02/08/2012 - 19:39
Bob Metcalfe, father of Ethernet, describes how his network got its name: "I think we were either lucky, or very shrewd, that we never referred to the coax as coax - we referred to it as The Ether. We talked about sending packets up into The Ether, and having them propagate everywhere."
It sounds like a vision of the Internet Cloud of the future... And surely it was, for where would today's cloud aspirations be without Ethernet? At every link along the chain - datacenter, office network, WAN core, mobile backhaul, first mile and access - there may be alternatives, but Ethernet is the one word that appears throughout.
NetEvents EMEA Press Summit Rome invited James Eibisch to act as Devil's Advocate challenging the visions of leading authorities in the industry on the role of Ethernet. It can be seen as the unifying force in the Cloud, but how much is it simply the lowest common denominator compared with a more fragmented, best-of-breed approach? With 10Gb Ethernet increasing at the network edge, can higher speed Ethernet deliver at the core?
Having fought to escape being "dumb pipe providers", can carriers see beyond the "dumb cloud" model and think in terms of end-to-end service delivery, capitalizing on their overall infrastructure and not just delivering from a datacenter?
Fundamental issues - demanding high-level debate.
Panellists: John McHugh, Vice President and Chief Marketing Officer, Brocade; Kevin Vachon, Chief Operating Officer, MEF; James Walker, Head of Managed Network Services, Tata Communications; Phil Tilley, VP Marketing EMEA, Alcatel-Lucent
Introduced and chaired by: James Eibisch, Research Director, EMEA Business Network Services, IDC
Welcome to the devil's advocacy session - what a lovely photo. That's not a photo of Harry Pottery, by the way. I'm going to try in this session to knock down the idea that Ethernet has any role at all to play in Cloud computing. That's what they asked me to do and I'm preparing for miserable failure, but let's see how far we go.
Unlike Joe Baguley, I actually like lecterns because I can hide behind them but I can also consult my notes, because I have a terrible working memory so I'm not going to be able to walk around very much.
So I cover Business Network Services in Europe for IDC - VPNs, WANs and so on.
And I'm joined by a panel of four esteemed figures in the Ethernet and Cloud industry.
We have, starting from this side onwards, [Kevin Vachon], Chief Operating Officer of the MEF; James Walker, Head of Global VPN Services for Tata Communications; John McHugh, VP and CMO of Brocade; and Phil Tilley, VP of EMEA Marketing for Alcatel-Lucent.
So we're going to have a chat amongst ourselves first, after a brief slide, and then we're going to open up for Q&A and then, most importantly, lunch. We're also going to try a vote in a minute and I'm hoping that we're not going to see N=2 on the chart.
So when the vote comes up please vote if you've got a laptop or a device that can do it.
In this session we've got a grand total of one slide, and here it is. And it's a great one, isn't it? Here are some lovely forecasts. Spending on Cloud services and spending on carrier Ethernet services in Western Europe. They both start at around the same level, so at the moment we're looking at a market of about $3b for Cloud and $3b for carrier Ethernet services. But you don't have to be a mathematical genius to work out that the CAGR on Cloud services is much higher and the Cloud market will be worth roughly twice as much as the Ethernet market by 2015.
One reason for that is, basically, that pretty much any company can buy Cloud services, but in most cases it's multi-site companies that buy Ethernet services. So the universe of companies that can buy Cloud, of course, is much greater than the universe of companies that's going to buy Ethernet, at least end-to-end Ethernet rather than Ethernet access into Internet services.
Now, we've got a couple of figures on here just to delve into these a little bit before we get started. 28% of companies in Western Europe use Ethernet. Now, this comes from a survey that we run very year called the European WAN Managers' Survey, where we talk to about 700 medium and large companies across Europe. And what we've found is that 28% use a proper end-to-end carrier Ethernet service. So this isn't just Ethernet access into an IP VPN or Ethernet access into an Internet services. This is proper point-to-point, multi-point, any-to-any Ethernet services.
Now, almost exactly the same number - 27% - say that they're currently using a Cloud service. Now, this is either infrastructure as a service or software as a service. And when we asked the question we tried to be as clear as we could that this is a paid-for Cloud service that the company is using consciously and deliberately - Amazon or sales force or a virtual private data centre service - rather than individual employees using Gmail or Drop Box, which, of course, is much higher.
So someone earlier questioned the figure of 75% of companies using Cloud services that came from, I think it was, the VMware service. And I think this shows - and we find this in our services as well - that it depends entirely on how you ask the question and who you ask the question of. So if companies are thinking of their employees that use Gmail they'll say, yes, we use Cloud. If they're thinking of a proper virtual private data centre service then they'll say, no, etc.
Now, if we put those two figures together, almost the same proportion -- in fact, pretty much the same proportion of companies using Cloud and using carrier Ethernet, we wanted to know are they the same companies. And this really is part of what this session is all about. If we look at this, this could give us a measure of how important Ethernet is to Cloud, if we find that there is a correlation between Cloud use and Ethernet use.
So when we mine the data we find, actually, that Ethernet and managed IP VPN services are both a little bit less popular with companies that are currently using Cloud than they are amongst companies that are not using Cloud, particularly for managed IP VPN services.
And at the same time what we call DIY Internet-based VPNs, which is where a company buys and manages its own IP [set] devices to construct a VPN over the public Internet instead of buying an IP VPN service at all -- amongst those companies Cloud use is more popular. So there seems to be a negative correlation between managed network services, particularly IP VPN, and use of Cloud.
And I think this reflects the stage where Cloud is at in the market at the moment. So a lot of companies are using public Cloud for test and dev. They're experimenting with Cloud rather than bringing it into their core IT systems and this will change over time.
If you want the figures, I'll just go through them quickly because some of you may want to write these down. From our survey, then, among companies that do not use Cloud currently 62% use DIY IP VPNs, 45% use a managed IP VPN and 30% use Ethernet. And amongst companies that do use Cloud 74% use DIY IP VPN, 33% use managed IP VPN and 27% use Ethernet. So there's a slight imbalance between Cloud users and non-users.
Ok, so my job is to get out of the way and let these guys speak, so let's get on with that as soon as we can. First of all, though, we're just going to do a quick vote, and here it is. Remember, we don't want to see on the chart N=2, so please vote. So I think you need to type the URL at the top of the chart to actually vote.
So the question is, how essential will Ethernet be to the large-scale migration of IT to the Cloud globally? And you have three options; completely, Ethernet will make or break Cloud; somewhat, use it where it makes sense; and not essential at all, IP MPLS and public Internet will do fine. Ok, so, let's give that a couple of minutes if you're on your devices voting.
So, to the panel, first of all what I'd like to do is just go along the panel and ask each member briefly to make a brief statement of the main one or two benefits that, from their perspective -- be it service provider, equipment manufacturer, the main benefits that they see Ethernet bringing to the Cloud. So if I could start with you, Kevin.
Thanks. For those of you that we didn't brief over the last couple of days, the – just introduce the MEF. We're an industry association. We have approximately 190 member companies, including everybody that's up here today, about half of which are service providers. Cloud initiatives within MEF is probably the highest-profile work that we have going on right now.
I guess our position is that we -- I'll be voting for the first option there, that we think it'll be very critical to success of Cloud. The major benefits that we see it delivering to the Cloud environment are also those that we're delivering to the industry at large; the fact that carrier Ethernet is fast, it's scalable, very reliable, secure and is very configurable in a very dynamic way. And those are the kinds of things that we see being instrumental for Cloud environments, particularly private Cloud as opposed to public Cloud.
Okay, thank you. James?
So I'm from Tata Communications and we're a service provider. We've seen Ethernet as being very important within our portfolio. We launched our first WAN Ethernet service in 2004, so we really got into the market very early on. As far as enabling service providers providing Cloud, we see early-stage take up of Ethernet services for public Cloud providers to link together their data centres behind the Internet. Some are more advanced than others.
In terms of companies that need to provide private Cloud services to themselves and, in some cases, to other clients, we see extremely strong take up of Ethernet services.
And this comes because it's a -- everything that Kevin said. It's a easily scalable, easily manageable platform and it doesn't introduce an additional element into the equation.
So customers are concerned about the situation where they're having to manage what feels like an Ethernet environment, but actually exists over some IP-led environment.
And they like being able to directly connect data centres together and have them appear as a virtual LAN or a virtual data centre environment. So we see very strong interest and take up on that. We also see a great variance in the solutions that the customers are provided, so we think ours is, perhaps, better suited for those service providers than some of the other ones in the market.
So, if I was to vote on the survey that they had, I think the answer is a combination of number one and number two, which is I think Ethernet is a critical element of the success and scale our of Cloud services where it's appropriate. And the bottom line is that it has always been the challenge -- and if we look at the situation we're facing here with wireless in this room, it's a classic example of Ethernet versus alternatives to Ethernet for the last mile.
If we all had the choice we would love a high performance, very flexible Internet connection over IP Ethernet and that that was where we got our Cloud services. The fact of the matter is it doesn't achieve the level of reliability, accessibility and standardisation such that it can fill the channel of the wireless world that we all get -- still get, sadly, 80% of our experience remotely from. And it's that particular challenge, that Ethernet, while it is ubiquitous, it is universal, it's not a very efficient model for custom channels and specific channels, such as cellular. And as a result we're always going to have co-existent models of very efficient technologies that use the physical channels more efficiently than Ethernet, and Ethernet everywhere else.
Ok, and Phil?
So I guess I'm in a position where I make my money out of selling IP and Ethernet products, so very much to me, in my mind, is actually both have a part to play. I think [EP] IP has a role to play and Ethernet has a role to play. So going off the chart, then I think very much Ethernet is going to be a critical part of Cloud services delivery, but also it needs to be used where it makes sense. And we will continue to use IP MPLS where that makes sense. To some, perhaps, home working environments, again, we've got IP here in the wireless aspect, the wireless tail circuit, so we're going to use both technologies.
But what does Ethernet bring? I think where you've got high capacity you, need a lot of bandwidth, it does provide reliable services, secure services when MAC addresses are locked down, and high performance. So I think where you've got known locations to be inter-connected, you want a lot of capacity, Ethernet makes a lot of sense.
Right, ok. So on the issue -- you mention MAC addresses in complexity and managing the network and so on. One thing that is a potential issue is the fact that when you move to a Cloud environment you've got this layer of abstraction between the physical and the logical environment and that introduces a lot of complexity.
Servers with their own MAC addresses come into and out of existence. They may move physical location and take their application workloads with them and so on. So that's a lot more complex to manage from a network point of view than a physical server that sits in a known place and stays there are doesn't move. So is Ethernet – in fact, is any network architecture or service up to the job of managing this on a large scale? Phil, do you want to take that?
Yes. Interestingly, I'll focus on complexity. Complexity is one of those things seen and admired and enjoyed by engineers. Engineers love complexity - it's what they thrive on. I think when we talk about Cloud services, if we've done our job successfully as an industry, if I've done my job successfully as a manufacturer, I can remove and hide all complexity from the end user.
And that really is, I think, our goal; is how do we ensure that we do enable servers and data centres to be seamlessly interconnected across multiple locations and the provisioning of those is done automatically by the hypervisor in there or castration layer and all that sort of thing. That is definitely one of our goals and objectives and something we've got loads of engineers working on. Are we fully there yet? No.
Will we get there? Absolutely, we will. I think, of that, you look at the first IP MPLS networks. You needed to be a CCIP to actually set up an MPLS network. That got horrendously expensive.
I think if we actually looked at the market share for that vendor in the last few years we'd actually be saying, actually, there is a simpler and easier way. It's through automated management. That's changed the model for IP MPLS networks and operators are buying that simpler provisioning process. We'll get exactly the same [state] and I think we are there, I think, and heading that way with Ethernet services and linking that to Cloud service deliveries.
Right, ok. And, John, Brocade, I know, has a view on this as well, managing the complexity of the network as well. Do you think that we're going to see Ethernet scale up to manage very large numbers of MAC addresses where they're moving around and so on?
I guess the whole concept of native Ethernet as being the panacea for any solution I think is just really too simplistic, in believing that you can remove enough of the complexity to get down to the point where people can literally have their own Ethernet and simply run it.
I think the one thing that's a disrupter there is the whole discussion around open flow and what open flow does in terms of create an ecosystem that maybe it's a service provider is managing the network at a higher level of abstraction, but operating on a pretty basic level, functional network below.
But I just think about it from our area of expertise in terms of connecting data centres together. It's a huge, huge issue, right? Everyone wants to create a large, flat, universal pool that's distributed over geographies, but the whole concept of running that over native Ethernet; I don't hear a lot of people offering that as an idea. There's this shortest path bridging, GRE, now VX LAN is being tossed around as being a potential solution.
There's got to be something to handle the fact that that traffic is almost never going to exist in its native environment solely on those pipes. And so I think you fall away from having -- you have to go to some kind of multi-protocol architecture.
Right, ok. Now, James, Tata is famous for going with PBB as well as MPLS and Ethernet over STH at this stage. So thinking about managing large-scale environments and the complexity of that, what's your view on how those different platforms compare and whether they actually scale up to what we may see as very, very large-scale enterprise Cloud deployments in a few years' time?
We started this project on PBB about two and a half, almost three, years ago now, so it's taken us that amount of time to -- well, really, we approached the problem as being an issue for us. It was a carrier scaling issue that we simply had platforms that had taken so many Ethernet circuits we were no longer able to -- we were able to see an endpoint for where that platform was able to scale to.
So we needed something to scale to thousands or hundreds of thousands or millions of MAC addresses and millions of VLANs over time. And so we did a fairly comprehensive survey of everything that anybody had thought of or was planning to launch in the next three to five years at the time we started. So we did 14 months of, I guess you'd call it, protocol evaluation and then we did a following 12 months of vendor evaluation. And we had 16 vendors through the labs and tested them out in their claims versus the reality and so on.
And so our eventual decision about the vendor we chose and the platform we chose was very much driven and informed by that process. We were then surprised to find that, actually, the largest enterprises in the world had exactly the same problem as we did as a carrier. And so there was a sort of -- you could say it was a foresight or fortuitous congruence of those two things together that we started to find an awfully -- a surprisingly large number of enterprises who had a scaling issue with existing networking protocols, particularly MPLS.
And as a result, as I've said to several people, the feedback we've had from the market for this technology is something I've never had for any piece of technology in 22 years in the marketplace.
Ok. So can you give us a word on how that's working with your Cloud service that you launched earlier this year? The Instacompute infrastructure Cloud service is coming to Europe. I'm not sure what the launch date is for that. I think it's launched in Singapore.
Nor am I. So we've launched that in India and we've launched that in Singapore and it's being delivered to the US, I think, very shortly and, Europe, very shortly after that, so certainly within this calendar year. So that's a publicly -- public Cloud addressable service. It's not a private Cloud addressable service.
So although in the background all of those locations are linked together on our Ethernet core and we're able to provide large-scale scaling in the background of it,
from an Ethernet perspective we're not exposing that capability directly to customers yet. Mostly because the Cloud platform that we've deployed is aimed at small to medium enterprises and they're not looking for private network connectivity onto Cloud-based services.
So we don't see Ethernet as the answer to every form of access you may ever want from any location anywhere in the world. We see Ethernet as an enabler of interconnectedness of the platform that provides the Cloud service. So we see it as sitting behind the -- it's the Cloud behind the Cloud, to coin a phrase, that actually enables that capability.
And certainly for the feedback we overwhelmingly get from the large customers and the problems that we had for this large-scale, data centre-style connectivity was IP convergences times after a major outage within the network is a very big problem for customers that run very big networks, and for us as well. We've managed to get that down to four seconds, as is now -- what we provide on our core network is a foursecond convergence time. For a lot of customers four seconds is too long. Four seconds of traffic black holing is disastrous.
But you go to a customer and say four seconds, and people who know the industry say, well, that's great. And most other people are doing 30 seconds, 60 seconds, 90 seconds. Four seconds is fantastic - four seconds isn't good enough. So we needed faster convergence times.
We also see -- started to see some big problems when we started moving large volumes of MPLS customer connections around. So 10Gb and more is a problem against the background networks that we run today. Ethernet gave us a much more flexible way to answer that. And those are exactly the things that the customers are asking us for today as well.
I'd just pick up on and link that point with the previous point on complexity. I think the adoption of PBB and, in our case, the marrying of PBB with MPLS as a technology is actually a way we've actually addressed a problem and added some simplification. Certainly, our approach is actually looking at -- what PBB brings is a huge scalability, allows you to interconnect, seamlessly, a number of MAC addresses and (inaudible) addresses interconnectivity. The real challenge is, then, how do you actually also then create those PBB connections quickly.
And I think PBB is standardised relatively recently or adopted in technology relatively recently. The last really mass availability of platforms probably the last 18 months, but it has solved a big problem. And I think that's where the technology has been developed and brought in to solve a problem and an area of complexity removed almost.
And as a customer of these platforms, if we'd decided that MPLS TP was the answer we would, as it turns out, still be waiting for that too to standardise. So, again, as an element of luck, but also we went with something that was 99% approved by the time we bought it.
That invites an easy question to Kevin, which is, how important is standardisation and certification of Ethernet services? Particularly with Cloud we know the answer that you'll give. But, actually, one thing I'm interested in is that you talk to a lot of service providers. And the MEF runs the quarterly meetings around the world and has this audience and membership made up of service providers offering Ethernet, looking to offer Ethernet and, in many cases, I guess, integrate Ethernet with Cloud offerings and so on.
So in your journeys and travelling and discussions with service providers what sense do you get from service providers in different regions as to how important Ethernet is to the Cloud? And are they going with one or the other, or are they -- their sales team's incentivised to sell both?
Well, I think the general consensus is consistent with everything that's been said here; is that it will play a very substantial role, obviously, in public Cloud environments.
There are always more than one way to achieve a solution. So you will see all sorts of different solutions, some more layer three oriented, and that's consistent with the way VPNs are sold today. One provider might prefer one versus the other for different reasons.
But I think in general -- what's going to happen here is that Cloud is going to be a driver that pushes Ethernet -- pushes service providers to, in fact, invoke or activate many capabilities that Ethernet already has; the ability to ratchet up and adjust the bandwidth quickly. And many people don't do that today. The provisioning of Ethernet services is still quite static in nature in OSS. Either it's done manually or an OSS system comes along, nails up a connection and it stays like that until there's some request to change.
Providers now are dealing with the fact that they're going to have to move Ethernet - carrier Ethernet [mainly] - more into a real-time environment where it will have to be able to adapt and adjust and take commands from different places as compared to before. Whereas it might -- provisioning may have been initiated from some kind of OSS system, it may now be an enterprise through -- an enterprise initiated request for more service. Or for a service change it could be an application like VMware or whatever, telling the network that we need to change things here; we're moving this application over here. And so your bandwidth profiling needs to change and your virtual circuits and all of that.
So a lot of these capabilities are there in Ethernet today. The management systems aren't necessarily all there. There's certainly more work to be done, but it's actually interesting, because it's going to push the envelope of Ethernet a little bit and that's a good thing for the industry.
Yes. Do you think it's going to get there? Because I was looking recently at which Ethernet service providers support bursting and the way in which they support that, so the pricing per megabit that a customer bursts above a committed rate and so on, and what the ceiling is and whether bursting can be configured on a site-by-site basis as opposed to an all-or-nothing basis. And there's quite a lot of variation.
And there doesn't seem to be many service providers that really offer, with Ethernet services, the same liquid bandwidth that Cloud, it seems, would need. When you can bring servers up and down in five minutes, half an hour, potentially, on a big scale, Ethernet, clearly much better than anything we've had before, doesn't quite seem to be as flexible or liquid as it actually needs to be for that real time.
I think that's probably -- as much as anything else it's a price and return on investment argument. Because I'm sure James or anybody else would say if we want flexibility to that extent I'll just put a 100Gb Ethernet pipe to every location and then you can have it. Can we afford to do that at this point in time? No. Will we, in five years' time, have 100Gb everywhere? I'd hope so.
I think from our point of view the biggest constraint for us so far in that kind of dynamic provisioning situation has been the OSS systems. And I'm having to spend $3.5m to write -- with a certain software vendor to write an element that manages PBB as a concept within their platform. And, annoyingly, that vendor is then not giving me the rights to that piece of software. They're actually boiling that into their standard OSS platform. And I'm going, well, that's nice, but then why should I give you $3.5m? So my -- if you're just going to turn around and sell the benefit of my coding to someone else.
So our biggest struggle has been dynamic provisioning of stuff and relying on a scalable OSS that actually supports that kind of very fast reaction is difficult. I also find that customers who want bursting generally fall into a category where they say there's going to be some terrible event that's going to require me to send an awfully large amount of traffic.
As a service provider I have to have set aside some pool of bandwidth that's there to take that traffic during that catastrophic event. If I ask them is that going to be very important traffic or very unimportant traffic they're saying it's going to be incredibly critical traffic. So there's already a completely different 180 degree point of view between the two of us. I'm setting aside some shared pool of stuff for bursting, but you're telling me that anything you send through there is incredibly important to you.
It's not going to economically work out, right? At some point we're going to have a divergence of opinion.
We see this on the MPLS side with Telepresence, for example. I want to deploy Telepresence everywhere, but I don't really want to pay for a port all the time. But what I do want is 20Mb of incredibly high quality MPLS to potentially any point on your network, including Nigeria and South Africa, available on a moment's notice.
I'm very happy to build my network that price, but your pricing just went up by threefold.
So something has to give.
Yes, indeed. Ok. And the last question before we see if there are any questions from the audience is -- and it's a pretty simple one. We talk to a lot of enterprises and small and medium-sized companies as well and a lot of companies are still pretty conservative and traditional. They're not using Cloud yet. They're not using Ethernet.
They've still got private lines. There's still quite a bit of frame relay out there using MPLS and so on.
I just wonder sometimes with a lot of these fairly conservative companies is it too much to ask to -- for them to start using Cloud, so moving their IT into a shared data centre on a shared platform, and at the same time start using a network they've heard of but aren't actually using, or at least not consciously using, like Ethernet VPN, any to-any Ethernet type services and so on?
What's going to come first? Are companies going to start using Cloud and then put in place a network that needs to support that, or are they going to start using the network because of its own economic benefits and then look at adding Cloud on top of that?
So, to any of you, does anyone have a view on what the dynamic is?
I think that Cloud will be -- like other applications, if you want to call it an application, will be a trigger for these businesses. And I don't think they will have a problem with it at all, as long as the service provider is in there selling an economic value proposition for introducing Ethernet. And the trigger will likely have the customer consolidate the traffic -- their Internet traffic and other traffic they have. Maybe they have other layer three services etc and they will consolidate onto an Ethernet and treat those different traffic types.
So as opposed to using additional circuits, if you will, for Cloud traffic it'll just make economic sense to consolidate onto one. And you see that with other applications as well.
I think it's a giant trigger. And I think there's a very simple argument to highlight what's going on here. Back to my commentary before about the Cloud; we're really not very far into it. The number of places where real significant, large enterprise apps have been virtualised and, actually, lifted up and transplanted to multiple data centres is very small. And, I've got to tell you, in all the focus around applications we're ignoring the dead elephant on the middle of the table. It's all about the information.
The applications are simple. It's picking up a terabyte or a petabyte of deep information which is what makes these applications rich and useful and valuable.
And trying to move that from one side of the world to the other side of the world breaks every model. And all you have to do is stretch your application from your information about 20 milliseconds and suddenly everything stops working. And noone's really addressed that problem.
So as we really stop talking about the Cloud as this theoretical thing that we can demonstrate on our iPhone and we actually start having enterprise apps that are geographically distributed, that's where the network -- we talk about the network not being up to snuff. That's where the -- this part of the network which, historically, has been as much as we needed it to be, the number of apps that could break a 100Mb pipe were very limited.
Suddenly it's going to shine a giant spotlight on the fact that what latency and what real performance in geographic long haul you can get and the ability to guarantee that performance so that your enterprise apps don't suddenly go belly up or crash while you're trying to run this distributed environment. I think it's going to change the whole ecology in the service provider sector in long-haul data flow.
From my perspective, actually, again I think I've failed as a representative of a manufacturer, failed in my duty to actually -- if I don't manage to get a way to make that happen simply, quickly and easily. And I don't care whether it's Ethernet or IP.
Actually, the challenge must be how do I enable that to happen so the enterprise can move his storage into a distributed [machon] and it is always available.
And I don't believe we should force IT managers into worrying about whether it's Ethernet or IP; it's actually let's keep the focus on delay, latency, jitter, speed of deployment.
Yes, sure. And I was going to say if only we had someone on the panel who was offering 10Gb Ethernet services.
Well, more than that, we're also converting basically all of our capacity, so, all of our wholly-owned cables to support native Ethernet services on as well. So as a submarine cable layer we're going Ethernet as well. So we've already converted about slightly more than half a terabyte transatlantic to run Ethernet only and we're approaching that transpacific. And I think we're about 700Gb on intra-Asia and so on and so forth.
And the new Gulf cable is native -- supports native Ethernet day one at all laying stations. And the new Eurasia cable the same thing. So we have this legacy. We do have 1.2m individual international circuits on legacy STH platforms and that is a big number. But there is such a rush towards Ethernet services at every layer, whether it's at a submarine cable layer or it's at a services layer and so on.
And I think the difference for us is that we're coming at this as a challenger. We're not trying to protect that legacy STH platform or a frame relay platform we didn't build, or an ATM platform we didn't build. We're not trying to protect that. So we are encouraging that move. And I think that some customers are stuck with suppliers that are trying to keep them in what is easy for them to supply. I'm trying to deliver to a customer what they want or what they don't realise they need yet perhaps.
Great. I hesitate to ask if we had any responses to the survey. I notice the slide hasn't come up. It's that bad it's disappeared from view. Well, that will go straight into our next forecast. Thank you for that.
I think there's wise people out there.
Actually, I sort of recognise the numbers. 17, 33, 50 is not quite N=2. Was it N=5 or N=7 so it's not as bad as it could be. So pretty much in the middle. You do stuff that makes sense. You're not religious about it. A sensible result.
Ok, well, with that, I think we're back on track for lunch now. So I'd like to thank our panel for the discussion. Thank you to the audience. And see you later. Thank you very much.