--- 1/draft-ietf-opsawg-service-model-explained-03.txt 2017-09-27 05:15:48.168246321 -0700 +++ 2/draft-ietf-opsawg-service-model-explained-04.txt 2017-09-27 05:15:49.604280738 -0700 @@ -1,75 +1,75 @@ OPS Area Working Group Q. Wu Internet-Draft W. Liu Intended status: Informational Huawei Technologies -Expires: March 9, 2018 A. Farrel +Expires: March 31, 2018 A. Farrel Juniper Networks - September 5, 2017 + September 27, 2017 Service Models Explained - draft-ietf-opsawg-service-model-explained-03 + draft-ietf-opsawg-service-model-explained-04 Abstract - The IETF has produced many data modules in the YANG modeling - language. The majority of these modules are used to construct data - models to model devices or monolithic functions. + The 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 Three Virtual Private Network Service Model 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 models that are - not exposed through the Customer-Provider Interface. + engineered to deliver a service are captured in other modules that + are not exposed through the Customer-Provider Interface. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. + Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 9, 2018. + This Internet-Draft will expire on March 31, 2018. Copyright Notice Copyright (c) 2017 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 - (http://trustee.ietf.org/license-info) in effect on the date of + (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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 4 3. Using Service Models . . . . . . . . . . . . . . . . . . . . 6 4. Service Models in an SDN Context . . . . . . . . . . . . . . 8 5. Possible Causes of Confusion . . . . . . . . . . . . . . . . 10 6. Comparison With Other Work . . . . . . . . . . . . . . . . . 12 6.1. Comparison With Network Service Models . . . . . . . . . 12 6.2. Service Delivery and Network Element Model Work . . . . . 14 6.3. Customer Service Model Work . . . . . . . . . . . . . . . 14 6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 16 7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 17 @@ -80,72 +80,77 @@ 9. Manageability Considerations . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction - In recent years the number of data modules written in the YANG - modeling language [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]). + In recent years the number of modules written in the YANG modeling + language [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" that 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 models may be used on the interface between a + [RFC7426], YANG data modules may be used on the interface between a controller and network devices, and 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 models. + 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 Three 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 eventually as part of an SDN system. This document explains the scope and purpose of service models within 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 models that - are not exposed through the Customer-Provider Interface. + are engineered to deliver a service are captured in other modules + that are not exposed through the Customer-Provider Interface. 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 data models has been done in - [RFC8199]. That document provides an important reference for this - document, and also uses the term "service model". Section 6.1 in - this document provides a comparison between these two uses of the - same terminology. + 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". Section 6.1 in this document + provides a comparison between these two uses of the same terminology. 2. Terms and Concepts Readers should familiarize themselves with the description and - classification of YANG models provided in [RFC8199]. + classification of YANG modules provided in [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 @@ -164,21 +169,21 @@ 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 Section 5 and Section 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 be a more complex connectivity model (such as a multi-site + may involve more complex connectivity (such as in a multi-site 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. @@ -199,73 +204,77 @@ designers. In order to make the overall design as clear as possible, an information model should hide all protocol and implementation details. Another important characteristic of an information model is that it defines relationships between managed objects. Data models, 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. The service model may be divided into two 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. It can be used by a human (via a user interface such as a GUI, web form, or 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 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 model. Except where - specific technology details (such as encapsulations, or - mechanisms applied on access links) are directly pertinent to - the customer, 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. + 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 (such as + encapsulations, or mechanisms applied on access links) are + directly pertinent to the customer, 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. Such models are sometimes - referred to as "network service models" [RFC8199] and are - consumed by "external systems" such as Operations Support - System (OSS). A service delivery model 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 model. Service delivery models include technology-specific - modules. + 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 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. A customer service model is - not a data model 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, a - customer service model is not a data model that describes how a - network operator realizes and delivers the service described by the - model. This distinction is discussed further in later sections. + 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 describes how + a network operator realizes and delivers the service described by the + module. This distinction is discussed further in later sections. 3. Using Service Models As already indicated, customer service models are used on the interface between customers and network operators. This is shown simply in 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]. @@ -403,64 +412,71 @@ : . . 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. + within the architecture. The Device Confguration Models are used by + a Controller to seet parameters on an individual network element. + The Network Configuration Models are use by a Network Orchestrator to + instruct Controllers (that may each be responsible for multiple + network elements) how to configure parts of a network. The split between control components that exposes a "service - interface" is present in many figures showing extended SDN + interface" that is present in many figures showing 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 - Models". + 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 customer and network operator. Further discussion of this point is provided in Section 5. 5. Possible Causes of Confusion In discussing service models, there are several possible causes of confusion: - o The services we are discussing are services provided by network - operators to customers. This is a completely different thing to - "Foo as a Service" (for example, Infrastructure as a Service - (IaaS)) where a service provider offers a service at some location - that is reached across a network. The confusion arises not only - because of the use of the word "service", but also because network - operators may offer value-added services as well as network - connection services to their customers. + o The services we are discussing are connectivity services provided + by network operators to customers achieved by manipulating the + network resources of the operator's network. This is a completely + different thing to "Foo as a Service" (for example, Storage as a + Service (SaaS)) where a service provider offers reachability to a + value-added service that is provided at some location in the + network using other resources (compute, storage, ...) that are not + part of the network itself. The confusion arises not only because + of the use of the word "service" in both cases, but also because + network operators may offer both types of service to their + customers. o Network operation is completely 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. The model does not expose details of technology or network resources used to provide the service. 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 @@ -471,25 +487,25 @@ 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" or "Network Service YANG Models" and a - comparison is provided in Section 6.1. It is important that the - Service Orchestrator should be able to map from a customer service - model to these service delivery models, but they are not the same - things. + models as "service models" and encode them as "Network Service + YANG Modules" and a comparison is provided in Section 6.1. It is + important that the Service Orchestrator should be able to map from + a customer service model to these service delivery models, but + they are not the same things. o Commercial terms 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 Service Level Agreements (SLAs) have a high degree of overlap with the definition of services present in customer service models. @@ -506,110 +522,119 @@ 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. 6. Comparison With Other Work - Other work has classified YANG models, produced parallel - architectures, and developed a range of YANG models. This section + Other work has classified YANG modules, produced parallel + architectures, and developed a range of YANG modules. This section briefly examines that other work and shows how it fits with the description of service models introduced in this document. 6.1. Comparison With Network Service Models - As previously noted, [RFC8199] provides a classification of YANG data - models. It introduces the term "Network Service YANG Module" to - identify the type of model used to "describe the configuration, state - data, operations and notifications of abstract representations of - services implemented on one or multiple network elements." These are - service delivery models as described in this document; that is, they - are the models used on the interface between the Service Orchestrator - or OSS/BSS and the Network Orchestrator as shown in Figure 3. + As previously noted, [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 - add an additional example of a Network Service YANG model as shown in - Figure 4. This figure illustrates a functional architecture, and an - implementation might choose to make different distinctions and - separations between components so that the functional units and - interfaces illustrated might fall within a single implementation. - - +---------------+ - | | - | Customers | - | | - +---------------+ + add 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 function such as billing and SLAs. - - - - - - - - - - - - - - - - Customer Service YANG Modules + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Operations Support and Business Support YANG Modules - +-------------------------------------------------------+ - | | - | +----------------------+ | - | | | Operations and Business | - | | Service Orchestrator | Support Systems | - | | | (OSS/BSS) | - | +----------------------+ | - | | - | | - +-------------------------------------------------------+ + +-----------------------+ +-----------------------+ + | | | | + | 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 - VPWS: Virtual Private Wire Service VPLS: Virtual Private LAN Service + VPWS: Virtual Private Wire Service - Figure 4: YANG Module Layers Showing Service Models + Figure 4: YANG Module Abstaction Layers Showing Customer Service + Modules 6.2. Service Delivery and Network Element Model Work - A number of IETF working groups are developing YANG models related to - services. These models focus on how the network operator configures - the network through protocols and devices to deliver a service. Some - of these models are classified as service delivery models, while - others have details that are related to specific element - configuration and so are classed as network element models (also - called device models). + A number of IETF working groups are developing YANG modules related + to services. These models focus on how the network operator + configures the network through protocols and devices to deliver a + service. Some of these models are classified as network service + delivery models (also called service delivery models or network + configuation models depending on the level at which they are + pitched), while others have details that are related to specific + element configuration and so are classed as network element models + (also called device models). A sample set of these models is listed here: - o [I-D.dhjain-bess-bgp-l3vpn-yang] defines a YANG model that can be + o [I-D.dhjain-bess-bgp-l3vpn-yang] defines a YANG module that can be used to configure and manage BGP L3VPNs. - o [I-D.ietf-bess-l2vpn-yang] documents a YANG model that it is + o [I-D.ietf-bess-l2vpn-yang] documents a data model that it is expected will 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 [I-D.ietf-bess-evpn-yang] defines YANG models for delivering an + o [I-D.ietf-bess-evpn-yang] defines YANG modules for delivering an Ethernet VPN service. 6.3. Customer Service Model Work Several initiatives within the IETF are developing customer service models. The L3SM presents the L3VPN service as described by a network operator to a customer. Figure 5, which is reproduced from [RFC8049], shows that the L3SM is a customer service model as described in this document. @@ -775,35 +800,41 @@ service model is important, the data will be described in its own module and may form part of the service model either by inclusion or by index. 8. Security Considerations The interface between customer and service provider is a commercial interface and needs to be subject to appropriate confidentiality. Additionally, knowledge of what services are provided to a customer or delivered by a network operator may supply information that can be - used in a variety of security attacks. + used in a variety of security attacks. The service model itself will + expose security-related parameters for the specific service where the + related functon is available to the customer. Clearly, the ability to modify information exchanges between customer and network operator may result in bogus requests, unwarranted billing, and false expectations. Furthermore, in an automated system, modifications to service requests or the injection of bogus requests may lead to attacks on the network and delivery of customer traffic to the wrong place. Therefore it is important that the protocol interface used to exchange service request information between customer and network operator is subject to authorization, authentication, and encryption. + Clearly, the level of abstraction provided by a service model + protects the operator from unwarranted visibility into their network, + and the fact that it is entirely up to the operator how they deliver + the service provides additional protection. + Equally, all external interfaces, such as any of those between the functional components in Figure 3 needs to be correctly secured. - This document discusses modeling the information, not how it is exchanged. 9. Manageability Considerations This whole document discusses issues related to network management and control. It is important to observe that automated service provisioning resulting from use of a customer service model may result in rapid @@ -823,22 +854,23 @@ 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. 10. IANA Considerations This document makes no requests for IANA action. 11. Acknowledgements - Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair, and - Luis Miguel Contreras Murillo for useful review and comments. + Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair, + Luis Miguel Contreras Murillo, Joe Salowey, Benoit Claise, Robert + Sparks, and Tom Petch for useful review and comments. Thanks to Dean Bogdanovic, Tianran Zhou, and Carl Moberg for their help coordinating with [RFC8199]. Many thanks to Jerry Bonner for spotting a tiny, one-word, but critical typo. 12. References 12.1. Normative References @@ -868,21 +900,21 @@ [I-D.ietf-bess-l2vpn-yang] Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., and K. Tiruveedhula, "YANG Data Model for MPLS-based L2VPN", draft-ietf-bess-l2vpn-yang-06 (work in progress), June 2017. [I-D.ietf-l2sm-l2vpn-service-model] Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn- - service-model-02 (work in progress), July 2017. + service-model-03 (work in progress), September 2017. [MEF-55] MEF Forum, "Service Operations Specification MEF 55 : Lifecycle Service Orchestration (LSO) Reference Architecture and Framework", 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, . @@ -913,20 +945,24 @@ Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, . [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for Application-Based Network Operations", RFC 7491, DOI 10.17487/RFC7491, March 2015, . + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + . + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/RFC8049, February 2017, . Authors' Addresses