reports.informationweek.com august 2013 $99 2013 sdn ... · 2013 sdn survey: growing pains while...

August 2013 $99

Report ID: R7240813

Next

reports

2013 SDN Survey: Growing PainsWhile vendors map software-defined networking strategies and

roll products out the door, IT is wary; 33% have no plans to

test SDN technologies, and 47% cite product immaturity as

a barrier to adoption.

By Ethan Banks

reports. informationweek.com

http://reports.informationweek.com/index

Previous Next

reports

3 Author’s Bio

4 Executive Summary

5 Research Synopsis

6 IT to SDN: We’ll Wait and See

10 Software-Defined FUD

11 Focus on Benefits

12 A Lack of Certifications

14 OpenDaylight and OpenFlow

17 Startup Opportunities

18 Cisco and SDN

22 Recommendations for Potential Customers

24 Appendix

37 Related Reports

Figures

6 Figure 1: Timeline for Testing SDN

7 Figure 2: Familiarity With Software-Defined

Networking

8 Figure 3: Familiarity With OpenFlow

10 Figure 4: Percentage of IT Budget Allocated Toward

SDN Implementation

12 Figure 5: LAN Challenges Mitigated by SDN

13 Figure 6: SDN Selling Points

14 Figure 7: Barriers to SDN Adoption

15 Figure 8: Perception of OpenDaylight

17 Figure 9: Predicted Network Format

18 Figure 10: Willingness to Purchase SDN

Technology From a Startup

19 Figure 11: Familiarity With Vendors’ SDN

Strategies

20 Figure 12: ‘Dumbing Down’ of Switches

and Routers?

21 Figure 13: Reasons for Buying ‘White-Box’

Switches

22 Figure 14: Expected Impact of SDN on

the Switch and Router Market

24 Figure 15: SDN Production Timeline

25 Figure 16: Willingness to Make

Architectural Changes for SDN

26 Figure 17: Impact of SDN on Network

Security

27 Figure 18: SDN Security Benefits

28 Figure 19: SDN Security Problems

29 Figure 20: Attitude Toward OpenFlow

30 Figure 21: Use of OpenFlow to Build

an SDN

31 Figure 22: Percentage of Future IT Budget

Allocated Toward Revamping the

Network for SDN

32 Figure 23: Best SDN Strategy

33 Figure 24: Job Title

34 Figure 25: Industry

35 Figure 26: Revenue

36 Figure 27: Company Size

CONT

ENTS

reports.informationweek.com

TABLE OF

August 2013 2

2 0 1 3 S D N S u r v e y : G r o w i n g P a i n s



August 2013 3

Previous Next

© 2013 InformationWeek, Reproduction Prohibited

reports


2 0 1 3 S D N S u r v e y : G r o w i n g P a i n sTable of Contents

Ethan Banks is CCIE No. 20655 and a 16-plus-year IT veteran. He has designed,implemented and supported networks for government, banking institutions,higher education and various corporations. He is a host of the “Packet Pushers”podcast and an independent blogger covering the data networking industry.Ethan Banks

InformationWeek Reports

FollowFollowFollowFollow

Want More?

Never Miss a Report!



https://twitter.com/#!/IW_Reports

https://www.facebook.com/pages/InformationWeek-Reports/149825495070501

August 2013 4

Previous Next

Software-defined networking is a work in progress, as vendors map out their strategiesand slowly bring products to market. Enterprise buyers, at present, have decided to sit onthe sidelines and wait to see how SDN plays out. That’s according to the results of Infor-mationWeek’s 2013 Software-Defined Networking Survey, which collected responsesfrom 267 IT pros across North America. In this report, we’ll look at the state of SDN in the marketplace and examine the survey

results. We’ll also outline what a typical SDN infrastructure looks like in 2013, including acontroller, programmable infrastructure, applications and network multitenancy. We’ll diginto both OpenDaylight and OpenFlow, two open source initiatives that are shaping SDNfrom outside. We’ll also discuss Cisco’s SDN strategy, and where it aligns and divergesfrom other efforts. Finally, We’ll offer guidance for network professionals on how to ap-proach bringing SDN into their own environments.

EXECUTIVE


reports

SUM

MAR

Y




August 2013 5reports.informationweek.com

Previous Next

RESEARCH

Survey Name InformationWeek 2013 Software-Defined Networking Survey

Survey Date July 2013

Region North America

Number of Respondents 267

Purpose To determine attitudes toward and awareness and adoption of software- defined networking in the enterprise

Methodology InformationWeek surveyed business technology decision-makers atNorth American companies. The survey was conducted online, and respondents were recruited via an email invitation containing an embedded link to the survey. The email invitation was sent to qualified InformationWeek subscribers.

reports

SYNO

PSIS


ABOUT US

InformationWeek Reports’

analysts arm business technology

decision-makers with real-world

perspective based on qualitative

and quantitative research, busi-

ness and technology assessment

and planning tools, and adoption

best practices gleaned from

experience.

OUR STAFFLorna Garey, content

director; [email protected]

Heather Vallis, managing

editor, research;

[email protected]

Elizabeth Chodak, copy

chief; elizabeth.chodak@

ubm.com

Tara DeFilippo, associate art

director; [email protected]

Find all of our reports at

reports.informationweek.com.



mailto:[email protected]

To hear some tell the tale, software-definednetworking is going to change all of IT. Ven-dors are sending starry-eyed engineers andhype-mongering marketers into the network-ing fray with a passionate message aboutSDN’s transformative powers. Despite this fer-vor, few companies have bought into SDN, aseither a concept or a set of technologies. Arethey interested? A little bit. Are they findinguse cases? Some are, and with good reason.But as InformationWeek’s 2013 Software-Defined Networking Survey demonstrates,many IT professionals are taking a wait-and-see approach. In my discussions with the network engi-

neering community, I see two SDN campsemerging. A few networkers are enthusiastic;they see SDN as an enabling technology thatallows them to virtualize their networks inflexible ways. But as evidenced by our survey,most networkers are standoffish when itcomes to SDN. Case in point, 33% of respon-dents have no plans to even test SDN tech-

Previous Next

2013 2012

What is your expected timeline to test SDN?

Timeline for Testing SDN

We're done testing; SDN is in production now

We are testing

Less than six months

Six to 12 months

More than 12 but less than 24 months

More than 24 months

No plans to test SDN

Don't know

Base: 267 respondents in July 2013 and 250 in July 2012Data: InformationWeek Software-Defined Networking Survey of business technology professionals

R7240813/2

4%4%

12%5%

8%7%

13%14%

13%17%

10%10%

33%30%

7%13%

R


IT to SDN: We’ll Wait and See

reports 2 0 1 3 S D N S u r v e y : G r o w i n g P a i n sTable of Contents

Figure 1

August 2013 6



August 2013 7

nologies, while another 23% say it will be atleast 12 months before they start (Figure 1). Respondents had to have some level of fa-

miliarity with SDN in order to participate inthe survey: 45% say they understand the ba-sics and 15% consider themselves very famil-iar (Figure 2). That’s not bad, considering hownew SDN is, as both a concept and a set ofemerging products.However, it’s one thing to be aware of a

