Let's demonstrate elements of Juniper's strategy around network programmability by showing what we actually do. And what we do is a reflection of Scott Shenker's views on SDN . He talks about three elements:
Abstraction: make it simple
Scale: make it possible to manage the distributed state
Open: use an open protocol to manage the infrastructure
The catch? Shenker’s vision on network programmability is interpreted and deployed with varying adherence to these three elements in the real world.
Of the three elements, scalability and open protocols have received considerable attention, and I will address them in a future blog. To my surprise, abstractions have been for the most part ignored while they sit at the top of the food chain.
The abstraction layer is the foundation for great programmability. A year ago, Juniper proposed at the Open Stack Summit in San Diego a set of integrated network connectivity and services APIs. These APIs were designed to elegantly abstract the underlying complexity of network elements, configuring layers 2 and 3 and security. This week Juniper has launched these APIs, named Network Director APIs fulfilling the need for the above defined abstraction layer. Next week we will be participating in the One Stack Design Summit in Hong Kong, working with the community and sharing the benefits and experience we gained in implementing programmability. Videos are available for Network Director APIs and the architecture of the solution, along with 3 demonstrations (physical L2 and security, virtual security, L3 connectivity) showing applicability to wide range of scenarios. An overview slide is presented below, but we suggest watching the API video for complete explanation.
The key highlights are:
Service Model: The goal of abstraction is to extract simplicity from the complexity of the networking infrastructure. In this case, it means providing a set of APIs that have a meaning in the consumer problem space. In one of the many excellent articles on this subject by Tom Nolle, it is called "service model". In the same article it is identified that service model in many vendor's approaches is missing in action. This API should resemble what customer requirements and expectations are as stated in plain English, and should be decoupled from the infrastructure topology and intricacies of managing individual elements, CLIs or features.
Network Model: Then there is a "logical network model" (blue box in the slide above) that contains specification of potential attachment points and description of infrastructure's capabilities to support consumer services.
Resource Model: Finally, there is a "resource model" which deals with configuring required features to support the advertised capabilities of the network model. The resource APIs are not presented to the consumer, but are available to the administrator, along with binding between the resources and consumer services for troubleshooting or billing.
Do we need all three APIs? Without the Service API it will be difficult to reason about anything that has relevance to the consumer, and that is not good. The network model APIs, on the other hand, enables freedom to choose between any “blue box” that has capabilities to satisfy service requirements. The resource model allows using the best of breed components to build end to end "blue box" solutions.
The main concern I most commonly hear about resource abstractions is that they drive development to the "lowest common denominator" which often plagues device abstraction approaches. This problem can be solved and will be addressed in subsequent blogs.
The Juniper approach can also be easily mapped to evolving NFV and SDN architectures. The underlying data-centric architecture enables developers to be agile and create concrete things fast. And doing things fast is the goal.