The Layer Three VPN Service Model (L3SM) Working Group has succeeded in its goal of describing an Internet service as a data model by documenting it in the YANG modelling language.
Driven by the huge interest in Software-Defined Networking (SDN), the use of YANG-based data models is now very popular in open-source projects, throughout the IETF, and in many other standards bodies and forums. A recent count showed more than 200 active Internet-Drafts and Request for Comments documents (RFCs) describing YANG data models. However, the focus of that work has been “southbound” of the network controller to configure and monitor network devices and protocols.
The purpose of a service model is to formalize the description of a service on the interface between a network operator and that operator’s customers. In this context, an operator may use the data model to describe and discuss services that the operator can supply, and the customer may request a service using the data model transmitted either on paper or via an Information Technology (IT) system. Increasingly, with the growth in SDN projects and products, consideration is given to automating service request and delivery via dynamic software systems.
Ultimately, the intent is that a network operator will convert a customer’s request into configurational and operational parameters that control network resources to deliver the service. In an SDN system, the control and configuration of network resources and protocols are under the control of software systems that determine how best to utilize the network. Figure 1 shows a simplified view of a common representation of the SDN architecture: the network orchestrator plans how the network should be used and communicates with the network controllers that configure and program the network devices.
The service model applies a level of abstraction so that it contains only the questions operators would ask their customers in order to activate the service (versus including all possible configuration knobs for the devices). That is, because a service request is network agnostic, it must be mapped onto the network orchestrator’s view of the network. This can be achieved by introducing a service orchestrator, as shown in Figure 2. The service orchestrator receives service requests from the customer and maps them to the correct network orchestrator of the operator’s network (or networks) that was chosen to deliver the service.
The L3SM Working Group took a different approach to working from the usual way. First, the work was driven entirely by network operators, not equipment vendors. Participation in the IETF by operators is a precious resource that can focus our work on real problems that need to be solved. Because network operators are the consumers of the data model, it was essential to both involve them and have them control the work. In addition, it has been a challenge for operators to agree on a common set of parameters to describe the L3VPN service that they each offer in their own unique way. Achieving this agreement was one of the ways the Working Group measured its success.
L3SM also is unusual in that it was created by Area Director Benoit Claise without holding a Birds-of-a-Feather (BoF) meeting. Instead, as soon as the team of operators had written a relatively early, but stable version of the data model and posted it as an Internet-Draft, Benoit chartered the Working Group. This is an example of how the IETF can be relatively quick at handling and progressing new work: the L3SM Working Group expects to last call this data model around IETF 96—14 months after the Working Group was chartered and only 15 months after the first version of the draft was posted.
The L3SM Working Group and draft can be found at https://datatracker.ietf.org/wg/l3sm.