draft-ietf-opsawg-service-model-explained-01.txt   draft-ietf-opsawg-service-model-explained-02.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: December 31, 2017 A. Farrel Expires: February 25, 2018 A. Farrel
Juniper Networks Juniper Networks
June 29, 2017 August 24, 2017
Service Models Explained Service Models Explained
draft-ietf-opsawg-service-model-explained-01 draft-ietf-opsawg-service-model-explained-02
Abstract Abstract
The IETF has produced a considerable number of data modules in the The IETF has produced many data modules in the YANG modeling
YANG modelling language. The majority of these modules are used to language. The majority of these modules are used to construct data
construct data models to model devices or monolithic functions and models to model devices or monolithic functions.
they allow access for configuration and to read operational status.
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 briefly sets out the scope of and purpose of an IETF This document describes service models as used within the IETF, and
service model, and it also shows where a service model might fit into also shows where a service model might fit into a Software Defined
a Software Defined Networking architecture. Note that service models Networking architecture. Note that service models do not make any
do not make any assumption of how a service is actually engineered assumption of how a service is actually engineered and delivered for
and delivered for a customer; details of how network protocols and a customer; details of how network protocols and devices are
devices are engineered to deliver a service are captured in other engineered to deliver a service are captured in other models that are
models that are not exposed through the Customer-Provider Interface. 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 http://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 December 31, 2017. This Internet-Draft will expire on February 25, 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 (http://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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . 11 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 . . . . . 13 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 . . . . . . . . . . . . . . . . . . 15 6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 16
7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 16 7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 16 7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 17
7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 16 7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 17
7.3. Operator-Specific Features . . . . . . . . . . . . . . . 17 7.3. Operator-Specific Features . . . . . . . . . . . . . . . 18
7.4. Supporting Multiple Services . . . . . . . . . . . . . . 17 7.4. Supporting Multiple Services . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Manageability Considerations . . . . . . . . . . . . . . . . 18 9. Manageability Considerations . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 data modules written in the YANG
modelling language [RFC6020] for configuration and monitoring has modeling language [RFC6020] for configuration and monitoring has
blossomed. Many of these are used for device-level configuration blossomed. Many of these are used for device-level configuration
(for example, [RFC7223]) or for control of monolithic functions or (for example, [RFC7223]) or for control of monolithic functions or
protocol instances (for example, [RFC7407]). protocol instances (for example, [RFC7407]).
Within the context of Software Defined Networking (SDN) [RFC7426] Within the context of Software Defined Networking (SDN) [RFC7149]
YANG data models may be used on Southbound Interfaces (SBIs) between [RFC7426] YANG data models may be used on the interface between a
a controller and network devices, and between network orchestrators controller and network devices, and between network orchestrators and
and controllers. There may also be a hierarchy of such components controllers. There may also be a hierarchy of such components with
with super-controllers, domain controllers, and device controllers super controllers, domain controllers, and device controllers all
all exchanging information and instructions using YANG models. exchanging information and instructions using YANG models.
Recently there has been interest in using YANG to define and document There has been interest in using YANG to define and document data
data models that describe services in a portable way that is models that describe services in a portable way that is independent
independent of which network operator uses the model. For example, of which network operator uses the model. For example, the Layer
the Layer Three Virtual Private Network Service Model (L3SM) Three Virtual Private Network Service Model (L3SM) [RFC8049]. Such
[RFC8049]. Such models may be used in manual and even paper-driven models may be used in manual and even paper-driven service request
service request processes with a gradual transition to IT-based processes with a gradual transition to IT-based mechanisms.
mechanisms. Ultimately they could be used in online, software-driven Ultimately they could be used in online, software-driven dynamic
dynamic systems. 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 models that
are not exposed through the Customer- Provider Interface. are not exposed through the Customer-Provider Interface.
In summary, a service model is a formal representation of the data
elements that describe a network service as that service is described
to or requested by a customer of a network operator. Details
included in the service model include a description of the service as
experienced by the customer, but not features of how that service is
delivered or realized by the service provider.
Other work on classifying YANG data models has been done in Other work on classifying YANG data models has been done in
[I-D.ietf-netmod-yang-model-classification]. That document provides [RFC8199]. That document provides an important reference for this
an important reference for this document, and also uses the term document, and also uses the term "service model". Section 6.1 in
"service model". Section 6.1 provides a comparison between these two this document provides a comparison between these two uses of the
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 classification of YANG models provided in [RFC8199].
[I-D.ietf-netmod-yang-model-classification].
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. The term is also connectivity services and/or other services.
used to refer to an individual who performs operations and
management on those networks.
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
own network or computing platforms and wishes to connect to the own network or computing platforms and wishes to connect to the
Internet or between sites. Such a customer may operate an Internet or between sites. Such a customer may operate an
enterprise network or a data center. Sometimes this term may also enterprise network or a data center. Sometimes this term may also
be used to refer to the individual in such a company who contracts be used to refer to the individual in such a company who contracts
to buy services from a network operator. A customer as described to buy services from a network operator. A customer as described
here is a separate commercial operation from the network operator, here is a separate commercial operation from the network operator,
skipping to change at page 4, line 39 skipping to change at page 4, line 43
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 be a more complex connectivity model (such as 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 realized within the network (as described in [RFC8199]). This
[I-D.ietf-netmod-yang-model-classification]). This distinction is distinction is discussed further in Section 6.
discussed further in Section 6.
Readers may also refer to [RFC7297] for an example of how an IP Readers may also refer to [RFC7297] for an example of how an IP
connectivity service may be characterized. connectivity service may be characterized.
Data Model: The concepts of information models and data models are Data Model: The concepts of information models and data models are
described in [RFC3444]. That document defines a data model by described in [RFC3444]. That document defines a data model by
contrasting it with the definition of an information model, so it contrasting it with the definition of an information model as
may be helpful to quote some text to give context within this follows:
document.
The main purpose of an information model is to model managed The main purpose of an information model is to model managed
objects at a conceptual level, independent of any specific objects at a conceptual level, independent of any specific
implementations or protocols used to transport the data. The implementations or protocols used to transport the data. The
degree of specificity (or detail) of the abstractions defined degree of specificity (or detail) of the abstractions defined
in the information model depends on the modeling needs of its in the information model depends on the modeling needs of its
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
skipping to change at page 6, line 10 skipping to change at page 6, line 10
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. Such models are sometimes
referred to as "network service models" referred to as "network service models" [RFC8199] and are
[I-D.ietf-netmod-yang-model-classification] and are consumed by consumed by "external systems" such as Operations Support
"external systems" such as Operations Support System (OSS). A System (OSS). A service delivery model is expressed as a core
service delivery model is expressed as a core set of parameters set of parameters that are common across a network type and
that are common across a network type and technology: technology: additional features that are specific to the
additional features that are specific to the configuration of configuration of individual vendor equipment or proprietary
individual vendor equipment or proprietary protocols would be protocols would be defined in extensions or augmentations of
defined in extensions or augmentations of the model. Service the model. Service delivery models include technology-specific
delivery models include technology-specific modules. 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 repeatedly clarified. A customer service delivery model needs to be repeatedly clarified. A customer service
model is not a data model used to directly configure network devices, model is not a data model used to directly configure network devices,
protocols, or functions: it is not something that is sent to network protocols, or functions: it is not something that is sent to network
devices (i.e., routers or switches) for processing. Equally, a devices (i.e., routers or switches) for processing. Equally, a
customer service model is not a data model that describes how a customer service model is not a data model that describes how a
network operator realizes and delivers the service described by the network operator realizes and delivers the service described by the
model. This distinction is discussed further in later sections. model. 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].
The encoding and communication protocol used to exchange a customer The encoding and communication protocol used to exchange a customer
service model between customer and network operator are deployment- service model between customer and network operator are deployment-
and implementation-specific. The IETF has standardized the NETCONF and implementation-specific. The IETF has standardized the NETCONF
protocol [RFC6241] and the RESTCONF protocol [RFC8040] for protocol [RFC6241] and the RESTCONF protocol [RFC8040] for
interactions "on the wire" between software components with data interactions "on the wire" between software components with data
encoded in XML or JSON. However, co-located software components encoded in XML or JSON. However, co-located software components
might use an API, while systems with more direct human interactions might use an internal API, while systems with more direct human
might use web pages or even paper forms. interactions might use web pages or even paper forms.
-------------- Customer ---------------------- -------------- Customer ----------------------
| | Service Model | | | | Service Model | |
| Customer | <-----------------> | Network Operator | | Customer | <-----------------> | Network Operator |
| | | | | | | |
-------------- ---------------------- -------------- ----------------------
Figure 1: The Customer Service Models used on the Interface between Figure 1: The Customer Service Models used on the Interface between
Customers and Network Operators Customers and Network Operators
skipping to change at page 7, line 32 skipping to change at page 7, line 32
one or more networks to deliver the requested services. That means one or more networks to deliver the requested services. That means
that the network operator (or software run by the network operator) that the network operator (or software run by the network operator)
takes the information in the customer service model and determines takes the information in the customer service model and determines
how to deliver the service by enabling and configuring network how to deliver the service by enabling and configuring network
protocols and devices. They may achieve this by constructing service protocols and devices. They may achieve this by constructing service
delivery models and passing them to network orchestrators or delivery models and passing them to network orchestrators or
controllers. The use of standard customer service models eases controllers. The use of standard customer service models eases
service delivery by means of automation. service delivery by means of automation.
The practicality of customer service models has been repeatedly The practicality of customer service models has been repeatedly
debated. It has been suggested that network operators have such debated. It has been suggested that network operators have radically
radically different business modes and such diverse commercial different business modes and widely diverse commercial offerings
offerings that a common customer service model is impractical. making a common customer service model is impractical. However, the
However, the L3SM [RFC8049] results from the consensus of multiple L3SM [RFC8049] results from the consensus of multiple individuals
individuals working at network operators and offers a common core of working at network operators and offers a common core of service
service options that can be augmented according to the needs of options that can be augmented according to the needs of individual
individual network operators. network operators.
It has also been suggested that there should be a single, base It has also been suggested that there should be a single, base
customer service module, and that details of individual services customer service module, and that details of individual services
should be offered as extensions or augmentations of this. It is should be offered as extensions or augmentations of this. It is
quite possible that a number of service parameters (such as the quite possible that a number of service parameters (such as the
identity and postal address of a customer) will be common and it identity and postal address of a customer) will be common and it
would be a mistake to define them multiple times, once in each would be a mistake to define them multiple times, once in each
customer service model. However, the distinction between a 'module' customer service model. However, the distinction between a 'module'
and a 'model' should be considered at this point: modules are how the and a 'model' should be considered at this point: modules are how the
data for models is logically broken out and documented especially for data for models is logically broken out and documented especially for
skipping to change at page 8, line 41 skipping to change at page 8, line 41
--------- --------- --------- --------- --------- --------- --------- ---------
| Network | | Network | | Network | | Network | | Network | | Network | | Network | | Network |
| Element | | Element | | Element | | Element | | Element | | Element | | Element | | Element |
--------- --------- --------- --------- --------- --------- --------- ---------
Figure 2: A Sample SDN Architecture Figure 2: A Sample SDN Architecture
But a customer's service request is (or should be) technology- But a customer's service request is (or should be) technology-
agnostic. That is, there should be an independence between the agnostic. That is, there should be an independence between the
behavior and functions that a customer requests and the technology behavior and functions that a customer requests and the technology
that the network operator has available to deliver the service. This that the network operator has available to deliver the service. The
means that the service request must be mapped to the orchestrator's orchestrator must map the service request to its view, and this
view, and this mapping may include a choice of which networks and mapping may include a choice of which networks and technologies to
technologies to use depending on which service features have been use depending on which service features have been requested.
requested.
One implementation option to achieve this mapping is to split the One implementation option to achieve this mapping is to split the
orchestration function between a "Service Orchestrator" and a orchestration function between a "Service Orchestrator" and a
"Network Orchestrator" as shown in Figure 3. "Network Orchestrator" as shown in Figure 3.
Customer Customer
------------------ Service ---------- ------------------ Service ----------
| | Model | | | | Model | |
| Service |<-------->| Customer | | Service |<-------->| Customer |
| Orchestrator | (a) | | | Orchestrator | (a) | |
| | ---------- | | ----------
------------------ ------------------
. . . .
. . ----------- . . (b) -----------
. (b) . ......|Application| . (b) . ......|Application|
. . : | BSS/OSS | . . : | BSS/OSS |
. . : ----------- . . : -----------
. Service Delivery . : . Service Delivery . :
. Model . : . Model . :
------------------ ------------------ ------------------ ------------------
| | | | | | | |
| Network | | Network | | Network | | Network |
| Orchestrator | | Orchestrator | | Orchestrator | | Orchestrator |
| | | | | | | |
skipping to change at page 10, line 8 skipping to change at page 10, line 8
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 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" 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 [RFC7491] describes an interface between an "Application Service o Figure 1 of [RFC7491] shows an interface between an "Application
Coordinator" and an "Application-Based Network Operations Service Coordinator" and an "Application-Based Network Operations
Controller". Controller".
o Figure 1 of [I-D.ietf-netmod-yang-model-classification] shows an o Figure 1 of [RFC8199] shows an interface from an OSS or a Business
interface from an OSS or a Business Support System (BSS) that is Support System (BSS) that is expressed in "Network Service YANG
expressed in "Network Service YANG Models". Models".
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
skipping to change at page 11, line 17 skipping to change at page 11, line 17
(such as might be revealed by a route trace), but these are not (such as might be revealed by a route trace), but these are not
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. device configuration information. [RFC8199] also terms these data
[I-D.ietf-netmod-yang-model-classification] also terms these data
models as "service models" or "Network Service YANG Models" and a models as "service models" or "Network Service YANG Models" and a
comparison is provided in Section 6.1. It is important that the comparison is provided in Section 6.1. It is important that the
Service Orchestrator should be able to map from a customer service Service Orchestrator should be able to map from a customer service
model to these service delivery models, but they are not the same model to these service delivery models, but they are not the same
things. 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. between network operators. Thus, this feature is out of scope for
standardized customer service models.
o Service Level Agreements (SLAs) have a high degree of overlap with 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.
Requests for specific bandwidth, for example, might be present in Requests for specific bandwidth, for example, might be present in
a customer service model, and agreement to deliver a service is a a customer service model, and agreement to deliver a service is a
commitment to the description of the service in the customer commitment to the description of the service in the customer
service model. However, SLAs typically include a number of fine- service model. However, SLAs typically include a number of fine-
grained details about how services are allowed to vary, by how grained details about how services are allowed to vary, by how
much, and how often. SLAs are also linked to commercial terms much, and how often. SLAs are also linked to commercial terms
with penalties and so forth, and so are also not good topics for with penalties and so forth, and so are also not good topics for
standardization. standardization. As with commercial terms, it is expected that
some network operators will enhance standard customer service
models to include SLA parameters either using their own work or
depending on material from standards bodies that specialize in
this topic, but this feature is out of scope for the IETF's
customer service models.
If a network operator chooses to express an SLA using a data 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 models, produced parallel
architectures, and developed a range of YANG models. This section architectures, and developed a range of YANG models. 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, [I-D.ietf-netmod-yang-model-classification] As previously noted, [RFC8199] provides a classification of YANG data
provides a classification of YANG data models. It introduces the models. It introduces the term "Network Service YANG Module" to
term "Network Service YANG Module" to identify the type of model used identify the type of model used to "describe the configuration, state
to "describe the configuration, state data, operations and data, operations and notifications of abstract representations of
notifications of abstract representations of services implemented on services implemented on one or multiple network elements." These are
one or multiple network elements." These are service delivery models service delivery models as described in this document, that is, they
as described in this document, that is, they are the models used on are the models used on the interface between the Service Orchestrator
the interface between the Service Orchestrator or OSS/BSS and the or OSS/BSS and the Network Orchestrator as shown in Figure 3.
Network Orchestrator as shown in Figure 3.
Figure 1 of [I-D.ietf-netmod-yang-model-classification] can be Figure 1 of [RFC8199] can be modified to make this more clear and to
modified to make this more clear and to add an additional example of add an additional example of a Network Service YANG model as shown in
a Network Service YANG model as shown in Figure 4. Figure 4. This figure illustrates a functional architecture and an
implementation might choose to make different distinctions and
separations between components so that the functional units and
interfaces illustrated might fall within a single implementation.
+---------------+ +---------------+
| | | |
| Customers | | Customers |
| | | |
+---------------+ +---------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Customer Service YANG Modules Customer Service YANG Modules
+--------------------------+ +--------------------------+ +-------------------------------------------------------+
| | | Operations and Business | | |
| Service Orchestrator | | Support Systems | | +----------------------+ |
| | | (OSS/BSS) | | | | Operations and Business |
+--------------------------+ +--------------------------+ | | Service Orchestrator | Support Systems |
| | | (OSS/BSS) |
| +----------------------+ |
| |
| |
+-------------------------------------------------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Service YANG Modules Network Service YANG Modules
+------------+ +-------------+ +-------------+ +-------------+ +------------+ +-------------+ +-------------+ +-------------+
| | | | | | | | | | | | | | | |
| - L2VPN | | - L2VPN | | EVPN | | L3VPN | | - L2VPN | | - L2VPN | | EVPN | | L3VPN |
| - VPWS | | - VPLS | | | | | | - VPWS | | - VPLS | | | | |
| | | | | | | | | | | | | | | |
+------------+ +-------------+ +-------------+ +-------------+ +------------+ +-------------+ +-------------+ +-------------+
skipping to change at page 13, line 51 skipping to change at page 14, line 10
VPWS: Virtual Private Wire Service VPWS: Virtual Private Wire Service
VPLS: Virtual Private LAN Service VPLS: Virtual Private LAN Service
Figure 4: YANG Module Layers Showing Service Models Figure 4: YANG Module Layers Showing Service Models
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 models related to
services. These models focus on how the network operator configures services. These models focus on how the network operator configures
the network through protocols and devices to deliver a service. Some the network through protocols and devices to deliver a service. Some
of these models are classed as service delivery models while others of these models are classified as service delivery models while
have details that are related to specific element configuration and others have details that are related to specific element
so are classed as network element models. 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 model that can be
used to configure and manage BGP Layer 3 VPNs. 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 YANG 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 models 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 most advanced presents the Layer Three Virtual Private models. The most advanced presents the L3VPN service as described by
Network (L3VPN) service as described by a network operator to a a network operator to a customer. The L3SM is described as in
customer. This L3VPN service model (L3SM) is documented in [RFC8049] Figure 5 which is reproduced from [RFC8049]. As can be seen, the
where its usage is described as in Figure 5 which is reproduced from L3SM is a customer service model as described in this document.
that document. As can be seen, the L3SM is a customer service model
as described in this document.
L3VPN-SVC | L3VPN-SVC |
MODEL | MODEL |
| |
+------------------+ +-----+ +------------------+ +-----+
| Orchestration | < --- > | OSS | | Orchestration | < --- > | OSS |
+------------------+ +-----+ +------------------+ +-----+
| | | |
+----------------+ | +----------------+ |
| Config manager | | | Config manager | |
skipping to change at page 17, line 5 skipping to change at page 17, line 50
The policies that express desired behavior of services on occurrence The policies that express desired behavior of services on occurrence
of specific events are close to SLA definitions: they should only be of specific events are close to SLA definitions: they should only be
included in the base service model where they are common to all included in the base service model where they are common to all
network operators' offerings. Policies that describe who at a network operators' offerings. Policies that describe who at a
customer may request or modify services (that is, authorization) are customer may request or modify services (that is, authorization) are
close to commercial terms: they, too, should only be included in the close to commercial terms: they, too, should only be included in the
base service model where they are common to all network operators' base service model where they are common to all network operators'
offerings. offerings.
As with commercial terms and SLAs discussed in Section 5 it is
expected that some network operators will enhance standard customer
service models to include policy parameters either using their own
work or depending on specific policy models built in the IETF or
other standards bodies.
Nevertheless, policy is so important that all service models should Nevertheless, policy is so important that all service models should
be designed to be easily extensible to allow policy components to be be designed to be easily extensible to allow policy components to be
added and associated with services as needed. added and associated with services as needed.
7.3. Operator-Specific Features 7.3. Operator-Specific Features
When work in the L3SM working group was started, there was some doubt When work on the L3SM was started, there was some doubt as to whether
as to whether network operators would be able to agree on a common network operators would be able to agree on a common description of
description of the services that they offer to their customers the services that they offer to their customers because, in a
because, in a competitive environment, each markets the services in a competitive environment, each markets the services in a different way
different way with different additional features. However, the with different additional features. However, the working group was
working group was able to agree on a core set of features that able to agree on a core set of features that multiple network
multiple network operators were willing to consider as "common". operators were willing to consider as "common". They also understood
They also understood that should an individual network operator want that should an individual network operator want to describe
to describe additional features (operator-specific features) they additional features (operator-specific features) they could do so by
could do so by extending or augmenting the L3SM model. extending or augmenting the L3SM model.
Thus, when a basic description of a core service is agreed and Thus, when a basic description of a core service is agreed and
documented in a service model, it is important that that model should documented in a service model, it is important that that model should
be easily extended or augmented by each network operator so that the be easily extended or augmented by each network operator so that the
standardized model can be used in a common way and only the operator- standardized model can be used in a common way and only the operator-
specific features varied from one environment to another. specific features varied from one environment to another.
7.4. Supporting Multiple Services 7.4. Supporting Multiple Services
Network operators will, in general, offer many different services to Network operators will, in general, offer many different services to
skipping to change at page 18, line 23 skipping to change at page 19, line 23
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.
This document discusses modeling that information, not how it is Equally, all external intefaces, such as any of those between the
functional components in Figure 3 needs to be correctly secured.
This document discusses modeling the information, not how it is
exchanged. 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.
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
and significant changes in traffic load within a network and that and significant changes in traffic load within a network and that
that might have an effect on other services carried in a network. that might have an effect on other services carried in a network.
It is expected, therefore, that a Service Orchestration component has It is expected, therefore, that a Service Orchestration component has
awareness of other service commitments, that the Network awareness of other service commitments, that the Network
Orchestration component will not commit network resources to fulfill Orchestration component will not commit network resources to fulfill
a service unless doing so is appropriate, and that a feedback loop a service unless doing so is appropriate, and that a feedback loop
will be provided to report on degradation of the network that will will be provided to report on degradation of the network that will
impact the service. impact the service.
The operational state of a service does not form part of a customer The operational state of a service does not form part of a customer
service model. However, it is likely that a network operator may service model. However, it is likely that a network operator may
want to report some state information about various components of the want to report some state information about various components of the
service, and that could be achieved through extensions to the core service, and that could be achieved through extensions to the core
service model. service model just as SLA extensions could be made as described in
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, and Michael Scharf for useful Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair, and
review and comments. Med Boucadair gave thoughtful and detailed Luis Miguel Contreras Murillo for useful review and comments.
comments on version -04 of this document. Thanks to Dean Bogdanovic
and Tianran Zhou for their help coordinating with [I-D.ietf-netmod-
yang-model-classification].
Many thanksto Jerry Bonner for spotting a tiny, one-word, but Thanks to Dean Bogdanovic, Tianran Zhou, and Carl Moberg for their
help coordinating with [RFC8199].
Many thanks to Jerry Bonner for spotting a tiny, one-word, but
critical typo. critical typo.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-netmod-yang-model-classification]
Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
Classification", draft-ietf-netmod-yang-model-
classification-08 (work in progress), June 2017.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3444>. editor.org/info/rfc3444>.
[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, <http://www.rfc-editor.org/info/rfc7426>.
[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
Model for L3VPN Service Delivery", RFC 8049, Classification", RFC 8199, DOI 10.17487/RFC8199, July
DOI 10.17487/RFC8049, February 2017, 2017, <https://www.rfc-editor.org/info/rfc8199>.
<http://www.rfc-editor.org/info/rfc8049>.
12.2. Informative References 12.2. Informative References
[I-D.dhjain-bess-bgp-l3vpn-yang] [I-D.dhjain-bess-bgp-l3vpn-yang]
Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S.,
Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model
for BGP/MPLS L3 VPNs", draft-dhjain-bess-bgp-l3vpn-yang-02 for BGP/MPLS L3 VPNs", draft-dhjain-bess-bgp-l3vpn-yang-02
(work in progress), August 2016. (work in progress), August 2016.
[I-D.ietf-bess-evpn-yang] [I-D.ietf-bess-evpn-yang]
Brissette, P., Sajassi, A., Shah, H., Li, Z., Brissette, P., Sajassi, A., Shah, H., Li, Z.,
Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data
Model for EVPN", draft-ietf-bess-evpn-yang-02 (work in Model for EVPN", draft-ietf-bess-evpn-yang-02 (work in
progress), March 2017. progress), March 2017.
[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-05 (work in progress), L2VPN", draft-ietf-bess-l2vpn-yang-06 (work in progress),
March 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-01 (work in progress), May 2017. service-model-02 (work in progress), July 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-
<http://www.rfc-editor.org/info/rfc6020>. editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <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 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>. <https://www.rfc-editor.org/info/rfc7223>.
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
Connectivity Provisioning Profile (CPP)", RFC 7297, Connectivity Provisioning Profile (CPP)", RFC 7297,
DOI 10.17487/RFC7297, July 2014, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7297>. editor.org/info/rfc7297>.
[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
December 2014, <http://www.rfc-editor.org/info/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 [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-
<http://www.rfc-editor.org/info/rfc7491>. editor.org/info/rfc7491>.
[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,
<http://www.rfc-editor.org/info/rfc8040>. <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>.
Authors' Addresses Authors' Addresses
Qin Wu Qin Wu
Huawei Technologies Huawei Technologies
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
Will Liu Will Liu
Huawei Technologies Huawei Technologies
 End of changes. 56 change blocks. 
174 lines changed or deleted 200 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/