Internet Engineering Task Force (IETF) Q. Wu Request for Comments: 8309 W. Liu Category: Informational Huawei Technologies ISSN: 2070-1721 A. Farrel Juniper Networks January 2018 Service Models Explained
AbstractThe IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049). This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8309.
Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 4 3. Using Service Models . . . . . . . . . . . . . . . . . . . . 7 3.1. Practical Considerations . . . . . . . . . . . . . . . . 8 4. Service Models in an SDN Context . . . . . . . . . . . . . . 8 5. Possible Causes of Confusion . . . . . . . . . . . . . . . . 11 6. Comparison with Other Work . . . . . . . . . . . . . . . . . 13 6.1. Comparison with Network Service Models . . . . . . . . . 13 6.2. Service Delivery and Network Element Model Work . . . . . 15 6.3. Customer Service Model Work . . . . . . . . . . . . . . . 16 6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 17 7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 18 7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 18 7.3. Operator-Specific Features . . . . . . . . . . . . . . . 19 7.4. Supporting Multiple Services . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Manageability Considerations . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 21 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
RFC6020] for configuration and monitoring has blossomed. Many of these are used for device-level configuration (for example, [RFC7223]) or for control of monolithic functions or protocol instances (for example, [RFC7407]). [RFC7950] makes a distinction between a "data model", which it defines as describing how data is represented and accessed, and a "YANG module", which defines hierarchies of schema nodes to make a self-contained and compilable block of definitions and inclusions. YANG structures data models into modules for ease of use. Within the context of Software-Defined Networking (SDN) [RFC7149] [RFC7426], YANG data modules may be used on the interface between a controller and network devices, as well as between network orchestrators and controllers. There may also be a hierarchy of such components with super controllers, domain controllers, and device controllers all exchanging information and instructions using YANG modules. There has been interest in using YANG to define and document data models that describe services in a portable way that is independent of which network operator uses the model, for example, the Layer 3 Virtual Private Network Service Model (L3SM) [RFC8049]. Such models may be used in manual and even paper-driven service request processes with a gradual transition to IT-based mechanisms. Ultimately, they could be used in online, software-driven dynamic systems and may be used as part of an SDN system. This document explains the scope and purpose of service models within the IETF (and is limited to within the scope of the IETF) and describes how a service model can be used by a network operator. Equally, this document clarifies what a service model is not and dispels some common misconceptions. The document also shows where a service model might fit into an SDN architecture, but it is important to note that a service model does not require or preclude the use of SDN. Note that service models do not make any assumption of how a service is actually engineered and delivered to a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider.
In summary, a service model is a formal representation of the data elements that describe a network service as that service is described to or requested by a customer of a network operator. Details included in the service model include a description of the service as experienced by the customer, but not features of how that service is delivered or realized by the service provider. Other work on classifying YANG modules has been done in [RFC8199]. That document provides an important reference for this document and also uses the term "service module". In this document, Section 6.1 provides a comparison between these two uses of the same terminology. RFC8199]. The following terms are used in this document: Network Operator: This term is used to refer to the company that owns and operates one or more networks that provide Internet connectivity services and/or other services. Customer: This term refers to someone who purchases a service (including connectivity) from a network operator. In the context of this document, a customer is usually a company that runs their own network or computing platforms and wishes to connect to the Internet or between sites. Such a customer may operate an enterprise network or a data center. Sometimes this term may also be used to refer to the individual in such a company who contracts to buy services from a network operator. A customer as described here is a separate commercial operation from the network operator, but some companies may operate with internal customers so that, for example, an IP/MPLS packet network may be the customer of an optical transport network.
Service: A network operator delivers one or more services to a customer. A service in the context of this document (sometimes called a Network Service) is some form of connectivity between customer sites and the Internet or between customer sites across the network operator's network and across the Internet. However, a distinction should be drawn between the parameters that describe a service as included in a customer service model (see the definition of this term, below) and a Service Level Agreement (SLA), as discussed in Sections 5 and 7.2. A service may be limited to simple connectivity (such as IP-based Internet access), may be a tunnel (such as a virtual circuit), or may involve more complex connectivity (such as in a multisite virtual private network). Services may be further enhanced by additional functions providing security, load balancing, accounting, and so forth. Additionally, services usually include guarantees of quality, throughput, and fault reporting. This document makes a distinction between a service as delivered to a customer (that is, the service as discussed on the interface between a customer and the network operator) and the service as realized within the network (as described in [RFC8199]). This distinction is discussed further in Section 6. Readers may also refer to [RFC7297] for an example of how an IP connectivity service may be characterized. Data Model: The information model (IM) and data model (DM) concepts are described in [RFC3444]. That document defines a data model by contrasting it with the definition of an IM as follows: The main purpose of an IM is to model managed objects at a conceptual level, independent of any specific implementations or protocols used to transport the data. The degree of specificity (or detail) of the abstractions defined in the IM depends on the modeling needs of its designers. In order to make the overall design as clear as possible, an IM should hide all protocol and implementation details. Another important characteristic of an IM is that it defines relationships between managed objects. DMs, conversely, are defined at a lower level of abstraction and include many details. They are intended for implementors and include protocol-specific constructs. As mentioned in Section 1, this document also uses the terms "data model" and "YANG module" as defined in [RFC7950].
Service Model: A service model is a specific type of data model. It describes a service and the parameters of the service in a portable way that can be used uniformly and independent of the equipment and operating environment. The service model may be divided into the two following categories: Customer Service Model: A customer service model is used to describe a service as offered or delivered to a customer by a network operator as shown in Figure 1. It can be used by a human (via a user interface such as a GUI, web form, or Command-Line Interface (CLI)) or by software to configure or request a service and may equally be consumed by a human (such as via an order fulfillment system) or by a software component. Such models are sometimes referred to simply as "service models" [RFC8049]. A customer service model is expressed in a YANG module as a core set of parameters that are common across network operators: additional features that are specific to the offerings of individual network operators would be defined in extensions or augmentations of the module. Except where specific technology details are directly pertinent to the customer (such as encapsulations or mechanisms applied on access links), customer service models are technology agnostic so that the customer does not have influence over or knowledge of how the network operator engineers the service. An example of where such details are relevant to the customer is when they describe the behavior or interactions on the interface between the equipment at the customer site (often referred to as the Customer Edge or CE equipment) and the equipment at the network operator's site (usually referred to as the Provider Edge or PE equipment). Service Delivery Model: A service delivery model is used by a network operator to define and manage how a service is engineered in the network. It can be used by a human operator (such as via a management station) or by a software tool to instruct network components. The YANG modules that encode such models are sometimes referred to as "network service YANG modules" [RFC8199] and are consumed by "external systems" such as an Operations Support System (OSS). A service delivery module is expressed as a core set of parameters that are common across a network type and technology: additional features that are specific to the configuration of individual vendor equipment or proprietary protocols would be defined in extensions or augmentations of the module. Service delivery modules include technology-specific modules.
The distinction between a customer service model and a service delivery model needs to be clarified. The modules that encode a customer service model are not used to directly configure network devices, protocols, or functions: it is not something that is sent to network devices (i.e., routers or switches) for processing. Equally, the modules that encode a customer service model do not describe how a network operator realizes and delivers the service described by the module. This distinction is discussed further in later sections. Figure 1. The language in which a customer service model is described is a choice for whoever specifies the model. The IETF uses the YANG data modeling language defined in [RFC6020]. The encoding and communication protocol used to exchange a customer service model between the customer and network operator is specific to deployment and implementation. The IETF has standardized the NETCONF protocol [RFC6241] and the RESTCONF protocol [RFC8040] for interactions "on the wire" between software components with data encoded in XML or JSON. However, co-located software components might use an internal API, while systems with more direct human interactions might use web pages or even paper forms. Where direct human interaction comes into play, interface interactions may be realized via business practices that may introduce some margin of error, thus raising the priority for automated, deterministic interfaces. -------------- Customer ---------------------- | | Service Model | | | Customer | <-----------------> | Network Operator | | | | | -------------- ---------------------- Figure 1: The Customer Service Models Used on the Interface between Customers and Network Operators How a network operator processes a customer's service request when described with a customer service model depends on the commercial and operational tools, processes, and policies used by the network operator. These may vary considerably from one network operator to another.
However, the intent is that the network operator maps the service request into configuration and operational parameters that control one or more networks to deliver the requested services. That means that the network operator (or software run by the network operator) takes the information in the customer service model and determines how to deliver the service by enabling and configuring network protocols and devices. They may achieve this by constructing service delivery models and passing them to network orchestrators or controllers. The use of standard customer service models eases service delivery by means of automation. RFC8049] results from the consensus of multiple individuals working at network operators and offers a common core of service options that can be augmented according to the needs of individual network operators. It has also been suggested that there should be a single, base customer service module, and that details of individual services should be offered as extensions or augmentations of this. It is quite possible that a number of service parameters (such as the identity and postal address of a customer) will be common, and it would be a mistake to define them multiple times (once in each customer service model). However, the distinction between a 'module' and a 'model' should be considered at this point: modules are how the data for models is logically broken out and documented, especially for reuse in multiple models. Figure 2 shows a sample architectural view of an SDN system where network elements are programmed by a component called an "SDN controller" (or "controller" for short) and where controllers are instructed by an orchestrator that has a wider view of the whole of, or part of, a network. The internal organization of an SDN control plane is specific to deployment.
------------------ | | | Orchestrator | | | .------------------. . : . . : . ------------ ------------ ------------ | | | | | | | Controller | | Controller | | Controller | | | | | | | ------------ ------------ ------------ : . . : : . . : : . . : --------- --------- --------- --------- | Network | | Network | | Network | | Network | | Element | | Element | | Element | | Element | --------- --------- --------- --------- Figure 2: A Sample SDN Architecture A customer's service request is (or should be) technology agnostic. That is, a customer is unaware of the technology that the network operator has available to deliver the service, so the customer does not make requests specific to the underlying technology but is limited to making requests specific to the service that is to be delivered. The orchestrator must map the service request to its view, and this mapping may include a choice of which networks and technologies to use depending on which service features have been requested. One implementation option to achieve this mapping is to split the orchestration function between a "Service Orchestrator" and a "Network Orchestrator" as shown in Figure 3.
Customer ------------------ Service ---------- | | Model | | | Service |<-------->| Customer | | Orchestrator | (a) | | | | ---------- ------------------ . . . . (b) ----------- . (b) . ......|Application| . . : | BSS/OSS | . . : ----------- . Service Delivery . : . Model . : ------------------ ------------------ | | | | | Network | | Network | | Orchestrator | | Orchestrator | | | | | .------------------ ------------------. . : : . . : Network Configuration : . . : Model : . ------------ ------------ ------------ ------------ | | | | | | | | | Controller | | Controller | | Controller | | Controller | | | | | | | | | ------------ ------------ ------------ ------------ : . . : : : . . Device : : : . . Configuration : : : . . Model : : --------- --------- --------- --------- --------- | Network | | Network | | Network | | Network | | Network | | Element | | Element | | Element | | Element | | Element | --------- --------- --------- --------- --------- Figure 3: An Example SDN Architecture with a Service Orchestrator Figure 3 also shows where different data models might be applied within the architecture. The device configuration models are used by a controller to set parameters on an individual network element. The network configuration models are used by a network orchestrator to instruct controllers (which may each be responsible for multiple network elements) how to configure parts of a network.
The following examples illustrate the split between control components that expose a "service interface" that is present in many figures that show extended SDN architectures: o Figure 1 of [RFC7426] shows a separation of the "Application Plane", the "Network Services Abstraction Layer (NSAL)", and the "Control Plane". It marks the "Service Interface" as situated between the NSAL and the control plane. o Figure 1 of [RFC7491] shows an interface between an "Application Service Coordinator" and an "Application-Based Network Operations Controller". o Figure 1 of [RFC8199] shows an interface from an OSS or a Business Support System (BSS) that is expressed in "Network Service YANG Modules". This can all lead to some confusion around the definition of a "service interface" and a "service model". Some previous literature considers the interface northbound of the network orchestrator (labeled "(b)" in Figure 3) to be a "service interface" used by an application, but the service described at this interface is network centric and is aware of many features, such as topology, technology, and operator policy. Thus, we make a distinction between this type of service interface and the more abstract service interface (labeled "(a)" in Figure 3) where the service is described by a service model and the interaction is between the customer and network operator. Further discussion of this point is provided in Section 5.
o Network operation is normally out of scope in the discussion of services between a network operator and a customer. That means that the customer service model does not reveal to the customer anything about how the network operator delivers the service, nor does the model expose details of technology or network resources used to provide the service (all of these details could, in any case, be considered security vulnerabilities). For example, in the simple case of point-to-point virtual link connectivity provided by a network tunnel (such as an MPLS pseudowire), the network operator does not expose the path through the network that the tunnel follows. Of course, this does not preclude the network operator from taking guidance from the customer (such as to avoid routing traffic through a particular country) or from disclosing specific details (such as might be revealed by a route trace), but these are not standard features of the service as described in the customer service model. o The network operator may use further data models (service delivery models) that help to describe how the service is realized in the network. These models might be used on the interface between the service orchestrator and the network orchestrator, as shown in Figure 3, and might include many of the pieces of information from the customer service model alongside protocol parameters and device configuration information. [RFC8199] also terms these data models as "service models" and encodes them as "Network Service YANG Modules"; a comparison is provided in Section 6.1. It is important that the service orchestrator be able to map from a customer service model to these service delivery models, but they are not the same thing. o Commercial terms (such as "cost per byte", "cost per minute", and "scoped by quality and type of service", as well as terms related to payment) are generally not a good subject for standardization. It is possible that some network operators will enhance standard customer service models to include commercial information, but the way this is done is likely to vary widely between network operators. Thus, this feature is out of scope for standardized customer service models. o SLAs have a high degree of overlap with the definition of services present in customer service models. Requests for specific bandwidth, for example, might be present in a customer service model, and agreement to deliver a service is a commitment to the description of the service in the customer service model. However, SLAs typically include a number of fine-grained details about how services are allowed to vary, by how much, and how often. SLAs are also linked to commercial terms with penalties and so forth and thus are also not good topics for
standardization. As with commercial terms, it is expected that some network operators will enhance standard customer service models to include SLA parameters either using their own work or depending on material from standards bodies that specialize in this topic, but this feature is out of scope for the IETF's customer service models. If a network operator chooses to express an SLA using a data model, that model might be referenced as an extension or an augmentation of the customer service model. RFC8199] provides a classification of YANG modules. It introduces the term "Network Service YANG Module" to identify the type of module used to "describe the configuration, state data, operations, and notifications of abstract representations of services implemented on one or multiple network elements." These modules are used to construct the service delivery models as described in this document; that is, they are the modules used on the interface between the service orchestrator or OSS/BSS and the network orchestrator, as shown in Figure 3. Figure 1 of [RFC8199] can be modified to make this more clear and to include an additional example of a Network Service YANG module, as shown in Figure 4. As can be seen, the highest classification of modules collects those that are used to deliver operations support and business support. These might be consumed by an Operations Support System (OSS) or a Business Support System (BSS), and a service orchestrator may form part of an OSS/BSS or may be a separate component. This highest layer in the figure is divided into the customer service modules that are used to describe services to a customer as discussed in this document, and other modules that describe further OSS/BSS functions such as billing and SLAs.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Operations Support and Business Support YANG Modules +-----------------------+ +-----------------------+ | | | | | Customer Service | | Other | | YANG Modules | | Operations Support | | | | and | | +------+ +------+ | | Business Support | | | | | | | | YANG Modules | | | L2SM | | L3SM | | | | | | | | | | | | | +------+ +------+ | | | | | | | +-----------------------+ +-----------------------+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Network Service YANG Modules +------------+ +-------------+ +-------------+ +-------------+ | | | | | | | | | - L2VPN | | - L2VPN | | EVPN | | L3VPN | | - VPWS | | - VPLS | | | | | | | | | | | | | +------------+ +-------------+ +-------------+ +-------------+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Network Element YANG Modules +------------+ +------------+ +-------------+ +------------+ | | | | | | | | | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | | | | | | | | | +------------+ +------------+ +-------------+ +------------+ Key: EVPN: Ethernet Virtual Private Network L2SM: Layer 2 Virtual Private Network Service Model L2VPN: Layer 2 Virtual Private Network L3SM: Layer 3 Virtual Private Network Service Model L3VPN: Layer 3 Virtual Private Network VPLS: Virtual Private LAN Service VPWS: Virtual Private Wire Service Figure 4: YANG Module Abstraction Layers Showing Customer Service Modules
BGP-L3VPN-YANG] defines a YANG module that can be used to configure and manage BGP L3VPNs. o [L2VPN-YANG] documents a data model that is expected to be used by the management tools run by the network operators in order to manage and monitor the network resources that they use to deliver L2VPN services. o [EVPN-YANG] defines YANG modules for delivering an Ethernet VPN service.
Figure 5, which is reproduced from [RFC8049], shows that the L3SM is a customer service model as described in this document. L3VPN-SVC | MODEL | | +------------------+ +-----+ | Orchestration | < --- > | OSS | +------------------+ +-----+ | | +----------------+ | | Config manager | | +----------------+ | | | | Netconf/CLI ... | | +------------------------------------------------+ Network Figure 5: The L3SM Service Architecture A Layer 2 VPN Service Model (L2SM) is defined in [L2VPN-SERVICE]. That model's usage is described as in Figure 6, which is a reproduction of Figure 5 from that document. As can be seen, the L2SM is a customer service model as described in this document.
---------------------------- | Customer Service Requester | ---------------------------- | L2VPN | Service | Model | | ----------------------- | Service Orchestration | ----------------------- | | Service +-------------+ | Delivery +------>| Application | | Model | | BSS/OSS | | V +-------------+ ----------------------- | Network Orchestration | ----------------------- | | +----------------+ | | Config manager | | +----------------+ | Device | | Models | | -------------------------------------------- Network Figure 6: The L2SM Service Architecture Figure 2 of [MEF-55]. The work of the MEF embraces all aspects of Lifecycle Service Orchestration, including billing, SLAs, order management, and lifecycle management. The IETF's work on service models is typically smaller and offers a simple, self-contained service YANG module. This does not invalidate either approach: it only observes that they are different approaches.
Section 5, it is expected that some network operators will enhance standard customer service models to include policy parameters either using their own
work or depending on specific policy models built in the IETF or other standards bodies. Nevertheless, policy is so important that all service models should be designed to be easily extensible to allow policy components to be added and associated with services as needed.
Figure 3, need to be correctly secured. This document discusses modeling the information, not how it is exchanged.
The operational state of a service does not form part of a customer service model. However, it is likely that a network operator may want to report some state information about various components of the service and that could be achieved through extensions to the core service model, just as SLA extensions could be made as described in Section 5. [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>. [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module Classification", RFC 8199, DOI 10.17487/RFC8199, July 2017, <https://www.rfc-editor.org/info/rfc8199>. [BGP-L3VPN-YANG] Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model for BGP/MPLS L3 VPNs", Work in Progress, draft-dhjain- bess-bgp-l3vpn-yang-02, August 2016. [EVPN-YANG] Brissette, P., Sajassi, A., Shah, H., Li, Z., Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data Model for EVPN", Work in Progress, draft-ietf-bess-evpn- yang-03, October 2017. [L2VPN-SERVICE] Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data Model for L2VPN Service Delivery", Work in Progress, draft-ietf-l2sm-l2vpn-service-model-04, October 2017. [L2VPN-YANG] Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., and K. Tiruveedhula, "YANG Data Model for MPLS-based L2VPN", Work in Progress, draft-ietf-bess-l2vpn-yang-07, October 2017.
[MEF-55] MEF Forum, "Lifecycle Service Orchestration (LSO): Reference Architecture and Framework", Service Operations Specification MEF 55, March 2016. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>. [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>. [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, <https://www.rfc-editor.org/info/rfc7223>. [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-editor.org/info/rfc7297>. [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, December 2014, <https://www.rfc-editor.org/info/rfc7407>. [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>. [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for Application-Based Network Operations", RFC 7491, DOI 10.17487/RFC7491, March 2015, <https://www.rfc-editor.org/info/rfc7491>. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>. [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/RFC8049, February 2017, <https://www.rfc-editor.org/info/rfc8049>. RFC8199]. Many thanks to Jerry Bonner for spotting a tiny but critical, one-word typo.