<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) --> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]> "rfc2629-xhtml.ent">

<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude"
     docName="draft-ietf-opsawg-model-automation-framework-10"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?> number="8969"
     ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
     category="info" consensus="true" xml:lang="en" tocInclude="true"
     symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="Service and &amp; Network Management Automation">A Framework for
    Automating Service and Network Management with YANG</title>
    <seriesInfo name="RFC" value="8969"/>
    <author fullname="Qin Wu" initials="Q." role="editor" surname="Wu">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street> Avenue</street>
	  <cityarea>Yuhua District</cityarea>
	  <city>Nanjing</city>
          <region>Jiangsu</region>

          <code>210012</code>
          <country>China</country>
        </postal>
        <email>bill.wu@huawei.com</email>
      </address>
    </author>
    <author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Boucadair">
      <organization>Orange</organization>
      <address>
        <postal>
          <street>Rennes 35000</street>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <author fullname="Diego R. Lopez " initials="D." surname="Lopez">
      <organization>Telefonica I+D</organization>
      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Spain</country>
        </postal>
        <email>diego.r.lopez@telefonica.com</email>
      </address>
    </author>
    <author fullname="Chongfeng Xie" initials="C." surname="Xie">
      <organization>China Telecom</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>xiechf@chinatelecom.cn</email>
      </address>
    </author>
    <author fullname="Liang Geng" initials="L." surname="Geng">
      <organization>China Mobile</organization>
      <address>
        <email>gengliang@chinamobile.com</email>
      </address>
    </author>
    <date year="2020" year="2021" month="January" />
    <area>OPS Area</area>
    <workgroup>OPSAWG</workgroup>
    <keyword>Model Driven, YANG Driven</keyword>
    <keyword>YANG Data Model</keyword>
    <keyword>automation</keyword>
    <keyword>service delivery</keyword>
    <keyword>notification</keyword>
    <keyword>SDN</keyword>
    <abstract>

      <t>Data models provide a programmatic approach to represent services and
      networks. Concretely, they can be used to derive configuration
      information for network and service components, and state information
      that will be monitored and tracked.

Data models can be used during the service and network management life cycle, such as cycle
(e.g., service instantiation, service provisioning, service optimization,
service monitoring, diagnostic, service diagnosing, and
      assurance. service assurance).

Data models are also instrumental in the automation of network management, and
they can provide closed-loop control for adaptive and deterministic service
creation, delivery, and maintenance.</t>
      <t>This document describes a framework for service and network
      management automation that takes advantage of YANG modeling
      technologies. This framework is drawn from a network operator
      perspective irrespective of the origin of a data model; thus, it can thus
      accommodate YANG modules that are developed outside the IETF.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>

      <t>Service management systems usually comprise service
      activation/provision and service operation. Current service delivery
      procedures, from the processing of customer requirements and orders to
      service delivery and operation, typically assume the manipulation of
      data sequentially into multiple Operations Support System (OSS) or
      Business Support System (BSS) applications that may be managed by
      different departments within the service provider's organization (e.g.,
      billing factory, design factory, network operation center). Many of
      these applications have been developed in-house in house over the years and
      operate in a silo mode:<list style="symbols">
          <t>The mode. As a result:</t>

      <ul spacing="normal">
        <li>The lack of standard data input/output (i.e., data model) raises
          many challenges in system integration and often results in manual
          configuration tasks.</t>

          <t>Service tasks.</li>
        <li>Service fulfillment systems might have a limited visibility on
          the network state and may therefore have a slow response to network
          changes.</t>
        </list></t>

      <t>Software Defined
          changes.</li>
      </ul>
      <t>Software-Defined Networking (SDN) becomes crucial to address these
      challenges. SDN techniques are meant to automate the overall service
      delivery procedures and typically rely upon standard data models.  These
      models are used to not only to reflect service providers' savoir-faire, savoir faire, but
      also to dynamically instantiate and enforce a set of service-inferred
      policies that best accommodate what has been defined and possibly
      negotiated with the customer. <xref target="RFC7149"></xref> target="RFC7149" format="default"/>
      provides a first tentative attempt to rationalize that service
      provider's view on the SDN space by identifying concrete technical
      domains that need to be considered and for which solutions can be provided: <list
          style="symbols">
          <t>Techniques
      provided. These include: </t>
      <ul spacing="normal">
        <li>Techniques for the dynamic discovery of topology, devices, and
          capabilities, along with relevant information and data models that
          are meant to precisely document such topology, devices, and their
          capabilities.</t>

          <t>Techniques
          capabilities.</li>
        <li>Techniques for exposing network services <xref
          target="RFC8309"></xref> target="RFC8309"
        format="default"/> and their characteristics.</t>

          <t>Techniques characteristics.</li>
        <li>Techniques used by service-derived dynamic resource allocation
          and policy enforcement schemes, so that networks can be programmed
          accordingly.</t>

          <t>Dynamic
          accordingly.</li>
        <li>Dynamic feedback mechanisms that are meant to assess how
          efficiently a given policy (or a set thereof) is enforced from a
          service fulfillment and assurance perspectives.</t>
        </list></t> perspective.</li>
      </ul>
      <t>Models are key for each of the aforementioned four technical items. items above.
      Service and network management automation is an important step to
      improve the agility of network operations. Models are also important to
      ease integrating multi-vendor solutions.</t>
      <t>YANG <xref target="RFC7950"></xref> module <xref target="RFC7950" format="default"/> developers have
      taken both top-down and bottom-up approaches to develop modules <xref
      target="RFC8199"></xref>
      target="RFC8199" format="default"/> and to establish a mapping between a
      network technology and customer requirements at the top or abstracting
      common constructs from various network technologies at the bottom.

