The open source OPNFV project is grappling with whether to expand its scope to include management and orchestration (MANO).

There's little question that OPNFV, which aims to produce a reference implementation for network functions virtualization (NFV), has to eventually include MANO. The question is whether it makes sense to do it now, with OPNFV barely a year old and preparing only its second code release, due in February.

Convictions run firm on both sides, judging from informal conversations at last week's OPNFV Summit. The matter inevitably came up at the end of that week as well, during the Nov. 13 OPNFV board meeting.

An email calling for votes on NFV MANO was due to come out sometime this week, according to one source who attended the meeting. Based on the board meeting, the source couldn't tell which way the vote was leaning. (OPNFV officials couldn't immediately be reached for comment.)

From the outside, this might sound like procedural trivia, but the undercurrent is that carriers, accustomed to rigid standards, are adapting to the relative chaos of the open source world. It's not easy.

Any complete NFV implementation will almost certainly need a higher-layer management piece that talks to applications and OSS/BSS. That's part of the role of MANO. If the industry waits too long to standardize on some form of MANO, more and more individualized versions of it will pop up, so the argument goes.

OPNFV's initial scope. Source: OPNFV

One example would be the OpenMANO project that Telefónica showed at Mobile World Congress early this year. OPNFV would be better served by considering those developments now, some believe. (Interestingly, Telefónica is not an OPNFV member.)

According to our source who attended the meeting, the analogy brought up by one board member is that NFV is the car that carriers want to buy, but OPNFV is obsessing about building the tires. The argument was that OPNFV should stop thinking about boundaries, as OpenStack once did, and start thinking about the big picture.

The argument for omitting MANO from Arno, the project's first code release, was one of practicality. The board decided that producing some code was a priority — showing some forward motion, as opposed to getting mired in formal debate.

Orchestration was considered too slow a step because the MANO definition was so vague at the time. Moreover, orchestration is difficult in general. So, OPNFV limited itself to infrastructure and the virtualized infrastructure manager (VIM).

That work remains in progress, which is one argument against OPNFV making the jump to MANO.

OpenStack comes into play here as a negative example. OpenStack itself is a likely candidate to fill that VIM role, but many believe OpenStack isn't ready to do that. Specifically, OpenStack isn't carrier-grade, one OPNFV participant told me; items such as fault management can't yet be taken for granted. It's something being investigated by the OPNFV project named Doctor.

Photo: Linux Foundation.