Tag: OpenFlow

Smart Network or Dumb Network: Customers Have More Pressing Needs

Monday.com
by Mike Fratto, posted in Network
Mike Fratto

Summary Bullets:

  • Few enterprises are 100% virtualized, so trying to make the argument that “a virtual overlay is all an enterprise needs” ignores a very real fact of life.
  • Enterprises require intelligence in both the virtual and physical networks, as each plays its part in delivering applications where they are needed.

I had hoped we were done with the smart network/dumb network argument, but I guess nothing ever really goes out of style.  History has proven over and over that anyone who tries to set extremes like smart network vs. dumb network is basing their entire premise on unrealistic expectations.  If I look at the extremes of either a completely virtual data center – and I mean everything – or a completely physical one, then I can make a convincing argument for either a dumb network or a smart one.  However, those examples are the far-edge cases and extremely rare.  Enterprises do not exist as edge cases.  Enterprises need intelligence in both the virtual network and the physical one. Continue reading “Smart Network or Dumb Network: Customers Have More Pressing Needs” →

Tomorrow’s Networking Decisions Will Revolve Around APIs

by Mike Fratto, posted in Network
Mike Fratto

Summary Bullets:

  • In a software defined data center, APIs will be the defining functions differentiating one product from another.
  • Enterprise IT will need to learn about the pertinent aspects of APIs application development to make informed product decisions.

Are APIs part of your checklist when investigating networking products? If not, they should be. In market segments like switching and, speeds and feeds have become a non-issue because networking manufacturers are reaching performance parity fairly quickly. The majority of switch and router features are also fairly uniform across product lines as well. The differentiators are found in SDN features such as overlay or OpenFlow support, automation capabilities, and integration features. Continue reading “Tomorrow’s Networking Decisions Will Revolve Around APIs” →

When Your Switch Vendor is also Your Software Vendor

by Mike Fratto, posted in Network
Mike Fratto

Summary Bullets:

  • A software defined data center is nothing without a software defined network. Programmability and API support are more important than speeds and feeds in making a purchasing decision.
  • Enterprises have to assess a networking vendor’s software plans as thoroughly as hardware specifications.

There are three critical features of data center switching that you need to keep in mind on your next refresh: overlay support, programmability, and APIs. Speeds and feeds, table sizes, and other data sheet specs are table stakes, and most data center networking vendors are keeping pace on the important parts. Seriously now, how many of you are going to make a purchase decision based on MAC table size? Do you really need more than 256,000 entries? Hardware is keeping up. Software impacts the integration and interoperation of your switching hardware with the rest of your data center, so much so that it becomes the most critical set of features that can make or break a fully automated data center. Continue reading “When Your Switch Vendor is also Your Software Vendor” →

OpenStack and ONS in Same Week; Can’t NetOps and Dev Just Get Along?

by Mike Spanbauer, posted in Network
Mike Spanbauer

Summary Bullets:

  • Enterprises struggle with whether a programmatic networks is a developer concept, a networking concept or both
  • The long term success of SDN will eventually depend on solutions being simple to integrate across multi-vendor environments

At the Open Networking Summit this week in Santa Clara, the largest SDN conference and marquee event for the Open Networking Foundation, the leading SDN standards body, it is not lost on this attendee that the event is concurrent with the OpenStack event, a parallel standards body that also fosters open initiatives and technology (though on compute and the software stack vs. networking and the L1-3 services stack).  It is ironic that while this particular conflict was not intentional, it does represent the challenge faced by enterprises who are seeking to incorporate more “open” technologies into their ecosystem.  The question is whether to pursue the early adoption path as is the case with SDN and several solutions which are more coding than CLI configured today, or to wait for the fully “baked” solutions expected to arrive in the future.  The skill sets, staffing challenges, and operational paradigm for each radically differ.  Where one is often sought for a solution that cannot be accomplished by other means, the other is more focused on resource optimization, solution maintenance, and minimized disruption. (While not necessarily technical interruption, introducing a new technology such as SDN is highly disruptive to people and processes at minimum.)

