(via Searching for an SDN Definition: What Is Software-Defined Networking? - Network Computing) Required reading.
In my view, SDN is not a tipping point. SDN is not obsoleting anyone. SDN is a starting point for a new network. It is an opportunity to ask if I threw all the crap in my network in the trash and started over what would we build, how would we architect the network and how would it work? Is there a better way?
All we are seeing today are failures and proofs of varying success to a new network. Drawing conclusions at this stage of development is pointless. We should be intrigued that people are asking: is there a better way?
Could not agree more. In fact, one of the big reasons I came to Juniper.
- Clean sheet approach to the DC network problem
- Software architecture with distributed control plane, but managed as a single entity. (An SDN)
- Hardware architecture that lowers latency & provides the equal-distant performance needed from SOA and turning DCs into computers without relying on the vulgarities of Ethernet as a transport mechanism (an integrated SDN)
- No change in behavior for compute / storage required as external interfaces are all standard.
- JUNOS automation (Netconf, etc) for infrastructure workflow/orchestration & connectivity to Openflowy sorts of stuff
Will QFabric be the cats meow vs and along with the 30 other solutions to DC networking? Time will tell. What’s important is the market is now questioning new decisions, something it hasn’t done in a decade. Game on.
Mr. Hölzle said Google would not be donating its networking software to any open source project. “It is very specialized,” he said.
Support is perhaps the biggest hurdle that stands in the way of adoption of OpenFlow. In order for product networks to adopt and deploy OpenFlow, ‘enterprise-class’ support must be made available. This is not as simple as troubleshooting a single switch, which can in itself be complicated depending on the logging capability and probes one may have on/in the network, but rather will span multiple devices, multiple disciplines, and (the greater challenge) quite possibly multiple vendors.
ODM hardware + Openflow does not = innovation
Over the last four days an interesting discussion around Openflow and QFabric. Granted it was kicked off by @Bradhedlund who is a knowledgeable guy when it comes to networks, but also works for Cisco as is known to shall we stay incite conversations from time to time.
[I’ll note here that when I originally posted this, I used a semi-derogatory name to describe Brad - which might have been fine had we been sitting around drinking beers, but was obnoxious on all other levels. I wasn’t thinking and it wasn’t right even though he and a bunch of others seemed to take it well. Brad - my apologies.]
This conversation highlights a common misconception of QFabric which is because it is deployed in multiple components, many network folk want to treat all the bits like a network… except it’s not. It’s a switch.
In general when ever you have a question about QFabric, start with - How would a single switch do that today?
Of course, the insightful people in the network community acknowledge the data path, but then go straight to the control plane, congestion management, and management of a intra-datacenter connectivity solution and begin asking lots of questions. Which of course is the right thing to do as at the end of the day resiliency and stability often trump performance.
Updated with tweets from @boobasan and @ccie15672
Interesting additions to the team and words from Volpi of all people.