SDN and NFV Era
Showing results for 
Search instead for 
Do you mean 

Introduction to the E2 Controller

by Juniper Employee ‎06-28-2017 08:19 AM - edited ‎07-05-2017 12:35 PM

Abstraction was initially about using centralized controllers as API brokers. Controllers basically were responsible for translating policy constructs into vendor-specific configuration. As that control model has evolved, it has led to the rise of intent-based networking.  Intent-based control is the only means by which operators will be able to thrive in an era that is simultaneously more demanding on its services and requires that operations be both cost-efficient and fast. But intent models will be hyper-contextual, meaning they need to developed not just for use cases but also specific deployments. Juniper has built out an intent-based framework that allows for these models to be developed and used, in combination with real-time data being streamed from the infrastructure.


Hope SPRINGs Eternal

by Juniper Employee on ‎06-20-2017 04:41 AM

There is great interest in the promise of an SDN enabled network. Source Packet Routing in Networks (SPRING) is an SDN enabled method of routing where a centralized controller maintains the network resources and can steer traffic based on the application’s need.


As applications evolve to take advantage of the traffic engineering capability of SPRING, they will need to operate a mixed SPRING and RSVP-TE network. SPRING and RSVP-TE traffic routes independently, but they may share common links.


Are Service Meshes the Next-gen SDN?

by Moderator Moderator ‎06-19-2017 10:32 PM - edited ‎06-28-2017 08:20 AM

Whether you’re adopting a containers- or functions-as-a-Service stack, or both, in the new world of micro-services architectures, one thing that has grown in importance is the network... <cut>


The idea and implementation of a service mesh is fairly new. The topic is also garnering a lot of attention because they handle the main networking challenges listed above (esp #1 & 2), and much more in the case of new projects like the CNCF Linkerd and newly launched project Istio.


Since I’ve written about SDN for container stacks before, namely OpenContrail for Kubernetes and OpenShift, I’m not going to cover it super deeply. Nor am I going to cover service meshes in general detail except to make comparisons. I will also put some references below and throughout. And I’ve tried to organize my blog by compartmentalizing the comparisons, so you can skip technical bits that you might not care for, and dive into the ones that matter most to you.


So on to the fun! Let’s look at some of the use cases and features of services meshes and compare them to SDN solutions, mostly OpenContrail, so we can answer the question posed in the title. Are service meshes the “Next-Generation” of SDN?logos service mesh.png





Juniper demonstrates a complete end-to-end NFV solution in NIA Interop Testing

by Juniper Employee ‎06-02-2017 08:09 AM - edited ‎06-08-2017 12:21 AM

Another phase of NFV interop testing was announced by The New IP Agency (NIA) this past March, and as with previous phases run by EANTC, Juniper took up the challenge and participated in a big way! 

By the time the dust had settled, Juniper was able to demonstrate interoperability of all of its participating platforms, and was the only vendor to successfully participate in all three categories tested in this phase.




SD-WAN: The Next Disruption of Virtualization


Come hear more about this topic at the Telecom Council on June 1st.


Serverless Can Smarten Up Your DevOps & Infrastructure Stack

by Moderator Moderator ‎05-25-2017 10:20 AM - edited ‎05-25-2017 10:48 AM

serverless-code-2170396_1920.jpgAs IT organizations and cultures reshape themselves for speed, we’ve seen a trend away from IT as a service provider, to IT as:

  • a collection of smaller micro-service provider teams,
  • each operating and measuring like autonomous (micro-)product teams,
  • each building and running technology systems as micro-services.

Now you’ve heard me cover the intersection of microservices and containers quite a bit, along with CaaS/Kubernetes or PaaS/OpenShift orchestration. In this blog, I’m going to change it up a bit and talk about the other kind of microservices building block: code functions.


Here I’m talking about microservices run atop of a serverless computing a.k.a. function-as-a-service (FaaS) stack. Serverless is a 2-years-new yet already well-covered topic. If you need a primer this one is the best I’ve found.


In my last blog, I examined avoiding cloud lock-in by bringing your own devops and software-defined infrastructure stack: bringing your own open-source/standard toolchain across public/private IaaS, you maintain portability and harmonized, if not unified, hybrid cloud policy. This software-defined infrastructure stack, underpinning the user- or business-facing applications, is also still just a bunch of software applications. FaaS is just one example of an increasingly popular app-developer technology that can be employed by infrastructure developers too, though this one hasn’t gotten much attention yet in that regard.


If you read the primer above, you won’t have learned that the popularity of FaaS systems like Lambda to reduce developer friction has led to a number of open source projects like OpenWhisk, and others that to sit atop of a CaaS/PaaS (such as Fission or Kubeless). If a FaaS is likely to exist in the application stack, it may well make sense to standardize on incorporating one into devops and infrastructure stack. Let’s see.


Extending AppFormix Cloud-Native Monitoring to vSphere

by Juniper Employee ‎05-15-2017 08:00 AM - edited ‎05-15-2017 10:43 AM

AppFormix already supports a diversity of cloud technologies and composable infrastructure environments. Public clouds like AWS, Google, and Azure are supported, and private cloud environments like OpenStack and Kubernetes are on the list as well.


Today, we add a major player to the list of private cloud environments: VMware vSphere.


How to Avoid the Cloud Trap

by Moderator Moderator on ‎05-11-2017 06:36 PM


ball and chain.pngWhen speed = haste, we blind ourselves to potential pitfalls. One area today of much haste in many enterprise IT organizations is, you guessed it, the move to the cloud. 


Intent-Driven Cloud

by Juniper Employee on ‎05-08-2017 06:00 AM

Carriers and enterprises know that success today is largely dependent upon giving customers and business units infrastructure choices that allow them to continuously move faster, all the time. New and improved applications and network services must be developed, packaged, and deployed across different environments—public, private, proprietary, open. To get there, they need a reliable and scalable infrastructure with security that is consistent across all environments, reducing complexity and risk while supporting growth opportunities.


Making this a reality requires giving developers a new set of abstractions that allow them to specify the infrastructure performance requirements that these services will demand in order for them to deliver the business value that customers expect. At the same time, operators of the infrastructure need to automate the monitoring and remedial actions necessary to keep those applications performing as expected.


This, in a nutshell, is what Intent-Driven Cloud is all about.


Last year, we talked about how Juniper Networks Contrail Networking caters to a wide variety of customer use-cases (SaaS & IaaS / BMaaS Clouds, Enterprise private cloud / ITaaS Cloud, SD-WAN, telco, IoT and cable clouds) and how Contrail provides cloud networking solutions for some of the largest customers in the world. Over the year, we have tirelessly worked to enhance the product capabilities, gain even more market leadership, but most importantly, win more customers and cater to more customer use-cases, while at the same time ensuring our unwavering commitment to open source.


Juniper Networks Technical Books