questions asked during network engineer interview

Tue Jul 21 14:59:50 UTC 2020

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.tinka at seacom.com<mailto:mark.tinka at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200721/cc36f4be/attachment.html>