technology and another to be ready to em-brace it. One challenge to SDN acceptance ishow quickly the technology develops. Estab-lished vendors have different approaches thatare shaped by existing product lines, whilestartups take a clean-slate approach that mayappear to IT to be a radical departure fromhardware and software in which they’ve de-veloped their expertise.In addition, vendor SDN implementations

often don’t interoperate. A buyer is in theprecarious position of having to choose SDNproducts that are both compatible with theirexisting network infrastructure and comple-mentary with other SDN building blocks

they might be considering.However, despite the disparity of SDN prod-

ucts and components, a framework has coa-lesced. No matter what vendor’s SDN productset you consider, the major components willlikely include a controller, programmable infrastructure, applications and support fornetwork virtualization (multitenancy). Let’stake some time to examine each of thesecomponents and explain how they form anSDN framework. This foundation will help

frame the analysis of the survey data.Let’s start with the controller. An SDN con-

troller has one major function: It’s the arbiterbetween applications that require the networkto behave in a particular way and the underly-ing network devices themselves. The idea of anetwork application is that it allows an organi-zation to describe specific business require-ments that the network will then fulfill via apolicy. The application translates what the busi-ness needs into technical directives that the

Previous Next

FAST FACT

33%of our survey respondents

have no plans to test SDN

technologies, while

another 13% say it will be

at least 12 months before

they start.



2013 2012

How familiar are you with software-defined networking, or SDN?

Familiarity With Software-Defined Networking

Very familiar; I understand the details

Familiar; I understand the basics

Somewhat familiar; I have a general idea of what it's about


R7240813/1

15%17%

45%35%

40%48%

R

Figure 2



August 2013 8

Previous Next

The Virtual Network:TRILL, SDN and More

Virtualization forces data centernetworks to become more flexible and efficient. Networkengineers have a bewilderingnumber of options to supporthighly virtualized environments,from fabrics or meshes built onprotocols such as TRILL and SPBto Layer 2 extensions that sup-port VM mobility between datacenters to software-defined networking. This report breaksdown standards-based and proprietary options for buildingnext-generation, virtualization-centric networks.

DownloadDownload



controller understands. The controller thentranslates those directives into programmaticnetwork commands the network infrastructureunderstands. Thus, the network is configured.To perform the role of arbiter, a controller

will have knowledge of the network topology,network devices (including soft switches em-bedded in hypervisors) and network capabil-ities. With that knowledge, the controller pro-grams forwarding tables, connects networkendpoints via an overlay, or adds networkservices such as firewalling or load-balancingto an infrastructure. In other words, the con-troller performs whatever tasks that are ap-propriate in the context of the application.The second component of SDN is the notion

of programmable infrastructure. In otherwords, switches, firewalls, load-balancers andso on need to provide an interface that a con-troller can access to program them. Tradition-ally, humans configure network devices by is-suing commands via a command-lineinterface or a graphical user interface. Au-tomation systems have had some successconfiguring devices with SNMP or via auto-

mated CLI interaction, but both SNMP and CLIhave a significant drawback. Every SNMP andCLI interface varies by vendor; even within avendor, the SNMP management interfacebases and CLI commands required to accom-plish a given task can differ.Part of SDN’s promise is that the controller

abstracts the network hardware from the ap-plications. The applications don’t need to knowthe particulars of the underlying network infra-structure — the controller takes care of that. Allthe application needs to be concerned with iscommunication with the controller.To accomplish this layer of abstraction and

2013 2012

How familiar are you with OpenFlow?

Familiarity With OpenFlow

Very familiar; I understand the details

Familiar; I understand the basics

Somewhat familiar; I have a general idea of what it's about

Not familiar


R7240813/15

10%10%

33%23%

36%38%

21%29%

R

Figure 3



http://reports.informationweek.com/abstract/25/8980/Virtualization/Strategy:-The-Virtual-Network:-TRILL,-SDN-and-More.html?cid=iwrpdf_side_724sdn

August 2013 9

achieve a programmable infrastructure, theindustry has used two major tactics. The mostsignificant is that of application program-ming interfaces. An API provides a meanswhereby instructions can be sent to a deviceto program it. Programmers can read API doc-umentation to understand what a device iscapable of, then code the appropriate com-mands into their applications. In SDN, APIsshow up in two important places. North-

bound APIs reside on acontroller and are used byapplications to send thecontroller instructions;ergo, the communicationhappens “north” of thecontroller. Southbound

APIs reside on network devices such asswitches and are used by an SDN controllerto provision the network; ergo, the commu-nication happens “south” of the controller.The second major tactic is OpenFlow. Open-

Flow is a standard managed by the Open Net-working Foundation with the goal of creatinga common “language” to program network

switches. OpenFlow commands allow a net-work programmer to match a network flowagainst a set of criteria, and then perform var-ious operations on that flow such as forward,copy or drop. OpenFlow is a southbound pro-tocol and has received mixed levels of sup-port by networking vendors. According to oursurvey, 43% of respondents say they under-stand the basics of OpenFlow. Another 36%say they are somewhat familiar (Figure 3). Applications are the third major component

of an SDN infrastructure. An application is soft-ware that a business uses to describe what itwants the network to do. SDN ap plications canbe broad, handling all aspects of a cloudprovider’s infrastructure-as-a-service network,for example. SDN applications can also bequite narrow, performing a function only of in-terest to a specific portion of an IT team.Along with full-featured, multitenant-

focused provisioning systems, vendors havereleased a small number of SDN applicationsto demonstrate how a software-defined infra-structure extends the capabilities of the net-work beyond traditional norms. The network-

ing industry is also discussing building anecosystem around SDN applications, wherecoders could release SDN apps to the publicin a controlled way. At this writing, there is noconsensus about how such a communityshould be built, but the concept is interestingand illustrative of what SDN could bring tonetworking in general.The final component is multitenancy. A

major use case for SDN has been to meet thecomplex provisioning needs of cloud pro -viders, specifically in the context of multite-nancy. Multitenancy is the idea that many cus-tomers share the same physical infrastructure,while being securely separated from one an-other. The technical challenges of multite-nancy include provisioning (creating a ten-ant’s environment across a complex anddiverse physical infrastructure), resource man-agement (making sure there’s enough physi-cal network capacity to handle requests fornew ser vices) and self-service (automatingthe provisioning of new se rvice requests asclients ask for them through a portal).SDN has stepped in with solutions to these

Previous Next



Part of SDN’s promise is that the

controller abstracts the network

hardware from the applications.



August 2013 10

challenges, where an integrated offering ofa controller, application and variety of south-bound programming approaches lets an op-erator leave the details of tenant provision-ing to the software. Tenantcontainers are created withOpenFlow, a network overlaysuch as VXLAN or a combinationof the two. Most importantly,these SDN platforms claim to ab-stract away the network com-plexity to such a degree that pro-visioning errors are greatlyreduced and the time required isnegligible to on-board new ten-ants and spin up services.While many service providers are

