Network Programmability is the answer ! What was the question again ? Or , is there really a case for Network Programmability ?

Recent developments in the broader networking community involve the decomposing and/or refactoring of network functions in order to ease the introduction of new protocols and services and indeed new networking architectures [3, 4, 8, 6, 5]. At first blush this appears to be a most desirable development from a service provider point of view, because it enables the introduction of new features/services without the need for industry wide standards or even buy-in from vendors. However, to some extent, as a community we have been here before: recall the network programmability efforts of the late 1990’s [11, 9, 12]. These earlier efforts met with limited (if any) success. While many reasons can be found for this less than desirable outcome, we argue that a primary reason (if not the primary reason) for the lack of success resulted from a poor understanding of the problems that these approaches were meant to solve. Indeed, as technologists, we exhibit a proneness to focus on the often more clearly defined mechanistic side of a given problem, rather than questioning whether that is the right problem to address. Despite constant customer demand for new services/features, and the obvious monetary incentive associated with that, the introduction of new network services and features has been an extremely protracted process for ISPs. We argue that the difficulty to rapidly and safely deploy new services and service features is the single most important challenge facing ISPs today. Given this position, we first define what we mean with network programmability and network services and then attempt to articulate why service deployment is challenging in today’s environment. Finally, we offer some thoughts about the applicability (or not) of open/programmable architectures to address these problems.