Categories
Alan Weissberger Cloud Computing Software Defined Network

2013 TiECon- Part 3: Software Defined Infrastructure Presentations & Panels (Continued)

Introduction:

In this third and final article on the information packed 2013 TiECon, we summarize key messages from the second half of the SDI Track on May 17th, including the afternoon keynote and two panel sessions. The first article covered all of the TiECon opening keynotes. The second article summarized the invited SDI presentations from the morning of May 17th (but not the panel sessions covered in this post).


PM Keynote: Software Defined Infrastructure – The Coming Wave of Datacenter Disruption

by Steve Herrod, PhD -General Catalyst Partners #

Large Data Center (DC) operators are under great pressure as they attempt to learn how to bring the benefits of public clouds to their DCs.  Those benefits of the cloud include: agility, flexibility, scalability, and reduction in total cost of ownership. The DC operators recognize they have to rebuild their DC infrastructure to realize those goals.  Compute server virtualization was the first step – it’s been widely deployed and has been hugely successful in improving efficiency and lowering compute system cost.

In the Software Defined Data Center (SD-DC), all infrastructure (compute, storage, network, management) is virtualized and delivered as a service. Control of the DC is then entirely driven by software.

Software Defined Storage is emerging together with a new class of applications. The objectives here include:

  • Move compute (servers) closer to storage
  • Make use of local disc and flash memory
  • Get better utilization of flash memory
  • Take advantage of economies of scale (e.g. get good pricing on memory)
  • Auto provisioning
  • Common automated management across all tiers

Today’s network can be a barrier to effective cloud computing. Network virtualization will help break that barrier. It provides a separate logical view of the network to services and applications, which is independent of how the physical network is laid out (topology) and implemented. Automated management should be an adjunct to Network Virtualization (logically off to the side or on residing top of it).

How to bring efficiency and automation to high level services in the SD-DC? Steve recommended the following:

  • Migrate entire DC (and beyond) to SDI.
  • Traffic management and security policies should be part of SDI.
  • Bring firewall and intrusion detection close to workloads, which results in a tighter security policy.
  • Provide “Instant” provisioning of the network (L2-L3) as well as L4-L7 services.
  • Provide Disaster Recovery (DR) without the need for pinging.
  • Management should wrap all of the software-defined services together.
  • Treat SDI management as a “big data problem.”

The figure below is a candidate solution for the SD-DC.  It depicts a Software Defined Network with Open Flow protocol used to communicate between the Physical Network (Data Plane) and centralized SDN Controller (Control plane):

Software Defined Network is shown with OpenFlow control.
Image courtesy of IBM

Panel Session: Software Defined Networks (SDN) Adoption — Crossing the chasm from Early Adopters to Mainstream:   Google, NEC-America, Orange-Silicon Valley

Key points made during this panel session:

Google:

There’s a steep growth in number of network users, need for more bandwidth, different types of information (e.g. video) transmitted, and a variety of services delivered over broadband networks. But the network “economies of scale are now terrible.” SDN provides better management, orchestration and control of network resources.

Global knowledge of the network topology facilitates quickly moving functionality from one (Google) DC location to another. Note, Google’s first SDN implementation was in an internal network which interconnects all their DCs.

“The industry needs more clarity in terminology, e.g. SDN, Open Flow, NFV, NV, etc.”

NEC-America:

Commonality is needed across all parts of the IT infrastructure (compute, storage, network, management). In particular, for auto-provisioning, service automation, and interactions with the rest of the system. More network interactions with many more devices, appliances, load balancers, etc. calls for a new, software based approach to networking. SDN may be used in Content Delivery Networks (CDNs) (No explanation or justification was provided).

There are still a lot of gaps in SDN before it can become mainstream. These include: QoS control, scalability, details on orchestration/provisioning, and network resiliency (protection and/or path restoration on failure). SDN also needs more business drivers to create a mass market.

Orange-Silicon Valley:

How do we innovate while ensuring openness for the Data Plane? At a minimum, the Data Plane needs to access flow tables and semantics (from the Control plane) in a standardized way (ONF is standardizing Open Flow for that very purpose).  Standardized communication between Control and Data Plane will lead to reduced CAPEX and (more importantly) OPEX for network operators. It will also facilitate the creation of new revenue generating services for network service providers, like Orange. Telcos should think of the network as a service (NaaS), with greater agility and lower OPEX than current networks offer.

ETSI NFV is adjacent to SDN. There are mobile network use cases for both. How SDN and NFV are related is an open question. Look at the mobile packet core (Evolved Packet Core =EPC for LTE) as a good place to virtualize the network.

We need a full implementation of SDN (not just Open Flow) as well as truly open APIs to have a programmable network. Network as a Service is not quite here yet. We need to personalize the network first, i.e. the user “owns” the network for a particular session.


Panel: Architecting a Scalable Software Defined Networks (SDN) Solution: Juniper, Cisco, Big Switch

