olly - Fotolia
IBM SNA, SDN comparisons debunked
In a recent post on his Ethereal Mind Blog, network engineer Greg Ferro called on the networking community to stop comparing software-defined networking (SDN) with IBM SNA, saying that's like comparing a modern car to a Model T. He said the comparison does a disservice to SDN, recalling the complexity of IBM's systems network architecture (SNA), which was widely used by large companies to link their terminals to their mainframe computers.
Ferro said SNA's fundamentals were appealing: each layer of abstraction clearly spelled out, functions separated, and physical and logical nodes clearly defined. But it performed only a single function.
And IBM SNA had severe drawbacks, especially with installation, maintenance and cost.
Additionally, very few companies could innovate on SNA because of its rigid standards, which IBM tightly controlled, Ferro wrote. SNA's pitfalls offer a cautionary tale to the SDN community: Users don't want expensive networks with complex architectures and closed standards.
Read Ferro's entire post here.
SDN allows for more clearly defined business policies
In his blog, Keeping it Classless, network engineer Matt Oswalt responded to a recent podcast by Ivan Pepelnjak in which he said access control lists (ACLs) are a poor representation of business policy. Although Oswalt didn't disagree with the statement, he wrote that alterations to the network generally do result in changes to the ACL.
"We shouldn't be relying on ACLs to be the end-all representation of what we're trying to do," Oswalt wrote. "Admittedly, ACLs are not great representations of business policy, but it's not because it doesn't have enough fields to match on -- it's because business policy should be applied at a much higher layer."
Oswalt said that with SDN architectures, companies are able to run a network as a system, enabling them to pull metadata from outside and inside the network. With this integration, according to Oswalt, the industry is much further down the road to automation, allowing users to more clearly and effectively define business policy.
Oswalt wrote that until we treat the network as a system, ACLs will be isolated, necessitating more complicated, manual fixes.
Read the entire post here.
When do we need network programmability?
In a recent post on his iPspace blog, Ivan Pepelnjak addressed the topic of network programmability. He answered the question: Why should an enterprise go through the coding process to add a new virtual LAN (VLAN), rather than adding it manually with a Prime data center infrastructure management (DCIM)?
Pepelnjak wrote that the answer depends on where you are in your IT automation journey. If you're still deploying everything by hand, then he recommended sticking with DCIM. However, if you're in a DevOps environment -- automatically deploying virtual machines, for example -- then network automation should be a priority.
Read Pepelnjak's entire response here.
Three steps to keep IT policies and procedures regulatory compliant
Network programmability, SDN blend into virtualization hairball
White-box switching: Three paths to network programmability