Continue reading “OpenStack and ONS in Same Week; Can’t NetOps and Dev Just Get Along?” →

Without Standards Conformance, OpenFlow Fails to Deliver Interoperability

by Mike Fratto, posted in Network
  • Mike Fratto

    Standards without conformance are useless. Conformance testing resolves varying interpretations which enables interoperability.

  • OpenFlow is starting to fragment along product and vendor partner lines, which isn’t good for either vendors or customers.

When it comes to standards, most if not all IT professionals agree that standards are important. The obvious reason is that standards allow enterprises to integrate the software and hardware they want to use rather than being confined to a subset of products from one vendor or a vendor’s partner program. That’s the high road. The reality is that IT just wants equipment that works whether or not they are standards based, and that’s because having a technical standard isn’t going to enable interoperation and integration. Continue reading “Without Standards Conformance, OpenFlow Fails to Deliver Interoperability” →

What’s an SDN? Who Cares? The Question is, Does It Help?

by Mike Fratto, posted in Network
Mike Fratto

Summary Bullets:

  • There isn’t any consensus on the definition of SDN, but in the many variations are value propositions that may be useful to you.
  • In the drive to define SDN, established and start-up networking vendors are developing products that can improve your network operations, and that is what is important.

Chalk it up to my extensive studies in philosophy, but I like definitions that are clear, concise, and differentiate one thing from another. At times I can be pedantic and get dragged down in details, but I’m also practical and I know that while theory can be fun and games, at some point, stuff has to get done. What was more important to me when I ran a small data center was getting things done. I didn’t really care about what I called whatever technology I was using. What I cared about, and what the IT professionals that I talk to care about, is how will this new technology make my job better, more efficient, less prone to error, or more cost effective. What matters is not the foundational ideas underpinning a new technology, but the practical applications. Continue reading “What’s an SDN? Who Cares? The Question is, Does It Help?” →

Software Defined Networks: Is the Technology Catching Up with the Hype?

by Mike Spanbauer, posted in Network
Mike Spanbauer

Summary Bullets:

  • SDN may have begun academically focused on enterprise LAN needs, but carrier interest is intense and driving innovation as well.
  • More SDN solutions are materializing out of powerpoints and into reality today, with some creative and innovative answers to challenging problems in the past – but when will adoption begin to accelerate?

SDN may be the most exciting networking technology since the advent of Internet Protocol (IP).  At its most fundamental, the concept of SDN provides a construct by which we can discuss the implementation of services within the fabric of the network itself, whether by decentralized routing & flow tables or the abstraction of more advanced network services that are embedded within the network intelligence itself.  There are many approaches, many proposals and of course many vendors vying for a piece of the pie that is in the oven.  It is likely that 2013 is when early momentum will begin. Cisco’s C-Scape in 2012 promised several elements of its One-PK solution would materialize in H1 2013, Juniper has come out with its own rather encompassing SDN vision, and HP has had enough time in the market to get traction (given the long sales cycles on a solution this complex), to name a few.  There are some truly great technology suppliers working in concert (mostly) to move the proverbial ball forward.  However, the question I get asked the most often remains “Is the need real?”, i.e., whether the market currently has a particular need that cannot be addressed or solved another way to which I have replied previously “Not yet, but soon.” Continue reading “Software Defined Networks: Is the Technology Catching Up with the Hype?” →

Despite OpenFlow’s Promises, Switch Architecture Still Matters

by Mike Spanbauer, posted in Network
Mike Spanbauer

Summary Bullets:

  • In the race to get OpenFlow and SDN onto new networking RFPs, enterprises must remember that controlling flow-based traffic patterns will serve to address a couple of weaknesses of networks past; however, edge-to-edge switching latency, performance, and more remain crucial.
  • For the first two to three years, as enterprises prove OpenFlow and early SDN technologies within their environments (and to themselves), the prevalent model will be a hybrid one, in which a vendor’s high-speed fabric and flow control run concurrently on a device (Cisco, Brocade, Juniper, Arista, etc.).