genuinely interested in SDN be-cause of the efficiencies it can de-liver, their enterprise counterpartsseem unconvinced. This is an im-portant point, because whileproviders often run huge networksand therefore spend lots of money,enterprises make up a far larger

number of networks on the whole.That’s not to say enterprises have dismissed

SDN altogether — they haven’t. Larger enter-prises that recognize that their networks can

be similar to a ser vice provider network arestarting to see how SDN coupled with multi-tenancy could benefit them. But most enter-prises are not large ones. It’s with the tide of

engineers managing the “nothuge” networks that vendorsmust fight for SDN mindshare.

Software-Defined FUD“Software-defined” has become

a buzzword term across the IT in-dustry. I’ve seen discussions aboutsoftware-defined security, software-defined data centersand software- defined storage,along with software-defined net-working. As a term, “software-de-fined” is becoming as overused as“as-a-service,” to the point ofthem comically competing witheach other in the form of Internetmemes. Doughnuts-as-a-service,you say? Well, I give you software-defined doughnuts instead!With SDN being its own mes-

Previous Next



What percentage of next year's IT budget will go toward implementing SDN? Include testing, training, premium paid for SDN-capable gear, etc.

Percentage of IT Budget Allocated to SDN Implementation

Base: 116 respondents in July 2013 and 116 in July 2012 at organizations with, or planning to have, SDN in productionData: InformationWeek Software-Defined Networking Survey of business technology professionals

R7240813/18

R

2013 2012

None

1% to

5%

5% to

9%

10%

to 1

9%

20%

to 2

9%

30%

to 3

9%

40%

to 4

9%

50%

or m

ore

Don'

t kno

w

11%

15%

26%

18%

16%

10% 12

%20

%

5%10

%

1% 1%

4%1%2%

3%

23%

22%

Figure 4



August 2013 11

sage to some degree, it’s little wonder thatmuch of the network engineering commu-nity doesn’t seem to grasp why SDN mightbe needed. For most, that’s a response basedon simple observation. IT organizations seethat they have a network that’s working. Per-haps their networking team is a bit stressed,but generally speaking the work is gettingdone. And sure, SDN is nifty, but what’s thepoint, really?That sound logic is behind the low budget

allocations organizations are putting towardSDN; 26% of respondents that have or plan tohave SDN in production say just 1% to 5% oftheir budget for 2014 will go to SDN (Figure4). It’s easier for an organization to buy bigger,newer versions of whatever has been workingfor it right along. If a switch lacks forwardingcapacity, buy a bigger one. If a storage array isrunning out of disk, buy a bigger one. Certainly the “buy a bigger one” philosophy

isn’t all that’s taking up organizational bud -gets. Interesting new technologies do maketheir way into companies, but new productsare often driven by pain points that the tech-

nology solves. If a company doesn’t perceivethat SDN fixes a problem it has, that companyis unlikely to devote resources to it.Not only are budgets light on SDN spending,

plans to even evaluate SDN are distant for mostsurvey respondents. This is an even moretelling statistic than the lack of budgetary com-mitment. It’s understandable that IT teamswouldn’t spend money on SDN-enabling theirnetwork at this early point in the technology’slife. However, to not even be evaluating SDNimplies that the technology is not compellingenough in the minds of overworked IT teamsto make the time necessary to explore it.A number of interesting quotes came into

the survey that help explain this:“I don’t believe in SDN.”“I see no compelling business case for a

move to SDN.”“Changes will happen, but there are more

pressing issues such as IPv4 exhaustion thatneed to be dealt with.”“There needs to be a problem to solve, with

defined inputs and desired effects. Just buy-ing SDN seems like a waste.”

“One challenge for us is devoting time to getaway from the production network to work inthe lab getting exposure to the SDN project.”The point is this: Many technical staffs don’t

care that a networking product is or isn’t soft-ware definable as much as they care about theservice that’s actually being delivered. Thatdoesn’t diminish the importance of SDN as atechnology, but it does diminish the long-termmarketability of SDN as a feature unto itself.

Focus on BenefitsWhen SDN is discussed as a major, exciting

technology, and the use cases for it are dis-cussed as a boring afterthought, engineersand IT staffs seem to be apathetic. SDN “go-ing to 11” isn’t good enough. If vendors shifttheir focus to marketing innovative network-ing applications, they’ll get more tractionwith the networking consumer.Put another way, a networking vendor

doesn’t walk into a customer opportunity andsell OSPF. It sells a device that routes trafficand has other interesting benefits to a busi-ness. The fact that OSPF might be part of the

Previous Next



Like This Report?

Rate It!Something we could dobetter? Let us know.

RateRate



http://reports.informationweek.com/abstract/6/11255/Data-Center/2013-sdn-survey-growing-pains.html?cid=rpt_like_linkR7240813

August 2013 12

overall solution is an incidental detail. WhileSDN is a catalyst, it’s not the endgame. The re-sult is the important part.And it’s clear that respondents are open to

SDN’s benefits. For example, when we asked re-spondents that have or plan to have SDN inproduction what LAN challenges they believeSDN could help them with, the top response

was “automate more provisioning and man-agement” (Figure 5). Other top responses in-cluded “implement network-wide policies” and“improve network utilization and efficiency.” Also, when asked how IT would try to sell

SDN benefits to their business counterparts,the top response by far was “a more efficientand flexible network that speeds service delivery” (Figure 6).

A Lack of CertificationsBeyond the perceived lack of applications

and use cases for many networks, the surveyreveals a number of reasons why a significantnumber of those who know a bit about thetechnology are ignoring SDN.When we asked about the top barriers to

adopting SDN, the No. 1 response was the im-maturity of current products (Figure 7). Inother words, the potential benefits of SDNaren’t worth the risks that come with bringingin technologies that aren’t fully baked.But there are other reasons as well. One is a

lack of available training in SDN skills. For wellover a decade, network engineers have had a

Previous Next

Which of the following data center LAN challenges do you believe SDN can be most helpful in overcoming?

LAN Challenges Mitigated by SDN

Note: Three responses allowedBase: 116 respondents in July 2013 and 116 in July 2012 at organizations with, or planning to have, SDN in productionData: InformationWeek Software-Defined Networking Survey of business technology professionals

R7240813/6

R

2013 2012

Auto

mat

e m

ore

prov

ision

ing

and

man

agem

ent

Impl

emen

t net

wor

k-w

ide

polic

ies

Impr

ove

netw

ork

utili

zatio

n an

d ef

ficie

ncy

Impr

ove

secu

rity

Redu

ce co

mpl

exity

Redu

ce co

st

Get m

ore

visib

ility

into

app

licat

ions

that

are

usin

g th

e ne

twor

k

Incr

ease

scal

abili

ty

Supp

ort c

reat

ion

and

dyna

mic

mov

emen

t of v

irtua

l mac

hine

s

Supp

ort c

reat

ion

of a

priv

ate

or h

ybrid

clou

d

Redu

ce re

lianc

e on

vend

ors'

prod

uct l

ife cy

