Clouding the issue versus issuing the cloud Ethernet as both problem and solution
Date: Tue, 10/29/2013 - 11:34
Last may, James Walker announced the launch of the CloudEthernet Forum to “address the specific issues of scaling and applying Ethernet technologies to meet the stringent demands of delivering cloud services”. Judging by the response, he clearly hit a vital issue – but what does it mean in practice?
James Walker, President, CloudEthernet Forum (left) and Phil Tilley, VP, Alcatel-Lucent, at NetEvents Press Spotlight on The Cloud, Nice, France
Image credited to NetEvents
As James put it: “as datacenter networks become larger and more sophisticated, they are coming up against challenges…” But aren’t challenges just what you expect in any growing business? And isn’t the immediate solution to constrain your business model to fit what can be done, rather than fret about what might be possible?
To set things straight, we’ve invited James to team up with another CloudEthernet Forum member for this keynote. After a brief introduction, Phil Tilley, VP, Alcatel-Lucent will outline his story, explaining the service and spelling out the stages of development: the point where Ethernet scaling might become an issue, then where it began to impact performance, and then the business workarounds that were needed.
In response, James will take this example to illustrate current CloudEthernet Forum thinking. What is the core issue here? To what extent will it become a global issue? What would be a long-term solution? What interim measures might be advised? How would the CloudEthernet Forum address this?
As Sun Tzu write in The Art of War: “Know your enemy and know yourself and you can fight a hundred battles without disaster.” Following this presentation we will better understand those challenges.
James Walker, President, CloudEthernet Forum
Right, thank you very much. If I could also introduce my co-presenter, Phil Tilley from Alcatel. And this is really to give you, by way of introduction to the CloudEthernet Forum, but also what we're looking to achieve and why it's a larger problem for the industry. So we're going to do that by just sort of sketching out the problem, talking a little bit from Alcatel's point of view, why they've been involved in the forum and then I'll talk about some of the work that it's undertaking.
So just in terms of who is the CEF or who are the CEF depending on how grammatically you want to do it, so I'll cover off that, so who are the member organisations and so on.
Really, fundamentally the objective is to look at what are the challenges of scaling cloud environments for cloud service providers and users, enterprises and eventually you and me who have to use these services as well, particularly with the focus on Ethernet as the enabler of that and I'll explain why that is. And really what we're taking is an approach which looks at multiple different parts of the industry because this covers a lot of different players, network service providers, datacentre providers, equipment manufacturers and so on.
But really this all becomes driven by a customer requirement and that customer requirement is what we use every day when we connect to a service from Google or salesforce.com or Azure or Office 365 or SAP. All these sorts of things, these infrastructures need to react to where we're connecting to them, the information that we're allowed to see, the regulations that govern it, the reliability that needs to be in place so we that can build a business on it. So with that, I'll just hand over to Phil.
Phil Tilley, VP, Alcatel-Lucent
Thanks a lot, James. I think what I want to just do is sort of give a vendor perspective and what we see and the reasons why we think why we need another forum, specifically, the CloudEthernet Forum and sort of just talk, a couple of slides quickly and some of the background. And as a vendor, we're a member of many, many forums, many standards organisations and everything else and when again another one gets proposed, you look at it sort of quite critically and say, oh god, here's another excuse for another load of engineers and marketing people to travel around the world and cost us a fortune.
So I think it's worth actually sort of just dialling back and seeing why are we behind this one, why do we think it's relevant and why are we prepared to justify time and investment and money in it and hopefully then pass back to James to go through a little bit more of the detail on the forum.
So basically, I think everything we talk and hear about these days is everything is about the cloud, the cloud is everything. But basically if you look again and historically myself as a networking guy and you look and say, okay, if we look to cloud infrastructure, where is it and where are we in the preparedness to deliver cloud services.
And just generally, sort of very quickly looking at this cloud infrastructure scorecard, I think we're at a stage where virtualisation of compute and storage is there, pretty readily adopted. It's now very easy and possible to get obviously get compute online within minutes, if not seconds. It's virtualised instantly available and very easily consumable just by putting your credit card details over there.
However, the network is still at a space where it still takes days, weeks and very rarely hours to actually get the network connected and as easy consumable as that cloud. So I think we've still got a question mark as to how consumable the network is and that's one of the big industry challenges we're facing here.
So again as we move and take that forward into the criticalities of moving into this cloud era, what are the real critical issues that we have to worry about and overcome so we can actually get to a stage where the network is no longer the bottleneck for delivering new cloud services and applications. So again we need greater agility. We need services to be more instantaneous and that's network services in particular.
So again the datacentre and its component parts need to become a part of the network requiring automation and abstraction. So we need the network to become automated, we need to be able to abstract network capabilities and provide those up to the higher compute layer. So there's work ongoing on there, but it still needs to continue to evolve and there's a lot of focus in areas there. And some would say that's the area of SDN, but basically it doesn't matter what you call it, that's what has to happen.
Then also in this cloud area, the speed at which things are happening and doing is we're seeing we have to move from closed historical stovepipe developments as it were, fiefdoms of development, corporations being very guarded on their intellectual property. I think with the cloud era we're seeing much more openness and with that openness, we're seeing greater speed and development activity.
So again, we need to engage, as vendors need to engage more in the speed of change, constraints on development times. We need to share to really meet the consumer appetite for cloud based services. So I think through open collaboration we can resolve problems faster and so again as vendors, as a vendor that's very conscious and very aware that we need to work together with other parties and build an open ecosystem to make things happen.
And then there's sort of bridging domains. Again we've got IT systems providers doing application development, server virtualisation. All the compute storage stuff going on in the datacentre is one typical team or group or ecosystem of partners.
We've got the network vendors such as Alcatel-Lucent again, a group of people who understand how to get the Internet growing to the way it is, how to get traffic ever faster between multiple locations in a very clear managed, result reliable, multi tenant environment. And then we've got the service providers as well again.
Obviously trying to work to put these two elements and two groups together, I think really to make this cloud work and this is where the forum sort of starts coming in is actually we can't have HC doing one thing, IT doing something else and we need a forum where we can bring together the IT systems providers, the networking equipment vendors and the service providers.
And that really is where we saw the CloudEthernet Forum as the unique forum where these three groups can come together and really remove this divide between the network and the datacentre. So no longer, [inaudible] today there's a pretty strict divide at the edge of the datacentre. It's called a edge router that controls access lists from the datacentre to the network. We need to remove that barrier and remove that demarcation point so we can actually automate the delivery of applications from there through to end users.
So really I think that's where we see this forum coming together to bridge those domains through these sort of things. So really enabling the network to make the cloud. So from that, I'll pass back to James.
James Walker, President, CloudEthernet Forum
Thank you very much. So it all sounds complicated, right and that's good because it is. The cloud services market is interesting because it's grown very rapidly and it's grown very much more rapidly than I think anybody at least from the network side of the business or in some cases the equipment vendors and so on ever expected. And that's meant that there's been a series of attempts to fill in gaps, to patch solutions, to create things quickly to keep things moving forward. But there's not been a fundamental look at all the foundations that go to build up these platforms.
So cloud is happening. It's real, it's here today and it's growing very quickly. Now I think the infrastructure really needs to catch up with that growth. And at the same time, there are a lot of other things that are happening. We see a lot of changes in regulation. We see privacy concerns, particularly recently and so on and so forth. So how do we manage all of that?
So scaling cloud becomes very important. It can't be something where cloud is just a series of machines that sit within a datacentre and then that datacentre might be in the United States and then I go to Asia and my experience is very poor because I've got to connect all the way across the world in order to get to the resources I need to use.
The cloud needs to adjust; it needs to bring content that's close to me. It needs to continue to scale to very large numbers of machines and also have these datacentres which are close to the end users. So it can't just be a datacentre in the US, a datacentre in Europe, a datacentre in Asia. You need to get much closer to your customer.
So Ethernet is really the fundamental technology that today as soon as you take a physical server and plug into a rack, the network connectivity is then the Ethernet cable that plugs into the back of it. There may be all sorts of fanciness that then happens over the top of that, but that's the fundamental piece that's being connected. So Ethernet becomes something that exists at both ends of the equation. It's plugged into the server. It provides connectivity within the datacentre environment and it provides connectivity in the datacentre environment at the other end of the servers. The question is also what then happens in between those two Ethernet environments.
So Phil mentioned that there are a large number of different companies which are all impacted by this very rapid evolution in growth of cloud services, so I've named here five of them and so we can add as time goes on, a sixth one which is enterprises.
But datacentre providers, so these are carrier neutral facilities and so on. They themselves build very large datacentre environments with lots of customers in there. Their problem is how do you take several thousand customers and logically separate them from each other. These datacentre providers are now also providing interconnect services between different cloud services and different network operators.
WAN service providers, such as my employers, system integrators who then have the same task of moving customers from legacy environments, network equipment manufacturers such as Alcatel and cloud service providers themselves. So all of these have a stake in what gets built and we all have to work together in some way.
This was something that actually we worked up this morning in a session earlier with the CEF members and some prospective members just to give a visual example of what we're trying to address. This is a very complex example, but in fact it's almost the most common example we come across, which is a customer who has a virtual machine or an environment within their own datacentre and they want to be able to extent their network to a cloud service provider on the right hand side.
Now that then immediately involves four different parties just in the networking piece. So on the left hand side, you have the customer's datacentre environment themselves and whatever it is that they might be doing there or it might be an outsourced environment through a systems integrator. There's a network service provider that that's then responsible to take that to some mutual exchange or Ethernet hand off point which then provides connectivity into the cloud service provider and then eventually a virtual machine that sits within that cloud environment.
Now the customer's expectation is that they have one unified service experience that goes from end to end. But in fact a number of these parties do not provide SLAs around network performance. So typically an Ethernet exchange or an NNI point that often takes place as I said inside a carrier neutral datacentre facility like an Equinix or a 4sight typically doesn't provide any kind of network SLA. The cloud service provider, so the piece from the edge of their network up to the virtual machine they provide there's typically no SLA around that either.
What the customers ask is I need to understand what the network performance is all the way through that entity. And not only does this involve these four constituent providers, but underneath this there's a whole series of different equipment manufacturers that might be sitting there. There might be a different orchestration layer at the two ends. All of this needs to work together if we're going to have a proper end to end service and that's really the remit of the CloudEthernet Forum.
So what are we doing? We have a technical committee. We have a marketing and at the moment marketing and operations is combined, committees. So the technical committee is responsible for a White Paper that states the issue that we're looking to serve and that became available today and you've got access to that.
How does it get implemented? The marketing and operations, the operations aspect becomes more and more important later on because that talks about interoperability about how all those different parties might work together.
So we've done a lot. This is something that's gone very quickly. We launched in late May. We had our first face to face meeting in late July. Today in late September we delivered the White Paper which is the collaborative work of 16 companies.
So some of the technical issues that we're going to look at, I won't go into those in detail but these form a starting point for some of the technical aspects that we're going to look at in the initial stages.
And as time goes forward, we've got another face to face meeting in Seattle and then a board meeting. And then we're doing a similar event to what we did this morning where interested companies can come, hear what the CEF is doing and comment on the White Paper, to see how they can get involved. The next one of those we're doing is in Singapore in November. So this is really the areas that the CloudEthernet Forum is working on.
We're working very closely with the MEF. The MEF provides a intellectual property structure. It provides back end resources to support the forum. It reduces our cost to operate. It has a very robust model for bringing to market standards and certifications and so on. So we're very happy to be associated with the MEF and they're a very important part of it. It's helped us to get to market quicker.
So I think that's pretty much everything.
Manek Dubah - NetEvents
So I was interested, if I can pick up your last point first, in your relationship with the MEF. What exactly -- can you expand on what you mean? It sounds like you're doing a very similar job as the MEF in many ways which kind of also speaks to the question of why we need another forum, which I'm sure isn't just an excuse for a load of engineers to go swanning off around the world and meeting in exotic places. is it Phil.
So what is the relationship with the MEF exactly? Can you put a bit more flesh on that?
James Walker - CloudEthernet Forum
So the MEF as I said provides what I would call back office pieces so that allowed us to get to market much quicker than it would have and it's less costly for the members also that way. So that is the basic things like collecting membership dues and all that sort of thing. But it also provides us with a collaboration environment so we have Wikis and online tools to collaborate. And the White Paper was entirely pulled together was using just online tools and online collaboration.
So it's a big departure away from the traditional way of bringing together these sorts of things where you'd have face to face meetings and conference calls and you'd exchange Word documents and that sort of thing. We understand that's not going to deliver results fast enough, so we can draw down on the MEF's tools.
So there's that and I mentioned it, but I will say it again. The intellectual property rights structure that the MEF brings is great and it's a problem that has plagued some other forums that the members are reluctant to participate because they feel that they are giving up the rights to their intellectual property. They are giving up their rights to the intellectual property that they bring to the table to the forum. Here we have a robust environment of more than 200 companies have already signed up to previously. Where does the split between CEF and MEF actually come? The MEF is about end to end service definition of Ethernet services. So I fully expect that the CEF will identify certain areas which are best handled by the MEF. So the E-NNI there that I referred to, that's a standard that's been referred to by the MEF. It's been brought together, built up by them and agreed to by their members. But it may need to be adjusted, expanded, developed or whatever it is to meet the needs of the cloud.
Similarly there are other things which might be protocol level things that could be better off in the ITU or the IEEE or whatever else it is. Again the CEF then defines the problem, the use cases if you want and then takes it and sort of husbands it through the process. So that's kind of the split.
The CEF is looking specifically at the infrastructure challenges faced by cloud service providers of which Ethernet services are a component, but there are also many other pieces of the puzzle so as I state at the end to end of how that service is managed and provisioned and looked after and traffic is directed and all those sorts of things.
So Phil what would you say was the -- it's quite a complicated message to put across I think. What would you say, if you're addressing a room full of journalists, what is the top level goal of the CEF and why would they care?
Phil Tilley - Alcatel-Lucent
So the goal is really to allow us to bring to market -- to break the barrier between the datacentre and the network to bring cloud services affordably to market for enterprises, big and small enterprises. And it's really again creating a forum where we can bring together multiple parties without any preconceived ideas that it's a networking forum or it's a datacentre forum. It's actually we want to bring that to market.
One of the reasons why and the advantage of bringing it under MEF is it actually gave us a quick bootstrap start as it were. Because the infrastructure was there, we didn't have to build a new forum from scratch. The facilities are there so we can actually get operational much, much quicker to address this problem, because the market is moving so fast.
That also speaks to the question about there's a number of other cloud standards bodies around, some more or less successful than others. What's your relationship going to be with those?
As I said, I think what we do is we represent the needs of the members. The members have said that there are things which are -- you said, well, this is another forum and it's another opportunity. So it's been interesting and I've said this earlier today in fact that on the one hand, I've got people saying well you know it's another forum and all that sort of thing, why should I join. On the other hand, I've had a ton of companies come to me and say could you look at this because it's not being addressed anywhere else, it's related to cloud, it's a real barrier to growth.
So for example?
Storage, storage standardisation is one thing. There's a lot of disparate different ways to connect storage area networks together, standardise that, put it on a [commodity] platform like Ethernet, much more scalable, much higher speed and all that sort of thing. But that requires wide industry adoption. It's not just one or two vendors deciding to do it. It's cloud service providers, it's network service providers, it's all of these, equipment manufacturers all working together. So it's those sorts of things.
So I think that the question of how we interact with other forums comes down to the pieces which we need to own end to end, so the sort of the end to end customer experience SLA provisioning piece, all that sort of thing that needs to be owned end to end. But we don't need to do every component of that.
So if it's a problem, that's best addressed at the control plane then we can take that to the ONF and we have a relationship with the ONF. If it's something that needs to be done as I said at protocol level then its IEEE or ITU or whatever. If it's purely an Ethernet service definition, then we'll take it to the MEF. But then we still have the responsibility to see it through that forum. And then there's a whole piece that sits in the middle which is the guts of what the CEF looks after.
So Ethernet and where it's headed and where it's going with its popularity and growth it's becoming almost a tradable commodity almost. So people want to -- to deliver a service, an Ethernet service it's a number of different segments of Ethernet and you can buy and sell those Ethernet segments in the middle from different operators. As you do that you need to actually be able to make sure that when you do go and buy an Ethernet segment that fits into the chain and is instantly operational.
And so it's that speed of bringing that connectivity at the same time as you can bring your computer on board. And that's quite a challenge to get all those pieces working in an automated fashion.
So kind of the difference -- sorry Phil, just picking up on James' point is that the MEF got on board with the equipment manufacturers and persuaded them to build standardised ways of interconnecting and putting services on top of their basic network base I suppose, where instead your approach is to go through the standards bodies. Now isn't that a much more difficult and complex thing to do?
I wouldn't say my approach is to go through the standards bodies. I would say that so, what the MEF has done very well is to bring together equipment manufacturers, network service providers primarily to define end to end Ethernet service requirements. What we're doing is we're saying okay, you take that same model and you make it larger because the number of players involved in the cloud space is bigger. It's not just network service providers, it's not just equipment manufacturers. It's also cloud service providers, it's people who make orchestrations software for cloud environments, it's the cloud service providers themselves.
And Phil alluded to it as well. It's the people who design and build networks today and the people who design and build datacentres and applications and all that sort of thing very rarely interact. And so a whole lot of stuff is being done within the datacentre within the application environment that is simply not supportable today in the network environment and the network doesn't meet the requirement end to end. These things can't operate in isolation, they have to be bridged.
So take the MEF approach but expand it larger because the ecosystem that it supports in cloud is bigger and has other players in it. And that's indeed why you see that several of the founding members of the CEF are in fact not MEF members. So people like Citrix for example coming at it from an orchestration point of view, and HP which covers a whole variety of things, system integration, orchestration, all sorts of things and equipment manufacturing as well, so different sorts of people and [inaudible] as well. So obviously it's meeting the need of a community that was not served in its entirety by the MEF.
Okay, thanks. Questions. Analysts always have questions.
Greg Ferro, Blogger
My name is Greg Ferro. I'm from a bunch of places. Network computing is what it says on my badge.
Ethernet in a way has been thoroughly discredited over the last three to five years as a datacentre interconnect technology and there's a widespread move amongst datacentre designers to abandon the concept of DCI as a move. And that's largely been evidenced in the new set of technologies we have which do Ethernet avoidance or Ethernet bypass. Are you sure, because you're very confidently stating that there's a demand for Ethernet end to end which strikes me as comedy? So where's the demand for Ethernet end to end?
I'm not necessarily saying that there's a demand for Ethernet end to end and different companies have got different views on that. And it becomes very much a religious debate as you identify. But I'm certainly saying that there is a requirement to hand over between service providers at different times, cloud service providers and network service providers a large amount of stuff which generally is going to be Layer 2 based.
Why? Because from a service provider point of view and from a datacentre, carrier neutral datacentre operator point of view and indeed, from a cloud service provider point of view, we don't want to get directly involved in the customer's IP addressing and routing and all that sort of thing.
So from a logical separation point of view it makes sense to do that at a Layer 2 and it makes sense to do that across these sort of Ethernet exchanges which are being built up to also become more cloud exchanges and those are Layer 2 based. So Layer 3 absolutely exists. At Layer 3 and all the various encapsulation technologies that sit over the top of that exist, have a place, and continue in that direction.
So I don't think we're looking to supplant that. But if I, as a service provider have a requirement to hand over 5, 10, 15, 1,000 customers to a Google and/or an AWS and/or and Azure through some sort of switching fabric, I need a way to do that.
I would also take to task, I'm not sure where the data comes from. But certainly it's the first I've heard of sort of that people are trying to bypass and avoid Ethernet. We actually look at the Ethernet service, wide area service growth, there actually it's one of the fastest growing services and a lot of that is because of its resiliency and reliability in the delivery of services from datacentre to end users. So I haven't seen or heard the sort of sense that people are trying to bypass and ignore Ethernet.
Ethernet is becoming the fundamental transport from datacentre to large enterprise sites for many, many applications and services. There may be some things being run on top of Ethernet as well, but basically and fundamentally there's an Ethernet infrastructure there to provide datacentre interconnect and datacentre to end users. And that's where service providers see massive growth in that service uptake.
So the question was just because people may not have heard that, he said, he thinks it's because service providers are selling it, not because customers want it.
No, I'd argue that service providers sell is an MPLS service in fact which is not Layer 2.
Peter Hall - Ovum
My question actually was on the very same theme. I find it somewhat strange and absurd that it's called the CloudEthernet Forum instead of the Cloud Networking Forum especially when it's chaired by James who runs the networking activities, not just the Layer 2 activites for Tata.
I mean if you look at enterprises toady, most of the interconnect is at Layer 3. Either it's public Internet or with perhaps virtual private cloud services it's MPLS. And whilst we all know Ethernet will have an important part to play, surely the issue is about networking and cloud, not Ethernet and cloud. And I just find it strange that you've just picked on one networking technology and built the forum around that.
I think to me there's a layer cake of problems that need to be solved in one form or another for a scalable datacentre environment and datacentre interconnect.
So there's an overarching orchestration layer, there's an overarching control plane and all that sort of thing. That seems to me well served. There is a lot of activity in that space and there are a number of forums that address that piece. So whether you look at it as an SDN problem, an open flow and all the rest of it or you look at it in SPB or whatever else it might be, there are a variety of things that look at that.
Similarly at Layer 3, there's quite a lot of work being done in V03 and all the rest of it and depending on what you look at with NVGRE and VXLAN and all the rest of it, whether they're Layer 2 over Layer 3 or how you want to represent them, there's a lot of work that goes within that.
But even just at a basic working level, if you take a datacentre the size of what's being deployed today and 1.4 million VLANs in a datacentre is being publicly announced by various companies as a scaling thing, that immediately has Ethernet implications irrespective of anything you might want to do over the even just within the datacentre building. There are nt switches that are made today with the ability to take that size of that compressed table, whatever else might be required.
So you can say well, we can take all of that away and we can encapsulate it and all that sort of thing and take the problem out of the switches, but then you have the problem of then carrying it across the WAN. And our issue from a service provider perspective of carrying an encapsulated and tunnelled protocol is that we can't measure it, we can't manage it, we can't provide end to end OAM around it. We have no visibility of it; we have to de-pack and inspect to find it.
So I think that -- I mean it's overly simplistic to state it this way, but there are multiple pieces that go to make up a datacentre interconnect. One is, if you like, the railway line that exists between the datacentres which I see as being the transport layer and that's really what I'm addressing here. Then there is the train that goes over the top of it and how you pack that train and what passengers are in it and all the rest of it. I see that as being really Layer 3 and so being the encapsulation that goes on, on top of that. And then you have a whole signalling system and everything that sits over the top of that which is for me the control plane and so on.
We're looking at making sure that the railway line is fit for purpose. It doesn't break under the strain of the amount of rail traffic and whatever else it might have to cover. There are other forums which are occupied with what the train is doing and where it's going.
Okay, bear in mind that this next session coming up immediately after this is going to be dealing very much with this issue of datacentre interconnectivity and there will be opportunities to ask questions after that. And I think both of these esteemed gentlemen are on the panel for that.
So if there's no further questions, I just want to ask one question, if I may, which is perhaps one definition, which I've just made up of a good forum or a good body, industry body is one that knows when it's had enough, when it's time to say okay, we've done the job, job done, time to go home. What's your measure of success?
So I think what you're talking to at the moment is a forum that has got in fact more work than it can do in terms of what's being delivered to it. So it's hard to, at this point to see the other side of that pile.
The fundamental objective here is to make sure that Ethernet is fit for purpose for the demands that are going to be put on it. That could be an early task and it's already over according to the audience or it could be a long term task. But Ethernet has kept going for 40 years. It seems to be fairly well established, so I'd be bold to be calling its demise I think at this point. So success looks like Ethernet not getting in the way of what's needed for the cloud really.
Okay, James, Phil, thank you very much indeed. And a quick round of applause for them perhaps. Thank you.