Service Models Explained
draft-ietf-opsawg-service-model-explained-05

Versions: (draft-wu-opsawg-service-model-explained)        Informational
          00 01 02 03 04 05                                             
OPS Area Working Group                                             Q. Wu
Internet-Draft                                                    W. Liu
Intended status: Informational                       Huawei Technologies
Expires: March 31, 2018                                        A. Farrel
                                                        Juniper Networks
                                                      September 27, 2017


                        Service Models Explained
              draft-ietf-opsawg-service-model-explained-04

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 Three Virtual Private Network Service Model
   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 Customer-Provider Interface.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 31, 2018.






Wu, et al.               Expires March 31, 2018                 [Page 1]


Internet-Draft          Service Models Explained          September 2017


Copyright Notice

   Copyright (c) 2017 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terms and Concepts  . . . . . . . . . . . . . . . . . . . . .   4
   3.  Using Service Models  . . . . . . . . . . . . . . . . . . . .   6
   4.  Service Models in an SDN Context  . . . . . . . . . . . . . .   8
   5.  Possible Causes of Confusion  . . . . . . . . . . . . . . . .  10
   6.  Comparison With Other Work  . . . . . . . . . . . . . . . . .  12
     6.1.  Comparison With Network Service Models  . . . . . . . . .  12
     6.2.  Service Delivery and Network Element Model Work . . . . .  14
     6.3.  Customer Service Model Work . . . . . . . . . . . . . . .  14
     6.4.  The MEF Architecture  . . . . . . . . . . . . . . . . . .  16
   7.  Further Concepts  . . . . . . . . . . . . . . . . . . . . . .  17
     7.1.  Technology Agnostic . . . . . . . . . . . . . . . . . . .  17
     7.2.  Relationship to Policy  . . . . . . . . . . . . . . . . .  17
     7.3.  Operator-Specific Features  . . . . . . . . . . . . . . .  18
     7.4.  Supporting Multiple Services  . . . . . . . . . . . . . .  18
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   9.  Manageability Considerations  . . . . . . . . . . . . . . . .  19
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  20
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     12.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

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]).



Wu, et al.               Expires March 31, 2018                 [Page 2]


Internet-Draft          Service Models Explained          September 2017


   [RFC7950] makes a distinction between a "data model" which it defines
   as describing how data is represented and accessed, and a "YANG
   module" that 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, 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 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
   Three 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 eventually as part of an SDN system.

   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.

   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 Customer-Provider Interface.

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

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





Wu, et al.               Expires March 31, 2018                 [Page 3]


Internet-Draft          Service Models Explained          September 2017


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.

   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 Section 5 and Section 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 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.

      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.




Wu, et al.               Expires March 31, 2018                 [Page 4]


Internet-Draft          Service Models Explained          September 2017


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

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



         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.

         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.

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

   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 be divided into two
      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.  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" [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 (such as
         encapsulations, or mechanisms applied on access links) are
         directly pertinent to the customer, customer service models are



Wu, et al.               Expires March 31, 2018                 [Page 5]


Internet-Draft          Service Models Explained          September 2017


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

   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 describes 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
   simply 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].



Wu, et al.               Expires March 31, 2018                 [Page 6]


Internet-Draft          Service Models Explained          September 2017


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


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

   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.

   The practicality of customer service models has been repeatedly
   debated.  It has been suggested that network operators have radically
   different business modes and widely diverse commercial offerings
   making a common customer service model is impractical.  However, the
   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



Wu, et al.               Expires March 31, 2018                 [Page 7]


Internet-Draft          Service Models Explained          September 2017


   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
   re-use 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 deployment-specific.


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


                    Figure 2: A Sample SDN Architecture

   But a customer's service request is (or should be) technology-
   agnostic.  That is, the technology that the network operator has
   available to deliver the service should not influence the behavior
   and functions that a customer requests.  The orchestrator must map



Wu, et al.               Expires March 31, 2018                 [Page 8]


Internet-Draft          Service Models Explained          September 2017


   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.


                                                 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



Wu, et al.               Expires March 31, 2018                 [Page 9]


Internet-Draft          Service Models Explained          September 2017


   Figure 3 also shows where different data models might be applied
   within the architecture.  The Device Confguration Models are used by
   a Controller to seet parameters on an individual network element.
   The Network Configuration Models are use by a Network Orchestrator to
   instruct Controllers (that may each be responsible for multiple
   network elements) how to configure parts of a network.

   The split between control components that exposes a "service
   interface" that is present in many figures showing 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 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 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



