This is one of the reasons I'm hesitant to embrace the various NoSQL options at this time - often there's only one implementation of an API, and it's tied to that code.
Compare this to the various message queueing options that all support STOMP or AMPQ, or programming languages that have multiple implementations.
Networking needs to define a format spec for routing and switching, and then have vendors meet the spec. Fortunately we should be getting something like this with software defined networking projects like OpenFlow.
"Networking needs to define a format spec for routing and switching, and then have vendors meet the spec."
Please check out the IETF (www.ietf.org) -- This is exactly how it works.
But BGP has no security, is complicated from an implementation standpoint, and you are right, there is a bit of a software duoculture. Juniper and Cisco. That's it.
This has happened before... too bad the routers didn't crash BEFORE propagating the bad BGP updates. :-)
They still make some great gear, as does Redback (now Ericsson) and a bunch of others. But for direct, Internet facing devices that manage the full global routing table, the preferred option is still Cisco or Juniper.
Even if there were many main stream options, Level 3 would not likely deploy much more than two in each level of it's network because of the complexity of managing and maintaining them. It might even be worse with OpenFlow if the majority of hardware vendors deployed the same open-source derived software, all with the same bug.
I agree with the advantages of a format spec for routing and switching and the promise of OpenFlow, but I think it's orthogonal. I could be misunderstanding your comment, but this failure was due to a software bug, which could exist whether or not there's a spec.
If a router is reset couldn't that cause some large changes in the BGP tables and subsequent route flapping as routers go on and off line. Perhaps large changes like that trigger the juniper bug if there is one.
This is one of the reasons I'm hesitant to embrace the various NoSQL options at this time - often there's only one implementation of an API, and it's tied to that code.
Compare this to the various message queueing options that all support STOMP or AMPQ, or programming languages that have multiple implementations.
Networking needs to define a format spec for routing and switching, and then have vendors meet the spec. Fortunately we should be getting something like this with software defined networking projects like OpenFlow.