Mark, But SDN is NOT just ""SDN = some kind of automation””. Its centralized management with good automation built-in. Good automation means automation that orchestrates cohesive, correct network changes — and can roll them back — not just scripts that can spew configs into individual devices. And you say SDN consists of "bits of code and ideas coming out of these operators” as if that’s a bad thing. That’s how all innovation happens in IT.
Today's SDN has delivered on orchestration and good automation.You only have to shop and compare, the products are there and very powerful. But more germane to this discussion, I would expect any network engineer candidate to know all about SDN, know how various vendors implement it, and have experience using it. You wouldn’t expect a bridge engineer to not be proficient in advanced computational modeling, would you? Or an electrical engineer to not understand field-programmable gate arrays? Or a chemical engineer ignorant of SCADA programmable logic controllers? That’s the equivalent of an SDN-ignorant engineer in today’s market. -mel On Jul 20, 2020, at 10:34 PM, Mark Tinka <mark.ti...@seacom.com<mailto:mark.ti...@seacom.com>> wrote: On 21/Jul/20 07:12, Mel Beckman wrote: Mark, There are a slew of fine SDN products out there, from VMware NSX-T in big enterprise to Ubiquiti UniFiOS in SMBs, and lots of other products aimed at various market niches. What failed about the original SDN academic vision, more or less, was standardized, vendor-agnostic SDN based on protocols such as OpenFlow. Sure, a standardized platform would be nice, but you can’t blame vendors for wanting to differentiate their products to gain marketshare. OpenFlow never really delivered in a way that any vendors could build a competitive product around. HP tried, but, well, here we are. The goal SDN was created for was centralized management with good automation built in. Nobody ever promised single-pane management of multiple vendors’ network elements. Nobody promised that because there is no way to make a living selling that. And despite taking the long route to get to that conclusion, that is essentially what we've had to learn the hard way. If "SDN = some kind of automation", this isn't new. Operators abound have been "automating" for years... decades, even. It's just that their solutions have been internal, either entirely homegrown, or cobbled together with hand-written + external vendor-provided systems. These systems have grown and become significantly large to the extent that it makes it difficult for these "established" operators to want to participate in "standardizing" what they already have, or openly contribute to a standardization process because, well, they don't really have a problem to solve. Moreover, a lot of the drive on these "SDN thingies" is bits of code and ideas coming out of these operators (notably, the cloud bags [boys & girls]), when they are feeling generous to share what they've been working on with the community. Regardless of what they share, they are probably 10 years ahead of what we get to see. How do you expect to standardize a gap like that? Ultimately, I don't think the industry will reasonably agree on standardization of this process. 40 years of the Internet and you still can't "buy" an NMS that "just works". That should tell you something :-). We should be spending more time encouraging folk on how to simplify repetitive tasks. The actual solutions they decide to implement to get there should be left to them. I don't want to waste another decade on this. Last week's Cloudflare incident should remind us how uncomplicated this is. The problems we need to solve are as simple now as they were 25 years ago. So let's not complicate it anymore than we need to. Mark.
