<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml2rfc.tools.ietf.org. --> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3688 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC4026 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4026.xml">
<!ENTITY RFC4176 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4176.xml">
<!ENTITY RFC6020 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6242 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml">
<!ENTITY RFC6991 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml">
<!ENTITY RFC7950 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml">
<!ENTITY RFC8040 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
  <!ENTITY RFC8277 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8277.xml"> nbsp    "&#160;">
  <!ENTITY RFC8299 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8299.xml"> zwsp   "&#8203;">
  <!ENTITY RFC8294 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8294.xml"> nbhy   "&#8209;">
  <!ENTITY RFC8309 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8309.xml">
<!ENTITY RFC8340 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml">
<!ENTITY RFC8341 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml">
<!ENTITY RFC8466 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8466.xml">
<!ENTITY RFC8453 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml">
<!ENTITY RFC8512 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8512.xml">
<!ENTITY RFC8519 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8519.xml">
<!ENTITY RFC8349 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8349.xml">
<!ENTITY RFC8345 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8345.xml"> wj     "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="5"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-opsawg-l3sm-l3nm-18" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" --> number="9182" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="5" symRefs="true" sortRefs="true" version="3">

  <!-- ***** FRONT MATTER ***** xml2rfc v2v3 conversion 3.10.0 -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->
    <title abbrev="L3NM YANG Data Model">A YANG Network Data Model for Layer 3 VPN Network YANG Model</title> VPNs</title>

    <seriesInfo name="RFC" value="9182"/>
    <author fullname="Samier Barguil" initials="S." surname="Barguil">
      <organization>Telefonica</organization>
      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->
          <city>Madrid</city>

          <region></region>

          <code></code>
          <country>Spain</country>
        </postal>

        <phone></phone>
        <email>samier.barguilgiraldo.ext@telefonica.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <author fullname="Oscar Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios">
      <organization>Telefonica</organization>
      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->
          <city>Madrid</city>

          <region></region>

          <code></code>
          <country>Spain</country>
        </postal>

        <phone></phone>
        <email>oscar.gonzalezdedios@telefonica.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Boucadair">
      <organization>Orange</organization>
      <address>
        <postal>
          <street>Rennes 35000</street>
          <city>Rennes</city>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <author fullname="Luis Angel Munoz" initials="L." surname="Munoz">
      <organization>Vodafone</organization>
      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>
          <country>Spain</country>
        </postal>

        <phone></phone>
        <email>luis-angel.munoz@vodafone.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <author fullname="Alejandro Aguado" initials="A." surname="Aguado">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->
          <city>Madrid</city>

          <region></region>

          <code></code>
          <country>Spain</country>
        </postal>

        <phone></phone>
        <email>alejandro.aguado_martin@nokia.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <date day="08" month="October" year="2021" />

    <!-- Meta-data Declarations --> month="February" year="2022"/>

    <area>ops</area>
    <workgroup>OPSAWG</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
  If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>l3vpn</keyword>
    <keyword>Automation</keyword>
    <keyword>Service Provisioning</keyword>
    <keyword>Network Automation</keyword>
    <keyword>Service Orchestration</keyword>
    <keyword>Service Delivery</keyword>
    <keyword>NETCONF</keyword>
    <keyword>RESTCONF</keyword>
    <keyword>Slices</keyword>
    <keyword>network slicing</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>As a complement to the Layer 3 Virtual Private Network Service YANG
      data Model (L3SM), which is used for communication between customers and service
      providers, this document defines an L3VPN Network YANG Model (L3NM) that
      can be used for the provisioning of Layer 3 Virtual Private Network
      (VPN)
      (L3VPN) services within a service provider network. The model provides a
      network-centric view of L3VPN services.</t>

      <t>L3NM
      <t>The L3NM is meant to be used by a network controller to derive the
      configuration information that will be sent to relevant network devices.
      The model can also facilitate the communication between a service
      orchestrator and a network controller/orchestrator.</t>
    </abstract>

    <note title="Editorial Note (To be removed by RFC Editor)">
      <t>Please update these statements within the document with the RFC
      number to be assigned to this document:<list style="symbols">
          <t>"This version of this YANG module is part of RFC XXXX;"</t>

          <t>"RFC XXXX: Layer 3 VPN Network Model";</t>

          <t>reference: RFC XXXX</t>
        </list></t>

      <t>Please update "RFC UUUU" to the RFC number to be assigned to
      I-D.ietf-opsawg-vpn-common.</t>

      <t>Also, please update the "revision" date of the YANG module.</t>
    </note>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC8299"></xref> target="RFC8299" format="default"/> defines a YANG Layer 3 Virtual Private
      Network Service YANG data Model (L3SM) that can be used for
      communication between customers and service providers. Such a model
      focuses on describing the customer view of the Virtual Private Network
      (VPN) services and provides an abstracted view of the customer's
      requested services. That approach limits the usage of the L3SM to the
      role of a customer service model (as per <xref
      target="RFC8309"></xref>).</t> target="RFC8309" format="default"/>).</t>
      <t>This document defines a YANG module called L3VPN the "L3VPN Network Model Model"
      (L3NM). The L3NM is aimed at providing a network-centric view of Layer 3
      (L3) VPN services. This data model can be used to facilitate
      communication between the service orchestrator and the network
      controller/orchestrator by allowing for more network-centric information
      to be included. It enables further capabilities such additional capabilities as resource
      management
      management, or it serves as a multi-domain orchestration interface, interface where
      logical resources (such as route targets or route distinguishers) must
      be coordinated.</t>
      <t>This document uses the common VPN YANG module defined in <xref
      target="I-D.ietf-opsawg-vpn-common"></xref>.</t> target="RFC9181" format="default"/>.</t>
      <t>This document does not obsolete <xref target="RFC8299"></xref>. target="RFC8299" format="default"/>. These
      two modules are used for similar objectives but with different scopes
      and views.</t>
      <t>The L3NM YANG module was initially built with a prune "prune and extend extend"
      approach, taking as a starting points point the YANG module described in <xref
      target="RFC8299"></xref>. target="RFC8299" format="default"/>. Nevertheless, the L3NM is not defined as an
      augment to L3SM the L3SM, because a specific structure is required to meet
      network-oriented L3 needs.</t>
      <t>Some information captured in the L3SM can be passed by the
      orchestrator in the L3NM (e.g., customer) or be used to feed some L3NM
      attributes (e.g., actual forwarding policies). Also, some information
      captured in the L3SM may be maintained locally within the orchestrator; orchestrator,
      which is in charge of maintaining the correlation between a customer
      view and its network instantiation. Likewise, some information captured
      and exposed using the L3NM can feed the service layer (e.g.,
      capabilities) to drive VPN service order handling, handling and thus the
      L3SM.</t>

      <t>Section 5.1 of <xref target="RFC8969"></xref>
      <t><xref target="RFC8969" sectionFormat="of" section="5.1"/> illustrates how the
      L3NM can be used within the network management automation
      architecture.</t>
      <t>The L3NM does not attempt to address all deployment cases, especially
      those where the L3VPN connectivity is supported through the coordination
      of different VPNs in different underlying networks. More complex
      deployment scenarios involving the coordination of different VPN
      instances and different technologies to provide an end-to-end VPN
      connectivity are addressed by complementary YANG modules, e.g., <xref
      target="I-D.evenwu-opsawg-yang-composed-vpn"></xref>.</t> target="YANG-Composed-VPN" format="default"/>.</t>
      <t>The L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs based on BGP Provider Edges (PEs) as
      described in <xref target="RFC4026"></xref><xref
      target="RFC4110"></xref><xref target="RFC4364"></xref> target="RFC4026" format="default"/>, <xref target="RFC4110" format="default"/>, and <xref target="RFC4364" format="default"/>; and Multicast
      VPNs as described in <xref target="RFC6037"></xref><xref
      target="RFC6513"></xref>.</t> target="RFC6037" format="default"/> and <xref target="RFC6513" format="default"/>.</t>
      <t>The YANG data model in this document conforms to the Network
      Management Datastore Architecture (NMDA) defined in <xref
      target="RFC8342"></xref>.</t> target="RFC8342" format="default"/>.</t>
    </section>
    <section anchor="terminology" title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
      "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
      "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
      "<bcp14>SHOULD NOT</bcp14>",
      "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
      "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
      are to be interpreted as described in BCP 14 BCP&nbsp;14
      <xref target="RFC2119"></xref> target="RFC2119"/> <xref target="RFC8174"></xref> target="RFC8174"/> when, and only
      when, they appear in all capitals, as shown here.</t>
      <t>This document assumes that the reader is familiar with the contents
      of <xref target="RFC6241"></xref>, target="RFC6241" format="default"/>, <xref target="RFC7950"></xref>, target="RFC7950" format="default"/>, <xref
      target="RFC8299"></xref>, target="RFC8299" format="default"/>, <xref target="RFC8309"></xref>, target="RFC8309" format="default"/>, and <xref
      target="RFC8453"></xref> target="RFC8453" format="default"/> and uses the terminology defined in those
      documents.</t>
      <t>This document uses the term "network model" as defined in Section 2.1 of <xref target="RFC8969"></xref>.</t> target="RFC8969" sectionFormat="of" section="2.1"/>.</t>
      <t>The meaning meanings of the symbols in the tree diagrams is are defined in <xref
      target="RFC8340"></xref>.</t> target="RFC8340" format="default"/>.</t>
      <t>This document makes use of the following terms:</t>

      <t><list style="hanging">
          <t hangText="Layer
      <dl newline="false" spacing="normal">
        <dt>Layer 3 VPN Customer Service Model (L3SM):">A (L3SM):</dt>
        <dd>A YANG
          module data model that describes the service requirements of an L3VPN that
          interconnects a set of sites from the point of view of the customer.
          The customer service model does not provide details on the service
          provider network. The L3VPN customer service model is defined in
          <xref target="RFC8299"></xref>.</t>

          <t hangText="Layer target="RFC8299" format="default"/>.</dd>
        <dt>Layer 3 VPN Service Network Model (L3NM):">A (L3NM):</dt>
        <dd>A YANG
          module data model that describes a VPN service in the service provider network.
          It contains information of on the service provider network and might
          include allocated resources. It can be used by network controllers
          to manage and control the VPN service configuration in the service
          provider network. The corresponding YANG module can be consumed used by a service
          orchestrator to request a VPN service to a network controller.</t>

          <t hangText="Service orchestrator:">A controller.</dd>
        <dt>Service orchestrator:</dt>
        <dd>A functional entity that
          interacts with the customer of an L3VPN. The service orchestrator
          interacts with the customer using the L3SM. The service orchestrator
          is responsible for the Customer Edge (CE) - to Provider Edge (PE) (CE-PE)
          attachment circuits, the PE selection, and requesting the VPN
          service to the network controller.</t>

          <t hangText="Network orchestrator:">A controller.</dd>
        <dt>Network orchestrator:</dt>
        <dd>A functional entity that is
          hierarchically intermediate between a service orchestrator and
          network controllers. A network orchestrator can manage one or
          several network controllers.</t>

          <t hangText="Network controller:">A controllers.</dd>
        <dt>Network controller:</dt>
        <dd>A functional entity responsible
          for the control and management of the service provider network.</t>

          <t hangText="VPN node:">An network.</dd>
        <dt>VPN node:</dt>
        <dd>An abstraction that represents a set of
          policies applied on a PE and that belong belonging to a single VPN service. A
          VPN service involves one or more VPN nodes. As it is an abstraction,
          the network controller will take on decide how to implement a VPN node. For
          example, typically, in a BGP-based VPN, a VPN node could typically be mapped
          into
          to a Virtual Routing and Forwarding (VRF).</t>

          <t hangText="VPN (VRF) instance.</dd>
        <dt>VPN network access:">An access:</dt>
        <dd>An abstraction that represents the
          network interfaces that are associated to with a given VPN node. Traffic
          coming from the VPN network access belongs to the VPN. The
          attachment circuits (bearers) between CEs and PEs are terminated in
          the VPN network access. A reference to the bearer is maintained to
          allow keeping the link between the L3SM and L3NM when both models are
          used in a given deployment.</t>

          <t hangText="VPN site: ">A deployment.</dd>
        <dt>VPN site:</dt>
        <dd>A VPN customer's location that is connected
          to the service provider network via a CE-PE link, which can access
          at least one VPN <xref target="RFC4176"></xref>.</t>

          <t hangText="VPN target="RFC4176" format="default"/>.</dd>
        <dt>VPN service provider:">A provider:</dt>
        <dd>A service provider that offers
          VPN-related services <xref target="RFC4176"></xref>.</t>

          <t hangText="Service target="RFC4176" format="default"/>.</dd>
        <dt>Service provider network:">A network:</dt>
        <dd>A network that is able to
          provide VPN-related services.</t>
        </list></t>

      <t>The services.</dd>
      </dl>
      <t>This document is aimed at modeling BGP PE-based VPNs in a service
      provider network, so the terms defined in <xref target="RFC4026"></xref> target="RFC4026" format="default"/>
      and <xref target="RFC4176"></xref> target="RFC4176" format="default"/> are used.</t> used in this document as well.</t>
    </section>
    <section title="Acronyms"> numbered="true" toc="default">
      <name>Acronyms and Abbreviations</name>
      <t>The following acronyms and abbreviations are used in the document:<?rfc subcompact="yes" ?></t>

      <t><list hangIndent="8" style="hanging">
          <t hangText="ACL">Access this 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="ASM">Any-Source Multicast</t>

          <t hangText="ASN">AS Number</t>

          <t hangText="BSR">Bootstrap Router</t>

          <t hangText="BFD">Bidirectional List</dd>
        <dt>AS</dt>
        <dd>Autonomous System</dd>
        <dt>ASM</dt>
        <dd>Any-Source Multicast</dd>
        <dt>ASN</dt>
        <dd>AS Number</dd>
        <dt>BFD</dt>
        <dd>Bidirectional Forwarding Detection</t>

          <t hangText="BGP">Border Detection</dd>
        <dt>BGP</dt>
        <dd>Border Gateway Protocol</t>

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

          <t hangText="CsC">Carriers' Carriers</t>

          <t hangText="IGMP">Internet Protocol</dd>
        <dt>BSR</dt>
        <dd>Bootstrap Router</dd>
        <dt>CE</dt>
        <dd>Customer Edge</dd>
        <dt>CsC</dt>
        <dd>Carriers' Carriers</dd>
        <dt>IGMP</dt>
        <dd>Internet Group Management Protocol</t>

          <t hangText="L3VPN">Layer Protocol</dd>
        <dt>L3NM</dt>
        <dd>L3VPN Network Model</dd>
        <dt>L3SM</dt>
        <dd>L3VPN Service Model</dd>
        <dt>L3VPN</dt>
        <dd>Layer 3 Virtual Private Network</t>

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

          <t hangText="L3NM">L3VPN Network Model</t>

          <t hangText="MLD">Multicast Network</dd>
        <dt>MLD</dt>
        <dd>Multicast Listener Discovery</t>

          <t hangText="MSDP">Multicast Discovery</dd>
        <dt>MSDP</dt>
        <dd>Multicast Source Discovery Protocol</t>

          <t hangText="MVPN">Multicast VPN</t>

          <t hangText="NAT">Network Protocol</dd>
        <dt>MVPN</dt>
        <dd>Multicast VPN</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="OSPF">Open Maintenance</dd>
        <dt>OSPF</dt>
        <dd>Open Shortest Path First</t>

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

          <t hangText="PIM">Protocol First</dd>
        <dt>PE</dt>
        <dd>Provider Edge</dd>
        <dt>PIM</dt>
        <dd>Protocol Independent Multicast</t>

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

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

          <t hangText="RP">Rendezvous Point</t>

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

          <t hangText="SA">Security Association</t>

          <t hangText="SSM">Source-Specific Multicast</t>

          <t hangText="VPN">Virtual Multicast</dd>
        <dt>QoS</dt>
        <dd>Quality of Service</dd>
        <dt>RD</dt>
        <dd>Route Distinguisher</dd>
        <dt>RP</dt>
        <dd>Rendezvous Point</dd>
        <dt>RT</dt>
        <dd>Route Target</dd>
        <dt>SA</dt>
        <dd>Security Association</dd>
        <dt>SSM</dt>
        <dd>Source-Specific Multicast</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>

    </section>
    <section anchor="ref" title="L3NM numbered="true" toc="default">
      <name>L3NM Reference Architecture"> Architecture</name>
      <t><xref target="xml_happy"></xref> target="xml_happy" format="default"/> depicts the reference architecture
      for the L3NM. The figure is an expansion of the architecture presented
      in Section 5 of <xref target="RFC8299"></xref>; target="RFC8299" sectionFormat="of" section="5"/>; it decomposes the box
      marked "orchestration" in that section into three separate functional
      components: Service Orchestration, Network Orchestration, service orchestration, network orchestration, and Domain
      Orchestration.</t> domain
      orchestration.</t>
      <t>Although some deployments may choose to construct a monolithic
      orchestration component (covering both service and network matters),
      this document advocates for a clear separation between service and
      network orchestration components for the sake of better flexibility.
      Such a design adheres to the L3VPN reference architecture defined in
      Section 1.3 of
      <xref target="RFC4176"></xref>. target="RFC4176" sectionFormat="of" section="1.3"/>. This separation relies
      upon a dedicated communication interface between these components and
      appropriate YANG modules that reflect network-related information. Such
      information is hidden to from customers.</t>
      <t>The intelligence for translating customer-facing information into
      network-centric one information (and vice versa) is implementation specific.</t>
      <t>The terminology from <xref target="RFC8309"></xref> target="RFC8309" format="default"/> is introduced used here to
      show the distinction between the customer service model, the service
      delivery model, the network configuration model, and the device
      configuration model. In that context, the "Domain Orchestration" "domain orchestration" and
      "Config Manager"
      "config manager" roles may be performed by "Controllers".</t> "controllers".</t>
      <figure align="center" anchor="xml_happy"
              title="L3NM anchor="xml_happy">
        <name>L3NM Reference Architecture"> Architecture</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="ascii-art" alt=""><![CDATA[
                        +---------------+
                        |   Customer    |
                        +-------+-------+
        Customer Service Model  |
                      e.g., l3vpn-svc
         (e.g., 'l3vpn-svc')    |
                        +-------+-------+
                        |    Service    |
                        | Orchestration |
                        +-------+-------+
       Service Delivery Model   |
                       l3vpn-ntw
           'l3vpn-ntw'          |
                        +-------+-------+
                        |   Network     |
                        | Orchestration |
                        +-------+-------+
  Network Configuration Model   |
                    +-----------+-----------+
                    |                       |
           +--------+------+       +--------+------+
           |    Domain     |       |     Domain    |
           | Orchestration |       | Orchestration |
           +---+-----------+       +--------+------+
Device         |        |                   |
Configuration  |        |                   |
Model          |        |                   |
          +----+----+   |                   |
          | Config  |   |                   |
          | Manager |   |                   |
          +----+----+   |                   |
               |        |                   |
               | NETCONF/CLI..................
               |        |                   |
        +------------------------------------------------+
                            Network

NETCONF:  Network Configuration Protocol
CLI:  Command-Line Interface
]]></artwork>
      </figure>

      <t>The customer may use a variety of means to request a service that may
      trigger the instantiation of an L3NM. The customer may use the L3SM or
      more abstract models to request a service that relies upon an L3VPN
      service. For example, the customer may supply an IP Connectivity
      Provisioning Profile (CPP) that characterizes the requested service
      <xref target="RFC7297"></xref>, target="RFC7297" format="default"/>, an enhanced VPN (VPN+) service <xref
      target="I-D.ietf-teas-enhanced-vpn"></xref>, target="I-D.ietf-teas-enhanced-vpn" format="default"/>, or an IETF network slice
      service <xref target="I-D.ietf-teas-ietf-network-slices"></xref>.</t> target="Network-Slices-Framework" format="default"/>.</t>
      <t>Note also that both the L3SM and the L3NM may be used in the context
      of the Abstraction and Control of TE Networks (ACTN) Framework framework <xref
      target="RFC8453"></xref>. target="RFC8453" format="default"/>. <xref target="l3sm_actn"></xref> target="l3sm_actn" format="default"/> shows the
      Customer Network Controller (CNC), the Multi-Domain Service Coordinator
      (MDSC), and the Provisioning Network Controller (PNC) components components, and the
      interfaces where L3SM/L3NM the L3SM and L3NM are used.</t>
      <figure align="center" anchor="l3sm_actn"
              title="L3SM anchor="l3sm_actn">
        <name>L3SM and L3NM in the Context of ACTN"> the ACTN</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="ascii-art" alt=""><![CDATA[
        +----------------------------------+
        | Customer                         |
        | +-----------------------------+  |
        | |             CNC             |  |
        | +-----------------------------+  |
        +----+-----------------------+-----+
             |                       |
             | L3SM                  | L3SM
             |                       |
   +---------+---------+   +---------+---------+
   | MDSC              |   |       MDSC        |
   | +---------------+ |   |     (parent)      |
   | |    Service    | |   +---------+---------+
   | | Orchestration | |             |
   | +-------+-------+ |             | L3NM
   |         |         |             |
   |         | L3NM    |   +---------+---------+
   |         |         |   |       MDSC        |
   | +-------+-------+ |   |      (child)      |
   | |    Network    | |   +---------+---------+
   | | Orchestration | |             |
   | +---------------+ |             |
   +---------+---------+             |
             |                       |
             | Network Configuration |
             |                       |
