Part of the interest in programmatic interfaces is fueled by the desire to logically centralize network control functions. A global view of network state can have many benefits but it does not preclude the use of distributed protocols within the network. Network Programming Interfaces (NPIs) provide a facility to construct global state, mutate that state and distribute that state to the network which in combination with distributed protocols can aid in achieving greater network efficiencies, improve visibility, robustness and add to the value of the network overall. When used the right way, these NPIs will help set a new balance between centralized and distributed control. Key to this balance will be domain or deployment specific constraints. Read More »
Now that the Internet community is done officially launching IPv6 (World IPv6 Launch) on June 6th, it is about time to seriously think about the co-existence of IPv6 and MPLS (i.e. MPLSv6) without relying on IPv4 for any control plane functionality.
Is it possible now? Well, yes (though the mileage may vary). Read More »
The onePK announcement Ric describes in the previous blog entry is game changing. It also intersects a trend which has gone fairly unnoticed in the networking standards areas. The importance of new standards is declining relative to advances in software and hardware. Read More »
Cisco’s OnePK (one Platform Kit) – APIs and the accompanying SDK is finally launching this week at Cisco Live! For myself and a few friends in Cisco, it has been a long journey to this point! Our passion is opening the network operating systems in such a way that customers can collaborate directly in code with the developers of the OSes and the platforms. The greatest challenge was, and still is, crafting a set of consistent and functional APIs covering the breadth of features in our network OSes.
Anyone who knows Cisco networking knows that feature consistency and breadth are all too often not found together. The unique challenge we have had is to achieve consistency without settling for a lowest common denominator approach. Letting platforms show their strengths while still offering a consistent programming model is a great challenge, and one I hope we will live up to.
Software Defined Networking, public networking APIs and abstractions are still in their infancy. Compare where we are today to the rich history of GUI APIs that we can read about here:
Networking APIs today are at a stage analogous to where applications under MS-DOS with proprietary GUIs were in the late 80s, coming up to the 1990s, when mainstream use of the desktop API’s propelled us into a decade of innovation in GUI elements and abstractions. Are we here with Network OSs?
“Boiled frog syndrome” refers to a fable that when you put a frog in hot water, it jumps out. However if you slowly heat up the water the frog is in, the frog will cook.
The number of features and associated CLI for networking equipment has increased gradually over the last 15+ years. Each feature is valuable in its own right, but the weight of all CLIs, all OSs, and all variations of deployment cannot be internalized by any human. The result: the concept of the über-CCIE is cooked.
The question is what displaces the CLI over time? It is argued by “good enough” network vendors that this complexity isn’t necessary. But considering most networking costs are operational costs, this argument can generally be discarded.
More articulate arguments are made by people who want to simplify overall network operations activities versus concentrating upon enhancements to CLI. Businesses don’t want to manage individual boxes; they would love to shed this complexity. Instead they would rather express their operational intents to their network, and let the network itself sort any box specific details.