SDN/NFV: We Don’t Need Everything We Think, but We DO Need Some Things We’re Not Thinking Of

Revolutions have their ups and downs.  “These are the times that try men’s souls,” said Tom Paine before the American Revolution, and the current times are probably trying the souls of many an SDN or NFV advocate.  For several years, we heard nothing except glowing reports of progress in both areas, and now we seem to hear little except statements of deficiency.  Both these conditions fail the market because they don’t conform to reality, which is somewhere between the glow and the gloom.  Obviously it would be nice to find a technical path that takes us there.

It’s easy to make progress when you’ve defined what “progress” means.  SDN and NFV both took the easy way out, starting down in the technical dirt and picking a little incremental piece of a very large and complicated pie.  That was dumb, to be sure, but it’s hardly fatal.  Even if we leave aside the ongoing question of business case and look to technology issues, we’re not really too deep in the woods…yet.

The biggest problem both SDN and NFV now face is that an effective operational umbrella and a complete picture of infrastructure have yet to be offered.  Given that services have a variable dependency on both operations and infrastructure depending on their specific features and targets, that means that it’s very doubtful that a vision for “total SDN” or “total NFV” could emerge from PoCs or use cases.

Absent an architectural vision to unify all these efforts as they progress, we’re already seeing what one operator characterized as “The Death of Ten Thousand Successes”, meaning an explosion of silos built around vendor and emphasis differences.  In many cases these silos will also be layered differently, approaching EMS, NMS, SMS, OSS, BSS, and whatever-SS differently.  It would do no good at this point to define a unified approach; it’s too late to take it.  What we need instead is to unify all our approaches in some way.  Fortunately that way has already presented itself in the principles of virtualization–abstraction.

An abstraction, or a “black box” or “intent model” is a functional concept or external behavior set that’s separated from its possible resources through a representation model.  “Black box” is a great term for this because it reflects the essential truth—you can’t see in, so you only know a black box by its properties, its interfaces and their relationships.

The reason this is nice is that such a black box can envelope anything, including any SDN or NFV silo, any interface, any network or IT element or service.  No matter what you do, or have done, it can be reduced to a black box.

Looking from the outside in, black boxes anonymize the implementation of something.  Looking from the inside out, they standardize it.  You can wrap something in a black box and transform how it looks, including from the management perspective.  It’s easiest to understand this by going to my description of an intent model from earlier blogs, to the notion that intent models or black boxes representing services have an associated SLA.  You could think of this SLA as a local data model, since everything that’s variable and knowable about a service should be thought of as being part of or contributing to an SLA.

Let’s take this principle and apply it at the top.  If we have an SDN controller or an NFV domain, we could wrap it in an intent model or black box.  Once inside it’s just an implementation of something, so a “service” created by either SDN or NFV is a realization of intent, an implementation inside the black box.  A legacy solution to the same service would also be such an implementation, so we could say that black box wrappings equalize the implementations.  And, if we assume that the black-box model of an SDN or NFV or legacy service has the same SLA (as it must, if it’s an implementation of the same abstraction) then we can say that the management variables of all this stuff is identical.

Now we get to the good part.  Because all of the implementations inside a black box are exposing the same management variables and features, they can all be managed in the same way.  Management is simply one of the properties abstracted by the black box or intent model.  It can also be “orchestrated” in the same way, meaning that everything that can be done to it on the outside can be done regardless of what’s inside.

Harmony at any level, within SDN or NFV, could be achieved using this approach.  If an SDN controller domain is an intent model or black box, then its management properties can be the same regardless of who implements it, or the boxes underneath.  They’re also the same as the properties asserted by real switches and routers or NFV-deployed virtual switches and routers, and all of these are the same regardless of the vendor.  If an NFV resource pool is represented by a series of intent models for the type of things they can do, then any set of hosting and connection features that can be combined to do anything useful can be represented, and the implementation can be anything that works.

With this approach the arguments on what the “right” data model is for NFV are moot.  As long as you model intent the way it’s expressed is a minor issue, one that software developers resolve regularly with transliteration processes for data and Adapter Design Patterns for interfaces.  The discussions on interfaces are moot too, because you can transform everything with these models.

What this represents for the SDN community, the NFV community, and the OSS/BSS community is profound.  You can pull this all together now, with a single stroke.  Further, if you focus orchestrating on combining intent models into services and focus management and operationalization on managing and operationalizing intent models, you can have one OSS/BSS/NMS model for everything.  All you have to do is make sure that what is inside an intent model translates between that model’s SLA goals and the internal steps represented.

We hear a lot about orchestration and modeling today, and it’s clear that having a single approach that crosses SDN/NFV and legacy, OSS/BSS and NMS, would have helped.  We can still have it.  You could build such a product and apply it at the top, the middle, the bottom.  Best of all, at least some of the products already built seem to have a lot of that capability.

I’ve always said there were six vendors who could make a business case for NFV.  These also incorporate at least some SDN and legacy vision, but it’s not always clear how these work in detail.  In particular, it’s not clear whether the modeling and orchestration meets black-box or intent-model standards.  Based on public documentation that I’ve seen, I can say that Ciena and HP are almost certainly capable of doing that which is needed.  Overture probably can, and I think Alcatel-Lucent, Huawei, and Oracle are at least looking at the approach.  While all these vendor-specific solutions are invitations to silos, that doesn’t hurt much in an intent-modeled black-box-seeking world.

What does hurt is a lack of acceptance of intent model principles lower down.  Both SDN and NFV need to look at their interfaces in those terms, and while there is some black-box momentum in the standards processes for both these areas it’s not yet fully percolated thinking.  I’d sure like to see the notion move quicker, because if it does then we would be closer to a deployable model of next-gen network services.