At the time of writing this document (2020), there are many YANG data models models,
including configuration and service models models, that have been specified or are
being specified by the IETF. They cover many of the networking protocols and
techniques. However, how these models work together to configure a function,
manage a set of devices involved in a service, or provide a service is
something that is not currently documented either within the IETF or other
Standards Development Organizations (SDOs).</t>
      <t>Many of the YANG modules listed in this document are used to exchange
      data between NETCONF/RESTCONF clients and servers <xref
      target="RFC6241"></xref><xref target="RFC8040"></xref>. target="RFC6241"
      format="default"/><xref target="RFC8040"
      format="default"/>. Nevertheless, YANG is a transport-independent data
      modeling language. It can thus be used independently of NETCONF/RESTONF.
      NETCONF/RESTCONF. For example, YANG can be used to define abstract data
      structures <xref target="RFC8791"></xref> target="RFC8791" format="default"/> that can be
      manipulated by other protocols (e.g., <xref
      target="I-D.ietf-dots-rfc8782-bis"></xref>).</t>
      target="I-D.ietf-dots-rfc8782-bis" format="default"/>).</t>
      <t>This document describes an architectural framework for service and
      network management automation (<xref target="concept"></xref>) target="concept"
      format="default"/>) that takes advantage of YANG modeling technologies
      and investigates how YANG data models at different layers interact with
      each other (e.g., service
      mapping, Service Mapping, model composition) in the context of
      service delivery and fulfillment (<xref target="compo"></xref>). target="compo"
      format="default"/>). Concretely, the following benefits can be provided: <list style="symbols">
          <t>Allow for vendor-agnostic
      </t>
      <ul spacing="normal">
        <li>Vendor-agnostic interfaces to manage managing a service and the
          underlying network.</t>

          <t>Move network are allowed.</li>
        <li>Movement from deployment schemes where vendor-specific network
          managers are required to a scheme where the entities that are
          responsible for orchestrating and controlling services and network
          resources provided by multi-vendor devices are unified.</t>

          <t>Ease data unified is allowed.</li>
        <li>Data inheritance and reusability among the various
          architecture layers thus promoting a network-wise provisioning
          instead of device-specific configuration.</t>

          <t>Dynamically feed configuration is eased.</li>
        <li>Dynamically feeding a decision-making process (e.g., Controllers,
          Orchestrators) with notifications that will trigger appropriate
          actions, allowing that decision-making process to continuously
          adjust a network (and thus, thus the involved resources) to deliver the
          service that conforms to the intended parameters (service
          objectives).</t>
        </list></t>
          objectives) is allowed.</li>
      </ul>
      <t>This framework is drawn from a network operator perspective
      irrespective of the origin of a data model; it can also accommodate YANG
      modules that are developed outside the IETF. The document covers service
      models that are used by an operator to expose its services and capture
      service requirements from the customers (including other operators).
      Nevertheless, the document does not elaborate on the communication
      protocol(s) that makes use of these service models in order to request
      and deliver a service. Such considerations are out of scope.</t>
      <t>The document identifies a list of use cases to exemplify the proposed
      approach (<xref target="examples"></xref>), target="examples" format="default"/>), but it does not claim nor
      aim to be exhaustive. <xref target="app"></xref> target="app" format="default"/> lists some examples to
      illustrate the layered YANG modules view.</t>
    </section>
    <section title="Terminology and Acronyms">
      <t></t>

      <section title="Terminology"> numbered="true" toc="default">
      <name>Terminology and Abbreviations</name>
      <t/>
      <section numbered="true" toc="default">
        <name>Terminology</name>
        <t>The following terms are defined in <xref
        target="RFC8309"></xref><xref target="RFC8199"></xref> target="RFC8309"
        format="default"/> and <xref target="RFC8199" format="default"/> and are
        not redefined here:<list style="symbols">
            <t>Network Operator</t>

            <t>Customer</t>

            <t>Service</t>

            <t>Data Model</t>

            <t>Service Model</t>

            <t>Network here:</t>
        <ul spacing="normal">
          <li>Network Operator</li>
          <li>Customer</li>
          <li>Service</li>
          <li>Data Model</li>
          <li>Service Model</li>
          <li>Network Element Module</t>
          </list></t> Model</li>
        </ul>

        <t>In addition, the document makes use of the following terms: <list
            style="hanging">
            <t hangText="Network Model:">Describes </t>
        <dl newline="true" spacing="normal">
          <dt>Network Model:</dt>
          <dd>
            <t>Describes a network level network-level abstraction
            (or a subset of aspects of a network infrastructure), including
            devices and their subsystems, and relevant protocols operating at
            the link and network layers across multiple devices. This model
            corresponds to the network configuration model discussed in <xref
            target="RFC8309"></xref>.<vspace blankLines="1" />It target="RFC8309" format="default"/>.</t>
            <t>It can be used
            by a network operator to allocate resources (e.g., tunnel
            resource, topology resource) for the service or schedule resources
            to meet the service requirements defined in a service model.</t>

            <t hangText="Network Domain:">Refers
          </dd>
          <dt>Network Domain:</dt>
          <dd>Refers to a network partitioning
            that is usually followed by network operators to delimit parts of
            their network. "access network" and "core network" are examples of
            network domains.</t>

            <t hangText="Device Model:">Refers domains.</dd>
          <dt>Device Model:</dt>
          <dd>
            <t>Refers to the Network Element YANG
            data model described in <xref target="RFC8199"></xref> target="RFC8199" format="default"/> or the
            device configuration model discussed in <xref
            target="RFC8309"></xref>.<vspace blankLines="1" />Device target="RFC8309" format="default"/>.</t>
            <t>Device models
            are also used to refer to model a function embedded in a device
            (e.g., Network Address Translation (NAT) <xref
            target="RFC8512"></xref>, target="RFC8512" format="default"/>, Access Control Lists (ACLs) <xref
            target="RFC8519"></xref>).</t>

            <t hangText="Pipe:">Refers target="RFC8519" format="default"/>).</t>
          </dd>
          <dt>Pipe:</dt>
          <dd>Refers to a communication scope where only
            one-to-one (1:1) communications are allowed. The scope can be
            identified between ingress and egress nodes, two service sites,
            etc.</t>

            <t hangText="Hose:">Refers
            etc.</dd>
          <dt>Hose:</dt>
          <dd>Refers to a communication scope where
            one-to-many (1:N) communications are allowed (e.g., one site to
            multiple sites).</t>

            <t hangText="Funnel:">Refers sites).</dd>
          <dt>Funnel:</dt>
          <dd>Refers to a communication scope where
            many-to-one (N:1) communications are allowed.</t>
          </list></t> allowed.</dd>
        </dl>
      </section>
      <section title="Acronyms"> numbered="true" toc="default">
        <name>Abbreviations</name>
        <t>The following acronyms abbreviations are used in the document:<?rfc subcompact="yes" ?></t>

        <t><list hangIndent="8" style="hanging">
            <t hangText="ACL">Access document:</t>
        <dl newline="false" spacing="compact" indent="8">
          <dt>ACL</dt>
          <dd>Access Control List</t>

            <t hangText="AS">Autonomous System</t>

            <t hangText="AP">Access Point</t>

            <t hangText="CE">Customer Edge</t>

            <t hangText="DBE">Data List</dd>
          <dt>AS</dt>
          <dd>Autonomous System</dd>
          <dt>AP</dt>
          <dd>Access Point</dd>
          <dt>CE</dt>
          <dd>Customer Edge</dd>
          <dt>DBE</dt>
          <dd>Data Border Element</t>

            <t hangText="E2E">End-to-End</t>

            <t hangText="ECA">Event Element</dd>
          <dt>E2E</dt>
          <dd>End-to-End</dd>
          <dt>ECA</dt>
          <dd>Event Condition Action</t>

            <t hangText="L2VPN">Layer Action</dd>
          <dt>L2VPN</dt>
          <dd>Layer 2 Virtual Private Network</t>

            <t hangText="L3VPN">Layer Network</dd>
          <dt>L3VPN</dt>
          <dd>Layer 3 Virtual Private Network</t>

            <t hangText="L3SM">L3VPN Service Model</t>

            <t hangText="L3NM">L3VPN Network</dd>
          <dt>L3SM</dt>
          <dd>L3VPN Service Model</dd>
          <dt>L3NM</dt>
          <dd>L3VPN Network Model</t>

            <t hangText="NAT">Network Model</dd>
          <dt>NAT</dt>
          <dd>Network Address Translation</t>

            <t hangText="OAM">Operations, Translation</dd>
          <dt>OAM</dt>
          <dd>Operations, Administration, and Maintenance</t>

            <t hangText="OWD">One-Way Delay</t>

            <t hangText="PE">Provider Edge</t>

            <t hangText="PM">Performance Monitoring</t>

            <t hangText="QoS">Quality of Service</t>

            <t hangText="RD">Route Distinguisher</t>

            <t hangText="RT">Route Target</t>

            <t hangText="SBE">Session Maintenance</dd>
          <dt>OWD</dt>
          <dd>One-Way Delay</dd>
          <dt>PE</dt>
          <dd>Provider Edge</dd>
          <dt>PM</dt>
          <dd>Performance Monitoring</dd>
          <dt>QoS</dt>
          <dd>Quality of Service</dd>
          <dt>RD</dt>
          <dd>Route Distinguisher</dd>
          <dt>RT</dt>
          <dd>Route Target</dd>
          <dt>SBE</dt>
          <dd>Session Border Element</t>

            <t hangText="SDN">Software Defined Networking</t>

            <t hangText="SP">Service Provider</t>

            <t hangText="TE">Traffic Engineering</t>

            <t hangText="VN">Virtual Network</t>

            <t hangText="VPN">Virtual Element</dd>
          <dt>SDN</dt>
          <dd>Software-Defined Networking</dd>
          <dt>SP</dt>
          <dd>Service Provider</dd>
          <dt>TE</dt>
          <dd>Traffic Engineering</dd>
          <dt>VN</dt>
          <dd>Virtual Network</dd>
          <dt>VPN</dt>
          <dd>Virtual Private Network</t>

            <t hangText="VRF">Virtual Network</dd>
          <dt>VRF</dt>
          <dd>Virtual Routing and Forwarding</t>
          </list></t>

        <t><?rfc subcompact="no" ?></t> Forwarding</dd>
        </dl>
        <t/>
      </section>
    </section>
    <section anchor="concept" title="Architectural numbered="true" toc="default">
      <name>Architectural Concepts and Goals"> Goals</name>
      <section anchor="lay" title="Data numbered="true" toc="default">
        <name>Data Models: Layering and Representation"> Representation</name>
        <t>As described in Section 2 of <xref target="RFC8199"></xref>, target="RFC8199"
	sectionFormat="of" section="2"/>,
        layering of modules allows for better reusability of lower-layer
        modules by higher-level modules while limiting duplication of features
        across layers.</t>
        <t>Data models in the context of network management can be classified
        into service, network, and device models. Different service models may
        rely on the same set of network and/or device models.</t>
        <t>Service models traditionally follow a top-down approach and are
        mostly customer-facing YANG modules providing a common model construct
        for higher level higher-level network services (e.g., Layer 3 Virtual Private
        Network (L3VPN)). Such modules can be mapped to network
        technology-specific modules at lower layers (e.g., tunnel, routing,
        Quality of Service (QoS), security). For example, service models can
        be used to characterise characterize the network service(s) to be ensured between
        service nodes (ingress/egress) such as: <?rfc subcompact="yes" ?><list
            style="symbols">
            <t>the </t>
        <ul spacing="compact">

          <li>the communication scope (pipe, hose, funnel, ...),</t>

            <t>the etc.),</li>
          <li>the directionality (inbound/outbound),</t>

            <t>the (inbound/outbound),</li>
          <li>the traffic performance guarantees expressed using metrics such
            as One-Way Delay (OWD) <xref target="RFC7679"></xref> target="RFC7679" format="default"/> or One-Way
            Loss <xref target="RFC7680"></xref>; target="RFC7680" format="default"/>; a summary of performance
            metrics maintained by IANA can be found in <xref
            target="IPPM"></xref>,</t>

            <t>link target="IPPM" format="default"/>,</li>
          <li>link capacity <xref target="RFC5136"></xref> target="RFC5136" format="default"/> <xref
            target="I-D.ietf-ippm-capacity-metric-method"></xref>,</t>

            <t>etc.<?rfc subcompact="no" ?></t>
          </list></t> target="I-D.ietf-ippm-capacity-metric-method" format="default"/>,</li>
          <li>etc.</li>
        </ul>
        <t><xref target="service_ex"></xref> target="service_ex" format="default"/> depicts the example of
        a VoIP Voice over IP (VoIP) service that relies upon connectivity services
        offered by a network operator. In this example, the VoIP service is
        offered to the network operator's customers by Service Provider 1
        (SP1). In order to provide global VoIP reachability, SP1 service site Service Site
        interconnects with other Service Providers service sites typically by
        interconnecting Session Border Elements (SBEs) and Data Border
        Elements (DBEs) <xref
        target="RFC5486"></xref><xref target="RFC6406"></xref>. target="RFC5486" format="default"/><xref
        target="RFC6406" format="default"/>. For other VoIP destinations,
        sessions are forwarded over the Internet. These connectivity services
        can be captured in a YANG service model that reflects the service
        attributes that are shown in <xref
        target="service_ex2"></xref>. target="service_ex2"/>. This example follows
        the IP Connectivity Provisioning Profile template defined in <xref
        target="RFC7297"></xref>.</t>

        <t>In reference to <xref target="service_ex2"></xref>, "Full traffic
        performance guarantees class" refers to a service class where all
        traffic performance metrics included in the service model (OWD, loss,
        delay variation) are guaranteed, while "Delay traffic performance
        guarantees class" refers to a service class where only OWD is
        guaranteed.</t>

        <t><figure anchor="service_ex"
            title="An
        target="RFC7297" format="default"/>.</t>

        <figure anchor="service_ex">
          <name>An Example of Service Connectivity Components"> Components</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[           ,--,--,--.              ,--,--,--.
        ,-'    SP1   `-.        ,-'   SP2     `-.
       ( Service Site   )      ( Service Site    )
        `-.          ,-'        `-.          ,-'
           `--'--'--'              `--'--'--'
            x  | o *                  * |
         (2)x  | o *                  * |
           ,x-,--o-*-.    (1)     ,--,*-,--.
        ,-' x    o  * * * * * * * * *       `-.
       (    x    o       +----(     Internet    )
User---(x x x      o o o o o o o o o o o o o o o o o o
        `-.          ,-'       `-.          ,-'   (3)
           `--'--'--'             `--'--'--'
        Network Operator

**** (1) Inter-SP connectivity
xxxx (2) Customer to SP Customer-to-SP connectivity
oooo (3) SP to any destination connectivity
]]></artwork>
          </figure></t>

        <t><figure align="center" anchor="service_ex2"
            title="Sample
        </figure>

        <t>In reference to <xref target="service_ex2"/>, "Full traffic
        performance guarantees class" refers to a service class where all
        traffic performance metrics included in the service model (OWD, loss,
        delay variation) are guaranteed, while "Delay traffic performance
        guarantees class" refers to a service class where only OWD is
        guaranteed.</t>

 <figure anchor="service_ex2">
          <name>Sample Attributes Captured in a Service Model">
            <artwork><![CDATA[Connectivity: Model</name>
<sourcecode>
<![CDATA[Connectivity: Scope and Guarantees
   (1) Inter-SP connectivity
      - Pipe scope from the local to the remote SBE/DBE
      - Full traffic performance guarantees class
   (2) Customer to SP Customer-to-SP connectivity
      - Hose/Funnel scope connecting the local SBE/DBE
        to the customer access points
      - Full traffic performance guarantees class
   (3) SP to any destination connectivity
      - Hose/Funnel scope from the local SBE/DBE to the
        Internet gateway
      - Delay traffic performance guarantees class
Flow Identification
   * Destination IP address (SBE, DBE)
   * DSCP marking
Traffic Isolation
   * VPN
Routing & Forwarding
   * Routing rule to exclude some ASes from the inter-domain
     paths
Notifications (including feedback)
   * Statistics on aggregate traffic to adjust capacity
   * Failures
   * Planned maintenance operations
   * Triggered by thresholds
]]></artwork>
          </figure></t> thresholds]]>
</sourcecode>
 </figure>

    <t>Network models are mainly network resource-facing network-resource-facing modules; they
        describe various aspects of a network infrastructure, including
        devices and their subsystems, and relevant protocols operating at the
        link and network layers across multiple devices (e.g., network
        topology and traffic-engineering tunnel modules).</t>
        <t>Device (and function) models usually follow a bottom-up approach
        and are mostly technology-specific modules used to realize a service
        (e.g., BGP, ACL).</t>
        <t>Each level maintains a view of the supported YANG modules provided
        by lower levels (see for example, <xref target="app"></xref>). target="app"
        format="default"/>).  Mechanisms such as the YANG library <xref target="RFC8525"></xref>
        target="RFC8525" format="default"/> can be used to expose which YANG
        modules are supported by nodes in lower levels.</t>
        <t><xref target="layering"></xref> target="layering" format="default"/> illustrates the overall
        layering model. The reader may refer to Section 4 of <xref
        target="RFC8309"></xref> target="RFC8309"
        sectionFormat="of" section="4"/> for an overview of "Orchestrator" and
        "Controller" elements. All these elements (i.e., Orchestrator(s),
        Controller(s), device(s)) are under the responsibility of the same
        operator.</t>
        <figure align="center" anchor="layering"
                title="Layering anchor="layering">
          <name>Layering and Representation Within within a Network Operator"> Operator</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+-----------------------------------------------------------------+
|                                         Hierarchy Abstraction   |
|                                                                 |
| +-----------------------+                    Service Model      |
| |    Orchestrator       |                 (Customer Oriented)   |
| |+---------------------+|               Scope: "1:1" Pipe model |
| ||  Service Modeling   ||                                       |
| |+---------------------+|                                       |
| |                       |                   Bidirectional       |
| |+---------------------+|              +-+  Capacity, OWD +-+   |
| ||Service Orchestration||              | +----------------+ |   |
| |+---------------------+|              +-+                +-+   |
| +-----------------------+            Ingress             Egress |
|                                                                 |
|                                                                 |
| +-----------------------+                Network Model          |
| |   Controller          |             (Operator Oriented)       |
| |+---------------------+|           +-+    +--+    +---+   +-+  |
| || Network Modeling    ||           | |    |  |    |   |   | |  |
| |+---------------------+|           | o----o--o----o---o---o |  |
| |                       |           +-+    +--+    +---+   +-+  |
| |+---------------------+|           src                    dst  |
| ||Network Orchestration||                L3VPN over TE          |
| |+---------------------+|        Instance Name/Access Interface |
| +-----------------------+      Protocol Type/Capacity/RD/RT/... |
|                                                                 |
|                                                                 |
| +-----------------------+                 Device Model          |
| |    Device             |                                       |
| |+--------------------+ |                                       |
| || Device Modeling    | |           Interface add, BGP Peer,    |
| |+--------------------+ |              Tunnel ID, QoS/TE, ...   |
| +-----------------------+                                       |
+-----------------------------------------------------------------+]]></artwork>
        </figure>

        <t></t>
        <t/>
        <t>A composite service offered by a network operator may rely on
        services from other operators. In such a case, the network operator acts
        as a customer to request services from other networks. The operators
        providing these services will then follow the layering depicted in
        <xref target="layering"></xref>. target="layering" format="default"/>. The mapping between a
        composite service and a third-party service is maintained at the
        orchestration level. From a data plane data-plane perspective, appropriate
        traffic steering policies (e.g., Service Function Chaining <xref
        target="RFC7665"></xref>)
        target="RFC7665" format="default"/>) are managed by the network
        controllers to guide how/when a third party third-party service is invoked for
        flows bound to a composite service.</t>
        <t>The layering model depicted in <xref target="layering"></xref> target="layering" format="default"/> does
        not make any assumption about the location of the various entities
        (e.g., controller, orchestrator) Controller, Orchestrator) within the network. As such, the
        architecture does not preclude deployments where, for example, the
        controller
        Controller is embedded on a device that hosts other functions that are
        controlled via YANG modules.</t>
        <t>In order to ease the mapping between layers and data reuse, this
        document focuses on service models that are modelled modeled using YANG.
        Nevertheless, fully compliant with Section 3 of <xref
        target="RFC8309"></xref>, target="RFC8309"
        sectionFormat="of" section="3"/>, <xref target="layering"></xref> target="layering"
        format="default"/> does not preclude service models to be modelled modeled
        using other data modelling modeling languages other than YANG.</t>
      </section>
      <section anchor="del" title="Automation numbered="true" toc="default">
        <name>Automation of Service Delivery Procedures"> Procedures</name>
        <t>Service models can be used by a network operator to expose its
        services to its customers. Exposing such models allows to automate automation of the
        activation of service orders and thus the service delivery. One or
        more monolithic service models can be used in the context of a
        composite service activation request (e.g., delivery of a caching
        infrastructure over a VPN). Such models are used to feed a
        decision-making intelligence to adequately accommodate customer's customer        needs.</t>
        <t>Also, such models may be used jointly with services that require
        dynamic invocation. An example is provided by the service modules
        defined by the DOTS WG to dynamically trigger requests to handle
        Distributed Denial-of-Service (DDoS) attacks <xref
        target="RFC8783"></xref>. target="RFC8783"
        format="default"/>. The service filtering request modelled modeled using <xref target="RFC8783"></xref>
        target="RFC8783" format="default"/> will be translated into
        device-specific filtering (e.g., ACLs defined in <xref target="RFC8519"></xref>)
        target="RFC8519" format="default"/>) that
        fulfils fulfills the service
        request.</t>

        <t>Network