cles

Redu

ce re

lianc

e on

pro

prie

tary

pro

toco

ls or

pro

prie

tary

ext

ensio

ns

of st

anda

rds-

base

d pr

otoc

ols

Supp

ort m

ore

east

-wes

t tra

ffic

Othe

r

None

53%

35%

41%

31%

39% 42

%

28%

32%

24%

23%

22%

29%

21%

25%

15%

14%

13%

8%

20%

8%

10%

4%

7%12

%

3%1%

0%1% 1%

0%



Figure 5



August 2013 13

number of certification ladders that theycould climb to increase their competency.Network engineering is a demanding careerthat can be stressful for the practitioners, asnetwork outages have a severe impact on thebusiness. To reduce this stress, network engi-neers train, many going as far as taking ex-ams to achieve professional certifications. Butwhere is a network engineer to go to achieveSDN skills? Major vendors like Cisco and Juniper aren’t offering SDN certificationtracks as yet.The SDN education situation is even more

complex than the dearth of official vendortraining. The fact is, SDN asks network engi-neers to add a new skill set to the complexbox of tools they already carry. For networkengineers to be competent professionals in a software-defined environment, they’ll neednot only an understanding of switching, rout-ing, tunneling, capacity management, resiliency and so on, but also programmingskills that allow them to communicate withthe network through APIs.In my role as co-host of the “Packet Pushers”

podcast, the SDN question that comes upmore than any other is, “Do I have to becomea programmer now?” That’s a great question;

and the only fair answer I have is that havingprogramming skills will doubtless be helpfulin the software-defined future.

Previous Next

2013 2012

What benefits did, or will, you use to "sell" SDN to the business?

SDN Selling Points

A more efficient and flexible network that speeds service delivery

Cost savings on hardware

Ability to apply QoS via traffic awareness

Ability to test new routing protocols

Other

We won't even try; benefits are on the networking side

Note: Multiple responses allowedBase: 116 respondents in July 2013 and 116 in July 2012 at organizations with, or planning to have, SDN in productionData: InformationWeek Software-Defined Networking Survey of business technology professionals

R7240813/7

76%66%

42%50%

35%36%

19%17%

4%3%

10%4%



Figure 6

LikeLike TweetTweetTweet

ShareShare

Like This Report?

Share it!



http://www.linkedin.com/shareArticle?title=2013+SDN+Survey:+Growing+Pains&mini=true&url=http://reports.informationweek.com/abstract/6/11255/Data-Center/2013-sdn-survey-growing-pains.html

http://twitter.com/home/?status=2013+SDN+Survey:+Growing+Pains+http://twb.io/15KpSPE @IW_Reports

http://www.facebook.com/sharer/sharer.php?u=http://reports.informationweek.com/abstract/6/11255/Data-Center/2013-sdn-survey-growing-pains.html&t=2013+SDN+Survey:+Growing+Pains&src=sp

August 2013 14

As one survey respondent put it: “Thebiggest hurdle I see for SDN to get off theground in the enterprise is bringing engi-neers’ skill levels up. I think the day a vendor

brings out a training book or course is the daywe will see SDN really take off.”Indeed. It’s hard to support what you don’t

understand.

OpenDaylight and OpenFlowThe lack of standardization in SDN is another

significant barrier to adoption. For many yearsnow, networking has enjoyed protocol stan-dards; compliance with these standards pro-motes interoperability. While there are plentyof exceptions, in general, if a vendor supportsSpanning Tree, OSPF, BGP or MPLS, that ven-dor’s product will work with a competitor’sproduct running those same protocols. WithSDN, there are no official standards at this time.While the look and feel of SDN (an applica-

tion speaking to a controller that programsnetwork infrastructure) is becoming familiar,the details of each implementation vary dra-matically among vendor offerings. Vendor interoperability isn’t a conversation the industry is having for the most part, althoughthere are a few bright spots.The first is OpenDaylight. This is an open

source project of the Linux Foundation, andit accepts software contributions from ven-dors and individuals alike. ODL is creating anopen source SDN stack that defines a con-troller as well as northbound and south-

Previous Next

Which of the following are the top inhibitors to your company adopting SDN in the next two years?

Barriers to SDN Adoption

Note: Three responses allowedBase: 267 respondents in July 2013 and 250 in July 2012Data: InformationWeek Software-Defined Networking Survey of business technology professionals

R7240813/8

R

2013 2012

Imm

atur

ity o

f cur

rent

pro

duct

s

Othe

r tec

hnol

ogy o

r bus

ines

s prio

ritie

s

Lack

of r

esou

rces

to e

valu

ate

SDN

Conf

usio

n an

d la

ck o

f def

initi

on in

term

s of v

endo

rs' s

trat

egie

s

Imm

atur

ity o

f ena

blin

g te

chno

logi

es

Conc

ern

that

the

tech

nolo

gy w

ill n

ot sc

ale

to su

ppor

t en

terp

rise-

class

net

wor

ks

We

don'

t see

a co

mpe

lling

valu

e pr

opos

ition

Lack

of a

criti

cal m

ass o

f org

aniza

tions

that

hav

e de

ploy

ed SD

N

Conc

ern

that

maj

or n

etw

orki

ng ve

ndor

s will

der

ail S

DN b

y ad

ding

pro

prie

tary

feat

ures

Wor

ry th

at co

st to

impl

emen

t will

exc

eed

ROI

Not s

ched

uled

to h

ave

a ne

twor

k te

chno

logy

refre

sh in

that

tim

efra

me

Othe

r

No in

hibi

tors

to im

plem

entin

g SD

N

We'

ve a

lread

y im

plem

ente

d SD

N

47%

41%

29%

24%

28%

23%

28% 32

%

23% 25

%

19%

18%19

% 22%

15%

14%

14%

13%

3% 4%

13%

11%

14% 18

%

2% 4%

2% 2%



Figure 7



August 2013 15

bound APIs. While there are lots of opensource projects in the world, ODL is signifi-cant in that several prominent networkingvendors came together to form the project,including Arista, Brocade, Cisco, Hewlett-Packard, IBM, Juniper, Microsoft, NEC, Red Hatand VMware. A number of SDN startups arealso involved with ODL, including Cyan, Nu-age, Plexxi and PLUMgrid.The ODL project is structured such that ven-

dors or individuals can contribute software. Asa vendor-driven open source project, this ledto an early conflict. Initially, Big Switch Net-works, an SDN startup whose flagship productis a controller, was a key part of ODL. As ven-dors came together to look at what they hadbrought to the project, overlap was identifiedbetween Big Switch’s controller and the con-troller code that Cisco submitted.While there was a proposal to integrate the

two controller codebases, ODL’s voting bodyopted to use the Cisco controller code. Shortlyafter that, Big Switch pulled out of ODL,choosing to forge ahead with the ecosystemit had already built around Floodlight, the

open source version of Big Switch’s commer-cial controller offering.Even without Big Switch, OpenDaylight has

moved on quickly, seeing a number of usefulcontributions being accepted into the project.As an open source project with features up anddown the SDN stack, ODL is positioned to be-come a point of commonality for all vendor

