…and how reflecting on this can help navigate the path ahead in realizing the promise of the new software-defined model
A number of parallels exist between the nascent forms of software-defined networking (SDN) we are working with today and the early stages of development in a similar area of technology that began in the mid 1990s and required more than a decade of steady enhancements to become the essential part of many network deployments that MPLS is today.
By looking at these parallels we can gain some perspective on the nature of such innovations and, yes, their related upheavals, as well as inspiration for continuing to work hard on the finer points of implementation that will ultimately bring the simplified, more agile design model of SDN into wider use.
Let’s look at the parallels in point-counterpoint mode.
Today: We often say in moments of exasperation things such as there are too many forms of SDN; it will die before lift-off because the parts just won’t play with each other.
Then: In 1997 the comments were that there were too many forms of MPLS (too many ways distributing labels in a network, TDP, LDP, BGP, etc.), and how will we ever build multivendor deployments? In the end, meeting customers’ requirements whittled options down to a few basic alternatives that allowed for some choice, but ensured multivendor networks using MPLS could be built.
Today: There are too many choices for communicating with elements southbound from controllers; there is no real hope for efficiencies and scaling in control plane abstractions.
Then: In the late 90s on MPLS we said things such as there are too many choices for implementing VPNs, quality of service and traffic engineering with MPLS; we will never be able to build real service offerings. But eventually customers’ requirements brought RSVP-TE, MP-BGP, VPLS, and BGP/MPLS IP VPNs into play as means of meeting market requirements with interoperable designs.
Today: People ask, how do I monitor this (add your own euphemism) thing and dismissively assert that SDN will forever be a lab experiment unless the real-time and on-going needs of managing such software-driven solutions can be met.
Then: In the early days of MPLS we said similar things. MPLS was interesting in the lab, but it would never be adopted widely unless we solved the OA&M problem. And with the firm guidance of customers’ demands the development of mechanisms to manage MPLS networks evolved via RFC 4379, LSP ping, LSP traceroute, and other mechanisms widely employed today.
And as we speak, innovation around MPLS is not yet dead despite its widespread adoption. EVPN and Segment Routing are two cases in point for how the evolution continues.
By reflecting on these innovations and their refinement over time, we can perhaps weave in a modest amount of patience amidst the stream of developments and implementation models we are digesting with the new designs that are ushering SDN incrementally into our multidomain, multilayer, and multivendor world.
In the end it may not matter if OpenFlow, XMPP, and NETCONF coexist in portions of an otherwise abstracted control plane. It may not matter that the service management templates used in different controllers vary greatly in implementation today, as they may evolve to converge on a few basic models as customers’ deployments continue, as happened with MPLS OAM.
No doubt we are in the disruptive, chaotic, and sometimes confusing phase of innovation when it comes to SDN (for the WAN, for overlay networks, for underlay physical systems, for VNFs, etc.). But if we focus on the gains available from the architecture that have been shown in their early forms to date (flexibility in platform choice, efficiency and scale in monitoring large network systems, and acceleration of new service deployment, to name a few examples) and work on closing the gaps in the implementations that remain to be resolved for the deployments to be pursued with more confidence, we may benefit in a manner similar to the way we did from the persistence of the innovators who spawned MPLS and labored for its viable deployment in the wide array of use cases we have it deployed in today.
For more information about ACG’s SDN services, click here.
Paul Parker-Johnson
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.