In June 2013 I wrote a rant that got stuck in my Evernote Blog Posts notebook for almost two years. Sadly, not much has changed since I wrote it, so I decided to publish it as-is.
In the meantime, the only vendor that’s working on making generic network deployments simpler seems to be Cumulus Networks (most other vendors went down the path of building proprietary fabrics, be it ACI, DFA, IRF, QFabric, Virtual Chassis or proprietary OpenFlow extensions).
Arista used to be in the same camp (I loved all the nifty little features they were rolling out to make ops simpler), but it seems they lost their mojo after the IPO.
If you have a well-designed network, and manage to push all the complexities onto the network edge (VoIP, iSCSI, virtual overlay networks, virtual appliances ...), all you need in the physical switches is all IP connectivity, in data center environments usually implemented with a Clos fabric.
It would be ideal if you could just plug the new switches in and they would auto-configure themselves and just work - and Brocade was pretty close to meeting that goal when their VCS fabric was a simple L2 solution.
The problem is that the existing switch configuration mechanisms are not well suited for that, and that's not due to lack of protocols or technologies, it's due to inability of networking vendors to be minimally creative and use the existing technologies and protocols that they already have implemented to their full advantage.
For example, when you plug in a new ToR switch, would it be really that hard to put some ports in uplink mode, listen to LACP updates on those ports, and auto-configure port channels when it turns out the other end wants to run port channel? Also, would it be THAT hard to support unnumbered P2P links over Ethernet so we could run OSPF without configuring IP addresses and subnets on every uplink interface (BTW, this will work with IPv6 automagically).
Junos supports unnumbered Ethernet interfaces (including OSPF support) since Junos release 8.2 - thanks to Doug Hanks for pointing that out in the comments!
The list could go on and on - for example, why wouldn't you use LLDP and figure out if there's another switch from the same vendor at the other end of the link. This might not be a ubiquitous solution, but at least I hope people aren't stupid enough to build multi-vendor Clos fabrics in a single pod or availability zone.
It could be really easy to add new ToR switches to an existing network, or to rewire Clos fabric if needed without changing all the IP addresses and OSPF setups, but alas, switch vendors aren't doing any of that, because it's sexier to promote all sorts of crazy stuff like SDN, APIs, Puppet/Chef on the switches, than to build boxes that just work using existing features and protocols.