SDN offerings. Conceptually, vendors would beable to sell a product that is ODL-compliantwhile also offering enhanced functionality thatthe vendor provides as a value-add.There’s a chance that ODL could become a

de facto standard. ODL’s open source con-troller architecture and service abstractionlayer could form a baseline that all vendors

Previous Next

What's your opinion of the OpenDaylight project?

44%

5%

12%

39%

Perception of OpenDaylight

Data: InformationWeek 2013 Software-Defined Networking Survey of 267 business technology professionals, July 2013 R7240813/14

1It's vital and will become a baseline architecture that all SDN products will refer back to

It's worthwhile and will move SDN forward

What's the OpenDaylight project?

It's going nowhere, too much vendor infighting



Figure 8



August 2013 16

support. While it follows that vendors wouldextend their SDN offering beyond the theo-retical ODL baseline, that’s not much differentfrom what happens in the industry today withnetworking standards. As a standard is deployed, some vendors extend the stan-dard’s capabilities. If the extension is popularenough, there’s potential for it to be added toindustry standards over time.However, ODL still has a ways to go in terms

of awareness among IT. Forty-four percent ofrespondents don’t know what it is, accordingto our survey (Figure 8). However, that number is counterbalanced by 44% whoagreed that the project is “vital and will be-come a baseline architecture that all SDNproducts will refer back to” or “worthwhileand will move SDN forward.”The second standardization effort is Open-

Flow, which is overseen by the Open Network-ing Foundation (ONF). While not an SDN offer-ing by itself, OpenFlow is gathering broadindustry support, although the level of supportvaries dramatically by vendor and product. For a time, OpenFlow enjoyed rapid stan-

dards development in the ONF. The initialOF1.0 release was followed by 1.1, 1.2 and 1.3specifications. Switch vendors that have chosen to support OpenFlow usually support1.0, with eyes toward 1.3 as the next target. Al-most no implementations of OF1.1 or 1.2 exist. The changes between OF1.0 and OF1.3 are

significant. Most switch vendors found that itwas impossible to map all OF1.0 operationsinto their silicon, meaning that some opera-tions would be punted to the switch CPU;punted operations are performed much moreslowly by the network switch, which presentsOpenFlow with a scaling challenge.OF1.3’s more complex list of capabilities has

only exacerbated this situation, as vendors arefaced with an even greater challenge for theirexisting silicon. If this seems like a peculiar sit-uation, it’s helpful to understand that networkswitch silicon takes years to develop and havelong production runs. Today’s silicon was conceived years ago, long before OpenFlowbecame important.The ONF is keen to push OpenFlow ahead

and is actively working on the OF1.4 specifi-

cation. To assist with implementing OpenFlowin hardware, a Chipmaker’s Advisory Boardwas created to allow silicon manufacturers toconverse with the ONF. The conversation willhelp the ONF construct OpenFlow standardsthat are chip-friendly, as well as give the ONFa way to express the functionality it is lookingfor in new silicon.That said, both of these bright spots are spec-

ulative. Time will tell what becomes of ODL, aswell as OpenFlow. In the meantime, survey re-spondents aren’t feeling comfortable. Wroteone respondent: “SDN and OpenFlow are a sig-nificant deviation from the standard, relativelyconsistent way that data networking has beendone over the last decade. In addition, Open-Flow is still very green and was, in the opinionof some, commercialized too quickly.”While SDN has the potential to completely

replace not only how a network forwardstraffic, but also how a network is constructedand maintained, most survey respondentsdon’t foresee that happening in their envi-ronments, even over the next five years. Fiftypercent of respondents believe their net-

Previous Next





August 2013 17

works will be about evenly split betweenSDN and traditional, while an additional 35%say their networks will remain largely tradi-tional (Figure 9). If this hybrid networking approach be-

comes mainstream, it puts vendors in an in-teresting position. Long-term, vendors aregoing to want customers to have their entirenetwork infrastructure managed by a con-troller. Why? A software-defined network infrastructure will facilitate new and interest-ing applications that couldn’t be imple-mented in a traditional network. This willpresent vendors with sales opportunities ofgreater variety than “a bigger box.”

Startup OpportunitiesSoftware-defined networking is proving

hard to sell on its own merits. Many customersare unclear on what SDN is or why they mightwant it. In that context, SDN is not yet a mar-ket comparable to, say, Ethernet switching.Changing that will take SDN applications.The most successful SDN demonstrations

that I’ve witnessed over the past year have

been of working applications that solve a spe-cific problem. These have happened to belargely in the cloud space, but there’s no reasonthat applications can’t be brought to the en-terprise. While the focus is perhaps a bit differ-ent for the enterprise, it still has challenges with

provisioning efficiency, resource management,troubleshooting, human error, multitenancy,regulatory compliance … the list goes on.Hammering away at individual device CLIs

doesn’t make managing these challenges easy.SDN coupled with the right applications might.

Previous Next

2013 2012

In five years, I believe my organization's networks will be:

Predicted Network Format

Exclusively based on SDN

Mostly SDN

Hybrid, with SDN and traditional coexisting about equally

Mostly traditional

Exclusively traditional


R7240813/4

3%2%

7%13%

50%54%

35%27%

5%4%

FAST FACT

35%of respondents say their

networks will remain

largely traditional.



Figure 9



August 2013 18

Vendors that create applications to make net-work implementations work in lockstep withother IT processes will make a compelling caseto enterprises and pique their interest.While established vendors have been

formulating and explaining their SDN strate-gies to customers, the survey revealed thatstartups have a fairly open door. Well over halfof survey respondents stated they were atleast somewhat willing to buy from a startupif the situation was right (Figure 10). That’s good news for startups, who tend to

have the most complete SDN offerings, asthey’ve devoted their entire business life tocreating their products. On the flip side,large vendors have also been acquiringsome SDN startups to help reduce their SDNtime to market. So it seems to be a goodtime to be an SDN startup. Potential cus-tomers are willing to talk to you, and estab-lished vendors might want to buy you.

Cisco and SDNStill the 800-pound networking gorilla even

in this emerging market, Cisco Systems’ SDN

vendor strategy ranks as the one that survey re-spondents are far and away the most familiarwith (Figure 11). This speaks volumes, as Ciscohas not been in a technical leadership positionregarding SDN until very recently. And eventhen, “technical leadership” is only a role it playsif you believe that ODL will become a referencemodel for SDN going forward. In a certain sense,

Cisco was the anti-SDN vendor for quite a while,waiting for its customers to make the first move.Now that Cisco’s SDN strategy is becomingmore clear, the model it represents is distinctfrom many of the values that SDN was rootedin — in particular, that SDN would herald anage of low-cost, commodity network gear.The idea is this: Rather than invest in expen-

Previous Next

How willing are you to purchase SDN technology from a startup?

43%

6%

51%

Willingness to Purchase SDN Technology From a Startup


1Very willing; startups are where innovation's happening

Somewhat willing; depends on the situation

Not at all willing; SDN is already risky enough

