Juniper’s Contrail Story: Left on Base?

Juniper has released an SDN Controller based on its Contrail acquisition, and the early state of the material makes it difficult to judge just how much of an advance the JunosV Contrail product is, for the industry or for Juniper.  I want to stress that I was not briefed on the announcement and so have had no opportunity to get any more detail than was presented in the press release, blog, and a white paper.  The latter was a re-release of an earlier one, so it didn’t contribute much to my understanding.  If we did baseball here, Juniper left a guy on base at the end of the first inning.

Those who read my blogs know that my biggest gripe with SDN is a lack of an architected higher layer to receive network telemetry and service requests and synthesize routes based on a combination of service needs and topology.  My second-biggest gripe is a data-center-only focus, something that doesn’t extend SDN to the branch.  Behind the first gripe is my conviction that you need to have a tie between SDN and the IP world that goes beyond providing a default gateway, and behind the second is my conviction that the IP world has to include all of the enterprise network or the strategy loses enterprise relevance.

I can’t say that Juniper hasn’t addressed these points, but I can’t say that they have.  There is nothing in the material that’s explicit in either area, and a search of their website didn’t provide anything more than the press release.  Juniper does include something I think is important for carriers and the cloud, and even for NFV—federation across provider or public/private boundaries for NaaS.

The best way to approach enterprise clouds is to consider them a federation, because nearly all enterprises will adopt a public cloud service and also retain data center IT in some form.  If we presumed that an enterprise was a private cloud user, the hybridization of the data center with public cloud providers would be almost a given in enterprise cloud adoption.  For cloud providers, the need to support enterprises with global geographies and different software and platform needs would seem to dictate a federation strategy—either among providers or across them based on an enterprise federation vision.  Juniper promises a standards-based approach to federation.

Cloud federation at the enterprise level, meaning adopted by the enterprise and extended to public providers without specific cooperation on their part, would be a matter of providing something like OpenStack APIs (Quantum, Nova, etc.) across multiple management interfaces, and the ability to recognize jurisdictional boundaries in Quantum to know which interface to grab for a given resource.  Juniper does mention OpenStack in their material, so it’s entirely possible that this is what they have in mind.

At the provider level, it’s hard to say exactly what federation would entail because it would depend on the nature of the cloud and network service being offered by the various providers.  There are three general cloud service models for IT (IaaS, PaaS, and SaaS) and a Quantum-based evolution of NaaS models as well.  In theory, you could federate all of these, and I think that would be a good idea and a strong industry position for Juniper to take.

Facilitating network federation is probably not much of an issue; physical interconnect would be sufficient.  The question is what virtual network structures were used to underpin application services.  Most of the prevailing cloud architectures use a virtual network overlay product set (OVS and related tunneling strategies) to create flexible and segmented application-specific VPNs.  To extend these across a provider boundary could be done in a variety of ways, including creating a boundary device that could link the VPNs or providing something to harmonize Quantum administration of virtual networks across providers (as I noted above).  Other formal approaches to exchanging route information would also be possible if we went beyond the virtual level to actual OpenFlow SDNs.  I think that some mechanism for SDN-to-SDN route exchange would be smart, and again something Juniper might well do—and do well.

I just don’t know if they did it.  There was nothing on how federation was done or the boundaries of the capabilities.  Juniper isn’t alone in saying little in their SDN announcements, of course.  Beyond avowing support for SDN, we don’t really know what Juniper’s competitors have done.  The whole topic is so under-articulated that I expect our spring survey will show that buyers can’t even align their goals with current products.  We have a fairly good idea of how SDN and OpenFlow can support data center segmentation and multi-tenancy for cloud providers, but we know little beyond that.  We have less on NFV, but here it’s because the work of the body hasn’t identified a full set of relevant standards.  Juniper has only one mention of NFV on their website according to our search, and it’s not related to their current Contrail announcement, but they have made NFV presentations in the past.

I think federation could be a good hook for Juniper and SDN, but to make it one they have to embrace an NFV story to cover the buyer-side issues and they have to outline just what federation approach they’re taking in order to validate the utility of their federation claim.  It may be these things will come along in a later announcement; they’re not there now.

Leave a Reply