<t>
 Network models can be derived from service models and used to provision,
 monitor, and instantiate the service, and service. Also, they are used to provide lifecycle
 life-cycle management of network resources.  Doing so is meant to:</t>

        <t><list style="symbols">
            <t>expose to:
</t>

        <ul spacing="normal">
          <li>expose network resources to customers (including other network
            operators) to provide service fulfillment and assurance.</t>

            <t>allow assurance.</li>
          <li>allow customers (or network operators) to dynamically adjust the
          network resources based on service requirements as described in
          service models (e.g., <xref target="service_ex2"></xref>) target="service_ex2" />) and the
          current network performance information described in the telemetry modules.</t>
          </list></t>
          modules.</li>
        </ul>
        <t>Note that it is out of the scope of this document to elaborate on
        the communication protocols that are used to implement the interface
        between the service ordering (customer) and service order handling
        (provider).</t>
      </section>
      <section anchor="ful" title="Service numbered="true" toc="default">
        <name>Service Fulfillment Automation"> Automation</name>
        <t>To operate a service, the settings of the parameters in the device
        models are derived from service models and/or network models and are
        used to:</t>

        <t><list style="symbols">
            <t>Provision
        <ul spacing="normal">
          <li>Provision each involved network function/device with the proper
            configuration information.</t>

            <t>Operate information.</li>
          <li>Operate the network based on service requirements as described
            in the service model(s) and local operational guidelines.</t>
          </list></t> guidelines.</li>
        </ul>
        <t>In addition, the operational state including configuration that is
        in effect together with statistics should be exposed to upper layers
        to provide better network visibility and assess to what extent the
        derived low level low-level modules are consistent with the upper level upper-level
        inputs.</t>
        <t>Filters are enforced on the notifications that are communicated to
        Service layers. The type and frequency of notifications may be agreed
        upon in the service model.</t>

        <t>Note that it is important to correlate telemetry data with
        configuration data to be used for closed loops at the different stages
        of service delivery, from resource allocation to service operation, in
        particular.</t>
      </section>
      <section anchor="int" title="YANG Modules Integration"> numbered="true" toc="default">
        <name>YANG Module Integration</name>
        <t>To support top-down service delivery, YANG modules at different
        levels or at the same level need to be integrated together for proper
        service delivery (including, (including proper network setup). For example, the
        service parameters captured in service models need to be decomposed
        into a set of configuration/notification parameters that may be
        specific to one or more technologies; these technology-specific
        parameters are grouped together to define technology-specific device
        level
        device-level models or network level network-level models.</t>

        <t>In addition, these technology-specific device or network models can
        be further integrated with each other using the schema mount mechanism
        <xref target="RFC8528"></xref> target="RFC8528" format="default"/> to provision each involved network
        function/device or each involved network domain to support newly added
        modules or features. A collection of integrated device models integrated together
        can be loaded and validated during implementation.</t>
        <t>High-level policies can be defined at service or network models
        (e.g., "Autonomous System Number (ASN) Exclude" in the example
        depicted in <xref target="service_ex2"></xref>). target="service_ex2"/>). Device models will be tweaked accordingly
        to provide policy-based management. Policies can also be used for
        telemetry automation, e.g., policies that contain conditions to
        trigger the generation and pushing of new telemetry data.</t>
      </section>
    </section>
    <section anchor="compo" title="Functional numbered="true" toc="default">
      <name>Functional Blocks and Interactions"> Interactions</name>
      <t>The architectural considerations described in <xref
      target="concept"></xref> target="concept"
      format="default"/> lead to the lifecycle life-cycle management architecture
      illustrated in <xref target="arc"></xref> target="arc" format="default"/> and described in the following
      subsections.</t>
      <figure anchor="arc" title="Service anchor="arc">
        <name>Service and Network Lifecycle Management"> Life-Cycle Management</name>

<artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[

                +------------------+
.................
............... |                  |
 Service level  |                  |
                V                  |
  E2E          E2E                E2E                    E2E
Service --> Service --------->  Service  ------------>  Service
Exposure    Creation     ^    Optimization   ^          Diagnosis
           /Modification |                   |              |
              ^ |        |Diff               |              |
    E2E       | |        |         E2E       |              |
  Service ----+ |        |        Service    |              |
 Decommission   |        +------ Assurance --+              |
                |                     ^                     |
 Multi-layer    |                     |                     |
 Multi-domain   |                     |                     |
 Service Mapping|                     |                     |
.................
............... |<-----------------+  |                     |
 Network level  |                  |  +-------+             v
                V                  |          |         Specific
            Specific           Specific       |          Service
            Service  -------->  Service <--+  |         Diagnosis
            Creation     ^    Optimization |  |             |
          /Modification  |                 |  |             |
                |        |Diff             |  |             |
                |        |      Specific --+  |             |
       Service  |        |       Service      |             |
  Decomposition |        +----- Assurance ----+             |
                |                  ^                        |
.................
............... |                  |  Aggregation           |
 Device level   |                  +------------+           |
                V                               |           |
Service      Intent                             |           v
Fulfillment  Config  ----> Config  ----> Performance ----> Fault
             Provision     Validation    Monitoring        Diagnostic
]]></artwork>

      </figure>
      <section anchor="details" title="Service Lifecycle numbered="true" toc="default">
        <name>Service Life-Cycle Management Procedure"> Procedure</name>
        <t>Service lifecycle life-cycle management includes end-to-end service lifecycle life-cycle
        management at the service level and technology specific technology-specific network
        lifecycle
        life-cycle management at the network level.</t>
        <t>The end-to-end service lifecycle life-cycle management is
        technology-independent service management and spans across multiple
        network domains and/or multiple layers while technology specific technology-specific
        service lifecycle life-cycle management is technology domain specific domain-specific or layer
        specific
        layer-specific service lifecycle life-cycle management.</t>
        <section anchor="expo" title="Service Exposure"> numbered="true" toc="default">
          <name>Service Exposure</name>
          <t>A service in the context of this document (sometimes called,
          Network Service) called
          "Network Service") is some form of connectivity between customer sites
          and the Internet or between customer sites across the operator's
          network and across the Internet.</t>
          <t>Service exposure is used to capture services offered to customers
          (ordering and order handling). One example is that a customer can
          use a an L3VPN Service Model (L3SM) to request L3VPN service by
          providing the abstract technical characterization of the intended
          service between customer sites.</t>

          <t>Service model catalogs can be created along to expose the various
          services and the information needed to invoke/order a given
          service.</t>
        </section>
        <section anchor="crea" title="Service Creation/Modification"> numbered="true" toc="default">
          <name>Service Creation/Modification</name>
          <t>A customer is usually 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. This service request can be filled using a service
          model.</t>
          <t>Upon receiving a service request, and assuming that appropriate
          authentication and authorization checks have been made with success,
          the service orchestrator/management Orchestrator/management system should verify whether the
          service requirements in the service request can be met (i.e.,
          whether there are sufficient resources that can be allocated with
          the requested guarantees).</t>
          <t>If the request is accepted, the service orchestrator/management Orchestrator/management
          system maps such a service request to its view. This view can be
          described as a technology specific technology-specific network model or a set of
          technology specific
          technology-specific device models models, and this mapping may include a
          choice of which networks and technologies to use depending on which
          service features have been requested.</t>
          <t>In addition, a customer may require to a change in the underlying
          network infrastructure to adapt to new customer's customers' needs and service
          requirements (e.g., service a new customer site, add a new access
          link, or provide disjoint paths). This service modification can be
          issued following the same service model used by the service
          request.</t>
          <t>Withdrawing a service is discussed in <xref
          target="decom"></xref>.</t> target="decom" format="default"/>.</t>
        </section>
        <section title="Service Assurance"> numbered="true" toc="default">
          <name>Service Assurance</name>

          <t>The performance measurement telemetry (<xref
          target="fulm"></xref>) target="tele"
          format="default"/>) can be used to provide service assurance at
          Service
          service and/or Network network levels. Performance The performance measurement telemetry
          model can tie with service or network models to monitor network
          performance or Service Level Agreement.</t> Agreements.</t>
        </section>
        <section anchor="optim" title="Service Optimization"> numbered="true" toc="default">
          <name>Service Optimization</name>
          <t>Service optimization is a technique that gets the configuration
          of the network updated due to network changes, incident mitigation,
          or new service requirements. One example is once a tunnel or a VPN
          is setup, Performance set up, performance monitoring information or telemetry
          information per tunnel (or per VPN) can be collected and fed into
          the management system. If the network performance doesn't meet the
          service requirements, the management system can create new VPN
          policies capturing network service requirements and populate them
          into the network.</t>
          <t>Both network performance information and policies can be modelled modeled
          using YANG. With Policy-based management, self-configuration and
          self-optimization behavior can be specified and implemented.</t>
          <t>The overall service optimization is managed at the service level,
          while the network level is responsible for the optimization of the
          specific network services it provides.</t>
        </section>
        <section anchor="diag" title="Service Diagnosis"> numbered="true" toc="default">
          <name>Service Diagnosis</name>
          <t>Operations, Administration, and Maintenance (OAM) are important
          networking functions for service diagnosis that allow network
          operators to:<list style="symbols">
              <t>monitor to:</t>
          <ul spacing="normal">
            <li>monitor network communications (i.e., reachability
              verification and Continuity Check)</t>

              <t>troubleshoot Check)</li>
            <li>troubleshoot failures (i.e., fault verification and
              localization)</t>

              <t>monitor service-level
              localization)</li>
            <li>monitor service level agreements and performance (i.e.,
              performance management)</t>
            </list></t> management)</li>
          </ul>
          <t>When the network is down, service diagnosis should be in place to
          pinpoint the problem and provide recommendations (or instructions)
          for the network recovery.</t>
          <t>The service diagnosis information can be modelled modeled as
          technology-independent Remote Procedure Call (RPC) operations for
          OAM protocols and technology-independent abstraction of key OAM
          constructs for OAM protocols <xref target="RFC8531"></xref><xref
          target="RFC8533"></xref>. target="RFC8531" format="default"/><xref target="RFC8533" format="default"/>. These models can be used to provide
          consistent configuration, reporting, and presentation for the OAM
          mechanisms used to manage the network.</t>
          <t>Refer to <xref target="dev-diag"></xref> target="dev-diag" format="default"/> for the device-specific
          side.</t>
        </section>
        <section anchor="decom" title="Service Decommission"> numbered="true" toc="default">
          <name>Service Decommission</name>
          <t>Service decommission allows a customer to stop the service by
          removing the service from active status and status, thus releasing the
          network resources that were allocated to the service. Customers can
          also use the service model to withdraw the subscription to a
          service.</t>
        </section>
      </section>
      <section anchor="fulm" title="Service Fullfillment numbered="true" toc="default">
        <name>Service Fulfillment Management Procedure"> Procedure</name>
        <section anchor="intended" title="Intended numbered="true" toc="default">
          <name>Intended Configuration Provision"> Provision</name>
          <t>Intended configuration at the device level is derived from
          network models at the network level or service model models at the service
          level and represents the configuration that the system attempts to
          apply. Take L3SM as a service model example to deliver a an L3VPN
          service,
          service; there is a need to map the L3VPN service view defined in
          the service model into a detailed intended configuration view
          defined by specific configuration models for network elements; the elements. The
          configuration information includes:<list style="symbols">
              <t>Virtual includes:</t>
          <ul spacing="normal">
            <li>Virtual Routing and Forwarding (VRF) definition, including
              VPN policy expression</t>

              <t>Physical Interface(s)</t>

              <t>IP expression</li>
            <li>Physical Interface(s)</li>
            <li>IP layer (IPv4, IPv6)</t>

              <t>QoS IPv6)</li>
            <li>QoS features such as classification, profiles, etc.</t>

              <t>Routing etc.</li>
            <li>Routing protocols: support of configuration of all protocols
              listed in a service request, as well as routing policies
              associated with those protocols.</t>

              <t>Multicast support</t>

              <t>Address sharing</t>

              <t>Security protocols</li>
            <li>Multicast support</li>
            <li>Address sharing</li>
            <li>Security (e.g., access control, authentication,
              encryption)</t>
            </list></t>
              encryption)</li>
          </ul>
          <t>These specific configuration models can be used to configure
          Provider Edge (PE) and Customer Edge (CE) devices within a site,
          e.g., a BGP policy model can be used to establish VPN membership
          between sites and VPN Service Topology.</t> service topology.</t>
          <t>Note that in networks with legacy devices (that support
          proprietary modules or do not support YANG at all), an adaptation
          layer is likely to be required at the network level so that these
          devices can be involved in the delivery of the network services.</t>
          <t>This interface is also used to handle service withdrawal (<xref
          target="decom"></xref>).</t> target="decom" format="default"/>).</t>
        </section>
        <section title="Configuration Validation"> numbered="true" toc="default">
          <name>Configuration Validation</name>
          <t>Configuration validation is used to validate intended
          configuration and ensure the configuration take takes effect.</t>
          <t>For example, if a customer creates an interface "eth-0/0/0" but
          the interface does not physically exist at this point, then
          configuration data appears in the &lt;intended&gt; status but does
          not appear in the &lt;operational&gt; datastore. More details about
          &lt;intended&gt; and &lt;operational&gt; datastores can be found in
          Section 5.1 of
          <xref target="RFC8342"></xref>.</t> target="RFC8342" sectionFormat="of" section="5.1"/>.</t>
        </section>
        <section anchor="tele" title="Performance Monitoring"> numbered="true" toc="default">
          <name>Performance Monitoring</name> <t>When a configuration is in
          effect in a device, the &lt;operational&gt; datastore holds the
          complete operational state of the device device, including learned, system,
          default configuration, and system state. However, the configurations
          and state of a particular device does do not have the visibility on the
          whole network or network, nor can they show how packets are going to be
          forwarded through the entire network.  Therefore, it becomes more
          difficult to operate the entire network without understanding the
          current status of the network.</t>

          <t>The management system should subscribe to updates of a YANG
          datastore in all the network devices for performance monitoring
          purposes and build a full topological visibility of the network by
          aggregating (and filtering) these operational state states from different
          sources.</t>
        </section>
        <section anchor="dev-diag" title="Fault Diagnostic"> numbered="true" toc="default">
          <name>Fault Diagnostic</name>
          <t>When configuration is in effect in a device, some devices may be
          mis-configured
          misconfigured (e.g., device links are not consistent in both sides
          of the network connection) or network resources might be
          mis-allocated.
          misallocated. Therefore, services may be negatively affected
          without knowing the root cause in the network.</t>
          <t>Technology-dependent nodes and RPC commands are defined in
          technology-specific YANG data models models, which can use and extend the
          base model described in <xref target="diag"></xref> target="diag" format="default"/> to deal with
          these issues.</t>
          <t>These RPC commands received in the technology-dependent node can
          be used to trigger technology-specific OAM message exchanges for
          fault verification and fault isolation.