I



Figure 10



August 2013 19

sive networking hardware with custom sili-con, an organization could buy generic“white-box” switches that run a generic oper-

ating system and are programmed using astandard language.The logic goes that a network switch only

needs to do a few things: path computation,link aggregation, communication with amanagement station and high-speed for-

warding. Anything morecomplex that the switchneeds to do could be pro-grammed via OpenFlow.Richer functionality such as overlay encapsulationcould be pushed to thevery edge of the network,inside a soft switch thatlives in a hypervisor.In this SDN-flavored re -

imagining of networking,the Ethernet switch thatlives at the heart of a datacenter becomes somewhatunimportant — a cheapway to uplink hosts andmove traffic, and little more.It’s a potentially compellingimage, but our survey showsthat most respondentsdon’t think it will become

Previous Next

How familiar are you with each of the following vendors' SDN strategies? Please use a scale of 1 to 5, where 1 is "not at all familiar" and 5 is "extremely familiar."

Familiarity With Vendors' SDN Strategies

Note: Mean average ratingsBase: 267 respondents in July 2013 and 250 in July 2012Data: InformationWeek Software-Defined Networking Survey of business technology professionals

R7240813/22

R

2013 2012

Cisc

o

Juni

per

HP Dell

Broc

ade

IBM

Big

Switc

h

Nicir

a

Arist

a

NEC

Alca

tel-L

ucen

t/Nu

age

Avay

a

Plex

xi

Huaw

ei

Pica

8

Extr

eme

Mid

okur

a

Embr

ane

Tail-

f Sys

tem

s

Vello

3.1

2.9

2.2

2.2

2.2

2.2

2.0

2.2

2.0

1.9 1.9 2.

1

1.9

1.7 1.

8

1.8

1.7

1.6

1.6

1.6 1.

8

1.6

1.6 1.

8

1.5

NA

1.5

1.5

1.4

NA

1.4 1.

5

1.4

NA

1.3

1.5

1.3

NA

1.2 1.

4

1 No

t at a

ll fa

mili

arEx

trem

ely f

amili

ar 5



Figure 11



August 2013 20

reality : When we asked if they thoughtswitches and routers would essentially be-come “dumb” forwarding engines, 46% saidno (Figure 12). That’s 9 percentage pointshigher than 2012. In addition, 57% of respon-dents said they have no plans to buy white-box switches (Figure 13). Thus far, OpenFlow has been the enabler for

this white-box approach. Organizations inter-ested in reducing the capex and opex tied upin vendor-specific hardware can opt for a net-work infrastructure of low-cost switches pro-grammed by a controller using OpenFlow.Service providers and cloud providers haveexpressed an interest in this, and in fact arethe types of organizations that dominate themembership rolls at the ONF.Naturally, Cisco disparages the notion of

white-box switches. A foundation of Cisco’sEthernet switching business is its custom sili-con (ASICs). Cisco’s application-specific inte-grated circuits give its switches both their rawforwarding performance and rich wire speedfunctionality. Cisco continues to bring newASICs to market, having recently announced

fresh silicon for the Nexus 7K F3-series linecard as well as the Catalyst 3850 switch. WhileCisco has occasionally worked with off-the-shelf silicon (witness the Nexus 3064, whichuses a Broadcom chipset), its hallmark will re-main custom silicon.Cisco believes it can compete with any seri-

ous white-box contender. It looks like our re-spondents do as well. When we asked aboutthe impact SDN might have on the router and

switch market, tied for the most popular re-sponse was “Somewhat lower prices, lesshardware differentiation, but same main play-ers” (Figure 14). In other words, SDN has littlechance of unseating Cisco. So far, that’sproved to be the case, but it’s a story worthkeeping an eye on as SDN evolves.In addition to custom silicon, Cisco is em-

phasizing custom APIs as the front end to itsproducts and its approach to SDN. This is for-

Previous Next

2013 2012

Do you believe that SDN will relegate switches and routers to being just relatively dumb forwarding engines?

'Dumbing Down' of Switches and Routers?

Yes

No

Don't know


R7240813/12

25%29%

46%37%

29%34%

R

FAST FACT

57%of respondents said they

have no plans to buy

white-box switches.



Figure 12



August 2013 21

mulated in Cisco’s Open Network Environ-ment initiative. As a part of ONE, Cisco is pro-viding onePK, a toolkit for programmers toboth program features into and extract datafrom the network via APIs. Cisco has stressedthat the onePK API libraries are critical to thelong-term success of SDN on its platforms.That’s because Cisco has baked a massive

number of features into its silicon and intoits IOS and NX-OS lines of software. Cisco argues that only with custom APIs can thefull potential of its hardware platforms beprogrammatically accessed. Cisco also con-tends that to properly abstract that featureset with APIs is something no open source orindependent body could reasonably do, orwould want to do. Cisco’s betting that cus-tomers will view SDN in the same way —that being able to leverage all of a device’scapabilities is desirable — and consequentlykeep them in the fold.In this context, it’s clear why Cisco has been

so late to support OpenFlow when comparedwith competitors. OpenFlow isn’t terriblycompatible with the Cisco way of building

networks. Cisco silicon wasn’t built withOpenFlow in mind (neither was anyone else’s,but the point remains), and OpenFlow doesn’texploit Cisco switch and operating systemfunctionality.While the huge installed base of Cisco

switches means there’s going to be at leastsome customer demand for OpenFlow, that’s

a minimal driver for Cisco right now. Ciscosees ONE as the way forward — the way toprovide programmatic functionality that’sboth more capable and nuanced than Open-Flow is likely to be, at least on Cisco hardware.Cisco’s aggressive position in the OpenDay-

light project, along with ODL adopting itscontroller code, implies an SDN leadership po-

Previous Next

If you currently or plan to buy generic "white-box" switches, what's your top motivator?

57%

17%

10%

8%

7%

1%

Reasons for Buying 'White-Box' Switches


1Save on hardware costs

Improve design flexibility

Improve network stability

Reduce risk of vendor lock-in

Other

No plans to buy white-box switches

I



Figure 13



August 2013 22

sition now. While ODL is still very early, it’swell-positioned to influence the SDN land-scape going forward. Cisco will be able to takethe codebase it’s contributed to ODL andbuild on that foundation to cre-ate a variety of SDN applicationsif it so chooses.Cisco is very smart about mar-

ket positioning. While the com-pany has had its failings in recentmemory, by and large, Ciscoknows how to identify a marketand redefine it to suit itself. Withthe SDN market, this exact thingis happening. And based on sur-vey responses, Cisco’s gettingthat message out the door to thecustomer base.That’s not to say that all other

vendors are at a competitive dis-advantage to Cisco when itcomes to SDN. Cisco is just one ofmany vendors contributing toODL. ODL is open source, whichmeans that any vendor would be

able to use that code as a jumping-off pointif it chooses. In that sense, ODL levels theplaying field, giving vendors of all stripes apoint of SDN commonality. Vendors that rec-

ognize the issue of a lack of standards andwork within the construct of ODL may winmindshare among customers.

