    Internet Engineering Task Force (IETF)                             Q. Wu
    Request for Comments: 8309                                        W. Liu
    Category: Informational                              Huawei Technologies
    ISSN: 2070-1721                                                A. Farrel
                                                            Juniper Networks
                                                                January 2018

                            Service Models Explained

    Abstract

       The IETF has produced many modules in the YANG modeling language.
       The majority of these modules are used to construct data models to
       model devices or monolithic functions.

       A small number of YANG modules have been defined to model services
       (for example, the Layer 3 Virtual Private Network Service Model
       (L3SM) produced by the L3SM working group and documented in RFC
       8049).

       This document describes service models as used within the IETF and
       also shows where a service model might fit into a software-defined
       networking architecture.  Note that service models do not make any
       assumption of how a service is actually engineered and delivered for
       a customer; details of how network protocols and devices are
       engineered to deliver a service are captured in other modules that
       are not exposed through the interface between the customer and the
       provider.

    Status of This Memo

       This document is not an Internet Standards Track specification; it is
       published for informational purposes.

       This document is a product of the Internet Engineering Task Force
       (IETF).  It represents the consensus of the IETF community.  It has
       received public review and has been approved for publication by the
       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.

       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.

    Wu, et al.                    Informational                     [Page 1]

    RFC 8309                Service Models Explained            January 2018

    Copyright Notice

       Copyright (c) 2018 IETF Trust and the persons identified as the
       document authors.  All rights reserved.

       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents
       (https://trustee.ietf.org/license-info) in effect on the date of
       publication of this document.  Please review these documents
       carefully, as they describe your rights and restrictions with respect
       to this document.  Code Components extracted from this document must
       include Simplified BSD License text as described in Section 4.e of
       the Trust Legal Provisions and are provided without warranty as
       described in the Simplified BSD License.

    Table of Contents

       1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.  Terms and Concepts  . . . . . . . . . . . . . . . . . . . . .   4
       3.  Using Service Models  . . . . . . . . . . . . . . . . . . . .   7
         3.1.  Practical Considerations  . . . . . . . . . . . . . . . .   8
       4.  Service Models in an SDN Context  . . . . . . . . . . . . . .   8
       5.  Possible Causes of Confusion  . . . . . . . . . . . . . . . .  11
       6.  Comparison with Other Work  . . . . . . . . . . . . . . . . .  13
         6.1.  Comparison with Network Service Models  . . . . . . . . .  13
         6.2.  Service Delivery and Network Element Model Work . . . . .  15
         6.3.  Customer Service Model Work . . . . . . . . . . . . . . .  16
         6.4.  The MEF Architecture  . . . . . . . . . . . . . . . . . .  17
       7.  Further Concepts  . . . . . . . . . . . . . . . . . . . . . .  18
         7.1.  Technology Agnostic . . . . . . . . . . . . . . . . . . .  18
         7.2.  Relationship to Policy  . . . . . . . . . . . . . . . . .  18
         7.3.  Operator-Specific Features  . . . . . . . . . . . . . . .  19
         7.4.  Supporting Multiple Services  . . . . . . . . . . . . . .  19
       8.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
       9.  Manageability Considerations  . . . . . . . . . . . . . . . .  20
       10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
       11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
         11.1.  Normative References . . . . . . . . . . . . . . . . . .  21
         11.2.  Informative References . . . . . . . . . . . . . . . . .  21
       Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
       Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

    Wu, et al.                    Informational                     [Page 2]

    RFC 8309                Service Models Explained            January 2018

    1.  Introduction

       In recent years, the number of modules written in the YANG modeling
       language [RFC6020] for configuration and monitoring has blossomed.
       Many of these are used for device-level configuration (for example,
       [RFC7223]) or for control of monolithic functions or protocol
       instances (for example, [RFC7407]).

       [RFC7950] makes a distinction between a "data model", which it
       defines as describing how data is represented and accessed, and a
       "YANG module", which defines hierarchies of schema nodes to make a
       self-contained and compilable block of definitions and inclusions.
       YANG structures data models into modules for ease of use.

       Within the context of Software-Defined Networking (SDN) [RFC7149]
       [RFC7426], YANG data modules may be used on the interface between a
       controller and network devices, as well as 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
       modules.

       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, for example, the Layer 3
       Virtual Private Network Service Model (L3SM) [RFC8049].  Such models
       may be used in manual and even paper-driven service request processes
       with a gradual transition to IT-based mechanisms.  Ultimately, they
       could be used in online, software-driven dynamic systems and may be
       used as part of an SDN system.

       This document explains the scope and purpose of service models within
       the IETF (and is limited to within the scope of 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.

       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
       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
       delivered to a customer; details of how network protocols and devices
       are engineered to deliver a service are captured in other modules
       that are not exposed through the interface between the customer and
       the provider.

    Wu, et al.                    Informational                     [Page 3]

    RFC 8309                Service Models Explained            January 2018

       In summary, a service model is a formal representation of the data
       elements that describe a network service as that service is described
       to or requested by a customer of a network operator.  Details
       included in the service model include a description of the service as
       experienced by the customer, but not features of how that service is
       delivered or realized by the service provider.

       Other work on classifying YANG modules has been done in [RFC8199].
       That document provides an important reference for this document and
       also uses the term "service module".  In this document, Section 6.1
       provides a comparison between these two uses of the same terminology.

    2.  Terms and Concepts

       Readers should familiarize themselves with the description and
       classification of YANG modules provided in [RFC8199].

       The following terms are used in this document:

       Network Operator:  This term is used to refer to the company that
          owns and operates one or more networks that provide Internet
          connectivity services and/or other services.

       Customer:  This term refers to someone who purchases a service
          (including connectivity) from a network operator.  In the context
          of this document, a customer is usually a 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 may be the customer of an
          optical transport network.

    Wu, et al.                    Informational                     [Page 4]

    RFC 8309                Service Models Explained            January 2018

       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 (see the
          definition of this term, below) and a Service Level Agreement
          (SLA), as discussed in Sections 5 and 7.2.

          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 involve more complex connectivity (such as in a multisite
          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.

          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 [RFC8199]).  This
          distinction is discussed further in Section 6.

          Readers may also refer to [RFC7297] for an example of how an IP
          connectivity service may be characterized.

       Data Model:  The information model (IM) and data model (DM) concepts
          are described in [RFC3444].  That document defines a data model by
          contrasting it with the definition of an IM as follows:

             The main purpose of an IM 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 IM
             depends on the modeling needs of its designers.  In order to
             make the overall design as clear as possible, an IM should hide
             all protocol and implementation details.  Another important
             characteristic of an IM is that it defines relationships
             between managed objects.

             DMs, conversely, are defined at a lower level of abstraction
             and include many details.  They are intended for implementors
             and include protocol-specific constructs.

          As mentioned in Section 1, this document also uses the terms "data
          model" and "YANG module" as defined in [RFC7950].

    Wu, et al.                    Informational                     [Page 5]

    RFC 8309                Service Models Explained            January 2018

       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 that can be used uniformly and independent of the
          equipment and operating environment.  The service model may be
          divided into the two following categories:

          Customer Service Model:  A customer service model is used to
             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
             human (via a user interface such as a GUI, web form, or
             Command-Line Interface (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" [RFC8049].  A customer service model is expressed in a
             YANG module 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 module.  Except where
             specific technology details are directly pertinent to the
             customer (such as encapsulations or mechanisms applied on
             access links), customer service models are technology agnostic
             so that the customer does not have influence over or knowledge
             of how the network operator engineers the service.

             An example of where such details are relevant to the customer
             is when they describe the behavior or interactions on the
             interface between the equipment at the customer site (often
             referred to as the Customer Edge or CE equipment) and the
             equipment at the network operator's site (usually referred to
             as the Provider Edge or PE equipment).

          Service Delivery Model:  A service delivery model is used by a
             network operator to define and manage how a service is
             engineered in 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.  The YANG modules that encode such
             models are sometimes referred to as "network service YANG
             modules" [RFC8199] and are consumed by "external systems" such
             as an Operations Support System (OSS).  A service delivery
             module 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 module.  Service delivery
             modules include technology-specific modules.

    Wu, et al.                    Informational                     [Page 6]

    RFC 8309                Service Models Explained            January 2018

          The distinction between a customer service model and a service
          delivery model needs to be clarified.  The modules that encode a
          customer service model are not 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, the modules that encode a customer service model do not
          describe how a network operator realizes and delivers the service
          described by the module.  This distinction is discussed further in
          later sections.

    3.  Using Service Models

       As already indicated, customer service models are used on the
       interface between customers and network operators.  This is shown in
       Figure 1.

       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 [RFC6020].

       The encoding and communication protocol used to exchange a customer
       service model between the customer and network operator is specific
       to deployment and implementation.  The IETF has standardized the
       NETCONF protocol [RFC6241] and the RESTCONF protocol [RFC8040] for
       interactions "on the wire" between software components with data
       encoded in XML or JSON.  However, co-located software components
       might use an internal API, while systems with more direct human
       interactions might use web pages or even paper forms.  Where direct
       human interaction comes into play, interface interactions may be
       realized via business practices that may introduce some margin of
       error, thus raising the priority for automated, deterministic
       interfaces.

                --------------       Customer        ----------------------
               |              |    Service Model    |                      |
               |   Customer   | <-----------------> |   Network Operator   |
               |              |                     |                      |
                --------------                       ----------------------

        Figure 1: The Customer Service Models Used on the Interface between
                          Customers and Network Operators

       How a network operator processes a customer's service request when
       described with a customer service model depends on the commercial and
       operational tools, processes, and policies used by the network
       operator.  These may vary considerably from one network operator to
       another.

    Wu, et al.                    Informational                     [Page 7]

    RFC 8309                Service Models Explained            January 2018

       However, the intent is that the network operator maps the service
       request into configuration and operational parameters that control
       one or more networks 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 to network orchestrators or
       controllers.  The use of standard customer service models eases
       service delivery by means of automation.

    3.1.  Practical Considerations

       The practicality of customer service models has been repeatedly
       debated.  It has been suggested that network operators have radically
       different business models and widely diverse commercial offerings,
       which makes a common customer service model impractical.  However,
       L3SM [RFC8049] results from the consensus of multiple individuals
       working at network operators and offers a common core of service
       options that can be augmented according to the needs of individual
       network operators.

       It has also been suggested that there should be a single, base
       customer service module, and that details of individual services
       should be offered as extensions or augmentations of this.  It is
       quite possible that a number of service parameters (such as the
       identity and postal address of a customer) will be common, and it
       would be a mistake to define them multiple times (once in each
       customer service model).  However, the distinction between a 'module'
       and a 'model' should be considered at this point: modules are how the
       data for models is logically broken out and documented, especially
       for reuse in multiple models.

    4.  Service Models in an SDN Context

       In an SDN system, the management of network resources and protocols
       is performed by software systems that determine how best to utilize
       the network.  Figure 2 shows a sample architectural view of an SDN
       system where network elements are programmed by a component called an
       "SDN controller" (or "controller" for short) and where controllers
       are instructed by an orchestrator that has a wider view of the whole
       of, or part of, a network.  The internal organization of an SDN
       control plane is specific to deployment.

    Wu, et al.                    Informational                     [Page 8]

    RFC 8309                Service Models Explained            January 2018

                                ------------------
                               |                  |
                               |   Orchestrator   |
                               |                  |
                               .------------------.
                              .          :         .
                             .           :          .
                  ------------     ------------     ------------
                 |            |   |            |   |            |
                 | Controller |   | Controller |   | Controller |
                 |            |   |            |   |            |
                  ------------     ------------     ------------
                     :              .       .               :
                     :             .         .              :
                     :            .           .             :
                 ---------     ---------   ---------     ---------
                | Network |   | Network | | Network |   | Network |
                | Element |   | Element | | Element |   | Element |
                 ---------     ---------   ---------     ---------

                        Figure 2: A Sample SDN Architecture

       A customer's service request is (or should be) technology agnostic.
       That is, a customer is unaware of the technology that the network
       operator has available to deliver the service, so the customer does
       not make requests specific to the underlying technology but is
       limited to making requests specific to the service that is to be
       delivered.  The orchestrator must map the service request to its
       view, and this mapping may include a choice of which networks and
       technologies to use depending on which service features have been
       requested.

       One implementation option to achieve this mapping is to split the
       orchestration function between a "Service Orchestrator" and a
       "Network Orchestrator" as shown in Figure 3.

    Wu, et al.                    Informational                     [Page 9]

    RFC 8309                Service Models Explained            January 2018

                                                     Customer
                                ------------------   Service  ----------
                               |                  |  Model   |          |
                               |     Service      |<-------->| Customer |
                               |   Orchestrator   |    (a)   |          |
                               |                  |           ----------
                                ------------------
                                   .          .
                                  .            .        (b)   -----------
                                 . (b)          .      ......|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 |
         ---------     ---------   ---------     ---------      ---------

         Figure 3: An Example SDN Architecture with a Service Orchestrator

       Figure 3 also shows where different data models might be applied
       within the architecture.  The device configuration models are used by
       a controller to set parameters on an individual network element.  The
       network configuration models are used by a network orchestrator to
       instruct controllers (which may each be responsible for multiple
       network elements) how to configure parts of a network.

    Wu, et al.                    Informational                    [Page 10]

    RFC 8309                Service Models Explained            January 2018

       The following examples illustrate the split between control
       components that expose a "service interface" that is present in many
       figures that show extended SDN architectures:

       o  Figure 1 of [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.

       o  Figure 1 of [RFC7491] shows an interface between an "Application
          Service Coordinator" and an "Application-Based Network Operations
          Controller".

       o  Figure 1 of [RFC8199] shows an interface from an OSS or a Business
          Support System (BSS) that is expressed in "Network Service YANG
          Modules".

       This can all lead to some confusion around the definition of a
       "service interface" and a "service model".  Some previous literature
       considers the interface northbound of the network orchestrator
       (labeled "(b)" in Figure 3) to be a "service interface" used by an
       application, 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 (labeled
       "(a)" in Figure 3) where the service is described by a service model
       and the interaction is between the customer and network operator.
       Further discussion of this point is provided in Section 5.

    5.  Possible Causes of Confusion

       In discussing service models, there are several possible causes of
       confusion:

       o  The services we are discussing are connectivity services provided
          by network operators to customers; the services are achieved by
          manipulating the network resources of the operator's network.
          This is a completely different thing to "Foo as a Service" (for
          example, Storage as a Service (SaaS)) where a service provider
          offers reachability to a value-added service that is provided at
          some location in the network using other resources (compute,
          storage, ...) that are not part of the network itself.  The
          confusion arises not only because of the use of the word "service"
          in both cases, but also because network operators may offer both
          types of service to their customers.

    Wu, et al.                    Informational                    [Page 11]

    RFC 8309                Service Models Explained            January 2018

       o  Network operation is normally 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, nor
          does the model expose details of technology or network resources
          used to provide the service (all of these details could, in any
          case, be considered security vulnerabilities).  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.

       o  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
          Figure 3, and might include many of the pieces of information from
          the customer service model alongside protocol parameters and
          device configuration information.  [RFC8199] also terms these data
          models as "service models" and encodes them as "Network Service
          YANG Modules"; a comparison is provided in Section 6.1.  It is
          important that the service orchestrator be able to map from a
          customer service model to these service delivery models, but they
          are not the same thing.

       o  Commercial terms (such as "cost per byte", "cost per minute", and
          "scoped by quality and type of service", as well as terms related
          to payment) 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.  Thus, this feature is out of scope for standardized
          customer service models.

       o  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 thus are also not good topics for

    Wu, et al.                    Informational                    [Page 12]

    RFC 8309                Service Models Explained            January 2018

          standardization.  As with commercial terms, it is expected that
          some network operators will enhance standard customer service
          models to include SLA parameters either using their own work or
          depending on material from standards bodies that specialize in
          this topic, but this feature is out of scope for the IETF's
          customer service models.

          If a network operator chooses to express an SLA using a data
          model, that model might be referenced as an extension or an
          augmentation of the customer service model.

    6.  Comparison with Other Work

       Other work has classified YANG modules, produced parallel
       architectures, and developed a range of YANG modules.  This section
       briefly examines that other work and shows how it fits with the
       description of service models introduced in this document.

    6.1.  Comparison with Network Service Models

       As previously noted, [RFC8199] provides a classification of YANG
       modules.  It introduces the term "Network Service YANG Module" to
       identify the type of module used to "describe the configuration,
       state data, operations, and notifications of abstract representations
       of services implemented on one or multiple network elements."  These
       modules are used to construct the service delivery models as
       described in this document; that is, they are the modules used on the
       interface between the service orchestrator or OSS/BSS and the network
       orchestrator, as shown in Figure 3.

       Figure 1 of [RFC8199] can be modified to make this more clear and to
       include an additional example of a Network Service YANG module, as
       shown in Figure 4.  As can be seen, the highest classification of
       modules collects those that are used to deliver operations support
       and business support.  These might be consumed by an Operations
       Support System (OSS) or a Business Support System (BSS), and a
       service orchestrator may form part of an OSS/BSS or may be a separate
       component.  This highest layer in the figure is divided into the
       customer service modules that are used to describe services to a
       customer as discussed in this document, and other modules that
       describe further OSS/BSS functions such as billing and SLAs.

    Wu, et al.                    Informational                    [Page 13]

    RFC 8309                Service Models Explained            January 2018

           - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
           Operations Support and Business Support YANG Modules

           +-----------------------+     +-----------------------+
           |                       |     |                       |
           |    Customer Service   |     |         Other         |
           |      YANG Modules     |     |  Operations Support   |
           |                       |     |          and          |
           |  +------+   +------+  |     |    Business Support   |
           |  |      |   |      |  |     |      YANG Modules     |
           |  | L2SM |   | L3SM |  |     |                       |
           |  |      |   |      |  |     |                       |
           |  +------+   +------+  |     |                       |
           |                       |     |                       |
           +-----------------------+     +-----------------------+

           - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
           Network Service YANG Modules

          +------------+  +-------------+  +-------------+  +-------------+
          |            |  |             |  |             |  |             |
          |  - L2VPN   |  |   - L2VPN   |  |    EVPN     |  |    L3VPN    |
          |  - VPWS    |  |   - VPLS    |  |             |  |             |
          |            |  |             |  |             |  |             |
          +------------+  +-------------+  +-------------+  +-------------+

           - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
           Network Element YANG Modules

           +------------+  +------------+  +-------------+  +------------+
           |            |  |            |  |             |  |            |
           |    MPLS    |  |    BGP     |  | IPv4 / IPv6 |  |  Ethernet  |
           |            |  |            |  |             |  |            |
           +------------+  +------------+  +-------------+  +------------+

           Key:
              EVPN: Ethernet Virtual Private Network
              L2SM: Layer 2 Virtual Private Network Service Model
              L2VPN: Layer 2 Virtual Private Network
              L3SM: Layer 3 Virtual Private Network Service Model
              L3VPN: Layer 3 Virtual Private Network
              VPLS: Virtual Private LAN Service
              VPWS: Virtual Private Wire Service

                 Figure 4: YANG Module Abstraction Layers Showing
                             Customer Service Modules

    Wu, et al.                    Informational                    [Page 14]

    RFC 8309                Service Models Explained            January 2018

    6.2.  Service Delivery and Network Element Model Work

       A number of IETF working groups are developing YANG modules related
       to services.  These models focus on how the network operator
       configures the network through protocols and devices to deliver a
       service.  Some of these models are classified as network service
       delivery models (also called service delivery models or network
       configuration models depending on the level at which they are
       pitched), while others have details that are related to specific
       element configuration and so are classed as network element models
       (also called device models).

       A sample set of these models is listed here:

       o  [BGP-L3VPN-YANG] defines a YANG module that can be used to
          configure and manage BGP L3VPNs.

       o  [L2VPN-YANG] documents a data model that is expected to 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.

       o  [EVPN-YANG] defines YANG modules for delivering an Ethernet VPN
          service.

    Wu, et al.                    Informational                    [Page 15]

    RFC 8309                Service Models Explained            January 2018

    6.3.  Customer Service Model Work

       Several initiatives within the IETF are developing customer service
       models.  The L3SM presents the L3VPN service, as described by a
       network operator, to a customer.  Figure 5, which is reproduced from
       [RFC8049], shows that the L3SM is a customer service model as
       described in this document.

                   L3VPN-SVC |
                     MODEL   |
                             |
                          +------------------+         +-----+
                          |   Orchestration  | < --- > | OSS |
                          +------------------+         +-----+
                             |            |
                     +----------------+   |
                     | Config manager |   |
                     +----------------+   |
                             |            |
                             | Netconf/CLI ...
                             |            |
               +------------------------------------------------+
                                    Network

                      Figure 5: The L3SM Service Architecture

       A Layer 2 VPN Service Model (L2SM) is defined in [L2VPN-SERVICE].
       That model's usage is described as in Figure 6, 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.

    Wu, et al.                    Informational                    [Page 16]

    RFC 8309                Service Models Explained            January 2018

                 ----------------------------
                | Customer Service Requester |
                 ----------------------------
                     |
             L2VPN   |
             Service |
             Model   |
                     |
                   -----------------------
                  | Service Orchestration |
                   -----------------------
                     |
                     |     Service             +-------------+
                     |     Delivery    +------>| Application |
                     |     Model       |       |   BSS/OSS   |
                     |                 V       +-------------+
                   -----------------------
                  | Network Orchestration |
                   -----------------------
                     |            |
             +----------------+   |
             | Config manager |   |
             +----------------+   |  Device
                     |            |  Models
                     |            |
          --------------------------------------------
                            Network

                      Figure 6: The L2SM Service Architecture

    6.4.  The MEF Architecture

       The MEF Forum (MEF) has developed an architecture for network
       management and operation.  It is documented as the Lifecycle Service
       Orchestration (LSO) Reference Architecture and is illustrated in
       Figure 2 of [MEF-55].

       The work of the MEF embraces all aspects of Lifecycle Service
       Orchestration, including billing, SLAs, order management, and
       lifecycle management.  The IETF's work on service models is typically
       smaller and offers a simple, self-contained service YANG module.
       This does not invalidate either approach: it only observes that they
       are different approaches.

    Wu, et al.                    Informational                    [Page 17]

    RFC 8309                Service Models Explained            January 2018

    7.  Further Concepts

       This section introduces a few further, more advanced concepts.

    7.1.  Technology Agnostic

       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.

       However, some technologies reach to the customer site and impact the
       type of service delivered.  Such features do need to be described in
       the service model.

       Two examples are as follows:

       o  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.

       o  Protocols that are run between customer equipment and network
          operator equipment (for example, Operations, Administration, and
          Maintenance (OAM) protocols, protocols for discovery, or protocols
          for exchanging routing information) need to be selected and
          configured as part of the service description.

    7.2.  Relationship to Policy

       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 and that are acted on by
       the network operator.

       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 offerings of
       all network operators.  Policies that describe which person working
       for 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 offerings
       of all network operators.

       As with commercial terms and SLAs discussed in Section 5, it is
       expected that some network operators will enhance standard customer
       service models to include policy parameters either using their own

    Wu, et al.                    Informational                    [Page 18]

    RFC 8309                Service Models Explained            January 2018

       work or depending on specific policy models built in the IETF or
       other standards bodies.

       Nevertheless, policy is so important that all service models should
       be designed to be easily extensible to allow policy components to be
       added and associated with services as needed.

    7.3.  Operator-Specific Features

       When work on the 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.  However, the working group was
       able to agree on a core set of features that multiple network
       operators were willing to consider as "common".  They also understood
       that, should an individual network operator want to describe
       additional features (operator-specific features), they could do so by
       extending or augmenting the L3SM model.

       Thus, when a basic description of a core service is agreed upon and
       documented in a service model, it is important that that model 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 be varied from one environment to another.

    7.4.  Supporting Multiple Services

       Network operators will, in general, offer many different services to
       their customers.  Each would normally be the subject of a separate
       service model.

       Whether each service model is handled by a specialized service
       orchestrator that is able to provide tuned behavior for a specific
       service, or whether all service models are handled by a single
       service orchestrator, is an implementation and deployment choice.

       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
       element is the postal address of the customer.

       It is anticipated that, while access to such information from each
       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
       by index.

    Wu, et al.                    Informational                    [Page 19]

    RFC 8309                Service Models Explained            January 2018

    8.  Security Considerations

       The interface between customer and service provider is a commercial
       interface, and it needs to be subject to appropriate confidentiality.
       Additionally, knowledge of what services are provided to a customer
       or delivered by a network operator may supply information that can be
       used in a variety of security attacks.  The service model itself will
       expose security-related parameters for the specific service where the
       related function is available to the customer.

       Clearly, the ability to modify information exchanges between customer
       and network operator may result in bogus requests, unwarranted
       billing, and false expectations.  Furthermore, in an automated
       system, modifications to service requests or the injection of bogus
       requests may lead to attacks on the network and delivery of customer
       traffic to the wrong place.

       Therefore, it is important that the protocol interface used to
       exchange service request information between customer and network
       operator is subject to authorization, authentication, and encryption.
       Clearly, the level of abstraction provided by a service model
       protects the operator from unwarranted visibility into their network,
       and additional protection is provided by the fact that how the
       service is delivered is entirely up to the operator.

       Equally, all external interfaces, such as any of those between the
       functional components in Figure 3, need to be correctly secured.
       This document discusses modeling the information, not how it is
       exchanged.

    9.  Manageability Considerations

       This whole document discusses issues related to network management
       and control.

       It is important to observe that automated service provisioning
       resulting from use of a customer service model may result in rapid
       and significant changes in traffic load within a network and that
       that might have an effect on other services carried in a network.

       It is expected, therefore, that a service-orchestration component has
       awareness of other service commitments, that the network-
       orchestration component will not commit network resources to fulfill
       a service unless doing so is appropriate, and that a feedback loop
       will be provided to report on degradation of the network that will
       impact the service.

    Wu, et al.                    Informational                    [Page 20]

    RFC 8309                Service Models Explained            January 2018

       The operational state of a service does not form part of a customer
       service model.  However, it is likely that a network operator may
       want to report some state information about various components of the
       service and that could be achieved through extensions to the core
       service model, just as SLA extensions could be made as described in
       Section 5.

    10.  IANA Considerations

       This document does not require any IANA actions.

    11.  References

    11.1.  Normative References

       [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
                  Information Models and Data Models", RFC 3444,
                  DOI 10.17487/RFC3444, January 2003,
                  <https://www.rfc-editor.org/info/rfc3444>.

       [RFC8199]  Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
                  Classification", RFC 8199, DOI 10.17487/RFC8199, July
                  2017, <https://www.rfc-editor.org/info/rfc8199>.

    11.2.  Informative References

       [BGP-L3VPN-YANG]
                  Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S.,
                  Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model
                  for BGP/MPLS L3 VPNs", Work in Progress, draft-dhjain-
                  bess-bgp-l3vpn-yang-02, August 2016.

       [EVPN-YANG]
                  Brissette, P., Sajassi, A., Shah, H., Li, Z.,
                  Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data
                  Model for EVPN", Work in Progress, draft-ietf-bess-evpn-
                  yang-03, October 2017.

       [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.,
                  and K. Tiruveedhula, "YANG Data Model for MPLS-based
                  L2VPN", Work in Progress, draft-ietf-bess-l2vpn-yang-07,
                  October 2017.

    Wu, et al.                    Informational                    [Page 21]

    RFC 8309                Service Models Explained            January 2018

       [MEF-55]   MEF Forum, "Lifecycle Service Orchestration (LSO):
                  Reference Architecture and Framework", Service Operations
                  Specification MEF 55, March 2016.

       [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
                  the Network Configuration Protocol (NETCONF)", RFC 6020,
                  DOI 10.17487/RFC6020, October 2010,
                  <https://www.rfc-editor.org/info/rfc6020>.

       [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
                  and A. Bierman, Ed., "Network Configuration Protocol
                  (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
                  <https://www.rfc-editor.org/info/rfc6241>.

       [RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
                  Networking: A Perspective from within a Service Provider
                  Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
                  <https://www.rfc-editor.org/info/rfc7149>.

       [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
                  Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
                  <https://www.rfc-editor.org/info/rfc7223>.

       [RFC7297]  Boucadair, M., Jacquenet, C., and N. Wang, "IP
                  Connectivity Provisioning Profile (CPP)", RFC 7297,
                  DOI 10.17487/RFC7297, July 2014,
                  <https://www.rfc-editor.org/info/rfc7297>.

       [RFC7407]  Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
                  SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
                  December 2014, <https://www.rfc-editor.org/info/rfc7407>.

       [RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
                  Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
                  Defined Networking (SDN): Layers and Architecture
                  Terminology", RFC 7426, DOI 10.17487/RFC7426, January
                  2015, <https://www.rfc-editor.org/info/rfc7426>.

       [RFC7491]  King, D. and A. Farrel, "A PCE-Based Architecture for
                  Application-Based Network Operations", RFC 7491,
                  DOI 10.17487/RFC7491, March 2015,
                  <https://www.rfc-editor.org/info/rfc7491>.

       [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
                  RFC 7950, DOI 10.17487/RFC7950, August 2016,
                  <https://www.rfc-editor.org/info/rfc7950>.

    Wu, et al.                    Informational                    [Page 22]

    RFC 8309                Service Models Explained            January 2018

       [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
                  Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
                  <https://www.rfc-editor.org/info/rfc8040>.

       [RFC8049]  Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
                  Model for L3VPN Service Delivery", RFC 8049,
                  DOI 10.17487/RFC8049, February 2017,
                  <https://www.rfc-editor.org/info/rfc8049>.

    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

       Qin Wu
       Huawei Technologies

       Email: bill.wu@huawei.com

       Will Liu
       Huawei Technologies

       Email: liushucheng@huawei.com

       Adrian Farrel
       Juniper Networks

       Email: afarrel@juniper.net

    Wu, et al.                    Informational                    [Page 23]