For example, TRILL Multicast Transparent Interconnection of Lots of Links (TRILL)
Multi-destination Tree Verification (MTV) RPC command <xref
          target="I-D.ietf-trill-yang-oam"></xref>
target="I-D.ietf-trill-yang-oam" format="default"/> can be used to trigger
Multi-Destination Tree Verification Message Messages (MTVMs) defined in <xref
          target="RFC7455"></xref>
target="RFC7455" format="default"/> to verify TRILL distribution tree
integrity.</t>
        </section>

      </section>
      <section anchor="inter" title="Multi-Layer/Multi-Domain numbered="true" toc="default">
        <name>Multi-layer/Multi-domain Service Mapping"> Mapping</name>
        <t>Multi-layer/Multi-domain Service Mapping allows to map the mapping of an
        end-to-end abstract view of the service segmented at different layers
        and/or different network domains into domain-specific views.</t>
        <t>One example is to map service parameters in the L3SM into
        configuration parameters such as Route Distinguisher (RD), Route
        Target (RT), and VRF in the L3VPN Network Model (L3NM).</t>
        <t>Another example is to map service parameters in the L3SM into
        Traffic Engineered (TE) tunnel parameters (e.g., Tunnel ID) in TE
        model and Virtual Network (VN) parameters (e.g., Access Point (AP)
        list,
        list and VN members) in the YANG data model for VN operation <xref
        target="I-D.ietf-teas-actn-vn-yang"></xref>.</t>
        target="I-D.ietf-teas-actn-vn-yang" format="default"/>.</t>
      </section>
      <section anchor="dec" title="Service Decomposition"> numbered="true" toc="default">
        <name>Service Decomposition</name>
        <t>Service Decomposition allows to decompose service models at the
        service level or network models at the network level into a set of
        device models at the device level. These device models may be tied to
        specific device types or classified into a collection of related YANG
        modules based on service types and features offered, and they may load at the
        implementation time before configuration is loaded and validated.</t>
      </section>
    </section>
    <section anchor="examples" title="YANG numbered="true" toc="default">
      <name>YANG Data Model Integration Examples"> Examples</name>
      <t>The following subsections provide some YANG data models model integration
      examples.</t>
      <section title="L2VPN/L3VPN numbered="true" toc="default">
        <name>L2VPN/L3VPN Service Delivery"> Delivery</name>
        <t>In reference to <xref target="l3"></xref>, target="l3" format="default"/>, the following steps are
        performed to deliver the L3VPN service within the network management
        automation architecture defined in <xref target="compo"></xref>: <list
            style="numbers"> target="compo" format="default"/>: </t>
        <ol spacing="normal" type="1"><li>

            <t>The Customer requests to create two sites (as per Service
            Creation in <xref target="intended"></xref>) target="crea" format="default"/>) relying upon L3SM
            with each site having one network access connectivity, for
            example:<list style="symbols">
                <t>Site
            example:</t>
            <ul spacing="normal">
              <li>Site A: network-access A, link-capacity = 20 Mbps, class
                "foo", guaranteed-capacity-percent = 10, average-one-way-delay
                = 70 ms.</t>

                <t>Site ms.</li>
              <li>Site B: network-access B, link-capacity = 30 Mbps, class
                "foo1", guaranteed-capacity-percent = 15,
                average-one-way-delay = 60 ms.</t>
              </list></t>

            <t>The ms.</li>
            </ul>
          </li>

          <li>The Orchestrator extracts the service parameters from the L3SM.
          Then, it uses them as input to the Service Mapping in <xref
            target="inter"></xref>
          target="inter" format="default"/> to translate them into an
          orchestrated configuration parameters (e.g., RD, RT, and VRF) that are
          part of the L3NM specified in <xref
            target="I-D.ietf-opsawg-l3sm-l3nm"></xref>.</t>

            <t>The
          target="I-D.ietf-opsawg-l3sm-l3nm" format="default"/>.</li>
          <li>The Controller takes the orchestrated configuration parameters
            in the L3NM and translates them into an orchestrated (Service
            Decomposition in <xref target="dec"></xref>) target="dec" format="default"/>) configuration of
            network elements that are part of, e.g., BGP, QoS, Network
            Instance, IP management, and interface models.</t>
          </list></t> models.</li>
        </ol>
        <t><xref target="I-D.ogondio-opsawg-uni-topology"></xref> target="I-D.ogondio-opsawg-uni-topology" format="default"/> can be used
        for representing, managing, and controlling the User Network Interface
        (UNI) topology.</t>

        <t><figure anchor="l3"
            title="L3VPN
        <figure anchor="l3">
          <name>L3VPN Service Delivery Example (Current)"> (Current)</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[                  L3SM    |
                Service   |
                 Model    |
 +------------------------+------------------------+
 |               +--------V--------+               |
 |               | Service Mapping |               |
 |               +--------+--------+               |
 | Orchestrator           |                        |
 +------------------------+------------------------+
                  L3NM    |     ^ UNI Topology Model
                 Network  |     |
                  Model   |     |
 +------------------------+------------------------+
 |            +-----------V-----------+            |
 |            | Service Decomposition |            |
 |            +--++---------------++--+            |
 |               ||               ||               |
 | Controller    ||               ||               |
 +---------------++---------------++---------------+
                 ||               ||
                 ||     BGP,      ||
                 ||     QoS,      ||
                 ||   Interface,  ||
    +------------+|      NI,      |+------------+
    |             |      IP       |             |
 +--+--+       +--+--+         +--+--+       +--+--+
 | CE1 +-------+ PE1 |         | PE2 +-------+ CE2 |
 +-----+       +-----+         +-----+       +-----+]]></artwork>
          </figure></t>
        </figure>
        <t>L3NM inherits some of the data elements from the L3SM. Nevertheless,
        the L3NM as currently designed in <xref
        target="I-D.ietf-opsawg-l3sm-l3nm"></xref> target="I-D.ietf-opsawg-l3sm-l3nm" format="default"/> does not expose some
        information to the above layer such as the capabilities of an
        underlying network (which can be used to drive service order handling)
        or notifications (to notify subscribers about specific events or
        degradations as per agreed SLAs). Some of this information can be
        provided using, e.g., <xref
        target="I-D.www-opsawg-yang-vpn-service-pm"></xref>. target="I-D.www-opsawg-yang-vpn-service-pm" format="default"/>. A target overall
        model is depicted in <xref target="l3-target"></xref>.</t>

        <t><figure anchor="l3-target"
            title="L3VPN target="l3-target" format="default"/>.</t>
        <figure anchor="l3-target">
          <name>L3VPN Service Delivery Example (Target)"> (Target)</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[                  L3SM    |     ^
                Service   |     |  Notifications
                 Model    |     |
 +------------------------+------------------------+
 |               +--------V--------+               |
 |               | Service Mapping |               |
 |               +--------+--------+               |
 | Orchestrator           |                        |
 +------------------------+------------------------+
                    L3NM  |     ^ UNI Topology Model
                   Network|     | L3NM Notifications
                    Model |     | L3NM Capabilities
 +------------------------+------------------------+
 |            +-----------V-----------+            |
 |            | Service Decomposition |            |
 |            +--++---------------++--+            |
 |               ||               ||               |
 | Controller    ||               ||               |
 +---------------++---------------++---------------+
                 ||               ||
                 ||     BGP,      ||
                 ||     QoS,      ||
                 ||   Interface,  ||
    +------------+|      NI,      |+------------+
    |             |      IP       |             |
 +--+--+       +--+--+         +--+--+       +--+--+
 | CE1 +-------+ PE1 |         | PE2 +-------+ CE2 |
 +-----+       +-----+         +-----+       +-----+
]]></artwork>
          </figure></t>
        </figure>
        <t>Note that a similar analysis can be performed for Layer 2 VPNs
        (L2VPNs). A An L2VPN Service Model (L2SM) is defined in <xref
        target="RFC8466"></xref>,
        target="RFC8466" format="default"/>, while the YANG L2VPN Network YANG
        Model (L2NM) is specified in <xref target="I-D.ietf-opsawg-l2nm"></xref>.</t> target="I-D.ietf-opsawg-l2nm"
        format="default"/>.</t>
      </section>

      <section title="VN Lifecycle Management"> numbered="true" toc="default">
        <name>VN Life-Cycle Management</name>
        <t>In reference to <xref target="lc"></xref>, target="lc" format="default"/>, the following steps are
        performed to deliver the VN service within the network management
        automation architecture defined in <xref target="compo"></xref>:<list
            style="numbers">
            <t>A target="compo" format="default"/>:</t>
        <ol spacing="normal" type="1"><li>A customer makes a request (Service
        Exposure in <xref
            target="expo"></xref>) target="expo" format="default"/>) to create a
        VN. The association between the VN, APs, and VN members is defined in
        the VN YANG module model <xref
            target="I-D.ietf-teas-actn-vn-yang"></xref>.</t>

            <t>The target="I-D.ietf-teas-actn-vn-yang"
        format="default"/>.</li>
          <li>The Orchestrator creates the single abstract node topology based
          on the information captured in the request.</t>

            <t>The request.</li>
          <li>The customer exchanges with the Orchestrator the connectivity
          matrix on the abstract node topology and explicit paths using the TE
          topology model <xref target="RFC8795"></xref>. target="RFC8795" format="default"/>. This
          information can be used to instantiate the VN and setup set up tunnels
          between source and destination endpoints (Service Creation in <xref
            target="crea"></xref>).</t>

            <t>In
          target="crea" format="default"/>).</li>
          <li>In order to provide service assurance (Service Optimization in
          <xref target="optim"></xref>), target="optim" format="default"/>), the telemetry model which that
          augments the VN model and corresponding TE tunnel model can be used
          by the Orchestrator to subscribe to performance measurement
          data. The Controller will then notify the Orchestrator with all the
          parameter changes and network performance changes related to the VN
          topology and the tunnels <xref
            target="I-D.ietf-teas-actn-pm-telemetry-autonomics"></xref>.</t>
          </list></t>

        <t><figure anchor="lc" title="A
          target="I-D.ietf-teas-actn-pm-telemetry-autonomics"
          format="default"/>.</li>
        </ol>
        <figure anchor="lc">
          <name>A VN Service Delivery Example"> Example</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[                        |
                VN      |
                Service |
                Model   |
 +----------------------|--------------------------+
 | Orchestrator         |                          |
 |             +--------V--------+                 |
 |             | Service Mapping |                 |
 |             +-----------------+                 |
 +----------------------+--------------------^-----+
               TE       |         Telemetry  |
               Tunnel   |         Model      |
               Model    |                    |
 +----------------------V--------------------+-----+
 | Controller                                      |
 |                                                 |
 +-------------------------------------------------+

 +-----+      +-----+           +-----+      +-----+
 | CE1 +------+ PE1 |           | PE2 +------+ CE2 |
 +-----+      +-----+           +-----+      +-----+]]></artwork>
          </figure></t>
        </figure>
      </section>
      <section title="Event-based numbered="true" toc="default">
        <name>Event-Based Telemetry in the Device Self Management"> Management</name>
        <t>In reference to <xref target="event"></xref>, target="event" format="default"/>, the
        following steps are performed to monitor state changes of managed
        resources in a network device and provide device self-management self management
        within the network management automation architecture defined in <xref
        target="compo"></xref>: <list style="numbers">
            <t>To
        target="compo" format="default"/>: </t>
        <ol spacing="normal" type="1"><li>To control which state a network
        device should be in or is allowed to be in at any given time, a set of
        conditions and actions are defined and correlated with network events
        (e.g., allow the NETCONF server to send updates only when the value
        exceeds a certain threshold for the first time, but not again until
        the threshold is cleared), which constitute an
            Event/Condition/Action Event Condition Action
        (ECA) policy or an event-driven policy control logic that can be
        executed on the device (e.g., <xref
            target="I-D.wwx-netmod-event-yang"></xref>).</t>

            <t>To target="I-D.wwx-netmod-event-yang"
        format="default"/>).</li>
          <li>To provide a rapid autonomic response that can exhibit
            self-management properties, the Controller pushes the ECA policy
            to the network device and delegates the network control logic to
            the network device.</t>

            <t>The device.</li>
          <li>The network device uses the ECA model to subscribe to the event
          source, e.g., an event stream or datastore state data conveyed to
          the server via YANG Push YANG-Push subscription <xref
            target="RFC8641"></xref>, target="RFC8641"
          format="default"/>, monitors state parameters, and takes simple and
          instant actions when an associated event condition on state
          parameters is met. ECA notifications can be generated as the result
          of actions based on event stream subscription or datastore
          subscription (model-driven telemetry operation discussed in <xref
            target="tele"></xref>).</t>
          </list><figure anchor="event" title="Event-based Telemetry">
          target="tele" format="default"/>).</li>
        </ol>
        <figure anchor="event">
          <name>Event-Based Telemetry</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[     +----------------+
     |                <----+
     |   Controller   |    |
     +-------+--------+    |
             |             |
             |             |
         ECA |             | ECA
       Model |             | Notification
             |             |
             |             |
+------------V-------------+-----+
|Device                    |     |
| +-------+ +---------+ +--+---+ |
| | Event +-> Event   +->Event | |
| | Source| |Condition| |Action| |
| +-------+ +---------+ +------+ |
+--------------------------------+
]]></artwork>
          </figure></t>
        </figure>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>Many of the YANG modules cited in this document define schema for
      data that are is designed to be accessed via network management protocols
      such as NETCONF <xref target="RFC6241"></xref> target="RFC6241" format="default"/> or RESTCONF <xref
      target="RFC8040"></xref>. target="RFC8040" format="default"/>. The lowest NETCONF layer is the secure
      transport layer, and the mandatory-to-implement secure transport is
      Secure Shell (SSH) <xref target="RFC6242"></xref>. target="RFC6242" format="default"/>. The lowest RESTCONF
      layer is HTTPS, and the mandatory-to-implement secure transport is TLS
      <xref target="RFC8446"></xref>.</t> target="RFC8446" format="default"/>.</t>
      <t>The NETCONF access control model <xref target="RFC8341"></xref> target="RFC8341" format="default"/>
      provides the means to restrict access for particular NETCONF or RESTCONF
      users to a preconfigured subset of all available NETCONF or RESTCONF
      protocol operations and content.</t>
      <t>Security considerations specific to each of the technologies and
      protocols listed in the document are discussed in the specification
      documents of each of these protocols.</t>
      <t>In order to prevent leaking sensitive information and the "confused
      deputy" problem <xref target="Hardy"></xref> target="Hardy" format="default"/> in general, special care
      should be considered when translating between the various layers in
      <xref target="compo"></xref> target="compo" format="default"/> or when aggregating data retrieved from
      various sources. Authorization and authentication checks should be
      performed to ensure that a data is available to an authorized entity.
      The network operator must enforce means to protect privacy-related
      information included in customer-facing models.</t>
      <t>To detect misalignment between layers that might be induced by
      misbehaving nodes, upper layers should continuously monitor the
      perceived service (<xref target="optim"></xref>) target="optim" format="default"/>) and should proceed with
      checks to assess that the provided service complies with the expected
      service and that the data reported by an underlying layer is matching
      the perceived service by the above layer. Such checks are the
      responsibility of the service diagnosis (<xref
      target="diag"></xref>).</t> target="diag" format="default"/>).</t>
      <t>When a YANG module includes security-related parameters, it is
      recommended to include the relevant information as part of the service
      assurance to track the correct functioning of the security
      mechanisms.</t>
      <t>Additional considerations are discussed in the following
      subsections.</t>
      <section title="Service Level"> numbered="true" toc="default">
        <name>Service Level</name>
        <t>A provider may rely on services offered by other providers to build
        composite services. Appropriate mechanisms should be enabled by the
        provider to monitor and detect a service disruption from these
        providers. The characterization of a service disruption (including, (including
        mean time between failures, failures and mean time to repair), the escalation
        procedure, and penalties are usually documented in contractual
        agreements (e.g., as described in Section 2.1 of <xref
        target="RFC4176"></xref>). target="RFC4176"
        sectionFormat="of" section="2.1"/>). Misbehaving peer providers will
        thus be identified and appropriate countermeasures will be
        applied.</t>
        <t>The communication protocols that make use of a service model
        between a customer and an operator are out of scope. Relevant security
        considerations should be discussed in the specification documents of
        these protocols.</t>
      </section>
      <section title="Network Level"> numbered="true" toc="default">
        <name>Network Level</name>
        <t>Security considerations specific to the network level are listed
        below:<list style="symbols">
            <t>A
        below:</t>
        <ul spacing="normal">
          <li>A controller may create forwarding loops by mis-configuring misconfiguring the
            underlying network nodes. It is recommended to proceed with tests
            to check the status of forwarding paths regularly or whenever
            changes are made to routing or forwarding processes. Such checks
            may be triggered from the service level owing to the means
            discussed in <xref target="diag"></xref>.</t>

            <t>Some target="diag" format="default"/>.</li>
          <li>Some service models may include a traffic isolation clause that
          is passed down to the network level so that appropriate
          technology-specific actions must be enforced at the underlying
          network (and thus involved network devices) to avoid that such
          traffic is accessible to non-authorized parties. In particular,
          network models may indicate whether encryption is enabled and and, if so,
          expose a list of supported encryption schemes and parameters.
            Refer  Refer,
          for example example, to the encryption feature defined in <xref
            target="I-D.ietf-opsawg-vpn-common"></xref>
          target="I-D.ietf-opsawg-vpn-common" format="default"/> and its use
          in <xref
            target="I-D.ietf-opsawg-l3sm-l3nm"></xref>.</t>
          </list></t> target="I-D.ietf-opsawg-l3sm-l3nm" format="default"/>.</li>
        </ul>
      </section>
      <section title="Device Level"> numbered="true" toc="default">
        <name>Device Level</name>
        <t>Network operators should monitor and audit their networks to detect
        misbehaving nodes and abnormal behaviors. For example, OAM OAM, as
        discussed in <xref target="diag"></xref> target="diag" format="default"/>, can be used for
        that purpose.</t>
        <t>Access to some data requires specific access privilege levels.
        Devices must check that a required access privilege is provided before
        granting access to specific data or performing specific actions.</t>
      </section>
    </section>
    <section title="IANA Considerations">
      <t>There are numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA requests or assignments included in this
      document.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter,
      Adrian Farrel, Christian Huitema, Tommy Pauly, Ines Robles, and Olivier
      Augizeau for the review.</t>

      <t>Many thanks to Robert Wilton for the detailed AD review.</t>

      <t>Thanks to &Eacute;ric Vyncke, Roman Danyliw, Erik Kline, and Benjamin
      Kaduk for the IESG review.</t>
    </section>

    <section title="Contributors">
      <figure>
        <artwork><![CDATA[   Christian Jacquenet
   Orange
   Rennes, 35000
   France
   Email: Christian.jacquenet@orange.com

   Luis Miguel Contreras Murillo
   Telifonica

   Email: luismiguel.contrerasmurillo@telefonica.com

   Oscar Gonzalez de Dios
   Telefonica
   Madrid
   ES

   Email: oscar.gonzalezdedios@telefonica.com

   Weiqiang Cheng
   China Mobile

   Email: chengweiqiang@chinamobile.com

   Young Lee
   Sung Kyun Kwan University

   Email: younglee.tx@gmail.com]]></artwork>
      </figure> actions.</t>
    </section>

  </middle>
  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.7950'?>

      <?rfc include='reference.RFC.6241'?>

      <?rfc include='reference.RFC.8040'?>

      <?rfc include='reference.RFC.6242'?>

      <?rfc include='reference.RFC.8446'?>

      <?rfc include='reference.RFC.8341'?>