Recommendations for PotentialCustomersFor the majority of networking

customers, SDN is real, but SDN isnot a product they need to shopfor specifically today. Allow me toqualify that statement. Software-defined networking is a powerful,real-world technology that enablesapplications to bring automation,orchestration, path engineering, se-curity tools, traffic analysis and ahost of other functions in an easy-to-consume way to all networkseverywhere. However, SDN isn’t thething to buy, as such. Applicationsthat meet a business objective arethe things to go after. Will SDN bebehind the scenes, facilitatingclever applications? In a variety offorms, yes. But buying SDN to buy

Previous Next

Which of the following best describes your expectation of SDN's effect on the switch and router market by 2015?

Expected Impact of SDN on the Switch and Router Market


R7240813/13

R

2013 2012

Som

ewha

t low

er p

rices

, less

har

dwar

e di

ffere

ntia

tion,

bu

t sam

e m

ain

play

ers

The

cost

will

just

shift

to co

ntro

llers

and

soft

war

e

Few

er p

ropr

ieta

ry fe

atur

es, e

mph

asis

on st

anda

rds

Resh

uffle

mar

ket l

eade

rshi

p

Switc

hes a

nd ro

uter

s will

be

a co

mm

odity

; pric

ing

land

scap

e w

ill b

e to

tally

diff

eren

t

Switc

hes a

nd ro

uter

s will

be

a co

mm

odity

; ven

dor l

ands

cape

w

ill b

e to

tally

diff

eren

t

Othe

r

No im

pact

; Cisc

o w

ill fi

gure

out

how

to m

aint

ain

its m

argi

ns

24%

22% 23

%18

%

10%

16%

6%11

%

6%7%

2% 1%

5%7%

24%

18%



Figure 14



August 2013 23

SDN isn’t what most customers should be do-ing, unless they’re in a position to be writingtheir own applications today.In that context, an IT organization should be

evaluating the SDN capabilities of its existinghardware as well as new hardware purchases.Network operators should understandwhether their hardware is SDN-capable, andwhat sorts of capabilities they are.This is important to understand going back

to the point of the coming network applica-tion marketplace. Assuming an ecosystem ofeasy-to-consume network applications arises,an organization will want to be able to con-sume them. If its hardware isn’t SDN-capable,that could put it at a competitive disadvan-tage. IT shops should be looking ahead to atime when rich applications won’t rely onSNMP or the CLI to engage the network, butrather will require API access to hardware.There’s no panic button to be pressed here.

One of the useful features of SDN is that it’snot an all-or-nothing proposition. Organiza-tions can start small with SDN, bridging fromtheir SDN-enabled island to their legacy in-

frastructure if they so choose. SDN couldtherefore grow over time into a networkingenvironment.In addition, some existing hardware that

might not be SDN-capable today could bemade SDN-capable by a vendor in the future.OpenFlow is one example of this. Puppetagents are another, enabling scripted provi-sioning of some network functions on sup-ported hardware. Cisco promises to enableseveral of its existing product lines with APIsthrough its ONE initiative. Many, many prod-ucts already have APIs today, even if cus-tomers are unaware they’re there. Ethernetfabric products from vendors like Avaya andBrocade are already SDN-friendly, hookinginto popular virtualization platforms fromVMware and OpenStack, allowing those plat-forms to communicate their needs on- demand to the underlying network infrastruc-ture with no manual intervention.SDN as a whole is starting to sort itself out,

get comfortable with what it is, and moveahead. I’m hopeful that SDN over the next 12months will see growth in the number and

function of network applications, which I antic-ipate will transform how networking is done.

Previous Next





August 2013 24

Previous Next


reports 2 0 1 3 S D N S u r v e y : G r o w i n g P a i n s

APPE

NDIX

Table of Contents

2013 2012

What is your expected timeline to have SDN in production?

SDN Production Timeline

We have SDN in production now

Less than six months

Six to 12 months

More than 12 but less than 24 months

More than 24 months

No plans to have SDN in production

Don't know


R7240813/3

4%4%

4%5%

9%9%

13%17%

13%11%

42%37%

15%17%

R

Figure 15



August 2013 25

Previous Next



2013 2012

How willing are you to make significant architectural changes to your production networks in order to achieve the promised benefits of SDN?

Willingness to Make Architectural Changes for SDN

Completely willing

Very willing

Moderately willing

Slightly willing

Not at all willing


R7240813/5

12%11%

23%29%

49%48%

15%12%

1%0%

Figure 16



August 2013 26

Previous Next



2013 2012

What impact will SDN have on network security?

Impact of SDN on Network Security

Networks will be much more secure

Networks will be somewhat more secure

It will have no impact on network security

Networks will be somewhat less secure

Networks will be much less secure

Don't know


R7240813/9

14%10%

31%32%

16%15%

9%11%

3%1%

27%31%

Figure 17



August 2013 27

Previous Next



What are the security benefits of SDN?

SDN Security Benefits

Note: Multiple responses allowedBase: 267 respondents in July 2013 and 250 in July 2012Data: InformationWeek Software-Defined Networking Survey of business technology professionals

R7240813/10

R

2013 2012

Abili

ty to

app

ly a

uni

fied

secu

rity p

olic

y

Inte

grat

ed a

nd m

ore

gran

ular

acc

ess c

ontr

ol

Addi

tiona

l poi

nts w

here

secu

rity c

ontr

ols c

an b

e pl

aced

to

addr

ess s

oftw

are/

appl

icatio

n se

curit

y iss

ues

Intr

a-hy

perv

isor (

VM-V

M) p

acke

t ins

pect

ion

and

firew

all

Mor

e sit

uatio

n- o

r app

licat

ion-

awar

e se

curit

y eve

nt lo

ggin

g de

tails

Data

secu

rity v

ia tr

ansp

ort e

ncry

ptio

n

DoS m

itiga

tion

Impr

oved

secu

rity a

pplia

nce

perf

orm

ance

/thr

ough

put

Mal

war

e fil

terin

g

Othe

r

None

; it w

ill h

urt s

ecur

ity

Don'

t kno

w

45%

44%

29%

29%

23%

28%

21% 22

%

21% 22

%

16% 17

%

17%

32%

16% 17

%

5%12

%

22%

NA

2%4%

13%

22%

Figure 18



August 2013 28

Previous Next



What security problems do you associate with SDN?

SDN Security Problems

Note: Multiple responses allowedBase: 267 respondents in July 2013 and 250 in July 2012Data: InformationWeek Software-Defined Networking Survey of business technology professionals

R7240813/11

R

2013 2012

Lack

of i

nteg

ratio

n w

ith e

xist

ing

secu

rity t

echn

olog

ies

Func

tiona

lity l

ever

agin

g co

ntro

ller i

ntel

ligen

ce o

pens

ne

w a

ttac

k su

rfac

es

The

cont

rolle

r sca

res m

e —

if a

n at

tack

er o

wns

that

, it's

gam

e ov

er

Mor

e co

mpl

exity

, whi

ch a

lway

s mea