Wu, et al.               Expires March 31, 2018                [Page 10]


Internet-Draft          Service Models Explained          September 2017


      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.

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

   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 encode them as "Network Service
      YANG Modules" and a comparison is provided in Section 6.1.  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.

   o  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.  Thus, this feature is out of scope for
      standardized customer service models.

   o  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



Wu, et al.               Expires March 31, 2018                [Page 11]


Internet-Draft          Service Models Explained          September 2017


      much, and how often.  SLAs are also linked to commercial terms
      with penalties and so forth, and thus are also not good topics for
      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
   add 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 function such as billing and SLAs.








Wu, et al.               Expires March 31, 2018                [Page 12]


Internet-Draft          Service Models Explained          September 2017


       - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
       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 Abstaction Layers Showing Customer Service
                                  Modules




Wu, et al.               Expires March 31, 2018                [Page 13]


Internet-Draft          Service Models Explained          September 2017


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
   configuation 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  [I-D.dhjain-bess-bgp-l3vpn-yang] defines a YANG module that can be
      used to configure and manage BGP L3VPNs.

   o  [I-D.ietf-bess-l2vpn-yang] documents a data 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.

   o  [I-D.ietf-bess-evpn-yang] defines YANG modules for delivering an
      Ethernet VPN service.

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.



















Wu, et al.               Expires March 31, 2018                [Page 14]


Internet-Draft          Service Models Explained          September 2017


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


                  Figure 5: The L3SM Service Architecture

   A Layer Two VPN service model (L2SM) is defined in
   [I-D.ietf-l2sm-l2vpn-service-model].  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.               Expires March 31, 2018                [Page 15]


Internet-Draft          Service Models Explained          September 2017


             ----------------------------
            | 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 has developed an architecture for network management
   and operation.  It is documented as the Lifecycle Service
   Orchestration (LSO) Reference Architecture and illustrated in
   Figure 2 of [MEF-55].

   The work of the MEF Forum embraces all aspects of Lifecycle Service
   Orchestration including billing, SLAs, order management, and life-
   cycle management.  The IETF's work on service models is typically
   smaller offering a simple, self-contained service YANG module.  Thus,
   it may be impractical to fit IETF service models into the MEF Forum
   LSO architecture.  This does not invalidate either approach: it only
   observes that they are different approaches.






Wu, et al.               Expires March 31, 2018                [Page 16]


Internet-Draft          Service Models Explained          September 2017


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 the customer site and make a
   difference to the type of service delivered.  Such features do need
   to be described in the service model.

   Two examples are:

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

   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.               Expires March 31, 2018                [Page 17]


Internet-Draft          Service Models Explained          September 2017


   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 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 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 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.               Expires March 31, 2018                [Page 18]


Internet-Draft          Service Models Explained          September 2017


8.  Security Considerations

   The interface between customer and service provider is a commercial
   interface and 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 functon 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 the fact that it is entirely up to the operator how they deliver
   the service provides additional protection.

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

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.               Expires March 31, 2018                [Page 19]


Internet-Draft          Service Models Explained          September 2017


   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 makes no requests for IANA action.

11.  Acknowledgements

   Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair,
   Luis Miguel Contreras Murillo, Joe Salowey, Benoit Claise, Robert
   Sparks, and Tom Petch 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

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

12.2.  Informative References

   [I-D.dhjain-bess-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", draft-dhjain-bess-bgp-l3vpn-yang-02
              (work in progress), August 2016.








Wu, et al.               Expires March 31, 2018                [Page 20]


Internet-Draft          Service Models Explained          September 2017


   [I-D.ietf-bess-evpn-yang]
              Brissette, P., Sajassi, A., Shah, H., Li, Z.,
              Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data
              Model for EVPN", draft-ietf-bess-evpn-yang-02 (work in
              progress), March 2017.

   [I-D.ietf-bess-l2vpn-yang]
              Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
              and K. Tiruveedhula, "YANG Data Model for MPLS-based
              L2VPN", draft-ietf-bess-l2vpn-yang-06 (work in progress),
              June 2017.

   [I-D.ietf-l2sm-l2vpn-service-model]
              Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data
              Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn-
              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
              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>.



Wu, et al.               Expires March 31, 2018                [Page 21]


Internet-Draft          Service Models Explained          September 2017


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

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

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.               Expires March 31, 2018                [Page 22]