I find it amusing that the OpenFlow discussion has polarized pockets of the IT industry so completely.  It is a great innovation, absolutely, and it will address certain limitations and free up otherwise locked networking resources.  However, you get the sense that any given author of one of these articles is slightly biased to applications, servers, or networks.  The application purist who consumes all resources for the purpose of application architecture wishes to remove inhibitive deployment times from the infrastructure and therefore does not focus on the minutia of each domain’s critical factors.  The server teams have long sought to enable their own domain constituency to deploy high-speed interconnect between adjacent servers; in fact, several technologies exist from the biggest server vendors to provide for just such an answer.  The network team members, who have found themselves thrust into the infrastructure limelight due to the efficiencies to be gained, struggle with this newfound stardom and the education that they must gain in order to elevate all of the network attribute qualities for which they are responsible.  Many enterprise IT buyers who are writing RFPs are in the process of adding (or have already added) some flavor of SDN language to the mix, which is good, but there is merit in having the discipline expertise contribute to the RFP itself.  Server administrators are the best at defining the understanding memory riser architectures and how best to deal with firmware ‘fun’ on their platforms, while network administrators are best suited to defining the wired architecture and intricacies and application guys can best address acceleration needs and OSI 4-7.  OpenFlow and SDN are amazing, but fundamental architecture needs remain. Continue reading “Despite OpenFlow’s Promises, Switch Architecture Still Matters” →

SDN Market Frenzy: Your Network Best Practices Remain Important!

by Mike Spanbauer, posted in Network
M. Spanbauer

Summary Bullets:

  • Software-defined networking (SDN) is a massive, all-encompassing concept which spans campus, data center, WAN, and carrier backbone networks (pretty much every type of networking infrastructure imaginable) and is being touted by some as capable of solving nearly every networking issue that has plagued us for the last 20 years; and yes, it does make coffee in the morning for you (no, not really).
  • Eventually, SDN may do most of the things claimed, but getting there will take a long time and some IT fundamentals and best practices will remain critical moving forward.

The OpenFlow protocol and (more recently) SDN have been discussed and put forth as solutions to complex, hierarchical, legacy architectures that were built up over years to solve the complex performance and management needs of enterprises and service providers alike.  Yes, the technology for each type of deployment was different (MPLS vs. OSPF vs. multicast, etc.), based on various criteria, but regardless of the technology, each vertical or segment executed on best practices learned over years of (sometimes painful) experience.  The result was a set of processes and instructions, if you will, that each IT or production environment team could leverage as they looked to new protocols or ports or architectures to avoid the same pitfalls encountered before.  SDN promises to eliminate the need for several of these, but a few still demand strict adherence or consideration. Continue reading “SDN Market Frenzy: Your Network Best Practices Remain Important!” →

Software-Defined Networking: Part 2

by Mike Spanbauer, posted in Network

M. Spanbauer

Summary Bullets:

  • NEC, IBM BNT, HP, and Juniper have committed to support and released OpenFlow-capable code.
  • The greatest impediment to mass-market adoption will be commercial support.

If you have read the trade magazines and press materials around network technology over the last six to twelve months, you have noticed a decided uptick in the number of articles that focus on SDN and OpenFlow.  These articles have covered the topics from the technology vendor perspective, as well as highlighting the academic and research communities’ support and interest in it.  There are commercial products available today through a joint effort from NEC and IBM.  HP announced the general availability of OpenFlow-capable switch software on a large swath of its switches, and Juniper committed to supporting OpenFlow within the SDK for its Junos developer community.  This is a demonstration of the networking community’s belief that there is promise and a bright future for this enabling technology.  Though conceived originally within the academic world for the purpose of network control and segregation to enable researchers, it has long since been perceived as a solution for certain ailments in the enterprise to address the scale and flexibility of networks.  It is clear with the increase in inquiries from both enterprises and observers, however, that interest in this movement is reaching critical mass.  The question is: When will it be commercially available, at scale, and supported in complex environments? Continue reading “Software-Defined Networking: Part 2” →