During my full day interviews for a position with Cisco (a long long time ago), the situation looked promising: around noon, the Cisco representatives told me: “Good profile … Good protocol knowledge … we envision for you … a position as Customer Support Engineer in the WAN (Wide Area Network) team”. Then they were puzzled by my polite but firm answer: “Thanks, but no thanks: I would prefer to spend my career in Network Management”.  They were perplexed! I could see in their eyes: “We found a crazy one!”. They changed the interview schedules for the afternoon, to meet up with some other crazy ones in the Network Management team and, at the end of day, I signed my contract.

Network management has always been treated as … “special”.
On one side, network management is a necessary activity. Sure, networks still need to be managed by the operation team. On the other side, network management is an after thought, i.e. a post sales activity. Who would contact the operation team to understand their needs at the time of buying routers anyway?
Network management was not leading-edge, not really glorious. In an industry were routing was THE key technology, my routing guru (*) friends were teasing me: “what are you doing in network management?” This translation would actually be closer to what they meant: “WTF, don’t you want a real career?”. The recurrent existential question “should network management be profitable, or should it be a sales enabler (we sell networking and we give the NMS products for free)” added the “special” character of the beast.

(*) Guru (definition): term often associated with routing, and rarely with network management, reflecting the relative job importance of networking.

Enough said about the past, let’s focus on the present!

A fundamental shift started in the industry a couple of years ago: A transition from network operators to network engineers programming the network. This was triggered by the combination of multiple factors. Just to name a few: multiplication of the number of devices in the network, a increased number of network management configuration transactions per second, a compulsory move to lower OPEX (Operational Expenditure), the shift to virtualization, faster and faster services deployment, licensing on a pay-per-usage basis, … or maybe simply the realization that network management is essential.

With this transition, which brings the worlds operations and development together, new initiatives and buzzwords appeared: Software-Defined Networking (SDN), Controller, DevOps, network progammability, management plane, network APIs, etc.
Obviously, the NETCONF and NETMOD Working Groups at the IETF, respectively specifying the protocol and the YANG data model (language), are the core building blocks, but there are also some other initiatives:

• Some stem from the open source world, for example OpenFlow, OpenStack, OpenDaylight, or Open Vswitch
• Some are more research-oriented, such as SDNRG
• Some are covered in standards organization, but not in OPS, such as the IETF I2RS Working Group in the routing area

Interestingly, this new sandbox attracted many non traditional network management people. Some come with a development background, some come from different technology areas (remember the routing gurus), some just surf the wave. Don’t get me wrong: that’s a good thing! I’ve been thinking for some time to tell those guys that their jobs is actually “network management” related (“Father, forgive them, for they do not know what they are doing.”), but I was concerned to scare participants away by labeling this necessary shift with an old-school etiquette. Maybe one day, when they will be ready, I will tell them 🙂

Regards, Benoit