/var/blog
mbushong

Nicira and Programmable Networking… a Juniper Perspective

by ‎02-06-2012 10:03 PM - edited ‎02-06-2012 10:08 PM

kinect-hacked-to-mimick-minority-report-ui.jpegToday the networking world has been all ‘a-twitter’ about Nicira; the networking start up who earlier this morning unveiled its network virtualization solution. Based on some of the analysis I’ve read, you’d think a gaping hole has opened up underneath Mathilda Ave. and Tasman Drive, destined to swallow the fortunes of network infrastructure vendors. But fear not; the reality is far more interesting -- and exciting. 

 

Network Virtualization shines a light on the deep, dark underbelly of network infrastructure today. For too many years, we’ve treated it as plumbing: a service that needs to be ultimately reliable, infinitely scalable, and as close to zero-cost as possible. But the more we’ve driven cost out of the system, the less attention we’ve paid to our customers needs - flexibility and dynamic control which is where the real value lies.. 

 

The unfortunate truth is:today’s networks are static and brittle. They’re far too big and complicated to run by hand and are therefore operated by a maze of management, provisioning and OSS/BSS systems.Complex change management procedures use process to drive out operational errors, but they push the network further away from being able to adapt to the business. They’re also as blind to the applications running on them, as the applications are to the network itself.

 

Juniper and Nicira share a vision: a future of dynamic, adaptive networks. Over the past three years Juniper has led the charge for the industry – developing and embracing programmable interfaces at multiple levels – including support for protocols like ALTO (Application Layer Traffic Optimization), PCE (Path Computation Element) and BGP-TE (Traffic Engineering data in BGP) – all of which enable externally visible and signaled connectivity. 

 

Juniper also plays a leading role in demonstrating OpenFlow as an interface to granular control of application forwarding in the network, highlighting how programmability is about adding value to network control, rather than a threat of commoditization. Network-centric APIs come in many flavors, operate at many layers of abstraction, and enable powerful new capabilities for carriers and enterprise networks alike. 

 

Network Programmability seeks to bring networking back into the fold of orchestration; to rejoin a pool of resources that scales and adapts to the needs of the business. Service Oriented Architectures teaches us that a network must enable and protect dynamic conversations between multiple endpoints (and not just in cardinal compass directions). Now, more than ever, the network is the fundamental glue between users, endpoints and services.  But somehow it’s not part of the orchestra today.

 

Abstraction and integration

As you dig into the technology, you’ll find that Nicira delivers two critical pieces to network programmability: flexible communications between endpoints, and a critical northbound API to higher-layer provisioning systems that harmonize the server, storage and communications resources.

 

Nicira’s solution enables communications between virtual machines by creating an overlay. It leverages GRE, and is similar to other tunneling protocols (like VXLAN or L2TP) that tunnel communications between network endpoints – but it adds a crucial element:  information and control. Instead of flooding the traffic, it maps connections between endpoints, based on input from the orchestration tools above. This is how the company proposes to deliver dynamic, custom communications paths between virtual endpoints – and deal with the inherent mobility of nodes in a dynamic datacenter.

 

This network abstraction layer is designed to make the virtualized network operate over any type of underlying physical infrastructure, and is a splendid first-step in adding networking to the pantheon of virtualized resources. But with great flexibility comes a lot of stretching. In this case, it means overlooking one of the primary values of network architectures today: the detailed understanding, and efficient use of the underlying network topology. As long as applications demand consistent throughput, and timely delivery of packets (read: bandwidth and latency guarantees), you can’t over-simplify the transport through virtualization. 

 

Here at Juniper, our experience in global network infrastructure has taught us that network abstraction is important, but represents only half of the problem. Awareness and control of the underlying topology is fundamental to deliver flexible services at scale. As virtual overlay networks seek to extend outside the datacenter, it’s critical that these systems interact with the underlying network in order to deliver the service levels demanded by real-time business communications.

 

The second value proposition is Nicira’s integration with the orchestration layer. This shows the true value of Network Programmability: the ability to add the network back into the business value chain. It’s what closes the gap in today’s networks and the applications that dynamically traverse them – and where we as an industry must advance.   

 

So, how do you get there? As with any new architecture, the devil is in the details. To make the network programmable, you need to have pervasive interfaces to the orchestrators above and the underlying topology below. This support for APIs has to span multiple device types and must be consistent and relevant to the problems our users are trying to solve. The challenge in enabling this end-to-end dynamic communications is to program conversations traversing the LAN, WAN, Datacenter, and even intermediate security enforcement nodes. Matching these network flows to services (like security) is one of the toughest network engineering tasks today – and dynamic services integration is ripe for integrating into an orchestration solution. But building a system like this across multiple operating systems means taking on the task of translating multiple dialects of lower-level programming interfaces. As a vendor, Juniper has built a solid foundation of One Junos as a common control plane for our routing, switching and security products. This puts us is in a unique position to deliver consistent and useful topology-aware APIs across the network and its service-enabling nodes.

 

It’s all about workflow

