draft-ietf-opsawg-service-model-explained-05.txt   rfc8309.txt 
OPS Area Working Group Q. Wu Internet Engineering Task Force (IETF) Q. Wu
Internet-Draft W. Liu Request for Comments: 8309 W. Liu
Intended status: Informational Huawei Technologies Category: Informational Huawei Technologies
Expires: April 15, 2018 A. Farrel ISSN: 2070-1721 A. Farrel
Juniper Networks Juniper Networks
October 12, 2017 January 2018
Service Models Explained Service Models Explained
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 3 Virtual Private Network Service Model
produced by the L3SM working group and documented in RFC 8049). (L3SM) produced by the L3SM working group and documented in RFC
8049).
This document describes service models as used within the IETF, and This document describes service models as used within the IETF and
also shows where a service model might fit into a Software Defined also shows where a service model might fit into a software-defined
Networking architecture. Note that service models do not make any networking architecture. Note that service models do not make any
assumption of how a service is actually engineered and delivered for assumption of how a service is actually engineered and delivered for
a customer; details of how network protocols and devices are a customer; details of how network protocols and devices are
engineered to deliver a service are captured in other modules that engineered to deliver a service are captured in other modules that
are not exposed through the Customer-Provider Interface. are not exposed through the interface between the customer and the
provider.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on April 15, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8309.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 4 2. Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 4
3. Using Service Models . . . . . . . . . . . . . . . . . . . . 6 3. Using Service Models . . . . . . . . . . . . . . . . . . . . 7
3.1. Practical Considerations . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . 11 5. Possible Causes of Confusion . . . . . . . . . . . . . . . . 11
6. Comparison With Other Work . . . . . . . . . . . . . . . . . 13 6. Comparison with Other Work . . . . . . . . . . . . . . . . . 13
6.1. Comparison With Network Service Models . . . . . . . . . 13 6.1. Comparison with Network Service Models . . . . . . . . . 13
6.2. Service Delivery and Network Element Model Work . . . . . 15 6.2. Service Delivery and Network Element Model Work . . . . . 15
6.3. Customer Service Model Work . . . . . . . . . . . . . . . 15 6.3. Customer Service Model Work . . . . . . . . . . . . . . . 16
6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 17 6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 17
7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 18 7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 18 7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 18
7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 18 7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 18
7.3. Operator-Specific Features . . . . . . . . . . . . . . . 19 7.3. Operator-Specific Features . . . . . . . . . . . . . . . 19
7.4. Supporting Multiple Services . . . . . . . . . . . . . . 19 7.4. Supporting Multiple Services . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Manageability Considerations . . . . . . . . . . . . . . . . 20 9. Manageability Considerations . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 21 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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
as describing how data is represented and accessed, and a "YANG defines as describing how data is represented and accessed, and a
module" that defines hierarchies of schema nodes to make a self- "YANG module", which defines hierarchies of schema nodes to make a
contained and compilable block of definitions and inclusions. YANG self-contained and compilable block of definitions and inclusions.
structures data models into modules for ease of use. YANG structures data models into modules for ease of use.
Within the context of Software Defined Networking (SDN) [RFC7149] Within the context of Software-Defined Networking (SDN) [RFC7149]
[RFC7426], YANG data modules may be used on the interface between a [RFC7426], YANG data modules may be used on the interface between a
controller and network devices, and between network orchestrators and controller and network devices, as well as between network
controllers. There may also be a hierarchy of such components with orchestrators and controllers. There may also be a hierarchy of such
super controllers, domain controllers, and device controllers all components with super controllers, domain controllers, and device
exchanging information and instructions using YANG modules. controllers all 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 3
Three Virtual Private Network Service Model (L3SM) [RFC8049]. Such Virtual Private Network Service Model (L3SM) [RFC8049]. Such models
models may be used in manual and even paper-driven service request may be used in manual and even paper-driven service request processes
processes with a gradual transition to IT-based mechanisms. with a gradual transition to IT-based mechanisms. Ultimately, they
Ultimately they could be used in online, software-driven dynamic could be used in online, software-driven dynamic systems and may be
systems, and may be used as part of an SDN system. 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 limited to within the scope of the IETF) and describes the IETF (and is limited to within the scope of the IETF) and
how a service model can be used by a network operator. Equally, this describes how a service model can be used by a network operator.
document clarifies what a service model is not, and dispels some Equally, this document clarifies what a service model is not and
common misconceptions. 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 interface betweeen the customer and that are not exposed through the interface between the customer and
the provider. 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
also uses the term "service module". Section 6.1 in this document also uses the term "service module". In this document, Section 6.1
provides a comparison between these two uses of the same terminology. provides a comparison between these two uses of the 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 modules provided in [RFC8199]. classification of YANG modules provided in [RFC8199].
The following terms are used in this document: The following terms are used in this document:
Network Operator: This term is used to refer to the company that Network Operator: This term is used to refer to the company that
skipping to change at page 4, line 37 skipping to change at page 5, line 8
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,
but some companies may operate with internal customers so that, but some companies may operate with internal customers so that,
for example, an IP/MPLS packet network may be the customer of an for example, an IP/MPLS packet network may be the customer of an
optical transport network. optical transport network.
Service: A network operator delivers one or more services to a Service: A network operator delivers one or more services to a
customer. A service in the context of this document (sometimes customer. A service in the context of this document (sometimes
called a Network Service) is some form of connectivity between called a Network Service) is some form of connectivity between
customer sites and the Internet, or between customer sites across customer sites and the Internet or between customer sites across
the network operator's network and across the Internet. However, the network operator's network and across the Internet. However,
a distinction should be drawn between the parameters that describe a distinction should be drawn between the parameters that describe
a service as included in a customer service model (see the a service as included in a customer service model (see the
definition of this term, below) and a Service Level Agreement definition of this term, below) and a Service Level Agreement
(SLA) as discussed in Section 5 and Section 7.2. (SLA), as discussed in Sections 5 and 7.2.
A service may be limited to simple connectivity (such as IP-based A service may be limited to simple connectivity (such as IP-based
Internet access), may be a tunnel (such as a virtual circuit), or Internet access), may be a tunnel (such as a virtual circuit), or
may involve more complex connectivity (such as in a multi-site may involve more complex connectivity (such as in a multisite
virtual private network). Services may be further enhanced by virtual private network). Services may be further enhanced by
additional functions providing security, load-balancing, additional functions providing security, load balancing,
accounting, and so forth. Additionally, services usually include accounting, and so forth. Additionally, services usually include
guarantees of quality, throughput, and fault reporting. guarantees of quality, throughput, and fault reporting.
This document makes a distinction between a service as delivered This document makes a distinction between a service as delivered
to a customer (that is, the service as discussed on the interface to a customer (that is, the service as discussed on the interface
between a customer and the network operator) and the service as between a customer and the network operator) and the service as
realized within the network (as described in [RFC8199]). This realized within the network (as described in [RFC8199]). This
distinction is discussed further in Section 6. distinction is discussed further in Section 6.
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 information model (IM) and data model (DM) concepts
described in [RFC3444]. That document defines a data model by are described in [RFC3444]. That document defines a data model by
contrasting it with the definition of an information model as contrasting it with the definition of an IM as follows:
follows:
The main purpose of an information model is to model managed The main purpose of an IM is to model managed objects at a
objects at a conceptual level, independent of any specific conceptual level, independent of any specific implementations
implementations or protocols used to transport the data. The or protocols used to transport the data. The degree of
degree of specificity (or detail) of the abstractions defined specificity (or detail) of the abstractions defined in the IM
in the information model depends on the modeling needs of its depends on the modeling needs of its designers. In order to
designers. In order to make the overall design as clear as make the overall design as clear as possible, an IM should hide
possible, an information model should hide all protocol and all protocol and implementation details. Another important
implementation details. Another important characteristic of an characteristic of an IM is that it defines relationships
information model is that it defines relationships between between managed objects.
managed objects.
Data models, conversely, are defined at a lower level of DMs, conversely, are defined at a lower level of abstraction
abstraction and include many details. They are intended for and include many details. They are intended for implementors
implementors and include protocol-specific constructs. 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 that can be used uniformly independent of the portable way that can be used uniformly and independent of the
equipment and operating environment. The service model may be equipment and operating environment. The service model may be
divided into two categories: divided into the two following 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 as shown in Figure 1. It can be used by a network operator as shown in Figure 1. It can be used by a
human (via a user interface such as a GUI, web form, or CLI) or human (via a user interface such as a GUI, web form, or
by software to configure or request a service, and may equally Command-Line Interface (CLI)) or by software to configure or
be consumed by a human (such as via an order fulfillment request a service and may equally be consumed by a human (such
system) or by a software component. Such models are sometimes as via an order fulfillment system) or by a software component.
referred to simply as "service models" [RFC8049]. A customer Such models are sometimes referred to simply as "service
service model is expressed in a YANG module as a core set of models" [RFC8049]. A customer service model is expressed in a
parameters that are common across network operators: additional YANG module as a core set of parameters that are common across
features that are specific to the offerings of individual network operators: additional features that are specific to the
network operators would be defined in extensions or offerings of individual network operators would be defined in
augmentations of the module. Except where specific technology extensions or augmentations of the module. Except where
details (such as encapsulations, or mechanisms applied on specific technology details are directly pertinent to the
access links) are directly pertinent to the customer, customer customer (such as encapsulations or mechanisms applied on
service models are technology agnostic so that the customer access links), customer service models are technology agnostic
does not have influence over or knowledge of how the network so that the customer does not have influence over or knowledge
operator engineers the service. of how the network operator engineers the service.
An example of where such details are relevant to the customer An example of where such details are relevant to the customer
is when they describe the behavior or interactions on the is when they describe the behavior or interactions on the
interface between the equipment at the customer site (often interface between the equipment at the customer site (often
referred to as the Customer Edge or CE equipment) and the referred to as the Customer Edge or CE equipment) and the
equipment at the network operator's site (usually referred to equipment at the network operator's site (usually referred to
as the Provider Edge or PE equipment). as the Provider Edge or PE equipment).
Service Delivery Model: A service delivery model is used by a Service Delivery Model: A service delivery model is used by a
network operator to define and manage how a service is network operator to define and manage how a service is
engineered in the network. It can be used by a human operator engineered in the network. It can be used by a human operator
(such as via a management station) or by a software tool to (such as via a management station) or by a software tool to
instruct network components. The YANG modules that encode such instruct network components. The YANG modules that encode such
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 an Operations Support System (OSS). A service delivery
is expressed as a core set of parameters that are common across module is expressed as a core set of parameters that are common
a network type and technology: additional features that are across a network type and technology: additional features that
specific to the configuration of individual vendor equipment or are specific to the configuration of individual vendor
proprietary protocols would be defined in extensions or equipment or proprietary protocols would be defined in
augmentations of the module. Service delivery modules include extensions or augmentations of the module. Service delivery
technology-specific modules. modules include 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 devices, protocols, or functions: it is not something that is sent
to network devices (i.e., routers or switches) for processing. to network devices (i.e., routers or switches) for processing.
Equally, the modules that encode a customer service model do not Equally, the modules that encode a customer service model do not
describes how a network operator realizes and delivers the service describe how a network operator realizes and delivers the service
described by the module. This distinction is discussed further in described by the module. This distinction is discussed further in
later sections. 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 in
simply in Figure 1. 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 the customer and network operator is specific
and implementation-specific. The IETF has standardized the NETCONF to deployment and implementation. The IETF has standardized the
protocol [RFC6241] and the RESTCONF protocol [RFC8040] for NETCONF 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. Where direct interactions might use web pages or even paper forms. Where direct
human interaction comes into play, interface interactions may be human interaction comes into play, interface interactions may be
realized via business practices and that may introduce some margin of realized via business practices that may introduce some margin of
error, thus raising the priority for automated, deterministic error, thus raising the priority for automated, deterministic
interfaces. 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
How a network operator processes a customer's service request How a network operator processes a customer's service request when
described with a customer service model depends on the commercial and described with a customer service model depends on the commercial and
operational tools, processes, and policies used by the network operational tools, processes, and policies used by the network
operator. These may vary considerably from one network operator to operator. These may vary considerably from one network operator to
another. another.
However, the intent is that the network operator maps the service However, the intent is that the network operator maps the service
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 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 models and widely diverse commercial offerings,
making a common customer service model is impractical. However, the which makes a common customer service model impractical. However,
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
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
re-use in multiple models. for reuse in multiple models.
4. Service Models in an SDN Context 4. Service Models in an SDN Context
In a Software Defined Networking (SDN) system, the management of In an SDN system, the management of network resources and protocols
network resources and protocols is performed by software systems that is performed by software systems that determine how best to utilize
determine how best to utilize the network. Figure 2 shows a sample the network. Figure 2 shows a sample architectural view of an SDN
architectural view of an SDN system where network elements are system where network elements are programmed by a component called an
programmed by a component called an "SDN controller" (or "controller" "SDN controller" (or "controller" for short) and where controllers
for short), and where controllers are instructed by an orchestrator are instructed by an orchestrator that has a wider view of the whole
that has a wider view of the whole of, or part of, a network. The of, or part of, a network. The internal organization of an SDN
internal organization of an SDN control plane is deployment-specific. control plane is specific to deployment.
------------------ ------------------
| | | |
| Orchestrator | | Orchestrator |
| | | |
.------------------. .------------------.
. : . . : .
. : . . : .
------------ ------------ ------------ ------------ ------------ ------------
| | | | | | | | | | | |
skipping to change at page 9, line 27 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
A customer's service request is (or should be) technology-agnostic. A customer's service request is (or should be) technology agnostic.
That is, a customer is unware of the technology that the network That is, a customer is unaware of the technology that the network
operator has available to deliver the service and so the customer operator has available to deliver the service, so the customer does
does not make requests specific to the underlying technology, but is not make requests specific to the underlying technology but is
limited to making requests specific to the service that is to be limited to making requests specific to the service that is to be
delivered. The orchestrator must map the service request to its delivered. The orchestrator must map the service request to its
view, and this mapping may include a choice of which networks and view, and this mapping may include a choice of which networks and
technologies to use depending on which service features have been technologies to 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.
skipping to change at page 10, line 45 skipping to change at page 10, line 45
: . . Configuration : : : . . Configuration : :
: . . Model : : : . . Model : :
--------- --------- --------- --------- --------- --------- --------- --------- --------- ---------
| Network | | Network | | Network | | Network | | Network | | Network | | Network | | Network | | Network | | Network |
| Element | | Element | | Element | | Element | | Element | | Element | | Element | | Element | | Element | | Element |
--------- --------- --------- --------- --------- --------- --------- --------- --------- ---------
Figure 3: An Example SDN Architecture with a Service Orchestrator Figure 3: An Example SDN Architecture with a Service Orchestrator
Figure 3 also shows where different data models might be applied Figure 3 also shows where different data models might be applied
within the architecture. The Device Confguration Models are used by within the architecture. The device configuration models are used by
a Controller to set parameters on an individual network element. The a controller to set parameters on an individual network element. The
Network Configuration Models are use by a Network Orchestrator to network configuration models are used by a network orchestrator to
instruct Controllers (that may each be responsible for multiple instruct controllers (which 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 following examples illustrate the split between control
interface" that is present in many figures showing extended SDN components that expose a "service interface" that is present in many
architectures: figures that show extended SDN architectures:
o Figure 1 of [RFC7426] shows a separation of the "Application o Figure 1 of [RFC7426] shows a separation of the "Application
Plane", the "Network Services Abstraction Layer (NSAL)", and the Plane", the "Network Services Abstraction Layer (NSAL)", and the
"Control Plane". It marks the "Service Interface" as situated "Control Plane". It marks the "Service Interface" as situated
between the NSAL and the control plane. between the NSAL and the control plane.
o Figure 1 of [RFC7491] shows an interface between an "Application o Figure 1 of [RFC7491] shows an interface between an "Application
Service Coordinator" and an "Application-Based Network Operations Service Coordinator" and an "Application-Based Network Operations
Controller". Controller".
o Figure 1 of [RFC8199] shows an interface from an OSS or a Business o Figure 1 of [RFC8199] shows an interface from an OSS or a Business
Support System (BSS) that is expressed in "Network Service YANG Support System (BSS) that is expressed in "Network Service YANG
Modules". Modules".
This can all lead to some confusion around the definition of a This can all lead to some confusion around the definition of a
"service interface" and a "service model". Some previous literature "service interface" and a "service model". Some previous literature
considers the interface northbound of the Network Orchestrator considers the interface northbound of the network orchestrator
(labeled "(b)" in Figure 3) to be a "service interface" used by an (labeled "(b)" in Figure 3) to be a "service interface" used by an
application, but the service described at this interface is network- application, but the service described at this interface is network
centric and is aware of many features such as topology, technology, centric and is aware of many features, such as topology, technology,
and operator policy. Thus, we make a distinction between this type and operator policy. Thus, we make a distinction between this type
of service interface and the more abstract service interface (labeled of service interface and the more abstract service interface (labeled
"(a)" in Figure 3) where the service is described by a service model "(a)" in Figure 3) where the service is described by a service model
and the interaction is between customer and network operator. and the interaction is between the customer and network operator.
Further discussion of this point is provided in Section 5. Further discussion of this point is provided in Section 5.
5. Possible Causes of Confusion 5. Possible Causes of Confusion
In discussing service models, there are several possible causes of In discussing service models, there are several possible causes of
confusion: confusion:
o The services we are discussing are connectivity services provided o The services we are discussing are connectivity services provided
by network operators to customers achieved by manipulating the by network operators to customers; the services are achieved by
network resources of the operator's network. This is a completely manipulating the network resources of the operator's network.
different thing to "Foo as a Service" (for example, Storage as a This is a completely different thing to "Foo as a Service" (for
Service (SaaS)) where a service provider offers reachability to a example, Storage as a Service (SaaS)) where a service provider
value-added service that is provided at some location in the offers reachability to a value-added service that is provided at
network using other resources (compute, storage, ...) that are not some location in the network using other resources (compute,
part of the network itself. The confusion arises not only because storage, ...) that are not part of the network itself. The
of the use of the word "service" in both cases, but also because confusion arises not only because of the use of the word "service"
network operators may offer both types of service to their in both cases, but also because network operators may offer both
customers. types of service to their customers.
o Network operation is normally 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, nor anything about how the network operator delivers the service, nor
does the model expose details of technology or network resources does the model expose details of technology or network resources
used to provide the service (all of these details could, in any used to provide the service (all of these details could, in any
case, be considered seecurity vulnerabilities. For example, in case, be considered security vulnerabilities). For example, in
the simple case of point-to-point virtual link connectivity the simple case of point-to-point virtual link connectivity
provided by a network tunnel (such as an MPLS pseudowire) the provided by a network tunnel (such as an MPLS pseudowire), the
network operator does not expose the path through the network that network operator does not expose the path through the network that
the tunnel follows. Of course, this does not preclude the network the tunnel follows. Of course, this does not preclude the network
operator from taking guidance from the customer (such as to avoid operator from taking guidance from the customer (such as to avoid
routing traffic through a particular country) or from disclosing routing traffic through a particular country) or from disclosing
specific details (such as might be revealed by a route trace), but specific details (such as might be revealed by a route trace), but
these are not standard features of the service as described in the these are not standard features of the service as described in the
customer service model. 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 encodes them as "Network Service
YANG Modules" and a comparison is provided in Section 6.1. It is YANG Modules"; 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 be able to map from a
a customer service model to these service delivery models, but customer service model to these service delivery models, but they
they are not the same things. are not the same thing.
o Commercial terms (such as cost per byte, per minute, scoped by o Commercial terms (such as "cost per byte", "cost per minute", and
quality and type of service, and related to payment terms) are "scoped by quality and type of service", as well as terms related
generally not a good subject for standardization. It is possible to payment) are generally not a good subject for standardization.
that some network operators will enhance standard customer service It is possible that some network operators will enhance standard
models to include commercial information, but the way this is done customer service models to include commercial information, but the
is likely to vary widely between network operators. Thus, this way this is done is likely to vary widely between network
feature is out of scope for standardized customer service models. 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 SLAs have a high degree of overlap with the definition of services
the definition of services present in customer service models. present in customer service models. Requests for specific
Requests for specific bandwidth, for example, might be present in bandwidth, for example, might be present in a customer service
a customer service model, and agreement to deliver a service is a model, and agreement to deliver a service is a commitment to the
commitment to the description of the service in the customer description of the service in the customer service model.
service model. However, SLAs typically include a number of fine- However, SLAs typically include a number of fine-grained details
grained details about how services are allowed to vary, by how about how services are allowed to vary, by how much, and how
much, and how often. SLAs are also linked to commercial terms often. SLAs are also linked to commercial terms with penalties
with penalties and so forth, and thus are also not good topics for and so forth and thus are also not good topics for
standardization. As with commercial terms, it is expected that standardization. As with commercial terms, it is expected that
some network operators will enhance standard customer service some network operators will enhance standard customer service
models to include SLA parameters either using their own work or models to include SLA parameters either using their own work or
depending on material from standards bodies that specialize in depending on material from standards bodies that specialize in
this topic, but this feature is out of scope for the IETF's this topic, but this feature is out of scope for the IETF's
customer service models. customer service models.
If a network operator chooses to express an SLA using a data If a network operator chooses to express an SLA using a data
model, that model might be referenced as an extension or an model, that model might be referenced as an extension or an
augmentation of the customer service model. augmentation of the customer service model.
6. Comparison With Other Work 6. Comparison with Other Work
Other work has classified YANG modules, produced parallel Other work has classified YANG modules, produced parallel
architectures, and developed a range of YANG modules. This section architectures, and developed a range of YANG modules. This section
briefly examines that other work and shows how it fits with the briefly examines that other work and shows how it fits with the
description of service models introduced in this document. description of service models introduced in this document.
6.1. Comparison With Network Service Models 6.1. Comparison with Network Service Models
As previously noted, [RFC8199] provides a classification of YANG As previously noted, [RFC8199] provides a classification of YANG
modules. It introduces the term "Network Service YANG Module" to modules. It introduces the term "Network Service YANG Module" to
identify the type of module used to "describe the configuration, identify the type of module used to "describe the configuration,
state data, operations and notifications of abstract representations state data, operations, and notifications of abstract representations
of services implemented on one or multiple network elements." These of services implemented on one or multiple network elements." These
modules are used to construct the service delivery models as modules are used to construct the service delivery models as
described in this document; that is, they are the modules used on the described in this document; that is, they are the modules used on the
interface between the Service Orchestrator or OSS/BSS and the Network interface between the service orchestrator or OSS/BSS and the network
Orchestrator as shown in Figure 3. orchestrator, as shown in Figure 3.
Figure 1 of [RFC8199] can be modified to make this more clear and to Figure 1 of [RFC8199] can be modified to make this more clear and to
add an additional example of a Network Service YANG module as shown include an additional example of a Network Service YANG module, as
in Figure 4. As can be seen, the highest classification of modules shown in Figure 4. As can be seen, the highest classification of
collects those that are used to deliver operations support and modules collects those that are used to deliver operations support
business support. These might be consumed by an Operations Support and business support. These might be consumed by an Operations
System (OSS) or a Business Support System (BSS), and a Service Support System (OSS) or a Business Support System (BSS), and a
Orchestrator may form part of an OSS/BSS or may be a separate service orchestrator may form part of an OSS/BSS or may be a separate
component. This highest layer in the figure is divided into the component. This highest layer in the figure is divided into the
Customer Service Modules that are used to describe services to a customer service modules that are used to describe services to a
customer as discussed in this document, and other modules that customer as discussed in this document, and other modules that
describe further OSS/BSS function such as billing and SLAs. describe further OSS/BSS functions such as billing and SLAs.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Operations Support and Business Support YANG Modules Operations Support and Business Support YANG Modules
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| | | | | | | |
| Customer Service | | Other | | Customer Service | | Other |
| YANG Modules | | Operations Support | | YANG Modules | | Operations Support |
| | | and | | | | and |
| +------+ +------+ | | Business Support | | +------+ +------+ | | Business Support |
skipping to change at page 14, line 49 skipping to change at page 14, line 49
Key: Key:
EVPN: Ethernet Virtual Private Network EVPN: Ethernet Virtual Private Network
L2SM: Layer 2 Virtual Private Network Service Model L2SM: Layer 2 Virtual Private Network Service Model
L2VPN: Layer 2 Virtual Private Network L2VPN: Layer 2 Virtual Private Network
L3SM: Layer 3 Virtual Private Network Service Model L3SM: Layer 3 Virtual Private Network Service Model
L3VPN: Layer 3 Virtual Private Network L3VPN: Layer 3 Virtual Private Network
VPLS: Virtual Private LAN Service VPLS: Virtual Private LAN Service
VPWS: Virtual Private Wire Service VPWS: Virtual Private Wire Service
Figure 4: YANG Module Abstaction Layers Showing Customer Service Figure 4: YANG Module Abstraction Layers Showing
Modules Customer Service Modules
6.2. Service Delivery and Network Element Model Work 6.2. Service Delivery and Network Element Model Work
A number of IETF working groups are developing YANG modules related A number of IETF working groups are developing YANG modules related
to services. These models focus on how the network operator to services. These models focus on how the network operator
configures the network through protocols and devices to deliver a configures the network through protocols and devices to deliver a
service. Some of these models are classified as network service service. Some of these models are classified as network service
delivery models (also called service delivery models or network delivery models (also called service delivery models or network
configuation models depending on the level at which they are configuration models depending on the level at which they are
pitched), while others have details that are related to specific pitched), while others have details that are related to specific
element configuration and so are classed as network element models element configuration and so are classed as network element models
(also called device 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 module that can be o [BGP-L3VPN-YANG] defines a YANG module that can be used to
used to configure and manage BGP L3VPNs. configure and manage BGP L3VPNs.
o [I-D.ietf-bess-l2vpn-yang] documents a data model that it is o [L2VPN-YANG] documents a data model that is expected to be used by
expected will be used by the management tools run by the network the management tools run by the network operators in order to
operators in order to manage and monitor the network resources manage and monitor the network resources that they use to deliver
that they use to deliver L2VPN services. L2VPN services.
o [I-D.ietf-bess-evpn-yang] defines YANG modules for delivering an o [EVPN-YANG] defines YANG modules for delivering an Ethernet VPN
Ethernet VPN service. service.
6.3. Customer Service Model Work 6.3. Customer Service Model Work
Several initiatives within the IETF are developing customer service Several initiatives within the IETF are developing customer service
models. The L3SM presents the L3VPN service as described by a models. The L3SM presents the L3VPN service, as described by a
network operator to a customer. Figure 5, which is reproduced from network operator, to a customer. Figure 5, which is reproduced from
[RFC8049], shows that the L3SM is a customer service model as [RFC8049], shows that the L3SM is a customer service model as
described in this document. described in this document.
L3VPN-SVC | L3VPN-SVC |
MODEL | MODEL |
| |
+------------------+ +-----+ +------------------+ +-----+
| Orchestration | < --- > | OSS | | Orchestration | < --- > | OSS |
+------------------+ +-----+ +------------------+ +-----+
| | | |
skipping to change at page 16, line 23 skipping to change at page 16, line 31
| Config manager | | | Config manager | |
+----------------+ | +----------------+ |
| | | |
| Netconf/CLI ... | Netconf/CLI ...
| | | |
+------------------------------------------------+ +------------------------------------------------+
Network Network
Figure 5: The L3SM Service Architecture Figure 5: The L3SM Service Architecture
A Layer Two VPN service model (L2SM) is defined in A Layer 2 VPN Service Model (L2SM) is defined in [L2VPN-SERVICE].
[I-D.ietf-l2sm-l2vpn-service-model]. That model's usage is described That model's usage is described as in Figure 6, which is a
as in Figure 6 which is a reproduction of Figure 5 from that reproduction of Figure 5 from that document. As can be seen, the
document. As can be seen, the L2SM is a customer service model as L2SM is a customer service model as described in this document.
described in this document.
---------------------------- ----------------------------
| Customer Service Requester | | Customer Service Requester |
---------------------------- ----------------------------
| |
L2VPN | L2VPN |
Service | Service |
Model | Model |
| |
----------------------- -----------------------
skipping to change at page 17, line 37 skipping to change at page 17, line 37
+----------------+ | Device +----------------+ | Device
| | Models | | Models
| | | |
-------------------------------------------- --------------------------------------------
Network Network
Figure 6: The L2SM Service Architecture Figure 6: The L2SM Service Architecture
6.4. The MEF Architecture 6.4. The MEF Architecture
The MEF Forum has developed an architecture for network management The MEF Forum (MEF) has developed an architecture for network
and operation. It is documented as the Lifecycle Service management and operation. It is documented as the Lifecycle Service
Orchestration (LSO) Reference Architecture and illustrated in Orchestration (LSO) Reference Architecture and is 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 embraces all aspects of Lifecycle Service
Orchestration including billing, SLAs, order management, and life- Orchestration, including billing, SLAs, order management, and
cycle management. The IETF's work on service models is typically lifecycle management. The IETF's work on service models is typically
smaller offering a simple, self-contained service YANG module. This smaller and offers a simple, self-contained service YANG module.
does not invalidate either approach: it only observes that they are This does not invalidate either approach: it only observes that they
different approaches. 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.
However, some technologies reach the customer site and make a However, some technologies reach to the customer site and impact the
difference to the type of service delivered. Such features do need type of service delivered. Such features do need to be described in
to be described in the service model. the service model.
Two examples are: Two examples are as follows:
o The data passed between customer equipment and network operator o The data passed between customer equipment and network operator
equipment will be encapsulated in a specific way, and that data equipment will be encapsulated in a specific way, and that data-
plane type forms part of the service. plane type forms part of the service.
o Protocols that are run between customer equipment and network o Protocols that are run between customer equipment and network
operator equipment (for example, Operations, Administration, and operator equipment (for example, Operations, Administration, and
Maintenance protocols, protocols for discovery, or protocols for Maintenance (OAM) protocols, protocols for discovery, or protocols
exchanging routing information) need to be selected and configured for exchanging routing information) need to be selected and
as part of the service description. configured as part of the service description.
7.2. Relationship to Policy 7.2. Relationship to Policy
Policy appears as a crucial function in many places during network Policy appears as a crucial function in many places during network
orchestration. A Service Orchestrator will, for example, apply the orchestration. A service orchestrator will, for example, apply the
network operator's policies to determine how to provide a service for network operator's policies to determine how to provide a service for
a particular customer (possibly considering commercial terms). a particular customer (possibly considering commercial terms).
However, the policies within a service model are limited to those However, the policies within a service model are limited to those
over which a customer has direct influence and that are acted on by over which a customer has direct influence and that are acted on by
the network operator. the network operator.
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 offerings of
network operators' offerings. Policies that describe who at a all network operators. Policies that describe which person working
customer may request or modify services (that is, authorization) are for a customer may request or modify services (that is,
close to commercial terms: they, too, should only be included in the authorization) are close to commercial terms: they, too, should only
base service model where they are common to all network operators' be included in the base service model where they are common offerings
offerings. of all network operators.
As with commercial terms and SLAs discussed in Section 5, it is As with commercial terms and SLAs discussed in Section 5, it is
expected that some network operators will enhance standard customer expected that some network operators will enhance standard customer
service models to include policy parameters either using their own service models to include policy parameters either using their own
work or depending on specific policy models built in the IETF or work or depending on specific policy models built in the IETF or
other standards bodies. 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.
skipping to change at page 19, line 24 skipping to change at page 19, line 24
network operators would be able to agree on a common description of network operators would be able to agree on a common description of
the services that they offer to their customers because, in a the services that they offer to their customers because, in a
competitive environment, each markets the services in a different way competitive environment, each markets the services in a different way
with different additional features. However, the working group was with different additional features. However, the working group was
able to agree on a core set of features that multiple network able to agree on a core set of features that multiple network
operators were willing to consider as "common". They also understood operators were willing to consider as "common". They also understood
that, should an individual network operator want to describe that, should an individual network operator want to describe
additional features (operator-specific features), they could do so by additional features (operator-specific features), they 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 upon and
documented in a service model, it is important that that model should documented in a service model, it is important that that model be
be easily extended or augmented by each network operator so that the 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 be 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
their customers. Each would normally be the subject of a separate their customers. Each would normally be the subject of a separate
service model. service model.
Whether each service model is handled by a specialized Service Whether each service model is handled by a specialized service
Orchestrator able to provide tuned behavior for a specific service or orchestrator that is able to provide tuned behavior for a specific
whether all service models are handled by a single Service service, or whether all service models are handled by a single
Orchestrator is an implementation and deployment choice. service orchestrator, is an implementation and deployment choice.
It is expected that, over time, certain elements of the service It is expected that, over time, certain elements of the service
models will be seen to repeat in each model. An example of such an models will be seen to repeat in each model. An example of such an
element is the postal address of the customer. element is the postal address of the customer.
It is anticipated that, while access to such information from each It is anticipated that, while access to such information from each
service model is important, the data will be described in its own service model is important, the data will be described in its own
module and may form part of the service model either by inclusion or module and may form part of the service model either by inclusion or
by index. by index.
8. Security Considerations 8. Security Considerations
The interface between customer and service provider is a commercial The interface between customer and service provider is a commercial
interface and needs to be subject to appropriate confidentiality. interface, and it needs to be subject to appropriate confidentiality.
Additionally, knowledge of what services are provided to a customer Additionally, knowledge of what services are provided to a customer
or delivered by a network operator may supply information that can be or delivered by a network operator may supply information that can be
used in a variety of security attacks. The service model itself will used in a variety of security attacks. The service model itself will
expose security-related parameters for the specific service where the expose security-related parameters for the specific service where the
related functon is available to the customer. related function is available to the customer.
Clearly, the ability to modify information exchanges between customer Clearly, the ability to modify information exchanges between customer
and network operator may result in bogus requests, unwarranted and network operator may result in bogus requests, unwarranted
billing, and false expectations. Furthermore, in an automated billing, and false expectations. Furthermore, in an automated
system, modifications to service requests or the injection of bogus system, modifications to service requests or the injection of bogus
requests may lead to attacks on the network and delivery of customer requests may lead to attacks on the network and delivery of customer
traffic to the wrong place. traffic to the wrong place.
Therefore it is important that the protocol interface used to Therefore, it is important that the protocol interface used to
exchange service request information between customer and network exchange service request information between customer and network
operator is subject to authorization, authentication, and encryption. operator is subject to authorization, authentication, and encryption.
Clearly, the level of abstraction provided by a service model Clearly, the level of abstraction provided by a service model
protects the operator from unwarranted visibility into their network, protects the operator from unwarranted visibility into their network,
and the fact that it is entirely up to the operator how they deliver and additional protection is provided by the fact that how the
the service provides additional protection. service is delivered is entirely up to the operator.
Equally, all external interfaces, such as any of those between the Equally, all external interfaces, such as any of those between the
functional components in Figure 3 needs to be correctly secured. functional components in Figure 3, need to be correctly secured.
This document discusses modeling the information, not how it is This document discusses modeling the information, not how it is
exchanged. exchanged.
9. Manageability Considerations 9. Manageability Considerations
This whole document discusses issues related to network management This whole document discusses issues related to network management
and control. and control.
It is important to observe that automated service provisioning It is important to observe that automated service provisioning
resulting from use of a customer service model may result in rapid resulting from use of a customer service model may result in rapid
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 just as SLA extensions could be made as described in service model, just as SLA extensions could be made as described in
Section 5. Section 5.
10. IANA Considerations 10. IANA Considerations
This document makes no requests for IANA action. This document does not require any IANA actions.
11. Acknowledgements
Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair,
Luis Miguel Contreras Murillo, Joe Salowey, Benoit Claise, Robert
Sparks, Tom Petch, David Sinicrope, and Deborah Brungard for useful
review and comments.
Thanks to Dean Bogdanovic, Tianran Zhou, and Carl Moberg for their
help coordinating with [RFC8199].
Many thanks to Jerry Bonner for spotting a tiny, one-word, but
critical typo.
12. References 11. References
12.1. Normative References 11.1. Normative References
[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-editor.org/info/rfc3444>. <https://www.rfc-editor.org/info/rfc3444>.
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
Classification", RFC 8199, DOI 10.17487/RFC8199, July Classification", RFC 8199, DOI 10.17487/RFC8199, July
2017, <https://www.rfc-editor.org/info/rfc8199>. 2017, <https://www.rfc-editor.org/info/rfc8199>.
12.2. Informative References 11.2. Informative References
[I-D.dhjain-bess-bgp-l3vpn-yang] [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", Work in Progress, draft-dhjain-
(work in progress), August 2016. bess-bgp-l3vpn-yang-02, August 2016.
[I-D.ietf-bess-evpn-yang] [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", Work in Progress, draft-ietf-bess-evpn-
progress), March 2017. yang-03, October 2017.
[I-D.ietf-bess-l2vpn-yang] [L2VPN-SERVICE]
Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data
Model for L2VPN Service Delivery", Work in Progress,
draft-ietf-l2sm-l2vpn-service-model-04, October 2017.
[L2VPN-YANG]
Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 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-07 (work in progress), L2VPN", Work in Progress, draft-ietf-bess-l2vpn-yang-07,
October 2017. October 2017.
[I-D.ietf-l2sm-l2vpn-service-model] [MEF-55] MEF Forum, "Lifecycle Service Orchestration (LSO):
Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data Reference Architecture and Framework", Service Operations
Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn- Specification MEF 55, March 2016.
service-model-03 (work in progress), September 2017.
[MEF-55] MEF Forum, "Service Operations Specification MEF 55 :
Lifecycle Service Orchestration (LSO) Reference
Architecture and Framework", March 2016.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[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,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
skipping to change at page 23, line 29 skipping to change at page 23, line 14
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
Model for L3VPN Service Delivery", RFC 8049, Model for L3VPN Service Delivery", RFC 8049,
DOI 10.17487/RFC8049, February 2017, DOI 10.17487/RFC8049, February 2017,
<https://www.rfc-editor.org/info/rfc8049>. <https://www.rfc-editor.org/info/rfc8049>.
Acknowledgements
Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair,
Luis Miguel Contreras Murillo, Joe Salowey, Benoit Claise, Robert
Sparks, Tom Petch, David Sinicrope, and Deborah Brungard for their
useful review and comments.
Thanks to Dean Bogdanovic, Tianran Zhou, and Carl Moberg for their
help coordinating with [RFC8199].
Many thanks to Jerry Bonner for spotting a tiny but critical,
one-word typo.
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. 103 change blocks. 
286 lines changed or deleted 284 lines changed or added

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