RFC 8309
Service Models Explained
RFC 8309: Service Models Explained 🎀
Okay bestie, this one is RFC 8309, titled Service Models Explained 💅. It's an Informational doc (so not a Standards Track spec 🦋), published in January 2018, with ISSN 2070-1721. The authors are Q. Wu and W. Liu from Huawei Technologies, plus A. Farrel from Juniper Networks. The title block doesn't list any documents it obsoletes or updates.
Abstract ✨
So the IETF has made loads of modules in the YANG modeling language, and most of them are for building data models of devices or monolithic functions 🧚.
Only a small handful of YANG modules model services. The big example is the Layer 3 Virtual Private Network Service Model (L3SM), made by the L3SM working group and written up in RFC 8049 💜.
This doc explains what service models look like inside the IETF and shows where one might fit into a software-defined networking architecture 🌸. Important bit: service models don't assume anything about how a service is actually engineered and delivered to a customer. The details of how protocols and devices are set up to deliver that service live in other modules, and those never get exposed through the interface between the customer and the provider 🔒.
Status of This Memo 🍓
This document is not an Internet Standards Track specification. It's published just for information 📚.
It's a product of the Internet Engineering Task Force (IETF), and it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the deets 🤓.
For the current status of this doc, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8309 🔗.
Copyright Notice 🦋
Copyright (c) 2018 IETF Trust and the people listed as the document's authors. All rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜.
Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License ⚖️.
Table of Contents 💜
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 . . . . . . . . . . . . . . . . . . . . . . . 231. Introduction 🌈
So in recent years, YANG (the modeling language from [RFC6020]) has totally blossomed 🌸 for configuration and monitoring. Lots of these modules handle device-level config, like [RFC7223], or control monolithic functions or protocol instances, like [RFC7407] 💅.
[RFC7950] draws a line between a "data model", which it describes as how data is represented and accessed, and a "YANG module", which defines hierarchies of schema nodes so you get a self-contained, compilable block of definitions and inclusions 🧠. YANG uses modules to structure data models so they're easier to use ✨.
In the Software-Defined Networking (SDN) world [RFC7149] [RFC7426] 🛰️, YANG data modules may sit on the interface between a controller and network devices, and also between network orchestrators and controllers. You can even get a whole hierarchy of these, with super controllers, domain controllers, and device controllers all swapping info and instructions through YANG modules 👑.
People have been eager to use YANG to define and document data models that describe services in a portable way, meaning the model doesn't depend on which network operator is using it. The Layer 3 Virtual Private Network Service Model (L3SM) from [RFC8049] is a good example 💜. These models can be used in manual, even paper-driven, service request processes, with a gradual move toward IT-based mechanisms 📄. Ultimately they could power online, software-driven dynamic systems, and they may be part of an SDN system too 🦋.
This doc explains the scope and purpose of service models within the IETF (and it's limited to the scope of the IETF, so no wandering off) and describes how a network operator can use a service model 🎀. It also clarifies what a service model is not and busts some common misconceptions 🙈.
The doc also shows where a service model might fit into an SDN architecture. Big note though: a service model does not require SDN, and it doesn't rule SDN out either 🫶. Again, service models don't assume how a service is actually engineered and delivered to a customer. The details of how network protocols and devices are engineered to deliver a service are captured in other modules, and those aren't exposed through the interface between the customer and the provider 🔒.
Quick summary, because it's important 💖: 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. It covers how the service is experienced by the customer, but not how the provider actually delivers or realizes it ✨.
Other work on classifying YANG modules is in [RFC8199] 🧚. That doc is an important reference for this one, and it also uses the term "service module". Section 6.1 of this doc compares those two uses of the same terminology 👀.
2. Terms and Concepts ✨
okay bestie, before we dive in, go read the description and classification of YANG modules in [RFC8199] 📚 it's the foundation for everything else here, and you'll thank me later 🫶
Here's the vocab we're working with, so we're all on the same page 🎀
Network Operator: the company that owns and operates one or more networks that provide Internet connectivity services and/or other services 👑
Customer: someone who purchases a service (including connectivity) from a network operator. In this context, a customer is usually a company that runs its own network or computing platforms and wants to connect to the Internet or between sites. That could be an enterprise network or a data center 🏢 Sometimes the word also refers to the individual person at that company who signs up to buy services from a network operator. A customer as described here is a separate commercial operation from the network operator, but some companies have internal customers, so 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 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. But you need to keep two things separate: the parameters that describe a service as included in a customer service model (see its definition below), and a Service Level Agreement (SLA), as discussed in Sections 5 and 7.2 🫣
A service may be limited to simple connectivity (like IP-based Internet access), may be a tunnel (like a virtual circuit), or may involve more complex connectivity (like a multisite virtual private network). Services can be further enhanced with extra functions like security, load balancing, accounting, and so forth. Services usually also come with 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]). That 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, like this:
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 following 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, as shown in Figure 1 below. 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 it 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 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 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 🫶
3. Using Service Models 🌈
As already indicated, customer service models are used on the interface between customers and network operators. This is shown 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] 💖
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 OperatorsHow 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 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 🪄
3.1. Practical Considerations 💅
The practicality of customer service models has been repeatedly debated. It has been suggested that network operators have radically different business models and widely diverse commercial offerings, which makes a common customer service model impractical. However, L3SM [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 🧩
4. Service Models in an SDN Context ✨
Okay so, in an SDN system, the management of network resources and protocols is handled by software that figures out the best way to use the network 🧠. Figure 2 shows a sample architecture where network elements get programmed by a component called an "SDN controller" (or "controller" for short 💅). Those controllers get instructed by an orchestrator that has a wider view of all of a network, or part of it 🦋. How the inside of an SDN control plane is organized is specific to each 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 🙈. The customer has no clue what tech the operator has available to deliver the service, so they don't make tech-specific requests. They're only allowed to ask for the service that's actually going to be delivered 💖. The orchestrator has to map that request onto its own view, and this mapping may include choosing which networks and technologies to use, depending on which service features were requested 🧚.
One way to do 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 get applied across 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 (each of which may be responsible for multiple network elements) on how to configure parts of a network 💜.
The following examples show the split between control components that expose a "service interface". You'll spot that in tons of figures for extended SDN architectures 🦋:
- 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 sitting between the NSAL and the control plane.
- Figure 1 of [RFC7491] shows an interface between an "Application Service Coordinator" and an "Application-Based Network Operations Controller".
- Figure 1 of [RFC8199] shows an interface from an OSS or a Business Support System (BSS) that is expressed in "Network Service YANG Modules".
Okay, and this is where things get messy 😭. People often mix up what a "service interface" and a "service model" actually are. Some earlier literature treats the interface northbound of the network orchestrator (labeled "(b)" in Figure 3) as a "service interface" used by an application. But the service described at that interface is network centric, and it's aware of lots of stuff like topology, technology, and operator policy 🧩. So we make a distinction between this kind of service interface and the more abstract one (labeled "(a)" in Figure 3), where the service is described by a service model and the interaction is between the customer and the network operator 💅. More on this point in Section 5.
5. Possible Causes of Confusion 🙈
When we talk about service models, there are a few things that can cause confusion:
- The services we're discussing are connectivity services that network operators provide to customers. The services are achieved by manipulating the operator's network resources. This is a completely different thing from "Foo as a Service" (for example, Storage as a Service (SaaS)), where a service provider offers reachability to a value-added service that runs at some location in the network, using other resources (compute, storage, ...) that aren't part of the network itself. The confusion comes not just from the word "service" showing up in both cases, but also because network operators may offer both types of service to their customers 😵💫.
- Network operation is normally out of scope when we talk about services between a network operator and a customer. That means the customer service model doesn't reveal anything to the customer about how the operator delivers the service. It also doesn't expose details of the technology or network resources used to provide the service (all of which 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 doesn't expose the path the tunnel takes through the network. Of course, this doesn't stop the 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 those aren't standard features of the service as described in the customer service model 🌍.
- The network operator may use further data models (service delivery models) that help 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. They might include many of the pieces of information from the customer service model, alongside protocol parameters and device configuration information. [RFC8199] also calls these data models "service models" and encodes them as "Network Service YANG Modules". A comparison is provided in Section 6.1. It's important that the service orchestrator can map from a customer service model to these service delivery models, but they are not the same thing 🫶.
- 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's possible that some network operators will enhance standard customer service models to include commercial information, but the way they do it is likely to vary widely between operators. So this feature is out of scope for standardized customer service models 🙅♀️.
- SLAs overlap a lot with the definition of services in customer service models 🥺. Requests for specific bandwidth, for example, might be in a customer service model, and agreeing to deliver a service is a commitment to the description of that service in the customer service model. However, SLAs typically include lots of fine-grained details about how services are allowed to vary, by how much, and how often. SLAs are also tied to commercial terms with penalties and so forth, so they aren't good topics for standardization either. Just like commercial terms, it's expected that some network operators will enhance standard customer service models to include SLA parameters, either using their own work or by 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 modules, produced parallel architectures, and developed a range of YANG modules. This section takes a quick look at 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 📚✨
okay so bestie, [RFC8199] already sorted YANG modules into classes 🧚. It came up with the term "Network Service YANG Module" for the type of module that describes "the configuration, state data, operations, and notifications of abstract representations of services implemented on one or multiple network elements." 💅 These are the modules used to build the service delivery models we've been talking about, so they're the ones sitting on the interface between the service orchestrator or OSS/BSS and the network orchestrator, as you can see in Figure 3. 🎀
Figure 1 of [RFC8199] can be tweaked to make this clearer, and to add another Network Service YANG module example, which you'll find in Figure 4. 🦋 The top layer is where the operations support and business support modules live 🌸. These might be used by an Operations Support System (OSS) or a Business Support System (BSS), and a service orchestrator might be part of an OSS/BSS or its own separate thing, no cap. 💖 That top layer splits into customer service modules, which describe services to a customer like we covered in this doc, and other modules for OSS/BSS stuff like 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 Modules6.2. Service Delivery and Network Element Model Work 🛠️
A bunch of IETF working groups are cooking up YANG modules for services 🍓. These focus on how the network operator configures the network through protocols and devices to actually deliver a service. Some are classed as network service delivery models (also called service delivery models or network configuration models, depending on how high-level they're pitched), while others get into specific element configuration and are classed as network element models (also called device models) 💜.
Here's a sample set of them, bestie 🌈:
- [BGP-L3VPN-YANG] defines a YANG module that can be used to configure and manage BGP L3VPNs. ✨
- [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. 🦋
- [EVPN-YANG] defines YANG modules for delivering an Ethernet VPN service. 🫶
6.3. Customer Service Model Work 👑
Several initiatives within the IETF are building customer service models, and this part is so iconic 😭. The L3SM presents the L3VPN service, as described by a network operator, to a customer. Figure 5, 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 ArchitectureA Layer 2 VPN Service Model (L2SM) is defined in [L2VPN-SERVICE] 🌸. Its usage is shown in Figure 6, which is a reproduction of Figure 5 from that document. As you can see, the L2SM is a customer service model as described in this document, lowkey the same vibe as the L3SM 🎀.
----------------------------
| 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 Architecture6.4. The MEF Architecture 🌟
The MEF Forum (MEF) built an architecture for network management and operation. It's documented as the Lifecycle Service Orchestration (LSO) Reference Architecture and is illustrated in Figure 2 of [MEF-55] 🧚.
MEF's work covers all of Lifecycle Service Orchestration, including billing, SLAs, order management, and lifecycle management. The IETF's service model work is usually smaller and offers a simple, self-contained service YANG module 🦋. This doesn't invalidate either approach, it just notes that they're different approaches, and that's totally fine 💅✨.
7. Further Concepts 🔮
This section introduces a few more advanced concepts, bestie 🫶.
7.1. Technology Agnostic 🌈
Service models should generally be technology agnostic. Like, the customer shouldn't care how the service gets provided, as long as it gets delivered 💅.
Some technologies do reach out to the customer site and change the type of service delivered, though, so those features do need to be described in the service model 😭.
Two examples:
- The data passed between customer equipment and network operator equipment will be encapsulated in a specific way, and that data-plane type forms part of the service. 🎀
- Protocols that run between customer equipment and network operator equipment (for example, Operations, Administration, and Maintenance (OAM) protocols, protocols for discovery, or protocols for exchanging routing information) need to be selected and configured as part of the service description. 🦋
7.2. Relationship to Policy 👑
Policy shows up as a crucial function in lots of places during network orchestration 💖. A service orchestrator will, for example, apply the network operator's policies to work out how to provide a service for a particular customer (possibly considering commercial terms) 🌸.
However, the policies inside a service model are limited to those a customer has direct influence over and that the network operator acts on 🎀.
Policies that express desired behavior of services when specific events happen are close to SLA definitions, so they should only go in the base service model where they're common offerings of all network operators 🍓. Policies that describe which person working for a customer may request or modify services (that is, authorization) are close to commercial terms, and they too should only go in the base service model where they're common offerings of all network operators 💜.
As with the commercial terms and SLAs discussed in Section 5, some network operators are expected to enhance standard customer service models with policy parameters, either using their own work or depending on specific policy models built in the IETF or other standards bodies ✨.
Still, policy is so important that all service models should be designed to be easily extensible, so policy components can be added and associated with services as needed 🫶🔥.
7.3. Operator-Specific Features 🌈
When work on the L3SM was getting started, there was some doubt about whether network operators would be able to agree on a common description of the services they offer customers. In a competitive environment, each one markets its services differently with different extra features 💀. But the working group did manage to agree on a core set of features that multiple network operators were willing to consider "common" 👑. They also understood that if an individual network operator wanted to describe additional features (operator-specific features), they could do that by extending or augmenting the L3SM model 🧚.
So when a basic description of a core service is agreed on and documented in a service model, it's important that the model be easily extended or augmented by each network operator. That way the standardized model can be used in a common way, and only the operator-specific features vary from one environment to another 💖🎀.
7.4. Supporting Multiple Services 🧚
okay so network operators don't just sell one thing, they sell a whole buffet 🍓 of services to their customers. Each one would normally get its own service model, bestie.
Whether each service model gets its own specialized service orchestrator that's tuned for that one service, or whether one single service orchestrator handles all of them, is an implementation and deployment choice. Totally up to whoever is building and running it 💅
Over time, we expect certain elements to keep showing up in every model. The postal address of the customer is a perfect example. Like, why would you retype it in every single model? 🙄
We anticipate that access to this kind of information from each service model is important. The data will be described in its own module, and the service model can include it or point to it by index. ✨
8. Security Considerations 🔐
okay this section is serious, so let's be serious for a sec 😭
The interface between the customer and the service provider is a commercial interface, and it needs appropriate confidentiality. Also, knowing what services a customer gets, or what a network operator delivers, can give attackers info they can use in all kinds of security attacks. The service model itself will expose security-related parameters for the specific service wherever the related function is available to the customer.
Clearly, being able to change the information exchanged between customer and network operator could lead to bogus requests, unwarranted billing, and false expectations. 💀 Furthermore, in an automated system, changing service requests or injecting bogus requests could lead to attacks on the network and send customer traffic to the wrong place. Yikes.
So it's 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 a service model provides protects the operator from unwarranted visibility into their network. There's extra protection too, because how the service is delivered is entirely up to the operator. 🫶
Equally, all external interfaces, like any of the ones between the functional components in Figure 3, need to be correctly secured. Also, this document discusses modeling the information, not how it gets exchanged. So that part is a different story 🙈
9. Manageability Considerations 🛠️
This whole document discusses issues related to network management and control. Obviously 💅
It's important to notice that automated service provisioning, which comes from using a customer service model, can cause rapid and significant changes in traffic load within a network. That might affect other services carried in the same network. Lowkey a big deal 👀
So, we expect that a service-orchestration component is aware of other service commitments. We also expect that the network-orchestration component won't commit network resources to fulfill a service unless doing so is appropriate. And a feedback loop will be provided to report on degradation of the network that would impact the service. Protect the vibes, protect the network 🦋
The operational state of a service does not form part of a customer service model. However, a network operator may want to report some state information about various components of the service. That could be done through extensions to the core service model, just like SLA extensions could be made as described in Section 5. ✨
10. IANA Considerations 🌸
This document does not require any IANA actions. Nothing to register, no vibes to request from IANA, we're all good 💖
11. References 📚
11.1. Normative References
[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>.11.2. Informative References
[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>.Acknowledgements 🫶
Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair, Luis Miguel Contreras Murillo, Joe Salowey, Benoit Claise, Robert Sparks, Tom Petch, David Sinicrope, and Deborah Brungard for their 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 but critical, one-word typo. Small word, big energy 🔥
Authors' Addresses 💌
Qin Wu
Huawei Technologies
Email: bill.wu@huawei.com
Will Liu
Huawei Technologies
Email: liushucheng@huawei.com
Adrian Farrel
Juniper Networks
Email: afarrel@juniper.net📦 where this page comes from
- ietf: rfc8309 2018-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms