draft-ietf-opsawg-service-model-explained-04.txt   draft-ietf-opsawg-service-model-explained-05.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 31, 2018 A. Farrel Expires: April 15, 2018 A. Farrel
Juniper Networks Juniper Networks
September 27, 2017 October 12, 2017
Service Models Explained Service Models Explained
draft-ietf-opsawg-service-model-explained-04 draft-ietf-opsawg-service-model-explained-05
Abstract Abstract
The IETF has produced many modules in the YANG modeling language. The IETF has produced many modules in the YANG modeling language.
The majority of these modules are used to construct data models to The majority of these modules are used to construct data 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).
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 https://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 31, 2018. This Internet-Draft will expire on April 15, 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
(https://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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . 4 2. Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 4
3. Using Service Models . . . . . . . . . . . . . . . . . . . . 6 3. Using Service Models . . . . . . . . . . . . . . . . . . . . 6
3.1. Practical Considerations . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . 11
6. Comparison With Other Work . . . . . . . . . . . . . . . . . 12 6. Comparison With Other Work . . . . . . . . . . . . . . . . . 13
6.1. Comparison With Network Service Models . . . . . . . . . 12 6.1. Comparison With Network Service Models . . . . . . . . . 13
6.2. Service Delivery and Network Element Model Work . . . . . 14 6.2. Service Delivery and Network Element Model Work . . . . . 15
6.3. Customer Service Model Work . . . . . . . . . . . . . . . 14 6.3. Customer Service Model Work . . . . . . . . . . . . . . . 15
6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 16 6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 17
7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 17 7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 17 7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 18
7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 17 7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 18
7.3. Operator-Specific Features . . . . . . . . . . . . . . . 18 7.3. Operator-Specific Features . . . . . . . . . . . . . . . 19
7.4. Supporting Multiple Services . . . . . . . . . . . . . . 18 7.4. Supporting Multiple Services . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Manageability Considerations . . . . . . . . . . . . . . . . 19 9. Manageability Considerations . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
In recent years the number of modules written in the YANG modeling In recent years the number of modules written in the YANG modeling
language [RFC6020] for configuration and monitoring has blossomed. language [RFC6020] for configuration and monitoring has blossomed.
Many of these are used for device-level configuration (for example, Many of these are used for device-level configuration (for example,
[RFC7223]) or for control of monolithic functions or protocol [RFC7223]) or for control of monolithic functions or protocol
instances (for example, [RFC7407]). instances (for example, [RFC7407]).
[RFC7950] makes a distinction between a "data model" which it defines [RFC7950] makes a distinction between a "data model" which it defines
as describing how data is represented and accessed, and a "YANG as describing how data is represented and accessed, and a "YANG
module" that defines hierarchies of schema nodes to make a self- module" that defines hierarchies of schema nodes to make a self-
contained and compilable block of definitions and inclusions. YANG contained and compilable block of definitions and inclusions. YANG
structures data models into modules for ease of use. 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]
skipping to change at page 3, line 25 skipping to change at page 3, line 28
super controllers, domain controllers, and device controllers all super controllers, domain controllers, and device controllers all
exchanging information and instructions using YANG modules. 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 may be used 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 limited to within the scope of the IETF) and describes
operator. Equally, this document clarifies what a service model is how a service model can be used by a network operator. Equally, this
not, and dispels some common misconceptions. document clarifies what a service model is not, and dispels some
common misconceptions.
The document also shows where a service model might fit into an SDN 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 modules are engineered to deliver a service are captured in other modules
that are not exposed through the Customer-Provider Interface. that are not exposed through the interface betweeen the customer and
the provider.
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 modules has been done in [RFC8199]. Other work on classifying YANG modules has been done in [RFC8199].
That document provides an important reference for this document, and That document provides an important reference for this document, and
skipping to change at page 5, line 28 skipping to change at page 5, line 34
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 As mentioned in Section 1, this document also uses the terms "data
model" and "YANG module" as defined in [RFC7950]. 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 that can be used uniformly independent of the
categories: equipment and operating environment. The service model may be
divided into two 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 as shown in Figure 1. It can be used by a
interface such as a GUI, web form, or CLI) or by software to human (via a user interface such as a GUI, web form, or CLI) or
configure or request a service, and may equally be consumed by by software to configure or request a service, and may equally
a human (such as via an order fulfillment system) or by a be consumed by a human (such as via an order fulfillment
software component. Such models are sometimes referred to system) or by a software component. Such models are sometimes
simply as "service models" [RFC8049]. A customer service model referred to simply as "service models" [RFC8049]. A customer
is expressed in a YANG module as a core set of parameters that service model is expressed in a YANG module as a core set of
are common across network operators: additional features that parameters that are common across network operators: additional
are specific to the offerings of individual network operators features that are specific to the offerings of individual
would be defined in extensions or augmentations of the module. network operators would be defined in extensions or
Except where specific technology details (such as augmentations of the module. Except where specific technology
encapsulations, or mechanisms applied on access links) are details (such as encapsulations, or mechanisms applied on
directly pertinent to the customer, customer service models are access links) are directly pertinent to the customer, customer
technology agnostic so that the customer does not have service models are technology agnostic so that the customer
influence over or knowledge of how the network operator does not have influence over or knowledge of how the network
engineers the service. 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
skipping to change at page 6, line 30 skipping to change at page 6, line 37
models are sometimes referred to as "network service YANG models are sometimes referred to as "network service YANG
modules" [RFC8199] and are consumed by "external systems" such modules" [RFC8199] and are consumed by "external systems" such
as Operations Support System (OSS). A service delivery module as Operations Support System (OSS). A service delivery module
is expressed as a core set of parameters that are common across is expressed as a core set of parameters that are common across
a network type and technology: additional features that are a network type and technology: additional features that are
specific to the configuration of individual vendor equipment or specific to the configuration of individual vendor equipment or
proprietary protocols would be defined in extensions or proprietary protocols would be defined in extensions or
augmentations of the module. Service delivery modules include augmentations of the module. Service delivery modules include
technology-specific 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. The modules that encode a delivery model needs to be clarified. The modules that encode a
customer service model are not used to directly configure network customer service model are not used to directly configure network
devices, protocols, or functions: it is not something that is sent to devices, protocols, or functions: it is not something that is sent
network devices (i.e., routers or switches) for processing. Equally, to network devices (i.e., routers or switches) for processing.
the modules that encode a customer service model do not describes how Equally, the modules that encode a customer service model do not
a network operator realizes and delivers the service described by the describes how a network operator realizes and delivers the service
module. This distinction is discussed further in later sections. described by the 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].
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 internal API, while systems with more direct human might use an internal API, while systems with more direct human
interactions might use web pages or even paper forms. interactions might use web pages or even paper forms. Where direct
human interaction comes into play, interface interactions may be
realized via business practices and that may introduce some margin of
error, thus raising the priority for automated, deterministic
interfaces.
-------------- 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 40 skipping to change at page 8, line 5
request into configuration and operational parameters that control request into configuration and operational parameters that control
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.
3.1. Practical Considerations
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 radically debated. It has been suggested that network operators have radically
different business modes and widely diverse commercial offerings different business modes and widely diverse commercial offerings
making a common customer service model is impractical. However, the making a common customer service model is impractical. However, the
L3SM [RFC8049] results from the consensus of multiple individuals L3SM [RFC8049] results from the consensus of multiple individuals
working at network operators and offers a common core of service working at network operators and offers a common core of service
options that can be augmented according to the needs of individual options that can be augmented according to the needs of 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
skipping to change at page 8, line 15 skipping to change at page 8, line 29
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
re-use in multiple models. re-use in multiple models.
4. Service Models in an SDN Context 4. Service Models in an SDN Context
In an SDN system, the management of network resources and protocols In a Software Defined Networking (SDN) system, the management of
is performed by software systems that determine how best to utilize network resources and protocols is performed by software systems that
the network. Figure 2 shows a sample architectural view of an SDN determine how best to utilize the network. Figure 2 shows a sample
system where network elements are programmed by a component called an architectural view of an SDN system where network elements are
"SDN controller" (or "controller" for short), and where controllers programmed by a component called an "SDN controller" (or "controller"
are instructed by an orchestrator that has a wider view of the whole for short), and where controllers are instructed by an orchestrator
of, or part of, a network. The internal organization of an SDN that has a wider view of the whole of, or part of, a network. The
control plane is deployment-specific. internal organization of an SDN control plane is deployment-specific.
------------------ ------------------
| | | |
| Orchestrator | | Orchestrator |
| | | |
.------------------. .------------------.
. : . . : .
. : . . : .
------------ ------------ ------------ ------------ ------------ ------------
| | | | | | | | | | | |
skipping to change at page 8, line 46 skipping to change at page 9, line 27
: . . : : . . :
: . . : : . . :
: . . : : . . :
--------- --------- --------- --------- --------- --------- --------- ---------
| 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- A customer's service request is (or should be) technology-agnostic.
agnostic. That is, the technology that the network operator has That is, a customer is unware of the technology that the network
available to deliver the service should not influence the behavior operator has available to deliver the service and so the customer
and functions that a customer requests. The orchestrator must map does not make requests specific to the underlying technology, but is
the service request to its view, and this mapping may include a limited to making requests specific to the service that is to be
choice of which networks and technologies to use depending on which delivered. The orchestrator must map the service request to its
service features have been requested. view, and this mapping may include a choice of which networks and
technologies to use depending on which service features have been
requested.
One implementation option to achieve this mapping is to split the 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) | |
skipping to change at page 10, line 7 skipping to change at page 10, line 46
: . . 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. The Device Confguration Models are used by within the architecture. The Device Confguration Models are used by
a Controller to seet parameters on an individual network element. a Controller to set parameters on an individual network element. The
The Network Configuration Models are use by a Network Orchestrator to Network Configuration Models are use by a Network Orchestrator to
instruct Controllers (that may each be responsible for multiple instruct Controllers (that may each be responsible for multiple
network elements) how to configure parts of a network. 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" that 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
skipping to change at page 11, line 9 skipping to change at page 11, line 51
network resources of the operator's network. This is a completely network resources of the operator's network. This is a completely
different thing to "Foo as a Service" (for example, Storage as a different thing to "Foo as a Service" (for example, Storage as a
Service (SaaS)) where a service provider offers reachability to a Service (SaaS)) where a service provider offers reachability to a
value-added service that is provided at some location in the value-added service that is provided at some location in the
network using other resources (compute, storage, ...) that are not network using other resources (compute, storage, ...) that are not
part of the network itself. The confusion arises not only because part of the network itself. The confusion arises not only because
of the use of the word "service" in both cases, but also because of the use of the word "service" in both cases, but also because
network operators may offer both types of service to their network operators may offer both types of service to their
customers. customers.
o Network operation is completely out of scope in the discussion of o Network operation is normally 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, nor
model does not expose details of technology or network resources does the model expose details of technology or network resources
used to provide the service. For example, in the simple case of used to provide the service (all of these details could, in any
point-to-point virtual link connectivity provided by a network case, be considered seecurity vulnerabilities. For example, in
tunnel (such as an MPLS pseudowire) the network operator does not the simple case of point-to-point virtual link connectivity
expose the path through the network that the tunnel follows. Of provided by a network tunnel (such as an MPLS pseudowire) the
course, this does not preclude the network operator from taking network operator does not expose the path through the network that
guidance from the customer (such as to avoid routing traffic the tunnel follows. Of course, this does not preclude the network
through a particular country) or from disclosing specific details operator from taking guidance from the customer (such as to avoid
(such as might be revealed by a route trace), but these are not routing traffic through a particular country) or from disclosing
standard features of the service as described in the customer specific details (such as might be revealed by a route trace), but
service model. these are not standard features of the service as described in the
customer service model.
o The network operator may use further data models (service delivery 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" and encode them as "Network Service models as "service models" and encode them as "Network Service
YANG Modules" and a comparison is provided in Section 6.1. It is YANG Modules" and a comparison is provided in Section 6.1. It is
important that the Service Orchestrator should be able to map from important that the Service Orchestrator should be able to map from
a customer service model to these service delivery models, but a customer service model to these service delivery models, but
they are not the same things. they are not the same things.
o Commercial terms are generally not a good subject for o Commercial terms (such as cost per byte, per minute, scoped by
standardization. It is possible that some network operators will quality and type of service, and related to payment terms) are
enhance standard customer service models to include commercial generally not a good subject for standardization. It is possible
information, but the way this is done is likely to vary widely that some network operators will enhance standard customer service
between network operators. Thus, this feature is out of scope for models to include commercial information, but the way this is done
standardized customer service models. is likely to vary widely between network operators. Thus, this
feature is out of scope for standardized customer service models.
o Service Level Agreements (SLAs) have a high degree of overlap with 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 thus are also not good topics for with penalties and so forth, and thus are also not good topics for
skipping to change at page 16, line 45 skipping to change at page 17, line 45
6.4. The MEF Architecture 6.4. The MEF Architecture
The MEF Forum has developed an architecture for network management The MEF Forum has developed an architecture for network management
and operation. It is documented as the Lifecycle Service and operation. It is documented as the Lifecycle Service
Orchestration (LSO) Reference Architecture and illustrated in Orchestration (LSO) Reference Architecture and illustrated in
Figure 2 of [MEF-55]. Figure 2 of [MEF-55].
The work of the MEF Forum embraces all aspects of Lifecycle Service The work of the MEF Forum embraces all aspects of Lifecycle Service
Orchestration including billing, SLAs, order management, and life- Orchestration including billing, SLAs, order management, and life-
cycle management. The IETF's work on service models is typically cycle management. The IETF's work on service models is typically
smaller offering a simple, self-contained service YANG module. Thus, smaller offering a simple, self-contained service YANG module. This
it may be impractical to fit IETF service models into the MEF Forum does not invalidate either approach: it only observes that they are
LSO architecture. This does not invalidate either approach: it only different approaches.
observes that they are different approaches.
7. Further Concepts 7. Further Concepts
This section introduces a few further, more advanced concepts This section introduces a few further, more advanced concepts
7.1. Technology Agnostic 7.1. Technology Agnostic
Service models should generally be technology agnostic. That is to Service models should generally be technology agnostic. That is to
say, the customer should not care how the service is provided so long say, the customer should not care how the service is provided so long
as the service is delivered. as the service is delivered.
skipping to change at page 20, line 20 skipping to change at page 21, line 20
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, Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair,
Luis Miguel Contreras Murillo, Joe Salowey, Benoit Claise, Robert Luis Miguel Contreras Murillo, Joe Salowey, Benoit Claise, Robert
Sparks, and Tom Petch for useful review and comments. Sparks, Tom Petch, David Sinicrope, and Deborah Brungard 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 14 skipping to change at page 22, line 14
[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-06 (work in progress), L2VPN", draft-ietf-bess-l2vpn-yang-07 (work in progress),
June 2017. October 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-03 (work in progress), September 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.
 End of changes. 25 change blocks. 
100 lines changed or deleted 116 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/