One document matched: draft-wu-opsawg-service-model-explained-03.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!--
vim: set softtabstop=2 shiftwidth=2 expandtab
version=20150108
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3444 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3444.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC7223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7223.xml">
<!ENTITY RFC7407 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7407.xml">
<!ENTITY RFC7426 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7426.xml">
<!ENTITY RFC7491 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7491.xml">
]>
<rfc category="info" docName="draft-wu-opsawg-service-model-explained-03"
ipr="trust200902">
<front>
<title abbrev="Service Models Explained">Service Models Explained</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei Technologies</organization>
<address>
<email>bill.wu@huawei.com</email>
</address>
</author>
<author fullname="Will Liu" initials="W." surname="Liu">
<organization>Huawei Technologies</organization>
<address>
<email>liushucheng@huawei.com</email>
</address>
</author>
<author fullname="Adrian Farrel" initials="A." surname="Farrel">
<organization>Juniper Networks</organization>
<address>
<email>adrian@olddog.co.uk</email>
</address>
</author>
<date year="2016"/>
<area>Operations and Management</area>
<workgroup>OPS Area Working Group</workgroup>
<keyword>YANG</keyword>
<keyword>NETCONF</keyword>
<keyword>RESTCONF</keyword>
<keyword>Data Model</keyword>
<keyword>SDN</keyword>
<keyword>Service Orchestrator</keyword>
<abstract>
<t>The IETF has produced a considerable number of data models in the
YANG modelling language. The majority of these are used to model devices
and they allow access for configuration and to read operational
status.</t>
<t>A small number of YANG models are used to model services (for
example, the Layer Three Virtual Private Network Service Model produced
by the L3SM working group).</t>
<t>This document briefly sets out the scope of and purpose of an IETF
service model, and it shows where a service model might fit into a
Software Defined Networking architecture or deployment.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>In recent years the number of data models written in the YANG
modelling language <xref target="RFC6020"/> for configuration and
monitoring has blossomed. Many of these are used for device-level
configuration (for example, <xref target="RFC7223"/>) or for control of
protocols (for example, <xref target="RFC7407"/>).</t>
<t>Within the context of Software Defined Networking (SDN) <xref
target="RFC7426"/> YANG data models may be used on Southbound Interfaces
(SBIs) between a controller and network devices, and between network
orchestrators and controllers. There may also be a hierarchy of such
components with super-controllers, domain controllers, and device
controllers all exchanging information and instructions using YANG
models.</t>
<t>Recently there has been interest in using YANG to define and document
data models that describe services in a portable way that is independent
of which network operator uses the model. These models may be used in
manual and even paper-driven service request processes moving to
IT-based mechanisms. Ultimately they could be used in online,
software-driven dynamic systems.</t>
<t>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
operator. Equally, this document clarifies what a service model is not,
and dispels some common misconceptions.</t>
<t>Other work on classifying YANG data models has been done in
<xref target="I-D.ietf-netmod-yang-model-classification" />. That document
provides an important reference for this document, and also uses the term
"service model". <xref target="compare-nsm" /> provides a comparison between
these two classifications.</t>
</section>
<section anchor="terms" title="Terms and Concepts">
<t>Readers should familiarize themselves with the description and
classification of YANG models provided in
<xref target="I-D.ietf-netmod-yang-model-classification" />.</t>
<t>The following terms are used in this document:
<list style="hanging">
<t hangText="Network Operator:">This term is used interchangeably to
refer to the company that owns a network that provides Internet
connectivity and services, or the individual who performs operations
and management on that network.</t>
<t hangText="Customer:">Someone who purchases connectivity and other
services from a network operator. In the context of this document, a
customer is usually the company that runs their own network or
computing platforms and wishes to connect to the Internet or between
sites. Such a customer may operate an enterprise network or a data
center. Sometimes this term may also be used to refer to the
individual in such a company who contracts to buy services from a
network operator. A customer as described here is a separate
commercial operation from the network operator, but some companies
may operate with internal customers so that, for example, an IP/MPLS
packet network is the customer of an optical transport network.</t>
<t hangText="Service:">A network operator delivers one or more
services to a customer. A service in the context of this document
(sometimes called a Network Service) is some form of connectivity
between customer sites and the Internet or between customer sites
across the network operator's network and across the Internet,
however a distinction should be drawn between the parameters that
describe a service as included in a customer service model (q.v.)
and a Service Level Agreement (SLA) as discussed in
<xref target="confused" /> and <xref target="policy" />.</t>
</list></t>
<t><list style="empty">
<t>A service may be limited to simple connectivity (such as IP-based
Internet access), may be a tunnel (such as a virtual circuit), or
may be a more complex connectivity model (such as a multi-site
virtual private network). Services may be further enhanced by
additional functions providing security, load-balancing, accounting,
and so forth. Additionally, services usually include guarantees of
quality, throughput, and fault reporting.</t>
<t>This document makes a distinction between a service as delivered
to a customer (that is, the service as discussed on the interface
between a customer and the network operator) and the service as
realized within the network (as described in
<xref target="I-D.ietf-netmod-yang-model-classification" />. This
distinction is discussed further in <xref target="compare" /></t>
</list></t>
<t><list style="hanging">
<t hangText="Data Model:">The concepts of information models and
data models are described in <xref target="RFC3444"/>. That document
defines a data model by contrasting it with the definition of an
information model, so it may be helpful to quote some text to give
context within this document.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>The main purpose of an information model is to model managed
objects at a conceptual level, independent of any specific
implementations or protocols used to transport the data. The
degree of specificity (or detail) of the abstractions defined in
the information model depends on the modeling needs of its
designers. In order to make the overall design as clear as
possible, an information model should hide all protocol and
implementation details. Another important characteristic of an
information model is that it defines relationships between
managed objects.</t>
<t>Data models, conversely, are defined at a lower level of
abstraction and include many details. They are intended for
implementors and include protocol-specific constructs.</t>
</list></t>
</list></t>
<t><list style="hanging">
<t hangText="Service Model:">A service model is a specific type of
data model. It describes a service and the parameters of the
service in a portable way. The service model may divided into to
categories:
<list style="hanging">
<t hangText="Customer Service Model:">A customer service model is
used to describe a service as offer or delivered to a customer by
a network operator. It can be used by a human (via a user interface
such as a GUI, web form, or CLI) or by software to configure or
request a service and may equally be consumed by a human (such as
via an order fulfillment system) or by a software component. Such
models are sometimes referred to simply as "service models"
<xref target="I-D.ietf-l3sm-l3vpn-service-model" />. A customer
service model is expressed as a core set of parameters that are
common across network operators: additional features that are
specific to the offerings of individual network operators would
be defined in extensions or augmentations of the model.</t>
<t hangText="Service Delivery Model:">A service delivery model is
used by a network operator to define and configure how a service
is provided by the network. It can be used by a human operator
(such as via a management station) or by a software tool to instruct
network components. Such models are sometimes referred to as "network
service models" <xref target="I-D.ietf-netmod-yang-model-classification" />.
A service delivery model is expressed as a core set of parameters
that are common across a network type and technology: additional
features that are specific to the configuration of individual
vendor equipment or proprietary protocols would be defined in
extensions or augmentations of the model.</t>
</list></t>
</list></t>
<t>The distinction between a customer service model and a service delivery
model needs to be repeatedly clarified. A customer service model is not a
data model used to directly configure network devices, protocols, or
functions: it is not something that is sent to network devices (i.e.,
routers or switches) for processing. Equally, a customer service model is
not a data model that describes how a network operator realizes and delivers
the service described by the model. This issue is discussed further in
later sections.</t>
</section>
<section anchor="usage" title="Using Service Models">
<t>As already indicated, customer service models are used on the interface
between customers and network operators. This is shown simply in
<xref target="ref_model"/></t>
<t>The language in which a customer service model is described is a choice
for whoever specifies the model. The IETF uses the YANG data modeling
language defined in <xref target="RFC6020"/></t>
<t>The encoding and communication protocol used to exchange a customer
service model between customer and network operator are deployment- and
implementation-specific. The IETF has standardized the NETCONF protocol
<xref target="RFC6241" /> and the RESTCONF protocol
<xref target="I-D.ietf-netconf-restconf" /> for interactions "on the wire"
between software components with data encoded in XML or JSON. However,
co-located software components might use an API, while systems with more
direct human interactions might use web pages or even paper forms.</t>
<figure anchor="ref_model"
title="The Customer Service Models used on the Interface between Customers and Network Operators">
<artwork>
<![CDATA[
-------------- Customer ----------------------
| | Service Model | |
| Customer | <-----------------> | Network Operator |
| | | |
-------------- ----------------------
]]>
</artwork>
</figure>
<t>How a network operator processes a customer's service request described
with a customer service model will depend on the commercial and operational tools,
processes, and policies used by the operator. These may vary considerably from
one network operator to another.</t>
<t>However, the intent is that the network operator maps the service
request into configuration and operational parameters that control one
or more network to deliver the requested services. That means that the
network operator (or software run by the network operator) takes the
information in the customer service model and determines how to deliver the
service by enabling and configuring network protocols and devices. They may
achieve this by constructing service delivery models and passing them southbound
to network orchestrators or controllers.</t>
</section>
<section anchor="sdn" title="Service Models in an SDN Context">
<t>In an SDN system, the control and configuration of network resources
and protocols is performed by software systems that determine how best
to utilize the network. <xref target="sdn_arch"/> shows a common
architectural view of an SDN system where network elements are
programmed by a component called a controller, and where controllers are
instructed by an orchestrator that has a wider view of the whole of, or
part of, a network.</t>
<figure anchor="sdn_arch" title="A Common SDN Architecture">
<artwork>
<![CDATA[
------------------
| |
| Orchestrator |
| |
.------------------.
. : .
. : .
------------ ------------ ------------
| | | | | |
| Controller | | Controller | | Controller |
| | | | | |
------------ ------------ ------------
: . . :
: . . :
: . . :
--------- --------- --------- ---------
| Network | | Network | | Network | | Network |
| Element | | Element | | Element | | Element |
--------- --------- --------- ---------
]]>
</artwork>
</figure>
<t>But a customer' service request is (or should be) network-agnostic.
That is, there should be an independence between the behavior and functions
that a customer requests and the technology that the network operator has
available to deliver the service. This means that the service request
must be mapped to the orchestrator's view, and this mapping may include
a choice of which networks to use depending on what technologies are
available and which service features have been requested.</t>
<t>This mapping can be achieved by splitting the orchestration function
between a "Service Orchestrator" and a "Network Orchestrator" as shown
in <xref target="svc_arch"/>. In a system that is fully implemented in
software, this could lead to agile service delivery or service
automation.</t>
<figure anchor="svc_arch" title="An SDN Architecture with a Service Orchestrator">
<artwork>
<![CDATA[
Customer
------------------ Service ----------
| | Model | |
| Service |<-------->| Customer |
| Orchestrator | | |
| | ----------
------------------
. .
. . -----------
. . ......|Application|
. . : | BSS/OSS |
. . : -----------
. Service Delivery . :
. Model . :
------------------ ------------------
| | | |
| Network | | Network |
| Orchestrator | | Orchestrator |
| | | |
.------------------ ------------------.
. : : .
. : Network Configuration : .
. : Model : .
------------ ------------ ------------ ------------
| | | | | | | |
| Controller | | Controller | | Controller | | Controller |
| | | | | | | |
------------ ------------ ------------ ------------
: . . : :
: . . Device : :
: . . Configuration : :
: . . Model : :
--------- --------- --------- --------- ---------
| Network | | Network | | Network | | Network | | Network |
| Element | | Element | | Element | | Element | | Element |
--------- --------- --------- --------- ---------
]]>
</artwork>
</figure>
<t><xref target="svc_arch" /> also shows where different data models
might be applied within the architecture.</t>
<t>The split between control components that exposes a "service
interface" is present in many figures showing extended SDN
architectures:
<list style="symbols">
<t>Figure 1 of <xref target="RFC7426"/> shows a separation of the
"Application Plane", the "Network Services Abstraction Layer
(NSAL)", and the "Control Plane". It marks the "Service Interface"
as situated between the NSAL and the Control Plane.</t>
<t><xref target="RFC7491"/> describes an interface between an
"Application Service Coordinator" and an "Application-Based Network
Operations Controller".</t>
<t>Figure 1 of <xref target="I-D.ietf-netmod-yang-model-classification" />
shows an interface from an Operations Support System (OSS) or a
Business Support System (BSS) that is expressed in "service models".</t>
</list></t>
<t>This can all lead to some confusion around the definition of a "service
interface" and a "service model". Some previous literature considers the
interface that is northbound of the Network Orchestrator to be a "service
interface" used by an application (as shown in <xref target="svc_arch" />),
but the service described at this interface is network-centric and is
aware of many features such as topology, technology, and operator
policy. Thus, we make a distinction between this type of service
interface and the more abstract service interface where the service is
described by a service model and the interaction is between customer and
operator. Further discussion of this point is provided in
<xref target="confused" />.</t>
</section>
<section anchor="confused" title="Possible Causes of Confusion">
<t>In discussing service models, there are several possible causes of
confusion:
<list style="symbols">
<t>The services we are discussing are services provided by network
operators to customers. This is a completely different thing to "Foo
as a Service" (for example, Infrastructure as a Service (IaaS))
where a service provider offers a service at some location that is
reached across a network. The confusion arises not only because of
the use of the word "service", but also because network operators
may offer value-added services as well as network connection services
to their customers.</t>
<t>Network operation is completely out of scope in the discussion of
services between a network operator and a customer. That means that
the customer service model does not reveal to the customer anything
about how the network operator delivers the service. The model does
not expose details of technology or network resources used to provide
the service. For example, in the simple case of point-to-point virtual
link connectivity provided by a network tunnel (such as an MPLS pseudowire)
the network operator does not expose the path through the network
that the tunnel follows. Of course, this does not preclude the network
operator from taking guidance from the customer (such as to avoid
routing traffic through a particular country) or from disclosing
specific details (such as might be revealed by a route trace), but
these are not standard features of the service as described in the
customer service model.</t>
<t>The network operator may use further data models (service delivery
models) that help to describe how the service is realized in the network.
These models might be used on the interface between the Service
Orchestrator and the Network Orchestrator as shown in
<xref target="svc_arch"/> and might include many of the pieces of
information from the customer service model alongside protocol parameters
and device configuration information.
<xref target="I-D.ietf-netmod-yang-model-classification" /> also
terms these data models as "service models" and a comparison is
provided in <xref target="compare-nsm" />. It is important that the
Service Orchestrator should be able to map from a customer service model
to these service delivery models, but they are not the same things.</t>
<t>Commercial terms are generally not a good subject for
standardization. It is possible that some network operators will
enhance standard customer service models to include commercial information,
but the way this is done is likely to vary widely between network
operators.</t>
<t>Service Level Agreements (SLAs) have a high degree of overlap
with the definition of services present in customer service models.
Requests for specific bandwidth, for example, might be present in a
customer service model, and agreement to deliver a service is a commitment
to the description of the service in the customer service model. However,
SLAs typically include a number of fine-grained details about how
services are allowed to vary, by how much, and how often. SLAs are
also linked to commercial terms with penalties and so forth, and so
are also not good topics for standardization.</t>
</list></t>
</section>
<section anchor="compare" title="Comparison With Other Work">
<t>Other work has classified YANG models, produced parallel architectures, and
developed a range of YANG models. This section briefly examines that other
work and shows how it fits with the description of service models introduced in
this document.</t>
<section anchor="compare-nsm" title="Comparison With Network Service Models">
<t>As previously noted, <xref target="I-D.ietf-netmod-yang-model-classification" />
provides a classification of YANG data models. It introduces the
term "Network Service YANG Module" to identify the type of model
used to "describe the configuration, state data and operations of an
abstract representation of a service implemented on one or multiple
network elements." These are service delivery models as described
in this document, that is, they are the models used on the interface
between the Service Orchestrator or OSS/BSS and the Network Orchestrator as
shown in <xref target="svc_arch" />.</t>
<t>Figure 1 of <xref target="I-D.ietf-netmod-yang-model-classification" />
can be modified to make this more clear and to add an additional example of
a Network Service YANG model as shown in <xref target="modfig" />.</t>
<figure anchor="modfig" title="YANG Module Layers Showing Service Models">
<artwork>
<![CDATA[
+---------------+
| |
| Customers |
| |
+---------------+
- - - - - - - - - - - - - -
Service YANG Modules
+--------------------------+ +--------------------------+
| | | Operations and Business |
| Service Orchestrator | | Support Systems |
| | | (OSS/BSS) |
+--------------------------+ +--------------------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Service YANG Modules
+------------+ +-------------+ +-------------+ +-------------+
| | | | | | | |
| - L2VPN | | - L2VPN | | EVPN | | L3VPN |
| - VPWS | | - VPLS | | | | |
| | | | | | | |
+------------+ +-------------+ +-------------+ +-------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Element YANG Modules
+------------+ +------------+ +-------------+ +------------+
| | | | | | | |
| MPLS | | BGP | | IPv4 / IPv6 | | Ethernet |
| | | | | | | |
+------------+ +------------+ +-------------+ +------------+
L2VPN: Layer 2 Virtual Private Network
L3VPN: Layer 3 Virtual Private Network
VPWS: Virtual Private Wire Service
VPLS: Virtual Private LAN Service
]]>
</artwork>
</figure>
</section>
<section anchor="compare-dm" title="Service Delivery Model Work">
<t>A number of IETF working groups are developing YANG models
related to services. These models focus on how the network
operator configures the network through protocols and devices
to deliver a service.</t>
<t>A sample set of these models is listed here:
<list style="symbols">
<t><xref target="I-D.dhjain-bess-bgp-l3vpn-yang" /> defines a YANG
model that can be used to configure and manage BGP Layer 3 VPNs.</t>
<t><xref target="I-D.ietf-bess-l2vpn-yang" /> documents a YANG model
that it is expected will be used by the management tools run by
the network operators in order to manage and monitor the network
resources that they use to deliver L2VPN services.</t>
<t><xref target="I-D.ietf-bess-evpn-yang" /> defines YANG models for
delivering an Ethernet VPN service.</t>
</list></t>
<t>All of these models are service delivery models in the context of
this document.</t>
</section>
<section anchor="compare-sm" title="Customer Service Model Work">
<t>Several initiatives within the IETF are developing customer
service models. The most advanced presents the Layer Three
Virtual Private Network (L3VPN) service as described by a
network operator to a customer. This L3VPN service model (L3SM)
is documented in <xref target="I-D.ietf-l3sm-l3vpn-service-model" />
where its usage is described as in <xref target="l3sm-fig" />
which is reproduced from that document. As can be seen, the
L3SM is a customer service model as described in this document.</t>
<figure anchor="l3sm-fig" title="The L3SM Service Architecture">
<artwork>
<![CDATA[
L3VPN-SVC |
MODEL |
|
+------------------+ +-----+
| Orchestration | < --- > | OSS |
+------------------+ +-----+
| |
+----------------+ |
| Config manager | |
+----------------+ |
| |
| Netconf/CLI ...
| |
+------------------------------------------------+
Network
]]>
</artwork>
</figure>
<t>A Layer Two VPN service model (L2SM) is defined in
<xref target="I-D.wen-l2sm-l2vpn-service-model" />. That model's
usage is described as in <xref target="l2sm-fig" /> which is a reproduction
of Figure 5 from that document. As can be seen, the L2SM is a customer
service model as described in this document.</t>
<figure anchor="l2sm-fig" title="The L2SM Service Architecture">
<artwork>
<![CDATA[
----------------------------
| Customer Service Requester |
----------------------------
|
L2VPN |
Service |
Model |
|
-----------------------
| Service Orchestration |
-----------------------
|
| Service +-------------+
| Delivery +------>| Application |
| Model | | BSS/OSS |
| V +-------------+
-----------------------
| Network Orchestration |
-----------------------
| |
+----------------+ |
| Config manager | |
+----------------+ | Device
| | Models
| |
--------------------------------------------
Network
]]>
</artwork>
</figure>
</section>
<section anchor="compare-mef" title="The MEF Architecture">
<t>The MEF has developed an architecture for network management and
operation. It is documented as the Lifecycle Serice Orchestration
(LSO) Reference Architecture and illustrated in Figure 2 of
<xref target="MEF-55" />. Part of this is depicted in
<xref target="mef-fig" />.</t>
<t>The MEF terms the functional interfaces between components as
Management Interface Reference Points (MIRPs). These are the logical points of
interaction between functional management entities and are further
defined by Interface Profiles and implemented by APIs. As can be seen
from <xref target="mef-fig" />, each of these MIRPs has been given a name.
In the context of this document:
<list style="symbols">
<t>ALEGRO is the MIRP on which customer service models are used</t>
<t>PRESTO is the MRP on which service delivery models are used.</t>
</list></t>
<figure anchor="mef-fig" title="Part of The MEF's LSO Reference Architecture">
<artwork>
<![CDATA[
:
Customer Domain : Service Provider Domain
:
CANATA : --------------
------------------>| Business |
| : | Applications |
v : --------------
------------- : ^
| Customer | : |
| Application | : | LEGATO
| Coordinator | : |
------------- : |
^ : v
| : ---------------
| : | Service |
------------------>| Orchestration |
ALEGRO : | Functionality |
: ---------------
: ^
: | PRESTO
: v
: ----------------
: | Infrastructure |
: | Control and |
: | Management |
: ----------------
: ^
: | ADAGIO
: v
: -------------
: | Element |
: | Control and |
: | Management |
: -------------
]]>
</artwork>
</figure>
</section>
</section>
<section anchor="more" title="Further Concepts">
<t>This section introduces a few further, more advanced concepts</t>
<section anchor="agnostic" title="Technology Agnostic">
<t>Service models should generally be technology agnostic. That is to
say, the customer should not care how the service is provided so long
as the service is delivered.</t>
<t>However, some technologies reach the customer site and make a
definition to the type of service delivered. Such features do need to
be described in the service model.</t>
<t>Two examples are:
<list style="symbols">
<t>The data passed between customer equipment and network operator
equipment will be encapsulated in a specific way, and that data
plane type forms part of the service.</t>
<t>Protocols that are run between customer equipment and network
operator equipment (for example, Operations, Administration, and
Maintenance protocols, or protocols for exchanging routing
information) need to be selected and configured as part of the
service description.</t>
</list></t>
</section>
<section anchor="policy" title="Relationship to Policy">
<t>Policy appears as a crucial function in many places during network
orchestration. A Service Orchestrator will, for example, apply the
network operator's policies to determine how to provide a service for
a particular customer (possibly considering commercial terms).
However, the policies within a service model are limited to those over
which a customer has direct influence, but which are acted on by the
network operator.</t>
<t>The policies that express desired behavior of services on
occurrence of specific events are close to SLA definitions: they
should only be included in the base service model where they are
common to all network operators' offerings. Policies that describe who
at a customer may request or modify services (that is, authorization)
are close to commercial terms: they, too, should only be included in
the base service model where they are common to all network operators'
offerings.</t>
<t>Nevertheless, policy is so important that all service models should
be designed to be easily extensible to allow policy components to be
added and associated with services as needed.</t>
</section>
<section anchor="specifics" title="Operator-Specific Features">
<t>When work in Layer Three Virtual Private Network Service Model
(L3SM) was started, there was some doubt as to whether network
operators would be able to agree on a common description of the
services that they offer to their customers because, in a competitive
environment, each markets the services in a different way with
different additional features. Thus, when a basic description of the
core service is agreed and documented in a service model, it is
important that that model should be easily extended or augmented by
each network operator so that the standardized model can be used in a
common way and only the operator- specific features vary from one
environment to another.</t>
</section>
<section anchor="multiplicity" title="Supporting Multiple Services">
<t>Network operators will, in general, offer many different services
to their customers. Each would normally be the subject of a separate
service model.</t>
<t>It is an implementation and deployment choice whether all service
models are processed by a single Service Orchestrator that can
coordinate between the different services, or whether each service
model is handled by a specialized Service Orchestrator able to provide
tuned behavior for a specific service.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>TBD</t>
</section>
<section anchor="manageability" title="Manageability Considerations">
<t>TBD</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document makes no requests for IANA action</t>
</section>
<section anchor="acks" title="Acknowledgements">
<t>Thanks to Daniel King, Xian Zhang, and Michael Scharf for useful review and comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC3444;
&RFC7426;
<?rfc include="reference.I-D.ietf-l3sm-l3vpn-service-model"?>
<?rfc include="reference.I-D.ietf-netmod-yang-model-classification"?>
</references>
<references title="Informative References">
&RFC6020;
&RFC6241;
&RFC7223;
&RFC7407;
&RFC7491;
<?rfc include="reference.I-D.dhjain-bess-bgp-l3vpn-yang"?>
<?rfc include="reference.I-D.ietf-bess-evpn-yang"?>
<?rfc include="reference.I-D.ietf-bess-l2vpn-yang"?>
<?rfc include="reference.I-D.ietf-netconf-restconf"?>
<?rfc include="reference.I-D.wen-l2sm-l2vpn-service-model"?>
<reference anchor="MEF-55">
<front>
<title abbrev="MEF55">Service Operations Specification MEF 55 : Lifecycle Service
Orchestration (LSO) Reference Architecture and Framework</title>
<author>
<organization>MEF Forum</organization>
</author>
<date month="March" year="2016"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:35:10 |