When I ask myself what has happened in networking in the past decade, the biggest shift has been from treating it as connectivity (read: plumbing) to communication. It sounds like semantics, but there’s a crucial difference. The workflow of running a network has traditionally centered around the task of “keeping the lights on” – in other words, keeping the infrastructure available, stable and secure. This results in highly static, deterministic networks, with careful change controls and stacks of best-practices and operations procedures designed to keep accidental keystrokes from violating SLAs. The server world was here just a few years ago. Server virtualization taught us a valuable lesson: if you run a utility with a mindset centered on eliminating operational issues and downtime, you stifle innovation. When you make the system more intelligent and adaptive, you can start to reap the rewards from all your resources. But this means re-evaluating how you deliver and support production resources.

 

The world of IT and network communication works faster now. It’s not about servers, links and connectivity anymore; it’s about capitalizing physical resources through dynamic workflows. It’s also not about servers, or network links anymore; it’s about workloads and communication paths.

 

Juniper has always been cognizant of how our users run their networks.  We built our business not only on highly-available, high-performance networking – but also in better understanding how our users run their networks. For a vendor, making networks run efficiently should be about understanding a customer’s business and the workflows they use to run their networks. Sometimes it means getting legacy details out of the way for better network operations: an efficient command line – for example transactional configuration models have long been a hallmark of Junos. But to add real value, you have to integrate with your customer’s business by being a programmable resource. Junos has delivered intelligent network APIs at multiple levels for years. From our XML API that led to an industry-wide NETCONF standard, to advanced SDK tools now available in our network OS.

 

Programmable Networking is the new frontier. It means providing best-in-class performance at the data plane, but also best-in-class intelligence, programmability and workflow integration in the control plane. Most importantly, this new level of network intelligence means becoming a part of the dynamic resource provisioning chain – and adding crucial value in the process. This means integrating with business workflows, and not running the network as a mysterious set of pipes hidden deep underground.

 

Conclusion

Networks aren’t valuable because they forward packets reliably and quickly, they’re a critical infrastructure for communications.  The more networking vendors can do to deliver dynamic, real-time infrastructure to enable end-to-end communications, the more value we can help build and grow effective network-based businesses and services.

 

In the end, Programmable Networks are good for our customers, our industry, and (we think) for us. Nicira’s solution demonstrates that as an industry we should be adding value with the network, by becoming more dynamic and integrated with the overarching service that pays for the pipes – that said this abstraction is not a license to gloss over the details of packet delivery. As this marketplace evolves, it’s important to make sure that we close the information gap between the orchestrated services and the detailed knowledge and experience of guaranteed connectivity delivery. Like Nicira, we at Juniper believe that increased intelligence in the network coupled with the exchange of information between applications and the underlying infrastructure is the right way forward.

Comments
by Ryan James on ‎02-07-2012 09:24 AM

