Big Flowering Things and Lego Bricks
Matt Oswalt wrote a great blog post complaining about vendors launching ocean-boiling solutions instead of focused reusable components, and one of the comments his opinion generated was along the lines of “I thought one of the reasons people wanted SDN, is because they wanted to deal with The Network – think about The Network's Performance, Robustness and Services instead of dealing with 100s or 1000s of individual boxes.”
The comment is obviously totally valid, so let me try to reiterate what Matt wrote using Lego bricks ;)
If you ever played with Lego bricks (or Minecraft ;), you know you can use them to build almost anything (including TCP/IP packets and a data center model). Not surprisingly, like any good engineer Matt wants Lego bricks – reusable components that he could use to build his solutions.
Unfortunately, it’s hard to get useful Lego bricks in networking land. What we usually get are pretty useless components that can only be used in one way.
With the advent of SDN, the situation got worse – most SDN vendors are selling you prefab solutions that use proprietary protocols and work only if all components run their software - if anything, the networking is becoming even more monolithic than it has been before. It’s like getting a Lego Death Star after Lord Business glued all the bricks together – it looks awesome from the outside, but it’s impossible to use the components to build anything else.
Obviously the business people paying the engineers can’t understand why they should pay people playing with Lego bricks (and even send them to training to understand the next-generation bricks coming out). All they want is a great toy, and I totally support that sentiment – if all you want to do is look at the Death Star, there’s no need to get involved with the individual bricks.
Unfortunately, the people who don’t want to know anything about the bricks usually never consider what might happen when they drop their toy (or their younger sister sits on it). We all know vendors tend to promise heavens-on-earth when they’re selling their warez, and most of us have at least one gruesome tech support story to share.
Finally, since everyone and their dog think their business is unique, they’re usually not happy just looking at their Death Star – they want to adapt it to the uniqueness of their situation, which is a bit hard to do if you cannot change it, because you bought a pre-glued toy, and not a box of bricks.
Want More?
For more real-life (or “contrarian” as someone put it) SDN perspectives read my SDN books or watch my SDN webinars and presentations.
I fully agree with your perspective outlined in the aritlce. Interestingly, your viewpoint is similar to that of David Meyer (now Brocade, IETF, etc..) in which he also makes references to the real future of SDN being one where there's a "block system" in place. For those of the audience that may not being following the industry as closely, in your closing comments you indicated "...Most of the controllers are no better than routers and switches...today". From your perspective, which vendors innovation delivers a product that's more closely aligned to the future of where the broader industry (operators, enterprises, etc.) could benefit from SDN.
I disagree with the premise of the article. I think there are cases where businesses need an all encompassing Death Star solution. Unless your a huge software development group with unlimited amount of resources, writing your own application software to handle the fundamental SDN features is cost prohibitive. I agree that the underlying protocols should be standards based, but right now there is tremendous disagreement on those standards, and not just because of the behemoths in the networking industry. If you look at software development, how many different flavors of programming languages are there out there? How many modeling languages (YAML, YANG, JSON) are needed? Everybody has their flavor of their month. One thing I learned as a programmer, before starting out my career in networking, was the most important aspect was extensibility and providing access to the underlying data. In the majority of cases, the Death Star will provide the needed functionality. When it doesn't, it's a great starting point to add additional functionality.
Great Lego analogy. I found Mr. Oswalt's blog compelling, as well.
Looking at networking as the ex server and storage type I am, I see Lego blocks (a wide variety of boxes, or even ASICs) which naively can be combined in many creative ways, much as I did with Legos as a child.
However, Legos fit together in a very simple, standardized way. In user interface terms, Legos are WYSIWYG. Networking is different: over the last 30 years, we've accumulated an incredible amount of complexity, largely in the control plane. Imagine Lego blocks with rules like "if you want to mix red and white blocks in the same design, it must be built on a pink base and there must be a grey flat piece between each connection of a red Lego to a white Lego." Pretty soon people couldn't just build things themselves, they'd need a Lego Master Builder. Or at least a CCIE.
So we're at the point where if you're an application developer and need a Death Star (some infrastructure to run your app on), you can't just throw some boxes together, you need to either buy a pre designed Death Star kit (one of the various vendor designs) or employ a Lego Master Builder to design you a custom one.
Seems to me as an old server guy, and then a somewhat more recent storage guy, that this creates the opportunity for a de facto standard (the x86 server running Linux comes to mind) which that app guy can in fact just plug together, to displace the full complexity of networking as it's evolved today. Maybe specialized for the wired/wireless campus, another for data center, and a different spin for service provider (more NFV than Lego). Will be interesting to see what happens over the next decade.
Achieving the Lego-like goal, which is worthy, will be as disruptive to the network industry as standardizing on x86 and Windows/Linux was to servers. I don't think we're ready. Do you?
@FStevenChalmers
(opinions my own, work for Hewlett Packard, which is in all of these businesses)
Could someone explain to me what such a lego-network will look like ? What will be the blocks ? And how will it be substantially different from the "old" networks that had routers, switches, load-balancers, firewalls, etc ? What will these "SDN-lego-blocks" do differently than those old "old-f'em-lego-blocks" ?
(Note, I'm not for or against SDN. I don't even work in this industry). From what I understand, these are the reasons why people want SDN. Please tell me if I'm wrong.
1) The big established vendors don't really want any change. Or don't need it. If things stay the way they are, they keep making money. Bastards.
2) Start-ups and companies that have been unsuccessful in the past want as big a shakeup as possible. Because they might give them a chance to be successful in the future. One thing I don't understand: if you can not successfully build and sell simple technology like linkstate routing and bridging protocols, a scalable BGP implementation, and hardware that forwards at linespeed, why do you expect you will be successful at building and selling something that's a lot harder to develop and build ? In the end, the true SDN (route compute on a central server, OpenFlow to transport fibs) might not even work.
3) People who build networks would like all the small vendors to be successful too. Because they can leverage that to lower the prices of the big vendors. If they'd buy and mature the small vendors today, they could achieve this goal without SDN. But they won't.
The only thing I see that buyers would really like is equipment that is easier to configure. And easier to troubleshoot. Some forms of SDN might do this, some might make things even harder.
There are so many ways boxes could be made smarter, without need for new protocols or technology. Some AI inside boxes that will tell you really what is wrong, and not just spout out a cryptic warning. Or boxes that understand what they are supposed to do, and understand what is going on when that is not happening. Boxes with zero-config (well, a unique identifier maybe). You need MPLS to do traffic-engineer ? You can do much smarter forwarding with current IP routing protocols, if someone would bother to look at some new stuff you can do with old technology. But no. The industry (vendors *and* their customers rather add a few more new protocols, encapsulations and paradigms).
From: https://tools.ietf.org/html/rfc1925
(12) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.
This awesome design-rule seems to be completely forgotten in these days of SDN.
I honestly don't think we need revolutionary new paradigm, we just need a better mechanisms of selecting, deploying, configuring and managing what we already have - and that's where every single vendor so far has failed miserably.
Best,
Ivan
Network design consists of a *huge* pile of building blocks. Physical blocks, like routers, switches, load-balancers, firewalls, application-gateways, dns-servers, you name it.
--
That's not really true. Yes, those are building blocks, but at a larger scale than what Matt is advocating for. Think about the number of times you've bought a switch from a vendor, or a router, which had feature X but not feature Y, when the best device for your application would be feature X + feature Y. This is a very common case in service provider networks and is also common in enterprise networks. The devil in the details is "positioning" and most vendors would like you to buy two boxes rather than one. The cost for development of a feature tends to be born by individual product teams who don't work collectively towards a shared set of goals. The situation is improving, but it's not improving fast enough.
Matt's conjecture seems to be that if you're going to give me feature X, then give me feature Y as well but let me choose where to put them. His argument is that it's not up to the vendors to determine whether or not I get feature Y in my data center switch; it's up to me as the customer. And that makes total sense.
Hey Ivan, as you know I work for Cisco as part of the CVG WANO group, that is what you previously knew as Cariden & the MATE product.
I wanted to make some points about Matt & your observations
1) The demand for modular SDN vs monolithic SDN is something that I personally believe is very dependent on the type of customer we're talking about. In the American markets, you have a tier of SP/Carrier networks where they want flexibility and they are prepared to staff and manage a dev-ops group within the organization. You also have in that same market a tier of customer that are seeking a magic box that does everything and just has a set of API they can exercise.
2) When we talk to customers, depending on the point if insertion we get different response as to what they want from a SDN system. If we talk to Engineering teams, the request is often a single point of interconnect to an SDN system (the magic box) but that single system has to be separate and unique between different teams, 1 for Optical/Transport, 1 for IP/MPLS, 1 for Data Centre etc. When we talk to Enterprise / Infrastructure Architects, they are seeking a modular flexible solution, but each tier must serve a unique purpose and there should only be a single north most interconnect point for their systems. When we talk to Product Management/Marketing teams we see a desire for off the shelf SDN applications (COTS) that require some integration professional services. When we talk to CTO & Executives, they are often seeking a modular solution which supports internal innovation but should encompass the entire organization SDN needs.
From a Vendor perspective, it's almost impossible to meet all these requirements with the current opensource based controllers & orchestrators no matter how much code each vendor uploads.
What is Cisco doing?
Without going into IP information, the simple answer is approach is completely modular, but also includes bundled SDN application packages to meet well established requirements.
Tail-F NSO (nee NCS) is proposed as the yang based service orchestrator and traditional element configuration manager.
- This platform in essence automatically builds all the north bound interfaces (Rest/Yang/libraries etc) dynamically based on Service Model Yang.
- It serves a role as a stateful configuration/protocol controller
Cisco WAE (nee Cariden Mate) is the vendor agnostic Analytic, Topology and Modelling SDN system for Layer 1 and Layer 3 networks.
- Any whatif, resource reservation or outage/failure reservation can be analysed or modeled independent of the protocol, vendor or architecture.
Cisco OSC (nee Opendaylight) is the open source, open standard SDN protocol controller
- Mainly for stateless protocols like PCEP, SR-TE, BGP-LS etc.
- Brings with it Layer 2 topology modeling in the SAL layer
- Exposes all it's control methods northbound as Netconf Yang, as well as other API like REST and programming libraries etc.
The stack above is not perfect by any means but it's certainly very flexible, probably the only complaint I've seen is need to understand which combination of tools is best suited for a particular use case. Those types of discussions are more about who the customer is before we present a particular solution.
- Best Regards Martin