<displayreference target="I-D.ietf-opsawg-vpn-common" to="OPSAWG-VPN-COMMON"/>
<displayreference target="I-D.ietf-dots-rfc8782-bis" to="DOTS-DDOS"/>
<displayreference target="I-D.ietf-ippm-capacity-metric-method" to="METRIC-METHOD"/>
<displayreference target="I-D.ietf-opsawg-l2nm" to="OPSAWG-L2NM"/>
<displayreference target="I-D.ietf-opsawg-l3sm-l3nm" to="OPSAWG-L3SM-L3NM"/>
<displayreference target="I-D.www-opsawg-yang-vpn-service-pm" to="OPSAWG-YANG-VPN"/>
<displayreference target="I-D.ietf-teas-yang-te" to="TEAS-YANG-TE"/>
<displayreference target="I-D.ietf-teas-yang-rsvp-te" to="TEAS-YANG-RSVP"/>
<displayreference target="I-D.ietf-teas-yang-path-computation" to="TEAS-YANG-PATH-COMP"/>
<displayreference target="I-D.ietf-idr-bgp-model" to="IDR-BGP-MODEL"/>
<displayreference target="I-D.ietf-rtgwg-qos-model" to="QOS-MODEL"/>
<displayreference target="I-D.ietf-pim-yang" to="PIM-YANG"/>
<displayreference target="I-D.ietf-pim-igmp-mld-snooping-yang" to="SNOOPING-YANG"/>
<displayreference target="I-D.ietf-teas-actn-vn-yang" to="ACTN-VN-YANG"/>
<displayreference target="I-D.ietf-bess-evpn-yang" to="EVPN-YANG"/>
<displayreference target="I-D.ietf-bess-l3vpn-yang" to="L3VPN-YANG"/>
<displayreference target="I-D.ietf-bess-l2vpn-yang" to="L2VPN-YANG"/>
<displayreference target="I-D.ietf-rtgwg-policy-model" to="RTGWG-POLICY"/>
<displayreference target="I-D.ietf-bfd-yang" to="BFD-YANG"/>
<displayreference target="I-D.ietf-spring-sr-yang" to="SPRING-SR-YANG"/>
<displayreference target="I-D.ietf-trill-yang-oam" to="TRILL-YANG-OAM"/>
<displayreference target="I-D.ogondio-opsawg-uni-topology" to="UNI-TOPOLOGY"/>
<displayreference target="I-D.ietf-teas-actn-pm-telemetry-autonomics" to="TEAS-ACTN-PM"/>
<displayreference target="I-D.ietf-ippm-stamp-yang" to="STAMP-YANG"/>
<displayreference target="I-D.ietf-bess-mvpn-yang" to="MVPN-YANG"/>
<displayreference target="I-D.wwx-netmod-event-yang" to="EVENT-YANG"/>
<displayreference target="I-D.clacla-netmod-model-catalog" to="NETMOD-MODEL"/>
<displayreference target="I-D.ietf-ippm-twamp-yang" to="TWAMP-DATA-MODEL"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/>
      </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.8199"?>

      <?rfc include='reference.I-D.ietf-opsawg-vpn-common'?>

      <?rfc include='reference.RFC.8525'?>

      <?rfc include='reference.RFC.8342'?>

      <?rfc include='reference.RFC.7665'?>

      <?rfc include='reference.RFC.4176'?>

      <?rfc include='reference.I-D.ietf-dots-rfc8782-bis'?>

      <?rfc include='reference.RFC.8791'?>

      <?rfc include='reference.RFC.5136'?>

      <?rfc include='reference.RFC.7680'?>

      <?rfc include="reference.RFC.8299"?>

      <?rfc include="reference.RFC.8309"?>

      <?rfc include="reference.RFC.7149"?>

      <?rfc include="reference.RFC.7297"?>

      <?rfc include="reference.RFC.8194"?>

      <?rfc include="reference.RFC.8349"?>

      <?rfc include="reference.RFC.8466"?>

      <?rfc include='reference.RFC.4364'?>

      <?rfc include="reference.RFC.8345"?>

      <?rfc include="reference.RFC.8346"?>

      <?rfc include="reference.RFC.8512"?>

      <?rfc include='reference.RFC.7276'?>

      <?rfc include='reference.RFC.8513'?>

      <?rfc include="reference.RFC.8528"?>

      <?rfc include="reference.RFC.8529"?>

      <?rfc include="reference.RFC.8530"?>

      <?rfc include='reference.RFC.8532'?>

      <?rfc include='reference.RFC.8533'?>

      <?rfc include='reference.RFC.7455'?>

      <?rfc include="reference.RFC.8519"?>

      <?rfc include="reference.RFC.8531"?>

      <?rfc include='reference.RFC.4664'?>

      <?rfc include='reference.RFC.8077'?>

      <?rfc include='reference.RFC.4762'?>

      <?rfc include='reference.RFC.4761'?>

      <?rfc include='reference.RFC.5880'?>

      <?rfc include='reference.RFC.8676'?>

      <?rfc include='reference.RFC.8675'?>

      <?rfc include='reference.RFC.5486'?>

      <?rfc include='reference.RFC.8632'?>

      <?rfc include='reference.RFC.8783'?>

      <?rfc include='reference.RFC.6406'?>

      <?rfc include='reference.RFC.7679'?>

      <?rfc include='reference.RFC.8652'?>

      <?rfc include='reference.RFC.8641'?>

      <?rfc include='reference.I-D.ietf-ippm-capacity-metric-method'?>

      <?rfc include='reference.I-D.ietf-opsawg-l2nm'?>

      <?rfc include='reference.I-D.ietf-opsawg-l3sm-l3nm'?>

      <?rfc include='reference.I-D.www-opsawg-yang-vpn-service-pm'?>

      <?rfc include="reference.RFC.8795"?>

      <?rfc include="reference.I-D.ietf-teas-yang-te"?>

      <?rfc include="reference.I-D.ietf-teas-yang-rsvp-te"?>

      <?rfc include="reference.I-D.ietf-teas-yang-path-computation"?>

      <?rfc include="reference.I-D.ietf-idr-bgp-model"?>

      <?rfc include="reference.I-D.ietf-mpls-base-yang"?>

      <?rfc include="reference.I-D.ietf-rtgwg-qos-model"?>

      <?rfc include="reference.I-D.ietf-pim-yang"?>

      <?rfc include="reference.I-D.ietf-pim-igmp-mld-snooping-yang"?>

      <?rfc include="reference.I-D.ietf-teas-actn-vn-yang"?>

      <?rfc include="reference.I-D.ietf-bess-evpn-yang"?>

      <?rfc include="reference.I-D.ietf-bess-l3vpn-yang"?>

      <?rfc include="reference.I-D.ietf-bess-l2vpn-yang"?>

      <?rfc include="reference.I-D.ietf-rtgwg-policy-model"?>

      <?rfc include="reference.I-D.ietf-bfd-yang"?>

      <?rfc include="reference.I-D.ietf-spring-sr-yang"?>

      <?rfc include="reference.I-D.ietf-trill-yang-oam"?>

      <?rfc include='reference.I-D.ogondio-opsawg-uni-topology'?>

      <?rfc include='reference.I-D.ietf-teas-actn-pm-telemetry-autonomics'?>

      <?rfc include='reference.I-D.ietf-ippm-twamp-yang'?>

      <?rfc include='reference.I-D.ietf-ippm-stamp-yang'?>

      <?rfc include='reference.I-D.ietf-i2rs-yang-l2-network-topology'?>

      <?rfc include='reference.I-D.ietf-bess-mvpn-yang'?>

      <?rfc include='reference.I-D.wwx-netmod-event-yang'?>

      <?rfc include='reference.I-D.ietf-netmod-module-tags'?>

      <?rfc include='reference.I-D.clacla-netmod-model-catalog'?>

      <?rfc include='reference.RFC.7224'?>

      <?rfc include='reference.RFC.8348'?>

      <?rfc include='reference.RFC.7317'?>

      <?rfc include='reference.RFC.8343'?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8199.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-opsawg-vpn-common.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8525.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4176.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-dots-rfc8782-bis.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8791.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5136.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7680.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8299.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8309.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7149.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7297.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8194.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8349.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8466.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8345.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8346.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8512.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7276.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8513.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8528.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8529.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8530.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8532.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8533.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7455.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8519.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8531.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4664.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8077.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4762.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4761.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8676.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8675.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5486.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8632.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8783.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6406.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7679.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8652.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8641.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ippm-capacity-metric-method.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-opsawg-l2nm.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-opsawg-l3sm-l3nm.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.www-opsawg-yang-vpn-service-pm.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8795.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-teas-yang-te.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-teas-yang-rsvp-te.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-teas-yang-path-computation.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-idr-bgp-model.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8960.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-rtgwg-qos-model.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-pim-yang.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-pim-igmp-mld-snooping-yang.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-teas-actn-vn-yang.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-bess-evpn-yang.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-bess-l3vpn-yang.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-bess-l2vpn-yang.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-rtgwg-policy-model.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-bfd-yang.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-spring-sr-yang.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-trill-yang-oam.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ogondio-opsawg-uni-topology.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-teas-actn-pm-telemetry-autonomics.xml"/>

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ippm-twamp-yang.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ippm-stamp-yang.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8944.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-bess-mvpn-yang.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.wwx-netmod-event-yang.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8819.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.clacla-netmod-model-catalog.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7224.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8348.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7317.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/>

        <reference anchor="IPPM" target="https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml">
          <front>
            <title>Performance Metrics</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date day="19" month="March" year="2020" /> year="2020"/>
          </front>
        </reference>

        <reference anchor="Hardy" target="https://dl.acm.org/doi/10.1145/54289.871709">
          <front>
            <title>The Confused Deputy: (or why capabilities might have been
            invented)</title>
            <author fullname="Norm Hardy  " Hardy" surname="Hardy">
            <organization></organization>
              <organization/>
            </author>
            <date month="October" year="1988" /> year="1988"/>
          </front>