I think you are completely missing Nicira's view of the world. You are naively trying to relate Juniper to Nicira's view of the world.  They claim to require no support from the underlying switching and networking fabric while supporting network virtualization.  (aka they dream to commodotize Juniper's business)  Whereas, you would want your boxes to be there with high margins, albeit with programmability to support network virtualization.  That's not what Nicira is advocating.  

 

What do you say about their positioning wrt Juniper?

 

Networking Start-Up Nicira Wants to Mess Up Cisco and Juniper’s Business

http://allthingsd.com/20120205/networking-startup-nicira-wants-to-mess-up-cisco-and-junipers-busines...

 

 

by Jason Edelman on ‎02-07-2012 10:51 AM

The bottom line is Juniper agrees with Nicira on network programmability and flexibilty, but also sees your point as well.

 

Note this paragraph from above:

"This network abstraction layer is designed to make the virtualized network operate over any type of underlying physical infrastructure, and is a splendid first-step in adding networking to the pantheon of virtualized resources. But with great flexibility comes a lot of stretching. In this case, it means overlooking one of the primary values of network architectures today: the detailed understanding, and efficient use of the underlying network topology. As long as applications demand consistent throughput, and timely delivery of packets (read: bandwidth and latency guarantees), you can’t over-simplify the transport through virtualization. "


While eating into margins may be unstoppable for some, there is also opportunity for these large vendors like Juniper to differentiate themselves by integrating other parts of the network into the virtual world, so that way the virtual world is aware of the physical world and vice versa.  

 

For the same reason, you don't want 2 x VMs on 1 x physical server, you may not want 2 x network flows riding on the same physical hardware/path.  Would this not be valueable for any network deployment?  Today, you can't do this with Nicira alone, but if Juniper and Cisco opens up their hardware, it may be possible, right?

 

I don't work for Juniper or any vendor - just stating how I interpreted this article as well.  

 

Regards,

 

Jason Edelman

T: @jedelman8

B: jedelman.com

 

 

by on ‎02-07-2012 04:19 PM

@Ryan James

 

In the end, you’re making an argument of commoditization.  Your reasoning supposes that if the underlying network transport is good enough, there is no need for “high-margin” hardware underneath the virtual network solution.  But beware: the argument of commodity cuts both ways (it can go upstream as well). If Nicira is only tunneling communications, then it too is just another layer that could be commoditized.   (note: I’m making a devil’s advocate point here – don’t stop reading yet). 

 

My point in the original blog entry is that there is actually value on both sides of the abstraction layer – as long as it’s not opaque.  The virtual network controller adds value by shielding the orchestration layer from the gory details of networking (true), but its own differentiation from competing virtual network overlays is its better understanding and optimization of how it tunnels communications between endpoints.  Remember:  VMware and Cisco are in the other corner advocating VXLAN, which floods all traffic through IP multicast groups and relies on data-plane MAC learning just like “commodity” L2 switches.  Intelligent network virtualization’s real value is that it’s smarter and more efficient, not just abstract.

 

The inherent driver for this level of abstraction comes from the virtual layer’s ability to shield the layer above from complexity, while still adding value through understanding and leveraging the infrastructure below. But without visibility of the topology below and an understanding of how to take advantage of it, the virtual network is just another set of tunnels.

 

Juniper has built its business on two critical factors:  improving the price/performance ratio of the underlying infrastructure, and increasing value by delivering more intelligent and dynamic services.  Lowering costs is great – but  doing so without adding value doesn’t move the industry forward – it just makes ‘good enough’ cheaper.  

 

The networking industry has long been criticized for not having enough innovation.  Innovation comes through making the system smarter – capable of making more optimized intelligent decisions (based on data from above and below), not cost-cutting.  This translucence between the network topology and the abstraction layer is the inherent innovation here – and where the value is derived.  If you accept that network virtualization is just about cutting costs and not adding value, then commoditization is not only where the network is headed, but also the layers above.  

 

We’re excited about what companies like Nicira and others are doing -- exactly because we see the value in expanding the role of the network topology and bringing it closer to the services it’s ultimately enabling. Innovation is the tide that raises all ships.

by Atif Khan on ‎02-09-2012 11:40 PM

The driver for this level of abstraction does not just come from hiding complexity but to also scale networks. Network abstraction is nothing new. MPLS VPN and other VPN technologies are built on this concept where service is decoupled from transport. Now people are realizing that this level of abstraction is required to scale data centers also as they grow to 10s/100s of thousands of VMs and east-west traffic requirements increase. If data centers were limited to 100s of servers then plain VLAN networks would just have been good enough.

 

As far as transport being dumb pipe Vs intelligent path, what stops companies like Nicira to not be able to use something like a MPLS-TE based transport? I suppose nothing.

by on ‎02-10-2012 10:55 AM

@Atif

 

To your first point: exactly.  

 

Specifically, MPLS has proven to be scalable (and extremely successful) exactly because it logically separates two distinct problem spaces: edge services and core transport. VPNs in MPLS are effectively modular and provide a level of abstraction (just like what the virtual datacenter networks seek to deliver), and also provide detailed control of the transport to enable high-value capabilities like traffic engineering and fast-reroute.  The model works because the VPNs have some level of visibility and control of the underlying transport topology (ex: views of LSP reachability and path selection), and spare the core transport from the complexities of edge VPN service provisioning.

 

If you abstract the model logically, there is a strong opportunity to build a similar symbiosis between the virtual overlay and the underlying transport.  Allow the complexities of endpoint communications to be handled by an overlying abstraction layer, and provide an interface for visibility and control of the underlying transport.  Viewed in this light, the work in BGP-TE (topology visibility) and Path Computation Element (PCE) starts to look somewhat prescient.

by Chuck Henry on ‎03-31-2012 07:25 PM

You can do the same thing with the LISP protocol , which will eventually become standardized, as Cisco did not patent it and submitted it to IETF.  Why get locked into some proprietary approach, with yet another overlay network, to solve what is likely a transient issue caused by what are in effect design limitations in the virtualization vendors software.  The really big customers that piloted Nicera did so because they have an immediate competitive scaling issue to deal with, and I'm sure only have rolled out on a very limited basis.  The average enterprise should take a big wait and see on this, as well as any other proprietary fabrics the vendors are trying to lock them into. Qfabric comes to mind, as well as Cisco Fabricpath.

Labels
About the Author
  • Mike currently acts as Senior Director of Product Strategy and Marketing for Junos Software. In this role, he is primarily responsible for defining and operationalizing strategic efforts around Juniper's flagship operating system Junos. Mike joined the company in 2001 as an internal technical trainer, developing and delivering engineering boot camp to Juniper's newest engineers. In that role, he focused on internal hardware and software architectures as well as product training. From there, Mike moved into product manager, first as the steward for Junos software and then as the head of product management for Juniper's central software development organization. Since that time, Mike has assumed a more strategy-oriented role. Managing a time horizon 3 to 5 years, Mike is responsible for Juniper's core architectural efforts, as well as emerging technologies like OpenFlow, ALTO, and PCE (combining in Juniper's answer in the SDN space).
About /var/blog

Subscribe to /var/blog  RSS Icon

Follow Mike on Twitter

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.