draft-ietf-opsawg-service-model-explained-03.txt   draft-ietf-opsawg-service-model-explained-04.txt 
OPS Area Working Group Q. Wu OPS Area Working Group Q. Wu
Internet-Draft W. Liu Internet-Draft W. Liu
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: March 9, 2018 A. Farrel Expires: March 31, 2018 A. Farrel
Juniper Networks Juniper Networks
September 5, 2017 September 27, 2017
Service Models Explained Service Models Explained
draft-ietf-opsawg-service-model-explained-03 draft-ietf-opsawg-service-model-explained-04
Abstract Abstract
The IETF has produced many data modules in the YANG modeling The IETF has produced many modules in the YANG modeling language.
language. The majority of these modules are used to construct data The majority of these modules are used to construct data models to
models to model devices or monolithic functions. model devices or monolithic functions.
A small number of YANG modules have been defined to model services A small number of YANG modules have been defined to model services
(for example, the Layer Three Virtual Private Network Service Model (for example, the Layer Three Virtual Private Network Service Model
produced by the L3SM working group and documented in RFC 8049). produced by the L3SM working group and documented in RFC 8049).
This document describes service models as used within the IETF, and This document describes service models as used within the IETF, and
also shows where a service model might fit into a Software Defined also shows where a service model might fit into a Software Defined
Networking architecture. Note that service models do not make any Networking architecture. Note that service models do not make any
assumption of how a service is actually engineered and delivered for assumption of how a service is actually engineered and delivered for
a customer; details of how network protocols and devices are a customer; details of how network protocols and devices are
engineered to deliver a service are captured in other models that are engineered to deliver a service are captured in other modules that
not exposed through the Customer-Provider Interface. are not exposed through the Customer-Provider Interface.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- 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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents 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 publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 3 2. Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 4
3. Using Service Models . . . . . . . . . . . . . . . . . . . . 6 3. Using Service Models . . . . . . . . . . . . . . . . . . . . 6
4. Service Models in an SDN Context . . . . . . . . . . . . . . 8 4. Service Models in an SDN Context . . . . . . . . . . . . . . 8
5. Possible Causes of Confusion . . . . . . . . . . . . . . . . 10 5. Possible Causes of Confusion . . . . . . . . . . . . . . . . 10
6. Comparison With Other Work . . . . . . . . . . . . . . . . . 12 6. Comparison With Other Work . . . . . . . . . . . . . . . . . 12
6.1. Comparison With Network Service Models . . . . . . . . . 12 6.1. Comparison With Network Service Models . . . . . . . . . 12
6.2. Service Delivery and Network Element Model Work . . . . . 14 6.2. Service Delivery and Network Element Model Work . . . . . 14
6.3. Customer Service Model Work . . . . . . . . . . . . . . . 14 6.3. Customer Service Model Work . . . . . . . . . . . . . . . 14
6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 16 6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 16
7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 17 7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 17 7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 2, line 48 skipping to change at page 2, line 48
9. Manageability Considerations . . . . . . . . . . . . . . . . 19 9. Manageability Considerations . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
In recent years the number of data modules written in the YANG In recent years the number of modules written in the YANG modeling
modeling language [RFC6020] for configuration and monitoring has language [RFC6020] for configuration and monitoring has blossomed.
blossomed. Many of these are used for device-level configuration Many of these are used for device-level configuration (for example,
(for example, [RFC7223]) or for control of monolithic functions or [RFC7223]) or for control of monolithic functions or protocol
protocol instances (for example, [RFC7407]). 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] 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 controller and network devices, and between network orchestrators and
controllers. There may also be a hierarchy of such components with controllers. There may also be a hierarchy of such components with
super controllers, domain controllers, and device controllers all 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 There has been interest in using YANG to define and document data
models that describe services in a portable way that is independent models that describe services in a portable way that is independent
of which network operator uses the model. For example, the Layer of which network operator uses the model. For example, the Layer
Three Virtual Private Network Service Model (L3SM) [RFC8049]. Such Three Virtual Private Network Service Model (L3SM) [RFC8049]. Such
models may be used in manual and even paper-driven service request models may be used in manual and even paper-driven service request
processes with a gradual transition to IT-based mechanisms. processes with a gradual transition to IT-based mechanisms.
Ultimately they could be used in online, software-driven dynamic Ultimately they could be used in online, software-driven dynamic
systems, and eventually as part of an SDN system. systems, and eventually as part of an SDN system.
This document explains the scope and purpose of service models within 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 the IETF and describes how a service model can be used by a network
operator. Equally, this document clarifies what a service model is operator. Equally, this document clarifies what a service model is
not, and dispels some common misconceptions. not, and dispels some common misconceptions.
The document also shows where a service model might fit into an SDN 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 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 require or preclude the use of SDN. Note that service models do
not make any assumption of how a service is actually engineered and not make any assumption of how a service is actually engineered and
delivered to a customer; details of how network protocols and devices delivered to a customer; details of how network protocols and devices
are engineered to deliver a service are captured in other models that are engineered to deliver a service are captured in other modules
are not exposed through the Customer-Provider Interface. that are not exposed through the Customer-Provider Interface.
In summary, a service model is a formal representation of the data In summary, a service model is a formal representation of the data
elements that describe a network service as that service is described elements that describe a network service as that service is described
to or requested by a customer of a network operator. Details to or requested by a customer of a network operator. Details
included in the service model include a description of the service as included in the service model include a description of the service as
experienced by the customer, but not features of how that service is experienced by the customer, but not features of how that service is
delivered or realized by the service provider. delivered or realized by the service provider.
Other work on classifying YANG data models has been done in Other work on classifying YANG modules has been done in [RFC8199].
[RFC8199]. That document provides an important reference for this That document provides an important reference for this document, and
document, and also uses the term "service model". Section 6.1 in also uses the term "service module". Section 6.1 in this document
this document provides a comparison between these two uses of the provides a comparison between these two uses of the same terminology.
same terminology.
2. Terms and Concepts 2. Terms and Concepts
Readers should familiarize themselves with the description and 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: The following terms are used in this document:
Network Operator: This term is used to refer to the company that Network Operator: This term is used to refer to the company that
owns and operates one or more networks that provide Internet owns and operates one or more networks that provide Internet
connectivity services and/or other services. connectivity services and/or other services.
Customer: This term refers to someone who purchases a service Customer: This term refers to someone who purchases a service
(including connectivity) from a network operator. In the context (including connectivity) from a network operator. In the context
of this document, a customer is usually a company that runs their of this document, a customer is usually a company that runs their
skipping to change at page 4, line 34 skipping to change at page 4, line 41
called a Network Service) is some form of connectivity between called a Network Service) is some form of connectivity between
customer sites and the Internet, or between customer sites across customer sites and the Internet, or between customer sites across
the network operator's network and across the Internet. However, the network operator's network and across the Internet. However,
a distinction should be drawn between the parameters that describe a distinction should be drawn between the parameters that describe
a service as included in a customer service model (see the a service as included in a customer service model (see the
definition of this term, below) and a Service Level Agreement definition of this term, below) and a Service Level Agreement
(SLA) as discussed in Section 5 and Section 7.2. (SLA) as discussed in Section 5 and Section 7.2.
A service may be limited to simple connectivity (such as IP-based A service may be limited to simple connectivity (such as IP-based
Internet access), may be a tunnel (such as a virtual circuit), or 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 virtual private network). Services may be further enhanced by
additional functions providing security, load-balancing, additional functions providing security, load-balancing,
accounting, and so forth. Additionally, services usually include accounting, and so forth. Additionally, services usually include
guarantees of quality, throughput, and fault reporting. guarantees of quality, throughput, and fault reporting.
This document makes a distinction between a service as delivered This document makes a distinction between a service as delivered
to a customer (that is, the service as discussed on the interface to a customer (that is, the service as discussed on the interface
between a customer and the network operator) and the service as between a customer and the network operator) and the service as
realized within the network (as described in [RFC8199]). This realized within the network (as described in [RFC8199]). This
distinction is discussed further in Section 6. distinction is discussed further in Section 6.
skipping to change at page 5, line 20 skipping to change at page 5, line 28
designers. In order to make the overall design as clear as designers. In order to make the overall design as clear as
possible, an information model should hide all protocol and possible, an information model should hide all protocol and
implementation details. Another important characteristic of an implementation details. Another important characteristic of an
information model is that it defines relationships between information model is that it defines relationships between
managed objects. managed objects.
Data models, conversely, are defined at a lower level of Data models, conversely, are defined at a lower level of
abstraction and include many details. They are intended for abstraction and include many details. They are intended for
implementors and include protocol-specific constructs. 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 Service Model: A service model is a specific type of data model. It
describes a service and the parameters of the service in a describes a service and the parameters of the service in a
portable way. The service model may be divided into two portable way. The service model may be divided into two
categories: categories:
Customer Service Model: A customer service model is used to Customer Service Model: A customer service model is used to
describe a service as offered or delivered to a customer by a describe a service as offered or delivered to a customer by a
network operator. It can be used by a human (via a user 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 interface such as a GUI, web form, or CLI) or by software to
configure or request a service, and may equally be consumed by configure or request a service, and may equally be consumed by
a human (such as via an order fulfillment system) or by a a human (such as via an order fulfillment system) or by a
software component. Such models are sometimes referred to software component. Such models are sometimes referred to
simply as "service models" [RFC8049]. A customer service model simply as "service models" [RFC8049]. A customer service model
is expressed as a core set of parameters that are common across is expressed in a YANG module as a core set of parameters that
network operators: additional features that are specific to the are common across network operators: additional features that
offerings of individual network operators would be defined in are specific to the offerings of individual network operators
extensions or augmentations of the model. Except where would be defined in extensions or augmentations of the module.
specific technology details (such as encapsulations, or Except where specific technology details (such as
mechanisms applied on access links) are directly pertinent to encapsulations, or mechanisms applied on access links) are
the customer, customer service models are technology agnostic directly pertinent to the customer, customer service models are
so that the customer does not have influence over or knowledge technology agnostic so that the customer does not have
of how the network operator engineers the service. influence over or knowledge of how the network operator
engineers the service.
An example of where such details are relevant to the customer An example of where such details are relevant to the customer
is when they describe the behavior or interactions on the is when they describe the behavior or interactions on the
interface between the equipment at the customer site (often interface between the equipment at the customer site (often
referred to as the Customer Edge or CE equipment) and the referred to as the Customer Edge or CE equipment) and the
equipment at the network operator's site (usually referred to equipment at the network operator's site (usually referred to
as the Provider Edge or PE equipment). as the Provider Edge or PE equipment).
Service Delivery Model: A service delivery model is used by a Service Delivery Model: A service delivery model is used by a
network operator to define and manage how a service is network operator to define and manage how a service is
engineered in the network. It can be used by a human operator engineered in the network. It can be used by a human operator
(such as via a management station) or by a software tool to (such as via a management station) or by a software tool to
instruct network components. Such models are sometimes instruct network components. The YANG modules that encode such
referred to as "network service models" [RFC8199] and are models are sometimes referred to as "network service YANG
consumed by "external systems" such as Operations Support modules" [RFC8199] and are consumed by "external systems" such
System (OSS). A service delivery model is expressed as a core as Operations Support System (OSS). A service delivery module
set of parameters that are common across a network type and is expressed as a core set of parameters that are common across
technology: additional features that are specific to the a network type and technology: additional features that are
configuration of individual vendor equipment or proprietary specific to the configuration of individual vendor equipment or
protocols would be defined in extensions or augmentations of proprietary protocols would be defined in extensions or
the model. Service delivery models include technology-specific augmentations of the module. Service delivery modules include
modules. technology-specific modules.
The distinction between a customer service model and a service The distinction between a customer service model and a service
delivery model needs to be clarified. A customer service model is delivery model needs to be clarified. The modules that encode a
not a data model used to directly configure network devices, customer service model are not used to directly configure network
protocols, or functions: it is not something that is sent to network devices, protocols, or functions: it is not something that is sent to
devices (i.e., routers or switches) for processing. Equally, a network devices (i.e., routers or switches) for processing. Equally,
customer service model is not a data model that describes how a the modules that encode a customer service model do not describes how
network operator realizes and delivers the service described by the a network operator realizes and delivers the service described by the
model. This distinction is discussed further in later sections. module. This distinction is discussed further in later sections.
3. Using Service Models 3. Using Service Models
As already indicated, customer service models are used on the As already indicated, customer service models are used on the
interface between customers and network operators. This is shown interface between customers and network operators. This is shown
simply in Figure 1. simply in Figure 1.
The language in which a customer service model is described is a The language in which a customer service model is described is a
choice for whoever specifies the model. The IETF uses the YANG data choice for whoever specifies the model. The IETF uses the YANG data
modeling language defined in [RFC6020]. modeling language defined in [RFC6020].
skipping to change at page 9, line 45 skipping to change at page 10, line 6
: . . Configuration : : : . . Configuration : :
: . . Model : : : . . Model : :
--------- --------- --------- --------- --------- --------- --------- --------- --------- ---------
| Network | | Network | | Network | | Network | | Network | | Network | | Network | | Network | | Network | | Network |
| Element | | Element | | Element | | Element | | Element | | Element | | Element | | Element | | Element | | Element |
--------- --------- --------- --------- --------- --------- --------- --------- --------- ---------
Figure 3: An Example SDN Architecture with a Service Orchestrator Figure 3: An Example SDN Architecture with a Service Orchestrator
Figure 3 also shows where different data models might be applied 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 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: architectures:
o Figure 1 of [RFC7426] shows a separation of the "Application o Figure 1 of [RFC7426] shows a separation of the "Application
Plane", the "Network Services Abstraction Layer (NSAL)", and the Plane", the "Network Services Abstraction Layer (NSAL)", and the
"Control Plane". It marks the "Service Interface" as situated "Control Plane". It marks the "Service Interface" as situated
between the NSAL and the control plane. between the NSAL and the control plane.
o Figure 1 of [RFC7491] shows an interface between an "Application o Figure 1 of [RFC7491] shows an interface between an "Application
Service Coordinator" and an "Application-Based Network Operations Service Coordinator" and an "Application-Based Network Operations
Controller". Controller".
o Figure 1 of [RFC8199] shows an interface from an OSS or a Business o Figure 1 of [RFC8199] shows an interface from an OSS or a Business
Support System (BSS) that is expressed in "Network Service YANG Support System (BSS) that is expressed in "Network Service YANG
Models". Modules".
This can all lead to some confusion around the definition of a This can all lead to some confusion around the definition of a
"service interface" and a "service model". Some previous literature "service interface" and a "service model". Some previous literature
considers the interface northbound of the Network Orchestrator considers the interface northbound of the Network Orchestrator
(labeled "(b)" in Figure 3) to be a "service interface" used by an (labeled "(b)" in Figure 3) to be a "service interface" used by an
application, but the service described at this interface is network- application, but the service described at this interface is network-
centric and is aware of many features such as topology, technology, centric and is aware of many features such as topology, technology,
and operator policy. Thus, we make a distinction between this type and operator policy. Thus, we make a distinction between this type
of service interface and the more abstract service interface (labeled of service interface and the more abstract service interface (labeled
"(a)" in Figure 3) where the service is described by a service model "(a)" in Figure 3) where the service is described by a service model
and the interaction is between customer and network operator. and the interaction is between customer and network operator.
Further discussion of this point is provided in Section 5. Further discussion of this point is provided in Section 5.
5. Possible Causes of Confusion 5. Possible Causes of Confusion
In discussing service models, there are several possible causes of In discussing service models, there are several possible causes of
confusion: confusion:
o The services we are discussing are services provided by network o The services we are discussing are connectivity services provided
operators to customers. This is a completely different thing to by network operators to customers achieved by manipulating the
"Foo as a Service" (for example, Infrastructure as a Service network resources of the operator's network. This is a completely
(IaaS)) where a service provider offers a service at some location different thing to "Foo as a Service" (for example, Storage as a
that is reached across a network. The confusion arises not only Service (SaaS)) where a service provider offers reachability to a
because of the use of the word "service", but also because network value-added service that is provided at some location in the
operators may offer value-added services as well as network network using other resources (compute, storage, ...) that are not
connection services to their customers. 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 o Network operation is completely out of scope in the discussion of
services between a network operator and a customer. That means services between a network operator and a customer. That means
that the customer service model does not reveal to the customer that the customer service model does not reveal to the customer
anything about how the network operator delivers the service. The anything about how the network operator delivers the service. The
model does not expose details of technology or network resources model does not expose details of technology or network resources
used to provide the service. For example, in the simple case of used to provide the service. For example, in the simple case of
point-to-point virtual link connectivity provided by a network point-to-point virtual link connectivity provided by a network
tunnel (such as an MPLS pseudowire) the network operator does not tunnel (such as an MPLS pseudowire) the network operator does not
expose the path through the network that the tunnel follows. Of expose the path through the network that the tunnel follows. Of
skipping to change at page 11, line 18 skipping to change at page 11, line 32
standard features of the service as described in the customer standard features of the service as described in the customer
service model. service model.
o The network operator may use further data models (service delivery o The network operator may use further data models (service delivery
models) that help to describe how the service is realized in the models) that help to describe how the service is realized in the
network. These models might be used on the interface between the network. These models might be used on the interface between the
Service Orchestrator and the Network Orchestrator as shown in Service Orchestrator and the Network Orchestrator as shown in
Figure 3 and might include many of the pieces of information from Figure 3 and might include many of the pieces of information from
the customer service model alongside protocol parameters and the customer service model alongside protocol parameters and
device configuration information. [RFC8199] also terms these data device configuration information. [RFC8199] also terms these data
models as "service models" or "Network Service YANG Models" and a models as "service models" and encode them as "Network Service
comparison is provided in Section 6.1. It is important that the YANG Modules" and a comparison is provided in Section 6.1. It is
Service Orchestrator should be able to map from a customer service important that the Service Orchestrator should be able to map from
model to these service delivery models, but they are not the same a customer service model to these service delivery models, but
things. they are not the same things.
o Commercial terms are generally not a good subject for o Commercial terms are generally not a good subject for
standardization. It is possible that some network operators will standardization. It is possible that some network operators will
enhance standard customer service models to include commercial enhance standard customer service models to include commercial
information, but the way this is done is likely to vary widely information, but the way this is done is likely to vary widely
between network operators. Thus, this feature is out of scope for between network operators. Thus, this feature is out of scope for
standardized customer service models. standardized customer service models.
o Service Level Agreements (SLAs) have a high degree of overlap with o Service Level Agreements (SLAs) have a high degree of overlap with
the definition of services present in customer service models. the definition of services present in customer service models.
skipping to change at page 12, line 7 skipping to change at page 12, line 19
depending on material from standards bodies that specialize in depending on material from standards bodies that specialize in
this topic, but this feature is out of scope for the IETF's this topic, but this feature is out of scope for the IETF's
customer service models. customer service models.
If a network operator chooses to express an SLA using a data If a network operator chooses to express an SLA using a data
model, that model might be referenced as an extension or an model, that model might be referenced as an extension or an
augmentation of the customer service model. augmentation of the customer service model.
6. Comparison With Other Work 6. Comparison With Other Work
Other work has classified YANG models, produced parallel Other work has classified YANG modules, produced parallel
architectures, and developed a range of YANG models. This section architectures, and developed a range of YANG modules. This section
briefly examines that other work and shows how it fits with the briefly examines that other work and shows how it fits with the
description of service models introduced in this document. description of service models introduced in this document.
6.1. Comparison With Network Service Models 6.1. Comparison With Network Service Models
As previously noted, [RFC8199] provides a classification of YANG data As previously noted, [RFC8199] provides a classification of YANG
models. It introduces the term "Network Service YANG Module" to modules. It introduces the term "Network Service YANG Module" to
identify the type of model used to "describe the configuration, state identify the type of module used to "describe the configuration,
data, operations and notifications of abstract representations of state data, operations and notifications of abstract representations
services implemented on one or multiple network elements." These are of services implemented on one or multiple network elements." These
service delivery models as described in this document; that is, they modules are used to construct the service delivery models as
are the models used on the interface between the Service Orchestrator described in this document; that is, they are the modules used on the
or OSS/BSS and the Network Orchestrator as shown in Figure 3. 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 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 add an additional example of a Network Service YANG module as shown
Figure 4. This figure illustrates a functional architecture, and an in Figure 4. As can be seen, the highest classification of modules
implementation might choose to make different distinctions and collects those that are used to deliver operations support and
separations between components so that the functional units and business support. These might be consumed by an Operations Support
interfaces illustrated might fall within a single implementation. 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
| Customers | 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
+-------------------------------------------------------+ +-----------------------+ +-----------------------+
| | | | | |
| +----------------------+ | | Customer Service | | Other |
| | | Operations and Business | | YANG Modules | | Operations Support |
| | Service Orchestrator | Support Systems | | | | and |
| | | (OSS/BSS) | | +------+ +------+ | | Business Support |
| +----------------------+ | | | | | | | | YANG Modules |
| | | | L2SM | | L3SM | | | |
| | | | | | | | | |
+-------------------------------------------------------+ | +------+ +------+ | | |
| | | |
+-----------------------+ +-----------------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Service YANG Modules Network Service YANG Modules
+------------+ +-------------+ +-------------+ +-------------+ +------------+ +-------------+ +-------------+ +-------------+
| | | | | | | | | | | | | | | |
| - L2VPN | | - L2VPN | | EVPN | | L3VPN | | - L2VPN | | - L2VPN | | EVPN | | L3VPN |
| - VPWS | | - VPLS | | | | | | - VPWS | | - VPLS | | | | |
| | | | | | | | | | | | | | | |
+------------+ +-------------+ +-------------+ +-------------+ +------------+ +-------------+ +-------------+ +-------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Element YANG Modules Network Element YANG Modules
+------------+ +------------+ +-------------+ +------------+ +------------+ +------------+ +-------------+ +------------+
| | | | | | | | | | | | | | | |
| MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet |
| | | | | | | | | | | | | | | |
+------------+ +------------+ +-------------+ +------------+ +------------+ +------------+ +-------------+ +------------+
L2VPN: Layer 2 Virtual Private Network Key:
L3VPN: Layer 3 Virtual Private Network EVPN: Ethernet Virtual Private Network
VPWS: Virtual Private Wire Service L2SM: Layer 2 Virtual Private Network Service Model
VPLS: Virtual Private LAN Service 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 Layers Showing Service Models Figure 4: YANG Module Abstaction Layers Showing Customer Service
Modules
6.2. Service Delivery and Network Element Model Work 6.2. Service Delivery and Network Element Model Work
A number of IETF working groups are developing YANG models related to A number of IETF working groups are developing YANG modules related
services. These models focus on how the network operator configures to services. These models focus on how the network operator
the network through protocols and devices to deliver a service. Some configures the network through protocols and devices to deliver a
of these models are classified as service delivery models, while service. Some of these models are classified as network service
others have details that are related to specific element delivery models (also called service delivery models or network
configuration and so are classed as network element models (also configuation models depending on the level at which they are
called device models). 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: 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. 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 expected will be used by the management tools run by the network
operators in order to manage and monitor the network resources operators in order to manage and monitor the network resources
that they use to deliver L2VPN services. 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. Ethernet VPN service.
6.3. Customer Service Model Work 6.3. Customer Service Model Work
Several initiatives within the IETF are developing customer service Several initiatives within the IETF are developing customer service
models. The L3SM presents the L3VPN service as described by a models. The L3SM presents the L3VPN service as described by a
network operator to a customer. Figure 5, which is reproduced from network operator to a customer. Figure 5, which is reproduced from
[RFC8049], shows that the L3SM is a customer service model as [RFC8049], shows that the L3SM is a customer service model as
described in this document. described in this document.
skipping to change at page 19, line 11 skipping to change at page 19, line 11
service model is important, the data will be described in its own 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 module and may form part of the service model either by inclusion or
by index. by index.
8. Security Considerations 8. Security Considerations
The interface between customer and service provider is a commercial The interface between customer and service provider is a commercial
interface and needs to be subject to appropriate confidentiality. interface and needs to be subject to appropriate confidentiality.
Additionally, knowledge of what services are provided to a customer Additionally, knowledge of what services are provided to a customer
or delivered by a network operator may supply information that can be 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 Clearly, the ability to modify information exchanges between customer
and network operator may result in bogus requests, unwarranted and network operator may result in bogus requests, unwarranted
billing, and false expectations. Furthermore, in an automated billing, and false expectations. Furthermore, in an automated
system, modifications to service requests or the injection of bogus system, modifications to service requests or the injection of bogus
requests may lead to attacks on the network and delivery of customer requests may lead to attacks on the network and delivery of customer
traffic to the wrong place. traffic to the wrong place.
Therefore it is important that the protocol interface used to Therefore it is important that the protocol interface used to
exchange service request information between customer and network exchange service request information between customer and network
operator is subject to authorization, authentication, and encryption. 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 Equally, all external interfaces, such as any of those between the
functional components in Figure 3 needs to be correctly secured. functional components in Figure 3 needs to be correctly secured.
This document discusses modeling the information, not how it is This document discusses modeling the information, not how it is
exchanged. exchanged.
9. Manageability Considerations 9. Manageability Considerations
This whole document discusses issues related to network management This whole document discusses issues related to network management
and control. and control.
It is important to observe that automated service provisioning It is important to observe that automated service provisioning
resulting from use of a customer service model may result in rapid resulting from use of a customer service model may result in rapid
skipping to change at page 20, line 11 skipping to change at page 20, line 18
service, and that could be achieved through extensions to the core service, and that could be achieved through extensions to the core
service model just as SLA extensions could be made as described in service model just as SLA extensions could be made as described in
Section 5. Section 5.
10. IANA Considerations 10. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
11. Acknowledgements 11. Acknowledgements
Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair, and Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair,
Luis Miguel Contreras Murillo for useful review and comments. 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 Thanks to Dean Bogdanovic, Tianran Zhou, and Carl Moberg for their
help coordinating with [RFC8199]. help coordinating with [RFC8199].
Many thanks to Jerry Bonner for spotting a tiny, one-word, but Many thanks to Jerry Bonner for spotting a tiny, one-word, but
critical typo. critical typo.
12. References 12. References
12.1. Normative References 12.1. Normative References
skipping to change at page 21, line 8 skipping to change at page 21, line 20
[I-D.ietf-bess-l2vpn-yang] [I-D.ietf-bess-l2vpn-yang]
Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
and K. Tiruveedhula, "YANG Data Model for MPLS-based and K. Tiruveedhula, "YANG Data Model for MPLS-based
L2VPN", draft-ietf-bess-l2vpn-yang-06 (work in progress), L2VPN", draft-ietf-bess-l2vpn-yang-06 (work in progress),
June 2017. June 2017.
[I-D.ietf-l2sm-l2vpn-service-model] [I-D.ietf-l2sm-l2vpn-service-model]
Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data
Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn- 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 : [MEF-55] MEF Forum, "Service Operations Specification MEF 55 :
Lifecycle Service Orchestration (LSO) Reference Lifecycle Service Orchestration (LSO) Reference
Architecture and Framework", March 2016. Architecture and Framework", March 2016.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
skipping to change at page 22, line 5 skipping to change at page 22, line 16
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>. 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491, Application-Based Network Operations", RFC 7491,
DOI 10.17487/RFC7491, March 2015, DOI 10.17487/RFC7491, March 2015,
<https://www.rfc-editor.org/info/rfc7491>. <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 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
Model for L3VPN Service Delivery", RFC 8049, Model for L3VPN Service Delivery", RFC 8049,
DOI 10.17487/RFC8049, February 2017, DOI 10.17487/RFC8049, February 2017,
<https://www.rfc-editor.org/info/rfc8049>. <https://www.rfc-editor.org/info/rfc8049>.
Authors' Addresses Authors' Addresses
 End of changes. 46 change blocks. 
138 lines changed or deleted 174 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/