<seriesInfo name="DOI" value="10.1145/54289.871709"/>
        </reference>

      </references>
    </references>
    <section anchor="app" title="Layered numbered="true" toc="default">
      <name>Layered YANG Modules Module Examples Overview"> Overview</name>
      <t>This appendix lists a set of YANG data models that can be used for
      the delivery of connectivity services. These models can be classified as
      service, network, or device models.</t>
      <t>It is not the intent of this appendix to provide an inventory of
      tools and mechanisms used in specific network and service management
      domains; such inventory can be found in documents such as <xref
      target="RFC7276"></xref>.</t> target="RFC7276" format="default"/>.</t>
      <t>The reader may refer to the YANG Catalog
      (&lt;https://www.yangcatalog.org&gt;) (&lt;<eref
      target="https://www.yangcatalog.org"/>&gt;) or the public Github YANG
      repository (&lt;https://github.com/YangModels/yang&gt;) (&lt;<eref target="https://github.com/YangModels/yang"/>&gt;) to
      query existing YANG models. The YANG Catalog includes some metadata to
      indicate the module type ('module-classification') <xref
      target="I-D.clacla-netmod-model-catalog"></xref>.
      target="I-D.clacla-netmod-model-catalog" format="default"/>. Note that
      the mechanism defined in <xref target="I-D.ietf-netmod-module-tags"></xref> target="RFC8819" format="default"/>
      allows to associate tags with YANG modules in order to help classifying
      the modules.</t>
      <section anchor="ns" title="Service numbered="true" toc="default">

        <name>Service Models: Definition and Samples"> Samples</name>

        <t>As described in <xref target="RFC8309"></xref>, target="RFC8309" format="default"/>, the
        service is "some form of connectivity between customer sites and the
        Internet
        and/or or between customer sites across the network operator's
        network and across the Internet". More concretely, an IP connectivity
        service can be defined as the IP transfer capability characterized by
        a (Source Nets, Destination Nets, Guarantees, Scope) tuple where
        "Source Nets" is a group of unicast IP addresses, "Destination Nets"
        is a group of IP unicast and/or multicast addresses, and "Guarantees"
        reflects the guarantees (expressed (expressed, for example, in terms of QoS,
        performance, and
        availability, for example) availability) to properly forward traffic to the said
        "Destination" <xref target="RFC7297"></xref>.</t> target="RFC7297" format="default"/>. The "Scope"
        denotes the network perimeter (e.g., between Provider Edge (PE)
        routers or Customer Nodes) where the said guarantees need to be
        provided.</t>

        <t>For example:<list style="symbols">
            <t>The example:</t>
        <ul spacing="normal">
          <li>The L3SM <xref target="RFC8299"></xref> target="RFC8299" format="default"/> defines the L3VPN
            service ordered by a customer from a network operator.</t>

            <t>The operator.</li>
          <li>The L2SM <xref target="RFC8466"></xref> target="RFC8466" format="default"/> defines the L2VPN
            service ordered by a customer from a network operator.</t>

            <t>The operator.</li>
          <li>The Virtual Network (VN) model <xref
            target="I-D.ietf-teas-actn-vn-yang"></xref>
          target="I-D.ietf-teas-actn-vn-yang" format="default"/> provides a
          YANG data model applicable to any mode of VN operation.</t>
          </list></t> operation.</li>
        </ul>
        <t>L2SM and L3SM are customer service models as per <xref
        target="RFC8309"></xref>.</t> target="RFC8309" format="default"/>.</t>
      </section>
      <section title="Schema Mount"> numbered="true" toc="default">

        <name>Schema Mount</name>
        <t>Modularity and extensibility were among the leading design
        principles of the YANG data modeling language. As a result, the same
        YANG module can be combined with various sets of other modules and
        thus form a data model that is tailored to meet the requirements of a
        specific use case. <xref target="RFC8528"></xref> target="RFC8528" format="default"/> defines a mechanism,
        denoted schema mount, "schema mount", that allows for mounting one data model
        consisting of any number of YANG modules at a specified location of
        another (parent) schema.</t>
      </section>
      <section anchor="rm" title="Network numbered="true" toc="default">
        <name>Network Models: Samples"> Samples</name>
        <t>L2NM <xref target="I-D.ietf-opsawg-l2nm"></xref> target="I-D.ietf-opsawg-l2nm" format="default"/> and L3NM <xref
        target="I-D.ietf-opsawg-l3sm-l3nm"></xref> target="I-D.ietf-opsawg-l3sm-l3nm" format="default"/> are examples of YANG
        network models.</t>
        <t><xref target="rfn"></xref> target="rfn" format="default"/> depicts a set of additional network
        models such as topology and tunnel models:</t>
        <figure align="center" anchor="rfn"
                title="Sample Resource Facing anchor="rfn">
          <name>Sample Resource-Facing Network Models"> Models</name>
          <artwork align="center"><![CDATA[+-------------------------------+-------------------------------+ align="center" name="" type="" alt=""><![CDATA[+-------------------------------+-------------------------------+
|      Topology YANG modules    |     Tunnel YANG modules       |
+-------------------------------+-------------------------------+
|  +------------------+         |                               |
|  |Network Topologies|         | +------+  +-----------+       |
|  |       Model      |         | |Other |  | TE Tunnel |       |
|  +--------+---------+         | |Tunnel|  +----+------+       |
|           |   +---------+     | +------+       |              |
|           +---+Service  |     |     +----------+---------+    |
|           |   |Topology |     |     |          |         |    |
|           |   +---------+     |     |          |         |    |
|           |   +---------+     |+----+---+ +----+---+ +---+---+|
|           +---+Layer 3  |     ||MPLS-TE | |RSVP-TE | | SR-TE ||
|           |   |Topology |     || Tunnel | | Tunnel | |Tunnel ||
|           |   +---------+     |+--------+ +--------+ +-------+|
|           |   +---------+     |                               |
|           +---+TE       |     |                               |
|           |   |Topology |     |                               |
|           |   +---------+     |                               |
|           |   +---------+     |                               |
|           +---+Layer 3  |     |                               |
|               |Topology |     |                               |
|               +---------+     |                               |
+-------------------------------+-------------------------------+                                 ]]></artwork>
        </figure>

        <t></t>
        <t/>
        <t>Examples of topology YANG modules are listed below:</t>

        <t><list style="symbols">
            <t>Network

<dl newline="true">

<dt>Network Topologies Model: <xref target="RFC8345"></xref>
</dt>
<dd><xref target="RFC8345" format="default"/> defines a base model for network
topology and inventories. Network topology data include includes link, node, and
terminate-point
            resources.</t>

            <t>TE resources.
</dd>

<dt>TE Topology Model: <xref target="RFC8795"></xref>
</dt>
<dd><t><xref target="RFC8795" format="default"/> defines a YANG data model for
representing and manipulating TE topologies.
            <vspace blankLines="1" />This
	  </t>

  <t>This module is extended from the network topology model defined in <xref target="RFC8345"></xref> with TE
            topologies
  target="RFC8345" format="default"/> and includes content related content. to TE
  topologies. This model contains technology-agnostic TE Topology topology building
  blocks that can be augmented and used by other technology-specific TE
  topology models.</t>

            <t>Layer
</dd>

<dt>Layer 3 Topology Model:<vspace blankLines="1" /><xref
            target="RFC8346"></xref> Model:
</dt>
<dd> <t><xref target="RFC8346" format="default"/> defines a YANG data model
for representing and manipulating Layer 3 topologies. This model is extended
from the network topology model defined in <xref
            target="RFC8345"></xref> with target="RFC8345"
format="default"/> and includes content related to Layer 3 topologies topology specifics.</t>

            <t>Layer
</dd>

<dt>Layer 2 Topology Model:<vspace blankLines="1" /><xref
            target="I-D.ietf-i2rs-yang-l2-network-topology"></xref> Model:
</dt>
<dd> <t><xref target="RFC8944" format="default"/> defines a YANG data model
for representing and manipulating Layer 2 topologies. This model is extended
from the network topology model defined in <xref target="RFC8345"></xref> with target="RFC8345"
format="default"/> and includes content related to Layer 2 topology specifics.</t>
          </list></t>
</dd>

</dl>

        <t>Examples of tunnel YANG modules are provided below:<list
            style="symbols">
            <t>Tunnel identities: <xref target="RFC8675"></xref> below:</t>

<dl newline="true">

<dt>Tunnel Identities:
</dt>
<dd><xref target="RFC8675" format="default"/> defines a collection of YANG
identities used as interface types for tunnel
            interfaces.</t>

            <t>TE interfaces.
</dd>

<dt>TE Tunnel Model:<vspace blankLines="1" /><xref
            target="I-D.ietf-teas-yang-te"></xref> Model:
</dt>
<dd><xref target="I-D.ietf-teas-yang-te" format="default"/> defines a YANG
module for the configuration and management of TE interfaces, tunnels, and
            LSPs.</t>

            <t>Segment
LSPs.
</dd>

<dt>Segment Routing (SR) Traffic Engineering (TE) Tunnel
            Model:<vspace blankLines="1" /><xref
            target="I-D.ietf-teas-yang-te"></xref> Model:
</dt>
<dd><xref target="I-D.ietf-teas-yang-te" format="default"/> augments the TE
generic and MPLS-TE model(s) and defines a YANG module for SR-TE specific
            data.</t>

            <t>MPLS-TE Model:<vspace blankLines="1" /><xref
            target="I-D.ietf-teas-yang-te"></xref> SR-TE-specific
data.
</dd>

<dt>MPLS-TE Model:
</dt>
<dd><xref target="I-D.ietf-teas-yang-te" format="default"/> augments the TE
generic and MPLS-TE model(s) and defines a YANG module for MPLS-TE
configurations, state, RPC RPC, and notifications.</t>

            <t>RSVP-TE notifications.
</dd>

<dt>RSVP-TE MPLS Model:<vspace blankLines="1" /><xref
            target="I-D.ietf-teas-yang-rsvp-te"></xref> Model:
</dt>
<dd><xref target="I-D.ietf-teas-yang-rsvp-te" format="default"/> augments the
RSVP-TE generic module with parameters to configure and manage signaling of
MPLS RSVP-TE LSPs.</t>
          </list></t> LSPs.
</dd>

</dl>

        <t>Other sample network models are listed hereafter:<list
            style="symbols">
            <t>Path hereafter:</t>

<dl newline="true">

<dt>Path Computation API Model:<vspace blankLines="1" /><xref
            target="I-D.ietf-teas-yang-path-computation"></xref> Model:
</dt>

<dd><xref target="I-D.ietf-teas-yang-path-computation" format="default"/>
defines a YANG module for a stateless RPC which that complements the stateful
solution defined in <xref target="I-D.ietf-teas-yang-te"></xref>.</t>

            <t>OAM target="I-D.ietf-teas-yang-te" format="default"/>.
</dd>

<dt>OAM Models (including Fault Management (FM) and Performance
            Monitoring):<vspace blankLines="1" /><xref
            target="RFC8532"></xref> Monitoring):
</dt>
<dd>
 <t><xref target="RFC8532" format="default"/> defines a base YANG module for
 the management of OAM protocols that use Connectionless Communications. <xref target="RFC8533"></xref>
 target="RFC8533" format="default"/> defines a retrieval method YANG module
 for connectionless OAM protocols. <xref
            target="RFC8531"></xref> target="RFC8531" format="default"/>
 defines a base YANG module for connection
            oriented connection-oriented OAM protocols. These three
 models are intended to provide consistent reporting, configuration, and
 representation for
            connection-less connectionless OAM and Connection oriented connection-oriented OAM separately.<vspace
            blankLines="1" />Alarm
 separately.</t>
            <t>Alarm monitoring is a fundamental part of monitoring the
            network. Raw alarms from devices do not always tell the status of
            the network services or necessarily point to the root cause. <xref target="RFC8632"></xref>
            target="RFC8632" format="default"/> defines a YANG module for
            alarm management.</t>
          </list></t>
</dd>

</dl>

      </section>
      <section title="Device numbered="true" toc="default">
        <name>Device Models: Samples"> Samples</name>
        <t>Network Element models (listed in <xref target="device"></xref>) target="device" format="default"/>)
        are used to describe how a service can be implemented by activating
        and tweaking a set of functions (enabled in one or multiple devices,
        or hosted in cloud infrastructures) that are involved in the service
        delivery. For example, the L3VPN service will involve many PEs and
        require manipulating the following modules:</t>

        <t><list style="symbols">
            <t>Routing
        <ul spacing="normal">
          <li>Routing management <xref target="RFC8349"></xref></t>

            <t>BGP <xref target="I-D.ietf-idr-bgp-model"></xref></t>

            <t>PIM <xref target="I-D.ietf-pim-yang"></xref></t>

            <t>NAT target="RFC8349" format="default"/></li>
          <li>BGP <xref target="I-D.ietf-idr-bgp-model" format="default"/></li>
          <li>PIM <xref target="I-D.ietf-pim-yang" format="default"/></li>
          <li>NAT management <xref target="RFC8512"></xref></t>

            <t>QoS target="RFC8512" format="default"/></li>
          <li>QoS management <xref
            target="I-D.ietf-rtgwg-qos-model"></xref></t>

            <t>ACLs <xref target="RFC8519"></xref></t>
          </list><xref target="device"></xref> target="I-D.ietf-rtgwg-qos-model" format="default"/></li>
          <li>ACLs <xref target="RFC8519" format="default"/></li>
        </ul>
        <t><xref target="device" format="default"/> uses IETF-defined data models
        as an example.<figure anchor="device"
            title="Network example.</t>
        <figure anchor="device">
          <name>Network Element Modules Overview">
            <artwork><![CDATA[ Models Overview</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[                                        +------------------------+
                                      +-+     Device Model       |
                                      | +------------------------+
                                      | +------------------------+
                  +---------------+   | |   Logical Network      |
                  |               |   +-+     Element Model      |
                  | Architecture  |   | +------------------------+
                  |               |   | +------------------------+
                  +-------+-------+   +-+ Network Instance Model |
                          |           | +------------------------+
                          |           | +------------------------+
                          |           +-+   Routing Type Model   |
                          |             +------------------------+
  +-------+----------+----+------+------------+-----------+------+
  |       |          |           |            |           |      |
+-+-+ +---+---+ +----+----+   +--+--+    +----+----+   +--+--+   |
|ACL| |Routing| |Transport|   | OAM |    |Multicast|   |  PM | Others
+---+ +-+-----+ +----+----+   +--+--+    +-----+---+   +--+--+
        | +-------+  | +------+  | +--------+  | +-----+  | +-----+
        +-+Core   |  +-+ MPLS |  +-+  BFD   |  +-+IGMP |  +-+TWAMP|
        | |Routing|  | | Base |  | +--------+  | |/MLD |  | +-----+
        | +-------+  | +------+  | +--------+  | +-----+  | +-----+
        | +-------+  | +------+  +-+LSP Ping|  | +-----+  +-+OWAMP|
        +-+  BGP  |  +-+ MPLS |  | +--------+  +-+ PIM |  | +-----+
        | +-------+  | | LDP  |  | +--------+  | +-----+  | +-----+
        | +-------+  | +------+  +-+MPLS-TP |  | +-----+  +-+LMAP |
        +-+  ISIS |  | +------+    +--------+  +-+ MVPN|    +-----+
        | +-------+  +-+ MPLS |                  +-----+
        | +-------+    |Static|
        +-+  OSPF |    +------+
        | +-------+
        | +-------+
        +-+  RIP  |
        | +-------+
        | +-------+
        +-+  VRRP |
        | +-------+
        | +-------+
        +-+SR/SRv6|
        | +-------+
        | +-------+
        +-+ISIS-SR|
        | +-------+
        | +-------+
        +-+OSPF-SR|
          +-------+]]></artwork>
          </figure></t>
        </figure>
        <section title="Model Composition">
          <t><list style="symbols">
              <t>Logical numbered="true" toc="default">
          <name>Model Composition</name>

<dl newline="true">

<dt>Logical Network Element Model<vspace blankLines="1" /><xref
              target="RFC8530"></xref> Model:
</dt>
<dd><xref target="RFC8530" format="default"/> defines a logical network
element
              module which model that can be used to manage the logical resource partitioning
that may be present on a network device. Examples of common industry terms for
logical resource partitioning are Logical Systems or Logical Routers.</t>

              <t>Network Routers.
</dd>

<dt>Network Instance Model<vspace blankLines="1" /><xref
              target="RFC8529"></xref> Model:
</dt>
<dd><xref target="RFC8529" format="default"/> defines a network instance
module. This module can be used to manage the virtual resource partitioning
that may be present on a network device. Examples of common industry terms for
virtual resource partitioning are VRF instances and Virtual Switch Instances (VSIs).</t>
            </list></t>
(VSIs).
</dd>

</dl>

        </section>
        <section title="Device Management "> numbered="true" toc="default">
          <name>Device Management</name>
          <t>The following list enumerates some YANG modules that can be used
          for device management:</t>

          <t><list style="symbols">
              <t><xref target="RFC8348"></xref>:
          <ul spacing="normal">
            <li>
              <xref target="RFC8348" format="default"/> defines a YANG module for the
              management of hardware.</t>

              <t><xref target="RFC7317"></xref>: hardware.</li>
            <li>
              <xref target="RFC7317" format="default"/> defines the "ietf-system"
              YANG module that provides many features such as the
              configuration and the monitoring of system or system control
              operations (e.g., shutdown, restart, and setting time)
              identification.</t>

              <t><xref target="RFC8341"></xref>:
              identification.</li>
            <li>
              <xref target="RFC8341" format="default"/> defines a network
              configuration access control YANG module.</t>
            </list></t> module.</li>
          </ul>
        </section>
        <section title="Interface Management"> numbered="true" toc="default">
          <name>Interface Management</name>
          <t>The following provides some YANG modules that can be used for
          interface management:</t>

          <t><list style="symbols">
              <t><xref target="RFC7224"></xref>:
          <ul spacing="normal">
            <li>
              <xref target="RFC7224" format="default"/> defines a YANG module for
              interface type definitions.</t>

              <t><xref target="RFC8343"></xref>: definitions.</li>
            <li>
              <xref target="RFC8343" format="default"/> defines a YANG module for the
              management of network interfaces.</t>
            </list></t> interfaces.</li>
          </ul>
        </section>
        <section anchor="sample" title="Some numbered="true" toc="default">
          <name>Some Device Model Examples"> Examples</name>
          <t>The following provides an overview of some device models that can
          be used within a network. This list is not comprehensive.<list
              hangIndent="11" style="hanging">
              <t hangText="L2VPN:"><xref
              target="I-D.ietf-bess-l2vpn-yang"></xref> comprehensive.</t>
          <dl newline="true" spacing="normal">
            <dt>L2VPN:</dt>
            <dd>
              <xref target="I-D.ietf-bess-l2vpn-yang" format="default"/>
              defines a YANG module for MPLS based MPLS-based Layer 2 VPN services
              (L2VPN) <xref
              target="RFC4664"></xref> target="RFC4664" format="default"/> and includes
              switching between the local attachment circuits. The L2VPN model
              covers point-to-point
              VPWS Virtual Private Wire Service (VPWS) and
              Multipoint VPLS services. Virtual Private LAN Service (VPLS). These
              services use signaling of Pseudowires across MPLS networks using
              LDP <xref
              target="RFC8077"></xref><xref target="RFC4762"></xref> target="RFC8077" format="default"/><xref
              target="RFC4762" format="default"/> or BGP <xref target="RFC4761"></xref>.</t>

              <t hangText="EVPN:"><xref
              target="I-D.ietf-bess-evpn-yang"></xref>
              target="RFC4761" format="default"/>.</dd>
            <dt>EVPN:</dt>
            <dd>
              <xref target="I-D.ietf-bess-evpn-yang" format="default"/>
              defines a YANG module for Ethernet VPN services. The model is
              agnostic of the underlay. It applies to MPLS as well as to VxLAN
              Virtual eXtensible Local Area Network (VxLAN) encapsulation.
              The module is also agnostic to the services, including E-LAN,
              E-LINE, and E-TREE services.</t>

              <t hangText="L3VPN:"><xref
              target="I-D.ietf-bess-l3vpn-yang"></xref> services.</dd>
            <dt>L3VPN:</dt>
            <dd>
              <xref target="I-D.ietf-bess-l3vpn-yang" format="default"/>
              defines a YANG module that can be used to configure and manage
              BGP L3VPNs <xref
              target="RFC4364"></xref>. target="RFC4364" format="default"/>. It
              contains VRF specific VRF-specific parameters as well as BGP specific BGP-specific
              parameters applicable for L3VPNs.</t>

              <t hangText="Core Routing:"><xref target="RFC8349"></xref> L3VPNs.</dd>
            <dt>Core Routing:</dt>
            <dd>
              <xref target="RFC8349" format="default"/>
              defines the core routing YANG data model, which is intended as a
              basis for future data model development covering
              more-sophisticated routing systems. It is expected that other
              Routing technology YANG modules (e.g., VRRP, RIP, ISIS, or OSPF
              models) will augment the Core Routing base YANG module.</t>

              <t hangText="MPLS:"><xref
              target="I-D.ietf-mpls-base-yang"></xref> module.</dd>
            <dt>MPLS:</dt>
            <dd>
              <xref target="RFC8960" format="default"/> defines a base model
              for MPLS which that serves as a base framework for configuring and
              managing an MPLS switching subsystem. It is expected that other
              MPLS technology YANG modules (e.g., MPLS LSP Static, LDP, or
              RSVP-TE models) will augment the MPLS base YANG module.</t>

              <t hangText="BGP:"><xref target="I-D.ietf-idr-bgp-model"></xref> module.</dd>
            <dt>BGP:</dt>
            <dd>
              <xref target="I-D.ietf-idr-bgp-model" format="default"/>
              defines a YANG module for configuring and managing BGP,
              including protocol, policy, and operational aspects based on
              data center, carrier, and content provider operational
              requirements.</t>

              <t hangText="Routing Policy:"><xref
              target="I-D.ietf-rtgwg-policy-model"></xref>
              requirements.</dd>
            <dt>Routing Policy:</dt>
            <dd>
              <xref target="I-D.ietf-rtgwg-policy-model" format="default"/> defines a YANG
              module for configuring and managing routing policies based on
              operational practice. The module provides a generic policy
              framework which that can be augmented with protocol-specific policy
              configuration.</t>

              <t hangText="SR/SRv6:"><xref
              target="I-D.ietf-spring-sr-yang"></xref>
              configuration.</dd>
            <dt>SR/SRv6:</dt>
            <dd>
              <t><xref target="I-D.ietf-spring-sr-yang" format="default"/>
              defines a YANG module for segment routing configuration and
              operation. <vspace
              blankLines="1" /></t>

              <t hangText="BFD:">Bidirectional </t>
              <t/>
            </dd>
            <dt>BFD:</dt>
            <dd>Bidirectional Forwarding Detection (BFD)
              <xref target="RFC5880"></xref> target="RFC5880" format="default"/> is a network protocol which that is
              used for liveness detection of arbitrary paths between systems.
              <xref target="I-D.ietf-bfd-yang"></xref> target="I-D.ietf-bfd-yang" format="default"/> defines a YANG module
              that can be used to configure and manage BFD.</t>

              <t hangText="Multicast:"><xref
              target="I-D.ietf-pim-yang"></xref> BFD.</dd>
            <dt>Multicast:</dt>
            <dd>
              <t><xref target="I-D.ietf-pim-yang" format="default"/> defines a YANG module that
              can be used to configure and manage Protocol Independent
              Multicast (PIM) devices.<vspace blankLines="1" /><xref
              target="RFC8652"></xref> devices.</t>
              <t><xref target="RFC8652" format="default"/> defines a YANG module that can be used
              to configure and manage Internet Group Management Protocol
              (IGMP) and Multicast Listener Discovery (MLD) devices.<vspace
              blankLines="1" /><xref
              target="I-D.ietf-pim-igmp-mld-snooping-yang"></xref> devices.</t>
              <t><xref target="I-D.ietf-pim-igmp-mld-snooping-yang" format="default"/> defines a
              YANG module that can be used to configure and manage Internet
              Group Management Protocol (IGMP) and Multicast Listener
              Discovery (MLD) Snooping devices.<vspace blankLines="1" /><xref
              target="I-D.ietf-bess-mvpn-yang"></xref> snooping devices.</t>
              <t><xref target="I-D.ietf-bess-mvpn-yang" format="default"/> defines a YANG data
              model to configure and manage Multicast in MPLS/BGP IP VPNs
              (MVPNs).</t>

              <t hangText="PM:"><xref
              target="I-D.ietf-ippm-twamp-yang"></xref>
            </dd>
            <dt>PM:</dt>
            <dd>
              <t><xref target="I-D.ietf-ippm-twamp-yang" format="default"/> defines a YANG data
              model for client and server implementations of the Two-Way
              Active Measurement Protocol (TWAMP).<vspace
              blankLines="1" /><xref target="I-D.ietf-ippm-stamp-yang"></xref> (TWAMP).</t>
              <t><xref target="I-D.ietf-ippm-stamp-yang" format="default"/>
              defines the data model for implementations of Session-Sender and
              Session-Reflector for Simple Two-way Active Measurement Protocol
              (STAMP) mode using YANG. <vspace blankLines="1" /><xref
              target="RFC8194"></xref> </t>
              <t><xref target="RFC8194" format="default"/> defines a YANG data model for
              Large-Scale Measurement Platforms (LMAPs).</t>

              <t hangText="ACL:">Access
            </dd>

            <dt>ACL:</dt>
            <dd>An Access Control List (ACL) is one of the basic
              elements used to configure device forwarding device-forwarding behavior. It is
              used in many networking technologies such as Policy Based Policy-Based
              Routing, firewalls, etc. <xref target="RFC8519"></xref> target="RFC8519" format="default"/>
              describes a YANG data model of ACL basic building blocks.</t>

              <t hangText="QoS:"><xref
              target="I-D.ietf-rtgwg-qos-model"></xref> blocks.</dd>
            <dt>QoS:</dt>
            <dd>
              <xref target="I-D.ietf-rtgwg-qos-model" format="default"/> describes a YANG
              module of Differentiated Services for configuration and
              operations.</t>

              <t hangText="NAT:">For
              operations.</dd>
            <dt>NAT:</dt>
            <dd>
              <t>For the sake of network automation and the need for
              programming the Network Address Translation (NAT) function in
              particular, a YANG data model for configuring and managing the
              NAT is essential.<vspace blankLines="1" /><xref
              target="RFC8512"></xref> essential.</t>
              <t><xref target="RFC8512" format="default"/> defines a YANG module for the NAT
              function covering a variety of NAT flavors such as Network
              Address Translation from IPv4 to IPv4 (NAT44), Network Address
              and Protocol Translation from IPv6 Clients to IPv4 Servers
              (NAT64), customer-side translator (CLAT), Stateless IP/ICMP
              Translation (SIIT), Explicit Address Mappings (EAM) (EAMs) for SIIT,
              IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination
              NAT. <vspace blankLines="1" /><xref target="RFC8513"></xref> </t>
              <t><xref target="RFC8513" format="default"/>
              specifies a DS-Lite Dual-Stack Lite (DS-Lite) YANG module.</t>

              <t hangText="Stateless
            </dd>
            <dt>Stateless Address Sharing:"><xref
              target="RFC8676"></xref> Sharing:</dt>
            <dd>
              <xref target="RFC8676" format="default"/> specifies a YANG
              module for A+P Address plus Port (A+P) address sharing, including
              Lightweight 4over6, Mapping of Address and Port with
              Encapsulation (MAP-E), and Mapping of Address and Port using
              Translation (MAP-T) softwire mechanisms.</t>
            </list></t> mechanisms.</dd>
          </dl>
        </section>
      </section>
    </section>

    <section anchor="ack" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Thanks to <contact fullname="Joe Clark"/>, <contact fullname="Greg
      Mirsky"/>, <contact fullname="Shunsuke Homma"/>, <contact fullname="Brian Carpenter"/>,
      <contact fullname="Adrian Farrel"/>, <contact fullname="Christian
      Huitema"/>, <contact fullname="Tommy Pauly"/>, <contact fullname="Ines
      Robles"/>, and <contact fullname="Olivier
      Augizeau"/> for the review.</t>
      <t>Many thanks to <contact fullname="Robert Wilton"/> for the detailed AD review.</t>
      <t>Thanks to <contact fullname="Éric Vyncke"/>, <contact fullname="Roman
      Danyliw"/>, <contact fullname="Erik Kline"/>, and <contact fullname="Benjamin
      Kaduk"/> for the IESG review.</t>
    </section>
    <section numbered="false" toc="default">
      <name>Contributors</name>

  <contact fullname="Christian Jacquenet">
  <organization>Orange</organization>
  <address>
    <postal>
     <city>Rennes, 35000</city>
     <country>France</country>
    </postal>
    <email>Christian.jacquenet@orange.com</email>
  </address>
  </contact>

  <contact fullname="Luis Miguel Contreras Murillo">
  <organization>Telefonica</organization>
  <address>
    <postal>
     <street></street>
     <city></city>
     <country></country>
    </postal>
    <email>luismiguel.contrerasmurillo@telefonica.com</email>
  </address>
  </contact>

  <contact fullname="Oscar Gonzalez de Dios">
  <organization>Telefonica</organization>
  <address>
    <postal>
     <street></street>
     <city>Madrid</city>
     <country>Spain</country>
    </postal>
    <email>oscar.gonzalezdedios@telefonica.com</email>
  </address>
  </contact>

<contact fullname="Weiqiang Cheng">
  <organization>China Mobile</organization>
  <address>
    <postal>
     <street></street>
     <city></city>
     <country></country>
    </postal>
    <email>chengweiqiang@chinamobile.com</email>
  </address>
</contact>

<contact fullname="Young Lee">
  <organization>Sung Kyun Kwan University</organization>
  <address>
    <postal>
     <street></street>
     <city></city>
     <country></country>
    </postal>
    <email>younglee.tx@gmail.com</email>
  </address>
</contact>

    </section>

  </back>
</rfc>