You Must Understand the Fundamentals to Be Successful
I was speaking with a participant of an SDN event in Zurich after the presentations, and he made an interesting comment: whenever he experienced serious troubleshooting problems in his career, it was due to lack of understanding of networking fundamentals.
Let me give you a few examples: Do you know how ARP works? What is proxy ARP? How does TCP offload work and why is it useful? What is an Ethernet collision and when would you see one? Why do we need MLD in IPv6 neighbor discovery?
Networking is already commoditized enough that most engineers never truly master the fundamentals (it's one thing to hear about ARP in a CCNA class and completely another one to troubleshoot an interesting proxy ARP problem caused by overlapping subnets), but it’s only getting worse.
In the SDN world, the networking infrastructure will become ever more complex, and you’ll experience totally unexpected interactions between controllers, controlled network devices, and attached end hosts. The deep understanding of the fundamentals will be the only way to ensure you’ll successfully fix problems in your SDN networks, regardless of the clueless marketing VPs telling you how we no longer need networking engineers.
The lack of understanding of technology fundamentals, and their impact on solutions we’re trying to deploy in our networks was one of the primary reasons I started creating ipSpace.net webinars. Have you tried the free introduction to SDN? Did it work for you? Need more details? Check out the advanced SDN track, and get access to all ipSpace.net webinars with the yearly subscription.
SDN is also a vague term that seems to encompass all areas of networking. It would be more valuable if the problem was decomposed into different areas for example SDN for data centre, for campus and for WAN or break it up into Edge vs Core SDN. In my opinion these areas would have significantly different solutions.
Nope Ivan you need not say any more. Spot on. Just reading the Cisco Press "The Policy Driven Data Center with ACI" and to be frank on first purse what a mess.
Forget about the HW ASIC+ on the 9k and all the juggling between the NFE, ALE, ASE and Buffer boost, odd over subscription and a recast version of what sounds like WFQ, plus your previous ACI posts. Look at how this is all orchestrated and controlled between the APN profiles, Tenants and EPGs, subjects, contracts, lables, bundles special multicast EPGs and all the rest of the Progresso soup and you wonder WT@#%$%^ were they thinking. I think in one of your older posts you called it spaghetti ;) See chapter 3 The Policy Data Center and chapter 4 Operational Model and you will see what I am talking about. I do get it and it makes sense but you think they could have come up with a better approach/system to simplify.
Regards...
As Ivan says these marketing VPs are blind to this, yes we might need fewer level 1 folk to provision services but the level 2 & 3 people need to be more skilled / expensive than before.
If you're still deploying everything by hand, and hand-crafting VMs from ISO images, then DCIM is the way to go. It gives you a somewhat consistent view of your data center, and you can deploy something like a VLAN across multiple boxes without ever logging into one.
If however your server/application people got further along on their path toward DevOps, they might start getting annoyed that they can deploy a VM in 5 seconds, but it still takes dozens of GUI clicks to get a new VLAN deployed. In those environments the need to program networking devices becomes pretty urgent.
Hope this helps,
Ivan