- The Beginning: A New Set of Requirements
- Network Management Is Dead, Long Live Network Management
- YANG: The Data Modeling Language
- The Key to Automation? Data Models
- The Management Architecture
- Data Model-Driven Management Components
- The Encoding (Protocol Binding and Serialization)
- The Server Architecture: Datastore
- The Protocols
- The Programming Language
- Telemetry
- The Bigger Picture: Using NETCONF to Manage a Network
- Interview with the Experts
- Summary
- References in This Chapter
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Management Architecture
From an architecture point of view, there are multiple API locations, all deduced from YANG modules. A controller typically configures network elements (routers and switches in the networking world) based on the network element YANG modules—typically network interfaces, routing, quality of service, and so on—as shown in Figure 2-3.
)
Figure 2.3 The Management Architecture
Controllers focus on one specific network domain or a specific technology. On top of the controllers, the orchestrator configures one or more controllers based on the network YANG modules’ APIs. With the architecture in Figure 2-3 in mind, let’s introduce the notion of northbound and southbound interfaces. From a controller point of view (as an example), the northbound interface is the interface toward the orchestrator, whereas the southbound interface is the one toward the server. Operators can also automate the orchestrator northbound interface to create/modify/delete their services, based on the service delivery YANG modules. A service YANG model is the management interface toward a software application, whereas a device YANG model is generally attached to a physical or virtual device. The classical service example is a Layer 3 virtual private network, or L3VPN, which touches the configuration on multiple devices in the network, configuring network element YANG modules on each point. Then this service is decomposed in the controller, where the required servers are configured.
Note that separating the controller and orchestrator in two different systems is not a requirement: An orchestrator might also handle the tasks of the controller system or connect directly to network elements without any controller function. Examples of systems that can take on various roles in this space are OpenDaylight,11 Network Services Orchestrator (NSO), Contrail, and CloudOpera.
Coming back to the different types of YANG modules, having network element YANG modules standardized for the industry offers some easier automation in case of cross-vendor development. The service delivery YANG modules, on the other hand, are mainly proprietary, as operators tend to differentiate themselves from the competition. There are two notable exceptions with the standardization of the L3VPN service delivery (RFC 8299) and L2VPN service delivery (soon an RFC). More details on the different YANG module types can be found in “YANG Module Classification” (RFC 8199) and “Service Modules Explained” (RFC 8309).
There is a need for standard mechanisms to allow system owners to control read, write, and execute access for particular parts of the YANG tree to different kinds of users. The Network configuration Access Control Model (NACM; RFC 8341) specifies the access control mechanisms for the operations and content layers of NETCONF and RESTCONF, thanks to the ietf-netconf-acm YANG module. This is the role-based access control (RBAC) mechanism most commonly used in the YANG model–driven world.