+------------+-------+     +---------+------------+
| Domain             |     |           Domain     |
| Controller         |     |           Controller |
|       +---------+  |     |    +---------+       |
|       |   PNC   |  |     |    |   PNC   |       |
|       +---------+  |     |    +---------+       |
+------------+-------+     +---------+------------+
             |                       |
             | Device Configuration  |
             |                       |
        +----+---+              +----+---+
        | Device |              | Device |
        +--------+              +--------+
]]></artwork>
      </figure>
    </section>
    <section anchor="relation" title="Relation with other numbered="true" toc="default">
      <name>Relationship to Other YANG Models"> Data Models</name>
      <t>The "ietf-vpn-common" module <xref
      target="I-D.ietf-opsawg-vpn-common"></xref> target="RFC9181" format="default"/> includes a set of
      identities, types, and groupings that are meant to be reused by
      VPN-related YANG modules independently of the layer (e.g., Layer 2,
      Layer 3) and the type of the module (e.g., network model, service model) model),
      including future revisions of existing models (e.g., <xref
      target="RFC8299"></xref> target="RFC8299" format="default"/> or <xref target="RFC8466"></xref>). target="RFC8466" format="default"/>). The L3NM
      reuses these common types and groupings.</t>
      <t>In order to avoid data duplication and to ease passing data between
      layers when required (service layer to network layer and vice versa),
      early versions of the L3NM reused many of the data nodes that are
      defined in <xref target="RFC8299"></xref>. target="RFC8299" format="default"/>. Nevertheless, that approach
      was abandoned in favor of the "ietf-vpn-common" module because that
      initial design was interpreted as if the deployment of the L3NM depends on the
      L3SM, while this is not the case. For example, a service provider may
      decide to use the L3NM to build its L3VPN services without exposing the
      L3SM.</t>
      <t>As discussed in <xref target="ref"></xref>, target="ref" format="default"/>, the L3NM is meant to
      manage L3VPN services within a service provider network. The module
      provides a network view of the service. Such a view is only visible
      within the service provider and is not exposed outside (to customers,
      for example). The following discusses items below discuss how the L3NM interfaces with other YANG modules:</t>

      <t><list style="hanging">
          <t hangText="L3SM:">L3NM
      <dl newline="false" spacing="normal">
        <dt>L3SM:</dt>
        <dd>
          <t>The L3NM is not a customer service model.<vspace
          blankLines="1" />The model.</t>
          <t>The internal view of the service (i.e., the L3NM) may
          be mapped to an external view which that is visible to customers: the L3VPN
          Service YANG data Model (L3SM) <xref target="RFC8299"></xref>.
          <vspace blankLines="1" />The target="RFC8299" format="default"/>.
          </t>
          <t>The L3NM can be fed with inputs that are
          requested by customers, typically, relying customers. Such requests typically rely upon an L3SM template.
          Concretely, some parts of the L3SM module can be directly mapped
          into L3NM
          to the L3NM, while other parts are generated as a function of the
          requested service and local guidelines. Some other parts are local
          to the service provider and do not map directly to L3SM.<vspace
          blankLines="1" />Note the L3SM.</t>
          <t>Note that using the use of L3NM within a service provider does not assume
          assume, nor preclude does it preclude, exposing the VPN service via the L3SM.
          This is deployment-specific. deployment specific. Nevertheless, the design of the L3NM tries
          to align as much as possible with the features supported by the L3SM
          to ease the grafting of both the L3NM and the L3SM for the sake of highly automated
          VPN service provisioning and delivery.</t>

          <t hangText="Network
        </dd>
        <dt>Network Topology Modules:">An Modules:</dt>
        <dd>An L3VPN involves nodes that
          are part of a topology managed by the service provider network. The
          topology can be represented using the network topology YANG module
          defined in <xref target="RFC8345"></xref> target="RFC8345" format="default"/> or its extension extension, such as a
          User-Network Interface (UNI) topology
          network YANG module (e.g., for Service Attachment Points (SAPs) <xref
          target="I-D.ogondio-opsawg-uni-topology"></xref>).</t>

          <t hangText="Device Modules:">L3NM target="YANG-SAPs" format="default"/>.</dd>
        <dt>Device Modules:</dt>
        <dd>
          <t>The L3NM is not a device model. <vspace
          blankLines="1" />Once model.</t>
          <t>Once a global VPN service is captured by means of the
          L3NM, the actual activation and provisioning of the VPN service will
          involve a variety of device modules to tweak the required functions
          for the delivery of the service. These functions are supported by
          the VPN nodes and can be managed using device YANG modules. A
          non-comprehensive list of such device YANG modules is provided
          below:<list style="symbols">
              <t>Routing
          below:</t>
          <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="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><vspace blankLines="1" />How target="I-D.ietf-rtgwg-qos-model" format="default"/>.</li>
            <li>ACLs <xref target="RFC8519" format="default"/>.</li>
          </ul>
          <t>How the L3NM is used to derive
          device-specific actions is implementation-specific.</t>
        </list></t> implementation specific.</t>
        </dd>
      </dl>
    </section>
    <section anchor="Use_of_the_data_model"
             title="Sample numbered="true" toc="default">
      <name>Sample Uses of the L3NM Data Model"> Model</name>
      <t>This section provides a non-exhaustive list of examples to that illustrate
      contexts where the L3NM can be used.</t>
      <section anchor="enterprise_services"
               title="Enterprise numbered="true" toc="default">
        <name>Enterprise Layer 3 VPN Services"> Services</name>
        <t>Enterprise L3VPNs are one of the most demanded services for
        carriers, and
        carriers; therefore, L3NM can be useful to automate for automating the
        provisioning and maintenance of these VPNs. Templates and batch
        processes can be built, and as a result many parameters are needed for
        the creation from scratch of a VPN that can be abstracted to the upper
        Software-Defined Networking (SDN) layer <xref target="RFC7149"></xref><xref
        target="RFC7426"></xref> layer, target="RFC7149" format="default"/> <xref target="RFC7426" format="default"/>, but some manual intervention will
        still be required.</t>
        <t>A common function that is supported by VPNs is the addition or
        removal of VPN nodes. Workflows can use the L3NM in these scenarios to
        add or prune nodes from the network data model as required.</t>
      </section>
      <section anchor="mdrmanagement" title="Multi-Domain numbered="true" toc="default">
        <name>Multi-Domain Resource Management"> Management</name>
        <t>The implementation of L3VPN services which that span across
        administratively separated domains (i.e., that are under the
        administration of different management systems or controllers)
        requires some network resources to be synchronized between systems.
        Particularly, resources must be adequately managed in each domain to
        avoid broken configuration.</t> configurations.</t>
        <t>For example, route targets (RTs) shall be synchronized between PEs.
        When all PEs are controlled by the same management system, RT
        allocation can be performed by that management system. In cases where
        the service spans across multiple management systems, the task of
        allocating RTs has to be aligned across the domains, domains; therefore, the
        network model must provide a way to specify RTs. In addition, route
        distinguishers (RDs) must also be synchronized to avoid collisions in of
        RD allocation allocations between separate management systems. An incorrect
        allocation might lead to the same RD and IP prefixes being exported by
        different PEs.</t>
      </section>
      <section anchor="ms_management" title="Management numbered="true" toc="default">
       <name>Management of Multicast Services"> Services</name>
        <t>Multicast services over L3VPN L3VPNs can be implemented using dual PIM
        MVPNs (also known as, Draft Rosen as the draft-rosen model) <xref
        target="RFC6037"></xref> target="RFC6037" format="default"/>
        or MVPNs based on Multiprotocol BGP (MP-BGP)-based MVPNs (MP-BGP) <xref target="RFC6513"></xref><xref target="RFC6514"></xref>. target="RFC6513" format="default"/>
        <xref target="RFC6514" format="default"/>.  Both
        methods are supported and equally effective, but the main difference
        is that MBGP-based MVPN does MP-BGP-based MVPNs do not require multicast configuration on
        the service provider network. MBGP MP-BGP MVPNs employ the intra-autonomous
        system intra-AS BGP control plane and PIM sparse mode Sparse Mode <xref target="RFC7761"/> as the data plane. The
        PIM state information is maintained between PEs using the same
        architecture that is used for unicast VPNs.</t>
        <t>On the other hand, <xref target="RFC6037"></xref> target="RFC6037" format="default"/> has limitations limitations,
        such as reduced options for transport, control plane scalability,
        availability, operational inconsistency, and the need of maintaining to maintain
        state in the backbone. Because of these limitations, MBGP MVPN is MP-BGP MVPNs provide the
        architectural model that has been taken as the base for implementing
        multicast service services in L3VPNs. In this scenario, BGP is used to
        auto-discover
        autodiscover MVPN PE members and the customer PIM signaling is sent
        across the provider's core through MP-BGP. The multicast traffic is
        transported on MPLS P2MP LSPs.</t> Point-to-Multipoint (P2MP) Label Switched Paths (LSPs).</t>
      </section>
    </section>
    <section anchor="YANG_explanation"
             title="Description numbered="true" toc="default">
      <name>Description of the L3NM YANG Module"> Module</name>
      <t>The L3NM ('ietf-l3vpn-ntw') ("ietf-l3vpn-ntw") is defined to manage L3VPNs in a service
      provider network. In particular, the 'ietf-l3vpn-ntw' "ietf-l3vpn-ntw" module can be used
      to create, modify, and retrieve L3VPN services of a network.</t>
      <t>The full tree diagram of the module can be generated using the
      "pyang" tool <xref target="PYANG"></xref>. target="PYANG" format="default"/>. That tree is not included
      here because it is too long (Section 3.3 of <xref
      target="RFC8340"></xref>). (<xref target="RFC8340" sectionFormat="of" section="3.3"/>). Instead, subtrees are provided for the
      reader's convenience.</t>
      <section anchor="structure_model"
               title="Overall numbered="true" toc="default">
        <name>Overall Structure of the Module"> Module</name>
        <t>The 'ietf-l3vpn-ntw' "ietf-l3vpn-ntw" module uses two main containers:
        'vpn-services' and
        'vpn-profiles' and 'vpn-services' (see <xref
        target="ietf-l3vpn-ntw_tree"></xref>).</t> target="ietf-l3vpn-ntw_tree" format="default"/>).</t>
        <t>The 'vpn-profiles' container is used by the provider to maintain a
        set of common VPN profiles that apply to one or several VPN services
        (<xref target="vpn_profiles"></xref>).</t> target="vpn_profiles" format="default"/>).</t>
        <t>The 'vpn-services' container maintains the set of VPN services
        managed within the service provider network. The 'vpn-service' is the data
        structure that abstracts a VPN service (<xref
        target="vpn_service"></xref>).</t> target="vpn_service" format="default"/>).</t>
        <figure align="center" anchor="ietf-l3vpn-ntw_tree"
                title="Overall anchor="ietf-l3vpn-ntw_tree">
          <name>Overall L3NM Tree Structure">
          <artwork align="center"><![CDATA[module: Structure</name>
          <sourcecode name="" type="yangtree"><![CDATA[module: ietf-l3vpn-ntw
  +--rw l3vpn-ntw
     +--rw vpn-profiles
     |  ...
     +--rw vpn-services
        +--rw vpn-service* [vpn-id]
           ...
           +--rw vpn-nodes
              +--rw vpn-node* [vpn-node-id]
                 ...
                 +--rw vpn-network-accesses
                    +--rw vpn-network-access* [id]
                       ...     ]]></artwork>
]]></sourcecode>
        </figure>

        <t></t>
        <t>Some of the data nodes are keyed by the address-family. address family. For the
        sake of data representation compactness, It it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to use the
        dual-stack address-family address family for data nodes that have the same value for
        both IPv4 and IPv6. If, for some reasons, reason, a data node is present for
        both dual-stack and IPv4 (or IPv6), the value that is indicated under
        dual-stack takes precedence over the one value that is indicated under IPv4
        (or IPv6).</t>
      </section>
      <section anchor="vpn_profiles" title="VPN Profiles"> numbered="true" toc="default">
        <name>VPN Profiles</name>
        <t>The 'vpn-profiles' container (<xref
        target="vpn_profiles_tree"></xref>) target="vpn_profiles_tree" format="default"/>) allows the VPN service provider to
        define and maintain a set of VPN profiles <xref
        target="I-D.ietf-opsawg-vpn-common"></xref> target="RFC9181" format="default"/> that apply to one or
        several VPN services.</t>

        <t><figure align="center" anchor="vpn_profiles_tree"
            title="VPN
        <figure anchor="vpn_profiles_tree">
          <name>VPN Profiles Subtree Structure">
            <artwork align="center"><![CDATA[ Structure</name>
          <sourcecode name="" type="yangtree"><![CDATA[  +--rw l3vpn-ntw
     +--rw vpn-profiles
     |  +--rw valid-provider-identifiers
     |     +--rw external-connectivity-identifier* [id]
     |     |       {external-connectivity}?
     |     |  +--rw id    string
     |     +--rw encryption-profile-identifier* [id]
     |     |  +--rw id    string
     |     +--rw qos-profile-identifier* [id]
     |     |  +--rw id    string
     |     +--rw bfd-profile-identifier* [id]
     |     |  +--rw id    string
     |     +--rw forwarding-profile-identifier* [id]
     |     |  +--rw id    string
     |     +--rw routing-profile-identifier* [id]
     |        +--rw id    string
     +--rw vpn-services
        ...
          ]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
        <t>This document does not make any assumption about the exact
        definition of these profiles. The exact definition of the profiles is
        local to each VPN service provider. The model only includes an
        identifier to for these profiles in order to facilitate identifying and
        binding local policies when building a VPN service. As shown in <xref
        target="vpn_profiles_tree"></xref>, target="vpn_profiles_tree" format="default"/>, the following identifiers can be
        included:<list style="hanging">
            <t hangText="'external-connectivity-identifier':">This
        included:</t>
        <dl newline="false" spacing="normal">
          <dt>'external-connectivity-identifier':</dt>
          <dd>This identifier
            refers to a profile that defines the external connectivity
            provided to a VPN service (or a subset of VPN sites). An external External
            connectivity may be an access to the Internet or a restricted
            connectivity
            connectivity, such as access to a public/private cloud.</t>

            <t hangText="'encryption-profile-identifier':">An cloud.</dd>
          <dt>'encryption-profile-identifier':</dt>
          <dd>An encryption
            profile refers to a set of policies related to the encryption
            schemes and setup that can be applied when building and offering a
            VPN service.</t>

            <t hangText="'qos-profile-identifier':">A service.</dd>
          <dt>'qos-profile-identifier':</dt>
          <dd>A Quality of Service (QoS)
            profile refers to a set of policies policies, such as classification,
            marking, and actions (e.g., <xref target="RFC3644"></xref>).</t>

            <t hangText="'bfd-profile-identifier':">A target="RFC3644" format="default"/>).</dd>
          <dt>'bfd-profile-identifier':</dt>
          <dd>A Bidirectional Forwarding
            Detection (BFD) profile refers to a set of BFD <xref
            target="RFC5880"></xref> policies <xref target="RFC5880" format="default"/> that can be invoked when
            building a VPN service.</t>

            <t hangText="'forwarding-profile-identifier':">A service.</dd>
          <dt>'forwarding-profile-identifier':</dt>
          <dd>A forwarding
            profile refers to the policies that apply to the forwarding of
            packets conveyed within a VPN. Such policies may consist, for
            example, of applying Access Control Lists (ACLs).</t>

            <t hangText="'routing-profile-identifier':">A (ACLs).</dd>
          <dt>'routing-profile-identifier':</dt>
          <dd>A routing profile
            refers to a set of routing policies that will be invoked (e.g.,
            BGP policies) when delivering the VPN service.</t>
          </list></t>

        <t></t> service.</dd>
        </dl>
      </section>
      <section anchor="vpn_service" title="VPN Services"> numbered="true" toc="default">
        <name>VPN Services</name>
        <t>The 'vpn-service' is the data structure that abstracts a VPN
        service in the service provider network. Each 'vpn-service' is
        uniquely identified by an identifier: 'vpn-id'. Such a 'vpn-id' is only
        meaningful locally (e.g., the network controller). The subtree of the
        'vpn-services' is shown in <xref
        target="vpn-service_tree"></xref>.</t>

        <t><figure align="center" anchor="vpn-service_tree"
            title="VPN target="vpn-service_tree" format="default"/>.</t>
        <figure anchor="vpn-service_tree">
          <name>VPN Services Subtree Structure">
            <artwork align="center"><![CDATA[ Structure</name>
          <sourcecode name="" type="yangtree"><![CDATA[  +--rw l3vpn-ntw
     +--rw vpn-profiles
     |  ...
     +--rw vpn-services
        +--rw vpn-service* [vpn-id]
           +--rw vpn-id                   vpn-common:vpn-id
           +--rw vpn-name?                string
           +--rw vpn-description?         string
           +--rw customer-name?           string
           +--rw parent-service-id?       vpn-common:vpn-id
           +--rw vpn-type?                identityref
           +--rw vpn-service-topology?    identityref
           +--rw status
           |  +--rw admin-status
           |  |  +--rw status?         identityref
           |  |  +--rw last-change?   yang:date-and-time
           |  +--ro oper-status
           |     +--ro status?         identityref
           |     +--ro last-change?   yang:date-and-time
           +--rw vpn-instance-profiles
           |  ...
           +--rw underlay-transport
           |  +-- (type)?
           |     +--:(abstract)
           |     |  +--  +--rw transport-instance-id?   string
           |     |  +--rw instance-type?           identityref
           |     +--:(protocol)
           |       +--        +--rw protocol*                identityref
           +--rw external-connectivity
           |                   {external-connectivity}                   {vpn-common:external-connectivity}?
           |  +--rw (profile)?
           |     +--:(profile)
           |        +--rw profile-name?            leafref
           +--rw vpn-nodes
              ...

]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
        <t>The description descriptions of the VPN service data nodes that are depicted in
        <xref target="vpn-service_tree"></xref> target="vpn-service_tree" format="default"/> are as follows:<list
            style="hanging">
            <t hangText="'vpn-id':">Is an follows:</t>
        <dl newline="false" spacing="normal">
          <dt>'vpn-id':</dt>
          <dd>An identifier that is used to uniquely
            identify the L3VPN service within the L3NM scope.</t>

            <t hangText="'vpn-name':">Associates scope.</dd>
          <dt>'vpn-name':</dt>
          <dd>Associates a name with the service in
            order to facilitate the identification of the service.</t>

            <t hangText="'vpn-description':">Includes service.</dd>
          <dt>'vpn-description':</dt>
          <dd>
            <t>Includes a textual description of
            the service. <vspace blankLines="1" />The </t>
            <t>The internal structure of a
            VPN description is local to each VPN service provider.</t>

            <t hangText="'customer-name':">Indicates
          </dd>
          <dt>'customer-name':</dt>
          <dd>Indicates the name of the customer
            who ordered the service.</t>

            <t hangText="'parent-service-id':">Refers service.</dd>
          <dt>'parent-service-id':</dt>
          <dd>Refers to an identifier of the
            parent service (e.g, (e.g., L3SM, IETF network slice, VPN+) that
            triggered the creation of the VPN service. This identifier is used
            to easily correlate the (network) service as built in the network
            with a service order. A controller can use that correlation to
            enrich or populate some fields (e.g., description fields) as a
            function of local deployments.</t>

            <t hangText="'vpn-type':">Indicates deployments.</dd>
          <dt>'vpn-type':</dt>
          <dd>Indicates the VPN type. The values are
            taken from <xref target="I-D.ietf-opsawg-vpn-common"></xref>. target="RFC9181" format="default"/>. For
            the L3NM, this is typically set to BGP/MPLS L3VPN, "BGP/MPLS L3VPN", but other
            values may be defined in the future to support specific Layer 3
            VPN capabilities (e.g., <xref
            target="I-D.ietf-bess-evpn-prefix-advertisement"></xref>).</t>

            <t hangText="'vpn-service-topology':">Indicates target="RFC9136" format="default"/>).</dd>
          <dt>'vpn-service-topology':</dt>
          <dd>Indicates the network
            topology for the service: hub-spoke, any-to-any, 'hub-spoke', 'any-to-any', or custom. 'custom'. The
            network implementation of this attribute is defined by the correct
            usage of import and export profiles (Section 4.3.5 of <xref
            target="RFC4364"></xref>).</t>

            <t hangText="'status':">Is used targets (<xref target="RFC4364" sectionFormat="of" section="4.3.5"/>).</dd>
          <dt>'status':</dt>
          <dd>
            <t>Used to track the service status of a
            given VPN service. Both operational status and administrative status are
            maintained together with a timestamp. For example, a service can
            be created, created but not put into effect.<vspace
            blankLines="1" />Administrative effect.</t>
            <t>Administrative status and operational status can be used
            as a trigger to detect service anomalies. For example, a service
            that is declared active at the service layer as being active but is still
            inactive at the network layer may be an indication that network
            provision actions are needed to align the observed service status
            with the expected service status.</t>

            <t hangText="'vpn-instance-profiles':">Defines
          </dd>
          <dt>'vpn-instance-profiles':</dt>
          <dd>
            <t>Defines reusable parameters
            for the same 'vpn-service'. <vspace blankLines="1" />More </t>
            <t>More details
            are provided in <xref target="ie_profiles"></xref>.</t>

            <t hangText="'underlay-transport':">Describes target="ie_profiles" format="default"/>.</t>
          </dd>
          <dt>'underlay-transport':</dt>
          <dd>
            <t>Describes the preference for
            the transport technology to carry the traffic of the VPN service.
            This preference is especially useful in networks with multiple
            domains and Network-to-Network Interface (NNI) types. The underlay
            transport can be expressed as an abstract transport instance
            (e.g., an identifier of a VPN+ instance, a virtual network
            identifier, or a network slice name) or as an ordered list of the
            actual protocols to be enabled in the network. <vspace
            blankLines="1" />A </t>
            <t>A rich set of protocol identifiers that can be
            used to refer to an underlay transport are defined in <xref
            target="I-D.ietf-opsawg-vpn-common"></xref>.</t>

            <t hangText="'external-connectivity':">Indicates target="RFC9181" format="default"/>.</t>
          </dd>
          <dt>'external-connectivity':</dt>
          <dd>
            <t>Indicates whether/how
            external connectivity is provided to the VPN service. For example,
            a service provider may provide an external connectivity to a VPN
            customer (e.g., to a public cloud). Such a service may involve
            tweaking both filtering and NAT rules (e.g., bind binding a Virtual
            Routing and Forwarding (VRF) interface with a NAT instance as
            discussed in Section 2.10 of <xref target="RFC8512"></xref>). target="RFC8512" sectionFormat="of" section="2.10"/>).
            These added value value-added features may be bound to all all, or a subset of of,
            network accesses. Some of these added value value-added features may be
            implemented in a PE or in other nodes other than PEs (e.g., a P node or
            even a dedicated node that hosts the NAT function). <vspace
            blankLines="1" />Only </t>
            <t>Only a pointer to a local profile that defines
            the external connectivity external-connectivity feature is supported in this
            document.</t>

            <t hangText="'vpn-node':">Is an
          </dd>
          <dt>'vpn-node':</dt>
          <dd>
            <t>An abstraction that represents a set
            of policies applied to a network node and that belong belonging to a single
            'vpn-service'. A VPN service is typically built by adding
            instances of 'vpn-node' to the 'vpn-nodes' container. <vspace
            blankLines="1" />A </t>
            <t>A 'vpn-node' contains 'vpn-network-accesses',
            which are the interfaces attached to the VPN by which the customer
            traffic is received. Therefore, the customer sites are connected
            to the 'vpn-network-accesses'.<vspace blankLines="1" />Note that,
            as 'vpn-network-accesses'.</t>
            <t>Note that
            because this is a network data model, the information about customers customers'
            sites is not required in the model. Such Rather, such information is rather
            relevant in the L3SM. Whether that information is included in the
            L3NM, e.g., to populate the various 'description' data node nodes, is
            implementation specific. <vspace blankLines="1" />More </t>
            <t>More details are
            provided in <xref target="vpn_node"></xref>.</t>
          </list></t> target="vpn_node" format="default"/>.</t>
          </dd>
        </dl>
      </section>
      <section anchor="ie_profiles" title="VPN numbered="true" toc="default">
        <name>VPN Instance Profiles"> Profiles</name>
        <t>VPN instance profiles are meant to factorize data nodes that are
        used at many levels of the model. Generic VPN instance profiles are
        defined at the VPN service level and then called at the VPN node and
        VPN network access levels. Each VPN instance profile is identified by
        'profile-id'. This identifier is then referenced for one or multiple
        VPN nodes (<xref target="vpn_node"></xref>) target="vpn_node" format="default"/>) so that the controller can
        identify generic resources (e.g., RTs and RDs) to be configured for a
        given VRF.</t> VRF instance.</t>
        <t>The subtree of 'vpn-instance-profile' the 'vpn-instance-profiles' is shown in <xref
        target="ie"></xref>.</t>

        <t><figure align="center" anchor="ie"
            title="Subtree target="ie" format="default"/>.</t>
        <figure anchor="ie">
          <name>Subtree Structure of VPN Instance Profiles">
            <artwork align="center"><![CDATA[ Profiles</name>
          <sourcecode name="" type="yangtree"><![CDATA[  +--rw l3vpn-ntw
     +--rw vpn-profiles
     |  ...
     +--rw vpn-services
        +--rw vpn-service* [vpn-id]
           +--rw vpn-id                   vpn-common:vpn-id
           ...
           +--rw vpn-instance-profiles
           |  +--rw vpn-instance-profile* [profile-id]
           |     +--rw profile-id                 string
           |     +--rw role?                      identityref
           |     +--rw local-as?                  inet:as-number
           |     |      {vpn-common:rtg-bgp}?
           |     +--rw (rd-choice)?
           |     |  +--:(directly-assigned)
           |     |  |  +--rw rd?
           |     |  |         rt-types:route-distinguisher
           |     |  +--:(directly-assigned-suffix)
           |     |  |  +--rw rd-suffix?           uint16
           |     |  +--:(auto-assigned)
           |     |  |  +--rw rd-auto
           |     |  |     +--rw (auto-mode)?
           |     |  |     |  +--:(from-pool)
           |     |  |     |  |  +--rw rd-pool-name?   string
           |     |  |     |  +--:(full-auto)
           |     |  |     |     +--rw auto?           empty
           |     |  |     +--ro auto-assigned-rd?
           |     |  |          rt-types:route-distinguisher
           |     |  +--:(auto-assigned-suffix)
           |     |  |  +--rw rd-auto-suffix
           |     |  |     +--rw (auto-mode)?
           |     |  |     |  +--:(from-pool)
           |     |  |     |  |  +--rw rd-pool-name?        string
           |     |  |     |  +--:(full-auto)
           |     |  |     |     +--rw auto?                empty
           |     |  |     +--ro auto-assigned-rd-suffix?   uint16
           |     |  +--:(no-rd)
           |     |     +--rw no-rd?               empty
           |     +--rw address-family* [address-family]
           |     |  +--rw address-family          identityref
           |     |  +--rw vpn-targets
           |     |  |  +--rw vpn-target* [id]
           |     |  |  |  +--rw id                  uint8
           |     |  |  |  +--rw route-targets* [route-target]
           |     |  |  |  |  +--rw route-target
           |     |  |  |  |       rt-types:route-target
           |     |  |  |  +--rw route-target-type
           |     |  |  |          rt-types:route-target-type
           |     |  |  +--rw vpn-policies
           |     |  |     +--rw import-policy?   string
           |     |  |     +--rw export-policy?   string
           |     |  +--rw maximum-routes* [protocol]
           |     |     +--rw protocol          identityref
           |     |     +--rw maximum-routes?   uint32
           |     +--rw multicast {vpn-common:multicast}?
           |        ...
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
        <t>The description descriptions of the listed data nodes is are as follows:</t>

        <t><list style="hanging">
            <t hangText="'profile-id':">Is used
        <dl newline="false" spacing="normal">
          <dt>'profile-id':</dt>
          <dd>Used to uniquely identify a VPN
            instance profile.</t>

            <t hangText="'role':">Indicates profile.</dd>
          <dt>'role':</dt>
          <dd>Indicates the role of the VPN instance
            profile in the VPN. Role values are defined in <xref
            target="I-D.ietf-opsawg-vpn-common"></xref> target="RFC9181" format="default"/> (e.g.,
            any-to-any-role, spoke-role, hub-role).</t>

            <t hangText="'local-as':">Indicates
            'any-to-any-role', 'spoke-role', 'hub-role').</dd>
          <dt>'local-as':</dt>
          <dd>Indicates the Autonomous System Number
            (ASN) that is configured for the VPN node.</t>

            <t hangText="'rd':">As node.</dd>
          <dt>'rd':</dt>
          <dd>
            <t>As defined in <xref
            target="I-D.ietf-opsawg-vpn-common"></xref>, target="RFC9181" format="default"/>, the following RD
            assignment modes are supported: direct assignment, full automatic
            assignment, automatic assignment from a given pool, automatic assignment, and no
            assignment. For illustration purposes, the following modes can be
            used in the deployment cases: <list style="hanging">
                <t hangText="'directly-assigned':">The cases:</t>
            <dl newline="false" spacing="normal">
              <dt>'directly-assigned':</dt>
              <dd>The VPN service provider
                (service orchestrator) assigns explicitly RDs. RDs explicitly. This case will
                fit with a brownfield scenario where some existing services
                need to be updated by the VPN service provider.</t>

                <t hangText="'full-auto':">The provider.</dd>
              <dt>'full-auto':</dt>
              <dd>The network controller auto-assigns
                RDs. This can apply for the deployment of new services.</t>

                <t hangText="'no-rd':">The services.</dd>
              <dt>'no-rd':</dt>
              <dd>The VPN service provider (service
                orchestrator) explicitly wants no RD to be assigned. This case
                can be used for CE testing within the network or for
                troubleshooting proposes.</t>
              </list>Also, proposes.</dd>
            </dl>

            <t>Also, the module accommodates deployments where only the
            Assigned Number subfield of RDs (Section 4.2 of <xref
            target="RFC4364"></xref>) (<xref target="RFC4364" sectionFormat="of" section="4.2"/>) is assigned from a pool while the
            Administrator subfield is set to, e.g., for example, the Router ID that is
            assigned to a VPN node. The module supports these modes for
            managing the Assigned Number subfield: explicit assignment,
            auto-assignment from a pool, and full auto-assignment.</t>

            <t hangText="'address-family':">Includes
          </dd>
          <dt>'address-family':</dt>
          <dd>
            <t>Includes a set of per-address
            family data nodes:<list style="hanging">
                <t hangText="'address-family':">Identifies nodes per address family:</t>
            <dl newline="false" spacing="normal">
              <dt>'address-family':</dt>
              <dd>Identifies the address family.
                It can be set to IPv4, IPv6, 'ipv4', 'ipv6', or dual-stack.</t>

                <t hangText="'vpn-targets':">Specifies 'dual-stack'.</dd>
              <dt>'vpn-targets':</dt>
              <dd>Specifies RT import/export rules
                for the VPN service (Section 4.3 of <xref
                target="RFC4364"></xref>).</t>

                <t hangText="'maximum-routes':">Indicates (<xref target="RFC4364" sectionFormat="of" section="4.3"/>).</dd>
              <dt>'maximum-routes':</dt>
              <dd>Indicates the maximum number
                of prefixes that the VPN node can accept for a given routing
                protocol. If 'protocol' is set to 'any', this means that the
                maximum value applies to each active routing protocol.</t>
              </list></t>

            <t hangText="'multicast':">Enables protocol.</dd>
            </dl>
          </dd>
          <dt>'multicast':</dt>
          <dd>Enables multicast traffic in the VPN
            service. Refer to <xref target="mc"></xref>.</t>
          </list></t>

        <t></t> target="mc" format="default"/>.</dd>
        </dl>
      </section>
      <section anchor="vpn_node" title="VPN Nodes"> numbered="true" toc="default">
        <name>VPN Nodes</name>
        <t>The 'vpn-node' is an abstraction that represents a set of common
        policies applied on a given network node (typically, a PE) and belong belonging
        to one L3VPN service. The 'vpn-node' includes a parameter to indicate
        the network node on which it is applied. In the case that the 'ne-id'
        points to a specific PE, the 'vpn-node' will likely be mapped into to a
        VRF instance in the node. However, the model also allows pointing to an
        abstract node. In this case, the network controller will decide how to
        split the 'vpn-node' into VRFs.</t>

        <t><figure align="center" anchor="vpn-node_tree"
            title="VPN VRF instances.</t>

        <t>The VPN node subtree structure is shown in <xref target="vpn-node_tree"/>.</t>
        <figure anchor="vpn-node_tree">
          <name>VPN Node Subtree Structure">
            <artwork align="center"><![CDATA[ Structure</name>
          <sourcecode name="" type="yangtree"><![CDATA[  +--rw l3vpn-ntw
     +--rw vpn-profiles
     |  ...
     +--rw vpn-services
        +--rw vpn-service* [vpn-id]
           ...
           +--rw vpn-nodes
              +--rw vpn-node* [vpn-node-id]
                 +--rw vpn-node-id                vpn-common:vpn-id
                 +--rw description?               string
                 +--rw ne-id?                     string
                 +--rw local-as?                  inet:as-number
                 |       {vpn-common:rtg-bgp}?
                 +--rw router-id?                 rt-types:router-id
                 +--rw active-vpn-instance-profiles
                 |  +--rw vpn-instance-profile* [profile-id]
                 |     +--rw profile-id                 leafref
                 |     +--rw router-id* [address-family]
                 |     |  +--rw address-family    identityref
                 |     |  +--rw router-id?        inet:ip-address
                 |     +--rw local-as?            inet:as-number
                 |     |     {vpn-common:rtg-bgp}?
                 |     +--rw (rd-choice)?
                 |     |  ....
                 |     +--rw address-family* [address-family]
                 |     |  +--rw address-family          identityref
                 |     |  |  ...
                 |     |  +--rw vpn-targets
                 |     |  |  ...
                 |     |  +--rw maximum-routes* [protocol]
                 |     |     ...
                 |     +--rw multicast {vpn-common:multicast}?
                 |        ...
                 +--rw msdp {msdp}?
                 |  +--rw peer?            inet:ipv4-address
                 |  +--rw local-address?   inet:ipv4-address
                 |  +--rw status
                 |     +--rw admin-status
                 |     |  +--rw status?         identityref
                 |     |  +--rw last-change?   yang:date-and-time
                 |     +--ro oper-status
                 |        +--ro status?         identityref
                 |        +--ro last-change?   yang:date-and-time
                 +--rw groups
                 |  +--rw group* [group-id]
                 |     +--rw group-id    string
                 +--rw status
                 |  +--rw admin-status
                 |  |  +--rw status?         identityref
                 |  |  +--rw last-change?   yang:date-and-time
                 |  +--ro oper-status
                 |     +--ro status?         identityref
                 |     +--ro last-change?   yang:date-and-time
                 +--rw vpn-network-accesses
                    ...]]></artwork>
          </figure></t>

        <t>In reference to the subtree shown in <xref
        target="vpn-node_tree"></xref>, the description
                    ...
]]></sourcecode>
        </figure>
        <t>The descriptions of VPN node the 'vpn-node' data nodes
        is (<xref  target="vpn-node_tree"/>) are as follows:<list style="hanging">
            <t hangText="'vpn-node-id':">Is an follows:</t>
        <dl newline="false" spacing="normal">
          <dt>'vpn-node-id':</dt>
          <dd>An identifier that uniquely
            identifies a node that enables a VPN network access.</t>

            <t hangText="'description':">Provides access.</dd>
          <dt>'description':</dt>
          <dd>Provides a textual description of the
            VPN node.</t>

            <t hangText="'ne-id':">Includes node.</dd>
          <dt>'ne-id':</dt>
          <dd>Includes a unique identifier of the network
            element where the VPN node is deployed.</t>

            <t hangText="'local-autonomous-system':">Indicates deployed.</dd>
          <dt>'local-as':</dt>
          <dd>Indicates the ASN that is
            configured for the VPN node.</t>

            <t hangText="'router-id':">Indicates node.</dd>
          <dt>'router-id':</dt>
          <dd>Indicates a 32-bit number that is used
            to uniquely identify a router within an Autonomous System.</t>

            <t hangText="'active-vpn-instance-profiles':">Lists AS.</dd>
          <dt>'active-vpn-instance-profiles':</dt>
          <dd>
            <t>Lists the set of
            active VPN instance profiles for this VPN node. Concretely, one or
            more VPN instance profiles that are defined at the VPN service
            level can be enabled at the VPN node level; each of these profiles
            is uniquely identified by means of 'profile-id'. The structure of
            'active-vpn-instance-profiles' is the same as the one structure discussed in
            <xref target="ie_profiles"></xref> target="ie_profiles" format="default"/>, except 'router-id'. that the structure of
 'active-vpn-instance-profiles' includes 'router-id' but does not include the 'role' leaf. The value
            of 'router-id' indicated under 'active-vpn-instance-profiles'
            takes precedence over the 'router-id' under the 'vpn-node' for the
            indicated address family. For example, Router IDs can be
            configured per address family. This capability can be used, for
            example, to configure an IPv6 address as a Router ID when such a
            capability is supported by involved routers. <vspace
            blankLines="1" />Values </t>
            <t>Values defined in 'active-vpn-instance-profiles'
            overrides
            override the ones values defined in at the VPN service level. An example is
            shown in <xref target="app-ex"></xref>.</t>

            <t hangText="'msdp':">For target="app-ex" format="default"/>.</t>
          </dd>
          <dt>'msdp':</dt>
          <dd>For redundancy purposes, the Multicast Source
            Discovery Protocol (MSDP) <xref target="RFC3618"></xref> target="RFC3618" format="default"/> may be
            enabled and used to share the state information about sources between multiple
            Rendezvous Points (RPs). The purpose of MSDP in this context is to
            enhance the robustness of the multicast service. MSDP may be
            configured on non-RP routers, which routers; this is useful in a domain that
            does not support multicast sources, sources but does support multicast
            transit.</t>

            <t hangText="'groups':">Lists
            transit.</dd>
          <dt>'groups':</dt>
          <dd>Lists the groups to which a VPN node
            belongs to <xref target="I-D.ietf-opsawg-vpn-common"></xref>. The target="RFC9181" format="default"/>. For example, the
            'group-id' is used to associate, e.g., associate redundancy or protection
            constraints with VPN nodes.</t>

            <t hangText="'status':">Tracks nodes.</dd>
          <dt>'status':</dt>
          <dd>Tracks the status of a node involved in a
            VPN service. Both operational status and administrative status are
            maintained. A mismatch between the administrative status vs. the
            operational status can be used as a trigger to detect
            anomalies.</t>

            <t hangText="'vpn-network-accesses':">Represents
            anomalies.</dd>
          <dt>'vpn-network-accesses':</dt>
          <dd>
            <t>Represents the point to
            which sites are connected. <vspace blankLines="1" />Note that, </t>
            <t>Note that
            unlike in the L3SM, the L3NM does not need to model the customer
            site,
            site -- only the points where the that receive traffic from the site are received
            (i.e., the PE side of PE-CE Provider Edge to Customer Edge (PE-CE) connections). Hence, the VPN network
            access contains the connectivity information between the
            provider's network and the customer premises. The VPN profiles
            ('vpn-profiles') have a set of routing policies that can be
            applied during the service creation. <vspace blankLines="1" />See </t>
            <t>See
            <xref target="sna"></xref> target="sna" format="default"/> for more details.</t>
          </list></t>

        <t></t>
          </dd>
        </dl>
      </section>
      <section anchor="sna" title="VPN numbered="true" toc="default">
        <name>VPN Network Accesses"> Accesses</name>
        <t>The 'vpn-network-access' includes a set of data nodes that describe
        the access information for the traffic that belongs to a particular
        L3VPN (<xref target="vpnaccess"></xref>).</t>

        <t><figure align="center" anchor="vpnaccess"
            title="VPN target="vpnaccess" format="default"/>).</t>
        <figure anchor="vpnaccess">
          <name>VPN Network Access Subtree Structure">
            <artwork align="left"><![CDATA[... Structure</name>
          <sourcecode name="" type="yangtree"><![CDATA[...
+--rw vpn-nodes
   +--rw vpn-node* [vpn-node-id]
      ...
      +--rw vpn-network-accesses
         +--rw vpn-network-access* [id]
            +--rw id                         vpn-common:vpn-id
            +--rw interface-id?              string
            +--rw description?               string
            +--rw vpn-network-access-type?   identityref
            +--rw vpn-instance-profile?      leafref
            +--rw status
            |  +--rw admin-status
            |  |  +--rw status?         identityref
            |  |  +--rw last-change?   yang:date-and-time
            |  +--ro oper-status
            |     +--ro status?         identityref
            |     +--ro last-change?   yang:date-and-time
            +--rw connection
            |  ...
            +--rw ip-connection
            |  ...
            +--rw routing-protocols
            |  ...
            +--rw oam
            |  ...
            +--rw security
            |  ...
            +--rw service
               ...
]]></artwork>
          </figure></t>

        <t>In reference to the subtree depicted in <xref
        target="vpnaccess"></xref>, a
]]></sourcecode>
        </figure>
        <t>A 'vpn-network-access' (<xref target="vpnaccess" format="default"/>) includes the following data nodes: <list style="hanging">
            <t hangText="'id':">Is an nodes:</t>
        <dl newline="false" spacing="normal">
          <dt>'id':</dt>
          <dd>An identifier of the VPN network
            access.</t>

            <t hangText="'interface-id':">Indicates
            access.</dd>
          <dt>'interface-id':</dt>
          <dd>Indicates the physical or logical
            interface on which the VPN network access is bound.</t>

            <t hangText="'description':">Includes bound.</dd>
          <dt>'description':</dt>
          <dd>Includes a textual description of the
            VPN network access.</t>

            <t hangText="'vpn-network-access-type':">Is used access.</dd>
          <dt>'vpn-network-access-type':</dt>
          <dd>
            <t>Used to select the
            type of network interface to be deployed in the devices. The
            available defined values are: <list style="hanging">
                <t hangText="'point-to-point':">Represents are as follows:</t>
            <dl newline="false" spacing="normal">
              <dt>'point-to-point':</dt>
              <dd>Represents a direct connection
                between the endpoints. The controller must keep the
                association between a logical or physical interface on the
                device with the 'id' of the 'vpn-network-access'.</t>

                <t hangText="'multipoint':">Represents 'vpn-network-access'.</dd>
              <dt>'multipoint':</dt>
              <dd>Represents a multipoint connection
                between the customer site and the PEs. The controller must
                keep the association between a logical or physical interface
                on the device with the 'id' of the 'vpn-network-access'.</t>

                <t hangText="'irb':">Represents 'vpn-network-access'.</dd>
              <dt>'irb':</dt>
              <dd>Represents a connection coming from an
                L2VPN service. An identifier of such a service ('l2vpn-id') may
                be included in the 'connection' container container, as depicted in <xref
                target="bearerethencap_tree"></xref>. target="bearerethencap_tree" format="default"/> (<xref target="connection"/>). The controller must keep
                the relationship between the logical tunnels or bridges on the
                devices with the 'id' of the' vpn-network-access'.</t>

                <t hangText="'loopback':">Represents the 'vpn-network-access'.</dd>
              <dt>'loopback':</dt>
              <dd>Represents the creation of a logical
                interface on a device. An example to illustrate that illustrates how a loopback
                interface can be used in the L3NM is provided in <xref
                target="loop"></xref>.</t>
              </list></t>

            <t hangText="'vpn-instance-profile':">Provides target="loop" format="default"/>.</dd>
            </dl>
          </dd>
          <dt>'vpn-instance-profile':</dt>
          <dd>Provides a pointer to an
            active VPN instance profile at the VPN node level. Referencing an
            active VPN instance profile implies that all associated data nodes
            will be inherited by the VPN network access. However, some
            inherited data nodes (e.g., multicast) can be overridden at the
            VPN network access level. In such a case, adjusted values take
            precedence over inherited ones.</t>

            <t hangText="'status':">Indicates values.</dd>
          <dt>'status':</dt>
          <dd>Indicates both operational status and
            administrative status of a VPN network access.</t>

            <t hangText="'connection':">Represents access.</dd>
          <dt>'connection':</dt>
          <dd>Represents and groups the set of Layer
            2 connectivity from where the traffic of the L3VPN in a particular
            VPN Network network access is coming. See <xref
            target="connection"></xref>.</t>

            <t hangText="'ip-connection':">Contains target="connection" format="default"/>.</dd>
          <dt>'ip-connection':</dt>
          <dd>Contains Layer 3 connectivity
            information of on a VPN network access (e.g., IP addressing). See
            <xref target="ip_conn"></xref>.</t>

            <t hangText="'routing-protocols':">Includes target="ip_conn" format="default"/>.</dd>
          <dt>'routing-protocols':</dt>
          <dd>Includes the CE-PE routing
            configuration information. See <xref target="rtg"></xref>.</t>

            <t hangText="'oam':">Specifies target="rtg" format="default"/>.</dd>
          <dt>'oam':</dt>
          <dd>Specifies the Operations, Administration, and
            Maintenance (OAM) mechanisms used for a VPN network access. See
            <xref target="sec-oam"></xref>.</t>

            <t hangText="'security':">Specifies target="sec-oam" format="default"/>.</dd>
          <dt>'security':</dt>
          <dd>Specifies the authentication and the
            encryption to be applied for a given VPN network access. See <xref
            target="sec"></xref>.</t>

            <t hangText="'service':">Specifies target="sec" format="default"/>.</dd>
          <dt>'service':</dt>
          <dd>Specifies the service parameters (e.g.,
            QoS, multicast) to apply for a given VPN network access. See <xref
            target="svc"></xref>.</t>
          </list></t>

        <t></t> target="svc" format="default"/>.</dd>
        </dl>
        <section anchor="connection" title="Connection"> numbered="true" toc="default">
          <name>Connection</name>
          <t>The 'connection' container represents the layer Layer 2 connectivity to
          the L3VPN for a particular VPN network access. As shown in the tree
          depicted in <xref target="bearerethencap_tree"></xref>, target="bearerethencap_tree" format="default"/>, the
          'connection' container defines protocols and parameters to enable
          such connectivity at layer Layer 2.</t>
          <t>The traffic can enter the VPN with or without encapsulation
          (e.g., VLAN, QinQ). The 'encapsulation' container specifies the
          layer
          Layer 2 encapsulation to use (if any) and allows to configure the configuration of the
          relevant tags.</t>
          <t>The interface that is attached to the L3VPN is identified by the
          'interface-id' at the 'vpn-network-access' level. From a network
          model perspective, it is expected that the 'interface-id' is
          sufficient to identify the interface. However, specific layer Layer 2
          sub-interfaces may be required to be configured in some
          implementations/deployments. Such a layer 2 specific Layer-2-specific interface can
          be included in 'l2-termination-point'.</t>
          <t>If a layer Layer 2 tunnel is needed to terminate the service in the
          CE-PE connection, the 'l2-tunnel-service' container is used to
          specify the required parameters to set such a tunneling service (e.g.,
          VPLS, VXLAN).
          a Virtual Private LAN Service (VPLS) or a Virtual eXtensible Local Area Network (VXLAN)). An identity, identity called 'l2-tunnel-type', 'l2-tunnel-type' is defined for
          layer
          Layer 2 tunnel selection. The container can also identify the
          pseudowire (Section 6.1 of <xref target="RFC8077"></xref>).</t> (<xref target="RFC8077" sectionFormat="of" section="6.1"/>).</t>
          <t>As discussed in <xref target="sna"></xref>, target="sna" format="default"/>, 'l2vpn-id' is used to
          identify the L2VPN service that is associated with an IRB Integrated Routing and Bridging (IRB)
          interface.</t>
          <t>To accommodate implementations that require internal bridging, a
          local bridge reference can be specified in 'local-bridge-reference'.
          Such a reference may be a local bridge domain.</t>
          <t>A site, as per <xref target="RFC4176"></xref> target="RFC4176" format="default"/>, represents a VPN
          customer's location that is connected to the service provider
          network via a CE-PE link, which can access at least one VPN. The
          connection from the site to the service provider network is the
          bearer. Every site is associated with a list of bearers. A bearer is
          the layer two Layer 2 connection with the site. In the L3NM, it is assumed
          that the bearer has been allocated by the service provider at the
          service orchestration stage. The bearer is associated to with a network
          element and a port. Hence, a bearer is just a 'bearer-reference' to
          allow the association between a service request (e.g., the L3SM) and
          the L3NM.</t>
          <t>The L3NM can be used to create a LAG Link Aggregation Group (LAG) interface for a given L3VPN
          service ('lag-interface') <xref target="IEEE802.1AX"></xref>. target="IEEE802.1AX" format="default"/>. Such a
          LAG interface can be referenced under 'interface-id' (<xref
          target="sna"></xref>).</t>

          <t><figure align="center" anchor="bearerethencap_tree"
              title="Connection target="sna" format="default"/>).</t>
          <figure anchor="bearerethencap_tree">
            <name>Connection Subtree Structure">
              <artwork align="center"><![CDATA[... Structure</name>
            <sourcecode name="" type="yangtree"><![CDATA[...
+--rw connection
|  +--rw encapsulation
|  |  +--rw type?              identityref
|  |  +--rw dot1q
|  |  |  +--rw tag-type?   identityref
|  |  |  +--rw cvlan-id?   uint16
|  |  +--rw priority-tagged
|  |  |  +--rw tag-type?   identityref
|  |  +--rw qinq
|  |     +--rw tag-type?   identityref
|  |     +--rw svlan-id    uint16
|  |     +--rw cvlan-id    uint16
|  +--rw (l2-service)?
|  |  +--:(l2-tunnel-service)
|  |  |  +--rw l2-tunnel-service
|  |  |     +--rw type?         identityref
|  |  |     +--rw pseudowire
|  |  |     |  +--rw vcid?      uint32
|  |  |     |  +--rw far-end?   union
|  |  |     +--rw vpls
|  |  |     |  +--rw vcid?      uint32
|  |  |     |  +--rw far-end*   union
|  |  |     +--rw vxlan
|  |  |        +--rw vni-id             uint32
|  |  |        +--rw peer-mode?         identityref
|  |  |        +--rw peer-ip-address*   inet:ip-address
|  |  +--:(l2vpn)
|  |     +--rw l2vpn-id?            vpn-common:vpn-id
|  +--rw l2-termination-point?      string
|  +--rw local-bridge-reference?    string
|  +--rw bearer-reference?          string
|  |       {vpn-common:bearer-reference}?
|  +--rw lag-interface {vpn-common:lag-interface}?
|     +--rw lag-interface-id?   string
|     +--rw member-link-list
|        +--rw member-link* [name]
|           +--rw name    string
...
]]></artwork>
            </figure></t>
]]></sourcecode>
          </figure>
        </section>
        <section anchor="ip_conn" title="IP Connection"> numbered="true" toc="default">
          <name>IP Connection</name>
          <t>This container is used to group Layer 3 connectivity information,
          particularly the IP addressing information, of a VPN network access.
          The allocated address represents the PE interface address
          configuration. Note that a distinct layer Layer 3 interface other than the
          one
          interface indicated under the 'connection' container may be needed to
          terminate the layer Layer 3 service. The identifier of such an interface is
          included in 'l3-termination-point'. For example, this data node can
          be used to carry the identifier of a bridge domain interface.</t>
          <t>As shown in <xref target="ip_conn_tree"></xref>, target="ip_conn_tree" format="default"/>, the
          'ip-connection' container can include IPv4, IPv6, or both if
          dual-stack is enabled.</t>

          <t><figure align="center" anchor="ip_conn_tree"
              title="IP
          <figure anchor="ip_conn_tree">
            <name>IP Connection Subtree Structure">
              <artwork align="center"><![CDATA[... Structure</name>
            <sourcecode name="" type="yangtree"><![CDATA[...
+--rw vpn-network-accesses
   +--rw vpn-network-access* [id]
      ...
      +--rw ip-connection
      |  +--rw l3-termination-point?     string
      |  +--rw ipv4 {vpn-common:ipv4}?
      |  |  ...
      |  +--rw ipv6 {vpn-common:ipv6}?
      |     ...
      ...

]]></artwork>
            </figure></t>
]]></sourcecode>
          </figure>
          <t>For both IPv4 and IPv6, the IP connection supports three IP
          address assignment modes for customer addresses: provider DHCP, DHCP
          relay, and static addressing. Note that for the IPv6 case, SLAAC Stateless Address Autoconfiguration (SLAAC)
          <xref target="RFC4862"></xref> target="RFC4862" format="default"/> can be used. For both IPv4 and IPv6,
          'address-allocation-type' is used to indicate the IP address
          allocation mode to activate for a given VPN network access.</t>
          <t>When 'address-allocation-type' is set to 'provider-dhcp', DHCP
          assignments can be made locally or by an external DHCP server. Such
          as
          behavior is controlled by setting 'dhcp-service-type'.</t>
          <t><xref target="ip_conn_tree_v4"></xref> target="ip_conn_tree_v4" format="default"/> shows the structure of the
          dynamic IPv4 address assignment (i.e., by means of DHCP).</t>

          <t><figure align="center" anchor="ip_conn_tree_v4"
              title="IP
          <figure anchor="ip_conn_tree_v4">
            <name>IP Connection Subtree Structure (IPv4)">
              <artwork align="center"><![CDATA[... (IPv4)</name>
            <sourcecode name="" type="yangtree"><![CDATA[...
+--rw ip-connection
|  +--rw l3-termination-point?     string
|  +--rw ipv4 {vpn-common:ipv4}?
|  |  +--rw local-address?             inet:ipv4-address
|  |  +--rw prefix-length?             uint8
|  |  +--rw address-allocation-type?   identityref
|  |  +--rw (allocation-type)?
|  |     +--:(provider-dhcp)
|  |     |  +--rw dhcp-service-type?   enumeration
|  |     |  +--rw (service-type)?
|  |     |     +--:(relay)
|  |     |     |  +--rw server-ip-address*
|  |     |     |          inet:ipv4-address
|  |     |     +--:(server)
|  |     |        +--rw (address-assign)?
|  |     |           +--:(number)
|  |     |           |  +--rw number-of-dynamic-address?
|  |     |           |           uint16
|  |     |           +--:(explicit)
|  |     |              +--rw customer-addresses
|  |     |                 +--rw address-pool* [pool-id]
|  |     |                    +--rw pool-id          string
|  |     |                    +--rw start-address
|  |     |                    |           inet:ipv4-address
|  |     |                    +--rw end-address?
|  |     |                                inet:ipv4-address
|  |     +--:(dhcp-relay)
|  |     |  +--rw customer-dhcp-servers
|  |     |     +--rw server-ip-address*   inet:ipv4-address
|  |     +--:(static-addresses)
|  |        ...
...
]]></artwork>
            </figure></t>
]]></sourcecode>
          </figure>
          <t><xref target="ip_conn_tree_v6"></xref> target="ip_conn_tree_v6" format="default"/> shows the structure of the
          dynamic IPv6 address assignment (i.e., DHCPv6 and/or SLAAC). Note
          that if 'address-allocation-type' is set to 'slaac', the Prefix
          Information option of Router Advertisements that will be issued for
          SLAAC purposes, purposes will carry the IPv6 prefix that is determined by
          'local-address' and 'prefix-length'. For example, if 'local-address'
          is set to '2001:db8:0:1::1' and 'prefix-length' is set to '64', the
          IPv6 prefix that will be used is '2001:db8:0:1::/64'.</t>

          <t><figure align="center" anchor="ip_conn_tree_v6"
              title="IP
          <figure anchor="ip_conn_tree_v6">
            <name>IP Connection Subtree Structure (IPv6)">
              <artwork align="center"><![CDATA[... (IPv6)</name>
            <sourcecode name="" type="yangtree"><![CDATA[...
+--rw ip-connection
|  +--rw l3-termination-point?     string
|  +--rw ipv4 {vpn-common:ipv4}?
|  |  ...
|  +--rw ipv6 {vpn-common:ipv6}?
|     +--rw local-address?                 inet:ipv6-address
|     +--rw prefix-length?                 uint8
|     +--rw address-allocation-type?       identityref
|     +--rw (allocation-type)?
|        +--:(provider-dhcp)
|        |  +--rw provider-dhcp
|        |     +--rw dhcp-service-type?
|        |     |       enumeration
|        |     +--rw (service-type)?
|        |        +--:(relay)
|        |        |  +--rw server-ip-address*
|        |        |          inet:ipv6-address
|        |        +--:(server)
|        |           +--rw (address-assign)?
|        |              +--:(number)
|        |              |  +--rw number-of-dynamic-address?
|        |              |          uint16
|        |              +--:(explicit)
|        |                 +--rw customer-addresses
|        |                    +--rw address-pool*  [pool-id]
|        |                       +--rw pool-id      string
|        |                       +--rw start-address
|        |                       |       inet:ipv6-address
|        |                       +--rw end-address?
|        |                               inet:ipv6-address
|        +--:(dhcp-relay)
|        |  +--rw customer-dhcp-servers
|        |     +--rw server-ip-address*
|        |             inet:ipv6-address
|        +--:(static-addresses)
|           ...

]]></artwork>
            </figure></t>
]]></sourcecode>
          </figure>
          <t>In the case of the static addressing (<xref
          target="ip_conn_tree-static"></xref>), target="ip_conn_tree-static" format="default"/>), the model supports the
          assignment of several IP addresses in the same 'vpn-network-access'.
          To identify which of the addresses is the primary address of a
          connection, the 'primary-address' reference MUST <bcp14>MUST</bcp14> be set with the
          corresponding 'address-id'.</t>
          <figure align="center" anchor="ip_conn_tree-static"
                  title="IP anchor="ip_conn_tree-static">
            <name>IP Connection Subtree Structure (Static Mode)">
            <artwork align="center"><![CDATA[... Mode)</name>
            <sourcecode name="" type="yangtree"><![CDATA[...
+--rw ip-connection
|  +--rw l3-termination-point?     string
|  +--rw ipv4 {vpn-common:ipv4}?
|  |  +--rw address-allocation-type?         identityref
|  |  +--rw (allocation-type)?
|  |     ...
|  |     +--:(static-addresses)
|  |        +--rw primary-address?        -> ../address/address-id
|  |        +--rw address* [address-id]
|  |           +--rw address-id          string
|  |           +--rw customer-address?   inet:ipv4-address
|  +--rw ipv6 {vpn-common:ipv6}?
|     +--rw address-allocation-type?         identityref
|     +--rw (allocation-type)?
|        ...
|        +--:(static-addresses)
|           +--rw primary-address?     -> ../address/address-id
|           +--rw address* [address-id]
|              +--rw address-id          string
|              +--rw customer-address?   inet:ipv6-address
...
]]></artwork>
]]></sourcecode>
          </figure>

          <t></t>
        </section>
        <section anchor="rtg" title="CE-PE numbered="true" toc="default">
          <name>CE-PE Routing Protocols"> Protocols</name>
          <t>A VPN service provider can configure one or more routing
          protocols associated with a particular 'vpn-network-access'. Such
          routing protocols are enabled between the PE and the CE. Each
          instance is uniquely identified to accommodate scenarios where
          multiple instances of the same routing protocol have to be
          configured on the same link.</t>
          <t>The subtree of the 'routing-protocols' is shown in <xref
          target="routing"></xref>.</t>

          <t><figure align="center" anchor="routing"
              title="Routing target="routing" format="default"/>.</t>
          <figure anchor="routing">
            <name>Routing Subtree Structure">
              <artwork align="center"><![CDATA[ Structure</name>
            <sourcecode name="" type="yangtree"><![CDATA[  ...
  +--rw vpn-network-accesses
     +--rw vpn-network-access* [id]
        ...
        +--rw routing-protocols
        |  +--rw routing-protocol* [id]
        |     +--rw id   string
        |     +--rw type?               identityref
        |     +--rw routing-profiles* [id]
        |     |  +--rw id      leafref
        |     |  +--rw type?   identityref
        |     +--rw static
        |     |  ...
        |     +--rw bgp
        |     |  ...
        |     +--rw ospf
        |     |  ...
        |     +--rw isis
        |     |  ...
        |     +--rw rip
        |     |  ...
        |     +--rw vrrp
        |        ...
        +--rw security
            ...
]]></artwork>
            </figure></t>
]]></sourcecode>
          </figure>
          <t>Multiple routing instances can be defined; defined, each uniquely
          identified by an 'id'. The type of routing instance is indicated in
          'type'. The values of these attributes are those defined in <xref
          target="I-D.ietf-opsawg-vpn-common"></xref> ('routing-protocol-type' target="RFC9181" format="default"/> (the 'routing-protocol-type'
          identity).</t>
          <t>Configuring multiple instances of the same routing protocol does
          not automatically imply that, from a device configuration
          perspective, there will be parallel instances (e.g., multiple
          processes) running on the PE-CE link. It is up to each
          implementation (typically, network orchestration orchestration, as shown in <xref
          target="xml_happy"></xref>) target="xml_happy" format="default"/>) to decide about on the appropriate
          configuration as a function of underlying capabilities and service
          provider operational guidelines. As an example, when multiple BGP
          peers need to be implemented, multiple instances of BGP must be
          configured as part of this model. However, from a device
          configuration point of view, this could be implemented as: <list
              style="symbols">
              <t>Multiple as:</t>
          <ul spacing="normal">
            <li>Multiple BGP processes with a single neighbor running in each
              process.</t>

              <t>A
              process.</li>
            <li>A single BGP process with multiple neighbors running.</t>

              <t>A running.</li>
            <li>A combination thereof.</t>
            </list></t> thereof.</li>
          </ul>
          <t>Routing configuration does not include low-level policies. Such
          policies are handled at the device configuration level. Local
          policies of a service provider (e.g., filtering) are implemented as
          part of the device configuration; these are not captured in the
          L3NM, but the model allows local profiles to be associated with
          routing instances ('routing-profiles'). Note that these routing
          profiles can be scoped to capture parameters that are globally
          applied to all L3VPN services within a service provider network,
          while customized L3VPN parameters are captured by means of the L3NM.
          The provisioning of an L3VPN service will, thus, will thus rely upon the
          instantiation of these global routing profiles and the customized
          L3NM.</t>
          <section title="Static Routing"> numbered="true" toc="default">
            <name>Static Routing</name>
            <t>The L3NM supports the configuration of one or more IPv4/IPv6
            static routes. Since the same structure is used for both IPv4 and
            IPv6, it was considered to have using one single container to group both
            static entries independently of their address family, family was considered at one time, but that
            design was abandoned to ease the mapping with mapping, using the structure provided in
            <xref target="RFC8299"></xref>.</t>

            <t><figure align="center" anchor="routing-static"
                title="Static target="RFC8299" format="default"/>.</t>

            <t>The static routing subtree structure is shown in <xref target="routing-static"/>.</t>
            <figure anchor="routing-static">
              <name>Static Routing Subtree Structure">
                <artwork align="center"><![CDATA[... Structure</name>
              <sourcecode name="" type="yangtree"><![CDATA[...
+--rw routing-protocols
|  +--rw routing-protocol* [id]
|     ...
|     +--rw static
|     |  +--rw cascaded-lan-prefixes
|     |     +--rw ipv4-lan-prefixes*
|     |     |       [lan next-hop]
|     |     |       {vpn-common:ipv4}?
|     |     |  +--rw lan         inet:ipv4-prefix
|     |     |  +--rw lan-tag?      string
|     |     |  +--rw next-hop      union
|     |     |  +--rw bfd-enable?   boolean
|     |     |  +--rw metric?       uint32
|     |     |  +--rw preference?   uint32
|     |     |  +--rw status
|     |     |     +--rw admin-status
|     |     |     |  +--rw status?         identityref
|     |     |     |  +--rw last-change?   yang:date-and-time
|     |     |     +--ro oper-status
|     |     |        +--ro status?         identityref
|     |     |        +--ro last-change?   yang:date-and-time
|     |     +--rw ipv6-lan-prefixes*
|     |             [lan next-hop]
|     |             {vpn-common:ipv6}?
|     |        +--rw lan         inet:ipv6-prefix
|     |        +--rw lan-tag?      string
|     |        +--rw next-hop      union
|     |        +--rw bfd-enable?   boolean
|     |        +--rw metric?       uint32
|     |        +--rw preference?   uint32
|     |        +--rw status
|     |           +--rw admin-status
|     |           |  +--rw status?         identityref
|     |           |  +--rw last-change?   yang:date-and-time
|     |           +--ro oper-status
|     |              +--ro status?         identityref
|     |              +--ro last-change?   yang:date-and-time
...
]]></artwork>
              </figure></t>
]]></sourcecode>
            </figure>
            <t>As depicted in <xref target="routing-static"></xref>, target="routing-static" format="default"/>, the
            following data nodes can be defined for a given IP prefix:<list
                style="hanging">
                <t hangText="'lan-tag':">Indicates prefix:</t>
            <dl newline="false" spacing="normal">
              <dt>'lan-tag':</dt>
              <dd>Indicates a local tag (e.g.,
                "myfavourite-lan")
                "myfavorite-lan") that is used to enforce local policies.</t>

                <t hangText="'next-hop':">Indicates policies.</dd>
              <dt>'next-hop':</dt>
              <dd>Indicates the next-hop next hop to be used
                for the static route. It can be identified by an IP address,
                an interface, etc.</t>

                <t hangText="'bfd-enable':">Indicates
                a predefined next-hop type (e.g., 'discard' or 'local-link'), etc.</dd>
              <dt>'bfd-enable':</dt>
              <dd>Indicates whether BFD is enabled
                or disabled for this static route entry.</t>

                <t hangText="'metric':">Indicates entry.</dd>
              <dt>'metric':</dt>
              <dd>Indicates the metric associated with
                the static route entry.</t>

                <t hangText="'preference':">Indicates entry. This metric is used when the route is exported
                into an IGP.</dd>
              <dt>'preference':</dt>
              <dd>Indicates the preference
                associated with the static route entry. This preference is
                used to selecting select a preferred route among routes to the same
                destination prefix.</t>

                <t hangText="'status':">Used prefix.</dd>
              <dt>'status':</dt>
              <dd>Used to convey the status of a static
                route entry. This data node can also be used to control the
                (de)activation of individual static route entries.</t>
              </list></t>

            <t></t> entries.</dd>
            </dl>
          </section>
          <section title="BGP"> numbered="true" toc="default">
            <name>BGP</name>
            <t>The L3NM allows the configuration of a BGP neighbor, including
            a set for of parameters that are pertinent to be tweaked at the
            network level for service customization purposes. <vspace
            blankLines="1" />The The 'bgp' container does not aim to include every
            BGP parameter; a comprehensive set of parameters belongs more to
            the BGP device model. model.</t>
            <t>The BGP routing subtree structure is shown in <xref target="routing-bgp"/>.</t>
            <figure align="center" anchor="routing-bgp"
                title="BGP anchor="routing-bgp">
              <name>BGP Routing Subtree Structure">
                <artwork align="center"><![CDATA[... Structure</name>
              <sourcecode name="" type="yangtree"><![CDATA[...
+--rw routing-protocols
|  +--rw routing-protocol* [id]
|     ...
|     +--rw bgp
|     |  +--rw description?               string
|     |  +--rw local-as?                  inet:as-number
|     |  +--rw peer-as                    inet:as-number
|     |  +--rw address-family?            identityref
|     |  +--rw local-address?             union
|     |  +--rw neighbor*                  inet:ip-address
|     |  +--rw multihop?                  uint8
|     |  +--rw as-override?               boolean
|     |  +--rw allow-own-as?              uint8
|     |  +--rw prepend-global-as?         boolean
|     |  +--rw send-default-route?        boolean
|     |  +--rw site-of-origin?            rt-types:route-origin
|     |  +--rw ipv6-site-of-origin?       rt-types:ipv6-route-origin
|     |  +--rw redistribute-connected* [address-family]
|     |  |  +--rw address-family    identityref
|     |  |  +--rw enable?           boolean
|     |  +--rw bgp-max-prefix
|     |  |  +--rw max-prefix?          uint32
|     |  |  +--rw warning-threshold?   decimal64
|     |  |  +--rw violate-action?      enumeration
|     |  |  +--rw restart-timer?       uint32
|     |  +--rw bgp-timers
|     |  |  +--rw keepalive?   uint16
|     |  |  +--rw hold-time?   uint16
|     |  +--rw authentication
|     |  |  +--rw enable?            boolean
|     |  |  +--rw keying-material
|     |  |     +--rw (option)?
|     |  |        +--:(ao)
|     |  |        |  +--rw enable-ao?         boolean
|     |  |        |  +--rw ao-keychain?       key-chain:key-chain-ref
|     |  |        +--:(md5)
|     |  |        |  +--rw md5-keychain?      key-chain:key-chain-ref
|     |  |        +--:(explicit)
|     |  |        |  +--rw key-id?            uint32
|     |  |        |  +--rw key?               string
|     |  |        |  +--rw crypto-algorithm?  identityref
|     |  |        +--:(ipsec)
|     |  |           +--rw sa?             string
|     |  +--rw status
|     |     +--rw admin-status
|     |     |  +--rw status?         identityref
|     |     |  +--rw last-change?   yang:date-and-time
|     |     +--ro oper-status
|     |        +--ro status?         identityref
|     |        +--ro last-change?   yang:date-and-time
...
]]></artwork>
              </figure></t>
]]></sourcecode>
            </figure>
            <t>The following data nodes are captured in <xref
            target="routing-bgp"></xref>. target="routing-bgp" format="default"/>. It is up to the implementation
            (e.g., network orchestrator) to derive the corresponding BGP
            device configuration:<list style="hanging">
                <t hangText="'description':">Includes configuration:</t>
            <dl newline="false" spacing="normal">
              <dt>'description':</dt>
              <dd>Includes a description of the BGP
                session.</t>

                <t hangText="'local-as':">Indicates
                session.</dd>
              <dt>'local-as':</dt>
              <dd>Indicates a local AS Number (ASN) (ASN), if
                a distinct ASN is required, required other than the one ASN configured at
                the VPN node level.</t>

                <t hangText="'peer-as':">Conveys level.</dd>
              <dt>'peer-as':</dt>
              <dd>Conveys the customer's ASN.</t>

                <t hangText="'address-family':">Indicates ASN.</dd>
              <dt>'address-family':</dt>
              <dd>
                <t>Indicates the address-family address family
                of the peer. It can be set to IPv4, IPv6, 'ipv4', 'ipv6', or dual-stack.
                <vspace blankLines="1" />This 'dual-stack'.
                </t>
                <t>This address family will be used
                together with the 'vpn-type' to derive the appropriate Address
                Family Identifiers (AFIs)/Subsequent (AFIs) / Subsequent Address Family
                Identifiers (SAFIs) that will be part of the derived device
                configurations (e.g., Unicast unicast IPv4 MPLS L3VPN (AFI,SAFI =
                1,128) as defined in Section 4.3.4 of <xref
                target="RFC4364"></xref>).</t>

                <t hangText="'local-address':">Specifies target="RFC4364" sectionFormat="of" section="4.3.4"/>).</t>
              </dd>
              <dt>'local-address':</dt>
              <dd>Specifies an address or a
                reference to an interface to use when establishing the BGP
                transport session.</t>

                <t hangText="'neighbor':">Can session.</dd>
              <dt>'neighbor':</dt>
              <dd>Can indicate two neighbors (each for
                a given address-family) address family) or one neighbor (if the 'address-family'
                attribute is set to dual-stack). 'dual-stack'). A list of IP address(es) of
                the BGP neighbors neighbor(s) can be then be conveyed in this data node.</t>

                <t hangText="'multihop':">Indicates node.</dd>
              <dt>'multihop':</dt>
              <dd>Indicates the number of allowed IP
                hops between a PE and its BGP peer.</t>

                <t hangText="'as-override':">If peer.</dd>
              <dt>'as-override':</dt>
              <dd>If set, this parameter indicates
                whether ASN override is enabled, i.e., replace replacing the ASN of the
                customer specified in the AS_PATH BGP attribute with the ASN
                identified in the 'local-as' attribute.</t>

                <t hangText="'allow-own-as':">Is used attribute.</dd>
              <dt>'allow-own-as':</dt>
              <dd>Used in some topologies
                (e.g., hub-and-spoke) to allow the provider's ASN to be
                included in the AS_PATH BGP attribute received from a CE.
                Loops are prevented by setting 'allow-own-as' to a maximum
                number of the provider's ASN occurrences. This By default, this parameter is set by
                default to '0' (that is, reject any AS_PATH attribute that
                includes the provider's ASN).</t>

                <t hangText="'prepend-global-as':">When ASN).</dd>
              <dt>'prepend-global-as':</dt>
              <dd>When distinct ASNs are
                configured in at the VPN node and network access levels, this
                parameter controls whether the ASN provided at the VPN node
                level is prepended to the AS_PATH attribute.</t>

                <t hangText="'send-default-route':">Controls attribute.</dd>
              <dt>'send-default-route':</dt>
              <dd>Controls whether default
                routes can be advertised to the peer.</t>

                <t hangText="'site-of-origin':">Is meant peer.</dd>
              <dt>'site-of-origin':</dt>
              <dd>Meant to uniquely identify
                the set of routes learned from a site via a particular CE/PE
                connection and CE-PE
                connection. It is used to prevent routing loops (Section 7 of
                <xref target="RFC4364"></xref>). (<xref target="RFC4364" sectionFormat="of" section="7"/>). The Site of Origin attribute
                is encoded as a Route Origin Extended Community.</t>

                <t hangText="'ipv6-site-of-origin':">Carries Community.</dd>
              <dt>'ipv6-site-of-origin':</dt>
              <dd>Carries an IPv6 Address
                Specific BGP Extended Community that is used to indicate the
                Site of Origin for VRF information <xref
                target="RFC5701"></xref>. target="RFC5701" format="default"/>. It is used to prevent routing
                loops.</t>

                <t hangText="'redistribute-connected':">Controls
                loops.</dd>
              <dt>'redistribute-connected':</dt>
              <dd>Controls whether the
                PE-CE link is advertised to other PEs.</t>

                <t hangText="'bgp-max-prefix':">Controls PEs.</dd>
              <dt>'bgp-max-prefix':</dt>
              <dd>
                <t>Controls the behavior when a
                prefix maximum is reached.<list style="hanging">
                    <t hangText="'max-prefix':">Indicates reached.</t>
                <dl newline="false" spacing="normal">
                  <dt>'max-prefix':</dt>
                  <dd>Indicates the maximum number
                    of BGP prefixes allowed in the BGP session. If the limit
                    is reached, the action indicated in 'violate-action' will
                    be followed.</t>

                    <t hangText="'warning-threshold':">A followed.</dd>
                  <dt>'warning-threshold':</dt>
                  <dd>A warning notification
                    is triggered when this limit is reached.</t>

                    <t hangText="'violate-action':">Indicates reached.</dd>
                  <dt>'violate-action':</dt>
                  <dd>Indicates which action to
                    execute when the maximum number of BGP prefixes is
                    reached. Examples of such actions are: send include sending a warning
                    message, discard discarding extra paths from the peer, or restart restarting the
                    session.</t>

                    <t hangText="'restart-timer':">Indicates,
                    session.</dd>
                  <dt>'restart-timer':</dt>
                  <dd>Indicates, in seconds, the
                    time interval after which the BGP session will be
                    reestablished.</t>
                  </list></t>

                <t hangText="'bgp-timers': ">Two
                    reestablished.</dd>
                </dl>
              </dd>
              <dt>'bgp-timers':</dt>
              <dd>Two timers can be captured in
                this container: (1) 'hold-time' 'hold-time', which is the time interval
                that will be used for the HoldTimer (Section 4.2 of <xref
                target="RFC4271"></xref>) Hold Timer (<xref target="RFC4271" sectionFormat="of" section="4.2"/>) when establishing a BGP session. session and (2)
                'keepalive'
                'keepalive', which is the time interval for the KeepAlive timer KeepaliveTimer
                between a PE and a BGP peer (Section 4.4 of <xref
                target="RFC4271"></xref>). (<xref target="RFC4271" sectionFormat="of" section="4.4"/>). Both timers are expressed in
                seconds.</t>

                <t hangText="'authentication':">The seconds.</dd>
              <dt>'authentication':</dt>
              <dd>
                <t>The module adheres to the
                recommendations in Section 13.2 of <xref
                target="RFC4364"></xref> target="RFC4364" sectionFormat="of" section="13.2"/>, as it allows enabling TCP-AO the TCP Authentication Option (TCP-AO) <xref
                target="RFC5925"></xref> target="RFC5925" format="default"/> and accommodates the installed base
                that makes use of MD5. In addition, the module includes a
                provision for the use of IPsec.<vspace blankLines="1" />This using IPsec.</t>
                <t>This
                version of the L3NM assumes that TCP-AO specific parameters specific to the TCP-AO are preconfigured as part of the key-chain key chain that is referenced
                in the L3NM. No assumption is made about how such a key-chain key chain
                is pre-configured. preconfigured. However, the structure of the key-chain key chain
                should cover data nodes beyond those in <xref
                target="RFC8177"></xref>, target="RFC8177" format="default"/>, mainly SendID and RecvID (Section
                3.1 of <xref target="RFC5925"></xref>).</t>

                <t hangText="'status':">Indicates (<xref target="RFC5925" sectionFormat="of" section="3.1"/>).</t>
              </dd>
              <dt>'status':</dt>
              <dd>Indicates the status of the BGP
                routing instance.</t>
              </list></t> instance.</dd>
            </dl>
          </section>
          <section title="OSPF"> numbered="true" toc="default">
            <name>OSPF</name>
            <t>OSPF can be configured to run as a routing protocol on the
            'vpn-network-access'.
            'vpn-network-access'.</t>
            <t>The OSPF routing subtree structure is shown in <xref target="routing-ospf"/>.</t>
            <figure align="center" anchor="routing-ospf"
                title="OPSF anchor="routing-ospf">
              <name>OSPF Routing Subtree Structure">
                <artwork align="center"><![CDATA[... Structure</name>
              <sourcecode name="" type="yangtree"><![CDATA[...
+--rw routing-protocols
|  +--rw routing-protocol* [id]
|     ...
|     +--rw ospf
|     |  +--rw address-family?   identityref
|     |  +--rw area-id           yang:dotted-quad
|     |  +--rw metric?           uint16
|     |  +--rw sham-links  {vpn-common:rtg-ospf-sham-link}?
|     |  |  +--rw sham-link* [target-site]
|     |  |     +--rw target-site
|     |  |     |       vpn-common:vpn-id    string
|     |  |     +--rw metric?        uint16
|     |  +--rw max-lsa?          uint32
|     |  +--rw authentication
|     |  |  +--rw enable?            boolean
|     |  |  +--rw keying-material
|     |  |     +--rw (option)?
|     |  |        +--:(auth-key-chain)
|     |  |        |  +--rw key-chain?
|     |  |        |          key-chain:key-chain-ref
|     |  |        +--:(auth-key-explicit)
|     |  |        |  +--rw key-id?      uint32
|     |  |        |  +--rw key?         string
|     |  |        |  +--rw crypto-algorithm?
|     |  |        |          identityref
|     |  |        +--:(ipsec)
|     |  |           +--rw sa?    string
|     |  +--rw status
|     |     +--rw admin-status
|     |     |  +--rw status?        identityref
|     |     |  +--rw last-change?  yang:date-and-time
|     |     +--ro oper-status
|     |        +--ro status?        identityref
|     |        +--ro last-change?  yang:date-and-time
...
]]></artwork>
              </figure></t>
]]></sourcecode>
            </figure>
            <t>The following data nodes are captured in <xref
            target="routing-ospf"></xref>:<list style="hanging">
                <t hangText="'address-family':">Indicates target="routing-ospf" format="default"/>:</t>
            <dl newline="false" spacing="normal">
              <dt>'address-family':</dt>
              <dd>
                <t>Indicates whether IPv4, IPv6,
                or both address families are to be activated. <vspace
                blankLines="1" />When </t>
                <t>When the IPv4 or dual-stack address-family address family is
                requested, it is up to the implementation (e.g., network
                orchestrator) to decide whether OSPFv2 <xref
                target="RFC4577"></xref> target="RFC4577" format="default"/> or OSPFv3 <xref
                target="RFC6565"></xref> target="RFC6565" format="default"/> is used to announce IPv4 routes. Such a
                decision will be typically be reflected in the device
                configurations that will be derived to implement the
                L3VPN.</t>

                <t hangText="'area-id':">Indicates
              </dd>
              <dt>'area-id':</dt>
              <dd>Indicates the OSPF Area ID.</t>

                <t hangText="'metric':">Associates ID.</dd>
              <dt>'metric':</dt>
              <dd>Associates a metric with OSPF
                routes.</t>

                <t hangText="'sham-links':">Is used
                routes.</dd>
              <dt>'sham-links':</dt>
              <dd>Used to create OSPF sham links
                between two VPN network accesses sharing the same area and
                having a backdoor link (Section 4.2.7 of <xref
                target="RFC4577"></xref> (<xref target="RFC4577" sectionFormat="of" section="4.2.7"/> and Section 5 of <xref
                target="RFC6565"></xref>).</t>

                <t hangText="'max-lsa':">Sets target="RFC6565" sectionFormat="of" section="5"/>).</dd>
              <dt>'max-lsa':</dt>
              <dd>Sets the maximum number of LSAs Link State Advertisements (LSAs) that
                the OSPF instance will accept.</t>

                <t hangText="'authentication':">Controls accept.</dd>
              <dt>'authentication':</dt>
              <dd>Controls the authentication
                schemes to be enabled for the OSPF instance. The following
                options are supported: IPsec for OSPFv3 authentication <xref
                target="RFC4552"></xref>, authentication trailer target="RFC4552" format="default"/>, and the Authentication Trailer for OSPFv2
                <xref target="RFC5709"></xref> target="RFC5709" format="default"/> <xref target="RFC7474"></xref> target="RFC7474" format="default"/>
                and OSPFv3 <xref target="RFC7166"></xref>.</t>

                <t hangText="'status':">Indicates target="RFC7166" format="default"/>.</dd>
              <dt>'status':</dt>
              <dd>Indicates the status of the OSPF
                routing instance.</t>
              </list></t> instance.</dd>
            </dl>
          </section>
          <section title="IS-IS"> numbered="true" toc="default">
            <name>IS-IS</name>
            <t>The model (<xref target="routing-isis"></xref>) allows the user
            to configure IS-IS <xref target="ISO10589"></xref><xref
            target="RFC1195"></xref><xref target="RFC5308"></xref> target="ISO10589" format="default"/> <xref target="RFC1195" format="default"/> <xref target="RFC5308" format="default"/> to run on
            the 'vpn-network-access' interface.<figure align="center"
                anchor="routing-isis" title="IS-IS interface. See <xref target="routing-isis" format="default"/>.</t>
            <figure anchor="routing-isis">
              <name>IS-IS Routing Subtree Structure">
                <artwork align="center"><![CDATA[... Structure</name>
              <sourcecode name="" type="yangtree"><![CDATA[...
+--rw routing-protocols
|  +--rw routing-protocol* [id]
|     ...
|     +--rw isis
|     |  +--rw address-family?   identityref
|     |  +--rw area-address      area-address
|     |  +--rw level?            identityref
|     |  +--rw metric?           uint16
|     |  +--rw mode?             enumeration
|     |  +--rw authentication
|     |  |  +--rw enable?            boolean
|     |  |  +--rw keying-material
|     |  |     +--rw (option)?
|     |  |        +--:(auth-key-chain)
|     |  |        |  +--rw key-chain?
|     |  |        |          key-chain:key-chain-ref
|     |  |        +--:(auth-key-explicit)
|     |  |           +--rw key-id?             uint32
|     |  |           +--rw key?                string
|     |  |           +--rw crypto-algorithm?   identityref
|     |  +--rw status
|     |     +--rw admin-status
|     |     |  +--rw status?        identityref
|     |     |  +--rw last-change?  yang:date-and-time
|     |     +--ro oper-status
|     |        +--ro status?        identityref
|     |        +--ro last-change?  yang:date-and-time
...
]]></artwork>
              </figure></t>
]]></sourcecode>
            </figure>
            <t>The following IS-IS data nodes are supported:<list
                style="hanging">
                <t hangText="'address-family':">Indicates supported:</t>
            <dl newline="false" spacing="normal">
              <dt>'address-family':</dt>
              <dd>Indicates whether IPv4, IPv6,
                or both address families are to be activated.</t>

                <t hangText="'area-address':">Indicates activated.</dd>
              <dt>'area-address':</dt>
              <dd>Indicates the IS-IS area
                address.</t>

                <t hangText="'level':">Indicates
                address.</dd>
              <dt>'level':</dt>
              <dd>Indicates the IS-IS level: Level 1,
                Level 2, or both.</t>

                <t hangText="'metric':">Associates both.</dd>
              <dt>'metric':</dt>
              <dd>Associates a metric with IS-IS
                routes.</t>

                <t hangText="'mode':">Indicates
                routes.</dd>
              <dt>'mode':</dt>
              <dd>Indicates the IS-IS interface mode type.
                It can be set to 'active' (that is, send or receive IS-IS
                protocol control packets) or 'passive' (that is, suppress the
                sending of IS-IS updates through the interface).</t>

                <t hangText="'authentication':">Controls interface).</dd>
              <dt>'authentication':</dt>
              <dd>Controls the authentication
                schemes to be enabled for the IS-IS instance. Both the
                specification of a key-chain key chain <xref target="RFC8177"></xref> target="RFC8177" format="default"/>
                and the direct specification of key and authentication
                algorithm
                algorithms are supported.</t>

                <t hangText="'status':">Indicates supported.</dd>
              <dt>'status':</dt>
              <dd>Indicates the status of the IS-IS
                routing instance.</t>
              </list></t> instance.</dd>
            </dl>
          </section>
          <section title="RIP"> numbered="true" toc="default">
            <name>RIP</name>
            <t>The model (<xref target="rip"></xref>) allows the user to
            configure RIP to run on the 'vpn-network-access' interface.  See
            <xref target="rip" format="default"/>.</t>
            <figure align="center" anchor="rip" title="RIP anchor="rip">
              <name>RIP Subtree Structure">
                <artwork align="center"><![CDATA[... Structure</name>
              <sourcecode name="" type="yangtree"><![CDATA[...
+--rw routing-protocols
|  +--rw routing-protocol* [id]
|     ...
|     +--rw rip
|     |  +--rw address-family?   identityref
|     |  +--rw timers
|     |  |  +--rw update-interval?     uint16
|     |  |  +--rw invalid-interval?    uint16
|     |  |  +--rw holddown-interval?   uint16
|     |  |  +--rw flush-interval?      uint16
|     |  +--rw neighbor*         inet:ip-address
|     |  +--rw default-metric?   uint8
|     |  +--rw authentication
|     |  |  +--rw enable?            boolean
|     |  |  +--rw keying-material
|     |  |     +--rw (option)?
|     |  |        +--:(auth-key-chain)
|     |  |        |  +--rw key-chain?
|     |  |        |          key-chain:key-chain-ref
|     |  |        +--:(auth-key-explicit)
|     |  |           +--rw key?                string
|     |  |           +--rw crypto-algorithm?   identityref
|     |  +--rw status
|     |     +--rw admin-status
|     |     |  +--rw status?        identityref
|     |     |  +--rw last-change?  yang:date-and-time
|     |     +--ro oper-status
|     |        +--ro status?        identityref
|     |        +--ro last-change?  yang:date-and-time
...
]]></artwork>
              </figure></t>
]]></sourcecode>
            </figure>
            <t>As shown in <xref target="rip"></xref>, target="rip" format="default"/>, the following RIP data
            nodes are supported:<list style="hanging">
                <t hangText="'address-family':">Indicates supported:</t>
            <dl newline="false" spacing="normal">
              <dt>'address-family':</dt>
              <dd>Indicates whether IPv4, IPv6,
                or both address families are to be activated. This parameter
                is used to determine whether RIPv2 <xref
                target="RFC2453"></xref> and/or RIPng target="RFC2453" format="default"/>, RIP Next Generation (RIPng), or both are to be enabled <xref
                target="RFC2080"></xref>.</t>

                <t hangText="'timers':">Indicates target="RFC2080" format="default"/>.</dd>
              <dt>'timers':</dt>
              <dd>
                <t>Indicates the following timers:<list
                    style="hanging">
                    <t hangText="'update-interval':">Is the timers:</t>
                <dl newline="false" spacing="normal">
                  <dt>'update-interval':</dt>
                  <dd>The interval at which
                    RIP updates are sent.</t>

                    <t hangText="'invalid-interval':">Is the sent.</dd>
                  <dt>'invalid-interval':</dt>
                  <dd>The interval before a
                    RIP route is declared invalid.</t>

                    <t hangText="'holddown-interval':">Is the invalid.</dd>
                  <dt>'holddown-interval':</dt>
                  <dd>The interval before
                    better RIP routes are released.</t>

                    <t hangText="'flush-interval':">Is the released.</dd>
                  <dt>'flush-interval':</dt>
                  <dd>The interval before a
                    route is removed from the routing table.</t>
                  </list>These table.</dd>
                </dl>
                <t>These timers are expressed in seconds.</t>

                <t hangText="'default-metric':">Sets
              </dd>
              <dt>'default-metric':</dt>
              <dd>Sets the default RIP
                metric.</t>

                <t hangText="'authentication':">Controls
                metric.</dd>
              <dt>'authentication':</dt>
              <dd>Controls the authentication
                schemes to be enabled for the RIP instance.</t>

                <t hangText="'status':">Indicates instance.</dd>
              <dt>'status':</dt>
              <dd>Indicates the status of the RIP
                routing instance.</t>
              </list></t> instance.</dd>
            </dl>
          </section>
          <section title="VRRP"> numbered="true" toc="default">
            <name>VRRP</name>
            <t>The model (<xref target="vrrp"></xref>) allows enabling VRRP the Virtual Router Redundancy Protocol (VRRP) on
            the 'vpn-network-access' interface. See <xref target="vrrp" format="default"/>.</t>
            <figure align="center"
                anchor="vrrp" title="VRRP anchor="vrrp">
              <name>VRRP Subtree Structure">
                <artwork align="center"><![CDATA[... Structure</name>
              <sourcecode name="" type="yangtree"><![CDATA[...
+--rw routing-protocols
|  +--rw routing-protocol* [id]
|     ...
|     +--rw vrrp
|        +--rw address-family*   identityref
|        +--rw vrrp-group?       uint8
|        +--rw backup-peer?      inet:ip-address
|        +--rw virtual-ip-address*   inet:ip-address
|        +--rw priority?         uint8
|        +--rw ping-reply?       boolean
|        +--rw status
|           +--rw admin-status
|           |  +--rw status?        identityref
|           |  +--rw last-change?  yang:date-and-time
|           +--ro oper-status
|              +--ro status?        identityref
|              +--ro last-change?  yang:date-and-time
...
]]></artwork>
              </figure></t>
]]></sourcecode>
            </figure>
            <t>The following data nodes are supported:<list style="hanging">
                <t hangText="'address-family':">Indicates supported:</t>
            <dl newline="false" spacing="normal">
              <dt>'address-family':</dt>
              <dd>Indicates whether IPv4, IPv6,
                or both address families are to be activated. Note that VRRP
                version 3 <xref target="RFC5798"></xref> target="RFC5798" format="default"/> supports both IPv4
                and IPv6.</t>

                <t hangText="'vrrp-group':">Is used IPv6.</dd>
              <dt>'vrrp-group':</dt>
              <dd>Used to identify the VRRP
                group.</t>

                <t hangText="'backup-peer':">Carries
                group.</dd>
              <dt>'backup-peer':</dt>
              <dd>Carries the IP address of the
                peer.</t>

                <t hangText="'virtual-ip-address':">Includes
                peer.</dd>
              <dt>'virtual-ip-address':</dt>
              <dd>Includes virtual IP
                addresses for a single VRRP group.</t>

                <t hangText="'priority':">Assigns group.</dd>
              <dt>'priority':</dt>
              <dd>Assigns the VRRP election priority
                for the backup virtual router.</t>

                <t hangText="'ping-reply':">Controls router.</dd>
              <dt>'ping-reply':</dt>
              <dd>Controls whether the VRRP speaker should
                reply to ping requests can
                be replied to.</t>

                <t hangText="'status':">Indicates requests.</dd>
              <dt>'status':</dt>
              <dd>Indicates the status of the VRRP
                instance.</t>
              </list>Note
                instance.</dd>
            </dl>
            <t>Note that no authentication data node is included for
            VRRP
            VRRP, as there isn't currently any type of VRRP authentication at this time (see
            Section 9 of
            <xref target="RFC5798"></xref>).</t> target="RFC5798" sectionFormat="of" section="9"/>).</t>
          </section>
        </section>
        <section anchor="sec-oam" title="OAM"> numbered="true" toc="default">
          <name>OAM</name>
          <t>This container (<xref target="oam"></xref>) target="oam" format="default"/>) defines the
          Operations, Administration, and Maintenance (OAM) mechanisms used
          for a VPN network access. In the current version of the L3NM, only
          BFD is supported.</t>

          <t><figure align="center" anchor="oam"
              title="IP
          <figure anchor="oam">
            <name>IP Connection Subtree Structure (OAM)">
              <artwork align="center"><![CDATA[... (OAM)</name>
            <sourcecode name="" type="yangtree"><![CDATA[...
+--rw oam
|  +--rw bfd {vpn-common:bfd}?
|     +--rw session-type?               identityref
|     +--rw desired-min-tx-interval?    uint32
|     +--rw required-min-rx-interval?   uint32
|     +--rw local-multiplier?           uint8
|     +--rw holdtime?                   uint32
|     +--rw profile?                    leafref
|     +--rw authentication!
|     |  +--rw key-chain?    key-chain:key-chain-ref
|     |  +--rw meticulous?   boolean
|     +--rw status
|        +--rw admin-status
|           |  +--rw status?         identityref
|           |  +--rw last-change?   yang:date-and-time
|           +--ro oper-status
|              +--ro status?         identityref
|              +--ro last-change?   yang:date-and-time
...            ]]></artwork>
            </figure></t>
]]></sourcecode>
          </figure>
          <t>The following OAM data nodes can be specified:</t>

          <t><list style="hanging">
              <t hangText="'session-type':">Indicates
          <dl newline="false" spacing="normal">
            <dt>'session-type':</dt>
            <dd>Indicates which BFD flavor is used
              to set up the session (e.g., classic BFD <xref
              target="RFC5880"></xref>, target="RFC5880" format="default"/>, Seamless BFD <xref
              target="RFC7880"></xref>). target="RFC7880" format="default"/>). By default, it is assumed that the BFD session is
              assumed to will
              follow the behavior specified in <xref
              target="RFC5880"></xref>.</t>

              <t hangText="'desired-min-tx-interval':">Is the target="RFC5880" format="default"/>.</dd>
            <dt>'desired-min-tx-interval':</dt>
            <dd>The minimum
              interval, in microseconds, that a PE would like to use when
              transmitting BFD Control packets packets, less any jitter applied.</t>

              <t hangText="'required-min-rx-interval':">Is the applied.</dd>
            <dt>'required-min-rx-interval':</dt>
            <dd>The minimum
              interval, in microseconds, between received BFD Control packets
              that a PE is capable of supporting, less any jitter applied by
              the sender.</t>

              <t hangText="'local-multiplier':">The sender.</dd>
            <dt>'local-multiplier':</dt>
            <dd>The negotiated transmit
              interval, multiplied by this value, provides the detection time
              for the peer.</t>

              <t hangText="'holdtime':">Is used peer.</dd>
            <dt>'holdtime':</dt>
            <dd>Used to indicate the expected BFD
              holddown time, in milliseconds. This value may be inherited from
              the service request (see Section 6.3.2.2.2 of <xref
              target="RFC8299"></xref>).</t>

              <t hangText="'profile':">Refers target="RFC8299" sectionFormat="of" section="6.3.2.2.2"/>).</dd>
            <dt>'profile':</dt>
            <dd>Refers to a BFD profile (<xref
              target="vpn_profiles"></xref>). target="vpn_profiles" format="default"/>). Such a profile can be set by the
              provider or inherited from the service request (see Section
              6.3.2.2.2 of <xref target="RFC8299"></xref>).</t>

              <t hangText="'authentication':">Includes target="RFC8299" sectionFormat="of" section="6.3.2.2.2"/>).</dd>
            <dt>'authentication':</dt>
            <dd>Includes the required
              information to enable the BFD authentication modes discussed in
              Section 6.7 of
              <xref target="RFC5880"></xref>. target="RFC5880" sectionFormat="of" section="6.7"/>. In particular particular,
              'meticulous' controls the activation of the meticulous mode as
              discussed in Sections 6.7.3 Sections&nbsp;<xref target="RFC5880" section="6.7.3"
 sectionFormat="bare"/> and 6.7.4 <xref target="RFC5880" section="6.7.4"
 sectionFormat="bare"/> of <xref
              target="RFC5880"></xref>.</t>

              <t hangText="'status':">Indicates target="RFC5880"/>.</dd>
            <dt>'status':</dt>
            <dd>Indicates the status of BFD.</t>
            </list></t> BFD.</dd>
          </dl>
        </section>
        <section anchor="sec" title="Security"> numbered="true" toc="default">
          <name>Security</name>
          <t>The 'security' container specifies the authentication and the
          encryption to be applied to traffic for a given VPN network access traffic. access. As
          depicted in the subtree shown in <xref target="security"></xref>, target="security" format="default"/>,
          the L3NM can be used to directly control the encryption to put in
          place be
          applied (e.g., Layer 2 or Layer 3 encryption) or invoke a local
          encryption profile.</t>

          <t><figure align="center" anchor="security"
              title="Security
          <figure anchor="security">
            <name>Security Subtree Structure">
              <artwork align="left"><![CDATA[ Structure</name>
            <sourcecode name="" type="yangtree"><![CDATA[     ...
     +--rw vpn-services
        +--rw vpn-service* [vpn-id]
           ...
           +--rw vpn-nodes
              +--rw vpn-node* [vpn-node-id]
                 ...
                 +--rw vpn-network-accesses
                    +--rw vpn-network-access* [id]
                       ...
                       +--rw security
                       |  +--rw encryption {vpn-common:encryption}?
                       |  |  +--rw enabled?   boolean
                       |  |  +--rw layer?     enumeration
                       |  +--rw encryption-profile
                       |     +--rw (profile)?
                       |        +--:(provider-profile)
                       |        |  +--rw profile-name?        leafref
                       |        +--:(customer-profile)
                       |           +--rw customer-key-chain?
                       |                   kc:key-chain-ref                   key-chain:key-chain-ref
                       +--rw service
                           ... ]]></artwork>
            </figure></t>
]]></sourcecode>
          </figure>
        </section>
        <section anchor="svc" title="Services"> numbered="true" toc="default">
          <name>Services</name>
          <section title="Overview"> numbered="true" toc="default">
            <name>Overview</name>
            <t>The 'service' container specifies the service parameters to
            apply for a given VPN network access (<xref
            target="services"></xref>).</t>

            <t><figure align="center" anchor="services"
                title="Services target="services" format="default"/>).</t>
            <figure anchor="services">
              <name>Services Subtree Structure">
                <artwork align="center"><![CDATA[... Structure</name>
              <sourcecode name="" type="yangtree"><![CDATA[...
+--rw vpn-network-accesses
   +--rw vpn-network-access* [id]
      ...
      +--rw service
         +--rw inbound-bandwidth? pe-to-ce-bandwidth?   uint64 {vpn-common:inbound-bw}?
         +--rw outbound-bandwidth? ce-to-pe-bandwidth?   uint64 {vpn-common:outbound-bw}?
         +--rw mtu?                  uint32
         +--rw qos {vpn-common:qos}?
         |  ...
         +--rw carriers-carrier
         |       {vpn-common:carriers-carrier}?
         |  +--rw signaling-type?   enumeration
         +--rw ntp
         |  +--rw broadcast?        enumeration
         |  +--rw auth-profile
         |  |  +--rw profile-id?    string
         |  +--rw status
         |     +--rw admin-status
         |     |  +--rw status?         identityref
         |     |  +--rw last-change?   yang:date-and-time
         |     +--ro oper-status
         |        +--ro status?         identityref
         |        +--ro last-change?   yang:date-and-time
         +--rw multicast {vpn-common:multicast}?
            ...
]]></artwork>
              </figure></t>
]]></sourcecode>
            </figure>
            <t>The following data nodes are defined: <list style="hanging">
                <t hangText="'inbound-bandwidth':">Indicates, defined:</t>
            <dl newline="false" spacing="normal">
              <dt>'pe-to-ce-bandwidth':</dt>
              <dd>Indicates, in bits per
                second (bps), the inbound bandwidth of the connection (i.e., the
                download bandwidth from the service provider to the site).</t>

                <t hangText="'outbound-bandwidth':">Indicates, site).</dd>
              <dt>'ce-to-pe-bandwidth':</dt>
              <dd>Indicates, in bps, the
                outbound bandwidth of the connection (i.e., the upload bandwidth
                from the site to the service provider).</t>

                <t hangText="'mtu':">Indicates provider).</dd>
              <dt>'mtu':</dt>
              <dd>Indicates the MTU at the service
                level.</t>

                <t hangText="'qos':">Is used
                level.</dd>
              <dt>'qos':</dt>
              <dd>Used to define a set of QoS policies
                to apply on a given connection (refer to <xref
                target="qos"></xref> target="qos" format="default"/> for more details).</t>

                <t hangText="'carriers-carrier':">Groups details).</dd>
              <dt>'carriers-carrier':</dt>
              <dd>Groups a set of parameters
                that are used when Carriers' Carriers (CsC) is enabled enabled, such
                the use of as
                using BGP for signaling purposes <xref
                target="RFC8277"></xref>.</t>

                <t hangText="'ntp':">Time target="RFC8277" format="default"/>.</dd>
              <dt>'ntp':</dt>
              <dd>Time synchronization may be needed in
                some VPNs VPNs, such as infrastructure and management VPNs. This
                container is used to enable the NTP service <xref
                target="RFC5905"></xref>.</t>

                <t hangText="'multicast':">Specifies target="RFC5905" format="default"/>.</dd>
              <dt>'multicast':</dt>
              <dd>Specifies the multicast mode and
                other data nodes nodes, such as the address-family. address family. Refer to <xref
                target="mc"></xref>.</t>
              </list></t> target="mc" format="default"/>.</dd>
            </dl>
          </section>
          <section anchor="qos" title="QoS ">
            <t>'qos' numbered="true" toc="default">
            <name>QoS</name>
            <t>The 'qos' container is used to define a set of QoS policies to
            apply on a given connection (<xref target="qos-sub"></xref>). target="qos-sub" format="default"/>). A
            QoS policy may be a classification or an action policy. For
            example, a QoS action can be defined to rate limit rate-limit
            inbound/outbound traffic of a given class of service. </t>
            <figure
                align="center" anchor="qos-sub"
                title="Services anchor="qos-sub">
              <name>Overall QoS Subtree Structure">
                <artwork align="center"><![CDATA[... Structure</name>
              <sourcecode name="" type="yangtree"><![CDATA[...
+--rw qos {vpn-common:qos}?
|  +--rw qos-classification-policy
|  |  +--rw rule* [id]
|  |     +--rw id             string
|  |     +--rw (match-type)?
|  |     |  +--:(match-flow)
|  |     |  |  +--rw (l3)?
|  |     |  |  |  +--:(ipv4)
|  |     |  |  |  |  ...
|  |     |  |  |  +--:(ipv6)
|  |     |  |  |     ...
|  |     |  |  +--rw (l4)?
|  |     |  |     +--:(tcp)
|  |     |  |     |  ...
|  |     |  |     +--:(udp)
|  |     |  |        ...
|  |     |  +--:(match-application)
|  |     |     +--rw match-application?
|  |     |             identityref
|  |     +--rw target-class-id?
|  |    string
|  +--rw qos-action
|  |  +--rw rule* [id]
|  |     +--rw id                     string
|  |     +--rw target-class-id?       string
|  |     +--rw inbound-rate-limit?    decimal64
|  |     +--rw outbound-rate-limit?   decimal64
|  +--rw qos-profile
|     +--rw qos-profile* [profile]
|        +--rw profile      leafref
|        +--rw direction?   identityref
...
]]></artwork>
              </figure></t>
]]></sourcecode>
            </figure>

            <t>QoS classification can be based on many criteria criteria, such as: <list
                style="hanging">
                <t hangText="Layer 3:">As as the following:</t>
            <dl newline="false" spacing="normal">
              <dt>Layer 3:</dt>
              <dd>As shown in <xref
                target="services-l3"></xref>, target="services-l3" format="default"/>, classification can be based on
                any IP header field or a combination thereof. Both IPv4 and
                IPv6 are supported. supported.</dd>
            </dl>
                <figure align="center"
                    anchor="services-l3" title="QoS anchor="services-l3">
                  <name>QoS Subtree Structure (L3)">
                    <artwork align="center"><![CDATA[+--rw (L3)</name>
                  <sourcecode name="" type="yangtree"><![CDATA[+--rw qos {vpn-common:qos}?
|  +--rw qos-classification-policy
|  |  +--rw rule* [id]
|  |     +--rw id           string
|  |     +--rw (match-type)?
|  |     |  +--:(match-flow)
|  |     |  |  +--rw (l3)?
|  |     |  |  |  +--:(ipv4)
|  |     |  |  |  |  +--rw ipv4
|  |     |  |  |  |     +--rw dscp?              inet:dscp
|  |     |  |  |  |     +--rw ecn?               uint8
|  |     |  |  |  |     +--rw length?            uint16
|  |     |  |  |  |     +--rw ttl?               uint8
|  |     |  |  |  |     +--rw protocol?          uint8
|  |     |  |  |  |     +--rw ihl?               uint8
|  |     |  |  |  |     +--rw flags?             bits
|  |     |  |  |  |     +--rw offset?            uint16
|  |     |  |  |  |     +--rw identification?    uint16
|  |     |  |  |  |     +--rw (destination-network)?
|  |     |  |  |  |     |  +--:(destination-ipv4-network)
|  |     |  |  |  |     |     +--rw destination-ipv4-network?
|  |     |  |  |  |     |             inet:ipv4-prefix
|  |     |  |  |  |     +--rw (source-network)?
|  |     |  |  |  |        +--:(source-ipv4-network)
|  |     |  |  |  |           +--rw source-ipv4-network?
|  |     |  |  |  |  inet:ipv4-prefix
|  |     |  |  |  +--:(ipv6)
|  |     |  |  |     +--rw ipv6
|  |     |  |  |        +--rw dscp?              inet:dscp
|  |     |  |  |        +--rw ecn?               uint8
|  |     |  |  |        +--rw length?            uint16
|  |     |  |  |        +--rw ttl?               uint8
|  |     |  |  |        +--rw protocol?          uint8
|  |     |  |  |        +--rw (destination-network)?
|  |     |  |  |        |  +--:(destination-ipv6-network)
|  |     |  |  |        |     +--rw destination-ipv6-network?
|  |     |  |  |        |             inet:ipv6-prefix
|  |     |  |  |        +--rw (source-network)?
|  |     |  |  |        |  +--:(source-ipv6-network)
|  |     |  |  |        |     +--rw source-ipv6-network?
|  |     |  |  |        |             inet:ipv6-prefix
|  |     |  |  |        +--rw flow-label?
|  |     |  |  |                   inet:ipv6-flow-label
...
]]></artwork>
                  </figure></t>

                <t hangText="Layer 4:">As
]]></sourcecode>
                </figure>
              <dl newline="false" spacing="normal">
              <dt>Layer 4:</dt>
              <dd>
                <t>As discussed in <xref
                target="I-D.ietf-opsawg-vpn-common"></xref>, target="RFC9181" format="default"/>, any layer Layer 4
                protocol can be indicated in the 'protocol' data node under
                'l3' (<xref target="services-l3"></xref>), target="services-l3" format="default"/>), but only TCP TCP- and
                UDP specific
                UDP-specific match criteria are elaborated in this version version, as
                these protocols are widely used in the context of VPN
                services. Augmentations can be considered in the future to add
                other Layer 4 specific Layer-4-specific data nodes, if needed.<vspace
                blankLines="1" />TCP needed.</t>
                <t>TCP- or UDP-related match criteria can be
                specified in the L3NM L3NM, as shown in <xref
                target="services-l4"></xref>. <vspace blankLines="1" />As target="services-l4" format="default"/>. </t>
                <t>As
                discussed in <xref
                target="I-D.ietf-opsawg-vpn-common"></xref>, target="RFC9181" format="default"/>, some transport
                protocols use existing protocols (e.g., TCP or UDP) as the
                substrate. The match criteria for such protocols may rely upon
                the 'protocol' setting under 'l3', TCP/UDP match criteria as shown in
                <xref target="services-l4"></xref>, target="services-l4" format="default"/>, part of the TCP/UDP
                payload, or a combination thereof. This version of the module
                does not support such advanced match criteria. Future
                revisions of the VPN common module or augmentations to the
                L3NM may consider adding match criteria based on the transport
                protocol payload (e.g., by means of a bitmask match). match).</t>
              </dd>
              </dl>
                <figure
                    align="center" anchor="services-l4"
                    title="QoS anchor="services-l4">
                  <name>QoS Subtree Structure (L4)">
                    <artwork align="center"><![CDATA[+--rw (L4)</name>
                  <sourcecode name="" type="yangtree"><![CDATA[+--rw qos {vpn-common:qos}?
|  +--rw qos-classification-policy
|  |  +--rw rule* [id]
|  |     +--rw id           string
|  |     +--rw (match-type)?
|  |     |  +--:(match-flow)
|  |     |  |  +--rw (l3)?
|  |     |  |  |  ...
|  |     |  |  +--rw (l4)?
|  |     |  |     +--:(tcp)
|  |     |  |     |  +--rw tcp
|  |     |  |     |     +--rw sequence-number?          uint32
|  |     |  |     |     +--rw acknowledgement-number?   uint32
|  |     |  |     |     +--rw data-offset?              uint8
|  |     |  |     |     +--rw reserved?                 uint8
|  |     |  |     |     +--rw flags?                    bits
|  |     |  |     |     +--rw window-size?              uint16
|  |     |  |     |     +--rw urgent-pointer?           uint16
|  |     |  |     |     +--rw options?                  binary
|  |     |  |     |     +--rw (source-port)?
|  |     |  |     |     |  +--:(source-port-range-or-operator)
|  |     |  |     |     |     +--rw source-port-range-or-operator
|  |     |  |     |     |        +--rw (port-range-or-operator)?
|  |     |  |     |     |           +--:(range)
|  |     |  |     |     |           |  +--rw lower-port
|  |     |  |     |     |           |  |       inet:port-number
|  |     |  |     |     |           |  +--rw upper-port
|  |     |  |     |     |           |          inet:port-number
|  |     |  |     |     |           +--:(operator)
|  |     |  |     |     |              +--rw operator? operator
|  |     |  |     |     |              +--rw port
|  |     |  |     |     |                      inet:port-number
|  |     |  |     |     +--rw (destination-port)?
|  |     |  |     |        +--:(destination-port-range-or-operator)
|  |     |  |     |          +--rw destination-port-range-or-operator
|  |     |  |     |             +--rw (port-range-or-operator)?
|  |     |  |     |                +--:(range)
|  |     |  |     |                |  +--rw lower-port
|  |     |  |     |                |  |       inet:port-number
|  |     |  |     |                |  +--rw upper-port
|  |     |  |     |                |          inet:port-number
|  |     |  |     |                +--:(operator)
|  |     |  |     |                   +--rw operator? operator
|  |     |  |     |                   +--rw port
|  |     |  |     |                           inet:port-number
|  |     |  |     +--:(udp)
|  |     |  |        +--rw udp
|  |     |  |           +--rw length?                    uint16
|  |     |  |           +--rw (source-port)?
|  |     |  |           |  +--:(source-port-range-or-operator)
|  |     |  |           |     +--rw source-port-range-or-operator
|  |     |  |           |        +--rw (port-range-or-operator)?
|  |     |  |           |           +--:(range)
|  |     |  |           |           |  +--rw lower-port
|  |     |  |           |           |  |       inet:port-number
|  |     |  |           |           |  +--rw upper-port
|  |     |  |           |           |          inet:port-number
|  |     |  |           |           +--:(operator)
|  |     |  |           |              +--rw operator?  operator
|  |     |  |           |              +--rw port
|  |     |  |           |                      inet:port-number
|  |     |  |           +--rw (destination-port)?
|  |     |  |              +--:(destination-port-range-or-operator)
|  |     |  |                +--rw destination-port-range-or-operator
|  |     |  |                    +--rw (port-range-or-operator)?
|  |     |  |                       +--:(range)
|  |     |  |                       |  +--rw lower-port
|  |     |  |                       |  |       inet:port-number
|  |     |  |                       |  +--rw upper-port
|  |     |  |                       |          inet:port-number
|  |     |  |                       +--:(operator)
|  |     |  |                          +--rw operator?   operator
|  |     |  |                          +--rw port
|  |     |  |                                  inet:port-number
...
]]></artwork>
                  </figure></t>

                <t hangText="Application match:">Relies
]]></sourcecode>
                </figure>
             <dl newline="false" spacing="normal">
              <dt>Application match:</dt>
              <dd>Relies upon
                application-specific classification.</t>
              </list></t> classification (<xref target="qos-sub"/>).</dd>
            </dl>
          </section>
        </section>
      </section>
      <section anchor="mc" title="Multicast"> numbered="true" toc="default">
        <name>Multicast</name>
        <t>Multicast may be enabled for a particular VPN at the VPN node and
        VPN network access levels (see <xref target="all-multicast"></xref>). target="all-multicast" format="default"/>).
        Some data nodes (e.g., max-groups) max-groups (<xref target="mcast-vpn-profile"/>)) can be controlled at various
        levels: VPN service, VPN node level, or VPN network access.</t>

        <t><figure align="center" anchor="all-multicast"
            title="Overall
        <figure anchor="all-multicast">
          <name>Overall Multicast Subtree Structure">
            <artwork align="center"><![CDATA[ Structure</name>
          <sourcecode name="" type="yangtree"><![CDATA[     ...
     +--rw vpn-services
        +--rw vpn-service* [vpn-id]
           ...
           +--rw vpn-instance-profiles
           |  +--rw vpn-instance-profile* [profile-id]
           |     ....
           |     +--rw multicast {vpn-common:multicast}?
           |        ...
           +--rw vpn-nodes
              +--rw vpn-node* [vpn-node-id]
                 ...
                 +--rw active-vpn-instance-profiles
                 |  +--rw vpn-instance-profile* [profile-id]
                 |     ...
                 |     +--rw multicast {vpn-common:multicast}?
                 |        ...
                 +--rw vpn-network-accesses
                    +--rw vpn-network-access* [id]
                       ...
                       +--rw service
                          ...
                          +--rw multicast {vpn-common:multicast}?
                             ...
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
        <t>Multicast-related data nodes at the VPN instance profile level has have
        the structure that is shown in <xref target="mcast-vpaccess"></xref>. target="mcast-vpn-profile"/>.
        </t>
        <figure align="center" anchor="mcast-vpn-profile"
            title="Multicast anchor="mcast-vpn-profile">
          <name>Multicast Subtree Structure (VPN Instance Profile Level)">
            <artwork align="center"><![CDATA[... Level)</name>
          <sourcecode name="" type="yangtree"><![CDATA[...
+--rw vpn-services
   +--rw vpn-service* [vpn-id]
      ...
      +--rw vpn-instance-profiles
      |  +--rw vpn-instance-profile* [profile-id]
      |     ....
      |     +--rw multicast {vpn-common:multicast}?
      |        +--rw tree-flavor?   identityref
      |        +--rw rp
      |        |  +--rw rp-group-mappings
      |        |  |  +--rw rp-group-mapping* [id]
      |        |  |     +--rw id                  uint16
      |        |  |     +--rw provider-managed
      |        |  |     |  +--rw enabled?                   boolean
      |        |  |     |  +--rw rp-redundancy?             boolean
      |        |  |     |  +--rw optimal-traffic-delivery?  boolean
      |        |  |     |  +--rw anycast
      |        |  |     |     +--rw local-address?    inet:ip-address
      |        |  |     |     +--rw rp-set-address*   inet:ip-address
      |        |  |     +--rw rp-address          inet:ip-address
      |        |  |     +--rw groups
      |        |  |        +--rw group* [id]
      |        |  |           +--rw id                     uint16
      |        |  |           +--rw (group-format)
      |        |  |              +--:(group-prefix)
      |        |  |              |  +--rw group-address?
      |        |  |              |          inet:ip-prefix
      |        |  |              +--:(startend)
      |        |  |                 +--rw group-start?
      |        |  |                 |       inet:ip-address
      |        |  |                 +--rw group-end?
      |        |  |                 |       inet:ip-address
      |        |  +--rw rp-discovery
      |        |     +--rw rp-discovery-type?   identityref
      |        |     +--rw bsr-candidates
      |        |        +--rw bsr-candidate-address*
      |        |        |       inet:ip-address
      |        +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
      |        |  +--rw static-group* [group-addr]
      |        |  |  +--rw group-addr
      |        |  |  |       rt-types:ipv4-multicast-group-address
      |        |  |  +--rw source-addr?
      |        |  |          rt-types:ipv4-multicast-source-address
      |        |  +--rw max-groups?     uint32
      |        |  +--rw max-entries?    uint32
      |        |  +--rw version?        identityref
      |        +--rw mld {vpn-common:mld and vpn-common:ipv6}?
      |        |  +--rw static-group* [group-addr]
      |        |  |  +--rw group-addr
      |        |  |  |       rt-types:ipv6-multicast-group-address
      |        |  |  +--rw source-addr?
      |        |  |          rt-types:ipv6-multicast-source-address
      |        |  +--rw max-groups?     uint32
      |        |  +--rw max-entries?    uint32
      |        |  +--rw version?        identityref
      |        +--rw pim {vpn-common:pim}?
      |           +--rw hello-interval?
      |           |       rt-types:timer-value-seconds16
      |           +--rw dr-priority?      uint32
           ...
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
        <t>The model supports a single type of tree per VPN access
        ('tree-flavor'): Any-Source Multicast (ASM), Source-Specific Multicast
        (SSM), or bidirectional.</t>
        <t>When ASM is used, the model supports the configuration of
        Rendezvous Points (RPs). RP discovery may be 'static', 'bsr-rp', or
        'auto-rp'. When set to 'static', RP to multicast grouping RP-to-multicast-group mappings
        MUST
        <bcp14>MUST</bcp14> be configured as part of the 'rp-group-mappings' container. The
        RP MAY <bcp14>MAY</bcp14> be a provider node or a customer node. When the RP is a
        customer node, the RP address must be configured using the
        'rp-address' leaf.</t>
        <t>The model supports RP redundancy through the 'rp-redundancy' leaf.
        How the redundancy is achieved is out of scope.</t>
        <t>When a particular VPN using ASM requires a more optimal traffic
        delivery that is more optimal (e.g., requested using per the guidance in <xref target="RFC8299"></xref>), target="RFC8299" format="default"/>),
        'optimal-traffic-delivery' can be set. When set to 'true', the
        implementation must use any mechanism to provide a more optimal
        traffic delivery that is more optimal for the customer. For example, anycast is one of the
        mechanisms to enhance RPs for enhancing RP redundancy, providing resilience against failures, and
        to recover
        recovering from failures quickly.</t>

        <t>The
        <t>
 When configuring multicast-related parameters at the VPN node level
 (<xref target="mcast-vpn" format="default"/>), the same structure as the one structure depicted in
 <xref
        target="mcast-vpaccess"></xref> target="mcast-vpaccess" format="default"/> is used when configuring
        multicast-related parameters at the VPN node level. used.  When defined at the VPN node level (<xref target="mcast-vpn"></xref>), level, Internet Group Management Protocol (IGMP) parameters <xref target="RFC1112" format="default"/> <xref target="RFC1112"></xref><xref
        target="RFC2236"></xref><xref target="RFC3376"></xref>, target="RFC2236" format="default"/> <xref target="RFC3376" format="default"/>, Multicast
        Listener Discovery (MLD) parameters <xref target="RFC2710" format="default"/> <xref target="RFC2710"></xref><xref
        target="RFC3810"></xref>, target="RFC3810" format="default"/>, and Protocol Independent Multicast (PIM)
        <xref target="RFC7761"></xref> parameters <xref target="RFC7761" format="default"/> are applicable to all VPN
        network accesses of that VPN node unless corresponding nodes are
        overridden at the VPN network access level.</t>

        <t><figure align="center" anchor="mcast-vpn"
            title="Multicast
        <figure anchor="mcast-vpn">
          <name>Multicast Subtree Structure (VPN Node Level)">
            <artwork align="center"><![CDATA[... Level)</name>
          <sourcecode name="" type="yangtree"><![CDATA[...
+--rw vpn-nodes
   +--rw vpn-node* [vpn-node-id]
      ...
      +--rw active-vpn-instance-profiles
      |  +--rw vpn-instance-profile* [profile-id]
      |     ...
      |     +--rw multicast {vpn-common:multicast}?
      |        +--rw tree-flavor*   identityref
      |        +--rw rp
      |        |  ...
      |        +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
      |        |  ...
      |        +--rw mld {vpn-common:mld and vpn-common:ipv6}?
      |        |  ...
      |        +--rw pim {vpn-common:pim}?
      |           ...
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
        <t>Multicast-related data nodes at the VPN network access level are
        shown in <xref target="mcast-vpaccess"></xref>. target="mcast-vpaccess" format="default"/>. The values configured
        at the VPN network access level override the values configured for the
        corresponding data nodes in at other levels.<figure align="center"
            anchor="mcast-vpaccess"
            title="Multicast levels.</t>
        <figure anchor="mcast-vpaccess">
          <name>Multicast Subtree Structure (VPN Network Access Level)">
            <artwork align="center"><![CDATA[... Level)</name>
          <sourcecode name="" type="yangtree"><![CDATA[...
+--rw vpn-network-accesses
   +--rw vpn-network-access* [id]
      ...
      +--rw service
         ...
         +--rw multicast {vpn-common:multicast}?
            +--rw access-type?      enumeration
            +--rw address-family?   identityref
            +--rw protocol-type?    enumeration
            +--rw remote-source?    boolean
            +--rw igmp  {vpn-common:igmp}?
            |  +--rw static-group* [group-addr]
            |  |  +--rw group-addr
            |  |          rt-types:ipv4-multicast-group-address
            |  |  +--rw source-addr?
            |  |          rt-types:ipv4-multicast-source-address
            |  +--rw max-groups?          uint32
            |  +--rw max-entries?         uint32
            |  +--rw max-group-sources?   uint32
            |  +--rw version?             identityref
            |  +--rw status
            |     +--rw admin-status
            |     |  +--rw status?         identityref
            |     |  +--rw last-change?   yang:date-and-time
            |     +--ro oper-status
            |        +--ro status?         identityref
            |        +--ro last-change?   yang:date-and-time
            +--rw mld {vpn-common:mld}?
            |  +--rw static-group* [group-addr]
            |  |  +--rw group-addr
            |  |          rt-types:ipv6-multicast-group-address
            |  |  +--rw source-addr?
            |  |          rt-types:ipv6-multicast-source-address
            |  +--rw max-groups?          uint32
            |  +--rw max-entries?         uint32
            |  +--rw max-group-sources?   uint32
            |  +--rw version?             identityref
            |  +--rw status
            |     +--rw admin-status
            |     |  +--rw status?         identityref
            |     |  +--rw last-change?   yang:date-and-time
            |     +--ro oper-status
            |        +--ro status?         identityref
            |        +--ro last-change?   yang:date-and-time
            +--rw pim {vpn-common:pim}?
               +--rw hello-interval?   rt-types:timer-value-seconds16
               +--rw dr-priority?      uint32
               +--rw status
                  +--rw admin-status
                  |  +--rw status?         identityref
                  |  +--rw last-change?   yang:date-and-time
                  +--ro oper-status
                     +--ro status?         identityref
                     +--ro last-change?   yang:date-and-time
]]></artwork>
          </figure></t>
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="YANG_module" title="L3NM numbered="true" toc="default">
      <name>L3NM YANG Module"> Module</name>
      <t>This module uses types defined in <xref target="RFC6991"></xref> target="RFC6991" format="default"/>,
      <xref target="RFC8343" format="default"/>, and <xref target="RFC8343"></xref>. target="RFC9181"/>. It also uses groupings defined in <xref
      target="RFC8519"></xref>, target="RFC8519" format="default"/>, <xref target="RFC8177"></xref>, target="RFC8177" format="default"/>, and <xref
      target="RFC8294"></xref>.</t>

      <figure align="center">
        <artwork align="center"><![CDATA[<CODE BEGINS>  file "ietf-l3vpn-ntw@2021-09-28.yang" target="RFC8294" format="default"/>.</t>
      <sourcecode name="ietf-l3vpn-ntw@2022-01-19.yang" type="yang" markers="true"><![CDATA[
module ietf-l3vpn-ntw {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw";
  prefix l3nm;

  import ietf-vpn-common {
    prefix vpn-common;
    reference
      "RFC UUUU: 9181: A Layer 2/3 VPN Common YANG Model"; Data Model for Layer 2 and Layer 3
                 VPNs";
  }
  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types, Section 4";
  }
  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991: Common YANG Data Types, Section 3";
  }
  import ietf-key-chain {
    prefix key-chain;
    reference
      "RFC 8177: YANG Data Model for Key Chain."; Chains";
  }
  import ietf-routing-types {
    prefix rt-types;
    reference
      "RFC 8294: Common YANG Data Types for the Routing Area";
  }
  import ietf-interfaces {
    prefix if;
    reference
      "RFC 8343: A YANG Data Model for Interface Management";
  }

  organization
    "IETF OPSAWG (Operations and Management Area Working Group)";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>

     Author:   Samier Barguil
               <mailto:samier.barguilgiraldo.ext@telefonica.com>
     Editor:   Oscar Gonzalez de Dios
               <mailto:oscar.gonzalezdedios@telefonica.com>
     Editor:   Mohamed Boucadair
               <mailto:mohamed.boucadair@orange.com>
     Author:   Luis Angel Munoz
               <mailto:luis-angel.munoz@vodafone.com>
     Author:   Alejandro Aguado
               <mailto:alejandro.aguado_martin@nokia.com>";
  description
    "This YANG module defines a generic network-oriented model
     for the configuration of Layer 3 Virtual Private Networks.

     Copyright (c) 2021 2022 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified Revised BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; 9182; see the
     RFC itself for full legal notices.";

  revision 2021-09-28 2022-01-19 {
    description
      "Initial revision.";
    reference
      "RFC XXXX: 9182: A YANG Network Data Model for Layer 3 VPN Network YANG Model"; VPNs";
  }

  /* Features */

  feature msdp {
    description
      "This feature indicates that Multicast Source Discovery
       Protocol (MSDP) capabilities are supported by the VPN.";
    reference
      "RFC 3618: Multicast Source Discovery Protocol (MSDP)";
  }

  /* Identities */

  identity address-allocation-type {
    description
      "Base identity for address allocation type in the
       Provider Edge (PE)-Customer to Customer Edge (CE) (PE-CE) link.";
  }

  identity provider-dhcp {
    base address-allocation-type;
    description
      "The Provider's provider's network provides a DHCP service to the
       customer.";
  }

  identity provider-dhcp-relay {
    base address-allocation-type;
    description
      "The Provider's provider's network provides a DHCP relay service to the
       customer.";
  }

  identity provider-dhcp-slaac {
    if-feature "vpn-common:ipv6";
    base address-allocation-type;
    description
      "The Provider's provider's network provides a DHCP service to the
       customer as well as IPv6 Stateless Address
       Autoconfiguration (SLAAC).";
    reference
      "RFC 4862: IPv6 Stateless Address Autoconfiguration";
  }

  identity static-address {
    base address-allocation-type;
    description
      "The Provider's provider's network provides static IP addressing to the
       customer.";
  }

  identity slaac {
    if-feature "vpn-common:ipv6";
    base address-allocation-type;
    description
      "The Provider's provider's network uses IPv6 SLAAC to provide
       addressing to the customer.";
    reference
      "RFC 4862: IPv6 Stateless Address Autoconfiguration";
  }

  identity local-defined-next-hop {
    description
      "Base identity of local defined next-hops."; next hops.";
  }

  identity discard {
    base local-defined-next-hop;
    description
      "Indicates an action to discard traffic for the
       corresponding destination.
       For example, this can be used to blackhole black-hole traffic.";
  }

  identity local-link {
    base local-defined-next-hop;
    description
      "Treat traffic towards addresses within the specified
       next-hop prefix as though they are connected to a local
       link.";
  }

  identity l2-tunnel-type {
    description
      "Base identity for layer-2 Layer 2 tunnel selection under the VPN
       network access.";
  }

  identity pseudowire {
    base l2-tunnel-type;
    description
      "Pseudowire tunnel termination in the VPN network access.";
  }

  identity vpls {
    base l2-tunnel-type;
    description
      "Virtual Private LAN Service (VPLS) tunnel termination in
       the VPN network access.";
  }

  identity vxlan {
    base l2-tunnel-type;
    description
      "Virtual eXtensible Local Area Network (VXLAN) tunnel
       termination in the VPN network access.";
  }

  /* Typedefs */

  typedef predefined-next-hop {
    type identityref {
      base local-defined-next-hop;
    }
    description
      "Pre-defined
      "Predefined next-hop designation for locally generated
       routes.";
  }

  typedef area-address {
    type string {
      pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
    }
    description
      "This type defines the area address format.";
  }

  /* Groupings */

  grouping vpn-instance-profile {
    description
      "Grouping for data nodes that may be factorized
       among many levels of the model.  The grouping can
       be used to define generic profiles at the VPN service
       level and then referenced at the VPN node and VPN
       network access levels.";
    leaf local-as {
      if-feature "vpn-common:rtg-bgp";
      type inet:as-number;
      description
        "Provider's Autonomous System (AS) number.  Used if the
         customer requests BGP routing.";
    }
    uses vpn-common:route-distinguisher;
    list address-family {
      key "address-family";
      description
        "Set of per-address family parameters."; parameters per address family.";
      leaf address-family {
        type identityref {
          base vpn-common:address-family;
        }
        description
          "Indicates the address family (IPv4 and/or IPv6).";
      }
      container vpn-targets {
        description
          "Set of route targets to match for import and export
           routes to/from VRF.";
        uses vpn-common:vpn-route-targets;
      }
      list maximum-routes {
        key "protocol";
        description
          "Defines the maximum number of routes for the VRF.";
        leaf protocol {
          type identityref {
            base vpn-common:routing-protocol-type;
          }
          description
            "Indicates the routing protocol. 'any'  A value of 'any'
             can be used to identify a limit that will apply for
             each active routing protocol.";
        }
        leaf maximum-routes {
          type uint32;
          description
            "Indicates the maximum number of prefixes that the VRF can
             accept for this address family and protocol.";
        }
      }
    }
    container multicast {
      if-feature "vpn-common:multicast";
      description
        "Global multicast parameters.";
      leaf tree-flavor {
        type identityref {
          base vpn-common:multicast-tree-type;
        }
        description
          "Type of the multicast tree to be used.";
      }
      container rp {
        description
          "Rendezvous Point (RP) parameters.";
        container rp-group-mappings {
          description
            "RP-to-group mappings mapping parameters.";
          list rp-group-mapping {
            key "id";
            description
              "List of RP-to-group mappings.";
            leaf id {
              type uint16;
              description
                "Unique identifier for the mapping.";
            }
            container provider-managed {
              description
                "Parameters for a provider-managed RP.";
              leaf enabled {
                type boolean;
                default "false";
                description
                  "Set to true 'true' if the Rendezvous Point (RP) RP must be a
                   provider-managed node.  Set to
                   false 'false' if it is
                   a customer-managed node.";
              }
              leaf rp-redundancy {
                type boolean;
                default "false";
                description
                  "If set to true, 'true', it indicates that a
                   redundancy mechanism for the RP is required.";
              }
              leaf optimal-traffic-delivery {
                type boolean;
                default "false";
                description
                  "If set to true, 'true', the service provider (SP)
                   must ensure that the traffic uses an optimal
                   path.  An SP may use Anycast RP or
                   RP-tree-to-SPT ('SPT' is 'shortest path tree')
                   switchover architectures.";
              }
              container anycast {
                when "../rp-redundancy = 'true' and
                      ../optimal-traffic-delivery = 'true'" {
                  description
                    "Only applicable if both RP redundancy and
                     delivery through an optimal path are
                     activated.";
                }
                description
                  "PIM Anycast-RP parameters.";
                leaf local-address {
                  type inet:ip-address;
                  description
                    "IP local address for the PIM RP. Usually, it  Usually
                     corresponds to the Router ID or the
                     primary address.";
                }
                leaf-list rp-set-address {
                  type inet:ip-address;
                  description
                    "Specifies the IP address of other RP routers
                     that share the same RP IP address.";
                }
              }
            }
            leaf rp-address {
              when "../provider-managed/enabled = 'false'" {
                description
                  "Relevant when the RP is not
                   provider-managed."; managed by the
                   provider.";
              }
              type inet:ip-address;
              mandatory true;
              description
                "Defines the address of the RP.
                 Used if the RP is customer-managed."; managed by the customer.";
            }
            container groups {
              description
                "Multicast groups associated with the RP.";
              list group {
                key "id";
                description
                  "List of multicast groups.";
                leaf id {
                  type uint16;
                  description
                    "Identifier for the group.";
                }
                choice group-format {
                  mandatory true;
                  description
                    "Choice for multicast group format.";
                  case group-prefix {
                    leaf group-address {
                      type inet:ip-prefix;
                      description
                        "A single multicast group prefix.";
                    }
                  }
                  case startend {
                    leaf group-start {
                      type inet:ip-address;
                      description
                        "The first multicast group address in
                         the multicast group address range.";
                    }
                    leaf group-end {
                      type inet:ip-address;
                      description
                        "The last multicast group address in
                         the multicast group address range.";
                    }
                  }
                }
              }
            }
          }
        }
        container rp-discovery {
          description
            "RP discovery parameters.";
          leaf rp-discovery-type {
            type identityref {
              base vpn-common:multicast-rp-discovery-type;
            }
            default "vpn-common:static-rp";
            description
              "Type of RP discovery used.";
          }
          container bsr-candidates {
            when "derived-from-or-self(../rp-discovery-type, "
               + "'vpn-common:bsr-rp')" {
              description
                "Only applicable if the discovery type
                 is BSR-RP."; 'bsr-rp'.";
            }
            description
              "Container for the customer Bootstrap Router (BSR)
               candidate's addresses.";
            leaf-list bsr-candidate-address {
              type inet:ip-address;
              description
                "Specifies the address of the candidate BSR.";
            }
          }
        }
      }
      container igmp {
        if-feature "vpn-common:igmp and vpn-common:ipv4";
        description
          "Includes IGMP-related parameters.";
        list static-group {
          key "group-addr";
          description
            "Multicast static source/group associated to with the
             IGMP session.";
          leaf group-addr {
            type rt-types:ipv4-multicast-group-address;
            description
              "Multicast group IPv4 address.";
          }
          leaf source-addr {
            type rt-types:ipv4-multicast-source-address;
            description
              "Multicast source IPv4 address.";
          }
        }
        leaf max-groups {
          type uint32;
          description
            "Indicates the maximum number of groups.";
        }
        leaf max-entries {
          type uint32;
          description
            "Indicates the maximum number of IGMP entries.";
        }
        leaf version {
          type identityref {
            base vpn-common:igmp-version;
          }
          default "vpn-common:igmpv2";
          description
            "Indicates the IGMP version.";
          reference
            "RFC 1112: Host Extensions for IP Multicasting
             RFC 2236: Internet Group Management Protocol,
                       Version 2
             RFC 3376: Internet Group Management Protocol,
                       Version 3";
        }
      }
      container mld {
        if-feature "vpn-common:mld and vpn-common:ipv6";
        description
          "Includes MLD-related parameters.";
        list static-group {
          key "group-addr";
          description
            "Multicast static source/group associated with the
             MLD session.";
          leaf group-addr {
            type rt-types:ipv6-multicast-group-address;
            description
              "Multicast group IPv6 address.";
          }
          leaf source-addr {
            type rt-types:ipv6-multicast-source-address;
            description
              "Multicast source IPv6 address.";
          }
        }
        leaf max-groups {
          type uint32;
          description
            "Indicates the maximum number of groups.";
        }
        leaf max-entries {
          type uint32;
          description
            "Indicates the maximum number of MLD entries.";
        }
        leaf version {
          type identityref {
            base vpn-common:mld-version;
          }
          default "vpn-common:mldv2";
          description
            "Indicates the MLD protocol version.";
          reference
            "RFC 2710: Multicast Listener Discovery (MLD) for IPv6
             RFC 3810: Multicast Listener Discovery Version 2
                       (MLDv2) for IPv6";
        }
      }
      container pim {
        if-feature "vpn-common:pim";
        description
          "Only applies when the protocol type is PIM."; 'pim'.";
        leaf hello-interval {
          type rt-types:timer-value-seconds16;
          default "30";
          description
            "PIM hello-messages interval.
            "Interval between PIM Hello messages.  If set to
             'infinity' or 'not-set', no periodic Hello messages
             are sent.";
          reference
            "RFC 7761: Protocol Independent Multicast - Sparse
                       Mode (PIM-SM): Protocol Specification
                       (Revised), Section 4.11"; 4.11
             RFC 8294: Common YANG Data Types for the Routing
                       Area";
        }
        leaf dr-priority {
          type uint32;
          default "1";
          description
            "Indicates the preference in associated with the
             Designated Router (DR) election process.  A larger
             value has a higher priority over a smaller value.";
          reference
            "RFC 7761: Protocol Independent Multicast - Sparse
                       Mode (PIM-SM): Protocol Specification
                       (Revised), Section 4.3.2";
        }
      }
    }
  }

  /* Main Blocks */
  /* Main l3vpn-ntw */

  container l3vpn-ntw {
    description
      "Main container for L3VPN services management."; management of Layer 3 Virtual Private
       Network (L3VPN) services.";
    container vpn-profiles {
      description
        "Contains a set of valid VPN profiles to reference
         in the VPN service.";
      uses vpn-common:vpn-profile-cfg;
    }
    container vpn-services {
      description
        "Container for the VPN services.";
      list vpn-service {
        key "vpn-id";
        description
          "List of VPN services.";
        uses vpn-common:vpn-description;
        leaf parent-service-id {
          type vpn-common:vpn-id;
          description
            "Pointer to the parent service, if any.
             A parent service can be an L3SM, a slice request,
             a VPN+ service, etc.";
        }
        leaf vpn-type {
          type identityref {
            base vpn-common:service-type;
          }
          description
            "Indicates the service type.";
        }
        leaf vpn-service-topology {
          type identityref {
            base vpn-common:vpn-topology;
          }
          default "vpn-common:any-to-any";
          description
            "VPN service topology.";
        }
        uses vpn-common:service-status;
        container vpn-instance-profiles {
          description
            "Container for a list of VPN instance profiles.";
          list vpn-instance-profile {
            key "profile-id";
            description
              "List of VPN instance profiles.";
            leaf profile-id {
              type string;
              description
                "VPN instance profile identifier.";
            }
            leaf role {
              type identityref {
                base vpn-common:role;
              }
              default "vpn-common:any-to-any-role";
              description
                "Role of the VPN node in the VPN.";
            }
            uses vpn-instance-profile;
          }
        }
        container underlay-transport {
          description
            "Container for the underlay transport.";
          uses vpn-common:underlay-transport;
        }
        container external-connectivity {
          if-feature "vpn-common:external-connectivity";
          description
            "Container for external connectivity.";
          choice profile {
            description
              "Choice for the external connectivity profile.";
            case profile {
              leaf profile-name {
                type leafref {
                  path "/l3vpn-ntw/vpn-profiles"
                     + "/valid-provider-identifiers"
                     + "/external-connectivity-identifier/id";
                }
                description
                  "Name of the service provider's profile to be
                   applied at the VPN service level.";
              }
            }
          }
        }
        container vpn-nodes {
          description
            "Container for VPN nodes.";
          list vpn-node {
            key "vpn-node-id";
            description
              "Includes a list of VPN nodes.";
            leaf vpn-node-id {
              type vpn-common:vpn-id;
              description
                "An identifier of the VPN node.";
            }
            leaf description {
              type string;
              description
                "Textual description of the VPN node.";
            }
            leaf ne-id {
              type string;
              description
                "Unique identifier of the network element where
                 the VPN node is deployed.";
            }
            leaf local-as {
              if-feature "vpn-common:rtg-bgp";
              type inet:as-number;
              description
                "Provider's AS number in case number.  Used if the customer
                 requests BGP routing.";
            }
            leaf router-id {
              type rt-types:router-id;
              description
                "A 32-bit number in the dotted-quad format that is
                 used to uniquely identify a node within an autonomous
                 system. AS.
                 This identifier is used for both IPv4 and IPv6.";
            }
            container active-vpn-instance-profiles {
              description
                "Container for active VPN instance profiles.";
              list vpn-instance-profile {
                key "profile-id";
                description
                  "Includes a list of active VPN instance
                   profiles.";
                leaf profile-id {
                  type leafref {
                    path "/l3vpn-ntw/vpn-services/vpn-service"
                       + "/vpn-instance-profiles/vpn-instance-profile" "/vpn-instance-profiles"
                       + "/profile-id"; "/vpn-instance-profile/profile-id";
                  }
                  description
                    "Node's active VPN instance profile.";
                }
                list router-id {
                  key "address-family";
                  description
                    "Router-id
                    "Router ID per address family.";
                  leaf address-family {
                    type identityref {
                      base vpn-common:address-family;
                    }
                    description
                      "Indicates the address family for which the
                       Router-ID
                       Router ID applies.";
                  }
                  leaf router-id {
                    type inet:ip-address;
                    description
                      "The router-id 'router-id' information can be an IPv4
                       or IPv6 address.  This can be used,
                       for example, to configure an IPv6 address
                       as a router-id Router ID when such a capability is
                       supported by underlay routers.  In such a
                       case, the configured value overrides the
                       generic one value defined at the VPN node
                       level.";
                  }
                }
                uses vpn-instance-profile;
              }
            }
            container msdp {
              if-feature "msdp";
              description
                "Includes MSDP-related parameters.";
              leaf peer {
                type inet:ipv4-address;
                description
                  "Indicates the IPv4 address of the MSDP peer.";
              }
              leaf local-address {
                type inet:ipv4-address;
                description
                  "Indicates the IPv4 address of the local end.
                   This local address must be configured on
                   the node.";
              }
              uses vpn-common:service-status;
            }
            uses vpn-common:vpn-components-group;
            uses vpn-common:service-status;
            container vpn-network-accesses {
              description
                "List of network accesses.";
              list vpn-network-access {
                key "id";
                description
                  "List of network accesses.";
                leaf id {
                  type vpn-common:vpn-id;
                  description
                    "Identifier for the network access.";
                }
                leaf interface-id {
                  type string;
                  description
                    "Identifier for the physical or logical
                     interface.
                     The identification of the sub-interface
                     is provided at the connection level and/or
                     the IP connection levels."; level.";
                }
                leaf description {
                  type string;
                  description
                    "Textual description of the network access.";
                }
                leaf vpn-network-access-type {
                  type identityref {
                    base vpn-common:site-network-access-type;
                  }
                  default "vpn-common:point-to-point";
                  description
                    "Describes the type of connection, e.g.,
                     point-to-point.";
                     point to point.";
                }
                leaf vpn-instance-profile {
                  type leafref {
                    path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes" "/l3vpn-ntw/vpn-services/vpn-service"
                       + "/vpn-node/active-vpn-instance-profiles" "/vpn-nodes/vpn-node"
                       + "/active-vpn-instance-profiles"
                       + "/vpn-instance-profile/profile-id";
                  }
                  description
                    "An identifier of an active VPN instance
                     profile.";
                }
                uses vpn-common:service-status;
                container connection {
                  description
                    "Defines layer Layer 2 protocols and parameters that
                     are required to enable connectivity between
                     the PE and the CE.";
                  container encapsulation {
                    description
                      "Container for layer Layer 2 encapsulation.";
                    leaf type {
                      type identityref {
                        base vpn-common:encapsulation-type;
                      }
                      default "vpn-common:priority-tagged";
                      description
                        "Encapsulation type.  By default, the type
                         of the tagged interface is
                         'priority-tagged'.";
                    }
                    container dot1q {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:dot1q')" {
                        description
                          "Only applies when the type of the
                           tagged interface is 'dot1q'.";
                      }
                      description
                        "Tagged interface.";
                      leaf tag-type {
                        type identityref {
                          base vpn-common:tag-type;
                        }
                        default "vpn-common:c-vlan";
                        description
                          "Tag type.  By default, the tag type is
                           'c-vlan'.";
                      }
                      leaf cvlan-id {
                        type uint16 {
                          range "1..4094";
                        }
                        description
                          "VLAN identifier.";
                      }
                    }
                    container priority-tagged {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:priority-tagged')" {
                        description
                          "Only applies when the type of
                           the tagged interface is
                           'priority-tagged'.";
                      }
                      description
                        "Priority tagged.";
                      leaf tag-type {
                        type identityref {
                          base vpn-common:tag-type;
                        }
                        default "vpn-common:c-vlan";
                        description
                          "Tag type.  By default, the tag type is
                           'c-vlan'.";
                      }
                    }
                    container qinq {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:qinq')" {
                        description
                          "Only applies when the type of the
                           tagged interface is QinQ."; 'qinq'.";
                      }
                      description
                        "Includes QinQ parameters.";
                      leaf tag-type {
                        type identityref {
                          base vpn-common:tag-type;
                        }
                        default "vpn-common:s-c-vlan";
                        description
                          "Tag type. By default, the tag type is
                           'c-s-vlan'."; type.";
                      }
                      leaf svlan-id {
                        type uint16;
                        mandatory true;
                        description
                          "S-VLAN
                          "Service VLAN (S-VLAN) identifier.";
                      }
                      leaf cvlan-id {
                        type uint16;
                        mandatory true;
                        description
                          "C-VLAN
                          "Customer VLAN (C-VLAN) identifier.";
                      }
                    }
                  }
                  choice l2-service {
                    description
                      "The layer Layer 2 connectivity service can be
                       provided by indicating a pointer to an
                       L2VPN or by specifying a layer Layer 2 tunnel
                       service.";
                    container l2-tunnel-service {
                      description
                        "Defines a layer Layer 2 tunnel termination.
                         It is only applicable when a tunnel is
                         required.  The supported values are:
                         pseudowire, VPLS, are
                         'pseudowire', 'vpls', and VXLAN. 'vxlan'.  Other
                         values may be defined, if needed.";
                      leaf type {
                        type identityref {
                          base l2-tunnel-type;
                        }
                        description
                          "Selects the tunnel termiantion termination option
                           for each vpn-network-access."; VPN network access.";
                      }
                      container pseudowire {
                        when "derived-from-or-self(../type, "
                           + "'pseudowire')" {
                          description
                            "Only applies when the type of the layer Layer 2 service
                             type is pseudowire ."; 'pseudowire'.";
                        }
                        description
                          "Includes pseudowire termination
                           parameters.";
                        leaf vcid {
                          type uint32;
                          description
                            "Indicates a PW pseudowire (PW) or VC
                             virtual circuit (VC) identifier.";
                        }
                        leaf far-end {
                          type union {
                            type uint32;
                            type inet:ip-address;
                          }
                          description
                            "Neighbor reference.";
                          reference
                            "RFC 8077: Pseudowire Setup and
                                       Maintenance Using the Label
                                       Distribution Protocol
                                       (LDP), Section 6.1";
                        }
                      }
                      container vpls {
                        when "derived-from-or-self(../type, "
                           + "'vpls')" {
                          description
                            "Only applies when the type of the layer Layer 2 service
                             type is VPLS."; 'vpls'.";
                        }
                        description
                          "VPLS termination parameters.";
                        leaf vcid {
                          type uint32;
                          description
                            "VC Identifier."; identifier.";
                        }
                        leaf-list far-end {
                          type union {
                            type uint32;
                            type inet:ip-address;
                          }
                          description
                            "Neighbor reference.";
                        }
                      }
                      container vxlan {
                        when "derived-from-or-self(../type, "
                           + "'vxlan')" {
                          description
                            "Only applies when the type of the layer Layer 2 service
                             type is VXLAN."; 'vxlan'.";
                        }
                        description
                          "VXLAN termination parameters.";
                        leaf vni-id {
                          type uint32;
                          mandatory true;
                          description
                            "VXLAN Network Identifier (VNI).";
                        }
                        leaf peer-mode {
                          type identityref {
                            base vpn-common:vxlan-peer-mode;
                          }
                          default "vpn-common:static-mode";
                          description
                            "Specifies the VXLAN access mode.  By
                             default, the peer mode is set to
                             'static-mode'.";
                        }
                        leaf-list peer-ip-address {
                          type inet:ip-address;
                          description
                            "List of a peer's IP addresses.";
                        }
                      }
                    }
                    case l2vpn {
                      leaf l2vpn-id {
                        type vpn-common:vpn-id;
                        description
                          "Indicates the L2VPN service associated
                           with an Integrated Routing and Bridging
                           (IRB) interface.";
                      }
                    }
                  }
                  leaf l2-termination-point {
                    type string;
                    description
                      "Specifies a reference to a local layer Layer 2
                       termination point point, such as a layer Layer 2
                       sub-interface.";
                  }
                  leaf local-bridge-reference {
                    type string;
                    description
                      "Specifies a local bridge reference to
                       accommodate, for example, implementations
                       that require internal bridging.
                       A reference may be a local bridge domain.";
                  }
                  leaf bearer-reference {
                    if-feature "vpn-common:bearer-reference";
                    type string;
                    description
                      "This is an internal reference for the
                       service provider to identify the bearer
                       associated with this VPN.";
                  }
                  container lag-interface {
                    if-feature "vpn-common:lag-interface";
                    description
                      "Container for configuration of LAG Link
                       Aggregation Group (LAG) interface attributes
                       configuration.";
                       attributes.";
                    leaf lag-interface-id {
                      type string;
                      description
                        "LAG interface identifier.";
                    }
                    container member-link-list {
                      description
                        "Container of Member for the member link list.";
                      list member-link {
                        key "name";
                        description
                          "Member link.";
                        leaf name {
                          type string;
                          description
                            "Member link name.";
                        }
                      }
                    }
                  }
                }
                container ip-connection {
                  description
                    "Defines IP connection parameters.";
                  leaf l3-termination-point {
                    type string;
                    description
                      "Specifies a reference to a local layer Layer 3
                       termination point point, such as a bridge domain
                       interface.";
                  }
                  container ipv4 {
                    if-feature "vpn-common:ipv4";
                    description
                      "IPv4-specific parameters.";
                    leaf local-address {
                      type inet:ipv4-address;
                      description
                        "The IP address used at the provider's
                         interface.";
                    }
                    leaf prefix-length {
                      type uint8 {
                        range "0..32";
                      }
                      description
                        "Subnet prefix length expressed in bits.
                         It is applied to both local and customer
                         addresses.";
                    }
                    leaf address-allocation-type {
                      type identityref {
                        base address-allocation-type;
                      }
                      must "not(derived-from-or-self(current(), "
                         + "'slaac') or derived-from-or-self(current()," "
                         + "derived-from-or-self(current(), " 'provider-dhcp-slaac'))"
                         + "'provider-dhcp-slaac'))" {
                        error-message "SLAAC is only applicable to "
                                    + "to IPv6.";
                      }
                      description
                        "Defines how addresses are allocated to
                         the peer site.

                         If there is no value for the address
                         allocation type, then IPv4 addressing
                         is not enabled.";
                    }
                    choice allocation-type {
                      description
                        "Choice of the IPv4 address allocation.";
                      case provider-dhcp {
                        description
                          "DHCP allocated addresses
                          "Parameters related
                           parameters. to DHCP-allocated
                           addresses.  IP addresses are allocated
                           by DHCP that DHCP, which is operated provided by the provider";
                           operator.";
                        leaf dhcp-service-type {
                          type enumeration {
                            enum server {
                              description
                                "Local DHCP server.";
                            }
                            enum relay {
                              description
                                "Local DHCP relay.  DHCP requests
                                 are relayed to a provider's
                                 server.";
                            }
                          }
                          description
                            "Indicates the type of DHCP service to
                             be enabled on this access.";
                        }
                        choice service-type {
                          description
                            "Choice based on the DHCP service
                             type.";
                          case relay {
                            description
                              "Container for a list of the
                               provider's DHCP servers (i.e., dhcp-service-type
                               'dhcp-service-type' is set to relay).";
                               'relay').";
                            leaf-list server-ip-address {
                              type inet:ipv4-address;
                              description
                                "IPv4 addresses of the provider's
                                 DHCP
                                 server to server, for use by the local
                                 DHCP relay.";
                            }
                          }
                          case server {
                            description
                              "A choice about for how addresses are
                               assigned when a local DHCP server
                               is enabled.";
                            choice address-assign {
                              default "number";
                              description
                                "Choice
                                "A choice for how IPv4 addresses
                                 are assigned.";
                              case number {
                                leaf number-of-dynamic-address {
                                  type uint16;
                                  default "1";
                                  description
                                    "Specifies the number of IP
                                     addresses to be assigned to
                                     the customer on this
                                     access.";
                                }
                              }
                              case explicit {
                                container customer-addresses {
                                  description
                                    "Container for customer
                                     addresses to be allocated
                                     using DHCP.";
                                  list address-pool {
                                    key "pool-id";
                                    description
                                      "Describes IP addresses to
                                       be allocated by DHCP.

                                       When only start-address 'start-address'
                                       is present, it represents a
                                       single address.

                                       When both start-address 'start-address'
                                       and
                                       end-address 'end-address' are
                                       specified, it implies a
                                       range inclusive of both
                                       addresses.";
                                    leaf pool-id {
                                      type string;
                                      description
                                        "A pool identifier for the
                                         address range from start-
                                         address
                                         'start-address' to end-address.";
                                         'end-address'.";
                                    }
                                    leaf start-address {
                                      type inet:ipv4-address;
                                      mandatory true;
                                      description
                                        "Indicates the first
                                         address in the pool.";
                                    }
                                    leaf end-address {
                                      type inet:ipv4-address;
                                      description
                                        "Indicates the last
                                         address in the pool.";
                                    }
                                  }
                                }
                              }
                            }
                          }
                        }
                      }
                      case dhcp-relay {
                        description
                          "DHCP
                          "The DHCP relay is provided by the
                           operator.";
                        container customer-dhcp-servers {
                          description
                            "Container for a list of the
                             customer's DHCP servers.";
                          leaf-list server-ip-address {
                            type inet:ipv4-address;
                            description
                              "IPv4 addresses of the customer's
                               DHCP server.";
                          }
                        }
                      }
                      case static-addresses {
                        description
                          "Lists the IPv4 addresses that are
                           used.";
                        leaf primary-address {
                          type leafref {
                            path "../address/address-id";
                          }
                          description
                            "Primary address of the connection.";
                        }
                        list address {
                          key "address-id";
                          description
                            "Lists the IPv4 addresses that are
                             used.";
                          leaf address-id {
                            type string;
                            description
                              "An identifier of the static IPv4
                               address.";
                          }
                          leaf customer-address {
                            type inet:ipv4-address;
                            description
                              "IPv4 address at of the customer
                               side.";
                          }
                        }
                      }
                    }
                  }
                  container ipv6 {
                    if-feature "vpn-common:ipv6";
                    description
                      "IPv6-specific parameters.";
                    leaf local-address {
                      type inet:ipv6-address;
                      description
                        "IPv6 address of the provider side.";
                    }
                    leaf prefix-length {
                      type uint8 {
                        range "0..128";
                      }
                      description
                        "Subnet prefix length expressed in bits.
                         It is applied to both local and customer
                         addresses.";
                    }
                    leaf address-allocation-type {
                      type identityref {
                        base address-allocation-type;
                      }
                      description
                        "Defines how addresses are allocated.
                         If there is no value for the address
                         allocation type, then IPv6 addressing is
                         disabled.";
                    }
                    choice allocation-type {
                      description
                        "A choice based on the IPv6 allocation
                         type.";
                      container provider-dhcp {
                        when "derived-from-or-self(../address-allo"
                           + "cation-type, 'provider-dhcp') or "
                           + "or derived-from-or-self(../address-allo" "derived-from-or-self(../address-allo"
                           + "cation-type, 'provider-dhcp-slaac')" {
                          description
                            "Only applies when addresses are
                             allocated by DHCPv6 as provided by
                             the operator.";
                        }
                        description
                          "DHCPv6 allocated addresses
                          "Parameters related
                           parameters."; to DHCP-allocated
                           addresses.";
                        leaf dhcp-service-type {
                          type enumeration {
                            enum server {
                              description
                                "Local DHCPv6 server.";
                            }
                            enum relay {
                              description
                                "DHCPv6 relay.";
                            }
                          }
                          description
                            "Indicates the type of the DHCPv6
                             service to be enabled on this
                             access.";
                        }
                        choice service-type {
                          description
                            "Choice based on the DHCPv6 service
                             type.";
                          case relay {
                            leaf-list server-ip-address {
                              type inet:ipv6-address;
                              description
                                "IPv6 addresses of the provider's
                                 DHCPv6 server.";
                            }
                          }
                          case server {
                            choice address-assign {
                              default "number";
                              description
                                "Choice about for how IPv6 prefixes are
                                 assigned by the DHCPv6 server.";
                              case number {
                                leaf number-of-dynamic-address {
                                  type uint16;
                                  default "1";
                                  description
                                    "Describes the number of IPv6
                                     prefixes that are allocated
                                     to the customer on this
                                     access.";
                                }
                              }
                              case explicit {
                                container customer-addresses {
                                  description
                                    "Container for customer IPv6
                                     addresses allocated by
                                     DHCPv6.";
                                  list address-pool {
                                    key "pool-id";
                                    description
                                      "Describes IPv6 addresses
                                       allocated by DHCPv6.

                                       When only start-address 'start-address'
                                       is present, it represents a
                                       single address.

                                       When both start-address 'start-address'
                                       and
                                       end-address 'end-address' are
                                       specified, it implies a
                                       range inclusive of both
                                       addresses.";
                                    leaf pool-id {
                                      type string;
                                      description
                                        "Pool
                                        "A pool identifier for the
                                         address range from identified by start-
                                         address and end-address.";
                                         'start-address' to
                                         'end-address'.";
                                    }
                                    leaf start-address {
                                      type inet:ipv6-address;
                                      mandatory true;
                                      description
                                        "Indicates the first
                                         address.";
                                    }
                                    leaf end-address {
                                      type inet:ipv6-address;
                                      description
                                        "Indicates the last
                                         address.";
                                    }
                                  }
                                }
                              }
                            }
                          }
                        }
                      }
                      case dhcp-relay {
                        description
                          "DHCPv6 relay provided by the
                           operator.";
                        container customer-dhcp-servers {
                          description
                            "Container for a list of customer the
                             customer's DHCP servers.";
                          leaf-list server-ip-address {
                            type inet:ipv6-address;
                            description
                              "Contains the IP addresses of the customer
                               customer's DHCPv6 server.";
                          }
                        }
                      }
                      case static-addresses {
                        description
                          "IPv6-specific parameters for static
                           allocation.";
                        leaf primary-address {
                          type leafref {
                            path "../address/address-id";
                          }
                          description
                            "Principal address of the connection";
                             connection.";
                        }
                        list address {
                          key "address-id";
                          description
                            "Describes IPv6 addresses that are
                             used.";
                          leaf address-id {
                            type string;
                            description
                              "An identifier of an IPv6 address.";
                          }
                          leaf customer-address {
                            type inet:ipv6-address;
                            description
                              "An IPv6 address of the customer
                               side.";
                          }
                        }
                      }
                    }
                  }
                }
                container routing-protocols {
                  description
                    "Defines routing protocols.";
                  list routing-protocol {
                    key "id";
                    description
                      "List of routing protocols used on the CE/PE
                       CE-PE link.  This list can be augmented.";
                    leaf id {
                      type string;
                      description
                        "Unique identifier for the routing
                         protocol.";
                    }
                    leaf type {
                      type identityref {
                        base vpn-common:routing-protocol-type;
                      }
                      description
                        "Type of routing protocol.";
                    }
                    list routing-profiles {
                      key "id";
                      description
                        "Routing profiles.";
                      leaf id {
                        type leafref {
                          path "/l3vpn-ntw/vpn-profiles"
                             + "/valid-provider-identifiers"
                             + "/routing-profile-identifier/id";
                        }
                        description
                          "Routing profile to be used.";
                      }
                      leaf type {
                        type identityref {
                          base vpn-common:ie-type;
                        }
                        description
                          "Import, export, or both.";
                      }
                    }
                    container static {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:static-routing')" {
                        description
                          "Only applies when the protocol is static."; a
                           static routing protocol.";
                      }
                      description
                        "Configuration specific to static
                         routing.";
                      container cascaded-lan-prefixes {
                        description
                          "LAN prefixes from the customer.";
                        list ipv4-lan-prefixes {
                          if-feature "vpn-common:ipv4";
                          key "lan next-hop";
                          description
                            "List of LAN prefixes for the site.";
                          leaf lan {
                            type inet:ipv4-prefix;
                            description
                              "LAN prefixes.";
                          }
                          leaf lan-tag {
                            type string;
                            description
                              "Internal tag to be used in VPN
                               policies.";
                          }
                          leaf next-hop {
                            type union {
                              type inet:ip-address;
                              type predefined-next-hop;
                            }
                            description
                              "The next-hop next hop that is to be used
                               for the static route.  This may be
                               specified as an IP address or a
                               pre-defined
                               predefined next-hop type (e.g.,
                               discard
                               'discard' or local-link)."; 'local-link').";
                          }
                          leaf bfd-enable {
                            if-feature "vpn-common:bfd";
                            type boolean;
                            description
                              "Enables BFD."; Bidirectional Forwarding
                               Detection (BFD).";
                          }
                          leaf metric {
                            type uint32;
                            description
                              "Indicates the metric associated
                               with the static route.";
                          }
                          leaf preference {
                            type uint32;
                            description
                              "Indicates the preference of associated
                               with the static
                               routes."; route.";
                          }
                          uses vpn-common:service-status;
                        }
                        list ipv6-lan-prefixes {
                          if-feature "vpn-common:ipv6";
                          key "lan next-hop";
                          description
                            "List of LAN prefixes for the site.";
                          leaf lan {
                            type inet:ipv6-prefix;
                            description
                              "LAN prefixes.";
                          }
                          leaf lan-tag {
                            type string;
                            description
                              "Internal tag to be used in VPN
                               policies.";
                          }
                          leaf next-hop {
                            type union {
                              type inet:ip-address;
                              type predefined-next-hop;
                            }
                            description
                              "The next-hop next hop that is to be used for
                               the static route.  This may be
                               specified as an IP address or a pre-defined
                               predefined next-hop type (e.g., discard
                               'discard' or local-link)."; 'local-link').";
                          }
                          leaf bfd-enable {
                            if-feature "vpn-common:bfd";
                            type boolean;
                            description
                              "Enables BFD.";
                          }
                          leaf metric {
                            type uint32;
                            description
                              "Indicates the metric associated
                               with the static route.";
                          }
                          leaf preference {
                            type uint32;
                            description
                              "Indicates the preference associated
                               with the static route.";
                          }
                          uses vpn-common:service-status;
                        }
                      }
                    }
                    container bgp {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:bgp-routing')" {
                        description
                          "Only applies when the protocol is
                           BGP.";
                      }
                      description
                        "BGP-specific configuration.";
                        "Configuration specific to BGP.";
                      leaf description {
                        type string;
                        description
                          "Includes a description of the BGP
                           session.

                           This description is meant to be used
                           for
                           diagnosis diagnostic purposes.  The semantic
                           of the description is local to an
                           implementation.";
                      }
                      leaf local-as {
                        type inet:as-number;
                        description
                          "Indicates a local AS Number (ASN) (ASN), if a
                           distinct
                           an ASN than distinct from the one ASN configured
                           at the VPN node level is needed.";
                      }
                      leaf peer-as {
                        type inet:as-number;
                        mandatory true;
                        description
                          "Indicates the customer's ASN when
                           the customer requests BGP routing.";
                      }
                      leaf address-family {
                        type identityref {
                          base vpn-common:address-family;
                        }
                        description
                          "This node contains the address families
                           to be activated. Dual-stack  'dual-stack' means
                           that both IPv4 and IPv6 will be
                           activated.";
                      }
                      leaf local-address {
                        type union {
                          type inet:ip-address;
                          type if:interface-ref;
                        }
                        description
                          "Set
                          "Sets the local IP address to use for
                           the BGP transport session.  This may be
                           expressed as either an IP address or a
                           reference to an interface.";
                      }
                      leaf-list neighbor {
                        type inet:ip-address;
                        description
                          "IP address(es) of the BGP neighbor.
                           IPv4 and IPv6 neighbors may be
                           indicated if two sessions will be used
                           for IPv4 and IPv6.";
                      }
                      leaf multihop {
                        type uint8;
                        description
                          "Describes the number of IP hops allowed
                           between a given BGP neighbor and
                           the PE.";
                      }
                      leaf as-override {
                        type boolean;
                        default "false";
                        description
                          "Defines whether ASN override is
                           enabled, i.e., replace replacing the ASN of
                           the customer specified in the AS_Path AS_PATH
                           attribute with the local ASN.";
                      }
                      leaf allow-own-as {
                        type uint8;
                        default "0";
                        description
                          "Specifies
                          "If set, specifies the maximum number of
                           occurrences of the provider's ASN that can occur
                           are permitted within the AS_PATH
                           before it is rejected.";
                      }
                      leaf prepend-global-as {
                        type boolean;
                        default "false";
                        description
                          "In some situations, the ASN that is
                           provided at the VPN node level may be
                           distinct from the one ASN configured at the
                           VPN network access level.  When such
                           ASNs are provided, they are both
                           prepended to the BGP route updates
                           for this access.  To disable that
                           behavior, the prepend-global-as 'prepend-global-as'
                           must be set to 'false'.  In such a
                           case, the ASN that is provided at
                           the VPN node level is not prepended
                           to the BGP route updates for
                           this access.";
                      }
                      leaf send-default-route {
                        type boolean;
                        default "false";
                        description
                          "Defines whether default routes can be
                           advertised to its a peer.  If set, the
                           default routes are advertised to its a
                           peer.";
                      }
                      leaf site-of-origin {
                        when "../address-family = 'vpn-common:ipv4' or "
                           + "'vpn-common:dual-stack'" "or 'vpn-common:dual-stack'" {
                          description
                            "Only applies if IPv4 is activated.";
                        }
                        type rt-types:route-origin;
                        description
                          "The Site of Origin attribute is encoded
                           as a Route Origin Extended Community.
                           It is meant to uniquely identify the
                           set of routes learned from a site via a
                           particular CE/PE CE-PE connection and is used
                           to prevent routing loops.";
                        reference
                          "RFC 4364: BGP/MPLS IP Virtual Private
                                     Networks (VPNs), Section 7";
                      }
                      leaf ipv6-site-of-origin {
                        when "../address-family = 'vpn-common:ipv6' or "
                           + "'vpn-common:dual-stack'" "or 'vpn-common:dual-stack'" {
                          description
                            "Only applies if IPv6 is activated.";
                        }
                        type rt-types:ipv6-route-origin;
                        description
                          "IPv6 Route Origins are
                          "The IPv6 Address Specific
                           BGP Site of Origin attribute is
                           encoded as an IPv6 Route Origin
                           Extended that are Community.  It is meant to
                           uniquely identify the Site set of
                           Origin for routes
                           learned from a site via VRF
                           information.";
                        reference
                          "RFC 5701: IPv6 Address Specific BGP
                                     Extended Community
                                     Attribute";
                      }
                      list redistribute-connected {
                        key "address-family";
                        description
                          "Indicates
                          "Indicates, per address family, the per-AF
                           policy to follow for connected
                           routes.";
                        leaf address-family {
                          type identityref {
                            base vpn-common:address-family;
                          }
                          description
                            "Indicates the address family.";
                        }
                        leaf enable {
                          type boolean;
                          description
                            "Enables to redistribute the redistribution of
                             connected routes.";
                        }
                      }
                      container bgp-max-prefix {
                        description
                          "Controls the behavior when a prefix
                           maximum is reached.";
                        leaf max-prefix {
                          type uint32;
                          default "5000";
                          description
                            "Indicates the maximum number of BGP
                             prefixes allowed in the BGP session.

                             It allows control of how many
                             prefixes can be received from a
                             neighbor.

                             If the limit is exceeded, the action
                             indicated in violate-action 'violate-action' will be
                             followed.";
                          reference
                            "RFC 4271: A Border Gateway Protocol 4
                                       (BGP-4), Section 8.2.2";
                        }
                        leaf warning-threshold {
                          type decimal64 {
                            fraction-digits 5;
                            range "0..100";
                          }
                          units "percent";
                          default "75";
                          description
                            "When this value is reached, a warning
                             notification will be triggered.";
                        }
                        leaf violate-action {
                          type enumeration {
                            enum warning {
                              description
                                "Only a warning message is sent to
                                 the peer when the limit is
                                 exceeded.";
                            }
                            enum discard-extra-paths {
                              description
                                "Discards extra paths when the
                                 limit is exceeded.";
                            }
                            enum restart {
                              description
                                "The BGP session restarts after
                                 a
                                 the indicated time interval.";
                            }
                          }
                          description
                            "BGP
                            "If the BGP neighbor max-prefix violate
                             action."; 'max-prefix'
                             limit is reached, the action
                             indicated in 'violate-action'
                             will be followed.";
                        }
                        leaf restart-timer {
                          type uint32;
                          units "seconds";
                          description
                            "Time interval after which the BGP
                             session will be reestablished.";
                        }
                      }
                      container bgp-timers {
                        description
                          "Includes two BGP timers that can be
                           customized when building a VPN service
                           with BGP used as the CE-PE routing
                           protocol.";
                        leaf keepalive {
                          type uint16 {
                            range "0..21845";
                          }
                          units "seconds";
                          default "30";
                          description
                            "This timer indicates the KEEPALIVE
                             messages' frequency between a PE
                             and a BGP peer.

                             If set to '0', it indicates that
                             KEEPALIVE messages are disabled.

                             It is suggested that the maximum
                             time between KEEPALIVE messages would be
                             one third
                             one-third of the Hold Time
                             interval.";
                          reference
                            "RFC 4271: A Border Gateway Protocol 4
                                       (BGP-4), Section 4.4";
                        }
                        leaf hold-time {
                          type uint16 {
                            range "0 | 3..65535";
                          }
                          units "seconds";
                          default "90";
                          description
                            "It indicates
                            "Indicates the maximum number of
                             seconds that may elapse between the
                             receipt of successive KEEPALIVE
                             and/or UPDATE messages from the peer.

                             The Hold Time must be either zero or
                             at least three seconds.";
                          reference
                            "RFC 4271: A Border Gateway Protocol 4
                                       (BGP-4), Section 4.2";
                        }
                      }
                      container authentication {
                        description
                          "Container for BGP authentication
                           parameters between a PE and a CE.";
                        leaf enable {
                          type boolean;
                          default "false";
                          description
                            "Enables or disables authentication.";
                        }
                        container keying-material {
                          when "../enable = 'true'";
                          description
                            "Container for describing how a BGP
                             routing session is to be secured
                             between a PE and a CE.";
                          choice option {
                            description
                              "Choice of authentication options.";
                            case ao {
                              description
                                "Uses TCP-Authentication the TCP Authentication
                                 Option (TCP-AO).";
                              reference
                                "RFC 5925: The TCP Authentication
                                           Option.";
                                           Option";
                              leaf enable-ao {
                                type boolean;
                                description
                                  "Enables the TCP-AO.";
                              }
                              leaf ao-keychain {
                                type key-chain:key-chain-ref;
                                description
                                  "Reference to the TCP-AO key
                                   chain.";
                                reference
                                  "RFC 8177: YANG Data Model for
                                             Key Chain."; Chains";
                              }
                            }
                            case md5 {
                              description
                                "Uses MD5 to secure the session.";
                              reference
                                "RFC 4364: BGP/MPLS IP Virtual
                                           Private Networks
                                           (VPNs), Section 13.2";
                              leaf md5-keychain {
                                type key-chain:key-chain-ref;
                                description
                                  "Reference to the MD5 key
                                   chain.";
                                reference
                                  "RFC 8177: YANG Data Model for
                                             Key Chain"; Chains";
                              }
                            }
                            case explicit {
                              leaf key-id {
                                type uint32;
                                description
                                  "Key Identifier."; identifier.";
                              }
                              leaf key {
                                type string;
                                description
                                  "BGP authentication key.
                                   This model only supports the
                                   subset of keys that are
                                   representable as ASCII
                                   strings.";
                              }
                              leaf crypto-algorithm {
                                type identityref {
                                  base key-chain:crypto-algorithm;
                                }
                                description
                                  "Indicates the cryptographic
                                   algorithm associated with the
                                   key.";
                              }
                            }
                            case ipsec {
                              description
                                "Specifies a reference to an IKE
                                 Internet Key Exchange Protocol
                                 (IKE) Security Association
                                 (SA).";
                              leaf sa {
                                type string;
                                description
                                  "Indicates the
                                   administrator-assigned name
                                   of the SA.";
                              }
                            }
                          }
                        }
                      }
                      uses vpn-common:service-status;
                    }
                    container ospf {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:ospf-routing')" {
                        description
                          "Only applies when the protocol is
                           OSPF.";
                      }
                      description
                        "OSPF-specific configuration.";
                        "Configuration specific to OSPF.";
                      leaf address-family {
                        type identityref {
                          base vpn-common:address-family;
                        }
                        description
                          "Indicates whether IPv4, IPv6, or
                           both are to be activated.";
                      }
                      leaf area-id {
                        type yang:dotted-quad;
                        mandatory true;
                        description
                          "Area ID.";
                        reference
                          "RFC 4577: OSPF as the Provider/Customer
                                     Edge Protocol for BGP/MPLS IP
                                     Virtual Private Networks
                                     (VPNs), Section 4.2.3
                           RFC 6565: OSPFv3 as a Provider Edge to
                                     Customer Edge (PE-CE) Routing
                                     Protocol, Section 4.2";
                      }
                      leaf metric {
                        type uint16;
                        default "1";
                        description
                          "Metric of the PE-CE link.  It is used
                           in the routing state calculation and
                           path selection.";
                      }
                      container sham-links {
                        if-feature "vpn-common:rtg-ospf-sham-link";
                        description
                          "List of sham links.";
                        reference
                          "RFC 4577: OSPF as the Provider/Customer
                                     Edge Protocol for BGP/MPLS IP
                                     Virtual Private Networks
                                     (VPNs), Section 4.2.7
                           RFC 6565: OSPFv3 as a Provider Edge to
                                     Customer Edge (PE-CE) Routing
                                     Protocol, Section 5";
                        list sham-link {
                          key "target-site";
                          description
                            "Creates a sham link with another
                             site.";
                          leaf target-site {
                            type string;
                            description
                              "Target site for the sham link
                               connection.  The site is referred
                               to by its identifier.";
                          }
                          leaf metric {
                            type uint16;
                            default "1";
                            description
                              "Metric of the sham link.  It is
                               used in the routing state
                               calculation and path selection.
                               The default value is set to 1."; '1'.";
                            reference
                              "RFC 4577: OSPF as the
                                         Provider/Customer Edge
                                         Protocol for BGP/MPLS IP
                                         Virtual Private Networks
                                         (VPNs), Section 4.2.7.3
                               RFC 6565: OSPFv3 as a Provider Edge
                                         to Customer Edge (PE-CE)
                                         Routing Protocol,
                                         Section 5.2";
                          }
                        }
                      }
                      leaf max-lsa {
                        type uint32 {
                          range "1..4294967294";
                        }
                        description
                          "Maximum number of allowed LSAs OSPF."; Link State
                           Advertisements (LSAs) that the OSPF
                           instance will accept.";
                      }
                      container authentication {
                        description
                          "Authentication configuration.";
                        leaf enable {
                          type boolean;
                          default "false";
                          description
                            "Enables or disables authentication.";
                        }
                        container keying-material {
                          when "../enable = 'true'";
                          description
                            "Container for describing how an OSPF
                             session is to be secured between a CE
                             and a PE.";
                          choice option {
                            description
                              "Options for OSPF authentication.";
                            case auth-key-chain {
                              leaf key-chain {
                                type key-chain:key-chain-ref;
                                description
                                  "key-chain name.";
                                  "Name of the key chain.";
                              }
                            }
                            case auth-key-explicit {
                              leaf key-id {
                                type uint32;
                                description
                                  "Key identifier.";
                              }
                              leaf key {
                                type string;
                                description
                                  "OSPF authentication key.
                                   This model only supports the
                                   subset of keys that are
                                   representable as ASCII
                                   strings.";
                              }
                              leaf crypto-algorithm {
                                type identityref {
                                  base key-chain:crypto-algorithm;
                                }
                                description
                                  "Indicates the cryptographic
                                   algorithm associated with the
                                   key.";
                              }
                            }
                            case ipsec {
                              leaf sa {
                                type string;
                                description
                                  "Indicates the
                                   administrator-assigned name
                                   of the SA.";
                                reference
                                  "RFC 4552: Authentication
                                             /Confidentiality Authentication/
                                             Confidentiality for
                                             OSPFv3";
                              }
                            }
                          }
                        }
                      }
                      uses vpn-common:service-status;
                    }
                    container isis {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:isis-routing')" {
                        description
                          "Only applies when the protocol is
                           IS-IS.";
                      }
                      description
                        "IS-IS
                        "Configuration specific configuration."; to IS-IS.";
                      leaf address-family {
                        type identityref {
                          base vpn-common:address-family;
                        }
                        description
                          "Indicates whether IPv4, IPv6, or both
                           are to be activated.";
                      }
                      leaf area-address {
                        type area-address;
                        mandatory true;
                        description
                          "Area address.";
                      }
                      leaf level {
                        type identityref {
                          base vpn-common:isis-level;
                        }
                        description
                          "Can be level-1, level-2, 'level-1', 'level-2', or level-1-2.";
                           'level-1-2'.";
                        reference
                          "RFC 9181: A Common YANG Data Model for
                                     Layer 2 and Layer 3 VPNs";
                      }
                      leaf metric {
                        type uint16;
                        default "1";
                        description
                          "Metric of the PE-CE link.  It is used
                           in the routing state calculation and
                           path selection.";
                      }
                      leaf mode {
                        type enumeration {
                          enum active {
                            description
                              "Interface
                              "The interface sends or receives
                               IS-IS protocol control packets.";
                          }
                          enum passive {
                            description
                              "Suppresses the sending of IS-IS
                               updates through the specified
                               interface.";
                          }
                        }
                        default "active";
                        description
                          "IS-IS interface mode type.";
                      }
                      container authentication {
                        description
                          "Authentication configuration.";
                        leaf enable {
                          type boolean;
                          default "false";
                          description
                            "Enables or disables authentication.";
                        }
                        container keying-material {
                          when "../enable = 'true'";
                          description
                            "Container for describing how an IS-IS
                             session is to be secured between a CE
                             and a PE.";
                          choice option {
                            description
                              "Options for IS-IS authentication.";
                            case auth-key-chain {
                              leaf key-chain {
                                type key-chain:key-chain-ref;
                                description
                                  "key-chain name.";
                                  "Name of the key chain.";
                              }
                            }
                            case auth-key-explicit {
                              leaf key-id {
                                type uint32;
                                description
                                  "Key Identifier."; identifier.";
                              }
                              leaf key {
                                type string;
                                description
                                  "IS-IS authentication key.
                                   This model only supports the
                                   subset of keys that are
                                   representable as ASCII
                                   strings.";
                              }
                              leaf crypto-algorithm {
                                type identityref {
                                  base key-chain:crypto-algorithm;
                                }
                                description
                                  "Indicates the cryptographic
                                   algorithm associated with the
                                   key.";
                              }
                            }
                          }
                        }
                      }
                      uses vpn-common:service-status;
                    }
                    container rip {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:rip-routing')" {
                        description
                          "Only applies when the protocol is RIP.
                           For IPv4, the model assumes that RIP
                           version 2 is used.";
                      }
                      description
                        "Configuration specific to RIP routing.";
                      leaf address-family {
                        type identityref {
                          base vpn-common:address-family;
                        }
                        description
                          "Indicates whether IPv4, IPv6, or both
                           address families are to be activated.";
                      }
                      container timers {
                        description
                          "Indicates the RIP timers.";
                        reference
                          "RFC 2453: RIP Version 2";
                        leaf update-interval {
                          type uint16 {
                            range "1..32767";
                          }
                          units "seconds";
                          default "30";
                          description
                            "Indicates the RIP update time.
                             That is, time, i.e.,
                             the amount of time for which RIP
                             updates are sent.";
                        }
                        leaf invalid-interval {
                          type uint16 {
                            range "1..32767";
                          }
                          units "seconds";
                          default "180";
                          description
                            "Is the
                            "The interval before a route is
                             declared invalid after no updates are
                             received.  This value is at least
                             three times the value for the update-interval
                             'update-interval' argument.";
                        }
                        leaf holddown-interval {
                          type uint16 {
                            range "1..32767";
                          }
                          units "seconds";
                          default "180";
                          description
                            "Specifies the interval before better
                             routes are released.";
                        }
                        leaf flush-interval {
                          type uint16 {
                            range "1..32767";
                          }
                          units "seconds";
                          default "240";
                          description
                            "Indicates the RIP flush timer. That is, timer, i.e.,
                             the amount of time that must elapse
                             before a route is removed from the
                             routing table.";
                        }
                      }
                      leaf default-metric {
                        type uint8 {
                          range "0..16";
                        }
                        default "1";
                        description
                          "Sets the default metric.";
                      }
                      container authentication {
                        description
                          "Authentication configuration.";
                        leaf enable {
                          type boolean;
                          default "false";
                          description
                            "Enables or disables authentication.";
                        }
                        container keying-material {
                          when "../enable = 'true'";
                          description
                            "Container for describing how a RIP
                             session is to be secured between a CE
                             and a PE.";
                          choice option {
                            description
                              "Specifies the authentication
                               scheme.";
                            case auth-key-chain {
                              leaf key-chain {
                                type key-chain:key-chain-ref;
                                description
                                  "key-chain name.";
                                  "Name of the key chain.";
                              }
                            }
                            case auth-key-explicit {
                              leaf key {
                                type string;
                                description
                                  "RIP authentication key.
                                   This model only supports the
                                   subset of keys that are
                                   representable as ASCII
                                   strings.";
                              }
                              leaf crypto-algorithm {
                                type identityref {
                                  base key-chain:crypto-algorithm;
                                }
                                description
                                  "Indicates the cryptographic
                                   algorithm associated with the
                                   key.";
                              }
                            }
                          }
                        }
                      }
                      uses vpn-common:service-status;
                    }
                    container vrrp {
                      when "derived-from-or-self(../type, "
                         + "'vpn-common:vrrp-routing')" {
                        description
                          "Only applies when the protocol is VRRP."; the
                           Virtual Router Redundancy Protocol
                           (VRRP).";
                      }
                      description
                        "Configuration specific to VRRP.";
                      reference
                        "RFC 5798: Virtual Router Redundancy
                                   Protocol (VRRP) Version 3 for
                                   IPv4 and IPv6";
                      leaf address-family {
                        type identityref {
                          base vpn-common:address-family;
                        }
                        description
                          "Indicates whether IPv4, IPv6, or both
                           address families are to be enabled.";
                      }
                      leaf vrrp-group {
                        type uint8 {
                          range "1..255";
                        }
                        description
                          "Includes the VRRP group identifier.";
                      }
                      leaf backup-peer {
                        type inet:ip-address;
                        description
                          "Indicates the IP address of the peer.";
                      }
                      leaf-list virtual-ip-address {
                        type inet:ip-address;
                        description
                          "Virtual IP addresses for a single VRRP
                           group.";
                        reference
                          "RFC 5798: Virtual Router Redundancy
                                     Protocol (VRRP) Version 3 for
                                     IPv4 and IPv6,
                                     Sections 1.2 and 1.3";
                      }
                      leaf priority {
                        type uint8 {
                          range "1..254";
                        }
                        default "100";
                        description
                          "Sets the local priority of the VRRP
                           speaker.";
                      }
                      leaf ping-reply {
                        type boolean;
                        default "false";
                        description
                          "Controls whether the VRRP speaker
                           should
                           answer reply to ping requests.";
                      }
                      uses vpn-common:service-status;
                    }
                  }
                }
                container oam {
                  description
                    "Defines the Operations, Administration,
                     and Maintenance (OAM) mechanisms used.

                     BFD is set as a fault detection mechanism,
                     but other mechanisms can be defined in the
                     future.";
                  container bfd {
                    if-feature "vpn-common:bfd";
                    description
                      "Container for BFD.";
                    leaf session-type {
                      type identityref {
                        base vpn-common:bfd-session-type;
                      }
                      default "vpn-common:classic-bfd";
                      description
                        "Specifies the BFD session type.";
                    }
                    leaf desired-min-tx-interval {
                      type uint32;
                      units "microseconds";
                      default "1000000";
                      description
                        "The minimum interval between transmission
                         transmissions of BFD control packets that Control packets, as
                         desired by the operator
                         desires."; operator.";
                      reference
                        "RFC 5880: Bidirectional Forwarding
                                   Detection (BFD),
                                   Section 6.8.7";
                    }
                    leaf required-min-rx-interval {
                      type uint32;
                      units "microseconds";
                      default "1000000";
                      description
                        "The minimum interval between received BFD
                         control
                         Control packets that the PE should
                         support.";
                      reference
                        "RFC 5880: Bidirectional Forwarding
                                   Detection (BFD),
                                   Section 6.8.7";
                    }
                    leaf local-multiplier {
                      type uint8 {
                        range "1..255";
                      }
                      default "3";
                      description
                        "Specifies the detection multiplier that
                         is transmitted to a BFD peer.

                         The detection interval for the receiving
                         BFD peer is calculated by multiplying the
                         value of the negotiated transmission
                         interval by the received detection
                         multiplier value.";
                      reference
                        "RFC 5880: Bidirectional Forwarding
                                   Detection (BFD),
                                   Section 6.8.7";
                    }
                    leaf holdtime {
                      type uint32;
                      units "milliseconds";
                      description
                        "Expected BFD holdtime.

                         The customer may impose some fixed
                         values for the holdtime period if the
                         provider allows the customer to use of
                         this function.

                         If the provider doesn't allow the
                         customer to use this function,
                         the fixed-value
                         fixed values will not be set.";
                      reference
                        "RFC 5880: Bidirectional Forwarding
                                   Detection (BFD),
                                   Section 6.8.18";
                    }
                    leaf profile {
                      type leafref {
                        path "/l3vpn-ntw/vpn-profiles"
                           + "/valid-provider-identifiers"
                           + "/bfd-profile-identifier/id";
                      }
                      description
                        "Well-known service provider profile name.

                         The provider can propose some profiles
                         to the customer, depending on the
                         service level the customer wants to
                         achieve.";
                    }
                    container authentication {
                      presence "Enables BFD authentication";
                      description
                        "Parameters for BFD authentication.";
                      leaf key-chain {
                        type key-chain:key-chain-ref;
                        description
                          "Name of the key-chain."; key chain.";
                      }
                      leaf meticulous {
                        type boolean;
                        description
                          "Enables meticulous mode.";
                        reference
                          "RFC 5880: Bidirectional Forwarding
                                     Detection (BFD),
                                     Section 6.7";
                      }
                    }
                    uses vpn-common:service-status;
                  }
                }
                container security {
                  description
                    "Site-specific security parameters.";
                  container encryption {
                    if-feature "vpn-common:encryption";
                    description
                      "Container for CE-PE security encryption.";
                    leaf enabled {
                      type boolean;
                      default "false";
                      description
                        "If true, set to 'true', traffic encryption on
                         the connection is required.  Otherwise,
                         it is disabled.";
                    }
                    leaf layer {
                      when "../enabled = 'true'" {
                        description
                          "It is included
                          "Included only when encryption
                           is enabled.";
                      }
                      type enumeration {
                        enum layer2 {
                          description
                            "Encryption occurs at Layer 2.";
                        }
                        enum layer3 {
                          description
                            "Encryption occurs at Layer 3.
                             For example, IPsec may be used when
                             a customer requests Layer 3
                             encryption.";
                        }
                      }
                      description
                        "Indicates the layer on which encryption
                         is applied.";
                    }
                  }
                  container encryption-profile {
                    when "../encryption/enabled = 'true'" {
                      description
                        "Indicates the layer on which encryption
                         is enabled.";
                    }
                    description
                      "Container for the encryption profile.";
                    choice profile {
                      description
                        "Choice for the encryption profile.";
                      case provider-profile {
                        leaf profile-name {
                          type leafref {
                            path "/l3vpn-ntw/vpn-profiles"
                               + "/valid-provider-identifiers"
                               + "/encryption-profile-identifier/id";
                          }
                          description
                            "Name of the service provider's
                             profile to be applied.";
                        }
                      }
                      case customer-profile {
                        leaf customer-key-chain {
                          type key-chain:key-chain-ref;
                          description
                            "Customer-supplied key chain.";
                        }
                      }
                    }
                  }
                }
                container service {
                  description
                    "Service parameters of the attachment.";
                  leaf inbound-bandwidth pe-to-ce-bandwidth {
                    if-feature "vpn-common:inbound-bw";
                    type uint64;
                    units "bps";
                    description
                      "From the customer site's perspective, the
                       service inbound bandwidth of the connection
                       or download bandwidth from the SP to the
                       site.  Note that the L3SM uses 'input-
                       -bandwidth'
                       'input-bandwidth' to refer to the same
                       concept.";
                  }
                  leaf outbound-bandwidth ce-to-pe-bandwidth {
                    if-feature "vpn-common:outbound-bw";
                    type uint64;
                    units "bps";
                    description
                      "From the customer site's perspective,
                       the service outbound bandwidth of the
                       connection or upload bandwidth from
                       the site to the SP.  Note that the L3SM
                       uses 'output-bandwidth' to refer to the
                       same concept.";
                  }
                  leaf mtu {
                    type uint32;
                    units "bytes";
                    description
                      "MTU at the service level.  If the service
                       is IP, it refers to the IP MTU.  If
                       Carriers' Carriers (CsC) is enabled, the
                       requested MTU will refer to the MPLS
                       maximum labeled packet size and not to the
                       IP MTU.";
                  }
                  container qos {
                    if-feature "vpn-common:qos";
                    description
                      "QoS configuration.";
                    container qos-classification-policy {
                      description
                        "Configuration of the traffic
                         classification policy.";
                      uses vpn-common:qos-classification-policy;
                    }
                    container qos-action {
                      description
                        "List of QoS action policies.";
                      list rule {
                        key "id";
                        description
                          "List of QoS actions.";
                        leaf id {
                          type string;
                          description
                            "An identifier of the QoS action
                             rule.";
                        }
                        leaf target-class-id {
                          type string;
                          description
                            "Identification of the class of
                             service.  This identifier is internal
                             to the administration.";
                        }
                        leaf inbound-rate-limit {
                          type decimal64 {
                            fraction-digits 5;
                            range "0..100";
                          }
                          units "percent";
                          description
                            "Specifies whether/how to rate-limit
                             the inbound traffic matching this QoS
                             policy.  It is expressed as a percent
                             of the value that is indicated in
                             'input-bandwidth'.";
                        }
                        leaf outbound-rate-limit {
                          type decimal64 {
                            fraction-digits 5;
                            range "0..100";
                          }
                          units "percent";
                          description
                            "Specifies whether/how to rate-limit
                             the outbound traffic matching this
                             QoS policy.  It is expressed as a
                             percent of the value that is
                             indicated in 'output-bandwidth'.";
                        }
                      }
                    }
                    container qos-profile {
                      description
                        "QoS profile configuration.";
                      list qos-profile {
                        key "profile";
                        description
                          "QoS profile.
                           Can be a standard profile or
                           a customized profile.";
                        leaf profile {
                          type leafref {
                            path "/l3vpn-ntw/vpn-profiles"
                               + "/valid-provider-identifiers"
                               + "/qos-profile-identifier/id";
                          }
                          description
                            "QoS profile to be used.";
                        }
                        leaf direction {
                          type identityref {
                            base vpn-common:qos-profile-direction;
                          }
                          default "vpn-common:both";
                          description
                            "The direction to which the QoS
                             profile is applied.";
                        }
                      }
                    }
                  }
                  container carriers-carrier {
                    if-feature "vpn-common:carriers-carrier";
                    description
                      "This container is used when the customer
                       provides MPLS-based services.  This is
                       only used in the case of CsC (i.e., a
                       customer builds an MPLS service using an
                       IP VPN to carry its traffic).";
                    leaf signaling-type {
                      type enumeration {
                        enum ldp {
                          description
                            "Use
                            "Uses LDP as the signaling protocol
                             between the PE and the CE.  In this
                             case, an IGP routing protocol must
                             also be configured.";
                        }
                        enum bgp {
                          description
                            "Use
                            "Uses BGP as the signaling protocol
                             between the PE and the CE.
                             In this case, BGP must also be
                             configured as the routing protocol.";
                          reference
                            "RFC 8277: Using BGP to Bind MPLS
                                       Labels to Address
                                       Prefixes";
                        }
                      }
                      default "bgp";
                      description
                        "MPLS signaling type.";
                    }
                  }
                  container ntp {
                    description
                      "Time synchronization may be needed in some
                       VPNs
                       VPNs, such as infrastructure and Management management
                       VPNs.  This container includes parameters
                       to enable the NTP service.";
                    reference
                      "RFC 5905: Network Time Protocol Version 4:
                                 Protocol and Algorithms
                                 Specification";
                    leaf broadcast {
                      type enumeration {
                        enum client {
                          description
                            "The VPN node will listen to NTP
                             broadcast messages on this VPN
                             network access.";
                        }
                        enum server {
                          description
                            "The VPN node will behave as a
                             broadcast server.";
                        }
                      }
                      description
                        "Indicates the NTP broadcast mode to use
                         for the VPN network access.";
                    }
                    container auth-profile {
                      description
                        "Pointer to a local profile.";
                      leaf profile-id {
                        type string;
                        description
                          "A pointer to a local authentication
                           profile on the VPN node is provided.";
                      }
                    }
                    uses vpn-common:service-status;
                  }
                  container multicast {
                    if-feature "vpn-common:multicast";
                    description
                      "Multicast parameters for the network
                       access.";
                    leaf access-type {
                      type enumeration {
                        enum receiver-only {
                          description
                            "The peer site only has receivers.";
                        }
                        enum source-only {
                          description
                            "The peer site only has sources.";
                        }
                        enum source-receiver {
                          description
                            "The peer site has both sources and
                             receivers.";
                        }
                      }
                      default "source-receiver";
                      description
                        "Type of multicast site.";
                    }
                    leaf address-family {
                      type identityref {
                        base vpn-common:address-family;
                      }
                      description
                        "Indicates the address family.";
                    }
                    leaf protocol-type {
                      type enumeration {
                        enum host {
                          description
                            "Hosts are directly connected to the
                             provider network.

                             Host protocols protocols, such as IGMP or MLD MLD,
                             are required.";
                        }
                        enum router {
                          description
                            "Hosts are behind a customer router.
                             PIM will be implemented.";
                        }
                        enum both {
                          description
                            "Some hosts are behind a customer
                             router, and some others are directly
                             connected to the provider network.
                             Both host and routing protocols must
                             be used.

                             Typically, IGMP and PIM will be
                             implemented.";
                        }
                      }
                      default "both";
                      description
                        "Multicast protocol type to be used with
                         the customer site.";
                    }
                    leaf remote-source {
                      type boolean;
                      default "false";
                      description
                        "A remote multicast source is a source
                         that is not on the same subnet as the
                         vpn-network-access.
                         VPN network access.  When set to 'true',
                         the multicast traffic from a remote
                         source is accepted.";
                    }
                    container igmp {
                      when "../protocol-type = 'host' and "
                         + "../address-family = 'vpn-common:ipv4' or "
                         + "'vpn-common:dual-stack'"; "or 'vpn-common:dual-stack'";
                      if-feature "vpn-common:igmp";
                      description
                        "Includes IGMP-related parameters.";
                      list static-group {
                        key "group-addr";
                        description
                          "Multicast static source/group
                           associated to with the IGMP session"; session.";
                        leaf group-addr {
                          type rt-types:ipv4-multicast-group-address;
                          description
                            "Multicast group IPv4 address.";
                        }
                        leaf source-addr {
                          type rt-types:ipv4-multicast-source-address; rt-types:ipv4-multicast-source\
                                        -address;
                          description
                            "Multicast source IPv4 address.";
                        }
                      }
                      leaf max-groups {
                        type uint32;
                        description
                          "Indicates the maximum number of
                           groups.";
                      }
                      leaf max-entries {
                        type uint32;
                        description
                          "Indicates the maximum number of IGMP
                           entries.";
                      }
                      leaf max-group-sources {
                        type uint32;
                        description
                          "The maximum number of group sources.";
                      }
                      leaf version {
                        type identityref {
                          base vpn-common:igmp-version;
                        }
                        default "vpn-common:igmpv2";
                        description
                          "Version of
                          "Indicates the IGMP."; IGMP version.";
                      }
                      uses vpn-common:service-status;
                    }
                    container mld {
                      when "../protocol-type = 'host' and "
                         + "../address-family = 'vpn-common:ipv6' or "
                         + "'vpn-common:dual-stack'"; "or 'vpn-common:dual-stack'";
                      if-feature "vpn-common:mld";
                      description
                        "Includes MLD-related parameters.";
                      list static-group {
                        key "group-addr";
                        description
                          "Multicast static source/group associated to
                           with the MLD session"; session.";
                        leaf group-addr {
                          type rt-types:ipv6-multicast-group-address;
                          description
                            "Multicast group IPv6 address.";
                        }
                        leaf source-addr {
                          type rt-types:ipv6-multicast-source-address; rt-types:ipv6-multicast-source\
                                        -address;
                          description
                            "Multicast source IPv6 address.";
                        }
                      }
                      leaf max-groups {
                        type uint32;
                        description
                          "Indicates the maximum number of
                           groups.";
                      }
                      leaf max-entries {
                        type uint32;
                        description
                          "Indicates the maximum number of MLD
                           entries.";
                      }
                      leaf max-group-sources {
                        type uint32;
                        description
                          "The maximum number of group sources.";
                      }
                      leaf version {
                        type identityref {
                          base vpn-common:mld-version;
                        }
                        default "vpn-common:mldv2";
                        description
                          "Version of
                          "Indicates the MLD protocol."; protocol version.";
                      }
                      uses vpn-common:service-status;
                    }
                    container pim {
                      when "../protocol-type = 'router'";
                      if-feature "vpn-common:pim";
                      description
                        "Only applies when the protocol type is PIM.";
                         'pim'.";
                      leaf hello-interval {
                        type rt-types:timer-value-seconds16;
                        default "30";
                        description
                          "PIM hello-messages interval.
                          "Interval between PIM Hello messages.
                           If set to 'infinity' or 'not-set',
                           no periodic Hello messages are sent.";
                        reference
                          "RFC 7761: Protocol Independent
                                     Multicast - Sparse Mode
                                     (PIM-SM): Protocol
                                     Specification (Revised),
                                     Section 4.11"; 4.11
                           RFC 8294: Common YANG Data Types for
                                     the Routing Area";
                      }
                      leaf dr-priority {
                        type uint32;
                        default "1";
                        description
                          "Indicates the preference in associated
                           with the DR election process.  A larger
                           value has a higher priority over a
                           smaller value.";
                        reference
                          "RFC 7761: Protocol Independent
                                     Multicast - Sparse Mode
                                     (PIM-SM): Protocol
                                     Specification (Revised),
                                     Section 4.3.2";
                      }
                      uses vpn-common:service-status;
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}
<CODE ENDS>
]]></artwork>
      </figure>
]]></sourcecode>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
<t>The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF <xref target="RFC6241"></xref> target="RFC6241"/> or RESTCONF <xref
      target="RFC8040"></xref>. target="RFC8040"/>.
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"/>. The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS <xref target="RFC8446"></xref>.</t> target="RFC8446"/>.</t>
<t>The Network Configuration Access Control Model (NACM) <xref
      target="RFC8341"></xref> target="RFC8341"/>
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>There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the default). These
data nodes may be considered sensitive or vulnerable in some network
environments. Write operations (e.g., edit-config) and delete operations to these data nodes without
proper protection or authentication can have a negative effect on network operations. These are
the subtrees and data nodes and their sensitivity/vulnerability in
the "ietf-l3vpn-ntw" module: <list style="symbols">
          <t>'vpn-profiles': This module:</t>
       <dl newline="false" spacing="normal">
        <dt>'vpn-profiles':</dt><dd>This container includes a set of sensitive data
          that influence how the L3VPN service is delivered. For example, an
          attacker who has access to these data nodes may be able to
          manipulate routing policies, QoS policies, or encryption properties.
          These data nodes are defined with "nacm:default-deny-write" tagging
          <xref target="I-D.ietf-opsawg-vpn-common"></xref>.</t>

          <t>'vpn-services': An target="RFC9181" format="default"/>.</dd>
        <dt>'vpn-services':</dt><dd>An attacker who is able to access network nodes
          can undertake various attacks, such as deleting a running L3VPN
          service, interrupting all the traffic of a client. In addition, an
          attacker may modify the attributes of a running service (e.g., QoS,
          bandwidth, routing protocols, keying material), leading to
          malfunctioning of the service and therefore to SLA Service Level Agreement (SLA) violations. In
          addition, an attacker could attempt to create an L3VPN service or
          add a new network access. In addition to using NACM to prevent
          authorized
          unauthorized access, such activity can be detected by adequately
          monitoring and tracking network configuration changes.</t>
        </list></t> changes.</dd>
       </dl>
<t>Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus important to
control read access (e.g., via get, get-config, or notification) to these data
nodes. These are the subtrees and data nodes and their
sensitivity/vulnerability:</t>

      <t><list style="symbols">
          <t>'customer-name'
       <dl newline="false" spacing="normal">
        <dt>'customer-name' and 'ip-connection': An 'ip-connection':</dt><dd>An attacker can retrieve
          privacy-related information information, which can be used to track a customer.
          Disclosing such information may be considered as a violation of the
          customer-provider trust relationship.</t>

          <t>'keying-material': An relationship.</dd>
        <dt>'keying-material':</dt><dd>An attacker can retrieve the cryptographic
          keys protecting the underlying VPN service (CE-PE routing, in
          particular). These keys could be used to inject spoofed routing
          advertisements.</t>
        </list></t>
          advertisements.</dd>
       </dl>
      <t>Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely
      upon <xref target="RFC8177"></xref> target="RFC8177" format="default"/> for authentication purposes.
      Therefore, this module inherits the security considerations discussed in
      Section 5 of
      <xref target="RFC8177"></xref>. target="RFC8177" sectionFormat="of" section="5"/>. Also, these data nodes
      support supplying explicit keys as strings in ASCII format. The use of
      keys in hexadecimal string format would afford greater key entropy with
      the same number of key-string octets. However, such a format is not
      included in this version of the L3NM L3NM, because it is not supported by the
      underlying device modules (e.g., <xref target="RFC8695"></xref>).</t> target="RFC8695" format="default"/>).</t>
      <t>As discussed in <xref target="rtg"></xref>, target="rtg" format="default"/>, the module supports MD5
      to basically accommodate the installed BGP base. MD5 suffers from the
      security weaknesses discussed in Section 2 of <xref
      target="RFC6151"></xref> or Section 2.1 of target="RFC6151" sectionFormat="of" section="2"/> and <xref
      target="RFC6952"></xref>.</t> target="RFC6952" sectionFormat="of" section="2.1"/>.</t>
      <t><xref target="RFC8633"></xref> target="RFC8633" format="default"/> describes best current practices to be
      considered in VPNs making use of NTP. Moreover, a mechanism to provide
      cryptographic security for NTP is specified in <xref
      target="RFC8915"></xref>.</t> target="RFC8915" format="default"/>.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests IANA to register numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has registered the following URI in the "ns"
      subregistry within the "IETF XML Registry" <xref
      target="RFC3688"></xref>:</t>

      <t><figure>
          <artwork><![CDATA[      URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
      Registrant Contact: The IESG.
      XML: N/A; target="RFC3688" format="default"/>:</t>
      <dl newline="false" spacing="compact">
      <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw</dd>
      <dt>Registrant Contact:</dt><dd>The IESG.</dd>
      <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.
]]></artwork>
        </figure></t>

      <t>This document requests IANA to register namespace.</dd>
      </dl>
      <t>IANA has registered the following YANG module in
      the "YANG Module Names" subregistry <xref target="RFC6020"></xref> target="RFC6020" format="default"/>
      within the "YANG Parameters" registry.</t>

      <t><figure>
          <artwork><![CDATA[      name: ietf-l3vpn-ntw
      namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
      maintained
      <dl newline="false" spacing="compact">
      <dt>Name:</dt><dd>ietf-l3vpn-ntw</dd>
      <dt>Maintained by IANA: N
      prefix: l3nm
      reference: RFC XXXX
]]></artwork>
        </figure></t> IANA?</dt><dd>N</dd>
      <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw</dd>
      <dt>Prefix:</dt><dd>l3nm</dd>
      <dt>Reference:</dt><dd>RFC 9182</dd>
    </dl>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->
  <back>

<displayreference target="I-D.ietf-idr-bgp-model" to="BGP-YANG"/>
<displayreference target="I-D.ietf-rtgwg-qos-model" to="QoS-YANG"/>
<displayreference target="I-D.ietf-teas-enhanced-vpn" to="Enhanced-VPN-Framework"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.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.6513.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8294.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.6991.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.8466.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.8341.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <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.6020.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>

<!-- References split into informative and normative draft-ietf-opsawg-vpn-common (RFC 9181) -->

    <!-- There are
<reference anchor='RFC9181' target="https://www.rfc-editor.org/info/rfc9181">
<front>
<title>A Common YANG Data Model for Layer 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.RFC.1195'?> Layer 3 VPNs</title>
<author initials='S' surname='Barguil' fullname='Samier Barguil'>
<organization />
</author>
<author initials='O' surname='Gonzalez de Dios' fullname='Oscar Gonzalez de Dios' role="editor">
<organization />
</author>
<author initials='M' surname='Boucadair' fullname='Mohamed Boucadair' role="editor">
<organization />
</author>
<author initials='Q' surname='Wu' fullname='Qin Wu'>
<organization />
</author>
<date year='2022' month='February'/>
</front>
<seriesInfo name="RFC" value="9181"/>
<seriesInfo name="DOI" value="10.17487/RFC9181"/>
</reference>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5701.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4577.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4552.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5709.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7474.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7166.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6565.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8177.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5798.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.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.2453.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2080.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2236.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2710.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.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.5905.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5308.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1195.xml"/>

        <reference anchor="ISO10589"
                 target="International Standard 10589:2002, Second Edition"> target="https://www.iso.org/standard/30932.html">
          <front>
          <title>Intermediate
            <title>Information technology - Telecommunications and information exchange between systems - Intermediate System to Intermediate System intra- domain intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)</title>
            <author><organization>ISO</organization></author>
            <date year="2002"/>
          </front>
         <refcontent>ISO/IEC 10589:2002</refcontent>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3644.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4110.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4026.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.8340.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8453.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.7426.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6037.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.8969.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3618.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862.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.8349.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4176.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.8277.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml"/>

<!-- draft-evenwu-opsawg-yang-composed-vpn (Expired)
   One name messed up; have to do long way. -->
<reference anchor='YANG-Composed-VPN'>
<front>
<title>YANG Data Model for Composed VPN Service Delivery</title>
<author fullname="ISO">
            <organization></organization> initials='R' surname='Even' fullname='Roni Even'>
    <organization/></author>
<author initials='B' surname='Wu' fullname='Bo Wu'>
    <organization/></author>
<author initials='Q' surname='Wu' fullname='Qin Wu'>
    <organization/></author>
<author initials='Y' surname='Cheng' fullname='Ying Cheng'>
    <organization/></author>
<date month='March' day='8' year='2019' />
</front>
<seriesInfo name='Internet-Draft' value='draft-evenwu-opsawg-yang-composed-vpn-03' />
</reference>

<!-- draft-ietf-opsawg-sap (I-D Exists) -->
<reference anchor='YANG-SAPs'>
<front>
<title>A Network YANG Model for Service Attachment Points</title>
<author initials='O' surname='Gonzalez de Dios' fullname='Oscar Gonzalez de Dios'>
    <organization/></author>
<author initials='S' surname='Barguil' fullname='Samier Barguil'>
    <organization/></author>
<author initials='Q' surname='Wu' fullname='Qin Wu'>
    <organization/></author>
<author initials='M' surname='Boucadair' fullname='Mohamed Boucadair'>
    <organization/></author>
<author initials='V' surname='Lopez' fullname='Victor Lopez'>
    <organization/></author>
<date month='January' day='25' year='2022' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-opsawg-sap-00' />
</reference>

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

<!-- draft-ietf-pim-yang (AUTH48 since 2021-09-04) -->
<reference anchor="PIM-YANG">
   <front>
      <title>A YANG Data Model for Protocol Independent Multicast (PIM)</title>
      <author fullname="Xufeng Liu">
	 <organization/>
      </author>
      <author fullname="Pete McAllister">
	 <organization/>
      </author>
      <author fullname="Anish Peter">
	 <organization/>
      </author>
      <author fullname="Mahesh Sivakumar">
	 <organization/>
      </author>
      <author fullname="Yisong Liu">
	 <organization/>
      </author>
      <author fullname="Fangwei Hu">
	 <organization/>
      </author>
      <date year="2002" month="May" day="19" year="2018" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-pim-yang-17" />
</reference>
    </references>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.evenwu-opsawg-yang-composed-vpn'?>

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

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

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

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

      <?rfc include='reference.I-D.ietf-teas-enhanced-vpn'?>

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

      <?rfc include='reference.I-D.ietf-bess-evpn-prefix-advertisement'?>

      <?rfc include='reference.I-D.ietf-teas-ietf-network-slices'?>

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

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

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

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

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

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

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

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

<!-- draft-ietf-teas-enhanced-vpn (I-D Exists) -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-teas-enhanced-vpn.xml"/>

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

<!-- draft-ietf-bess-evpn-prefix-advertisement (Published; RFC 9136) -->
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9136.xml"/>

<!-- draft-ietf-teas-ietf-network-slices (I-D Exists)
    One author is editor; have to do long way. -->
<reference anchor="Network-Slices-Framework">
<front>
<title>Framework for IETF Network Slices</title>
<author initials="A" surname="Farrel" fullname="Adrian Farrel" role="editor">
<organization/></author>
<author initials="E" surname="Gray" fullname="Eric Gray">
<organization/></author>
<author initials="J" surname="Drake" fullname="John Drake">
<organization/></author>
<author initials="R" surname="Rokui" fullname="Reza Rokui">
<organization/></author>
<author initials="S" surname="Homma" fullname="Shunsuke Homma">
<organization/></author>
<author initials="K" surname="Makhijani" fullname="Kiran Makhijani">
<organization/></author>
<author initials="LM" surname="Contreras" fullname="Luis M. Contreras">
<organization/></author>
<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
<organization/></author>
<date month='October' day='25' year='2021'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-teas-ietf-network-slices-05'/>
</reference>

        <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.7880.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6952.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8915.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8633.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8695.xml"/>
        <reference anchor="PYANG" target="https://github.com/mbj4668/pyang">
          <front>
            <title>pyang</title>
            <author>
            <organization></organization>
              <organization/>
            </author>
            <date month="November" year="2020" /> month="December" year="2021"/>
          </front>
         <refcontent>commit 524cf61</refcontent>
        </reference>

        <reference anchor="IEEE802.1AX"> anchor="IEEE802.1AX" target="https://ieeexplore.ieee.org/document/9105034">
          <front>
          <title>Link
            <title>802.1AX-2020 - IEEE Standard for Local and Metropolitan Area Networks--Link Aggregation</title>

          <author>
            <organization></organization>
          </author>
            <author><organization>IEEE</organization></author>
<!--            <date month="" year="2020" /> year="2020"/> -->
          </front>
          <refcontent>IEEE Std 802.1AX-2020</refcontent>
<!--         <seriesInfo name="IEEE" value="Std 802.1AX-2020" /> name="DOI" value="10.1109/IEEESTD.2020.9105034"/> -->
        </reference>
      </references>

    <!---->
    </references>

    <section anchor="examples" title="L3VPN Examples">
      <t></t> numbered="true" toc="default">
      <name>L3VPN Examples</name>
      <section anchor="mbh-vpn" title="4G numbered="true" toc="default">
        <name>4G VPN Provisioning Example"> Example</name>
        <t>L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise
        services
        services, mainly because several traffic discrimination policies can be
        applied within the network to deliver to the mobile customers a
        service that meets the SLA requirements.</t>

        <t>As it is
        <t>Typically, and as shown in the <xref target="vpn-service-mbh"></xref>,
        typically, target="vpn-service-mbh" format="default"/>,
        an eNodeB (CE) is directly connected to the access routers
        of the mobile backhaul and their logical interfaces (one or many many,
        according to the service type) are configured in a VPN that transports
        the packets to the mobile core platforms. In this example, a
        'vpn-node' is created with two 'vpn-network-accesses'.</t>
        <figure align="center" anchor="vpn-service-mbh"
                title="Mobile anchor="vpn-service-mbh">
          <name>Mobile Backhaul Example"> Example</name>
          <artwork align="left"><![CDATA[ align="center" name="" type="ascii-art" alt=""><![CDATA[
+-------------+                  +------------------+
|             |                  | PE               |
|             |                  |  198.51.100.1    |
|   eNodeB    |>--------/------->|...........       |
|             |          vlan 1  |          |       |
|             |>--------/------->|......    |       |
|             |          vlan 2  |     |    |       |
|             | Direct           |  +-------------+ |
+-------------+ Routing          |  | vpn-node-id | |
                                 |  | 44          | |
                                 |  +-------------+ |
                                 |                  |
                                 +------------------+
]]></artwork>
        </figure>
        <t>To create an L3VPN service using the L3NM, the following steps can
        be followed.</t>

        <t>First: Create
        <t>First, create the 4G VPN service (<xref
        target="service-mbh2"></xref>).</t> target="service-mbh2" format="default"/>).</t>

        <figure align="center" anchor="service-mbh2"
                title="Create anchor="service-mbh2">
          <name>Create VPN Service">
          <artwork align="center"><![CDATA[POST: Service</name>
<sourcecode name="" type=""><![CDATA[
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services
Host: example.com
Content-Type: application/yang-data+json

{
 "ietf-l3vpn-ntw:vpn-services": {
   "vpn-service": [
     {
       "vpn-id": "4G",
        "customer-name": "mycustomer",
        "vpn-service-topology": "custom",
       "vpn-description": "VPN to deploy 4G services",
       "customer-name": "mycustomer",
       "vpn-service-topology": "custom",
       "vpn-instance-profiles": {
         "vpn-instance-profile": [
           {
             "profile-id": "simple-profile",
             "local-as": 65550,
             "rd": "0:65550:1",
             "address-family": [
               {
                 "address-family": "ietf-vpn-common:dual-stack",
                 "vpn-targets": {
                   "vpn-target": [
                     {
                       "id": 1,
                       "route-targets": [
                         {
                           "route-target": "0:65550:1"
                         }
                       ],
                       "route-target-type": "both"
                     }
                   ]
                 }
               }
             ]
           }
         ]
       }
     }
   ]
 }
}
]]></artwork>
]]></sourcecode>
        </figure>

        <t>Second: Create
        <t>Second, create a VPN node node, as depicted in <xref
        target="service-mbh3"></xref>. target="service-mbh3" format="default"/>. In this type of service, the VPN node
        is equivalent to the VRF configured in the physical device
        ('ne-id'=198.51.100.1).</t>

        <figure align="center" anchor="service-mbh3" title="Create VPN Node">
          <artwork align="center"><![CDATA[===============
        ('ne-id'=198.51.100.1).  NOTE: '\' line wrapping in Figures&nbsp;<xref target="service-mbh3" format="counter"/> and <xref target="service-mbh4" format="counter"/> is implemented per RFC 8792 ================

POST: <xref target="RFC8792"/>.</t>
        <figure anchor="service-mbh3">
          <name>Create VPN Node</name>
          <sourcecode name="" type=""><![CDATA[POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
      vpn-services/vpn-service=4G
Host: example.com
Content-Type: application/yang-data+json

{
  "ietf-l3vpn-ntw:vpn-nodes": {
    "vpn-node": [
      {
        "vpn-node-id": "44",
        "ne-id": "198.51.100.1",
        "active-vpn-instance-profiles": {
          "vpn-instance-profile": [
            {
              "profile-id": "simple-profile"
            }
          ]
        }
      }
    ]
  }
}]]></artwork>
}
]]></sourcecode>
        </figure>
        <t>Finally, two VPN network accesses are created using the same
        physical port ('interface-id'=1/1/1). Each 'vpn-network-access' has a
        particular VLAN (1,2) to interface (1,2): "SYNC" and "DATA" (<xref target="service-mbh4" format="default"/>). These interfaces differentiate the traffic between: Sync and
        data (<xref target="service-mbh4"></xref>).</t> between them.</t>
        <figure align="center" anchor="service-mbh4"
                title="Create anchor="service-mbh4">
          <name>Create VPN Network Access">
          <artwork align="center"><![CDATA[=============== NOTE: '\' line wrapping per RFC 8792 ================

POST: Access</name>
          <sourcecode name="" type=""><![CDATA[POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
      vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44
content-type: application/yang-data+json

{
  "ietf-l3vpn-ntw:vpn-network-accesses": {
    "vpn-network-access": [
      {
        "id": "1/1/1.1",
        "interface-id": "1/1/1",
        "description": "Interface SYNC to eNODE-B",
        "vpn-network-access-type": "ietf-vpn-common:point-to-point",
        "vpn-instance-profile": "simple-profile",
        "status": {
          "admin-status": {
            "status": "ietf-vpn-common:admin-up"
          }
        },
        "connection": {
          "encapsulation": {
            "type": "ietf-vpn-common:dot1q",
            "dot1q": {
              "cvlan-id": 1
            }
          }
        },
        "ip-connection": {
          "ipv4": {
            "local-address": "192.0.2.1",
            "prefix-length": 30,
            "address-allocation-type": "static-address",
            "static-addresses": {
              "primary-address": "1",
              "address": [
                {
                  "address-id": "1",
                  "customer-address": "192.0.2.2"
                }
              ]
            }
          },
          "ipv6": {
            "local-address": "2001:db8::1",
            "prefix-length": 64,
            "address-allocation-type": "static-address",
            "primary-address": "1",
            "address": [
              {
                "address-id": "1",
                "customer-address": "2001:db8::2"
              }
            ]
          }
        },
        "routing-protocols": {
          "routing-protocol": [
            {
              "id": "1",
              "type": "ietf-vpn-common:direct"
            }
          ]
        }
      },
      {
        "id": "1/1/1.2",
        "interface-id": "1/1/1",
        "description": "Interface DATA to eNODE-B",
        "vpn-network-access-type": "ietf-vpn-common:point-to-point",
        "vpn-instance-profile": "simple-profile",
        "status": {
          "admin-status": {
            "status": "ietf-vpn-common:admin-up"
          }
        },
        "connection": {
          "encapsulation": {
            "type": "ietf-vpn-common:dot1q",
            "dot1q": {
              "cvlan-id": 2
            }
          }
        },
        "ip-connection": {
          "ipv4": {
            "local-address": "192.0.2.1",
            "prefix-length": 30,
            "address-allocation-type": "static-address",
            "static-addresses": {
              "primary-address": "1",
              "address": [
                {
                  "address-id": "1",
                  "customer-address": "192.0.2.2"
                }
              ]
            }
          },
          "ipv6": {
            "local-address": "2001:db8::1",
            "prefix-length": 64,
            "address-allocation-type": "static-address",
            "primary-address": "1",
            "address": [
              {
                "address-id": "1",
                "customer-address": "2001:db8::2"
              }
            ]
          }
        },
        "routing-protocols": {
          "routing-protocol": [
            {
              "id": "1",
              "type": "ietf-vpn-common:direct"
            }
          ]
        }
      }
    ]
  }
}]]></artwork>
}
]]></sourcecode>
        </figure>

        <t></t>
      </section>
      <section anchor="loop" title="Loopback Interface"> numbered="true" toc="default">
        <name>Loopback Interface</name>
        <t>An example of a loopback interface is depicted in <xref
        target="loopback"></xref>.</t> target="loopback" format="default"/>.</t>
        <figure align="center" anchor="loopback"
                title="VPN anchor="loopback">
          <name>VPN Network Access with a Loopback Interface (Message Body)">
          <artwork align="center"><![CDATA[{ Body)</name>
          <sourcecode name="" type="json"><![CDATA[{
  "ietf-l3vpn-ntw:vpn-network-accesses": {
    "vpn-network-access": [
      {
        "id": "vpn-access-loopback",
        "interface-id": "Loopback1",
        "description": "An example of a loopback interface.",
        "vpn-network-access-type": "ietf-vpn-common:loopback",
        "status": {
          "admin-status": {
            "status": "ietf-vpn-common:admin-up"
          }
        },
        "ip-connection": {
          "ipv6": {
            "local-address": "2001:db8::4",
            "prefix-length": 128
          }
        }
      }
    ]
  }
}  ]]></artwork>
]]></sourcecode>
        </figure>
      </section>
      <section anchor="app-ex"
               title="Overriding numbered="true" toc="default">
        <name>Overriding VPN Instance Profile Parameters"> Parameters</name>
        <t><xref target="override-ex"></xref> target="override-ex" format="default"/> shows a simplified example to
        illustrate how some information that is provided at the VPN service
        level (particularly as part of the 'vpn-instance-profiles') can be
        overridden by the one information configured at the VPN node level. In this
        example, PE3 and PE4 inherit the 'vpn-instance-profiles' parameters
        that are specified at the VPN service level, but PE1 and PE2 are
        provided with "maximum-routes" values at the VPN node level that
        override the ones values that are specified at the VPN service level.</t>

        <t><figure align="center" anchor="override-ex"
            title="VPN
        <figure anchor="override-ex">
          <name>VPN Instance Profile Example (Message Body)">
            <artwork><![CDATA[{ Body)</name>
          <sourcecode name="" type="json"><![CDATA[{
  "ietf-l3vpn-ntw:vpn-services": {
    "vpn-service": [
      {
        "vpn-id": "override-example",
        "vpn-service-topology": "ietf-vpn-common:hub-spoke",
        "vpn-instance-profiles": {
          "vpn-instance-profile": [
            {
              "profile-id": "HUB",
              "role": "ietf-vpn-common:hub-role",
              "local-as": 64510,
              "rd-suffix": 1001,
              "address-family": [
                {
                  "address-family": "ietf-vpn-common:dual-stack",
                  "maximum-routes": [
                    {
                      "protocol": "ietf-vpn-common:any",
                      "maximum-routes": 100
                    }
                  ]
                }
              ]
            },
            {
              "profile-id": "SPOKE",
              "role": "ietf-vpn-common:spoke-role",
              "local-as": 64510,
              "address-family": [
                {
                  "address-family": "ietf-vpn-common:dual-stack",
                  "maximum-routes": [
                    {
                      "protocol": "ietf-vpn-common:any",
                      "maximum-routes": 1000
                    }
                  ]
                }
              ]
            }
          ]
        },
        "vpn-nodes": {
          "vpn-node": [
            {
              "vpn-node-id": "PE1",
              "ne-id": "pe1",
              "router-id": "198.51.100.1",
              "active-vpn-instance-profiles": {
                "vpn-instance-profile": [
                  {
                    "profile-id": "HUB",
                    "rd": "1:198.51.100.1:1001",
                    "address-family": [
                      {
                        "address-family":
                                 "ietf-vpn-common:dual-stack",
                        "maximum-routes": [
                          {
                            "protocol": "ietf-vpn-common:any",
                            "maximum-routes": 10
                          }
                        ]
                      }
                    ]
                  }
                ]
              }
            },
            {
              "vpn-node-id": "PE2",
              "ne-id": "pe2",
              "router-id": "198.51.100.2",
              "active-vpn-instance-profiles": {
                "vpn-instance-profile": [
                  {
                    "profile-id": "SPOKE",
                    "address-family": [
                      {
                        "address-family":
                                 "ietf-vpn-common:dual-stack",
                        "maximum-routes": [
                          {
                            "protocol": "ietf-vpn-common:any",
                            "maximum-routes": 100
                          }
                        ]
                      }
                    ]
                  }
                ]
              }
            },
            {
              "vpn-node-id": "PE3",
              "ne-id": "pe3",
              "router-id": "198.51.100.3",
              "active-vpn-instance-profiles": {
                "vpn-instance-profile": [
                  {
                    "profile-id": "SPOKE"
                  }
                ]
              }
            },
            {
              "vpn-node-id": "PE4",
              "ne-id": "pe4",
              "router-id": "198.51.100.4",
              "active-vpn-instance-profiles": {
                "vpn-instance-profile": [
                  {
                    "profile-id": "SPOKE"
                  }
                ]
              }
            }
          ]
        }
      }
    ]
  }
}]]></artwork>
          </figure></t>

        <t></t>
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="multicast_vpn_example"
               title="Multicast numbered="true" toc="default">
        <name>Multicast VPN Provisioning Example"> Example</name>
        <t>IPTV is mainly distributed through multicast over the LANs. In the
        following example, PIM-SM PIM - Sparse Mode (PIM-SM) is enabled and functional between the PE and
        the CE. The PE receives multicast traffic from a CE that is directly
        connected to the multicast source. The signaling between the PE and the CE is
        achieved using BGP. Also, the RP is statically configured for a multicast
        group.</t>
        <figure align="center" anchor="service-mc1"
                title="Multicast anchor="service-mc1">
          <name>Multicast L3VPN Service Example"> Example</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="ascii-art" alt=""><![CDATA[
+-----------+   +------+     +------+    +-----------+
| Multicast |---|  CE  |--/--|  PE  |----|  Backbone |
|  source   |   +------+     +------+    |   IP/MPLS |
+-----------+                            +-----------+
]]></artwork>
        </figure>

        <t>An example is provided below to illustrate
        <t><xref target="service-mc2"/> illustrates how to configure a
        multicast L3VPN service using the L3NM.</t>
        <t>First, the multicast service is created together with a generic VPN
        instance profile (see the excerpt of the request message body shown in
        <xref target="service-mc2"></xref>)</t> target="service-mc2" format="default"/>).</t>
        <figure align="center" anchor="service-mc2"
                title=" Create anchor="service-mc2">
          <name>Create Multicast VPN Service (Excerpt of the Message Request Body)">
          <artwork align="center"><![CDATA[{ Body)</name>
          <sourcecode name="" type="json"><![CDATA[{
  "ietf-l3vpn-ntw:vpn-services": {
    "vpn-service": [
      {
        "vpn-id": "Multicast-IPTV",
        "vpn-description": "Multicast IPTV VPN service",
        "customer-name": "a-name",
        "vpn-service-topology": "ietf-vpn-common:hub-spoke",
        "vpn-instance-profiles": {
          "vpn-instance-profile": [
            {
              "profile-id": "multicast",
              "role": "ietf-vpn-common:hub-role",
              "local-as": 65536,
              "multicast": {
                "rp": {
                  "rp-group-mappings": {
                    "rp-group-mapping": [
                      {
                        "id": 1,
                        "rp-address": "203.0.113.17",
                        "groups": {
                          "group": [
                            {
                              "id": 1,
                              "group-address": "239.130.0.0/15"
                            }
                          ]
                        }
                      }
                    ]
                  },
                  "rp-discovery": {
                    "rp-discovery-type": "ietf-vpn-common:static-rp"
                  }
                }
              }
            }
          ]
        }
      }
    ]
  }
}
]]></artwork>
]]></sourcecode>
        </figure>
        <t>Then, the VPN nodes are created (see the excerpt of the request
        message body shown in <xref target="service-mc3"></xref>). target="service-mc3" format="default"/>). In this
        example, the VPN node will represent VRF configured in the physical
        device.</t>
        <figure align="center" anchor="service-mc3"
                title="Create anchor="service-mc3">
          <name>Create Multicast VPN Node (Excerpt of the Message Request Body)">
          <artwork align="left"><![CDATA[{ Body)</name>
          <sourcecode name="" type="json"><![CDATA[{
  "ietf-l3vpn-ntw:vpn-node": [
    {
      "vpn-node-id": "500003105",
      "description": "VRF-IPTV-MULTICAST",
      "ne-id": "198.51.100.10",
      "router-id": "198.51.100.10",
      "active-vpn-instance-profiles": {
        "vpn-instance-profile": [
          {
            "profile-id": "multicast",
            "rd": "65536:31050202"
          }
        ]
      }
    }
  ]
}]]></artwork>
}
]]></sourcecode>
        </figure>
        <t>Finally, create the VPN network access with multicast enabled (see
        the excerpt of the request message body shown in <xref
        target="service-mc4"></xref>).</t> target="service-mc4" format="default"/>).</t>
        <figure align="center" anchor="service-mc4"
                title="Create anchor="service-mc4">
          <name>Create VPN Network Access (Excerpt of the Message Request Body)">
          <artwork align="left"><![CDATA[{ Body)</name>
          <sourcecode name="" type="json"><![CDATA[{
  "ietf-l3vpn-ntw:vpn-network-access": {
    "id": "1/1/1",
    "description": "Connected-to-source",
    "vpn-network-access-type": "ietf-vpn-common:point-to-point",
    "vpn-instance-profile": "multicast",
    "status": {
      "admin-status": {
        "status": "vpn-common:admin-up" "ietf-vpn-common:admin-up"
      },
      "ip-connection": {
        "ipv4": {
          "local-address": "203.0.113.1",
          "prefix-length": 30,
          "address-allocation-type": "static-address",
          "static-addresses": {
            "primary-address": "1",
            "address": [
              {
                "address-id": "1",
                "customer-address": "203.0.113.2"
              }
            ]
          }
        }
      },
      "routing-protocols": {
        "routing-protocol": [
          {
            "id": "1",
            "type": "ietf-vpn-common:bgp-routing",
            "bgp": {
              "description": "Connected to CE",
              "peer-as": "65537",
              "address-family": "ietf-vpn-common:ipv4",
              "neighbor": "203.0.113.2"
            }
          }
        ]
      },
      "service": {
        "inbound-bandwidth":
        "pe-to-ce-bandwidth": "100000000",
        "outbound-bandwidth":
        "ce-to-pe-bandwidth": "100000000",
        "mtu": 1500,
        "multicast": {
          "access-type": "source-only",
          "address-family": "ietf-vpn-common:ipv4",
          "protocol-type": "router",
          "pim": {
            "hello-interval": 30,
            "status": {
              "admin-status": {
                "status": "ietf-vpn-common:admin-up"
              }
            }
          }
        }
      }
    }
  }
}]]></artwork>
}
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="Implementation" title="Implementation Status">
      <t>This section records the status of known implementations of the YANG
      module defined by this specification at the time of posting of this
      document and is based on a proposal described in <xref
      target="RFC7942"></xref>. The description of implementations in this
      section is intended to assist the IETF in its decision processes in
      progressing drafts to RFCs. Please note that the listing of any
      individual implementation here does not imply endorsement by the IETF.
      Furthermore, no effort has been spent to verify the information
      presented here that was supplied by IETF contributors. This is not
      intended as, and must not be construed to be, a catalog of available
      implementations or their features. Readers are advised to note that
      other implementations may exist.</t>

      <t>According to <xref target="RFC7942"></xref>, "this will allow
      reviewers and working groups to assign due consideration to documents
      that have the benefit of running code, which may serve as evidence of
      valuable experimentation and feedback that have made the implemented
      protocols more mature. It is up to the individual working groups to use
      this information as they see fit".</t>

      <t>Note to the RFC Editor: As per <xref target="RFC7942"></xref>
      guidelines, please remove this Implementation Status apendix prior
      publication.</t>

      <section title="Nokia Implementation">
        <t>Details can be found at:
        https://github.com/IETF-OPSAWG-WG/l3nm/blob/master/Implementattion/Nokia.txt</t>
      </section>

      <section title="Huawei Implementation">
        <t>Details can be found at:
        https://github.com/IETF-OPSAWG-WG/l3nm/blob/master/Implementattion/Huawei.txt</t>
      </section>

      <section title="Infinera Implementation">
        <t>Details can be found at:
        https://github.com/IETF-OPSAWG-WG/l3nm/blob/master/Implementattion/Infinera.txt</t>
      </section>

      <section title="Ribbon-ECI Implementation">
        <t>Details can be found at:
        https://github.com/IETF-OPSAWG-WG/l3nm/blob/master/Implementattion/Ribbon-ECI.txt</t>
      </section>

      <section title="Juniper Implementation">
        <t>https://github.com/IETF-OPSAWG-WG/lxnm/blob/master/Implementattion/Juniper</t>
      </section>
    </section>

    <section numbered="false" title="Acknowledgements" toc="default">
      <name>Acknowledgements</name>
      <t>During the discussions of this work, helpful comments, suggestions,
      and reviews were received from (listed alphabetically): Raul Arco,
      Miguel alphabetically) <contact fullname="Raul Arco"/>,
      <contact fullname="Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque
      Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Greg
      Mirsky, and Tom Petch. Cecilia"/>, <contact fullname="Joe Clarke"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Adrian Farrel"/>, <contact fullname="Roque Gagliano"/>, <contact fullname="Christian Jacquenet"/>, <contact fullname="Kireeti Kompella"/>, <contact fullname="Julian Lucek"/>, <contact fullname="Greg Mirsky"/>, and <contact fullname="Tom Petch"/>. Many thanks to them. Thanks to Philip Eardly <contact fullname="Philip Eardley"/> for
      the review of an early draft version of the document.</t>

      <t>Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski
      <t><contact fullname="Daniel King"/>, <contact fullname="Daniel Voyer"/>, <contact fullname="Luay Jalil"/>, and <contact fullname="Stephane Litkowski"/>
      contributed to early version draft versions of the individual submission. <vspace
      blankLines="1" />Many this document. Many thanks to Robert Wilton <contact fullname="Robert Wilton"/> for the AD review. <vspace
      blankLines="1" />Thanks Thanks to Andrew Malis <contact fullname="Andrew Malis"/> for the routing directorate
      review, Rifaat Shekh-Yusef <contact fullname="Rifaat Shekh-Yusef"/> for the security directorate review, Qin Wu <contact fullname="Qin Wu"/>
      for the opsdir review, and Pete Resnick <contact fullname="Pete Resnick"/> for the genart directorate
      review. Thanks to Michael Scharf <contact fullname="Michael Scharf"/> for the discussion on the TCP-AO. <vspace
      blankLines="1" />Thanks to Martin Duke, Lars Eagert, Zaheduzzaman
      Sarker, Roman Danyliw, Erik Kline, Benjamin Kaduk, Francesca Palombini,
      and &Eacute;ric Vyncke Thanks to <contact fullname="Martin Duke"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Erik Kline"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Francesca Palombini"/>,
      and <contact fullname="Éric Vyncke"/> for the IESG review.</t>
      <t>This work was supported in part by the European Commission funded Commission-funded
      H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020
      Secured autonomic traffic management for a Tera of SDN flows (Teraflow)
      project (G.A. 101015857).</t>
    </section>
    <section anchor="Contributors" numbered="false" title="Contributors">
      <figure>
        <artwork><![CDATA[Victor Lopez
Telefonica
Email: victor.lopezalvarez@telefonica.com

Qin Wu
Huawei
Email: bill.wu@huawei.com>

Manuel Julian
Vodafone
Email: manuel-julian.lopez@vodafone.com

Lucia toc="default">
      <name>Contributors</name>
      <contact fullname="Victor Lopez">
        <organization>Nokia</organization>
        <address>
          <postal>
            <street></street>
            <city>Madrid</city>
            <region></region>
            <code></code>
            <country>Spain</country>
          </postal>
          <email>victor.lopez@nokia.com</email>
        </address>
      </contact>

      <contact fullname="Qin Wu">
        <organization>Huawei</organization>
        <address>
          <email>bill.wu@huawei.com</email>
        </address>
      </contact>

      <contact fullname="Manuel Lopez">
        <organization>Vodafone</organization>
        <address>
        <postal>
        <country>Spain</country>
        </postal>
          <email>manuel-julian.lopez@vodafone.com</email>
        </address>
      </contact>

      <contact fullname="Lucia Oliva Ballega
Telefonica
Email: lucia.olivaballega.ext@telefonica.com

Erez Segev
ECI Telecom
Email: erez.segev@ecitele.com>

Paul Sherratt
Gamma Telecom
Email: paul.sherratt@gamma.co.uk
]]></artwork>
      </figure> Ballega">
        <organization>Telefonica</organization>
        <address>
          <email>lucia.olivaballega.ext@telefonica.com</email>
        </address>
      </contact>

      <contact fullname="Erez Segev">
        <organization>Ribbon Communications</organization>
        <address>
          <email>erez.segev@rbbn.com</email>
        </address>
      </contact>

      <contact fullname="Paul Sherratt">
        <organization>Gamma Telecom</organization>
        <address>
          <email>paul.sherratt@gamma.co.uk</email>
        </address>
      </contact>
    </section>
  </back>
</rfc>