Key points made during this panel session:

  • Cloud computing, mobile data & connections, and social networking are all putting pressure on the existing network infrastructure (both wireless and wireline).
  • Users want more control of the network and more automation.
  • Need a level of abstraction that we don’t have today.
  • Juniper: SDN can provide more control of the network while being decoupled from network equipment and devices.
  • Big Switch: Industry needs to bring good software design into network architecture. This includes: loose coupling, modularity, APIs in between layers.
  • Cisco: SDI solutions for network service providers will be different than those for enterprise or Data Center customers.
  • Cisco: IT organizations are not set up to take advantage of SDN and this represents a barrier to adoption. There are also perceived risks with any new technology (such as SDN). IT skill sets need to change to take advantage of what SDN can offer.
  • Big Switch: Corporate culture and skill set gap is an issue for SDN deployments. “It will take people a while before they can wrap their minds around SDN.”
  • Juniper: SDN will simplify the network and lower barriers to adoption. If using SDN makes a company more efficient, it will realize more revenue and be able to do more with less people, e.g. network administrators.
  • Juniper: What is the correct abstraction for networks? He doesn’t know if SDN is the answer and doesn’t believe in standardized APIs that enable users to “program the network.”
  • Big Switch: Open Daylight consortium (open source software) will permit everyone to leverage a commodity SDN controller.
  • Cisco: Industry needs to bring eco-system together to avoid market fragmentation (this author thinks that this is the #1 stumbling block to SDI).
  • Big Switch: Customers (users) care about benefits of the application(s). They don’t care about implementation details of SDN.
  • Juniper: DC scale is huge. We have an agile compute infrastructure now (through server virtualization), but the neither the DC network or storage is agile or efficient. That’s the big opportunity for SDI. He recommends configuration of the DC network to handle storage information exchanges, as well as packet forwarding for compute tasks. Note, that’s a huge change from the current DC environment where there are separate networks for storage (Fiber channel based SANs) and compute (Ethernet).
  • Big Switch: As everyone is working on SDN for DC networks, start-ups should look for less crowded SDN opportunities. Those might include: campus LAN, enterprise networks, or mobile networks (campus and wireless telco). Advice: be focused and nimble (they are opposites of one another), be prepared to go from plan A to plan B, carefully pick the ecosystem to work in and not do anything else.
  • Cisco: A great start-up opportunity is SDN professional services and support. Start-ups should “go where no one else is.” He says, “Plexxi stuff is awesome.” Pick something to work on that gives you a sustainable advantage over the competition.
  • Juniper: Start-ups should focus on their value add when making the key decision of what to do and not do in the SDI space. “Think about how you are going to make your first dollar and who is on your leadership team.”
  • Cisco: SDN is a tool that may solve customers problems. (No explanation or justification provided)
  • Juniper: Customers say “I want SDN. What is It?” That indicates potential SDN users are confused by all the hype and vendor claims.

A Service Provider view of SDN– Victa McClelland of Ericsson

Victa talked about Ericcson’s SDN trial with Telstra. Due to time and space limitations, we can not cover it in this article, but refer the reader to this Ericsson presentation from 2013 Open Network Summit: SERVICE PROVIDER SDN MEETS OPERATOR CHALLENGES

Panel: How do you manage the Software Defined Infrastructure (SDI) – Use Cases and Technology : AppDynamics, BMC, VMWare

Again, due to time and space limitations, we can not cover this panel session in this article. However, we emphasize that management will be a crucial component of SDI. There are no standards or open specifications for SDI management at this time, so it will be vendor specific for quite some time.

http://tiecon.org/content/how-do-you-manage-software-defined-infrastructure-sdi-use-cases-and-technology

Closing Comment:

We hope readers enjoyed this three part series on 2013 TiECon, which highlighted the SDI Track sessions. We will be covering more of that topic in future posts, including the SDN related sessions and discussions at last week’s Global Press & Analyst Summit at the Computer History Museum in Mt View, CA.  Bob Metcalfe’s closing keynote is at:

http://community.comsoc.org/blogs/alanweissberger/bob-metcalfes-closing-keynote-ethernet-innovation-summit-may-23-2013-chm-mt-vi

Author Alan Weissberger

By Alan Weissberger

Alan Weissberger is a renowned researcher in the telecommunications field. Having consulted for telcos, equipment manufacturers, semiconductor companies, large end users, venture capitalists and market research firms, we are fortunate to have his critical eye examining new technologies.

11 replies on “2013 TiECon- Part 3: Software Defined Infrastructure Presentations & Panels (Continued)”

Very well done indeed! More detailed than anyone else who covered TiECon this year. It is interesting that some speakers thought the startup opportunity will be in the SDN/SDI integration space. TiEcon 2013 even had a session with Cisco discussing that in the professional services track on Saturday.

Paul, Thanks very much for your comment below. Could not attend Sat TieCON so I missed the Cisco talk you referenced. Is a replay available anywhere?
The Friday May17 SDI panels stated there were 2 distinct start-up opportunities within SDI space:
1. Professional services, systems integration, management, etc.
2. Building (software) products or services in areas where others have not gone. That might be anything other than the Data Center which is currently the focus of most SDN/SDI start-ups and legacy equipment vendors like HP, Dell, Juniper, Cisco, etc. One SDN start-up opportunity might be wireless campus networks. Another might be the mobile packet core for 3G+ and4G-LTE.
SDN/SDI for a telco/network provider will look very different then SDN for a data center implementation. And neither might go with SDN. Instead, it might be network virtualization (as VMWare has chosen) rather than either pure SDN or overlay model with duplicated control planes!

Thanks Alan for writing this very comprehensive series of articles about the TiEcon event.

Based on Orange’s comments, it seems like SDN/SDI has the potential to reduce Capex and Opex. Still, as pointed out repeatedly in the article, the questions regarding standardization/open APIs will slow deployment and cause marketplace confusion. Still, it does seem like at some point SDN/SDI is something new entrants into the Data Center business could use as an advantage, given the lower cost structure.

The on-going development of SDI/SDN is something that telecom operators will need to monitor, as this approach could be their edge as they increasingly move into data center services.

Alan:

Great write-up and very detailed. Just to expound on the “SDN is a tool” comment (since I made it), the point I was trying to make to the audience is that their focus should remain on fixing customer’s problems–SDN might be a tool to help them do it better than anyone else, but its not a destination all by itself.

Regards,
Omar (@omarsultan)

Omar,

You are so right about SDN being a tool. This is why I think some of the discussion about SDN definitions, while academically intriguing, might not be terribly relevant in actual customer deployments. Whether something meets all or some criteria is interesting to categorize it, but the real measure is whether it does something useful in a way that is pleasing (for some definition of useful and pleasing).

-Mike (@mbushong)

But Guru Parulkar insists that pure SDN is the way forward- with all new network infrastructure! Is that only for greenfield deployments or legacy network providers as well?

I submit that there will be very few pure SDN Open Flow implementations near term, because network owners will not be willing to ditch their existing equipment and start over again. Hence, I see the overlay model as being most popular, but that will likely be based on vendor specific implementations of SDN or Network Virtualization (e.g. VMWare)

Wonderful article with a lot of depth. Panelists points were particularly enlightening.

My question is whether telcos/network SPs will support true SDN-Open Flow in their WANs/cloud service delivery networks?

Anand,

I think some of this will depend on definition. OpenFlow plays a role but is not sufficient to drive some of the new services that need to be created. I expect there to be a suite of SDN protocols that includes OpenFlow but also Path Computation Element (PCE), BGP-TE, Application Layer Traffic Optimization (ALTO), Interface to the Routing System (I2RS), and others.

These will join efforts to do things like service chaining (think NFV type stuff).

The real technical question here is how these converge from an orchestration point of view. Pure OpenFlow controllers will lack additional protocol support needed to truly manage the service. We already have OF controllers, PCE servers, and the like. These will need to converge, else we have traded a bunch of appliances for a bunch of controllers.

This is where I think efforts like OpenDaylight can really help. A common operating platform with extensibility as a goal can be a tremendous help. It creates a management platform while not requiring those that would innovate to spend cycles reinventing some of the baseline functionality. It’s a win for everyone – vendors and customers.

-Mike (@mbushong)

While I don’t know what SPs are planning for SDN-Open Flow, I do know that many of them are participating in ETSI NFV ISG. It remains to be seen if any specifications come out of that activity that might lead to implementations of Network Virtualization.

Blog Post by Alan Earls:

The data center of the future could lead to a software-defined infrastructure, but current technology is still relatively immature, with more work needed in the area of automation.

Eric Hanselman, research director for networking at 451 Research in Boston, agrees that the software-defined data center (SDDC) is about improving integration, as well as about automation. The goal is to take activities that often involve physical changes and manual processes, and integrate them with other, more automated data center practices, he said. The starting point is virtualization.

“You have to have a certain amount of abstraction to deal more flexibly with the various resources,” Hanselman said, “but the real value is achieving a higher level of management integration. It doesn’t have to be cloud initially, but it is going to look like cloud.”

An SDDC’s primary goal is to make it easier to change server, storage and in particular, network configurations. An SDDC does that, Hanselman explained, by automating the partitioning of the entire data center infrastructure and spanning that architecture, and by scaling and thus delivering much greater efficiency. At the moment, it is still early days for adopting an SDDC, he said. So far, the organizations that are building hyperscale data centers are those blazing the trail for these data centers. “There have been some widely discussed implementations, particularly Google,” he said.

Google has done interesting things to shift internal capacity dynamically using homegrown applications and its own OpenFlow control switches, Hanselman said. That has been further supplemented by having a dynamic scheduling system that shifts capacity as systems perform more traffic-intensive activities, such as replication.

There are two major players in software-defined infrastructure, according to Hanselman. Nicira’s (now VWare) Network Virtualization Platform, or NVP, enables the dynamic creation of a virtual network infrastructure, as well as services that are completely decoupled from the physical network hardware. Big Switch Networks offers what it calls “open software-defined networking (SDN).” Hanselman said both companies aim to use virtual connections across virtualized environments, then extend their reach through tunnels into other virtualized environments.

http://searchdatacenter.techtarget.com/tip/The-downsides-of-a-software-defined-infrastructure

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.