ns le

ss se

curit

y

Inab

ility

to in

spec

t eve

ry p

acke

t

It w

ill h

inde

r per

form

ance

to su

ch a

deg

ree

that

pub

lic

cloud

/Saa

S use

will

incr

ease

Othe

r

None

; it w

ill h

elp

secu

rity

Don'

t kno

w

38%

44%

33%

38%

32%

40%

31%

38%

10%

20%

3% 2%

9%10

%

4%9%

20%

NA

Figure 19



August 2013 29

Previous Next



2013 2012

What is your attitude toward OpenFlow in regard to SDN?

Attitude Toward OpenFlow

OpenFlow is an integral part of SDN; you can't have one without the other

OpenFlow is important but not essential

OpenFlow goes hand in hand with SDN now, but that could change

You don't need OpenFlow to build an SDN

Base: 210 respondents in July 2013 and 178 in July 2012 familiar with OpenFlowData: InformationWeek Software-Defined Networking Survey of business technology professionals

R7240813/16

9%15%

39%40%

33%32%

19%13%

Figure 20



August 2013 30

Previous Next



2013 2012

Did, or will, your organization use OpenFlow to build an SDN?

Use of OpenFlow to Build an SDN

Yes

No

Don't know


R7240813/17

26%37%

15%13%

59%50%

Figure 21



August 2013 31

Previous Next



What percentage of your IT budget will go toward revamping the network to take advantage of SDN in 24 months?

Future IT Budget Allocated to Revamping the Network for SDN


R7240813/19

R

2013 2012

None

1% to

5%

5% to

9%

10%

to 1

9%

20%

to 2

9%

30%

to 3

9%

40%

to 4

9%

50%

or m

ore

Don'

t kno

w4%2%

12%

9%

15%

21%

16%

16%

13%

16%

31%

28%

4%1%1%

0%

4%7%

Figure 22



Previous Next



Which of the following vendors' SDN strategies do you think best address your organization's requirements?

Best SDN Strategy

Note: Three responses allowedBase: 116 respondents in July 2013 and 116 in July 2012 at organizations with, or planning to have, SDN in productionData: InformationWeek Software-Defined Networking Survey of business technology professionals

R7240813/23

R

2013 2012

Cisc

o

Arist

a

HP Juni

per

Dell

Broc

ade

Alca

tel-L

ucen

t/Nu

age

Big

Switc

h

Avay

a

IBM

Nicir

a

Huaw

ei

NEC

Mid

okur

a

Pica

8

Plex

xi

Embr

ane

Extr

eme

Tail-

f Sys

tem

s

Vello

Don'

t kno

w

58%

66%

17%

8%

17%

22%

15%

20%

14%

23%

11%

6%

11% 14

%

9% 9% 9%18

%

9%6%

4%2%

4%2%

4%NA

4%NA

4%NA

3%1% 2%

4%

2%NA 0% 1%

13%

10%13

%12

%

Figure 23

August 2013 32



August 2013 33

Previous Next



Which of the following best describes your job title?

17%

6% 4%

24%

42%

6%

1%

Job Title


1IT executive management (C-level/VP)

IT director/manager

Other

Consultant

Line-of-business management

Non-IT executive management (C-level/VP)

IT/IS staff

Figure 24



August 2013 34

Previous Next



What is your organization's primary industry?

Industry

Cons

ultin

g an

d bu

sines

s ser

vice

s

Educ

atio

n

Elec

tron

ics

Fina

ncia

l ser

vice

s

Gove

rnm

ent

Heal

thca

re/m

edica

l

IT ve

ndor

s

Man

ufac

turin

g/in

dust

rial, n

onco

mpu

ter

Med

ia/e

nter

tain

men

t

Reta

il/e-

com

mer

ce

Tele

com

mun

icatio

ns/IS

Ps

Utili

ties

Othe

r

Data: InformationWeek 2013 Software-Defined Networking Survey of 267 business technology professionals, July 2013

R7240813/25

11%

11%

2%

8%

13%

6%

9%

6%

2% 2%

13%

2%

15%

Figure 25



August 2013 35

Previous Next



Which of the following dollar ranges includes the annual revenue of your entire organization?

8%

15% 15%

15%

13% 5%8%

5%16%

Revenue


1Less than $6 million

$6 million to $49.9 million




Don't know/decline to say

Government/nonprofit

$5 billion or more

$1 billion to $4.9 billion

Figure 26



August 2013 36

Previous Next



Approximately how many employees are in your organization?

26%13%

9%

19%

7%

12%14%

Company Size


1Fewer than 50

50-99

100-499

500-999

10,000 or more

5,000-9,999

1,000-4,999

Figure 27



SubscribeSubscribe

Newsletter

Want to stay current on all newInformationWeek Reports? Subscribe to our weeklynewsletter and never miss a beat.

August 2013 37

Previous


reports 2 0 1 3 S D N S u r v e y : G r o w i n g P a i n s

MOR

ELIKE THIS

Want More Like This?

InformationWeek creates more than 150 reports like this each year, and they’re all free toregistered users. We’ll help you sort through vendor claims, justify IT projects and implementnew systems by providing analysis and advice from IT professionals. Right now on our siteyou’ll find:

SDN Buyer’s Guide: SDN is segmenting into product slices targeting different network layers,IT problems and application needs. We decided to define four categories, outline what to lookfor in each and ask vendors to take their best shot at your SDN business by completing oursurvey. While the market is young, we know it will grow, so we’ll continue to augment our on-line comparison with new submissions throughout the year, hoping to make it your one-stopshop for the latest and best SDN information.

Data Center Decision Time: Is your glass house a sparkling hub of IT innovation or a financialalbatross? For many, it’s the latter. Worse, we often lack agility, 67% say application and hardware philosophies frequently or occasionally conflict business demand, and just 27% saya private cloud is a high priority. Meanwhile, planned use of colocation facilities is up an anemic five points over last year.

IT’s Stake in Vendor Turf Wars: The enterprise tech market used to be an orderly place. Nomore. Now big vendors like Cisco, HP, IBM and Oracle are duking it out for primacy — and refusing to work together for IT’s benefit. Must we now pick a side, or is neutrality an option?

PLUS: Find signature reports, such as the InformationWeek Salary Survey, InformationWeek500 and the annual State of Security report; full issues; and much more.

Table of Contents



http://links.techwebnewsletters.com/servlet/SignUpForm?f=491839


http://reports.informationweek.com/abstract/19/10435/Network-Infrastructure/SDN-Buyer%27s-Guide.html?cid=iwrpdf_rltd_724sdn

http://reports.informationweek.com/abstract/6/10736/Data-Center/Research:-Data-Center-Decision-Time.html?cid=iwrpdf_rltd_724sdn

http://reports.informationweek.com/abstract/83/11157/IT-Business-Strategy/IT%27s-Stake-in-Vendor-Turf-Wars.html?cid=iwrpdf_rltd_724sdn

reports.informationweek.com august 2013 $99 2013 sdn ... · 2013 sdn survey: growing pains while...

Documents