<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="utf-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.3.6) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-opsawg-ntw-attachment-circuit-16" number="9835" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.25.0 --> version="3" updates="" obsoletes="" xml:lang="en">

  <front>
    <title abbrev="A YANG Network Model for ACs">A Network YANG Data Model for Attachment Circuits</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ntw-attachment-circuit-16"/> name="RFC" value="9835"/>
    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair" role="editor">
      <organization>Orange</organization>
      <address>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <author fullname="Richard Roberts"> Roberts" initials="R." surname="Roberts">
      <organization>Juniper</organization>
      <address>
        <email>rroberts@juniper.net</email>
      </address>
    </author>
    <author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dios">
      <organization>Telefonica</organization>
      <address>
        <email>oscar.gonzalezdedios@telefonica.com</email>
      </address>
    </author>
    <author fullname="Samier Barguil Giraldo" initials="S." surname="Barguil Giraldo">
      <organization>Nokia</organization>
      <address>
        <email>samier.barguil_giraldo@nokia.com</email>
      </address>
    </author>
    <author fullname="Bo Wu"> Wu" initials="B" surname="Wu">
      <organization>Huawei Technologies</organization>
      <address>
        <email>lana.wubo@huawei.com</email>
      </address>
    </author>
    <date year="2025" month="January" day="23"/>
    <area>Operations and Management</area>
    <workgroup>Operations and Management Area Working Group</workgroup> month="August"/>
    <area>OPS</area>
    <workgroup>opsawg</workgroup>

    <keyword>Slice Service</keyword>
    <keyword>L3VPN</keyword>
    <keyword>L2VPN</keyword>
    <keyword>Automation</keyword>
    <keyword>Network Automation</keyword>
    <keyword>Orchestration</keyword>
    <keyword>service delivery</keyword>
    <keyword>Service provisioning</keyword>
    <keyword>service segmentation</keyword>
    <keyword>service flexibility</keyword>
    <keyword>service simplification</keyword>
    <keyword>Network Service</keyword>
    <keyword>3GPP</keyword>
    <keyword>Network Slicing</keyword>

    <abstract>
      <?line 95?>
<t>This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior to or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG "YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf-opsawg-teas-attachment-circuit).</t> (ACaaS)" (RFC9834).</t>
      <t>The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs).</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org),
    which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/opsawg/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/boucadair/attachment-circuit-model"/>.</t>
    </note>
  </front>
  <middle>
    <?line 101?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Connectivity services are provided by networks to customers via
   dedicated terminating points, such as Service Functions <xref target="RFC7665"/>,
   customer edges
   Customer Edges (CEs), peer Autonomous System Border Routers (ASBRs),
   data centers center gateways, or Internet Exchange Points.</t>
      <t>The procedure to provision a service in a service provider network may depend on the practices adopted by a service provider, including the flow put in place for the provisioning of advanced network services and how they are bound to an attachment circuit (AC). For example, the same attachment circuit may host multiple services (e.g., Layer 2 Virtual Private Network (VPN), or VPN (L2VPN), Layer 3 VPN, VPN (L3VPN), or Network Slice Service <xref target="RFC9543"/>). In order to avoid service interference and redundant information in various locations, a service provider may expose an interface to manage ACs network-wide. Customers can then request a standalone attachment circuit to be put in place, place and then  refer to that attachment circuit when requesting services to be bound to that AC. <xref target="I-D.ietf-opsawg-teas-attachment-circuit"/> target="RFC9834"/> specifies a data model for managing attachment circuits Attachment Circuits as a service.</t> Service (ACaaS).</t>
      <t><xref target="sec-module"/> specifies a network model for attachment circuits ("ietf-ac-ntw"). The model can be used for the provisioning of ACs in a provider network prior to or during service provisioning. For example, <xref target="I-D.ietf-opsawg-ac-lxsm-lxnm-glue"/> target="RFC9836"/> specifies augmentations to the L2VPN Network Model (L2NM) <xref target="RFC9291"/> and the L3VPN Network Model (L3NM) <xref target="RFC9182"/> to bind LxVPNs to ACs that are provisioned using the procedure defined in this document.</t>
      <t>The
      <t>This document leverages <xref target="RFC9182"/> and <xref target="RFC9291"/> by adopting an AC provisioning structure that uses data nodes that are defined in those RFCs. Some refinements were introduced to cover not only conventional service provider networks, networks but also specifics of other target deployments (e.g., cloud network).</t>
      <t>The AC network model is designed as augmentations of both the 'ietf-network' model <xref target="RFC8345"/> and the Service Attachment Point (SAP) model <xref target="RFC9408"/>. An attachment circuit can be bound to a single or multiple SAPs. Likewise, the model is designed to accommodate deployments where a SAP can be bound to one or multiple ACs (e.g., a parent AC and its child ACs).</t>
      <figure anchor="sap-ac-ntw">
        <name>Attachment Circuits Examples</name>
        <artset>
          <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="496" width="536" viewBox="0 0 536 496" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
              <path d="M 8,240 L 8,256" fill="none" stroke="black"/>
              <path d="M 40,224 L 40,240" fill="none" stroke="black"/>
              <path d="M 80,176 L 80,224" fill="none" stroke="black"/>
              <path d="M 80,256 L 80,272" fill="none" stroke="black"/>
              <path d="M 80,304 L 80,400" fill="none" stroke="black"/>
              <path d="M 112,112 L 112,160" fill="none" stroke="black"/>
              <path d="M 144,48 L 144,64" fill="none" stroke="black"/>
              <path d="M 160,64 L 160,112" fill="none" stroke="black"/>
              <path d="M 176,32 L 176,48" fill="none" stroke="black"/>
              <path d="M 192,464 L 192,480" fill="none" stroke="black"/>
              <path d="M 208,112 L 208,160" fill="none" stroke="black"/>
              <path d="M 208,416 L 208,448" fill="none" stroke="black"/>
              <path d="M 224,448 L 224,464" fill="none" stroke="black"/>
              <path d="M 240,96 L 240,112" fill="none" stroke="black"/>
              <path d="M 240,176 L 240,272" fill="none" stroke="black"/>
              <path d="M 240,304 L 240,400" fill="none" stroke="black"/>
              <path d="M 272,80 L 272,96" fill="none" stroke="black"/>
              <path d="M 296,176 L 296,272" fill="none" stroke="black"/>
              <path d="M 296,304 L 296,400" fill="none" stroke="black"/>
              <path d="M 328,96 L 328,160" fill="none" stroke="black"/>
              <path d="M 328,416 L 328,464" fill="none" stroke="black"/>
              <path d="M 360,464 L 360,480" fill="none" stroke="black"/>
              <path d="M 376,416 L 376,448" fill="none" stroke="black"/>
              <path d="M 384,96 L 384,112" fill="none" stroke="black"/>
              <path d="M 392,448 L 392,464" fill="none" stroke="black"/>
              <path d="M 416,80 L 416,96" fill="none" stroke="black"/>
              <path d="M 424,416 L 424,464" fill="none" stroke="black"/>
              <path d="M 456,176 L 456,272" fill="none" stroke="black"/>
              <path d="M 456,304 L 456,320" fill="none" stroke="black"/>
              <path d="M 456,360 L 456,400" fill="none" stroke="black"/>
              <path d="M 496,336 L 496,352" fill="none" stroke="black"/>
              <path d="M 528,320 L 528,336" fill="none" stroke="black"/>
              <path d="M 160,32 L 176,32" fill="none" stroke="black"/>
              <path d="M 144,64 L 160,64" fill="none" stroke="black"/>
              <path d="M 256,80 L 272,80" fill="none" stroke="black"/>
              <path d="M 400,80 L 416,80" fill="none" stroke="black"/>
              <path d="M 272,96 L 384,96" fill="none" stroke="black"/>
              <path d="M 112,112 L 208,112" fill="none" stroke="black"/>
              <path d="M 240,112 L 256,112" fill="none" stroke="black"/>
              <path d="M 384,112 L 400,112" fill="none" stroke="black"/>
              <path d="M 80,176 L 96,176" fill="none" stroke="black"/>
              <path d="M 128,176 L 192,176" fill="none" stroke="black"/>
              <path d="M 224,176 L 240,176" fill="none" stroke="black"/>
              <path d="M 296,176 L 312,176" fill="none" stroke="black"/>
              <path d="M 344,176 L 456,176" fill="none" stroke="black"/>
              <path d="M 24,224 L 40,224" fill="none" stroke="black"/>
              <path d="M 40,240 L 64,240" fill="none" stroke="black"/>
              <path d="M 8,256 L 24,256" fill="none" stroke="black"/>
              <path d="M 80,272 L 240,272" fill="none" stroke="black"/>
              <path d="M 296,272 L 456,272" fill="none" stroke="black"/>
              <path d="M 80,304 L 240,304" fill="none" stroke="black"/>
              <path d="M 296,304 L 456,304" fill="none" stroke="black"/>
              <path d="M 512,320 L 528,320" fill="none" stroke="black"/>
              <path d="M 472,336 L 496,336" fill="none" stroke="black"/>
              <path d="M 496,352 L 512,352" fill="none" stroke="black"/>
              <path d="M 80,400 L 192,400" fill="none" stroke="black"/>
              <path d="M 224,400 L 240,400" fill="none" stroke="black"/>
              <path d="M 296,400 L 312,400" fill="none" stroke="black"/>
              <path d="M 344,400 L 360,400" fill="none" stroke="black"/>
              <path d="M 392,400 L 408,400" fill="none" stroke="black"/>
              <path d="M 440,400 L 456,400" fill="none" stroke="black"/>
              <path d="M 208,448 L 224,448" fill="none" stroke="black"/>
              <path d="M 376,448 L 392,448" fill="none" stroke="black"/>
              <path d="M 224,464 L 264,464" fill="none" stroke="black"/>
              <path d="M 288,464 L 328,464" fill="none" stroke="black"/>
              <path d="M 392,464 L 424,464" fill="none" stroke="black"/>
              <path d="M 192,480 L 208,480" fill="none" stroke="black"/>
              <path d="M 360,480 L 376,480" fill="none" stroke="black"/>
              <path d="M 160,32 C 151.16936,32 144,39.16936 144,48" fill="none" stroke="black"/>
              <path d="M 160,64 C 168.83064,64 176,56.83064 176,48" fill="none" stroke="black"/>
              <path d="M 256,80 C 247.16936,80 240,87.16936 240,96" fill="none" stroke="black"/>
              <path d="M 400,80 C 391.16936,80 384,87.16936 384,96" fill="none" stroke="black"/>
              <path d="M 256,112 C 264.83064,112 272,104.83064 272,96" fill="none" stroke="black"/>
              <path d="M 400,112 C 408.83064,112 416,104.83064 416,96" fill="none" stroke="black"/>
              <path d="M 112,160 C 103.16936,160 96,167.16936 96,176" fill="none" stroke="black"/>
              <path d="M 112,160 C 120.83064,160 128,167.16936 128,176" fill="none" stroke="black"/>
              <path d="M 208,160 C 199.16936,160 192,167.16936 192,176" fill="none" stroke="black"/>
              <path d="M 208,160 C 216.83064,160 224,167.16936 224,176" fill="none" stroke="black"/>
              <path d="M 328,160 C 319.16936,160 312,167.16936 312,176" fill="none" stroke="black"/>
              <path d="M 328,160 C 336.83064,160 344,167.16936 344,176" fill="none" stroke="black"/>
              <path d="M 112,192 C 103.16936,192 96,184.83064 96,176" fill="none" stroke="black"/>
              <path d="M 112,192 C 120.83064,192 128,184.83064 128,176" fill="none" stroke="black"/>
              <path d="M 208,192 C 199.16936,192 192,184.83064 192,176" fill="none" stroke="black"/>
              <path d="M 208,192 C 216.83064,192 224,184.83064 224,176" fill="none" stroke="black"/>
              <path d="M 328,192 C 319.16936,192 312,184.83064 312,176" fill="none" stroke="black"/>
              <path d="M 328,192 C 336.83064,192 344,184.83064 344,176" fill="none" stroke="black"/>
              <path d="M 24,224 C 15.16936,224 8,231.16936 8,240" fill="none" stroke="black"/>
              <path d="M 80,224 C 71.16936,224 64,231.16936 64,240" fill="none" stroke="black"/>
              <path d="M 80,224 C 88.83064,224 96,231.16936 96,240" fill="none" stroke="black"/>
              <path d="M 24,256 C 32.83064,256 40,248.83064 40,240" fill="none" stroke="black"/>
              <path d="M 80,256 C 71.16936,256 64,248.83064 64,240" fill="none" stroke="black"/>
              <path d="M 80,256 C 88.83064,256 96,248.83064 96,240" fill="none" stroke="black"/>
              <path d="M 456,320 C 447.16936,320 440,327.16936 440,336" fill="none" stroke="black"/>
              <path d="M 456,320 C 464.83064,320 472,327.16936 472,336" fill="none" stroke="black"/>
              <path d="M 512,320 C 503.16936,320 496,327.16936 496,336" fill="none" stroke="black"/>
              <path d="M 456,352 C 447.16936,352 440,344.83064 440,336" fill="none" stroke="black"/>
              <path d="M 456,352 C 464.83064,352 472,344.83064 472,336" fill="none" stroke="black"/>
              <path d="M 512,352 C 520.83064,352 528,344.83064 528,336" fill="none" stroke="black"/>
              <path d="M 208,384 C 199.16936,384 192,391.16936 192,400" fill="none" stroke="black"/>
              <path d="M 208,384 C 216.83064,384 224,391.16936 224,400" fill="none" stroke="black"/>
              <path d="M 328,384 C 319.16936,384 312,391.16936 312,400" fill="none" stroke="black"/>
              <path d="M 328,384 C 336.83064,384 344,391.16936 344,400" fill="none" stroke="black"/>
              <path d="M 376,384 C 367.16936,384 360,391.16936 360,400" fill="none" stroke="black"/>
              <path d="M 376,384 C 384.83064,384 392,391.16936 392,400" fill="none" stroke="black"/>
              <path d="M 424,384 C 415.16936,384 408,391.16936 408,400" fill="none" stroke="black"/>
              <path d="M 424,384 C 432.83064,384 440,391.16936 440,400" fill="none" stroke="black"/>
              <path d="M 208,416 C 199.16936,416 192,408.83064 192,400" fill="none" stroke="black"/>
              <path d="M 208,416 C 216.83064,416 224,408.83064 224,400" fill="none" stroke="black"/>
              <path d="M 328,416 C 319.16936,416 312,408.83064 312,400" fill="none" stroke="black"/>
              <path d="M 328,416 C 336.83064,416 344,408.83064 344,400" fill="none" stroke="black"/>
              <path d="M 376,416 C 367.16936,416 360,408.83064 360,400" fill="none" stroke="black"/>
              <path d="M 376,416 C 384.83064,416 392,408.83064 392,400" fill="none" stroke="black"/>
              <path d="M 424,416 C 415.16936,416 408,408.83064 408,400" fill="none" stroke="black"/>
              <path d="M 424,416 C 432.83064,416 440,408.83064 440,400" fill="none" stroke="black"/>
              <path d="M 208,448 C 199.16936,448 192,455.16936 192,464" fill="none" stroke="black"/>
              <path d="M 376,448 C 367.16936,448 360,455.16936 360,464" fill="none" stroke="black"/>
              <path d="M 208,480 C 216.83064,480 224,472.83064 224,464" fill="none" stroke="black"/>
              <path d="M 376,480 C 384.83064,480 392,472.83064 392,464" fill="none" stroke="black"/>
              <g class="text">
                <text x="160" y="52">CE6</text>
                <text x="140" y="84">ac</text>
                <text x="256" y="100">CE5</text>
                <text x="400" y="100">CE2</text>
                <text x="340" y="132">ac</text>
                <text x="112" y="180">sap</text>
                <text x="208" y="180">sap</text>
                <text x="328" y="180">sap</text>
                <text x="160" y="212">PE1</text>
                <text x="376" y="212">PE2</text>
                <text x="24" y="244">CE1</text>
                <text x="80" y="244">sap</text>
                <text x="52" y="260">ac</text>
                <text x="484" y="324">ac</text>
                <text x="168" y="340">PE3</text>
                <text x="376" y="340">PE4</text>
                <text x="456" y="340">sap</text>
                <text x="512" y="340">CE5</text>
                <text x="208" y="404">sap</text>
                <text x="328" y="404">sap</text>
                <text x="376" y="404">sap</text>
                <text x="424" y="404">sap</text>
                <text x="220" y="436">ac</text>
                <text x="388" y="436">ac</text>
                <text x="436" y="436">ac</text>
                <text x="208" y="468">CE3</text>
                <text x="276" y="468">ac</text>
                <text x="376" y="468">CE4</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="center"><![CDATA[
                  .--.
                 |CE6|
                 '-+'
                ac |          .--.              .--.
                   |         |CE5+------+------+CE2|
             .-----+-----.   '--'       |      '--'
             |           |              |ac
             |           |              |
            .+.         .+.            .+.
         .-+sap+-------+sap+-.      .-+sap+-------------.
         |  '-'         '-'  |      |  '-'              |
         |        PE1        |      |        PE2        |
 .--.   .+.                  |      |                   |
|CE1+--+sap|                 |      |                   |
'--' ac '+'                  |      |                   |
         '-------------------'      '-------------------'

         .-------------------.      .-------------------.
         |                   |      |                  .+. ac .--.
         |         PE3       |      |        PE4      |sap+--+CE5|
         |                   |      |                  '-'   '--'
         |                   |      |                   |
         |              .-.  |      |  .-.   .-.   .-.  |
         '-------------+sap+-'      '-+sap+-+sap+-+sap+-'
                        '+'            '+'   '+'   '+'
                         |ac            |     |ac   |ac
                        .+-.            |    .+-.   |
                       |CE3+-----ac-----'   |CE4+---'
                       '--'                 '--'
]]></artwork>
        </artset>
      </figure>
      <t>The AC network model uses the AC common model defined in <xref target="I-D.ietf-opsawg-teas-common-ac"/>.</t> target="RFC9833"/>.</t>
      <t>The YANG 1.1 <xref target="RFC7950"/> data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t>
      <t>Sample
      <t>Some examples are provided in <xref target="sec-examples"/>.</t>
      <section anchor="editorial-note-to-be-removed-by-rfc-editor">
        <name>Editorial Note (To be removed by RFC Editor)</name>
        <t>Note to the RFC Editor: This section is to be removed prior to publication.</t>
        <t>This document contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed.</t>
        <t>Please apply the following replacements:</t>
        <ul spacing="normal">
          <li>
            <t>CCCC --&gt; the assigned RFC number for <xref target="I-D.ietf-opsawg-teas-common-ac"/></t>
          </li>
          <li>
            <t>SSSS --&gt; the assigned RFC number for <xref target="I-D.ietf-opsawg-teas-attachment-circuit"/></t>
          </li>
          <li>
            <t>XXXX --&gt; the assigned RFC number for this I-D</t>
          </li>
          <li>
            <t>2025-01-07 --&gt; the actual date of the publication of this document</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The
        <t>
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t>
      <?line -18?> here.
        </t>
      <t>The reader should be familiar with the terms defined in <xref section="2" sectionFormat="of" target="RFC9408"/>.</t>
      <t>This document uses the term "network model" as defined in <xref section="2.1" sectionFormat="of" target="RFC8969"/>.</t>
      <t>The meanings of the symbols in the YANG tree diagrams are defined in <xref target="RFC8340"/>.</t>
      <t>LxSM refers to both the Layer 2 Service Model (L2SM) <xref target="RFC8466"/> and the Layer 3 Service Model (L3SM) <xref target="RFC8299"/>.</t>
      <t>LxNM refers to both the L2VPN Network Model (L2NM) <xref target="RFC9291"/> and the L3VPN Network Model (L3NM) <xref target="RFC9182"/>.</t>
      <t>LxVPN refers to both L2VPN and L3VPN.</t>
      <t>The following are used in the module prefixes:</t>
      <dl>
      <dl spacing="normal" newline="false">
        <dt>ac:</dt>
        <dd>
          <t>Attachment circuit</t>
        </dd>
        <dt>ntw:</dt>
        <dd>
          <t>Network</t>
        </dd>
        <dt>sap:</dt>
        <dd>
          <t>Service Attchment Attachment Point</t>
        </dd>
        <dt>svc:</dt>
        <dd>
          <t>Service</t>
        </dd>
      </dl>
      <t>In addition, this document uses the following terms:</t>
      <dl>
      <dl spacing="normal" newline="false">
        <dt>Bearer:</dt>
        <dd>
          <t>A physical or logical link that connects a customer node (or site) to a provider network.</t>
        </dd>
        <dt/>
        <dd>
          <t>A bearer can be a wireless or wired link. One or multiple technologies can be used to build a bearer. The bearer type can be specified by a customer.</t>
        </dd>
        <dt/>
        <dd>
          <t>The operator allocates a unique bearer reference to identify a bearer within its network (e.g., customer line identifier). Such a reference can be retrieved by a customer and then used in subsequent service placement requests to unambiguously identify where a service is to be bound.</t>
        </dd>
        <dt/>
        <dd>
          <t>The concept of a bearer can be generalized to refer to the required underlying connection for the provisioning of an attachment circuit.</t>
        </dd>
        <dt/>
        <dd>
          <t>One or multiple attachment circuits may be hosted over the same bearer (e.g., multiple Virtual Local Area Networks (VLANs) on the same bearer that is provided by a physical link).</t>
        </dd>
        <dt>Network controller:</dt>
        <dd>
          <t>Denotes a functional entity responsible for the management of the service provider network. One or multiple network controllers can be deployed in a service provider network.</t>
        </dd>
        <dt>Service orchestrator:</dt>
        <dd>
          <t>Refers to a functional entity that interacts with the customer of a network service.</t>
        </dd>
        <dt/>
        <dd>
          <t>A service orchestrator is typically responsible for the attachment circuits, the Provider Edge (PE) selection, and requesting the activation of the requested services to a network controller.</t>
        </dd>
        <dt/>
        <dd>
          <t>A service orchestrator may interact with one or more network controllers.</t>
        </dd>
        <dt>Service provider network:</dt>
        <dd>
          <t>A network that is able to provide network services (e.g., LxVPN or Network Slice Services).</t>
        </dd>
        <dt>Service provider:</dt>
        <dd>
          <t>An entity that offers network services (e.g., LxVPN or Network Slice Services).</t>
        </dd>
      </dl>
      <t>The names of data nodes are prefixed using the prefix associated with the corresponding imported YANG module as shown in <xref target="pref"/>:</t>
      <table anchor="pref">
        <name>Modules and Their Associated Prefixes</name>
        <thead>
          <tr>
            <th align="left">Prefix</th>
            <th align="left">Module</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">ac-common</td>
            <td align="left">ietf-ac-common</td>
            <td align="left">RFC CCCC</td> align="left"><xref target="RFC9833"/></td>
          </tr>
          <tr>
            <td align="left">ac-svc</td>
            <td align="left">ietf-ac-svc</td>
            <td align="left">Section 5.2 of RFC SSSS</td> align="left"><xref section="5.2" target="RFC9834"/></td>
          </tr>
          <tr>
            <td align="left">dot1q-types</td>
            <td align="left">ieee802-dot1q-types</td>
            <td align="left">
              <xref target="IEEE802.1Qcp"/></td>
          </tr>
          <tr>
            <td align="left">if</td>
            <td align="left">ietf-interfaces</td>
            <td align="left">
              <xref target="RFC8343"/></td>
          </tr>
          <tr>
            <td align="left">inet</td>
            <td align="left">ietf-inet-types</td>
            <td align="left">
              <xref section="4" sectionFormat="of" target="RFC6991"/></td>
          </tr>
          <tr>
            <td align="left">key-chain</td>
            <td align="left">ietf-key-chain</td>
            <td align="left">
              <xref target="RFC8177"/></td>
          </tr>
          <tr>
            <td align="left">nacm</td>
            <td align="left">ietf-netconf-acm</td>
            <td align="left">
              <xref target="RFC8341"/></td>
          </tr>
          <tr>
            <td align="left">nw</td>
            <td align="left">ietf-network</td>
            <td align="left">
              <xref target="RFC8345"/></td>
          </tr>
          <tr>
            <td align="left">rt-types</td>
            <td align="left">ietf-routing-types</td>
            <td align="left">
              <xref target="RFC8294"/></td>
          </tr>
          <tr>
            <td align="left">rt-pol</td>
            <td align="left">ietf-routing-policy</td>
            <td align="left">
              <xref target="RFC9067"/></td>
          </tr>
          <tr>
            <td align="left">sap</td>
            <td align="left">ietf-sap-ntw</td>
            <td align="left">
              <xref target="RFC9408"/></td>
          </tr>
          <tr>
            <td align="left">vpn-common</td>
            <td align="left">ietf-vpn-common</td>
            <td align="left">
              <xref target="RFC9181"/></td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="relationship-to-other-ac-data-models">
      <name>Relationship to Other AC Data Models</name>
      <t><xref target="ac-overview"/> depicts the relationship between the various AC data models:</t>
      <ul spacing="normal">
        <li>
          <t>"ietf-ac-common" (<xref target="I-D.ietf-opsawg-teas-common-ac"/>)</t> <xref target="RFC9833"/></t>
        </li>
        <li>
          <t>"ietf-bearer-svc" (<xref section="5.1" section="6.1" sectionFormat="of" target="I-D.ietf-opsawg-teas-attachment-circuit"/>)</t> target="RFC9834"/>)</t>
        </li>
        <li>
          <t>"ietf-ac-svc" (<xref section="5.2" section="6.2" sectionFormat="of" target="I-D.ietf-opsawg-teas-attachment-circuit"/>)</t> target="RFC9834"/>)</t>
        </li>
        <li>
          <t>"ietf-ac-ntw" (<xref target="sec-module"/>)</t>
        </li>
        <li>
          <t>"ietf-ac-glue" (<xref target="I-D.ietf-opsawg-ac-lxsm-lxnm-glue"/>)</t> <xref target="RFC9836"/></t>
        </li>
      </ul>
      <figure anchor="ac-overview">
        <name>AC Data Models</name>
        <artset>
          <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="288" width="368" viewBox="0 0 368 288" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
              <path d="M 32,144 L 32,240" fill="none" stroke="black"/>
              <path d="M 56,80 L 56,112" fill="none" stroke="black"/>
              <path d="M 72,144 L 72,176" fill="none" stroke="black"/>
              <path d="M 144,48 L 144,80" fill="none" stroke="black"/>
              <path d="M 192,40 L 192,112" fill="none" stroke="black"/>
              <path d="M 240,48 L 240,80" fill="none" stroke="black"/>
              <path d="M 328,80 L 328,160" fill="none" stroke="black"/>
              <path d="M 328,192 L 328,240" fill="none" stroke="black"/>
              <path d="M 56,80 L 144,80" fill="none" stroke="black"/>
              <path d="M 240,80 L 328,80" fill="none" stroke="black"/>
              <path d="M 104,128 L 128,128" fill="none" stroke="black"/>
              <path d="M 72,176 L 264,176" fill="none" stroke="black"/>
              <path d="M 32,240 L 128,240" fill="none" stroke="black"/>
              <path d="M 248,240 L 328,240" fill="none" stroke="black"/>
              <path d="M 24,272 L 40,272" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="336,192 324,186.4 324,197.6" fill="black" transform="rotate(270,328,192)"/>
              <polygon class="arrowhead" points="248,48 236,42.4 236,53.6" fill="black" transform="rotate(270,240,48)"/>
              <polygon class="arrowhead" points="200,40 188,34.4 188,45.6" fill="black" transform="rotate(270,192,40)"/>
              <polygon class="arrowhead" points="152,48 140,42.4 140,53.6" fill="black" transform="rotate(270,144,48)"/>
              <polygon class="arrowhead" points="112,128 100,122.4 100,133.6" fill="black" transform="rotate(180,104,128)"/>
              <polygon class="arrowhead" points="80,144 68,138.4 68,149.6" fill="black" transform="rotate(270,72,144)"/>
              <polygon class="arrowhead" points="48,272 36,266.4 36,277.6" fill="black" transform="rotate(0,40,272)"/>
              <polygon class="arrowhead" points="40,144 28,138.4 28,149.6" fill="black" transform="rotate(270,32,144)"/>
              <g class="text">
                <text x="188" y="36">ietf-ac-common</text>
                <text x="48" y="132">ietf-ac-svc</text>
                <text x="200" y="132">ietf-bearer-svc</text>
                <text x="320" y="180">ietf-ac-ntw</text>
                <text x="188" y="244">ietf-ac-glue</text>
                <text x="8" y="276">X</text>
                <text x="60" y="276">Y:</text>
                <text x="80" y="276">X</text>
                <text x="120" y="276">imports</text>
                <text x="160" y="276">Y</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="center"><![CDATA[
                ietf-ac-common
                 ^     ^     ^
                 |     |     |
      .----------'     |     '----------.
      |                |                |
      |                |                |
ietf-ac-svc <--- ietf-bearer-svc        |
   ^    ^                               |
   |    |                               |
   |    '------------------------ ietf-ac-ntw
   |                                    ^
   |                                    |
   |                                    |
   '------------ ietf-ac-glue ----------'

X --> Y: X imports Y
]]></artwork>
        </artset>
      </figure>
      <t>The "ietf-ac-common" module is imported by the "ietf-bearer-svc", "ietf-ac-svc", and "ietf-ac-ntw" modules. Bearers managed using the "ietf-bearer-svc" module may be referenced by service ACs managed using the "ietf-ac-svc" module. Similarly, a bearer managed using the "ietf-bearer-svc" module may list the set of ACs that use that bearer. To facilitate correlation between an AC service request and the actual AC provisioned in the network, "ietf-ac-ntw" leverages the AC references exposed by the "ietf-ac-svc" module. Furthermore, to bind Layer 2 VPN or Layer 3 VPN services with ACs, the "ietf-ac-glue" module augments the LxSM and LxNM with AC service references exposed by the "ietf-ac-svc" module and AC network references exposed by the "ietf-ac-ntw" module.</t>
    </section>
    <section anchor="sample-uses-of-the-attachment-circuit-data-models">
      <name>Sample Uses of the Attachment Circuit Data Models</name>
      <section anchor="acs-terminated-by-one-or-multiple-customer-edges-ces">
        <name>ACs Terminated by One or Multiple Customer Edges (CEs)</name>
        <t><xref target="uc"/> depicts a sample target topology that involve ACs:</t>
        <ul spacing="normal">
          <li>
            <t>ACs are terminated by a SAP at the network side. See <xref target="sap-ac-ntw"/> for an example of SAPs within a PE.</t>
          </li>
          <li>
            <t>A CE can be either a physical device or a logical entity. Such a logical entity is typically a software component (e.g., a virtual service function Service Function that is hosted within the provider's network or a third-party infrastructure). A CE is seen by the network as a peer SAP <xref target="RFC9408"/>.</t>
          </li>
          <li>
            <t>CEs may be either dedicated to one single connectivity service or host multiple connectivity services (e.g., CEs with roles of service functions Service Functions <xref target="RFC7665"/>).</t>
          </li>
          <li>
            <t>A network provider may bind a single AC to one or multiple peer SAPs (e.g., CE1 and CE2 are tagged as peer SAPs for the same AC). For example, and as discussed in <xref target="RFC4364"/>, multiple CEs can be attached to a PE over the same attachment circuit. This scenario is typically implemented when the Layer 2 infrastructure between the CE and the network is a multipoint service.</t>
          </li>
          <li>
            <t>A single CE may terminate multiple ACs, which can be associated with the same bearer or distinct bearers (e.g., CE4).</t>
          </li>
          <li>
            <t>Customers may request protection schemes in which the ACs associated with their endpoints are terminated by the same PE (e.g., CE3), distinct PEs (e.g., CE4), etc. The network provider uses this request to decide where to terminate the AC in the service provider network and also whether to enable specific capabilities (e.g., Virtual Router Redundancy Protocol (VRRP)).</t>
          </li>
        </ul>
        <t>The "ietf-ac-ntw"
        <t>"ietf-ac-ntw" is a network model that is used to manage the PE side of ACs at a provider network.</t>
        <figure anchor="uc">
          <name>Examples of ACs</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="304" width="512" viewBox="0 0 512 304" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,80 L 8,112" fill="none" stroke="black"/>
                <path d="M 8,160 L 8,192" fill="none" stroke="black"/>
                <path d="M 72,64 L 72,96" fill="none" stroke="black"/>
                <path d="M 72,144 L 72,176" fill="none" stroke="black"/>
                <path d="M 112,80 L 112,176" fill="none" stroke="black"/>
                <path d="M 176,112 L 176,144" fill="none" stroke="black"/>
                <path d="M 192,32 L 192,104" fill="none" stroke="black"/>
                <path d="M 192,152 L 192,224" fill="none" stroke="black"/>
                <path d="M 200,112 L 200,144" fill="none" stroke="black"/>
                <path d="M 280,208 L 280,240" fill="none" stroke="black"/>
                <path d="M 288,248 L 288,272" fill="none" stroke="black"/>
                <path d="M 304,208 L 304,240" fill="none" stroke="black"/>
                <path d="M 352,64 L 352,112" fill="none" stroke="black"/>
                <path d="M 352,144 L 352,192" fill="none" stroke="black"/>
                <path d="M 360,32 L 360,56" fill="none" stroke="black"/>
                <path d="M 360,200 L 360,224" fill="none" stroke="black"/>
                <path d="M 376,64 L 376,112" fill="none" stroke="black"/>
                <path d="M 376,144 L 376,192" fill="none" stroke="black"/>
                <path d="M 448,80 L 448,112" fill="none" stroke="black"/>
                <path d="M 448,160 L 448,192" fill="none" stroke="black"/>
                <path d="M 480,192 L 480,272" fill="none" stroke="black"/>
                <path d="M 504,64 L 504,96" fill="none" stroke="black"/>
                <path d="M 504,144 L 504,176" fill="none" stroke="black"/>
                <path d="M 192,32 L 360,32" fill="none" stroke="black"/>
                <path d="M 24,64 L 72,64" fill="none" stroke="black"/>
                <path d="M 352,64 L 376,64" fill="none" stroke="black"/>
                <path d="M 464,64 L 504,64" fill="none" stroke="black"/>
                <path d="M 72,80 L 112,80" fill="none" stroke="black"/>
                <path d="M 376,80 L 400,80" fill="none" stroke="black"/>
                <path d="M 424,80 L 448,80" fill="none" stroke="black"/>
                <path d="M 376,96 L 400,96" fill="none" stroke="black"/>
                <path d="M 424,96 L 448,96" fill="none" stroke="black"/>
                <path d="M 8,112 L 56,112" fill="none" stroke="black"/>
                <path d="M 176,112 L 200,112" fill="none" stroke="black"/>
                <path d="M 352,112 L 376,112" fill="none" stroke="black"/>
                <path d="M 448,112 L 488,112" fill="none" stroke="black"/>
                <path d="M 112,128 L 136,128" fill="none" stroke="black"/>
                <path d="M 160,128 L 176,128" fill="none" stroke="black"/>
                <path d="M 24,144 L 72,144" fill="none" stroke="black"/>
                <path d="M 176,144 L 200,144" fill="none" stroke="black"/>
                <path d="M 352,144 L 376,144" fill="none" stroke="black"/>
                <path d="M 464,144 L 504,144" fill="none" stroke="black"/>
                <path d="M 376,160 L 400,160" fill="none" stroke="black"/>
                <path d="M 424,160 L 448,160" fill="none" stroke="black"/>
                <path d="M 72,176 L 112,176" fill="none" stroke="black"/>
                <path d="M 376,176 L 400,176" fill="none" stroke="black"/>
                <path d="M 424,176 L 448,176" fill="none" stroke="black"/>
                <path d="M 8,192 L 56,192" fill="none" stroke="black"/>
                <path d="M 352,192 L 376,192" fill="none" stroke="black"/>
                <path d="M 448,192 L 488,192" fill="none" stroke="black"/>
                <path d="M 280,208 L 304,208" fill="none" stroke="black"/>
                <path d="M 192,224 L 280,224" fill="none" stroke="black"/>
                <path d="M 304,224 L 360,224" fill="none" stroke="black"/>
                <path d="M 280,240 L 304,240" fill="none" stroke="black"/>
                <path d="M 288,272 L 376,272" fill="none" stroke="black"/>
                <path d="M 400,272 L 480,272" fill="none" stroke="black"/>
                <path d="M 24,64 C 15.16936,64 8,71.16936 8,80" fill="none" stroke="black"/>
                <path d="M 464,64 C 455.16936,64 448,71.16936 448,80" fill="none" stroke="black"/>
                <path d="M 56,112 C 64.83064,112 72,104.83064 72,96" fill="none" stroke="black"/>
                <path d="M 488,112 C 496.83064,112 504,104.83064 504,96" fill="none" stroke="black"/>
                <path d="M 24,144 C 15.16936,144 8,151.16936 8,160" fill="none" stroke="black"/>
                <path d="M 464,144 C 455.16936,144 448,151.16936 448,160" fill="none" stroke="black"/>
                <path d="M 56,192 C 64.83064,192 72,184.83064 72,176" fill="none" stroke="black"/>
                <path d="M 488,192 C 496.83064,192 504,184.83064 504,176" fill="none" stroke="black"/>
                <g class="text">
                  <text x="412" y="68">(b1)</text>
                  <text x="412" y="84">AC</text>
                  <text x="40" y="100">CE1</text>
                  <text x="364" y="100">PE</text>
                  <text x="412" y="100">AC</text>
                  <text x="480" y="100">CE3</text>
                  <text x="412" y="116">(b2)</text>
                  <text x="148" y="132">AC</text>
                  <text x="188" y="132">PE</text>
                  <text x="272" y="132">Network</text>
                  <text x="360" y="132">|</text>
                  <text x="412" y="148">(b3)</text>
                  <text x="412" y="164">AC</text>
                  <text x="40" y="180">CE2</text>
                  <text x="364" y="180">PE</text>
                  <text x="412" y="180">AC</text>
                  <text x="480" y="180">CE4</text>
                  <text x="412" y="196">(b3)</text>
                  <text x="292" y="228">PE</text>
                  <text x="388" y="276">AC</text>
                  <text x="20" y="292">(bx)</text>
                  <text x="48" y="292">=</text>
                  <text x="84" y="292">bearer</text>
                  <text x="124" y="292">Id</text>
                  <text x="144" y="292">x</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
                       .--------------------.
                       |                    |
 .------.              |                   .--.  (b1)   .-----.
|       +----.         |                   |  +---AC---+      |
|  CE1  |    |         |                   |PE+---AC---+  CE3 |
'------'     |       .--.                  '--'  (b2)  '-----'
             +---AC--+PE|     Network       |
 .------.    |       '--'                  .--.  (b3)   .-----.
|       |    |         |                   |  +---AC---+      |
|  CE2  +----'         |                   |PE+---AC---+  CE4 |
'------'               |                   '--'  (b3)  '---+-'
                       |          .--.      |              |
                       '----------+PE+------'              |
                                  '--'                     |
                                   |                       |
                                   '-----------AC----------'
(bx) = bearer Id x
]]></artwork>
          </artset>
        </figure>
      </section>
      <section anchor="positioning-the-ac-network-model-in-the-overall-service-delivery-process">
        <name>Positioning the AC Network Model in the Overall Service Delivery Process</name>
        <t><xref target="_u-ex"/> shows the positioning of the AC network model in the overall service delivery process. The "ietf-ac-ntw" module is a network model which that augments the SAP with a comprehensive set of parameters to reflect the attachment circuits that are in place in a network. The model also maintains the mapping with the service references that are used to expose those ACs to customer customers using the 'ietf-ac-svc' "ietf-ac-svc" module defined in <xref target="I-D.ietf-opsawg-teas-attachment-circuit"/>. target="RFC9834"/>. Whether the same naming conventions to reference an AC are used in the service and network layers is deployment-specific.</t>
        <figure anchor="_u-ex">
          <name>An Example of the Network AC Model Usage</name>

<!--[rfced] We note that Figure 4 uses "CE#1" and "CE#2", while other
figures in the document use "CE1" and "CE2". May we update the CEs in
Figure 4 to match the other figures in the document?

If so, both artworks (svg and ascii-art) will be updated accordingly.
-->

          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="688" width="512" viewBox="0 0 512 688" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,608 L 8,624" fill="none" stroke="black"/>
                <path d="M 48,592 L 48,608" fill="none" stroke="black"/>
                <path d="M 96,480 L 96,496" fill="none" stroke="black"/>
                <path d="M 104,368 L 104,384" fill="none" stroke="black"/>
                <path d="M 120,576 L 120,640" fill="none" stroke="black"/>
                <path d="M 136,400 L 136,464" fill="none" stroke="black"/>
                <path d="M 136,512 L 136,528" fill="none" stroke="black"/>
                <path d="M 176,320 L 176,352" fill="none" stroke="black"/>
                <path d="M 176,480 L 176,496" fill="none" stroke="black"/>
                <path d="M 208,144 L 208,160" fill="none" stroke="black"/>
                <path d="M 208,256 L 208,272" fill="none" stroke="black"/>
                <path d="M 208,400 L 208,568" fill="none" stroke="black"/>
                <path d="M 232,368 L 232,384" fill="none" stroke="black"/>
                <path d="M 272,64 L 272,128" fill="none" stroke="black"/>
                <path d="M 272,176 L 272,240" fill="none" stroke="black"/>
                <path d="M 272,288 L 272,320" fill="none" stroke="black"/>
                <path d="M 296,368 L 296,384" fill="none" stroke="black"/>
                <path d="M 336,144 L 336,160" fill="none" stroke="black"/>
                <path d="M 336,256 L 336,272" fill="none" stroke="black"/>
                <path d="M 368,320 L 368,352" fill="none" stroke="black"/>
                <path d="M 368,400 L 368,568" fill="none" stroke="black"/>
                <path d="M 384,576 L 384,640" fill="none" stroke="black"/>
                <path d="M 424,368 L 424,384" fill="none" stroke="black"/>
                <path d="M 456,608 L 456,624" fill="none" stroke="black"/>
                <path d="M 496,592 L 496,608" fill="none" stroke="black"/>
                <path d="M 224,32 L 320,32" fill="none" stroke="black"/>
                <path d="M 224,64 L 320,64" fill="none" stroke="black"/>
                <path d="M 224,128 L 320,128" fill="none" stroke="black"/>
                <path d="M 224,176 L 320,176" fill="none" stroke="black"/>
                <path d="M 224,240 L 320,240" fill="none" stroke="black"/>
                <path d="M 224,288 L 320,288" fill="none" stroke="black"/>
                <path d="M 176,320 L 368,320" fill="none" stroke="black"/>
                <path d="M 120,352 L 216,352" fill="none" stroke="black"/>
                <path d="M 312,352 L 408,352" fill="none" stroke="black"/>
                <path d="M 120,400 L 216,400" fill="none" stroke="black"/>
                <path d="M 312,400 L 408,400" fill="none" stroke="black"/>
                <path d="M 112,464 L 160,464" fill="none" stroke="black"/>
                <path d="M 112,512 L 160,512" fill="none" stroke="black"/>
                <path d="M 120,576 L 384,576" fill="none" stroke="black"/>
                <path d="M 24,592 L 48,592" fill="none" stroke="black"/>
                <path d="M 472,592 L 496,592" fill="none" stroke="black"/>
                <path d="M 48,608 L 120,608" fill="none" stroke="black"/>
                <path d="M 384,608 L 456,608" fill="none" stroke="black"/>
                <path d="M 8,624 L 32,624" fill="none" stroke="black"/>
                <path d="M 456,624 L 480,624" fill="none" stroke="black"/>
                <path d="M 120,640 L 384,640" fill="none" stroke="black"/>
                <path d="M 224,32 C 215.16936,32 208,39.16936 208,48" fill="none" stroke="black"/>
                <path d="M 320,32 C 328.83064,32 336,39.16936 336,48" fill="none" stroke="black"/>
                <path d="M 224,64 C 215.16936,64 208,56.83064 208,48" fill="none" stroke="black"/>
                <path d="M 320,64 C 328.83064,64 336,56.83064 336,48" fill="none" stroke="black"/>
                <path d="M 224,128 C 215.16936,128 208,135.16936 208,144" fill="none" stroke="black"/>
                <path d="M 320,128 C 328.83064,128 336,135.16936 336,144" fill="none" stroke="black"/>
                <path d="M 224,176 C 215.16936,176 208,168.83064 208,160" fill="none" stroke="black"/>
                <path d="M 320,176 C 328.83064,176 336,168.83064 336,160" fill="none" stroke="black"/>
                <path d="M 224,240 C 215.16936,240 208,247.16936 208,256" fill="none" stroke="black"/>
                <path d="M 320,240 C 328.83064,240 336,247.16936 336,256" fill="none" stroke="black"/>
                <path d="M 224,288 C 215.16936,288 208,280.83064 208,272" fill="none" stroke="black"/>
                <path d="M 320,288 C 328.83064,288 336,280.83064 336,272" fill="none" stroke="black"/>
                <path d="M 120,352 C 111.16936,352 104,359.16936 104,368" fill="none" stroke="black"/>
                <path d="M 216,352 C 224.83064,352 232,359.16936 232,368" fill="none" stroke="black"/>
                <path d="M 312,352 C 303.16936,352 296,359.16936 296,368" fill="none" stroke="black"/>
                <path d="M 408,352 C 416.83064,352 424,359.16936 424,368" fill="none" stroke="black"/>
                <path d="M 120,400 C 111.16936,400 104,392.83064 104,384" fill="none" stroke="black"/>
                <path d="M 216,400 C 224.83064,400 232,392.83064 232,384" fill="none" stroke="black"/>
                <path d="M 312,400 C 303.16936,400 296,392.83064 296,384" fill="none" stroke="black"/>
                <path d="M 408,400 C 416.83064,400 424,392.83064 424,384" fill="none" stroke="black"/>
                <path d="M 112,464 C 103.16936,464 96,471.16936 96,480" fill="none" stroke="black"/>
                <path d="M 160,464 C 168.83064,464 176,471.16936 176,480" fill="none" stroke="black"/>
                <path d="M 112,512 C 103.16936,512 96,504.83064 96,496" fill="none" stroke="black"/>
                <path d="M 160,512 C 168.83064,512 176,504.83064 176,496" fill="none" stroke="black"/>
                <path d="M 24,592 C 15.16936,592 8,599.16936 8,608" fill="none" stroke="black"/>
                <path d="M 472,592 C 463.16936,592 456,599.16936 456,608" fill="none" stroke="black"/>
                <path d="M 32,624 C 40.83064,624 48,616.83064 48,608" fill="none" stroke="black"/>
                <path d="M 480,624 C 488.83064,624 496,616.83064 496,608" fill="none" stroke="black"/>
                <g class="text">
                  <text x="268" y="52">Customer</text>
                  <text x="108" y="84">Customer</text>
                  <text x="176" y="84">Service</text>
                  <text x="236" y="84">Models</text>
                  <text x="72" y="100">ietf-l2vpn-svc,</text>
                  <text x="200" y="100">ietf-l3vpn-svc,</text>
                  <text x="392" y="100">ietf-network-slice-service,</text>
                  <text x="100" y="116">ietf-ac-svc,</text>
                  <text x="208" y="116">ietf-ac-glue,</text>
                  <text x="296" y="116">and</text>
                  <text x="376" y="116">ietf-bearer-svc</text>
                  <text x="272" y="148">Service</text>
                  <text x="272" y="164">Orchestration</text>
                  <text x="112" y="196">Network</text>
                  <text x="172" y="196">Models</text>
                  <text x="72" y="212">ietf-l2vpn-ntw,</text>
                  <text x="200" y="212">ietf-l3vpn-ntw,</text>
                  <text x="336" y="212">ietf-sap-ntw,</text>
                  <text x="448" y="212">ietf-ac-glue,</text>
                  <text x="96" y="228">and</text>
                  <text x="160" y="228">ietf-ac-ntw</text>
                  <text x="264" y="260">Network</text>
                  <text x="272" y="276">Orchestration</text>
                  <text x="56" y="308">Network</text>
                  <text x="144" y="308">Configuration</text>
                  <text x="224" y="308">Model</text>
                  <text x="164" y="372">Domain</text>
                  <text x="364" y="372">Domain</text>
                  <text x="168" y="388">Orchestration</text>
                  <text x="360" y="388">Orchestration</text>
                  <text x="36" y="420">Device</text>
                  <text x="64" y="436">Configuration</text>
                  <text x="36" y="452">Models</text>
                  <text x="132" y="484">Config</text>
                  <text x="136" y="500">Manager</text>
                  <text x="156" y="548">NETCONF/CLI.</text>
                  <text x="288" y="548">...................</text>
                  <text x="376" y="548">.</text>
                  <text x="136" y="564">|</text>
                  <text x="84" y="596">Bearer</text>
                  <text x="420" y="596">Bearer</text>
                  <text x="28" y="612">CE#1</text>
                  <text x="248" y="612">Network</text>
                  <text x="476" y="612">CE#2</text>
                  <text x="28" y="660">Site</text>
                  <text x="56" y="660">A</text>
                  <text x="476" y="660">Site</text>
                  <text x="504" y="660">B</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
                           .-------------.
                          |   Customer    |
                           '------+------'
          Customer Service Models |
  ietf-l2vpn-svc, ietf-l3vpn-svc, | ietf-network-slice-service,
       ietf-ac-svc, ietf-ac-glue, | and ietf-bearer-svc
                           .------+------.
                          |    Service    |
                          | Orchestration |
                           '------+------'
           Network Models         |
  ietf-l2vpn-ntw, ietf-l3vpn-ntw, | ietf-sap-ntw, ietf-ac-glue,
           and ietf-ac-ntw        |
                           .------+------.
                          |   Network     |
                          | Orchestration |
                           '------+------'
    Network Configuration Model   |
                      .-----------+-----------.
                      |                       |
              .-------+-----.         .-------+-----.
             |    Domain     |       |     Domain    |
             | Orchestration |       | Orchestration |
              '--+--------+-'         '-------+-----'
  Device         |        |                   |
  Configuration  |        |                   |
  Models         |        |                   |
             .---+---.    |                   |
            | Config  |   |                   |
            | Manager |   |                   |
             '---+---'    |                   |
                 |        |                   |
              NETCONF/CLI.......................
                 |        |                   |
               .--------------------------------.
  .---. Bearer |                                | Bearer  .---.
 |CE#1+--------+            Network             +--------+CE#2|
 '---'         |                                |        '---'
               '--------------------------------'
  Site A                                                  Site B
]]></artwork>
          </artset>
        </figure>
        <t>Similar to <xref target="RFC9408"/>, the "ietf-ac-ntw" module can be used for both User-to-Network Interface (UNI) and
Network-to-Network Interface (NNI). For example, all the ACs shown in <xref target="fig-inter-pn"/> have a 'role' set
to 'ietf-sap-ntw:nni'. Typically, ASBRs of each network are directly
connected to ASBRs of a neighboring network via one or multiple links (bearers). ASBRs of "Network#1" behave as a PE and treat the other adjacent ASBRs as if it were a CE.</t>
        <figure anchor="fig-inter-pn">
          <name>An Example of the Network AC Model Usage Between Provider Networks</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="240" width="376" viewBox="0 0 376 240" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,224" fill="none" stroke="black"/>
                <path d="M 176,32 L 176,224" fill="none" stroke="black"/>
                <path d="M 256,32 L 256,112" fill="none" stroke="black"/>
                <path d="M 256,144 L 256,224" fill="none" stroke="black"/>
                <path d="M 368,32 L 368,112" fill="none" stroke="black"/>
                <path d="M 368,144 L 368,224" fill="none" stroke="black"/>
                <path d="M 8,32 L 176,32" fill="none" stroke="black"/>
                <path d="M 256,32 L 368,32" fill="none" stroke="black"/>
                <path d="M 176,48 L 200,48" fill="none" stroke="black"/>
                <path d="M 224,48 L 256,48" fill="none" stroke="black"/>
                <path d="M 176,80 L 200,80" fill="none" stroke="black"/>
                <path d="M 224,80 L 256,80" fill="none" stroke="black"/>
                <path d="M 256,112 L 368,112" fill="none" stroke="black"/>
                <path d="M 256,144 L 368,144" fill="none" stroke="black"/>
                <path d="M 176,192 L 200,192" fill="none" stroke="black"/>
                <path d="M 224,192 L 256,192" fill="none" stroke="black"/>
                <path d="M 8,224 L 176,224" fill="none" stroke="black"/>
                <path d="M 256,224 L 368,224" fill="none" stroke="black"/>
                <g class="text">
                  <text x="212" y="52">AC</text>
                  <text x="212" y="84">AC</text>
                  <text x="312" y="84">Network#2</text>
                  <text x="88" y="116">Network#1</text>
                  <text x="212" y="196">AC</text>
                  <text x="312" y="196">Network#3</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
.--------------------.         .-------------.
|                    +---AC----+             |
|                    |         |             |
|                    +---AC----+  Network#2  |
|                    |         |             |
|     Network#1      |         '-------------'
|                    |
|                    |         .-------------.
|                    |         |             |
|                    |         |             |
|                    +---AC----+  Network#3  |
|                    |         |             |
'--------------------'         '-------------'
]]></artwork>
          </artset>
        </figure>
      </section>
    </section>
    <section anchor="description-of-the-attachment-circuit-yang-module">
      <name>Description of the Attachment Circuit YANG Module</name>
      <t>The full tree diagram of the "ietf-ac-ntw" module is provided in <xref target="AC-Ntw-Tree"/>. Subtrees are provided in the following subsections
for the reader's convenience.</t>
      <section anchor="overall-structure-of-the-module">
        <name>Overall Structure of the Module</name>
        <t>The overall tree structure of the "ietf-ac-ntw" module is shown in <xref target="o-ntw-tree"/>.</t>
        <figure anchor="o-ntw-tree">
          <name>Overall Tree Structure</name>
          <artwork><![CDATA[
          <sourcecode type="yangtree"><![CDATA[
  augment /nw:networks/nw:network:
    +--rw specific-provisioning-profiles
    |  ...
    +--rw ac-profile* [name]
       ...
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       +--rw svc-ref?             ac-svc:attachment-circuit-reference
       +--rw profile* [ac-profile-ref]
       |  +--rw ac-profile-ref    leafref
       |  +--rw network-ref?      -> /nw:networks/network/network-id
       +--rw parent-ref
       |  +--rw ac-ref?        leafref
       |  +--rw node-ref?      leafref
       |  +--rw network-ref?   -> /nw:networks/network/network-id
       +--ro child-ref
       |  +--ro ac-ref*        leafref
       |  +--ro node-ref?      leafref
       |  +--ro network-ref?   -> /nw:networks/network/network-id
       +--rw peer-sap-id*         string
       +--rw group* [group-id]
       |  +--rw group-id      string
       |  +--rw precedence?   identityref
       +--rw status
       |  +--rw admin-status
       |  |  +--rw status?        identityref
       |  |  +--ro last-change?   yang:date-and-time
       |  +--ro oper-status
       |     +--ro status?        identityref
       |     +--ro last-change?   yang:date-and-time
       +--rw description?         string
       +--rw l2-connection  {ac-common:layer2-ac}?
       |  ...
       +--rw ip-connection  {ac-common:layer3-ac}?
       |  ...
       +--rw routing-protocols
       |  ...
       +--rw oam
       |  ...
       +--rw security
       |  ...
       +--rw service
          ...
    augment /nw:networks/nw:network/nw:node/sap:service/sap:sap:
      +--rw ac* [ac-ref]
         +--rw ac-ref         leafref
         +--rw node-ref?      leafref
         +--rw network-ref?   -> /nw:networks/network/network-id
]]></artwork>
]]></sourcecode>
        </figure>
        <t>A node can host one or more SAPs. Per <xref target="RFC9408"/>, a SAP is an abstraction of the network
reference point (the PE side of an AC, in the context of this document) where network services can be delivered and/or are delivered to customers. Each SAP terminates one or multiple ACs. Each In turn, each AC in turn may be terminated by one or more peer SAPs ('peer-sap'). In order to expose such AC/SAP binding information, the SAP model <xref target="RFC9408"/> is augmented with the required AC-related information.</t>
        <t>Unlike the AC service model <xref target="I-D.ietf-opsawg-teas-attachment-circuit"/>, target="RFC9834"/>, an AC is uniquely identified by a name within the scope of a node, not a network. A textual description of the AC may be provided ('description').</t>
        <t>Also, in order to ease the correlation between the AC exposed at the service layer and the AC that is actually provisioned in the network operation, a reference to the AC exposed to the customer ('svc-ref') is stored in the "ietf-ac-ntw" module.</t>
        <t>ACs that are terminated by a SAP are listed in the 'ac' container under '/nw:networks/nw:network/nw:node/sap:service/sap:sap'. A controller may indicate a filter based on the service type (e.g., Network Slice or L3VPN) to retrieve the list of available SAPs, and thus ACs, for that service.</t>
        <t>In order to factorize common data that is provisioned for a group of ACs, a set of profiles (<xref target="sec-profiles"/>) can be defined at the network level, level and then called under the node level. The information contained in a profile is thus inherited, unless the corresponding data node is refined at the AC level. In such a case, the value provided at the AC level takes precedence over the global one.</t>
        <t>In contexts where the same AC is terminated by multiple peer SAPs (e.g., an AC with multiple CEs) but a subset of them have specific information, the module allows operators to:</t>
        <ul spacing="normal">
          <li>
            <t>Define a parent AC that may list all these CEs as peer SAPs.</t>
          </li>
          <li>
            <t>Create individual ACs that are bound to the parent AC using 'parent-ref'.</t>
          </li>
          <li>
            <t>Indicate for each individual AC one or a subset of the CEs as peer SAPs. All these individual ACs will inherit the properties of the parent AC.</t>
          </li>
        </ul>
        <t>Whenever a parent AC is deleted, then all child ACs of that AC <bcp14>MUST</bcp14> be deleted. Child ACs are referenced using 'child-ref'.</t>
        <t>An AC may belong to one or multiple groups <xref target="RFC9181"/>. For example, the 'group-id' is used to associate redundancy or protection constraints with ACs.</t>
        <t>The status of an AC can be tracked using 'status'. 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>An AC can be characterized using Layer 2 connectivity (<xref target="sec-l2"/>), Layer 3 connectivity (<xref target="sec-l3"/>), routing protocols (<xref target="sec-rtg"/>), Operations, Administration, and Maintenance (OAM) (<xref target="sec-oam"/>), security (<xref target="sec-sec"/>), and service (<xref target="sec-svc"/>) considerations. Features are used to tag conditional protions portions to accomodate accommodate various deployments (support of layer Layer 2 ACs, Layer 3 ACs, IPv4, IPv6, routing protocols, BFD, Bidirectional Forwarding Detection (BFD), etc.).</t>
      </section>
      <section anchor="references">
        <name>References</name>
        <t>The AC network module defines a set of groupings depicted in <xref target="references-tree"/> for referencing purposes. These references are used within or outside the AC network module. The use of such groupings is consistent with the design in <xref target="RFC8345"/>.</t>
        <figure anchor="references-tree">
          <name>References Groupings</name>
          <artwork><![CDATA[
          <sourcecode type="yangtree"><![CDATA[
  grouping attachment-circuit-reference:
    +-- ac-ref?        leafref
    +-- node-ref?      leafref
    +-- network-ref?   -> /nw:networks/network/network-id
  grouping attachment-circuit-references:
    +-- ac-ref*        leafref
    +-- node-ref?      leafref
    +-- network-ref?   -> /nw:networks/network/network-id
  grouping ac-profile-reference:
    +-- ac-profile-ref?   leafref
    +-- network-ref?      -> /nw:networks/network/network-id
  grouping encryption-profile-reference:
    +-- encryption-profile-ref?   leafref
    +-- network-ref?              -> /nw:networks/network/network-id
  grouping qos-profile-reference:
    +-- qos-profile-ref?   leafref
    +-- network-ref?       -> /nw:networks/network/network-id
  grouping failure-detection-profile-reference:
    +-- failure-detection-profile-ref?   leafref
    +-- network-ref?       -> /nw:networks/network/network-id
  grouping forwarding-profile-reference:
    +-- forwarding-profile-ref?   leafref
    +-- network-ref?              -> /nw:networks/network/network-id
  grouping routing-profile-reference:
    +-- routing-profile-ref?   leafref
    +-- network-ref?           -> /nw:networks/network/network-id
]]></artwork>
]]></sourcecode>
        </figure>
        <t>The groupings shown in <xref target="references-tree"/> contain the information necessary to reference:</t>
        <ul spacing="normal">
          <li>
            <t>an attachment circuit that is terminated by a specific node in a given network,</t>
          </li>
          <li>
            <t>an attachment circuit profile of a specific network (<xref target="sec-profiles"/>), and</t>
          </li>
          <li>
            <t>specific provisioning profiles that are bound to a specific network (<xref target="sec-profiles"/>).</t>
          </li>
        </ul>
      </section>
      <section anchor="sec-profiles">
        <name>Provisioning Profiles</name>
        <t>The AC and specific provisioning profiles tree structure is shown in <xref target="profiles-tree"/>.</t>
        <figure anchor="profiles-tree">
          <name>Profiles Tree Structure</name>
          <artwork><![CDATA[
          <sourcecode type="yangtree"><![CDATA[
  augment /nw:networks/nw:network:
    +--rw specific-provisioning-profiles
    |  +--rw valid-provider-identifiers
    |     +--rw encryption-profile-identifier* [id]
    |     |  +--rw id    string
    |     +--rw qos-profile-identifier* [id]
    |     |  +--rw id    string
    |     +--rw failure-detection-profile-identifier* [id]
    |     |  +--rw id    string
    |     +--rw forwarding-profile-identifier* [id]
    |     |  +--rw id    string
    |     +--rw routing-profile-identifier* [id]
    |        +--rw id    string
    +--rw ac-profile* [name]
       +--rw name                 string
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id      string
       |     +--rw type?   identityref
       |     +--rw bgp {vpn-common:rtg-bgp}?
       |     |  +--rw peer-groups
       |     |     +--rw peer-group* [name]
       |     |        +--rw name                      string
       |     |        +--rw description?              string
       |     |        +--rw apply-policy
       |     |        |  +--rw import-policy*           leafref
       |     |        |  +--rw default-import-policy?
       |     |        |  |       default-policy-type
       |     |        |  +--rw export-policy*           leafref
       |     |        |  +--rw default-export-policy?
       |     |        |          default-policy-type
       |     |        +--rw local-as?                 inet:as-number
       |     |        +--rw peer-as                   inet:as-number
       |     |        +--rw address-family?           identityref
       |     |        +--rw role?                     identityref
       |     |        +--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 enabled?          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 ospf {vpn-common:rtg-ospf}?
       |     |  +--rw address-family?   identityref
       |     |  +--rw area-id           yang:dotted-quad
       |     |  +--rw metric?           uint16
       |     |  +--rw max-lsa?          uint32
       |     |  +--rw passive?          boolean
       |     +--rw isis {vpn-common:rtg-isis}?
       |     |  +--rw address-family?   identityref
       |     |  +--rw area-address      area-address
       |     |  +--rw level?            identityref
       |     |  +--rw metric?           uint32
       |     |  +--rw passive?          boolean
       |     +--rw rip {vpn-common:rtg-rip}?
       |     |  +--rw address-family?   identityref
       |     |  +--rw timers
       |     |  |  +--rw update-interval?     uint16
       |     |  |  +--rw invalid-interval?    uint16
       |     |  |  +--rw holddown-interval?   uint16
       |     |  |  +--rw flush-interval?      uint16
       |     |  +--rw default-metric?   uint8
       |     +--rw vrrp {vpn-common:rtg-vrrp}?
       |        +--rw address-family?   identityref
       |        +--rw ping-reply?       boolean
       +--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
]]></artwork>
]]></sourcecode>
        </figure>
        <t>Similar to <xref target="RFC9182"/> and <xref target="RFC9291"/>, the exact definition of the specific provisioning profiles is local to each service provider. The model only includes an identifier for these profiles in order to ease identifying and binding local policies when building an AC. As shown in <xref target="profiles-tree"/>, the following identifiers can be included:</t>
        <dl>
          <dt>'encryption-profile-identifier':</dt>
          <dd>
            <t>An encryption profile refers to a set of policies related to the encryption schemes and setup that can be applied on the AC. See also <xref target="sec-sec"/>.</t>
          </dd>
          <dt>'qos-profile-identifier':</dt>
          <dd>
            <t>A Quality of Service (QoS) profile refers to a set of policies such as classification, marking, and actions (e.g., <xref target="RFC3644"/>). See also <xref target="sec-svc"/>.</t>
          </dd>
          <dt>'failure-detection-profile-identifier':</dt>
          <dd>
            <t>A failure detection profile refers to a set of failure detection policies such as Bidirectional Forwarding Detection (BFD) policies <xref target="RFC5880"/> that can be invoked when building an AC. Such a profile can be, for example, referenced in static routes (<xref target="sec-static-rtg"/>) or under the OAM level (<xref target="sec-oam"/>). The use of this profile is similar to the detailed examples depicted in Appendices A.11.3 <xref section="A.11.3" sectionFormat="bare" target="RFC9834"/> and A.12 <xref section="A.12" sectionFormat="bare" target="RFC9834"/> of <xref target="I-D.ietf-opsawg-teas-attachment-circuit"/>.</t> target="RFC9834"/>.</t>
          </dd>
          <dt>'forwarding-profile-identifier':</dt>
          <dd>
            <t>A forwarding profile refers to the policies that apply to the forwarding of packets conveyed over an AC. Such policies may consist of, for example, applying Access Control Lists (ACLs) as in <xref target="sec-svc"/>.</t>
          </dd>
          <dt>'routing-profile-identifier':</dt>
          <dd>
            <t>A routing profile refers to a set of routing policies that will be invoked (e.g., BGP policies) for an AC. Refer to <xref target="sec-rtg"/>.</t>
          </dd>
        </dl>
        <t>The 'ac-profile' defines parameters that can be factorized among a set of ACs. Each profile is identified by a 'name' that is unique in a network. Some of the data nodes can be adjusted at the node level. These adjusted values take precedence over the values in the profile.</t>
      </section>
      <section anchor="sec-l2">
        <name>L2 Connection</name>
        <t>The 'l2-connection' container is used to manage the Layer 2 properties of an AC (mainly, the PE side of an AC). The Layer 2 connection tree structure is shown in <xref target="l2-tree"/>.</t>
        <figure anchor="l2-tree">
          <name>Layer 2 Connection Tree Structure</name>
          <artwork><![CDATA[
          <sourcecode type="yangtree"><![CDATA[
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       + ...
       +--rw l2-connection  {ac-common:layer2-ac}?
       |  +--rw encapsulation
       |  |  +--rw encap-type?        identityref
       |  |  +--rw dot1q
       |  |  |  +--rw tag-type?         identityref
       |  |  |  +--rw cvlan-id?         uint16
       |  |  |  +--rw tag-operations
       |  |  |     +--rw (op-choice)?
       |  |  |     |  +--:(pop)
       |  |  |     |  |  +--rw pop?         empty
       |  |  |     |  +--:(push)
       |  |  |     |  |  +--rw push?        empty
       |  |  |     |  +--:(translate)
       |  |  |     |     +--rw translate?   empty
       |  |  |     +--rw tag-1?             dot1q-types:vlanid
       |  |  |     +--rw tag-1-type?
       |  |  |     |       dot1q-types:dot1q-tag-type
       |  |  |     +--rw tag-2?             dot1q-types:vlanid
       |  |  |     +--rw tag-2-type?
       |  |  |             dot1q-types:dot1q-tag-type
       |  |  +--rw priority-tagged
       |  |  |  +--rw tag-type?   identityref
       |  |  +--rw qinq
       |  |     +--rw tag-type?         identityref
       |  |     +--rw svlan-id?         uint16
       |  |     +--rw cvlan-id?         uint16
       |  |     +--rw tag-operations
       |  |        +--rw (op-choice)?
       |  |        |  +--:(pop)
       |  |        |  |  +--rw pop?         uint8
       |  |        |  +--:(push)
       |  |        |  |  +--rw push?        empty
       |  |        |  +--:(translate)
       |  |        |     +--rw translate?   uint8
       |  |        +--rw tag-1?             dot1q-types:vlanid
       |  |        +--rw tag-1-type?
       |  |        |       dot1q-types:dot1q-tag-type
       |  |        +--rw tag-2?             dot1q-types:vlanid
       |  |        +--rw tag-2-type?
       |  |                dot1q-types:dot1q-tag-type
       |  +--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
       |  |       {ac-common:server-assigned-reference}?
       |  +--rw lag-interface {vpn-common:lag-interface}?
       |     +--rw lag-interface-id?   string
       |     +--rw member-link-list
       |        +--rw member-link* [name]
       |           +--rw name    string
       +--rw ip-connection  {ac-common:layer3-ac}?
       |  ...
       +--rw routing-protocols
       |  ...
       +--rw oam
       |  ...
       +--rw security
       |  ...
       +--rw service
          ...
]]></artwork>
]]></sourcecode>
        </figure>
        <t>The 'encapsulation' container specifies the Layer 2 encapsulation to use (if any) and allows the configuration of the relevant tags. Also, the model supports tag manipulation operations (e.g., tag rewrite).</t>
        <t>The 'l2-tunnel-service' container is used to specify the required parameters to set a Layer 2 tunneling service (e.g., a Virtual Private LAN Service (VPLS), a Virtual eXtensible Local Area Network (VXLAN), or a pseudowire (<xref section="6.1" sectionFormat="of" target="RFC8077"/>)). 'l2vpn-id' is used to identify a L2VPN service that is associated with an Integrated Routing and Bridging (IRB) interface.</t>
        <t>Specific Layer 2 sub-interfaces may be required to be configured in some implementations/deployments. Such a Layer-2-specific interface can be included in 'l2-termination-point'.</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 reference to the bearer used by this AC is maintained using 'bearer-reference'.</t>
      </section>
      <section anchor="sec-l3">
        <name>IP Connection</name>
        <t>This 'ip-connection' container is used to group Layer 3 connectivity information, particularly the IP addressing information, of an AC.</t>
        <t>The  Layer 3 connection tree structure is shown in <xref target="l3-tree"/>.</t>
        <figure anchor="l3-tree">
          <name>IP Connection Tree Structure</name>
          <artwork><![CDATA[
          <sourcecode type="yangtree"><![CDATA[
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       + ...
       +--rw l2-connection  {ac-common:layer2-ac}?
       |  ...
       +--rw ip-connection  {ac-common:layer3-ac}?
       |  +--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)?
       |  |     +--:(dynamic)
       |  |     |  +--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
       |  |     |  +--rw (provider-dhcp)?
       |  |     |  |  +--:(dhcp-service-type)
       |  |     |  |  |  +--rw dhcp-service-type?
       |  |     |  |  |          enumeration
       |  |     |  |  +--:(service-type)
       |  |     |  |     +--rw (service-type)?
       |  |     |  |        +--:(relay)
       |  |     |  |           +--rw server-ip-address*
       |  |     |  |                   inet:ipv4-address
       |  |     |  +--rw (dhcp-relay)?
       |  |     |     +--:(customer-dhcp-servers)
       |  |     |        +--rw customer-dhcp-servers
       |  |     |           +--rw server-ip-address*
       |  |     |                   inet:ipv4-address
       |  |     +--:(static-addresses)
       |  |        +--rw address* [address-id]
       |  |           +--rw address-id                       string
       |  |           +--rw customer-address?
       |  |           |       inet:ipv4-address
       |  |           +--rw failure-detection-profile-ref?   leafref
       |  |           +--rw network-ref?
       |  |                   -> /nw:networks/network/network-id
       |  +--rw ipv6 {vpn-common:ipv6}?
       |     +--rw local-address?
       |     |       inet:ipv6-address
       |     +--rw prefix-length?                           uint8
       |     +--rw address-allocation-type?
       |     |       identityref
       |     +--rw (allocation-type)?
       |        +--:(dynamic)
       |        |  +--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
       |        |  +--rw (provider-dhcp)?
       |        |  |  +--:(dhcp-service-type)
       |        |  |  |  +--rw dhcp-service-type?
       |        |  |  |          enumeration
       |        |  |  +--:(service-type)
       |        |  |     +--rw (service-type)?
       |        |  |        +--:(relay)
       |        |  |           +--rw server-ip-address*
       |        |  |                   inet:ipv6-address
       |        |  +--rw (dhcp-relay)?
       |        |     +--:(customer-dhcp-servers)
       |        |        +--rw customer-dhcp-servers
       |        |           +--rw server-ip-address*
       |        |                   inet:ipv6-address
       |        +--:(static-addresses)
       |           +--rw address* [address-id]
       |              +--rw address-id                       string
       |              +--rw customer-address?
       |              |       inet:ipv6-address
       |              +--rw failure-detection-profile-ref?   leafref
       |              +--rw network-ref?
       |                      -> /nw:networks/network/network-id
       +--rw routing-protocols
       |  ...
       +--rw oam
       |  ...
       +--rw security
       |  ...
       +--rw service
          ...
]]></artwork>
]]></sourcecode>
        </figure>
        <t>A distinct Layer 3 interface other than the interface indicated under the 'l2-connection' container may be needed to terminate the Layer 3 connectivity. 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>This container can include IPv4, IPv6, or both if dual-stack is enabled. 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, Stateless Address Autoconfiguration (SLAAC) <xref target="RFC4862"/> can be used.</t>
        <t>For both IPv4 and IPv6, 'address-allocation-type' is used to indicate the IP address allocation mode to activate for an AC. The allocated address represents the PE interface address configuration. When 'address-allocation-type' is set to 'provider-dhcp', DHCP assignments can be made locally or by an external DHCP server. Such behavior is controlled by setting 'dhcp-service-type'.</t>
        <t>For IPv6, if 'address-allocation-type' is set to 'slaac', the Prefix Information option of Router Advertisements that will be issued for SLAAC 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>In some deployment contexts (e.g., network merging), multiple IP subnets may be used in a transition period. For such deployments, multiple ACs (typically, two) with overlapping information may be maintained during a transition period. The correlation between these ACs may rely upon the same 'svc-ref'.</t>
      </section>
      <section anchor="sec-rtg">
        <name>Routing</name>
        <t>The overall routing subtree structure is shown in <xref target="rtg-tree"/>.</t>
        <figure anchor="rtg-tree">
          <name>Routing Tree Structure</name>
          <artwork><![CDATA[
          <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw
  augment /nw:networks/nw:network:
    +--rw ac-profile* [name]
       +--rw name                 string
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id      string
       |     +--rw type?   identityref
       |     +--rw bgp  {vpn-common:rtg-bgp}?
       |     |  ...
       |     +--rw ospf  {vpn-common:rtg-ospf}?
       |     |  ...
       |     +--rw isis  {vpn-common:rtg-isis}?
       |     |  ...
       |     +--rw rip  {vpn-common:rtg-rip}?
       |     |  ...
       |     +--rw vrrp  {vpn-common:rtg-vrrp}?
       |        ...
       +--rw oam
          ...
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       ...
       +--rw l2-connection  {ac-common:layer2-ac}?
       |  ...
       +--rw ip-connection  {ac-common:layer3-ac}?
       |  ...
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id                  string
       |     +--rw type?               identityref
       |     +--rw routing-profile* [routing-profile-ref]
       |     |  +--rw routing-profile-ref    leafref
       |     |  +--rw network-ref?
       |     |  |       -> /nw:networks/network/network-id
       |     |  +--rw type?                  identityref
       |     +--rw static
       |     |  ...
       |     +--rw bgp  {vpn-common:rtg-bgp}?
       |     |  ...
       |     +--rw ospf  {vpn-common:rtg-ospf}?
       |     |  ...
       |     +--rw isis  {vpn-common:rtg-isis}?
       |     |  ...
       |     +--rw rip  {vpn-common:rtg-rip}?
       |     |  ...
       |     +--rw vrrp  {vpn-common:rtg-vrrp}?
       |        ...
       +--rw oam
       |  ...
       +--rw security
       |  ...
       +--rw service
          ...
]]></artwork>
]]></sourcecode>
        </figure>
        <t>Multiple routing instances ('routing-protocol') can be defined, each uniquely identified
by an 'id'. Specifically, each instance is uniquely identified to accommodate scenarios
where multiple instances of the same routing protocol have to be configured on the same AC.</t>
        <t>The type of a routing instance is indicated in 'type'.
The values of this attribute are those defined in <xref target="RFC9181"/> (the
'routing-protocol-type' identity). Specific data nodes are then provided
as a function of the 'type'. See more details in the following subsections.</t>
        <t>One or multiple routing profiles ('routing-profile') can be provided for
a given routing instance.</t>
        <section anchor="sec-static-rtg">
          <name>Static Routing</name>
          <t>The static routing subtree structure is shown in <xref target="static-tree"/>.</t>
          <figure anchor="static-tree">
            <name>Static Routing Tree Structure</name>
            <artwork><![CDATA[
            <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw
          ...
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       ...
       +--rw l2-connection  {ac-common:layer2-ac}?
       |  ...
       +--rw ip-connection  {ac-common:layer3-ac}?
       |  ...
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id                 string
       |     +--rw type?              identityref
       |     +--rw routing-profile* [routing-profile-ref]
       |     |  +--rw routing-profile-ref    leafref
       |     |  +--rw network-ref?
       |     |  |       -> /nw:networks/network/network-id
       |     |  +--rw type?                  identityref
       |     +--rw static
       |     |  +--rw cascaded-lan-prefixes
       |     |     +--rw ipv4-lan-prefix* [lan next-hop]
       |     |     |       {vpn-common:ipv4}?
       |     |     |  +--rw lan           inet:ipv4-prefix
       |     |     |  +--rw lan-tag?      string
       |     |     |  +--rw next-hop      union
       |     |     |  +--rw metric?       uint32
       |     |     |  +--rw bfd {vpn-common:bfd}?
       |     |     |  |  +--rw enabled?
       |     |     |  |  |       boolean
       |     |     |  |  +--rw failure-detection-profile-ref?
       |     |     |  |  |       leafref
       |     |     |  |  +--rw network-ref?
       |     |     |  |          -> /nw:networks/network/network-id
       |     |     |  +--rw preference?   uint32
       |     |     |  +--rw status
       |     |     |     +--rw admin-status
       |     |     |     |  +--rw status?        identityref
       |     |     |     |  +--ro last-change?   yang:date-and-time
       |     |     |     +--ro oper-status
       |     |     |        +--ro status?        identityref
       |     |     |        +--ro last-change?   yang:date-and-time
       |     |     +--rw ipv6-lan-prefix* [lan next-hop]
       |     |             {vpn-common:ipv6}?
       |     |        +--rw lan           inet:ipv6-prefix
       |     |        +--rw lan-tag?      string
       |     |        +--rw next-hop      union
       |     |        +--rw metric?       uint32
       |     |        +--rw bfd {vpn-common:bfd}?
       |     |        |  +--rw enabled?
       |     |        |  |       boolean
       |     |        |  +--rw failure-detection-profile-ref?
       |     |        |  |       leafref
       |     |        |  +--rw network-ref?
       |     |        |          -> /nw:networks/network/network-id
       |     |        +--rw preference?   uint32
       |     |        +--rw status
       |     |           +--rw admin-status
       |     |           |  +--rw status?        identityref
       |     |           |  +--ro last-change?   yang:date-and-time
       |     |           +--ro oper-status
       |     |              +--ro status?        identityref
       |     |              +--ro last-change?   yang:date-and-time
       |     +--rw bgp  {vpn-common:rtg-bgp}?
       |     |  ...
       |     +--rw ospf  {vpn-common:rtg-ospf}?
       |     |  ...
       |     +--rw isis  {vpn-common:rtg-isis}?
       |     |  ...
       |     +--rw rip  {vpn-common:rtg-rip}?
       |     |  ...
       |     +--rw vrrp  {vpn-common:rtg-vrrp}?
       |        ...
       +--rw oam
       |  ...
       +--rw security
       |  ...
       +--rw service
          ...
]]></artwork>
]]></sourcecode>
          </figure>
          <t>The following data nodes can be defined for a given IP prefix:</t>
          <dl>
          <dl spacing="normal" newline="false">
            <dt>'lan-tag':</dt>
            <dd>
              <t>Indicates a local tag (e.g., "myfavorite-lan") 'myfavorite-lan') that is used
              to enforce local policies.</t>
            </dd>
            <dt>'next-hop':</dt>
            <dd>
              <t>Indicates the next hop to be used for the static route.</t>
            </dd>
            <dt/>
            <dd>
              <t>It can be identified by an IP address, a predefined next-hop
              type (e.g., 'discard' or 'local-link'), etc.</t>
            </dd>
            <dt>'bfd':</dt>
            <dd>
              <t>Indicates whether BFD is enabled or disabled for this static
              route entry. A BFD profile may also be provided.</t>
            </dd>
            <dt>'metric':</dt>
            <dd>
              <t>Indicates the metric associated with the static route
              entry. This metric is used when the route is exported into an
              IGP.</t>
            </dd>
            <dt>'preference':</dt>
            <dd>
              <t>Indicates the preference associated with the static route entry.</t>
            </dd>
            <dt/>
            <dd>
              <t>This preference is used to select a preferred route among routes to the same destination prefix.</t>
            </dd>
            <dt>'status':</dt>
            <dd>
              <t>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>
            </dd>
          </dl>
        </section>
        <section anchor="sec-bgp-rtg">
          <name>BGP</name>
          <t>The BGP routing subtree structure is shown in <xref target="bgp-tree"/>.</t>
          <figure anchor="bgp-tree">
            <name>BGP Routing Tree Structure</name>
            <artwork><![CDATA[
            <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw
  augment /nw:networks/nw:network:
    +--rw ac-profile* [name]
       +--rw name                 string
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id      string
       |     +--rw type?   identityref
       |     +--rw bgp  {vpn-common:rtg-bgp}?
       |     |  +--rw peer-groups
       |     |     +--rw peer-group* [name]
       |     |        +--rw name                      string
       |     |        +--rw description?              string
       |     |        +--rw apply-policy
       |     |        |  +--rw import-policy*           leafref
       |     |        |  +--rw default-import-policy?
       |     |        |  |       default-policy-type
       |     |        |  +--rw export-policy*           leafref
       |     |        |  +--rw default-export-policy?
       |     |        |          default-policy-type
       |     |        +--rw local-as?                 inet:as-number
       |     |        +--rw peer-as                   inet:as-number
       |     |        +--rw address-family?           identityref
       |     |        +--rw role?                     identityref
       |     |        +--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 enabled?          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 ospf  {vpn-common:rtg-ospf}?
       |     |  ...
       |     +--rw isis  {vpn-common:rtg-isis}?
       |     |  ...
       |     +--rw rip  {vpn-common:rtg-rip}?
       |     |  ...
       |     +--rw vrrp  {vpn-common:rtg-vrrp}?
       |        ...
       +--rw oam
          ...
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       ...
       +--rw l2-connection  {ac-common:layer2-ac}?
       |  ...
       +--rw ip-connection  {ac-common:layer3-ac}?
       |  ...
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id                  string
       |     +--rw type?               identityref
       |     +--rw routing-profile* [routing-profile-ref]
       |     |  +--rw routing-profile-ref    leafref
       |     |  +--rw network-ref?
       |     |  |       -> /nw:networks/network/network-id
       |     |  +--rw type?                  identityref
       |     +--rw static
       |     |  ...
       |     +--rw bgp {vpn-common:rtg-bgp}?
       |     |  +--rw peer-groups
       |     |  |  +--rw peer-group* [name]
       |     |  |     +--rw name                      string
       |     |  |     +--rw local-address?            union
       |     |  |     +--rw description?              string
       |     |  |     +--rw apply-policy
       |     |  |     |  +--rw import-policy*           leafref
       |     |  |     |  +--rw default-import-policy?
       |     |  |     |  |       default-policy-type
       |     |  |     |  +--rw export-policy*           leafref
       |     |  |     |  +--rw default-export-policy?
       |     |  |     |          default-policy-type
       |     |  |     +--rw local-as?                 inet:as-number
       |     |  |     +--rw peer-as                   inet:as-number
       |     |  |     +--rw address-family?           identityref
       |     |  |     +--rw role?                     identityref
       |     |  |     +--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 enabled?          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 enabled?           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
       |     |  +--rw neighbor* [remote-address]
       |     |     +--rw remote-address            inet:ip-address
       |     |     +--rw local-address?            union
       |     |     +--rw peer-group?
       |     |     |       -> ../../peer-groups/peer-group/name
       |     |     +--rw description?              string
       |     |     +--rw apply-policy
       |     |     |  +--rw import-policy*           leafref
       |     |     |  +--rw default-import-policy?
       |     |     |  |       default-policy-type
       |     |     |  +--rw export-policy*           leafref
       |     |     |  +--rw default-export-policy?
       |     |     |          default-policy-type
       |     |     +--rw local-as?                 inet:as-number
       |     |     +--rw peer-as                   inet:as-number
       |     |     +--rw address-family?           identityref
       |     |     +--rw role?                     identityref
       |     |     +--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 enabled?          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 bfd {vpn-common:bfd}?
       |     |     |  +--rw enabled?                         boolean
       |     |     |  +--rw failure-detection-profile-ref?   leafref
       |     |     |  +--rw network-ref?
       |     |     |          -> /nw:networks/network/network-id
       |     |     +--rw authentication
       |     |     |  +--rw enabled?           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
       |     |     +--rw status
       |     |        +--rw admin-status
       |     |        |  +--rw status?        identityref
       |     |        |  +--ro last-change?   yang:date-and-time
       |     |        +--ro oper-status
       |     |           +--ro status?        identityref
       |     |           +--ro last-change?   yang:date-and-time
       |     +--rw ospf  {vpn-common:rtg-ospf}?
       |     |  ...
       |     +--rw isis  {vpn-common:rtg-isis}?
       |     |  ...
       |     +--rw rip  {vpn-common:rtg-rip}?
       |     |  ...
       |     +--rw vrrp  {vpn-common:rtg-vrrp}?
       |        ...
       +--rw oam
       |  ...
       +--rw security
       |  ...
       +--rw service
          ...
]]></artwork>
]]></sourcecode>
          </figure>
          <t>The following data nodes are supported for each 'peer-group':</t>
          <dl>
            <dt>'name':</dt>
            <dd>
              <t>Defines a name for the peer group.</t>
            </dd>
            <dt>'local-address':</dt>
            <dd>
              <t>Specifies an address or a reference to an interface to use
              when establishing the BGP transport session.</t>
            </dd>
            <dt>'description':</dt>
            <dd>
              <t>Includes a description of the peer group.</t>
            </dd>
            <dt>'apply-policy':</dt>
            <dd>
              <t>Lists a set of import/export policies <xref target="RFC9067"/> to apply for this group.</t>
            </dd>
            <dt>'local-as':</dt>
            <dd>
              <t>Indicates a local AS Number (ASN).</t>
            </dd>
            <dt>'peer-as':</dt>
            <dd>
              <t>Indicates the peer's ASN.</t>
            </dd>
            <dt>'address-family':</dt>
            <dd>
              <t>Indicates the address family of the peer.  It can be set to
              'ipv4', 'ipv6', or 'dual-stack'.</t>
            </dd>
            <dt/>
            <dd>
              <t>This address family might be used together with the service
              type that uses an AC (e.g., 'vpn-type' <xref target="RFC9182"/>)
              to derive the appropriate Address Family Identifiers (AFIs) /
              Subsequent Address Family Identifiers (SAFIs) that will be part
              of the derived device configurations (e.g., unicast IPv4 MPLS
              L3VPN (AFI,SAFI = 1,128) as defined in <xref section="4.3.4"
              sectionFormat="of" target="RFC4364"/>).</t>
            </dd>
            <dt>'role':</dt>
            <dd>
              <t>Specifies the BGP role in a session. Role values are taken
              from the list defined in <xref section="4" sectionFormat="of"
              target="RFC9234"/>.</t>
            </dd>
            <dt>'multihop':</dt>
            <dd>
              <t>Indicates the number of allowed IP hops to reach a BGP peer.</t>
            </dd>
            <dt>'as-override':</dt>
            <dd>
              <t>If set, this parameter indicates whether ASN override is
              enabled, i.e., replacing the ASN of the customer specified in
              the AS_PATH BGP attribute with the ASN identified in the 'local-
              as' attribute.</t>
            </dd>
            <dt>'allow-own-as':</dt>
            <dd>
              <t>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 peer.  Loops are prevented by setting
              'allow-own-as' to a maximum number of the provider's ASN
              occurrences.  By default, this parameter is set to '0' (that is,
              reject any AS_PATH attribute that includes the provider's
              ASN).</t>
            </dd>
            <dt>'prepend-global-as':</dt>
            <dd>
              <t>When distinct ASNs are configured at the node and AC levels,
              this parameter controls whether the ASN provided at the node
              level is prepended to the AS_PATH attribute.</t>
            </dd>
            <dt>'send-default-route':</dt>
            <dd>
              <t>Controls whether default routes can be advertised to the peer.</t>
            </dd>
            <dt>'site-of-origin':</dt>
            <dd>
              <t>Meant to uniquely identify the set of routes learned from a
              site via a particular AC.  It is used to prevent routing loops
              (<xref section="7" sectionFormat="of" target="RFC4364"/>).  The
              Site of Origin attribute is encoded as a Route Origin Extended
              Community.</t>
            </dd>
            <dt>'ipv6-site-of-origin':</dt>
            <dd>
              <t>Carries an IPv6 Address Specific BGP Extended Community that
              is used to indicate the Site of Origin <xref target="RFC5701"/>.
              It is used to prevent routing loops.</t>
            </dd>
            <dt>'redistribute-connected':</dt>
            <dd>
              <t>Controls whether the AC is advertised to other PEs.</t>
            </dd>
          </dl>
          <t>'bgp-max-prefix':
            <dt>'bgp-max-prefix':</dt>
	    <dd> Controls the behavior when a prefix maximum is
      reached.</t>
          <dl> reached.</dd>
            <dt>'max-prefix':</dt>
            <dd>
              <t>Indicates the maximum number of BGP prefixes allowed in a
              session for this group.  If the limit is reached, the action
              indicated in 'violate-action' will be followed.</t>
            </dd>
            <dt>'warning-threshold':</dt>
            <dd>
              <t>A warning notification is triggered when this limit is reached.</t>
            </dd>
            <dt>'violate-action':</dt>
            <dd>
              <t>Indicates which action to execute when the maximum number of
              BGP prefixes is reached.  Examples of such actions include
              sending a warning message, discarding extra paths from the peer,
              or restarting the session.</t>
            </dd>
            <dt>'restart-timer':</dt>
            <dd>
              <t>Indicates, in seconds, the time interval after which the BGP
              session will be reestablished.</t>
            </dd>
            <dt>'bgp-timers':</dt>
            <dd>
              <t>Two timers can be captured in this container: (1)
              'hold-time', which is the time interval that will be used for
              the Hold Timer (<xref section="4.2" sectionFormat="of"
              target="RFC4271"/>) when establishing a BGP session and (2)
              'keepalive', which is the time interval for the KeepaliveTimer
              between a PE and a BGP peer (<xref section="4.4"
              sectionFormat="of" target="RFC4271"/>).</t>
            </dd>
            <dt/>
            <dd>
              <t>Both timers are expressed in seconds.</t>
            </dd>
            <dt>'bfd':</dt>
            <dd>
              <t>Indicates whether BFD is enabled or disabled for this nighbor.
              neighbor. A BFD profile to apply may also be provided.</t>
            </dd>
            <dt>'authentication':</dt>
            <dd>
              <t>The module adheres to the recommendations in <xref
              section="13.2" sectionFormat="of" target="RFC4364"/>, as it
              allows enabling the TCP Authentication Option (TCP-AO) <xref
              target="RFC5925"/> and accommodates the installed base that
              makes use of MD5.</t>
            </dd>
            <dt/>
            <dd>
              <t>This version of the model assumes that parameters specific to
              the TCP-AO are preconfigured as part of the key chain that is
              referenced in the model.  No assumption is made about how such a
              key chain is preconfigured.  However, the structure of the key
              chain should cover data nodes beyond those in <xref
              target="RFC8177"/>, mainly SendID and RecvID (<xref
              section="3.1" sectionFormat="of" target="RFC5925"/>).</t>
            </dd>
          </dl>

          <t>For each neighbor, the following data nodes are supported in addition to similar parameters that are provided for a peer group:</t>
          <dl>

          <dl spacing="normal" newline="false">
            <dt>'remote-address':</dt>
            <dd>
              <t>Specifies the remote IP address of a BGP neighbor.</t>
            </dd>
            <dt>'peer-group':</dt>
            <dd>
              <t>A name of a peer group.</t>
            </dd>
            <dt/>
            <dd>
              <t>Parameters that are provided at the 'neighbor' level takes take
              precedence over the ones provided in the peer group.</t>
            </dd>
            <dt>'status':</dt>
            <dd>
              <t>Indicates the status of the BGP session.</t>
            </dd>
          </dl>

        </section>
        <section anchor="sec-ospf-rtg">
          <name>OSPF</name>
          <t>The OSPF routing subtree structure is shown in <xref target="ospf-tree"/>.</t>
          <figure anchor="ospf-tree">
            <name>OSPF Routing Tree Structure</name>
            <artwork><![CDATA[
            <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw
  augment /nw:networks/nw:network:
    +--rw ac-profile* [name]
       +--rw name                 string
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id      string
       |     +--rw type?   identityref
       |     +--rw bgp  {vpn-common:rtg-bgp}?
       |     |  ...
       |     +--rw ospf  {vpn-common:rtg-ospf}?
       |     |  +--rw address-family?   identityref
       |     |  +--rw area-id           yang:dotted-quad
       |     |  +--rw metric?           uint16
       |     |  +--rw max-lsa?          uint32
       |     +--rw isis  {vpn-common:rtg-isis}?
       |     |  ...
       |     +--rw rip  {vpn-common:rtg-rip}?
       |     |  ...
       |     +--rw vrrp  {vpn-common:rtg-vrrp}?
       |        ...
       +--rw oam
          ...
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       ...
       +--rw l2-connection  {ac-common:layer2-ac}?
       |  ...
       +--rw ip-connection  {ac-common:layer3-ac}?
       |  ...
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id                  string
       |     +--rw type?               identityref
       |     +--rw routing-profile* [routing-profile-ref]
       |     |  +--rw routing-profile-ref    leafref
       |     |  +--rw network-ref?
       |     |  |       -> /nw:networks/network/network-id
       |     |  +--rw type?                  identityref
       |     +--rw static
       |     |  ...
       |     +--rw bgp  {vpn-common:rtg-bgp}?
       |     |  ...
       |     +--rw ospf {vpn-common:rtg-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    string
       |     |  |     +--rw metric?        uint16
       |     |  +--rw max-lsa?          uint32
       |     |  +--rw passive?          boolean
       |     |  +--rw authentication
       |     |  |  +--rw enabled?           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
       |     |     |  +--ro last-change?   yang:date-and-time
       |     |     +--ro oper-status
       |     |        +--ro status?        identityref
       |     |        +--ro last-change?   yang:date-and-time
       |     +--rw isis  {vpn-common:rtg-isis}?
       |     |  ...
       |     +--rw rip  {vpn-common:rtg-rip}?
       |     |  ...
       |     +--rw vrrp  {vpn-common:rtg-vrrp}?
       |        ...
       +--rw oam
       |  ...
       +--rw security
       |  ...
       +--rw service
          ...
]]></artwork>
]]></sourcecode>
          </figure>
          <t>The following OSPF data nodes are supported:</t>
          <dl>
          <dl spacing="normal" newline="false">
            <dt>'address-family':</dt>
            <dd>
              <t>Indicates whether IPv4, IPv6, or both address families are to
              be activated.</t>
            </dd>
            <dt/>
            <dd>
              <t>When the IPv4 or dual-stack address family is requested, it
              is up to the implementation (e.g., network orchestrator) to
              decide whether OSPFv2 <xref target="RFC4577"/> or OSPFv3 <xref
              target="RFC6565"/> is used to announce IPv4 routes.</t>
            </dd>
            <dt>'area-id':</dt>
            <dd>
              <t>Indicates the OSPF Area ID.</t>
            </dd>
            <dt>'metric':</dt>
            <dd>
              <t>Associates a metric with OSPF routes.</t>
            </dd>
            <dt>'sham-links':</dt>
            <dd>
              <t>Used to create OSPF sham links between two ACs sharing the
              same area and having a backdoor link (<xref section="4.2.7"
              sectionFormat="of" target="RFC4577"/> and <xref section="5"
              sectionFormat="of" target="RFC6565"/>).</t>
            </dd>
            <dt>'max-lsa':</dt>
            <dd>
              <t>Sets the maximum number of Link State Advertisements (LSAs)
              that the OSPF instance will accept.</t>
            </dd>
            <dt>'passive':</dt>
            <dd>
              <t>Controls whether an OSPF interface is passive or active.</t>
            </dd>
            <dt>'authentication':</dt>
            <dd>
              <t>Controls the authentication schemes to be enabled for the
              OSPF instance. The module supports authentication options that
              are common to both OSPF versions: the Authentication Trailer for
              OSPFv2 <xref target="RFC5709"/> <xref target="RFC7474"/> and
              OSPFv3 <xref target="RFC7166"/>; as such, the model does not
              support <xref target="RFC4552"/>.</t>
            </dd>
            <dt>'status':</dt>
            <dd>
              <t>Indicates the status of the OSPF routing instance.</t>
            </dd>
          </dl>
        </section>
        <section anchor="sec-isis-rtg">
          <name>IS-IS</name>
          <t>The IS-IS routing subtree structure is shown in <xref target="isis-tree"/>.</t>
          <figure anchor="isis-tree">
            <name>IS-IS Routing Tree Structure</name>
            <artwork><![CDATA[
            <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw
  augment /nw:networks/nw:network:
    +--rw ac-profile* [name]
       +--rw name                 string
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id      string
       |     +--rw type?   identityref
       |     +--rw bgp  {vpn-common:rtg-bgp}?
       |     |  ...
       |     +--rw ospf  {vpn-common:rtg-ospf}?
       |     |  ...
       |     +--rw isis  {vpn-common:rtg-isis}?
       |     |  +--rw address-family?   identityref
       |     |  +--rw area-address      area-address
       |     |  +--rw level?            identityref
       |     |  +--rw metric?           uint32
       |     |  +--rw passive?          boolean
       |     +--rw rip  {vpn-common:rtg-rip}?
       |     |  ...
       |     +--rw vrrp  {vpn-common:rtg-vrrp}?
       |        ...
       +--rw oam
          ...
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       ...
       +--rw l2-connection
       |  ...
       +--rw ip-connection
       |  ...
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id                  string
       |     +--rw type?               identityref
       |     +--rw routing-profile* [routing-profile-ref]
       |     |  +--rw routing-profile-ref    leafref
       |     |  +--rw network-ref?
       |     |  |       -> /nw:networks/network/network-id
       |     |  +--rw type?                  identityref
       |     +--rw static
       |     |  ...
       |     +--rw bgp  {vpn-common:rtg-bgp}?
       |     |  ...
       |     +--rw ospf  {vpn-common:rtg-ospf}?
       |     |  ...
       |     +--rw isis {vpn-common:rtg-isis}?
       |     |  +--rw address-family?   identityref
       |     |  +--rw area-address      area-address
       |     |  +--rw level?            identityref
       |     |  +--rw metric?           uint32
       |     |  +--rw passive?          boolean
       |     |  +--rw authentication
       |     |  |  +--rw enabled?           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
       |     |     |  +--ro last-change?   yang:date-and-time
       |     |     +--ro oper-status
       |     |        +--ro status?        identityref
       |     |        +--ro last-change?   yang:date-and-time
       |     +--rw rip  {vpn-common:rtg-rip}?
       |     |  ...
       |     +--rw vrrp  {vpn-common:rtg-vrrp}?
       |        ...
       +--rw oam
       |  ...
       +--rw security
       |  ...
       +--rw service
          ...
]]></artwork>
]]></sourcecode>
          </figure>
          <t>The following IS-IS data nodes are supported:</t>
          <dl>
          <dl spacing="normal" newline="false">
            <dt>'address-family':</dt>
            <dd>
              <t>Indicates whether IPv4, IPv6, or both address families are to be activated.</t>
            </dd>
            <dt>'area-address':</dt>
            <dd>
              <t>Indicates the IS-IS area address.</t>
            </dd>
            <dt>'level':</dt>
            <dd>
              <t>Indicates the IS-IS level: Level 1, Level 2, or both.</t>
            </dd>
            <dt>'metric':</dt>
            <dd>
              <t>Associates a metric with IS-IS routes.</t>
            </dd>
            <dt>'passive':</dt>
            <dd>
              <t>Controls whether an IS-IS interface is passive or active.</t>
            </dd>
            <dt>'authentication':</dt>
            <dd>
              <t>Controls the authentication schemes to be enabled for the
              IS-IS instance.  Both the specification of a key chain <xref
              target="RFC8177"/> and the direct specification of key and
              authentication algorithms are supported.</t>
            </dd>
            <dt>'status':</dt>
            <dd>
              <t>Indicates the status of the IS-IS routing instance.</t>
            </dd>
          </dl>

        </section>
        <section anchor="sec-rip-rtg">
          <name>RIP</name>
          <t>The RIP routing subtree structure is shown in <xref target="rip-tree"/>.</t>
          <figure anchor="rip-tree">
            <name>RIP Routing Tree Structure</name>
            <artwork><![CDATA[
            <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw
  augment /nw:networks/nw:network:
    +--rw ac-profile* [name]
       +--rw name                 string
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id      string
       |     +--rw type?   identityref
       |     +--rw bgp  {vpn-common:rtg-bgp}?
       |     |  ...
       |     +--rw ospf  {vpn-common:rtg-ospf}?
       |     |  ...
       |     +--rw isis  {vpn-common:rtg-isis}?
       |     |  ...
       |     +--rw rip  {vpn-common:rtg-rip}?
       |     |  +--rw address-family?   identityref
       |     |  +--rw timers
       |     |  |  +--rw update-interval?     uint16
       |     |  |  +--rw invalid-interval?    uint16
       |     |  |  +--rw holddown-interval?   uint16
       |     |  |  +--rw flush-interval?      uint16
       |     |  +--rw default-metric?   uint8
       |     +--rw vrrp  {vpn-common:rtg-vrrp}?
       |        ...
       +--rw oam
          ...
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       ...
       +--rw l2-connection  {ac-common:layer2-ac}?
       |  ...
       +--rw ip-connection  {ac-common:layer3-ac}?
       |  ...
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id                  string
       |     +--rw type?               identityref
       |     +--rw routing-profile* [routing-profile-ref]
       |     |  +--rw routing-profile-ref    leafref
       |     |  +--rw network-ref?
       |     |  |       -> /nw:networks/network/network-id
       |     |  +--rw type?                  identityref
       |     +--rw static
       |     |  ...
       |     +--rw bgp  {vpn-common:rtg-bgp}?
       |     |  ...
       |     +--rw ospf  {vpn-common:rtg-ospf}?
       |     |  ...
       |     +--rw isis  {vpn-common:rtg-isis}?
       |     |  ...
       |     +--rw rip  {vpn-common:rtg-rip}?
       |     |  +--rw address-family?   identityref
       |     |  +--rw timers
       |     |  |  +--rw update-interval?     uint16
       |     |  |  +--rw invalid-interval?    uint16
       |     |  |  +--rw holddown-interval?   uint16
       |     |  |  +--rw flush-interval?      uint16
       |     |  +--rw default-metric?   uint8
       |     |  +--rw authentication
       |     |  |  +--rw enabled?            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
       |     |     |  +--ro last-change?   yang:date-and-time
       |     |     +--ro oper-status
       |     |        +--ro status?        identityref
       |     |        +--ro last-change?   yang:date-and-time
       |     +--rw vrrp
       |        ...
       +--rw oam
       |  ...
       +--rw security
       |  ...
       +--rw service
          ...
]]></artwork>
]]></sourcecode>
          </figure>
          <t>The following RIP data nodes are supported:</t>
          <dl>
          <dl spacing="normal" newline="false">
            <dt>'address-family':</dt>
            <dd>
              <t>Indicates whether IPv4, IPv6, or both address families are to
              be activated.  This parameter is used to determine whether RIPv2
              <xref target="RFC2453"/>, RIP Next Generation (RIPng) <xref
              target="RFC2080"/>, or both are to be enabled.</t>
            </dd>
            <dt>'timers':</dt>
            <dd>
              <t>Indicates the following timers (expressed in seconds):
</t>
              <ul spacing="normal">
                <li>
                  <dl> seconds):</t>
                  <dl spacing="normal" newline="false">
                    <dt>'update-interval':</dt>
                    <dd>
                      <t>The interval at which RIP updates are sent.</t>
                    </dd>
                  </dl>
                </li>
                <li>
                  <dl>
                    <dt>'invalid-interval':</dt>
                    <dd>
                      <t>The interval before a RIP route is declared invalid.</t>
                    </dd>
                  </dl>
                </li>
                <li>
                  <dl>
                    <dt>'holddown-interval':</dt>
                    <dd>
                      <t>The interval before better RIP routes are released.</t>
                    </dd>
                  </dl>
                </li>
                <li>
                  <dl>
                    <dt>'flush-interval':</dt>
                    <dd>
                      <t>The interval before a route is removed from the routing table.</t>
                    </dd>
                  </dl>
                </li>
              </ul>
            </dd>
            <dt>'default-metric':</dt>
            <dd>
              <t>Sets the default RIP metric.</t>
            </dd>
            <dt>'authentication':</dt>
            <dd>
              <t>Controls the authentication schemes to be enabled for the RIP instance.</t>
            </dd>
            <dt>'status':</dt>
            <dd>
              <t>Indicates the status of the RIP routing instance.</t>
            </dd>
          </dl>
        </section>
        <section anchor="sec-VRRP-rtg">
          <name>VRRP</name>
          <t>The VRRP subtree structure is shown in <xref target="vrrp-tree"/>.</t>
          <figure anchor="vrrp-tree">
            <name>VRRP Tree Structure</name>
            <artwork><![CDATA[
            <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw
  augment /nw:networks/nw:network:
    +--rw ac-profile* [name]
       +--rw name                 string
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id      string
       |     +--rw type?   identityref
       |     +--rw bgp  {vpn-common:rtg-bgp}?
       |     |  ...
       |     +--rw ospf  {vpn-common:rtg-ospf}?
       |     |  ...
       |     +--rw isis  {vpn-common:rtg-isis}?
       |     |  ...
       |     +--rw rip  {vpn-common:rtg-rip}?
       |     |  ...
       |     +--rw vrrp  {vpn-common:rtg-vrrp}?
       |        +--rw address-family?   identityref
       |        +--rw ping-reply?       boolean
       +--rw oam
          ...
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       ...
       +--rw l2-connection  {ac-common:layer2-ac}?
       |  ...
       +--rw ip-connection  {ac-common:layer3-ac}?
       |  ...
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id                  string
       |     +--rw type?               identityref
       |     +--rw routing-profile* [routing-profile-ref]
       |     |  +--rw routing-profile-ref    leafref
       |     |  +--rw network-ref?
       |     |  |       -> /nw:networks/network/network-id
       |     |  +--rw type?                  identityref
       |     +--rw static
       |     |  ...
       |     +--rw bgp  {vpn-common:rtg-bgp}?
       |     |  ...
       |     +--rw ospf  {vpn-common:rtg-ospf}?
       |     |  ...
       |     +--rw isis  {vpn-common:rtg-isis}?
       |     |  ...
       |     +--rw rip  {vpn-common:rtg-rip}?
       |     |  ...
       |     +--rw vrrp  {vpn-common:rtg-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
       |           |  +--ro last-change?   yang:date-and-time
       |           +--ro oper-status
       |              +--ro status?        identityref
       |              +--ro last-change?   yang:date-and-time
       +--rw oam
       |  ...
       +--rw security
       |  ...
       +--rw service
          ...
]]></artwork>
]]></sourcecode>
          </figure>
          <t>The following VRRP data nodes are supported:</t>
          <dl>
          <dl newline="false" spacing="normal">
            <dt>'address-family':</dt>
            <dd>
              <t>Indicates whether IPv4, IPv6, or both address
   families are to be activated.  Note that VRRP version 3 <xref target="RFC9568"/>
   supports both IPv4 and IPv6.</t>
            </dd>
            <dt>'vrrp-group':</dt>
            <dd>
              <t>Used to identify the VRRP group.</t>
            </dd>
            <dt>'backup-peer':</dt>
            <dd>
              <t>Carries the IP address of the peer.</t>
            </dd>
            <dt>'virtual-ip-address':</dt>
            <dd>
              <t>Includes virtual IP addresses for a single VRRP group.</t>
            </dd>
            <dt>'priority':</dt>
            <dd>
              <t>Assigns the VRRP election priority for the backup virtual router.</t>
            </dd>
            <dt>'ping-reply':</dt>
            <dd>
              <t>Controls whether the VRRP speaker should reply to ping requests.</t>
            </dd>
            <dt>'status':</dt>
            <dd>
              <t>Indicates the status of the VRRP instance.</t>
            </dd>
          </dl>
          <t>Note that no authentication data node is included for VRRP, as there
isn't any type of VRRP authentication at this time (see <xref section="9" sectionFormat="of" target="RFC9568"/>).</t>
        </section>
      </section>
      <section anchor="sec-oam">
        <name>OAM</name>
        <t>The OAM subtree structure is shown in <xref target="oam-tree"/>.</t>
        <figure anchor="oam-tree">
          <name>OAM Tree Structure</name>
          <artwork><![CDATA[
          <sourcecode type="yangtree"><![CDATA[
  augment /nw:networks/nw:network:
    +--rw ac-profile* [name]
       +--rw name                 string
       +--rw routing-protocols
       |  ...
       +--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
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       + ...
       +--rw l2-connection  {ac-common:layer2-ac}?
       |  ...
       +--rw ip-connection  {ac-common:layer3-ac}?
       |  ...
       +--rw routing-protocols
       |  ...
       +--rw oam
       |  +--rw bfd {vpn-common:bfd}?
       |     +--rw session* [dest-addr]
       |        +--rw dest-addr                   inet:ip-address
       |        +--rw source-address?             union
       |        +--rw failure-detection-profile-ref?   leafref
       |        +--rw network-ref?
       |        |       -> /nw:networks/network/network-id
       |        +--rw session-type?               identityref
       |        +--rw desired-min-tx-interval?    uint32
       |        +--rw required-min-rx-interval?   uint32
       |        +--rw local-multiplier?           uint8
       |        +--rw holdtime?                   uint32
       |        +--rw authentication!
       |        |  +--rw key-chain?    key-chain:key-chain-ref
       |        |  +--rw meticulous?   boolean
       |        +--rw status
       |           +--rw admin-status
       |           |  +--rw status?        identityref
       |           |  +--ro last-change?   yang:date-and-time
       |           +--ro oper-status
       |              +--ro status?        identityref
       |              +--ro last-change?   yang:date-and-time
       +--rw security
       |  ...
       +--rw service
          ...
]]></artwork>
]]></sourcecode>
        </figure>
        <t>The following OAM data nodes can be specified for each BFD session:</t>
        <dl>
        <dl spacing="normal" newline="false">
          <dt>'dest-addr':</dt>
          <dd>
            <t>Specifies the BFD peer address. This data node is mapped to 'remote-address' of the BFD container in <xref target="I-D.ietf-opsawg-teas-attachment-circuit"/>. target="RFC9834"/>. 'dest-address' is used here to ease the mapping with the underlying device model defind defined in <xref target="RFC9127"/>.</t>
          </dd>
          <dt>'source-address':</dt>
          <dd>
            <t>Specifies the local IP address or interface to use for the session. This data node is mapped to 'local-address' of the BFD container in <xref target="I-D.ietf-opsawg-teas-attachment-circuit"/>. target="RFC9834"/>. 'source-address' is used here to ease the mapping with the underlying device model defind defined in <xref target="RFC9127"/>.</t>
          </dd>
          <dt>'failure-detection-profile-ref':</dt>
          <dd>
            <t>Refers to a BFD profile in <xref target="sec-profiles"/>.</t>
          </dd>
          <dt>'network-ref':</dt>
          <dd>
            <t>Includes a network reference to uniquely identify a BFD profile.</t>
          </dd>
          <dt>'session-type':</dt>
          <dd>
            <t>Indicates which BFD flavor is used to set up the session (e.g., classic BFD <xref target="RFC5880"/>, Seamless BFD <xref target="RFC7880"/>). By default, it is assumed that the BFD session will follow the behavior specified in <xref target="RFC5880"/>.</t>
          </dd>
          <dt>'desired-min-tx-interval':</dt>
          <dd>
            <t>The minimum interval, in microseconds, to use when transmitting BFD Control packets, less any jitter applied.</t>
          </dd>
          <dt>'required-min-rx-interval':</dt>
          <dd>
            <t>The minimum interval, in microseconds, between received BFD Control packets packets, less any jitter applied by the sender.</t>
          </dd>
          <dt>'local-multiplier':</dt>
          <dd>
            <t>The negotiated transmit interval, multiplied by this value, provides the detection time for the peer.</t>
          </dd>
          <dt>'holdtime':</dt>
          <dd>
            <t>Used to indicate the expected BFD holddown time, in milliseconds.</t>
          </dd>
          <dt>'authentication':</dt>
          <dd>
            <t>Includes the required information to enable the BFD authentication modes discussed in <xref section="6.7" sectionFormat="of" target="RFC5880"/>. In particular, 'meticulous' controls the activation of meticulous mode as discussed in Sections 6.7.3 <xref target="RFC5880" sectionFormat="bare" section="6.7.3"/> and 6.7.4 <xref target="RFC5880" sectionFormat="bare" section="6.7.4"/> of <xref target="RFC5880"/>.</t>
          </dd>
          <dt>'status':</dt>
          <dd>
            <t>Indicates the status of BFD.</t>
          </dd>
        </dl>

      </section>
      <section anchor="sec-sec">
        <name>Security</name>
        <t>The security subtree structure is shown in <xref target="sec-tree"/>. The 'security' container specifies the the encryption to be applied to traffic for a given AC. The model can be used to directly control the encryption to be applied (e.g., Layer 2 or Layer 3 encryption) or invoke a local encryption profile.</t>
        <figure anchor="sec-tree">
          <name>Security Tree Structure</name>
          <artwork><![CDATA[
          <sourcecode type="yangtree"><![CDATA[
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       + ...
       +--rw l2-connection  {ac-common:layer2-ac}?
       |  ...
       +--rw ip-connection  {ac-common:layer3-ac}?
       |  ...
       +--rw routing-protocols
       |  ...
       +--rw oam
       |  ...
       +--rw security
       |  +--rw encryption {vpn-common:encryption}?
       |  |  +--rw enabled?   boolean
       |  |  +--rw layer?     enumeration
       |  +--rw encryption-profile
       |     +--rw (profile)?
       |        +--:(provider-profile)
       |        |  +--rw encryption-profile-ref?   leafref
       |        |  +--rw network-ref?
       |        |          -> /nw:networks/network/network-id
       |        +--:(customer-profile)
       |           +--rw customer-key-chain?  key-chain:key-chain-ref
       +--rw service
          ...
]]></artwork>
]]></sourcecode>
        </figure>
      </section>
      <section anchor="sec-svc">
        <name>Service</name>
        <t>The service subtree structure is shown in <xref target="svc-tree"/>.</t>
        <figure anchor="svc-tree">
          <name>Service Tree Structure</name>
          <artwork><![CDATA[
          <sourcecode type="yangtree"><![CDATA[
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       + ...
       +--rw l2-connection  {ac-common:layer2-ac}?
       |  ...
       +--rw ip-connection  {ac-common:layer3-ac}?
       |  ...
       +--rw routing-protocols
       |  ...
       +--rw oam
       |  ...
       +--rw security
       |  ...
       +--rw service
          +--rw mtu?                      uint32
          +--rw svc-pe-to-ce-bandwidth {vpn-common:inbound-bw}?
          |  +--rw bandwidth* [bw-type]
          |     +--rw bw-type      identityref
          |     +--rw (type)?
          |        +--:(per-cos)
          |        |  +--rw cos* [cos-id]
          |        |     +--rw cos-id    uint8
          |        |     +--rw cir?      uint64
          |        |     +--rw cbs?      uint64
          |        |     +--rw eir?      uint64
          |        |     +--rw ebs?      uint64
          |        |     +--rw pir?      uint64
          |        |     +--rw pbs?      uint64
          |        +--:(other)
          |           +--rw cir?   uint64
          |           +--rw cbs?   uint64
          |           +--rw eir?   uint64
          |           +--rw ebs?   uint64
          |           +--rw pir?   uint64
          |           +--rw pbs?   uint64
          +--rw svc-ce-to-pe-bandwidth {vpn-common:outbound-bw}?
          |  +--rw bandwidth* [bw-type]
          |     +--rw bw-type      identityref
          |     +--rw (type)?
          |        +--:(per-cos)
          |        |  +--rw cos* [cos-id]
          |        |     +--rw cos-id    uint8
          |        |     +--rw cir?      uint64
          |        |     +--rw cbs?      uint64
          |        |     +--rw eir?      uint64
          |        |     +--rw ebs?      uint64
          |        |     +--rw pir?      uint64
          |        |     +--rw pbs?      uint64
          |        +--:(other)
          |           +--rw cir?   uint64
          |           +--rw cbs?   uint64
          |           +--rw eir?   uint64
          |           +--rw ebs?   uint64
          |           +--rw pir?   uint64
          |           +--rw pbs?   uint64
          +--rw qos {vpn-common:qos}?
          |  +--rw qos-profiles
          |     +--rw qos-profile* [qos-profile-ref]
          |        +--rw qos-profile-ref    leafref
          |        +--rw network-ref?
          |        |       -> /nw:networks/network/network-id
          |        +--rw direction?         identityref
          +--rw access-control-list
             +--rw acl-profiles
                +--rw acl-profile* [forwarding-profile-ref]
                   +--rw forwarding-profile-ref    leafref
                   +--rw network-ref?
                           -> /nw:networks/network/network-id
]]></artwork>
]]></sourcecode>
        </figure>
        <t>The description of the service data nodes is are defined as follows:</t>
        <dl>
        <dl spacing="normal" newline="false">
          <dt>'mtu':</dt>
          <dd>
            <t>Specifies the Layer 2 MTU, in bytes, for the AC.</t>
          </dd>
          <dt>'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth':</dt>
          <dd>
            <t>Specify the service bandwidth for the AC.</t>
          </dd>
          <dt/>
          <dd>
            <t>'svc-pe-to-ce-bandwidth' indicates
	    <dl newline="false" spacing="normal">
              <dt>'svc-pe-to-ce-bandwidth':</dt> <dd>Indicates the inbound bandwidth of the connection (i.e., download bandwidth from the service provider to the site).</t>
          </dd>
          <dt/>
          <dd>
            <t>'svc-ce-to-pe-bandwidth' indicates site).</dd>
              <dt>'svc-ce-to-pe-bandwidth':</dt> <dd>Indicates the outbound bandwidth of the connection (i.e., upload bandwidth from the site to the service provider).</t>
          </dd>
          <dt/>
          <dd> provider).</dd>
	    </dl>
            <t>'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth' can be represented using the Committed Information Rate (CIR), the Committed Burst Size (CBS), the Excess Information Rate (EIR), the Excess Burst Size (EBS), the Peak Information Rate (PIR), and the Peak Burst Size (PBS). CIR, EIR, and PIR are expressed in bps, while CBS, EBS, and PBS are expressed in bytes.</t>
          </dd>
          <dt/>
          <dd>
            <t>The following types, defined in <xref target="RFC9181"/>, can be used to indicate the bandwidth type:</t>
            <dl>
            <dl spacing="normal" newline="false">
              <dt>'bw-per-cos':</dt>
              <dd>
                <t>The bandwidth is per CoS.</t> Class of Service (CoS).</t>
              </dd>
              <dt>'bw-per-port':</dt>
              <dd>
                <t>The bandwidth is per port.</t>
              </dd>

<!--[rfced] To improve readability, may we update "to" to "for"?

Original:
   'bw-per-site':  The bandwidth is to all peer SAPs that belong to
      the same site.

Perhaps:
   'bw-per-site':  The bandwidth is for all peer SAPs that belong to
      the same site.
-->
              <dt>'bw-per-site':</dt>
              <dd>
                <t>The bandwidth is to all peer SAPs that belong to the same site.</t>
              </dd>
              <dt>'bw-per-service':</dt>
              <dd>
                <t>The bandwidth is per service instance that is bound to an AC.</t>
              </dd>
            </dl>
          </dd>
          <dt>'qos':</dt>
          <dd>
            <t>Specifies a list of QoS profiles to apply for this AC.</t>
          </dd>
          <dt>'access-control-list':</dt>
          <dd>
            <t>Specifies a list of ACL profiles to apply for this AC.</t>
          </dd>
        </dl>

      </section>
    </section>
    <section anchor="sec-module">
      <name>YANG Module</name>
      <t>This module uses types defined in <xref target="RFC6991"/>, <xref target="RFC8177"/>, <xref target="RFC8294"/>, <xref target="RFC8343"/>, <xref target="RFC9067"/>, <xref target="RFC9181"/>, <xref target="I-D.ietf-opsawg-teas-common-ac"/>, target="RFC9833"/>, and <xref target="IEEE802.1Qcp"/>.</t>

<!--[rfced] FYI, this YANG module has been updated per the
formatting option of pyang.  Please let us know any concerns.
-->
      <sourcecode type="yang"><![CDATA[
<CODE BEGINS> file "ietf-ac-ntw@2025-01-07.yang" type="yang" name="ietf-ac-ntw@2025-08-11.yang" markers="true"><![CDATA[
module ietf-ac-ntw {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-ac-ntw";
  prefix ac-ntw;

  import ietf-vpn-common {
    prefix vpn-common;
    reference
      "RFC 9181: A Common YANG 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-key-chain {
    prefix key-chain;
    reference
      "RFC 8177: YANG Data Model for Key Chains";
  }
  import ietf-routing-types {
    prefix rt-types;
    reference
      "RFC 8294: Common YANG Data Types for the Routing Area";
  }
  import ietf-routing-policy {
    prefix rt-pol;
    reference
      "RFC 9067: A YANG Data Model for Routing Policy";
  }
  import ietf-interfaces {
    prefix if;
    reference
      "RFC 8343: A YANG Data Model for Interface Management";
  }
  import ieee802-dot1q-types {
    prefix dot1q-types;
    reference
      "IEEE Std 802.1Qcp: Bridges and Bridged Networks--
                          Amendment 30: YANG Data Model";
  }
  import ietf-network {
    prefix nw;
    reference
      "RFC 8345: A YANG Data Model for Network Topologies,
                 Section 6.1";
  }
  import ietf-sap-ntw {
    prefix sap;
    reference
      "RFC 9408: A YANG Network Data Model for Service Attachment
                 Points (SAPs)";
  }
  import ietf-ac-common {
    prefix ac-common;
    reference
      "RFC CCCC: 9833: A Common YANG Data Model for Attachment Circuits";
  }
  import ietf-ac-svc {
    prefix ac-svc;
    reference
      "RFC SSSS: 9834: YANG Data Models for Bearers and 'Attachment
                  Circuits'-as-a-Service (ACaaS)";
  }

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

     Editor:   Mohamed Boucadair
               <mailto:mohamed.boucadair@orange.com>
     Author:   Richard Roberts
               <mailto:rroberts@juniper.net>
     Author:   Oscar Gonzalez de Dios
               <mailto:oscar.gonzalezdedios@telefonica.com>
     Author:   Samier Barguil
               <mailto:ssamier.barguil_giraldo@nokia.com>
     Author:   Bo Wu
               <mailto:lana.wubo@huawei.com>";
  description
    "This YANG module defines a YANG network model for the management
     of attachment circuits (ACs).

     Copyright (c) 2025 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 Revised BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

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

  revision 2025-01-07 2025-08-11 {
    description
      "Initial revision.";
    reference
      "RFC XXXX: 9835: A YANG Network Data Model for Attachment Circuits";
  }

  // References

  /* A set of groupings to ease referencing cross-modules */

  grouping attachment-circuit-reference {
    description
      "This grouping can be used to reference an attachment circuit
       in a specific node.";
    leaf ac-ref {
      type leafref {
        path "/nw:networks/nw:network[nw:network-id=current()/../"
           + "network-ref]/nw:node[nw:node-id=current()/../"
           + "node-ref]/ac-ntw:ac/ac-ntw:name";
        require-instance false;
      }
      description
        "An absolute reference to an attachment circuit.";
    }
    uses nw:node-ref;
  }

  grouping attachment-circuit-references {
    description
      "This grouping can be used to reference a list of attachment
       circuits in a specific node.";
    leaf-list ac-ref {
      type leafref {
        path "/nw:networks/nw:network[nw:network-id=current()/../"
           + "network-ref]/nw:node[nw:node-id=current()/../"
           + "node-ref]/ac-ntw:ac/ac-ntw:name";
        require-instance false;
      }
      description
        "An absolute reference to an attachment circuit.";
    }
    uses nw:node-ref;
  }

  grouping ac-profile-reference {
    description
      "This grouping can be used to reference an attachment circuit
       profile.";
    leaf ac-profile-ref {
      type leafref {
        path "/nw:networks/nw:network[nw:network-id=current()/../"
           + "network-ref]/ac-ntw:ac-profile/ac-ntw:name";
        require-instance false;
      }
      description
        "An absolute reference to an attachment circuit.";
    }
    uses nw:network-ref;
  }

  grouping encryption-profile-reference {
    description
      "This grouping can be used to reference an encryption
       profile.";
    leaf encryption-profile-ref {
      type leafref {
        path "/nw:networks/nw:network[nw:network-id=current()/../"
           + "network-ref]"
           + "/ac-ntw:specific-provisioning-profiles"
           + "/ac-ntw:valid-provider-identifiers"
           + "/ac-ntw:encryption-profile-identifier/ac-ntw:id";
        require-instance false;
      }
      description
        "An absolute reference to an encryption profile.";
    }
    uses nw:network-ref;
  }

  grouping qos-profile-reference {
    description
      "This grouping can be used to reference a QoS profile.";
    leaf qos-profile-ref {
      type leafref {
        path "/nw:networks/nw:network[nw:network-id=current()/../"
           + "network-ref]"
           + "/ac-ntw:specific-provisioning-profiles"
           + "/ac-ntw:valid-provider-identifiers"
           + "/ac-ntw:qos-profile-identifier/ac-ntw:id";
        require-instance false;
      }
      description
        "An absolute reference to a QoS profile.";
    }
    uses nw:network-ref;
  }

  grouping failure-detection-profile-reference {
    description
      "This grouping can be used to reference a failure detection
       profile.";
    leaf failure-detection-profile-ref {
      type leafref {
        path "/nw:networks/nw:network[nw:network-id=current()/../"
          + "network-ref]"
          + "/ac-ntw:specific-provisioning-profiles"
          + "/ac-ntw:valid-provider-identifiers"
          + "/ac-ntw:failure-detection-profile-identifier/ac-ntw:id";
        require-instance false;
      }
      description
        "An absolute reference to a failure detection profile.";
    }
    uses nw:network-ref;
  }

  grouping forwarding-profile-reference {
    description
      "This grouping can be used to reference a forwarding profile.";
    leaf forwarding-profile-ref {
      type leafref {
        path "/nw:networks/nw:network[nw:network-id=current()/../"
           + "network-ref]"
           + "/ac-ntw:specific-provisioning-profiles"
           + "/ac-ntw:valid-provider-identifiers"
           + "/ac-ntw:forwarding-profile-identifier/ac-ntw:id";
        require-instance false;
      }
      description
        "An absolute reference to a forwarding profile.";
    }
    uses nw:network-ref;
  }

  grouping routing-profile-reference {
    description
      "This grouping can be used to reference a routing profile.";
    leaf routing-profile-ref {
      type leafref {
        path "/nw:networks/nw:network[nw:network-id=current()/../"
           + "network-ref]"
           + "/ac-ntw:specific-provisioning-profiles"
           + "/ac-ntw:valid-provider-identifiers"
           + "/ac-ntw:routing-profile-identifier/ac-ntw:id";
        require-instance false;
      }
      description
        "An absolute reference to a routing profile.";
    }
    uses nw:network-ref;
  }

  // Layer 2 connection

  grouping l2-connection {
    description
      "Defines Layer 2 protocols and parameters that are required to
       enable AC connectivity on the network side.";
    container encapsulation {
      description
        "Container for Layer 2 encapsulation.";
      leaf encap-type {
        type identityref {
          base vpn-common:encapsulation-type;
        }
        description
          "Tagged interface type.";
      }
      container dot1q {
        when "derived-from-or-self(../encap-type, "
           + "'vpn-common:dot1q')" {
          description
            "Only applies when the type of the tagged interface is
             'dot1q'.";
        }
        description
          "Tagged interface.";
        uses ac-common:dot1q;
        container tag-operations {
          description
            "Sets the tag manipulation policy for this AC.  It
             defines a set of tag manipulations that allow for the
             insertion, removal, or rewriting of 802.1Q VLAN tags.
             These operations are indicated for the CE-PE direction.
             By default, tag operations are symmetric.  As such, the
             reverse tag operation is assumed on the PE-CE
             direction.";
          choice op-choice {
            description
              "Selects the tag rewriting policy for an AC.";
            leaf pop {
              type empty;
              description
                "Pop the outer tag.";
            }
            leaf push {
              type empty;
              description
                "Pushes one or two tags defined by the tag-1 and
                 tag-2 leaves.  It is assumed that, absent any
                 policy, the default value of 0 will be used for
                 the Priority Code Point (PCP) setting.";
            }
            leaf translate {
              type empty;
              description
                "Translates the outer tag to one or two tags.  PCP
                 bits are preserved.";
            }
          }
          leaf tag-1 {
            when 'not(../pop)';
            type dot1q-types:vlanid;
            description
              "A first tag to be used for push or translate
               operations.  This tag will be used as the outermost
               tag as a result of the tag operation.";
          }
          leaf tag-1-type {
            type dot1q-types:dot1q-tag-type;
            default "dot1q-types:s-vlan";
            description
              "Specifies a specific 802.1Q tag type of tag-1.";
          }
          leaf tag-2 {
            when '(../translate)';
            type dot1q-types:vlanid;
            description
              "A second tag to be used for translation.";
          }
          leaf tag-2-type {
            type dot1q-types:dot1q-tag-type;
            default "dot1q-types:c-vlan";
            description
              "Specifies a specific 802.1Q tag type of tag-2.";
          }
        }
      }
      container priority-tagged {
        when "derived-from-or-self(../encap-type, "
           + "'vpn-common:priority-tagged')" {
          description
            "Only applies when the type of the tagged interface is
             'priority-tagged'.";
        }
        description
          "Priority tagged container.";
        uses ac-common:priority-tagged;
      }
      container qinq {
        when "derived-from-or-self(../encap-type, "
           + "'vpn-common:qinq')" {
          description
            "Only applies when the type of the tagged interface is
             'QinQ'.";
        }
        description
          "Includes QinQ parameters.";
        uses ac-common:qinq;
        container tag-operations {
          description
            "Sets the tag manipulation policy for this AC.  It
             defines a set of tag manipulations that allow for the
             insertion, removal, or rewriting of 802.1Q VLAN tags.
             These operations are indicated for the CE-PE direction.
             By default, tag operations are symmetric.  As such, the
             reverse tag operation is assumed on the PE-CE
             direction.";
          choice op-choice {
            description
              "Selects the tag rewriting policy for a an AC.";
            leaf pop {
              type uint8 {
                range "1|2";
              }
              description
                "Pops one or two tags as a function of the indicated
                 pop value.";
            }
            leaf push {
              type empty;
              description
                "Pushes one or two tags defined by the tag-1 and
                 tag-2 leaves.  It is assumed that, absent any
                 policy, the default value of 0 will be used for
                 PCP setting.";
            }
            leaf translate {
              type uint8 {
                range "1|2";
              }
              description
                "Translates one or two outer tags.  PCP bits are
                 preserved.  The following operations are supported:

                 - translate 1 with tag-1 leaf is provided: only the
                   outermost tag is translated to the value in tag-1.

                 - translate 2 with both tag-1 and tag-2 leaves are
                   provided: both outer and inner tags are translated
                   to the values in tag-1 and tag-2, respectively.

                 - translate 2 with tag-1 leaf is provided: the
                   outer tag is popped while the inner tag is
                   translated to the value in tag-1.";
            }
          }
          leaf tag-1 {
            when 'not(../pop)';
            type dot1q-types:vlanid;
            description
              "A first tag to be used for push or translate
               operations.  This tag will be used as the outermost
               tag as a result of the tag operation.";
          }
          leaf tag-1-type {
            type dot1q-types:dot1q-tag-type;
            default "dot1q-types:s-vlan";
            description
              "Specifies a specific 802.1Q tag type of tag-1.";
          }
          leaf tag-2 {
            when 'not(../pop)';
            type dot1q-types:vlanid;
            description
              "A second tag to be used for push or translate
               operations.";
          }
          leaf tag-2-type {
            type dot1q-types:dot1q-tag-type;
            default "dot1q-types:c-vlan";
            description
              "Specifies a specific 802.1Q tag type of tag-2.";
          }
        }
      }
    }
    choice l2-service {
      description
        "The Layer 2 connectivity service can be provided by
         indicating a pointer to an L2VPN or by specifying a Layer 2
         tunnel service.";
      container l2-tunnel-service {
        description
          "Defines a Layer 2 tunnel termination.";
        uses ac-common:l2-tunnel-service;
      }
      case l2vpn {
        leaf l2vpn-id {
          type vpn-common:vpn-id;
          description
            "Indicates the L2VPN service associated with an
             Integrated Routing and Bridging (IRB) interface.";
        }
      }
    }
  }

  grouping l2-connection-if-ref {
    description
      "Specifies Layer 2 connection parameters with interface
       references.";
    uses l2-connection;
    leaf l2-termination-point {
      type string;
      description
        "Specifies a reference to a local Layer 2 termination point,
         such as a Layer 2 sub-interface.";
    }
    leaf local-bridge-reference {
      type string;
      description
        "Specifies a local bridge reference to accommodate, e.g.,
         implementations that require internal bridging.
         A reference may be a local bridge domain.";
    }
    leaf bearer-reference {
      if-feature "ac-common:server-assigned-reference";
      type string;
      description
        "This is an internal reference for the service provider to
         identify the bearer associated with this AC.";
    }
    container lag-interface {
      if-feature "vpn-common:lag-interface";
      description
        "Container for configuration of Link Aggregation Group (LAG)
         interface attributes.";
      leaf lag-interface-id {
        type string;
        description
          "LAG interface identifier.";
      }
      container member-link-list {
        description
          "Container for the member link list.";
        list member-link {
          key "name";
          description
            "Member link.";
          leaf name {
            type string;
            description
              "Member link name.";
          }
        }
      }
    }
  }

  // IPv4 connection

  grouping ipv4-connection {
    description
      "IPv4-specific connection parameters.";
    leaf local-address {
      type inet:ipv4-address;
      description
        "The IPv4 address used at the provider's interface.";
    }
    uses ac-common:ipv4-allocation-type;
    choice allocation-type {
      description
        "Choice of the IPv4 address allocation.";
      case dynamic {
        description
          "When the addresses are allocated by DHCP or other
           dynamic means local to the infrastructure.";
        choice address-assign {
          description
            "A choice for how IPv4 addresses are assigned.";
          case number {
            leaf number-of-dynamic-address {
              type uint16;
              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 dynamically
                   allocated.

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

                   When both 'start-address' and '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' to '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.";
                }
              }
            }
          }
        }
        choice provider-dhcp {
          description
            "Parameters related to DHCP-allocated addresses.
             IP addresses are allocated by DHCP, which is provided
             by the 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' is set to 'relay').";
              leaf-list server-ip-address {
                type inet:ipv4-address;
                description
                  "IPv4 addresses of the provider's DHCP server, for
                   use by the local DHCP relay.";
              }
            }
          }
        }
        choice dhcp-relay {
          description
            "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 static IPv4 addresses that are used.";
        list address {
          key "address-id";
          ordered-by user;
          description
            "Lists the IPv4 addresses that are used.  The first
             address of the list is the primary address of the
             connection.";
          leaf address-id {
            type string;
            description
              "An identifier of the static IPv4 address.";
          }
          leaf customer-address {
            type inet:ipv4-address;
            description
              "An IPv4 address of the customer side.";
          }
          uses failure-detection-profile-reference;
        }
      }
    }
  }

  grouping ipv6-connection {
    description
      "IPv6-specific connection parameters.";
    leaf local-address {
      type inet:ipv6-address;
      description
        "IPv6 address of the provider side.";
    }
    uses ac-common:ipv6-allocation-type;
    choice allocation-type {
      description
        "Choice of the IPv6 address allocation.";
      case dynamic {
        description
          "When the addresses are allocated by DHCP or other
           dynamic means local to the infrastructure.";
        choice address-assign {
          description
            "A choice for how IPv6 addresses are assigned.";
          case number {
            leaf number-of-dynamic-address {
              type uint16;
              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 IPv6 addresses to be dynamically
                   allocated.

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

                   When both 'start-address' and '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' to 'end-address'.";
                }
                leaf start-address {
                  type inet:ipv6-address;
                  mandatory true;
                  description
                    "Indicates the first address in the pool.";
                }
                leaf end-address {
                  type inet:ipv6-address;
                  description
                    "Indicates the last address in the pool.";
                }
              }
            }
          }
        }
        choice provider-dhcp {
          description
            "Parameters related to DHCP-allocated addresses.
             IP addresses are allocated by DHCP, which is provided
             by the 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' is set to 'relay').";
              leaf-list server-ip-address {
                type inet:ipv6-address;
                description
                  "IPv6 addresses of the provider's DHCP server, for
                   use by the local DHCP relay.";
              }
            }
          }
        }
        choice dhcp-relay {
          description
            "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:ipv6-address;
              description
                "IPv6 addresses of the customer's DHCP servers.";
            }
          }
        }
      }
      case static-addresses {
        description
          "Lists the static IPv6 addresses that are used.";
        list address {
          key "address-id";
          ordered-by user;
          description
            "Lists the IPv6 addresses that are used.  The first
             address of the list is the primary address of
             the connection.";
          leaf address-id {
            type string;
            description
              "An identifier of the static IPv6 address.";
          }
          leaf customer-address {
            type inet:ipv6-address;
            description
              "An IPv6 address of the customer side.";
          }
          uses failure-detection-profile-reference;
        }
      }
    }
  }

  grouping ip-connection {
    description
      "Defines IP connection parameters.";
    leaf l3-termination-point {
      type string;
      description
        "Specifies a reference to a local Layer 3 termination point,
         such as a bridge domain interface.";
    }
    container ipv4 {
      if-feature "vpn-common:ipv4";
      description
        "IPv4-specific connection parameters.";
      uses ipv4-connection;
    }
    container ipv6 {
      if-feature "vpn-common:ipv6";
      description
        "IPv6-specific connection parameters.";
      uses ipv6-connection;
    }
  }

  /* Routing */
  //BGP base parameters

  grouping bgp-base {
    description
      "Configuration specific to BGP.";
    leaf description {
      type string;
      description
        "Includes a description of the BGP session.  This description
         is meant to be used for diagnostic purposes.  The semantic semantics
         of the description is are local to an implementation.";
    }
    uses rt-pol:apply-policy-group;
    leaf local-as {
      type inet:as-number;
      description
        "Indicates a local AS Number (ASN), if an ASN distinct from
         the ASN configured at the AC 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' means that both IPv4 and IPv6 will be
         activated.";
    }
    leaf role {
      type identityref {
        base ac-common:bgp-role;
      }
      description
        "Specifies the BGP role (provider, customer, peer, etc.).";
    }
    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;
      description
        "Defines whether ASN override is enabled, i.e., replacing the
         ASN of the customer specified in the AS_PATH attribute with
         the local ASN.";
    }
    leaf allow-own-as {
      type uint8;
      description
        "If set, specifies the maximum number of occurrences of the
         provider's ASN that are permitted within the AS_PATH
         before it is rejected.";
    }
    leaf prepend-global-as {
      type boolean;
      description
        "In some situations, the ASN that is provided at the node
         level may be distinct from the ASN configured at the AC.
         When such ASNs are provided, they are both prepended to the
         BGP route updates for this AC.  To disable that behavior,
         'prepend-global-as' must be set to 'false'.  In such a
         case, the ASN that is provided at the node level is not
         prepended to the BGP route updates for this access.";
    }
    leaf send-default-route {
      type boolean;
      description
        "Defines whether default routes can be advertised to a peer.
         If set to 'true', the default routes are advertised to
         a peer.";
    }
    leaf site-of-origin {
      when "derived-from-or-self(../address-family, "
         + "'vpn-common:ipv4' 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 AC 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 "derived-from-or-self(../address-family, "
         + "'vpn-common:ipv6' or 'vpn-common:dual-stack')" {
        description
          "Only applies if IPv6 is activated.";
      }
      type rt-types:ipv6-route-origin;
      description
        "The IPv6 Site of Origin attribute is encoded as an IPv6
         Route Origin Extended Community.  It is meant to uniquely
         identify the set of routes learned from a site.";
      reference
        "RFC 5701: IPv6 Address Specific BGP Extended Community
                   Attribute";
    }
    list redistribute-connected {
      key "address-family";
      description
        "Indicates, per address family, the policy to follow for
         connected routes.";
      leaf address-family {
        type identityref {
          base vpn-common:address-family;
        }
        description
          "Indicates the address family.";
      }
      leaf enabled {
        type boolean;
        description
          "Enables, when set to 'true', the redistribution of
           Connected
           connected routes.";
      }
    }
    container bgp-max-prefix {
      description
        "Controls the behavior when a prefix maximum is reached.";
      leaf max-prefix {
        type uint32;
        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' 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";
        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 the indicated time
               interval.";
          }
        }
        description
          "If the BGP neighbor '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.";
      leaf keepalive {
        type uint16 {
          range "0..21845";
        }
        units "seconds";
        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 be 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";
        description
          "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";
      }
    }
  }

  grouping bgp-base-peer-group {
    description
      "Grouping for a basic BGP peer group.";
    leaf name {
      type string;
      description
        "Name of the BGP peer group.";
    }
    uses bgp-base;
  }

  grouping bgp-base-peer-group-list {
    description
      "Grouping for a list of basic BGP peer groups.";
    list peer-group {
      key "name";
      description
        "List of BGP peer groups uniquely identified by a name.";
      uses bgp-base-peer-group;
    }
  }

  grouping bgp-peer-group {
    description
      "Grouping for BGP peer group.";
    leaf name {
      type string;
      description
        "Name of the BGP peer group";
    }
    leaf local-address {
      type union {
        type inet:ip-address;
        type if:interface-ref;
      }
      description
        "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.";
    }
    uses bgp-base;
    uses ac-common:bgp-authentication;
  }

  grouping bgp-peer-group-list {
    description
      "Grouping for a list of BGP peer groups.";
    list peer-group {
      key "name";
      description
        "List of BGP peer groups uniquely identified by a name.";
      uses bgp-peer-group;
    }
  }

  // RIP base parameters

  grouping rip-base {
    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 2080: RIPng for IPv6
         RFC 2453: RIP Version 2";
      leaf update-interval {
        type uint16 {
          range "1..32767";
        }
        units "seconds";
        description
          "Indicates the RIP update time, i.e., the amount of time
           for which RIP updates are sent.";
      }
      leaf invalid-interval {
        type uint16 {
          range "1..32767";
        }
        units "seconds";
        description
          "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' argument.";
      }
      leaf holddown-interval {
        type uint16 {
          range "1..32767";
        }
        units "seconds";
        description
          "Specifies the interval before better routes are
           released.";
      }
      leaf flush-interval {
        type uint16 {
          range "1..32767";
        }
        units "seconds";
        description
          "Indicates the RIP flush 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";
      }
      description
        "Sets the default metric.";
    }
  }

  // Routing profile

  grouping routing-profile {
    description
      "Defines profiles for routing protocols.";
    list routing-protocol {
      key "id";
      description
        "List of routing protocols used on the AC.";
      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.";
      }
      container bgp {
        when "derived-from-or-self(../type, "
           + "'vpn-common:bgp-routing')" {
          description
            "Only applies when the protocol is BGP.";
        }
        if-feature "vpn-common:rtg-bgp";
        description
          "Configuration specific to BGP.";
        container peer-groups {
          description
            "Lists a set of BGP peer groups.";
          uses bgp-base-peer-group-list;
        }
      }
      container ospf {
        when "derived-from-or-self(../type, "
           + "'vpn-common:ospf-routing')" {
          description
            "Only applies when the protocol is OSPF.";
        }
        if-feature "vpn-common:rtg-ospf";
        description
          "Configuration specific to OSPF.";
        uses ac-common:ospf-basic;
        leaf max-lsa {
          type uint32 {
            range "1..4294967294";
          }
          description
            "Maximum number of allowed Link State Advertisements
             (LSAs) that the OSPF instance will accept.";
        }
        leaf passive {
          type boolean;
          description
            "Enables when
            "When set to 'true' 'true', enables a passive interface.  It is
             active when set to 'false'.  A passive interface's
             prefix will be advertised, but no neighbor adjacencies
             will be formed on the interface.";
        }
      }
      container isis {
        when "derived-from-or-self(../type, "
           + "'vpn-common:isis-routing')" {
          description
            "Only applies when the protocol is IS-IS.";
        }
        if-feature "vpn-common:rtg-isis";
        description
          "Configuration specific to IS-IS.";
        uses ac-common:isis-basic;
        leaf level {
          type identityref {
            base vpn-common:isis-level;
          }
          description
            "Can be 'level-1', 'level-2', or 'level-1-2'.";
          reference
            "RFC 9181: A Common YANG Data Model for Layer 2
                       and Layer 3 VPNs";
        }
        leaf metric {
          type uint32 {
            range "0 .. 16777215";
          }
          description
            "Metric of the AC.  It is used in the routing state
             calculation and path selection.";
        }
        leaf passive {
          type boolean;
          description
            "When set to 'false', the interface is active.  In such
             mode, the interface sends or receives IS-IS protocol
             control packets.

             When set to 'true', the interface is passive.  That
             is, it suppresses the sending of IS-IS updates through
             the specified interface.";
        }
      }
      container rip {
        when "derived-from-or-self(../type, "
           + "'vpn-common:rip-routing')" {
          description
            "Only applies when the protocol is RIP.";
        }
        if-feature "vpn-common:rtg-rip";
        description
          "Configuration specific to RIP routing.";
        uses rip-base;
      }
      container vrrp {
        when "derived-from-or-self(../type, "
           + "'vpn-common:vrrp-routing')" {
          description
            "Only applies when the protocol is the Virtual Router
             Redundancy Protocol (VRRP).";
        }
        if-feature "vpn-common:rtg-vrrp";
        description
          "Configuration specific to VRRP.";
        reference
          "RFC 9568: 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 ping-reply {
          type boolean;
          description
            "Controls whether the VRRP speaker should reply to ping
             requests.  Such behavior is enabled, if set to 'true'.";
        }
      }
    }
  }

  grouping routing {
    description
      "Defines routing protocols.";
    list routing-protocol {
      key "id";
      description
        "List of routing protocols used on the AC.";
      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-profile {
        key "routing-profile-ref";
        description
          "Routing profiles.";
        uses routing-profile-reference;
        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 routing.";
        }
        description
          "Configuration specific to static routing.";
        container cascaded-lan-prefixes {
          description
            "LAN prefixes from the customer.";
          list ipv4-lan-prefix {
            if-feature "vpn-common:ipv4";
            key "lan next-hop";
            description
              "List of LAN prefixes for the site.";
            uses ac-common:ipv4-static-rtg-entry;
            uses bfd-routing;
            leaf preference {
              type uint32;
              description
                "Indicates the preference associated with the static
                 route.";
            }
            uses ac-common:service-status;
          }
          list ipv6-lan-prefix {
            if-feature "vpn-common:ipv6";
            key "lan next-hop";
            description
              "List of LAN prefixes for the site.";
            uses ac-common:ipv6-static-rtg-entry;
            uses bfd-routing;
            leaf preference {
              type uint32;
              description
                "Indicates the preference associated with the static
                 route.";
            }
            uses ac-common:service-status;
          }
        }
      }
      container bgp {
        when "derived-from-or-self(../type, "
           + "'vpn-common:bgp-routing')" {
          description
            "Only applies when the protocol is BGP.";
        }
        if-feature "vpn-common:rtg-bgp";
        description
          "Configuration specific to BGP.";
        container peer-groups {
          description
            "Configuration for BGP peer groups";
          uses bgp-peer-group-list;
        }
        list neighbor {
          key "remote-address";
          description
            "List of BGP neighbors.";
          leaf remote-address {
            type inet:ip-address;
            description
              "The remote IP address of this entry's BGP peer.";
          }
          leaf local-address {
            type union {
              type inet:ip-address;
              type if:interface-ref;
            }
            description
              "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 peer-group {
            type leafref {
              path "../../peer-groups/peer-group/name";
            }
            description
              "The peer group with which this neighbor is
               associated.";
          }
          uses bgp-base;
          uses bfd-routing;
          uses ac-common:bgp-authentication;
          uses ac-common:service-status;
        }
      }
      container ospf {
        when "derived-from-or-self(../type, "
           + "'vpn-common:ospf-routing')" {
          description
            "Only applies when the protocol is OSPF.";
        }
        if-feature "vpn-common:rtg-ospf";
        description
          "Configuration specific to OSPF.";
        uses ac-common:ospf-basic;
        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;
              description
                "Metric of the sham link.  It is used in the routing
                 state calculation and path selection.";
              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 Link State Advertisements
             (LSAs) that the OSPF instance will accept.";
        }
        leaf passive {
          type boolean;
          description
            "Enables when
            "When set to 'true' 'true', enables a passive interface.  It is
             active when set to 'false'.  A passive interface's
             prefix will be advertised, but no neighbor adjacencies
             will be formed on the interface.";
        }
        uses ac-common:ospf-authentication;
        uses ac-common:service-status;
      }
      container isis {
        when "derived-from-or-self(../type, "
           + "'vpn-common:isis-routing')" {
          description
            "Only applies when the protocol is IS-IS.";
        }
        if-feature "vpn-common:rtg-isis";
        description
          "Configuration specific to IS-IS.";
        uses ac-common:isis-basic;
        leaf level {
          type identityref {
            base vpn-common:isis-level;
          }
          description
            "Can be 'level-1', 'level-2', or 'level-1-2'.";
          reference
            "RFC 9181: A Common YANG Data Model for Layer 2 and
                       Layer 3 VPNs";
        }
        leaf metric {
          type uint32 {
            range "0 .. 16777215";
          }
          description
            "Metric of the AC.  It is used in the routing state
             calculation and path selection.";
        }
        leaf passive {
          type boolean;
          description
            "When set to 'false', the interface is active.  In such
             mode, the interface sends or receives IS-IS protocol
             control packets.

             When set to 'true', the interface is passive.  That
             is, it suppresses the sending of IS-IS updates through
             the specified interface.";
        }
        uses ac-common:isis-authentication;
        uses ac-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.";
        }
        if-feature "vpn-common:rtg-rip";
        description
          "Configuration specific to RIP routing.";
        uses rip-base;
        uses ac-common:rip-authentication;
        uses ac-common:service-status;
      }
      container vrrp {
        when "derived-from-or-self(../type, "
           + "'vpn-common:vrrp-routing')" {
          description
            "Only applies when the protocol is the VRRP.";
        }
        if-feature "vpn-common:rtg-vrrp";
        description
          "Configuration specific to VRRP.";
        reference
          "RFC 9568: 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 9568: Virtual Router Redundancy Protocol (VRRP)
                       Version 3 for IPv4 and IPv6, Sections 1.2
                       and 1.3";
        }
        leaf priority {
          type uint8 {
            range "1..254";
          }
          description
            "Sets the local priority of the VRRP speaker.";
        }
        leaf ping-reply {
          type boolean;
          description
            "Controls whether the VRRP speaker should reply to ping
             requests.";
        }
        uses ac-common:service-status;
      }
    }
  }

  // OAM

  grouping bfd {
    description
      "Grouping for BFD.";
    leaf session-type {
      type identityref {
        base vpn-common:bfd-session-type;
      }
      description
        "Specifies the BFD session type.";
    }
    leaf desired-min-tx-interval {
      type uint32;
      units "microseconds";
      description
        "The minimum interval between transmissions of BFD Control
         packets, as desired by the operator.";
      reference
        "RFC 5880: Bidirectional Forwarding Detection (BFD),
                   Section 6.8.7";
    }
    leaf required-min-rx-interval {
      type uint32;
      units "microseconds";
      description
        "The minimum interval between received BFD 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";
      }
      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 this
         function.";
      reference
        "RFC 5880: Bidirectional Forwarding Detection (BFD),
                   Section 6.8.18";
    }
  }

  grouping bfd-routing {
    description
      "Defines a basic BFD grouping for routing configuration.";
    container bfd {
      if-feature "vpn-common:bfd";
      description
        "BFD control for this neighbor.";
      leaf enabled {
        type boolean;
        description
          "Enables BFD if set to 'true'. BFD is disabled of if set to
           'false'.";
      }
      uses failure-detection-profile-reference;
    }
  }

  grouping oam {
    description
      "Defines the Operations, Administration, and Maintenance
       (OAM) mechanisms used.";
    container bfd {
      if-feature "vpn-common:bfd";
      description
        "Container for BFD.";
      list session {
        key "dest-addr";
        description
          "List of IP sessions.";
        leaf dest-addr {
          type inet:ip-address;
          description
            "IP address of the peer.";
        }
        leaf source-address {
          type union {
            type inet:ip-address;
            type if:interface-ref;
          }
          description
            "Sets the local IP address to use for the BFD session.
             This may be expressed as either an IP address or
             a reference to an interface.";
        }
        uses failure-detection-profile-reference;
        uses bfd;
        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.";
          }
          leaf meticulous {
            type boolean;
            description
              "Enables meticulous mode, if set to 'true'.";
            reference
              "RFC 5880: Bidirectional Forwarding Detection (BFD),
                         Section 6.7";
          }
        }
        uses ac-common:service-status;
      }
    }
  }

  // Security

  grouping security {
    description
      "Security parameters for an AC.";
    container encryption {
      if-feature "vpn-common:encryption";
      description
        "Container for AC encryption.";
      leaf enabled {
        type boolean;
        description
          "If set to 'true', traffic encryption on the connection is
           required.  Otherwise, it is disabled.";
      }
      leaf layer {
        when "../enabled = 'true'" {
          description
            "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 {
          uses encryption-profile-reference;
        }
        case customer-profile {
          leaf customer-key-chain {
            type key-chain:key-chain-ref;
            description
              "Customer-supplied key chain.";
          }
        }
      }
    }
  }

  // AC profile

  grouping ac-profile {
    description
      "Grouping for attachment circuit profiles.";
    container routing-protocols {
      description
        "Defines routing protocols.";
      uses routing-profile;
    }
    container oam {
      description
        "Defines the OAM mechanisms used for the AC profile.";
      container bfd {
        if-feature "vpn-common:bfd";
        description
          "Container for BFD.";
        uses bfd;
      }
    }
  }

  // Parent and Child ACs

  grouping ac-hierarchy {
    description
      "Container for parent and child AC references.";
    container parent-ref {
      description
        "Specifies the parent AC that is inherited by an AC.
         Parent ACs are used, e.g., in contexts where multiple
         CEs are terminating the same AC, but some specific
         information is required for each peer SAP.";
      uses ac-ntw:attachment-circuit-reference;
    }
    container child-ref {
      config false;
      description
        "Specifies a child AC that relies upon a parent AC.";
      uses ac-ntw:attachment-circuit-references;
    }
  }

  // AC network provisioning

  grouping ac {
    description
      "Grouping for attachment circuits.";
    leaf description {
      type string;
      description
        "Associates a description with an AC.";
    }
    container l2-connection {
      if-feature "ac-common:layer2-ac";
      description
        "Defines Layer 2 protocols and parameters that are required
         to enable AC connectivity.";
      uses l2-connection-if-ref;
    }
    container ip-connection {
      if-feature "ac-common:layer3-ac";
      description
        "Defines IP connection parameters.";
      uses ip-connection;
    }
    container routing-protocols {
      description
        "Defines routing protocols.";
      uses routing;
    }
    container oam {
      description
        "Defines the OAM mechanisms used for the AC.";
      uses oam;
    }
    container security {
      description
        "AC-specific security parameters.";
      uses security;
    }
    container service {
      description
        "AC-specific bandwidth parameters.";
      leaf mtu {
        type uint32;
        units "bytes";
        description
          "Layer 2 MTU.";
      }
      uses ac-svc:bandwidth;
      container qos {
        if-feature "vpn-common:qos";
        description
          "QoS configuration.";
        container qos-profiles {
          description
            "QoS profile configuration.";
          list qos-profile {
            key "qos-profile-ref";
            description
              "Points to a QoS profile.";
            uses qos-profile-reference;
            leaf direction {
              type identityref {
                base vpn-common:qos-profile-direction;
              }
              description
                "The direction to which the QoS profile is applied.";
            }
          }
        }
      }
      container access-control-list {
        description
          "Container for the Access Control List (ACL).";
        container acl-profiles {
          description
            "ACL profile configuration.";
          list acl-profile {
            key "forwarding-profile-ref";
            description
              "Points to an ACL profile.";
            uses forwarding-profile-reference;
          }
        }
      }
    }
  }

  augment "/nw:networks/nw:network" {
    description
      "Add a list of profiles.";
    container specific-provisioning-profiles {
      description
        "Contains a set of valid profiles to reference in the AC
         activation.";
      uses ac-common:ac-profile-cfg;
    }
    list ac-profile {
      key "name";
      description
        "Specifies a list of AC profiles.";
      leaf name {
        type string;
        description
          "Name of the AC.";
      }
      uses ac-ntw:ac-profile;
    }
  }

  augment "/nw:networks/nw:network/nw:node" {
    when '../nw:network-types/sap:sap-network' {
      description
        "Augmentation parameters apply only for SAP networks.";
    }
    description
      "Augments nodes with AC provisioning details.";
    list ac {
      key "name";
      description
        "List of ACs.";
      leaf name {
        type string;
        description
          "A name that identifies the AC locally.";
      }
      leaf svc-ref {
        type ac-svc:attachment-circuit-reference;
        description
          "A reference to the AC as exposed at the service level.";
      }
      list profile {
        key "ac-profile-ref";
        description
          "List of AC profiles.";
        uses ac-profile-reference;
      }
      uses ac-hierarchy;
      leaf-list peer-sap-id {
        type string;
        description
          "One or more peer SAPs can be indicated.";
      }
      uses ac-common:redundancy-group;
      uses ac-common:service-status;
      uses ac-ntw:ac;
    }
  }

  augment "/nw:networks/nw:network/nw:node"
        + "/sap:service/sap:sap" {
    when '../../../nw:network-types/sap:sap-network' {
      description
        "Augmentation parameters apply only for SAP networks.";
    }
    description
      "Augments SAPs with AC provisioning details.";
    list ac {
      key "ac-ref";
      description
        "Specifies the ACs that are terminated by the SAP.";
      uses ac-ntw:attachment-circuit-reference;
    }
  }
}
<CODE ENDS>
]]></sourcecode>
    </section>
    <section anchor="security-considerations">

<!--[rfced] *AD - We note that there is some text in the
Security Considerations section that differs from the template on
<https://wiki.ietf.org/group/ops/yang-security-guidelines>. Please
review and let us know if the text is acceptable.

For example:
- This sentence is not present; should it be added?
  "There are no particularly sensitive RPC or action operations."
  If so, should it be at the end of the section?
  (Your reply to this question will also be applied to RFC 9836.)

From the guidelines page:
  "If the data model contains any particularly sensitive RPC or action
  operations, then those operations must be listed here, along with an
  explanation of the associated specific sensitivity or vulnerability
  concerns. Otherwise, state: 'There are no particularly sensitive RPC or
  action operations.'"

- The last two paragraphs (after the readable nodes section) do
not seem to be within a section of the template.
-->

      <name>Security Considerations</name>
      <!-- DNE begins -->
      <t>This section is modeled after the template described in in <xref section="3.7" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t>
      <t>The "ietf-ac-ntw" YANG module defines a data model that is
designed to be accessed via YANG-based management protocols, such as
   NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These protocols have to
   use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref target="RFC8446"/>, and
   QUIC <xref target="RFC9000"/>) and have to use mutual authentication.</t>
      <t>The Network Configuration Access Control Model (NACM) <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, "config true", which is the
   default).  These  All writable data nodes may are likely to be considered reasonably 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.
   Specifically, the
   The following
subtrees and data nodes have particular sensitivities/vulnerabilities:</t>
      <dl> sensitivities/vulnerabilities:</t><!-- DNE ends -->
      <dl spacing="normal" newline="false">
        <dt>'specific-provisioning-profiles':</dt>
        <dd>
          <t>This container includes a set of sensitive data that
 influence
 influences how an AC 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-teas-common-ac"/>.</t> target="RFC9833"/>.</t>
        </dd>
        <dt>'ac':</dt>
        <dd>
          <t>An attacker who is able to access network nodes can
 undertake various attacks, such as modify the attributes of an AC (e.g.,
 QoS, bandwidth, routing protocols, keying material), leading to
 malfunctioning of services that are delivered over that AC and therefore to Service Level
 Agreement (SLA) violations.  In addition, an attacker could
 attempt to add a new AC.
    : In addition to
    By also using NACM to prevent unauthorized access, such
 activity can be detected by adequately monitoring and tracking
 network configuration changes.</t>
        </dd>
      </dl>
      <!-- DNE begins -->
      <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. Specifically, the following
subtrees and data nodes have particular sensitivities/vulnerabilities:</t>
      <dl> sensitivities/vulnerabilities:</t><!-- DNE ends -->
      <dl spacing="normal" newline="false">
        <dt>'ac':</dt>
        <dd>
          <t>Unauthorized access to this subtree can disclose the identity
 of a customer 'peer-sap-id'.</t>
        </dd>
        <dt>'l2-connection' and 'ip-connection':</dt>
        <dd>
          <t>An attacker can retrieve
privacy-related information, which can be used to track a
customer.  Disclosing such information may be considered a
violation of the customer-provider trust relationship.</t>
        </dd>
        <dt>'keying-material' and 'customer-key-chain':</dt>
        <dd>
          <t>An attacker can retrieve the cryptographic keys
protecting an AC (routing, in particular). These keys could
be used to inject spoofed routing  advertisements.</t>
        </dd>
      </dl>
      <t>Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-chain') rely upon <xref target="RFC8177"/> for authentication purposes. As such, the AC network module inherits the security considerations discussed in <xref section="5" sectionFormat="of" target="RFC8177"/>. 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 AC network model, because it is not supported by the underlying device modules (e.g., <xref target="RFC8695"/>).</t>
      <t><xref target="sec-sec"/> specifies the the encryption to be applied to traffic for a given AC.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to register has registered the following URI in the "ns" subregistry within
   the "IETF XML Registry" <xref target="RFC3688"/>:</t>
      <artwork><![CDATA[
   URI:  urn:ietf:params:xml:ns:yang:ietf-ac-ntw
   Registrant Contact:  The IESG.
   XML:  N/A;

   <dl spacing="compact" newline="false">
     <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-ntw</dd>
     <dt>Registrant Contact:</dt><dd>The IESG.</dd>
     <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.
]]></artwork> namespace.</dd>
   </dl>
      <t>IANA is requested to register has registered the following YANG module in the "YANG Module
   Names" subregistry registry <xref target="RFC6020"/> within the "YANG Parameters" registry:</t>
      <artwork><![CDATA[
   Name:  ietf-ac-ntw
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-ac-ntw
   Prefix:  ac-ntw
   Maintained registry group:</t>

   <dl spacing="compact" newline="false">
     <dt>Name:</dt><dd>ietf-ac-ntw</dd>
     <dt>Maintained by IANA?  N
   Reference:  RFC XXXX
]]></artwork> IANA?</dt><dd>N</dd>
     <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-ntw</dd>
     <dt>Prefix:</dt><dd>ac-ntw</dd>
     <dt>Reference:</dt><dd>RFC 9835</dd>
   </dl>
    </section>
  </middle>
  <back>

<displayreference target="I-D.ietf-netmod-rfc8407bis" to ="YANG-GUIDELINES"/>

    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="IEEE802.1Qcp" target="https://doi.org/10.1109/IEEESTD.2018.8467507"> anchor="IEEE802.1Qcp">
          <front>
            <title>IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks--Amendment 30: YANG Data Model</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2018" month="September"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.1Qcp-2018"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8467507"/>
        </reference>

<!-- [RFC9834]
companion doc RFC9834 - draft-ietf-opsawg-teas-attachment-circuit-20
RFC Ed Queue as of 03/03/25.
-->
<reference anchor="I-D.ietf-opsawg-teas-attachment-circuit"> anchor="RFC9834" target="https://www.rfc-editor.org/info/rfc9834">
  <front>
    <title>YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)</title>
      <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> role="editor">
         <organization>Orange</organization>
      </author>
      <author initials="R." surname="Roberts" fullname="Richard Roberts" initials="R." surname="Roberts"> role="editor">
         <organization>Juniper</organization>
      </author>
      <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez de Dios" initials="O. G." surname="de Dios">
         <organization>Telefonica</organization>
      </author>
      <author fullname="Samier Barguil" initials="S." surname="Barguil"> surname="Barguil" fullname="Samier Barguil">
         <organization>Nokia</organization>
      </author>
      <author fullname="Bo Wu" initials="B." surname="Wu"> surname="Wu" fullname="Bo Wu">
         <organization>Huawei Technologies</organization>
      </author>
      <date day="23" month="January" year="2025"/>
            <abstract>
              <t>   Delivery of network services assumes that appropriate setup is
   provisioned over the links that connect customer termination points
   and a provider network.  The required setup to allow successful data
   exchange over these links is referred to as an attachment circuit
   (AC), while the underlying link is referred to as "bearer".

   This document specifies a YANG service data model for ACs.  This
   model can be used for the provisioning of ACs before or during
   service provisioning (e.g., Network Slice Service).

   The document also specifies a YANG service model for managing bearers
   over which ACs are established.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-attachment-circuit-20"/>
        </reference>
        <reference anchor="RFC9291">
          <front>
            <title>A YANG Network Data Model for Layer 2 VPNs</title>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="O. Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"/>
            <author fullname="S. Barguil" initials="S." surname="Barguil"/>
            <author fullname="L. Munoz" initials="L." surname="Munoz"/>
            <date month="September" year="2022"/>
            <abstract>
              <t>This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices.</t>
              <t>Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9291"/>
          <seriesInfo name="DOI" value="10.17487/RFC9291"/>
        </reference>
        <reference anchor="RFC9182">
          <front>
            <title>A YANG Network Data Model for Layer 3 VPNs</title>
            <author fullname="S. Barguil" initials="S." surname="Barguil"/>
            <author fullname="O. Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"/>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="L. Munoz" initials="L." surname="Munoz"/>
            <author fullname="A. Aguado" initials="A." surname="Aguado"/>
            <date month="February" year="2022"/>
            <abstract>
              <t>As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services.</t>
              <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 communication between a service orchestrator and a network controller/orchestrator.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9182"/>
          <seriesInfo name="DOI" value="10.17487/RFC9182"/>
        </reference>
        <reference anchor="RFC8345">
          <front>
            <title>A YANG Data Model for Network Topologies</title>
            <author fullname="A. Clemm" initials="A." surname="Clemm"/>
            <author fullname="J. Medved" initials="J." surname="Medved"/>
            <author fullname="R. Varga" initials="R." surname="Varga"/>
            <author fullname="N. Bahadur" initials="N." surname="Bahadur"/>
            <author fullname="H. Ananthakrishnan" initials="H." surname="Ananthakrishnan"/>
            <author fullname="X. Liu" initials="X." surname="Liu"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.</t>
            </abstract> month='August' year='2025'/>
  </front>
  <seriesInfo name="RFC" value="8345"/> value="9834"/>
  <seriesInfo name="DOI" value="10.17487/RFC8345"/> value="10.17487/RFC9834"/>
</reference>
        <reference anchor="RFC9408">
          <front>
            <title>A YANG Network Data Model for Service Attachment Points (SAPs)</title>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/>
            <author fullname="S. Barguil" initials="S." surname="Barguil"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <author fullname="V. Lopez" initials="V." surname="Lopez"/>
            <date month="June" year="2023"/>
            <abstract>
              <t>This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks).</t>
              <t>This document augments the 'ietf-network' data model defined in

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9291.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9182.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8345.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9408.xml"/>

<!-- [RFC9833]
companion doc RFC9833
draft-ietf-opsawg-teas-common-ac-15
RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, such Ed Queue as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are supported in the SAP data model.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9408"/>
          <seriesInfo name="DOI" value="10.17487/RFC9408"/>
        </reference> of 03/03/25.
-->

<reference anchor="I-D.ietf-opsawg-teas-common-ac"> anchor="RFC9833" target="https://www.rfc-editor.org/info/rfc9833">
  <front>
      <title>A Common YANG Data Model for Attachment Circuits</title>
      <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> role="editor">
         <organization>Orange</organization>
      </author>
      <author initials="R." surname="Roberts" fullname="Richard Roberts" initials="R." surname="Roberts"> role="editor">
         <organization>Juniper</organization>
      </author>
      <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez de Dios" initials="O. G." surname="de Dios">
         <organization>Telefonica</organization>
      </author>
      <author fullname="Samier Barguil" initials="S." surname="Barguil"> surname="Barguil Giraldo" fullname="Samier Barguil Giraldo">
         <organization>Nokia</organization>
      </author>
      <author fullname="Bo Wu" initials="B." surname="Wu"> surname="Wu" fullname="Bo Wu">
         <organization>Huawei Technologies</organization>
      </author>
    <date day="23" month="January" year="2025"/>
            <abstract>
              <t>   The document specifies a common attachment circuits (ACs) YANG model,
   which is designed to be reusable by other models.  This design is
   meant to ensure consistent AC structures among models that manipulate
   ACs.  For example, this common model can be reused by service models
   to expose ACs as a service, service models that require binding a
   service to a set of ACs, network and device models to provision ACs,
   etc.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-common-ac-15"/>
        </reference>
        <reference anchor="RFC7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
        <reference anchor="RFC8342">
          <front>
            <title>Network Management Datastore Architecture (NMDA)</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/>
            <author fullname="P. Shafer" initials="P." surname="Shafer"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="R. Wilton" initials="R." surname="Wilton"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8342"/>
          <seriesInfo name="DOI" value="10.17487/RFC8342"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8343">
          <front>
            <title>A YANG Data Model for Interface Management</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).</t>
              <t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</t>
              <t>This document obsoletes RFC 7223.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8343"/>
          <seriesInfo name="DOI" value="10.17487/RFC8343"/>
        </reference>
        <reference anchor="RFC6991">
          <front>
            <title>Common YANG Data Types</title>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <date month="July" year="2013"/>
            <abstract>
              <t>This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.</t>
            </abstract> month='August' year='2025'/>
  </front>
  <seriesInfo name="RFC" value="6991"/> value="9833"/>
  <seriesInfo name="DOI" value="10.17487/RFC6991"/>
        </reference>
        <reference anchor="RFC8177">
          <front>
            <title>YANG Data Model for Key Chains</title>
            <author fullname="A. Lindem" initials="A." role="editor" surname="Lindem"/>
            <author fullname="Y. Qu" initials="Y." surname="Qu"/>
            <author fullname="D. Yeung" initials="D." surname="Yeung"/>
            <author fullname="I. Chen" initials="I." surname="Chen"/>
            <author fullname="J. Zhang" initials="J." surname="Zhang"/>
            <date month="June" year="2017"/>
            <abstract>
              <t>This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8177"/>
          <seriesInfo name="DOI" value="10.17487/RFC8177"/>
        </reference>
        <reference anchor="RFC8341">
          <front>
            <title>Network Configuration Access Control Model</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t>
              <t>This document obsoletes RFC 6536.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="91"/>
          <seriesInfo name="RFC" value="8341"/>
          <seriesInfo name="DOI" value="10.17487/RFC8341"/>
        </reference>
        <reference anchor="RFC8294">
          <front>
            <title>Common YANG Data Types for the Routing Area</title>
            <author fullname="X. Liu" initials="X." surname="Liu"/>
            <author fullname="Y. Qu" initials="Y." surname="Qu"/>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <author fullname="C. Hopps" initials="C." surname="Hopps"/>
            <author fullname="L. Berger" initials="L." surname="Berger"/>
            <date month="December" year="2017"/>
            <abstract>
              <t>This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8294"/>
          <seriesInfo name="DOI" value="10.17487/RFC8294"/>
        </reference>
        <reference anchor="RFC9067">
          <front>
            <title>A YANG Data Model for Routing Policy</title>
            <author fullname="Y. Qu" initials="Y." surname="Qu"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <author fullname="X. Liu" initials="X." surname="Liu"/>
            <date month="October" year="2021"/>
            <abstract>
              <t>This document defines a YANG data model for configuring and managing routing policies in a vendor-neutral way. The model provides a generic routing policy framework that can be extended for specific routing protocols using the YANG 'augment' mechanism.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9067"/>
          <seriesInfo name="DOI" value="10.17487/RFC9067"/>
        </reference>
        <reference anchor="RFC9181">
          <front>
            <title>A Common YANG Data Model for Layer 2 and Layer 3 VPNs</title>
            <author fullname="S. Barguil" initials="S." surname="Barguil"/>
            <author fullname="O. Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"/>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="February" year="2022"/>
            <abstract>
              <t>This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN network models.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9181"/>
          <seriesInfo name="DOI" value="10.17487/RFC9181"/>
        </reference>
        <reference anchor="RFC4364">
          <front>
            <title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="February" year="2006"/>
            <abstract>
              <t>This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4364"/>
          <seriesInfo name="DOI" value="10.17487/RFC4364"/>
        </reference>
        <reference anchor="RFC5880">
          <front>
            <title>Bidirectional Forwarding Detection (BFD)</title>
            <author fullname="D. Katz" initials="D." surname="Katz"/>
            <author fullname="D. Ward" initials="D." surname="Ward"/>
            <date month="June" year="2010"/>
            <abstract>
              <t>This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5880"/>
          <seriesInfo name="DOI" value="10.17487/RFC5880"/>
        </reference>
        <reference anchor="RFC8077">
          <front>
            <title>Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)</title>
            <author fullname="L. Martini" initials="L." role="editor" surname="Martini"/>
            <author fullname="G. Heron" initials="G." role="editor" surname="Heron"/>
            <date month="February" year="2017"/>
            <abstract>
              <t>Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents.</t>
              <t>This document is a rewrite of RFC 4447 for publication as an Internet Standard.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="84"/>
          <seriesInfo name="RFC" value="8077"/>
          <seriesInfo name="DOI" value="10.17487/RFC8077"/>
        </reference>
        <reference anchor="RFC5701">
          <front>
            <title>IPv6 Address Specific BGP Extended Community Attribute</title>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="November" year="2009"/>
            <abstract>
              <t>Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support an IPv6 Address Specific Extended Community. The lack of an IPv6 Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, the IPv6 Address Specific Extended Community, that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. [STANDARDS TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5701"/>
          <seriesInfo name="DOI" value="10.17487/RFC5701"/>
        </reference>
        <reference anchor="RFC4271">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="T. Li" initials="T." role="editor" surname="Li"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t>The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t>
              <t>BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t>
              <t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4271"/>
          <seriesInfo name="DOI" value="10.17487/RFC4271"/>
        </reference>
        <reference anchor="RFC5925">
          <front>
            <title>The TCP Authentication Option</title>
            <author fullname="J. Touch" initials="J." surname="Touch"/>
            <author fullname="A. Mankin" initials="A." surname="Mankin"/>
            <author fullname="R. Bonica" initials="R." surname="Bonica"/>
            <date month="June" year="2010"/>
            <abstract>
              <t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5925"/>
          <seriesInfo name="DOI" value="10.17487/RFC5925"/>
        </reference>
        <reference anchor="RFC4577">
          <front>
            <title>OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="P. Psenak" initials="P." surname="Psenak"/>
            <author fullname="P. Pillay-Esnault" initials="P." surname="Pillay-Esnault"/>
            <date month="June" year="2006"/>
            <abstract>
              <t>Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol.</t>
              <t>This document updates RFC 4364. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4577"/>
          <seriesInfo name="DOI" value="10.17487/RFC4577"/>
        </reference>
        <reference anchor="RFC6565">
          <front>
            <title>OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol</title>
            <author fullname="P. Pillay-Esnault" initials="P." surname="Pillay-Esnault"/>
            <author fullname="P. Moyer" initials="P." surname="Moyer"/>
            <author fullname="J. Doyle" initials="J." surname="Doyle"/>
            <author fullname="E. Ertekin" initials="E." surname="Ertekin"/>
            <author fullname="M. Lundberg" initials="M." surname="Lundberg"/>
            <date month="June" year="2012"/>
            <abstract>
              <t>Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6 VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as PE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6565"/>
          <seriesInfo name="DOI" value="10.17487/RFC6565"/>
        </reference>
        <reference anchor="RFC5709">
          <front>
            <title>OSPFv2 HMAC-SHA Cryptographic Authentication</title>
            <author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
            <author fullname="V. Manral" initials="V." surname="Manral"/>
            <author fullname="M. Fanto" initials="M." surname="Fanto"/>
            <author fullname="R. White" initials="R." surname="White"/>
            <author fullname="M. Barnes" initials="M." surname="Barnes"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="R. Atkinson" initials="R." surname="Atkinson"/>
            <date month="October" year="2009"/>
            <abstract>
              <t>This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5709"/>
          <seriesInfo name="DOI" value="10.17487/RFC5709"/>
        </reference>
        <reference anchor="RFC7474">
          <front>
            <title>Security Extension for OSPFv2 When Using Manual Key Management</title>
            <author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
            <author fullname="S. Hartman" initials="S." surname="Hartman"/>
            <author fullname="D. Zhang" initials="D." surname="Zhang"/>
            <author fullname="A. Lindem" initials="A." role="editor" surname="Lindem"/>
            <date month="April" year="2015"/>
            <abstract>
              <t>The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.</t>
              <t>This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7474"/>
          <seriesInfo name="DOI" value="10.17487/RFC7474"/>
        </reference>
        <reference anchor="RFC7166">
          <front>
            <title>Supporting Authentication Trailer for OSPFv3</title>
            <author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
            <author fullname="V. Manral" initials="V." surname="Manral"/>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <date month="March" year="2014"/>
            <abstract>
              <t>Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.</t>
              <t>The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7166"/>
          <seriesInfo name="DOI" value="10.17487/RFC7166"/>
        </reference>
        <reference anchor="RFC2453">
          <front>
            <title>RIP Version 2</title>
            <author fullname="G. Malkin" initials="G." surname="Malkin"/>
            <date month="November" year="1998"/>
            <abstract>
              <t>This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="56"/>
          <seriesInfo name="RFC" value="2453"/>
          <seriesInfo name="DOI" value="10.17487/RFC2453"/>
        </reference>
        <reference anchor="RFC2080">
          <front>
            <title>RIPng for IPv6</title>
            <author fullname="G. Malkin" initials="G." surname="Malkin"/>
            <author fullname="R. Minnear" initials="R." surname="Minnear"/>
            <date month="January" year="1997"/>
            <abstract>
              <t>This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in the IPv4 Internet [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2080"/>
          <seriesInfo name="DOI" value="10.17487/RFC2080"/>
        </reference>
        <reference anchor="RFC9568">
          <front>
            <title>Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6</title>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <author fullname="A. Dogra" initials="A." surname="Dogra"/>
            <date month="April" year="2024"/>
            <abstract>
              <t>This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It obsoletes RFC 5798, which previously specified VRRP (version 3). RFC 5798 obsoleted RFC 3768, which specified VRRP (version 2) for IPv4. VRRP specifies an election protocol that dynamically assigns responsibility for a Virtual Router to one of the VRRP Routers on a LAN. The VRRP Router controlling the IPv4 or IPv6 address(es) associated with a Virtual Router is called the Active Router, and it forwards packets routed to these IPv4 or IPv6 addresses. Active Routers are configured with virtual IPv4 or IPv6 addresses, and Backup Routers infer the address family of the virtual addresses being advertised based on the IP protocol version. Within a VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address families are independent of one another and always treated as separate Virtual Router instances. The election process provides dynamic failover in the forwarding responsibility should the Active Router become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup Routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9568"/>
          <seriesInfo name="DOI" value="10.17487/RFC9568"/>
        </reference>
        <reference anchor="RFC3688">
          <front>
            <title>The IETF XML Registry</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <date month="January" year="2004"/>
            <abstract>
              <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC6020">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="October" year="2010"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6020"/>
          <seriesInfo name="DOI" value="10.17487/RFC6020"/> value="10.17487/RFC9833"/>
</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8177.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8294.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9067.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9181.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8077.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5701.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4577.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6565.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5709.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7474.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7166.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2453.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2080.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9568.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4252.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC7665">
          <front>
            <title>Service Function Chaining (SFC) Architecture</title>
            <author fullname="J. Halpern" initials="J." role="editor" surname="Halpern"/>
            <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro"/>
            <date month="October" year="2015"/>
            <abstract>
              <t>This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7665"/>
          <seriesInfo name="DOI" value="10.17487/RFC7665"/>
        </reference>
        <reference anchor="RFC9543">
          <front>
            <title>A Framework for Network Slices in Networks Built from IETF Technologies</title>
            <author fullname="A. Farrel" initials="A." role="editor" surname="Farrel"/>
            <author fullname="J. Drake" initials="J." role="editor" surname="Drake"/>
            <author fullname="R. Rokui" initials="R." surname="Rokui"/>
            <author fullname="S. Homma" initials="S." surname="Homma"/>
            <author fullname="K. Makhijani" initials="K." surname="Makhijani"/>
            <author fullname="L. Contreras" initials="L." surname="Contreras"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <date month="March" year="2024"/>
            <abstract>
              <t>This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context.</t>
              <t>The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security.</t>
              <t>This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9543.xml"/>
<!-- [RFC9836]
draft-ietf-opsawg-ac-lxsm-lxnm-glue-14
IESG State: RFC Ed Queue as of IETF Network Slices.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9543"/>
          <seriesInfo name="DOI" value="10.17487/RFC9543"/>
        </reference> 03/03/25. -->
<reference anchor="I-D.ietf-opsawg-ac-lxsm-lxnm-glue"> anchor="RFC9836"
target="https://www.rfc-editor.org/info/rfc9836">
   <front>
      <title>A YANG Data Model for Augmenting VPN Service and Network Models with Attachment
Circuits</title>
      <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> role="editor">
         <organization>Orange</organization>
      </author>
      <author fullname="Richard Roberts" initials="R." surname="Roberts"> surname="Roberts" fullname="Richard Roberts">
         <organization>Juniper</organization>
      </author>
      <author fullname="Samier Barguil" initials="S." surname="Barguil"> surname="Barguil" fullname="Samier Barguil">
         <organization>Nokia</organization>
      </author>
      <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez de Dios" initials="O. G." surname="de Dios">
         <organization>Telefonica</organization>
      </author>
      <date day="9" month="January" year="2025"/>
            <abstract>
              <t>   The document specifies a module that updates existing service (i.e.,
   the Layer 2 Service Model (L2SM) and the Layer 3 Service Model
   (L3SM)) and network (i.e., the Layer 2 Network Model (L2NM) and the
   Layer 3 Network Model (L3NM)) Virtual Private Network (VPN) modules
   with the required information to bind specific VPN services to
   attachment circuits (ACs) that are created using the AC service
   ("ietf-ac-svc") and network ("ietf-ac-ntw") models.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ac-lxsm-lxnm-glue-13"/>
        </reference>
        <reference anchor="RFC8969">
          <front>
            <title>A Framework for Automating Service and Network Management with YANG</title>
            <author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="D. Lopez" initials="D." surname="Lopez"/>
            <author fullname="C. Xie" initials="C." surname="Xie"/>
            <author fullname="L. Geng" initials="L." surname="Geng"/>
            <date month="January" year="2021"/>
            <abstract>
              <t>Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance.</t>
              <t>This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8969"/>
          <seriesInfo name="DOI" value="10.17487/RFC8969"/>
        </reference>
        <reference anchor="RFC8340">
          <front>
            <title>YANG Tree Diagrams</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="215"/>
          <seriesInfo name="RFC" value="8340"/>
          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
        </reference>
        <reference anchor="RFC8466">
          <front>
            <title>A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery</title>
            <author fullname="B. Wen" initials="B." surname="Wen"/>
            <author fullname="G. Fioccola" initials="G." role="editor" surname="Fioccola"/>
            <author fullname="C. Xie" initials="C." surname="Xie"/>
            <author fullname="L. Jalil" initials="L." surname="Jalil"/>
            <date month="October" year="2018"/>
            <abstract>
              <t>This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.</t>
              <t>The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624.</t>
              <t>The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8466"/>
          <seriesInfo name="DOI" value="10.17487/RFC8466"/>
        </reference>
        <reference anchor="RFC8299">
          <front>
            <title>YANG Data Model for L3VPN Service Delivery</title>
            <author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="L. Tomotaki" initials="L." surname="Tomotaki"/>
            <author fullname="K. Ogaki" initials="K." surname="Ogaki"/>
            <date month="January" year="2018"/>
            <abstract>
              <t>This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.</t>
              <t>This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8299"/>
          <seriesInfo name="DOI" value="10.17487/RFC8299"/>
        </reference>
        <reference anchor="RFC3644">
          <front>
            <title>Policy Quality of Service (QoS) Information Model</title>
            <author fullname="Y. Snir" initials="Y." surname="Snir"/>
            <author fullname="Y. Ramberg" initials="Y." surname="Ramberg"/>
            <author fullname="J. Strassner" initials="J." surname="Strassner"/>
            <author fullname="R. Cohen" initials="R." surname="Cohen"/>
            <author fullname="B. Moore" initials="B." surname="Moore"/>
            <date month="November" year="2003"/>
            <abstract>
              <t>This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies. This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3644"/>
          <seriesInfo name="DOI" value="10.17487/RFC3644"/>
        </reference>
        <reference anchor="RFC4862">
          <front>
            <title>IPv6 Stateless Address Autoconfiguration</title>
            <author fullname="S. Thomson" initials="S." surname="Thomson"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <author fullname="T. Jinmei" initials="T." surname="Jinmei"/>
            <date month="September" year="2007"/>
            <abstract>
              <t>This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4862"/>
          <seriesInfo name="DOI" value="10.17487/RFC4862"/>
        </reference>
        <reference anchor="RFC9234">
          <front>
            <title>Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages</title>
            <author fullname="A. Azimov" initials="A." surname="Azimov"/>
            <author fullname="E. Bogomazov" initials="E." surname="Bogomazov"/>
            <author fullname="R. Bush" initials="R." surname="Bush"/>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <author fullname="K. Sriram" initials="K." surname="Sriram"/>
            <date month="May" year="2022"/>
            <abstract>
              <t>Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9234"/>
          <seriesInfo name="DOI" value="10.17487/RFC9234"/>
        </reference>
        <reference anchor="RFC4552">
          <front>
            <title>Authentication/Confidentiality for OSPFv3</title>
            <author fullname="M. Gupta" initials="M." surname="Gupta"/>
            <author fullname="N. Melam" initials="N." surname="Melam"/>
            <date month="June" year="2006"/>
            <abstract>
              <t>This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4552"/>
          <seriesInfo name="DOI" value="10.17487/RFC4552"/>
        </reference>
        <reference anchor="RFC9127">
          <front>
            <title>YANG Data Model for Bidirectional Forwarding Detection (BFD)</title>
            <author fullname="R. Rahman" initials="R." role="editor" surname="Rahman"/>
            <author fullname="L. Zheng" initials="L." role="editor" surname="Zheng"/>
            <author fullname="M. Jethanandani" initials="M." role="editor" surname="Jethanandani"/>
            <author fullname="S. Pallagatti" initials="S." surname="Pallagatti"/>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <date month="October" year="2021"/>
            <abstract>
              <t>This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).</t>
              <t>The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) (RFC 8342).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9127"/>
          <seriesInfo name="DOI" value="10.17487/RFC9127"/>
        </reference>
        <reference anchor="RFC7880">
          <front>
            <title>Seamless Bidirectional Forwarding Detection (S-BFD)</title>
            <author fullname="C. Pignataro" initials="C." surname="Pignataro"/>
            <author fullname="D. Ward" initials="D." surname="Ward"/>
            <author fullname="N. Akiya" initials="N." surname="Akiya"/>
            <author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
            <author fullname="S. Pallagatti" initials="S." surname="Pallagatti"/>
            <date month="July" year="2016"/>
            <abstract>
              <t>This document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.</t>
              <t>This document updates RFC 5880.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7880"/>
          <seriesInfo name="DOI" value="10.17487/RFC7880"/>
        </reference>
        <reference anchor="I-D.ietf-netmod-rfc8407bis">
          <front>
            <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title>
            <author fullname="Andy Bierman" initials="A." surname="Bierman">
              <organization>YumaWorks</organization>
            </author>
            <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
              <organization>Orange</organization>
            </author>
            <author fullname="Qin Wu" initials="Q." surname="Wu">
              <organization>Huawei</organization>
            </author>
            <date day="14" month="January" year="2025"/>
            <abstract>
              <t>   This memo provides guidelines for authors and reviewers of
   specifications containing YANG modules, including IANA-maintained
   modules.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG modules.  This document obsoletes
   RFC 8407.

   Also, this document updates RFC 8126 by providing additional
   guidelines for writing the IANA considerations for RFCs that specify
   IANA-maintained modules.  The document also updates RFC 6020 by
   clarifying how modules and their revisions are handled by IANA.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis-22"/>
        </reference>
        <reference anchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
        <reference anchor="RFC4252">
          <front>
            <title>The Secure Shell (SSH) Authentication Protocol</title>
            <author fullname="T. Ylonen" initials="T." surname="Ylonen"/>
            <author fullname="C. Lonvick" initials="C." role="editor" surname="Lonvick"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4252"/>
          <seriesInfo name="DOI" value="10.17487/RFC4252"/>
        </reference>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract> year="2025" />
   </front>
   <seriesInfo name="RFC" value="9000"/> value="9836" />
  <seriesInfo name="DOI" value="10.17487/RFC9000"/> value="10.17487/RFC9836"/>
</reference>
        <reference anchor="RFC8695">
          <front>
            <title>A YANG Data Model for the Routing Information Protocol (RIP)</title>
            <author fullname="X. Liu" initials="X." surname="Liu"/>
            <author fullname="P. Sarda" initials="P." surname="Sarda"/>
            <author fullname="V. Choudhary" initials="V." surname="Choudhary"/>
            <date month="February" year="2020"/>
            <abstract>
              <t>This document describes a data model for the management

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8969.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8466.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8299.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3644.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9234.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4552.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9127.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7880.xml"/>
<!-- [I-D.ietf-netmod-rfc8407bis]
draft-ietf-netmod-rfc8407bis-22
IESG State: Publication Requested as of the Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. The data model includes definitions for configuration, operational state, and Remote Procedure Calls (RPCs).</t>
              <t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8695"/>
          <seriesInfo name="DOI" value="10.17487/RFC8695"/>
        </reference> 03/03/25. -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-rfc8407bis.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8695.xml"/>
      </references>
    </references>
    <?line 4195?>

<section anchor="sec-examples">
      <name>Examples</name>
      <section anchor="vpls">
        <name>VPLS</name>
        <t>Let us consider the example depicted in <xref target="ex-topo"/> with two customer terminating points (CE1 and CE2). Let us also assume that the bearers to attach these CEs to the provider network are already in place. References to the identify these bearers are shown in the figure.</t>
        <figure anchor="ex-topo">
          <name>Topology Example</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="128" width="488" viewBox="0 0 488 128" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,64 L 8,80" fill="none" stroke="black"/>
                <path d="M 48,48 L 48,64" fill="none" stroke="black"/>
                <path d="M 80,72 L 80,96" fill="none" stroke="black"/>
                <path d="M 104,32 L 104,80" fill="none" stroke="black"/>
                <path d="M 152,32 L 152,80" fill="none" stroke="black"/>
                <path d="M 184,32 L 184,112" fill="none" stroke="black"/>
                <path d="M 304,32 L 304,112" fill="none" stroke="black"/>
                <path d="M 336,32 L 336,80" fill="none" stroke="black"/>
                <path d="M 384,32 L 384,80" fill="none" stroke="black"/>
                <path d="M 416,72 L 416,96" fill="none" stroke="black"/>
                <path d="M 440,64 L 440,80" fill="none" stroke="black"/>
                <path d="M 480,48 L 480,64" fill="none" stroke="black"/>
                <path d="M 104,32 L 152,32" fill="none" stroke="black"/>
                <path d="M 184,32 L 304,32" fill="none" stroke="black"/>
                <path d="M 336,32 L 384,32" fill="none" stroke="black"/>
                <path d="M 24,48 L 48,48" fill="none" stroke="black"/>
                <path d="M 152,46 L 184,46" fill="none" stroke="black"/>
                <path d="M 152,50 L 184,50" fill="none" stroke="black"/>
                <path d="M 304,46 L 336,46" fill="none" stroke="black"/>
                <path d="M 304,50 L 336,50" fill="none" stroke="black"/>
                <path d="M 456,48 L 480,48" fill="none" stroke="black"/>
                <path d="M 48,64 L 104,64" fill="none" stroke="black"/>
                <path d="M 384,64 L 440,64" fill="none" stroke="black"/>
                <path d="M 8,80 L 32,80" fill="none" stroke="black"/>
                <path d="M 104,80 L 152,80" fill="none" stroke="black"/>
                <path d="M 336,80 L 384,80" fill="none" stroke="black"/>
                <path d="M 440,80 L 464,80" fill="none" stroke="black"/>
                <path d="M 184,112 L 304,112" fill="none" stroke="black"/>
                <path d="M 24,48 C 15.16936,48 8,55.16936 8,64" fill="none" stroke="black"/>
                <path d="M 456,48 C 447.16936,48 440,55.16936 440,64" fill="none" stroke="black"/>
                <path d="M 32,80 C 40.83064,80 48,72.83064 48,64" fill="none" stroke="black"/>
                <path d="M 464,80 C 472.83064,80 480,72.83064 480,64" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="424,72 412,66.4 412,77.6" fill="black" transform="rotate(270,416,72)"/>
                <polygon class="arrowhead" points="88,72 76,66.4 76,77.6" fill="black" transform="rotate(270,80,72)"/>
                <g class="text">
                  <text x="128" y="52">PE1</text>
                  <text x="360" y="52">PE2</text>
                  <text x="32" y="68">CE1</text>
                  <text x="128" y="68">"450"</text>
                  <text x="244" y="68">MPLS</text>
                  <text x="360" y="68">"451"</text>
                  <text x="464" y="68">CE2</text>
                  <text x="244" y="100">Core</text>
                  <text x="80" y="116">Bearer:1234</text>
                  <text x="424" y="116">Bearer:5678</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
            .-----.   .--------------.   .-----.
 .---.      | PE1 +===+              +===+ PE2 |       .---.
| CE1+------+"450"|   |     MPLS     |   |"451"+------+ CE2|
'---'    ^  '-----'   |              |   '-----'   ^  '---'
         |            |     Core     |             |
    Bearer:1234       '--------------'         Bearer:5678
]]></artwork>
          </artset>
        </figure>
        <t>The AC service model <xref target="I-D.ietf-opsawg-teas-attachment-circuit"/> target="RFC9834"/> can be used by the provider to manage and expose the ACs over existing bearers as shown in <xref target="ex-ac"/>.</t>
        <figure anchor="ex-ac">
          <name>ACs Created Using ACaaS</name>
          <artwork><![CDATA[
          <sourcecode type="json"><![CDATA[
{
  "ietf-ac-svc:attachment-circuits": {
    "ac-group-profile": [
      {
        "name": "an-ac-profile",
        "l2-connection": {
          "encapsulation": {
            "type": "ietf-vpn-common:dot1q",
            "dot1q": {
              "tag-type": "ietf-vpn-common:c-vlan",
              "cvlan-id": 550
            }
          }
        },
        "service": {
          "mtu": 1550,
          "svc-pe-to-ce-bandwidth": {
            "bandwidth": [
              {
                "bw-type": "ietf-vpn-common:bw-per-port",
                "cir": "20480000"
              }
            ]
          },
          "svc-ce-to-pe-bandwidth": {
            "bandwidth": [
              {
                "bw-type": "ietf-vpn-common:bw-per-port",
                "cir": "20480000"
              }
            ]
          },
          "qos": {
            "qos-profiles": {
              "qos-profile": [
                {
                  "profile": "QoS_Profile_A",
                  "direction": "ietf-vpn-common:both"
                }
              ]
            }
          }
        }
      }
    ],
    "ac": [
      {
        "name": "ac-1",
        "description": "First attachment",
        "ac-group-profile": [
          "an-ac-profile"
        ],
        "l2-connection": {
          "bearer-reference": "1234"
        }
      },
      {
        "name": "ac-2",
        "description": "Second attachment",
        "ac-group-profile": [
          "an-ac-profile"
        ],
        "l2-connection": {
          "bearer-reference": "5678"
        }
      }
    ]
  }
}
]]></artwork>
]]></sourcecode>
        </figure>
        <t>The provisioned AC at PE1 can be retrieved using the AC network model as depicted in <xref target="ex-acntw-query"/>. A similar query can be used for the AC at PE2.</t>
        <figure anchor="ex-acntw-query">
          <name>Example of AC Network Response (Message Body)</name>
          <artwork><![CDATA[
          <sourcecode type="json"><![CDATA[
{
   "ietf-ac-ntw:ac":[
      {
         "name":"ac-11",
         "svc-ref":"ac-1",
         "peer-sap-id":[
            "ce-1"
         ],
         "status":{
            "admin-status":{
               "status":"ietf-vpn-common:admin-up"
            },
            "oper-status":{
               "status":"ietf-vpn-common:op-up"
            }
         },
         "l2-connection":{
            "encapsulation":{
               "encap-type":"ietf-vpn-common:dot1q",
               "dot1q":{
                  "tag-type":"ietf-vpn-common:c-vlan",
                  "cvlan-id":550
               }
            },
            "bearer-reference":"1234"
         },
         "service":{
            "mtu":1550,
            "svc-pe-to-ce-bandwidth":{
               "bandwidth":[
                  {
                     "bw-type": "ietf-vpn-common:bw-per-port",
                     "cir":"20480000"
                  }
               ]
            },
            "svc-ce-to-pe-bandwidth":{
               "bandwidth":[
                  {
                     "bw-type": "ietf-vpn-common:bw-per-port",
                     "cir":"20480000"
                  }
               ]
            },
            "qos":{
               "qos-profiles":{
                  "qos-profile":[
                     {
                        "qos-profile-ref":"QoS_Profile_A",
                        "network-ref":"example:an-id",
                        "direction":"ietf-vpn-common:both"
                     }
                  ]
               }
            }
         }
      }
   ]
}
]]></artwork>
]]></sourcecode>
        </figure>
        <t>Also, the AC network model can be used to retrieve the list of SAPs to which the ACs are bound as shown in <xref target="ex-acntw-query"/>.</t>
        <figure anchor="ex-acntw-query-2">
          <name>Example of AC Network Response to Retrieve the SAP (Message Body)</name>
          <artwork><![CDATA[
          <sourcecode type="json"><![CDATA[
{
   "ietf-sap-ntw:service":[
      {
         "service-type":"ietf-vpn-common:vpls",
         "sap":[
            {
               "sap-id":"sap#1",
               "peer-sap-id":[
                  "ce-1"
               ],
               "description":"A parent SAP",
               "attachment-interface":"GE0/6/1",
               "interface-type":"ietf-sap-ntw:phy",
               "role":"ietf-sap-ntw:uni",
               "allows-child-saps":true,
               "sap-status":{
                  "status":"ietf-vpn-common:op-up"
               }
            },
            {
               "sap-id":"sap#11",
               "description":"A child SAP",
               "parent-termination-point":"GE0/6/4",
               "attachment-interface":"GE0/6/4.2",
               "interface-type":"ietf-sap-ntw:logical",
               "encapsulation-type":"ietf-vpn-common:vlan-type",
               "sap-status":{
                  "status":"ietf-vpn-common:op-up"
               },
               "ietf-ac-ntw:ac":[
                  {
                     "ac-ref":"ac-1",
                     "node-ref":"example:pe2",
                     "network-ref":"example:an-id"
                  }
               ]
            }
         ]
      }
   ]
}
]]></artwork>
]]></sourcecode>
        </figure>
      </section>
      <section anchor="parent-ac">
        <name>Parent AC</name>
        <t>In reference to the topology depicted in <xref target="sap-ac-ntw"/>, PE2 has a SAP which that terminates an AC with two peer SAPs (CE2 and CE5). In order to control data that is specific to each of these peer SAPs over the same AC, child ACs can be instantiated as depicted in <xref target="ex-parent-ac"/>.</t>
        <figure anchor="ex-parent-ac">
          <name>Example of Child ACs</name>
          <artwork><![CDATA[
          <sourcecode type="json"><![CDATA[
{
   "ietf-ac-ntw:ac":[
      {
         "name":"ac-1",
         "peer-sap-id":[
            "CE2",
            "CE5"
         ],
         "status":{
            "admin-status":{
               "status":"ietf-vpn-common:admin-up"
            },
            "oper-status":{
               "status":"ietf-vpn-common:op-up"
            }
         },
         "l2-connection":{
            "encapsulation":{
               "encap-type":"ietf-vpn-common:dot1q",
               "dot1q":{
                  "tag-type":"ietf-vpn-common:c-vlan",
                  "cvlan-id":550
               }
            },
            "bearer-reference":"1234"
         }
      },
      {
         "name":"ac-1-to-ce2",
         "parent-ref":{
            "ac-ref":"ac-1",
            "node-ref":"example:pe2",
            "network-ref":"example:an-id"
         },
         "peer-sap-id":[
            "CE2"
         ]
      },
      {
         "name":"ac-1-to-ce5",
         "parent-ref":{
            "ac-ref":"ac-1",
            "node-ref":"example:pe2",
            "network-ref":"example:an-id"
         },
         "peer-sap-id":[
            "CE5"
         ]
      }
   ]
}
]]></artwork>
]]></sourcecode>
        </figure>
        <t><xref target="ex-parent-ac-sap"/> shows how to bind the parent AC to a SAP.</t>
        <figure anchor="ex-parent-ac-sap">
          <name>Example of Binding Parent AC ACs to SAPs</name>
          <artwork><![CDATA[
          <sourcecode type="json"><![CDATA[
{
   "ietf-sap-ntw:service":[
      {
         "service-type":"ietf-vpn-common:l3vpn",
         "sap":[
            {
               "sap-id":"sap#14587",
               "description":"A SAP",
               "parent-termination-point":"GE0/6/4",
               "attachment-interface":"GE0/6/4.2",
               "interface-type":"ietf-sap-ntw:logical",
               "encapsulation-type":"ietf-vpn-common:vlan-type",
               "sap-status":{
                  "status":"ietf-vpn-common:op-up"
               },
               "ietf-ac-ntw:ac":[
                  {
                     "ac-ref":"ac-1",
                     "node-ref":"example:pe2",
                     "network-ref":"example:an-id"
                  }
               ]
            }
         ]
      }
   ]
}
]]></artwork>
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="AC-Ntw-Tree">
      <name>Full Tree</name>
      <artwork><![CDATA[
      <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw

  augment /nw:networks/nw:network:
    +--rw specific-provisioning-profiles
    |  +--rw valid-provider-identifiers
    |     +--rw encryption-profile-identifier* [id]
    |     |  +--rw id    string
    |     +--rw qos-profile-identifier* [id]
    |     |  +--rw id    string
    |     +--rw failure-detection-profile-identifier* [id]
    |     |  +--rw id    string
    |     +--rw forwarding-profile-identifier* [id]
    |     |  +--rw id    string
    |     +--rw routing-profile-identifier* [id]
    |        +--rw id    string
    +--rw ac-profile* [name]
       +--rw name                 string
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id      string
       |     +--rw type?   identityref
       |     +--rw bgp {vpn-common:rtg-bgp}?
       |     |  +--rw peer-groups
       |     |     +--rw peer-group* [name]
       |     |        +--rw name                      string
       |     |        +--rw description?              string
       |     |        +--rw apply-policy
       |     |        |  +--rw import-policy*           leafref
       |     |        |  +--rw default-import-policy?
       |     |        |  |       default-policy-type
       |     |        |  +--rw export-policy*           leafref
       |     |        |  +--rw default-export-policy?
       |     |        |          default-policy-type
       |     |        +--rw local-as?                 inet:as-number
       |     |        +--rw peer-as                   inet:as-number
       |     |        +--rw address-family?           identityref
       |     |        +--rw role?                     identityref
       |     |        +--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 enabled?          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 ospf {vpn-common:rtg-ospf}?
       |     |  +--rw address-family?   identityref
       |     |  +--rw area-id           yang:dotted-quad
       |     |  +--rw metric?           uint16
       |     |  +--rw max-lsa?          uint32
       |     |  +--rw passive?          boolean
       |     +--rw isis {vpn-common:rtg-isis}?
       |     |  +--rw address-family?   identityref
       |     |  +--rw area-address      area-address
       |     |  +--rw level?            identityref
       |     |  +--rw metric?           uint32
       |     |  +--rw passive?          boolean
       |     +--rw rip {vpn-common:rtg-rip}?
       |     |  +--rw address-family?   identityref
       |     |  +--rw timers
       |     |  |  +--rw update-interval?     uint16
       |     |  |  +--rw invalid-interval?    uint16
       |     |  |  +--rw holddown-interval?   uint16
       |     |  |  +--rw flush-interval?      uint16
       |     |  +--rw default-metric?   uint8
       |     +--rw vrrp {vpn-common:rtg-vrrp}?
       |        +--rw address-family?   identityref
       |        +--rw ping-reply?       boolean
       +--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
  augment /nw:networks/nw:network/nw:node:
    +--rw ac* [name]
       +--rw name                 string
       +--rw svc-ref?             ac-svc:attachment-circuit-reference
       +--rw profile* [ac-profile-ref]
       |  +--rw ac-profile-ref    leafref
       |  +--rw network-ref?      -> /nw:networks/network/network-id
       +--rw parent-ref
       |  +--rw ac-ref?        leafref
       |  +--rw node-ref?      leafref
       |  +--rw network-ref?   -> /nw:networks/network/network-id
       +--ro child-ref
       |  +--ro ac-ref*        leafref
       |  +--ro node-ref?      leafref
       |  +--ro network-ref?   -> /nw:networks/network/network-id
       +--rw peer-sap-id*         string
       +--rw group* [group-id]
       |  +--rw group-id      string
       |  +--rw precedence?   identityref
       +--rw status
       |  +--rw admin-status
       |  |  +--rw status?        identityref
       |  |  +--ro last-change?   yang:date-and-time
       |  +--ro oper-status
       |     +--ro status?        identityref
       |     +--ro last-change?   yang:date-and-time
       +--rw description?         string
       +--rw l2-connection {ac-common:layer2-ac}?
       |  +--rw encapsulation
       |  |  +--rw encap-type?        identityref
       |  |  +--rw dot1q
       |  |  |  +--rw tag-type?         identityref
       |  |  |  +--rw cvlan-id?         uint16
       |  |  |  +--rw tag-operations
       |  |  |     +--rw (op-choice)?
       |  |  |     |  +--:(pop)
       |  |  |     |  |  +--rw pop?         empty
       |  |  |     |  +--:(push)
       |  |  |     |  |  +--rw push?        empty
       |  |  |     |  +--:(translate)
       |  |  |     |     +--rw translate?   empty
       |  |  |     +--rw tag-1?          dot1q-types:vlanid
       |  |  |     +--rw tag-1-type?     dot1q-types:dot1q-tag-type
       |  |  |     +--rw tag-2?          dot1q-types:vlanid
       |  |  |     +--rw tag-2-type?     dot1q-types:dot1q-tag-type
       |  |  +--rw priority-tagged
       |  |  |  +--rw tag-type?   identityref
       |  |  +--rw qinq
       |  |     +--rw tag-type?         identityref
       |  |     +--rw svlan-id?         uint16
       |  |     +--rw cvlan-id?         uint16
       |  |     +--rw tag-operations
       |  |        +--rw (op-choice)?
       |  |        |  +--:(pop)
       |  |        |  |  +--rw pop?         uint8
       |  |        |  +--:(push)
       |  |        |  |  +--rw push?        empty
       |  |        |  +--:(translate)
       |  |        |     +--rw translate?   uint8
       |  |        +--rw tag-1?          dot1q-types:vlanid
       |  |        +--rw tag-1-type?     dot1q-types:dot1q-tag-type
       |  |        +--rw tag-2?          dot1q-types:vlanid
       |  |        +--rw tag-2-type?     dot1q-types:dot1q-tag-type
       |  +--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
       |  |       {ac-common:server-assigned-reference}?
       |  +--rw lag-interface {vpn-common:lag-interface}?
       |     +--rw lag-interface-id?   string
       |     +--rw member-link-list
       |        +--rw member-link* [name]
       |           +--rw name    string
       +--rw ip-connection {ac-common:layer3-ac}?
       |  +--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)?
       |  |     +--:(dynamic)
       |  |     |  +--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
       |  |     |  +--rw (provider-dhcp)?
       |  |     |  |  +--:(dhcp-service-type)
       |  |     |  |  |  +--rw dhcp-service-type?
       |  |     |  |  |          enumeration
       |  |     |  |  +--:(service-type)
       |  |     |  |     +--rw (service-type)?
       |  |     |  |        +--:(relay)
       |  |     |  |           +--rw server-ip-address*
       |  |     |  |                   inet:ipv4-address
       |  |     |  +--rw (dhcp-relay)?
       |  |     |     +--:(customer-dhcp-servers)
       |  |     |        +--rw customer-dhcp-servers
       |  |     |           +--rw server-ip-address*
       |  |     |                   inet:ipv4-address
       |  |     +--:(static-addresses)
       |  |        +--rw address* [address-id]
       |  |           +--rw address-id                       string
       |  |           +--rw customer-address?
       |  |           |       inet:ipv4-address
       |  |           +--rw failure-detection-profile-ref?   leafref
       |  |           +--rw network-ref?
       |  |                   -> /nw:networks/network/network-id
       |  +--rw ipv6 {vpn-common:ipv6}?
       |     +--rw local-address?
       |     |       inet:ipv6-address
       |     +--rw prefix-length?                           uint8
       |     +--rw address-allocation-type?
       |     |       identityref
       |     +--rw (allocation-type)?
       |        +--:(dynamic)
       |        |  +--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
       |        |  +--rw (provider-dhcp)?
       |        |  |  +--:(dhcp-service-type)
       |        |  |  |  +--rw dhcp-service-type?
       |        |  |  |          enumeration
       |        |  |  +--:(service-type)
       |        |  |     +--rw (service-type)?
       |        |  |        +--:(relay)
       |        |  |           +--rw server-ip-address*
       |        |  |                   inet:ipv6-address
       |        |  +--rw (dhcp-relay)?
       |        |     +--:(customer-dhcp-servers)
       |        |        +--rw customer-dhcp-servers
       |        |           +--rw server-ip-address*
       |        |                   inet:ipv6-address
       |        +--:(static-addresses)
       |           +--rw address* [address-id]
       |              +--rw address-id                       string
       |              +--rw customer-address?
       |              |       inet:ipv6-address
       |              +--rw failure-detection-profile-ref?   leafref
       |              +--rw network-ref?
       |                      -> /nw:networks/network/network-id
       +--rw routing-protocols
       |  +--rw routing-protocol* [id]
       |     +--rw id                 string
       |     +--rw type?              identityref
       |     +--rw routing-profile* [routing-profile-ref]
       |     |  +--rw routing-profile-ref    leafref
       |     |  +--rw network-ref?
       |     |  |       -> /nw:networks/network/network-id
       |     |  +--rw type?                  identityref
       |     +--rw static
       |     |  +--rw cascaded-lan-prefixes
       |     |     +--rw ipv4-lan-prefix* [lan next-hop]
       |     |     |       {vpn-common:ipv4}?
       |     |     |  +--rw lan           inet:ipv4-prefix
       |     |     |  +--rw lan-tag?      string
       |     |     |  +--rw next-hop      union
       |     |     |  +--rw metric?       uint32
       |     |     |  +--rw bfd {vpn-common:bfd}?
       |     |     |  |  +--rw enabled?
       |     |     |  |  |       boolean
       |     |     |  |  +--rw failure-detection-profile-ref?
       |     |     |  |  |       leafref
       |     |     |  |  +--rw network-ref?
       |     |     |  |          -> /nw:networks/network/network-id
       |     |     |  +--rw preference?   uint32
       |     |     |  +--rw status
       |     |     |     +--rw admin-status
       |     |     |     |  +--rw status?        identityref
       |     |     |     |  +--ro last-change?   yang:date-and-time
       |     |     |     +--ro oper-status
       |     |     |        +--ro status?        identityref
       |     |     |        +--ro last-change?   yang:date-and-time
       |     |     +--rw ipv6-lan-prefix* [lan next-hop]
       |     |             {vpn-common:ipv6}?
       |     |        +--rw lan           inet:ipv6-prefix
       |     |        +--rw lan-tag?      string
       |     |        +--rw next-hop      union
       |     |        +--rw metric?       uint32
       |     |        +--rw bfd {vpn-common:bfd}?
       |     |        |  +--rw enabled?
       |     |        |  |       boolean
       |     |        |  +--rw failure-detection-profile-ref?
       |     |        |  |       leafref
       |     |        |  +--rw network-ref?
       |     |        |          -> /nw:networks/network/network-id
       |     |        +--rw preference?   uint32
       |     |        +--rw status
       |     |           +--rw admin-status
       |     |           |  +--rw status?        identityref
       |     |           |  +--ro last-change?   yang:date-and-time
       |     |           +--ro oper-status
       |     |              +--ro status?        identityref
       |     |              +--ro last-change?   yang:date-and-time
       |     +--rw bgp {vpn-common:rtg-bgp}?
       |     |  +--rw peer-groups
       |     |  |  +--rw peer-group* [name]
       |     |  |     +--rw name                      string
       |     |  |     +--rw local-address?            union
       |     |  |     +--rw description?              string
       |     |  |     +--rw apply-policy
       |     |  |     |  +--rw import-policy*           leafref
       |     |  |     |  +--rw default-import-policy?
       |     |  |     |  |       default-policy-type
       |     |  |     |  +--rw export-policy*           leafref
       |     |  |     |  +--rw default-export-policy?
       |     |  |     |          default-policy-type
       |     |  |     +--rw local-as?                 inet:as-number
       |     |  |     +--rw peer-as                   inet:as-number
       |     |  |     +--rw address-family?           identityref
       |     |  |     +--rw role?                     identityref
       |     |  |     +--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 enabled?          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 enabled?           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
       |     |  +--rw neighbor* [remote-address]
       |     |     +--rw remote-address            inet:ip-address
       |     |     +--rw local-address?            union
       |     |     +--rw peer-group?
       |     |     |       -> ../../peer-groups/peer-group/name
       |     |     +--rw description?              string
       |     |     +--rw apply-policy
       |     |     |  +--rw import-policy*           leafref
       |     |     |  +--rw default-import-policy?
       |     |     |  |       default-policy-type
       |     |     |  +--rw export-policy*           leafref
       |     |     |  +--rw default-export-policy?
       |     |     |          default-policy-type
       |     |     +--rw local-as?                 inet:as-number
       |     |     +--rw peer-as                   inet:as-number
       |     |     +--rw address-family?           identityref
       |     |     +--rw role?                     identityref
       |     |     +--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 enabled?          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 bfd {vpn-common:bfd}?
       |     |     |  +--rw enabled?                         boolean
       |     |     |  +--rw failure-detection-profile-ref?   leafref
       |     |     |  +--rw network-ref?
       |     |     |          -> /nw:networks/network/network-id
       |     |     +--rw authentication
       |     |     |  +--rw enabled?           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
       |     |     +--rw status
       |     |        +--rw admin-status
       |     |        |  +--rw status?        identityref
       |     |        |  +--ro last-change?   yang:date-and-time
       |     |        +--ro oper-status
       |     |           +--ro status?        identityref
       |     |           +--ro last-change?   yang:date-and-time
       |     +--rw ospf {vpn-common:rtg-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    string
       |     |  |     +--rw metric?        uint16
       |     |  +--rw max-lsa?          uint32
       |     |  +--rw passive?          boolean
       |     |  +--rw authentication
       |     |  |  +--rw enabled?           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
       |     |     |  +--ro last-change?   yang:date-and-time
       |     |     +--ro oper-status
       |     |        +--ro status?        identityref
       |     |        +--ro last-change?   yang:date-and-time
       |     +--rw isis {vpn-common:rtg-isis}?
       |     |  +--rw address-family?   identityref
       |     |  +--rw area-address      area-address
       |     |  +--rw level?            identityref
       |     |  +--rw metric?           uint32
       |     |  +--rw passive?          boolean
       |     |  +--rw authentication
       |     |  |  +--rw enabled?           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
       |     |     |  +--ro last-change?   yang:date-and-time
       |     |     +--ro oper-status
       |     |        +--ro status?        identityref
       |     |        +--ro last-change?   yang:date-and-time
       |     +--rw rip {vpn-common:rtg-rip}?
       |     |  +--rw address-family?   identityref
       |     |  +--rw timers
       |     |  |  +--rw update-interval?     uint16
       |     |  |  +--rw invalid-interval?    uint16
       |     |  |  +--rw holddown-interval?   uint16
       |     |  |  +--rw flush-interval?      uint16
       |     |  +--rw default-metric?   uint8
       |     |  +--rw authentication
       |     |  |  +--rw enabled?           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
       |     |     |  +--ro last-change?   yang:date-and-time
       |     |     +--ro oper-status
       |     |        +--ro status?        identityref
       |     |        +--ro last-change?   yang:date-and-time
       |     +--rw vrrp {vpn-common:rtg-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
       |           |  +--ro last-change?   yang:date-and-time
       |           +--ro oper-status
       |              +--ro status?        identityref
       |              +--ro last-change?   yang:date-and-time
       +--rw oam
       |  +--rw bfd {vpn-common:bfd}?
       |     +--rw session* [dest-addr]
       |        +--rw dest-addr              inet:ip-address
       |        +--rw source-address?                  union
       |        +--rw failure-detection-profile-ref?   leafref
       |        +--rw network-ref?
       |        |       -> /nw:networks/network/network-id
       |        +--rw session-type?                    identityref
       |        +--rw desired-min-tx-interval?         uint32
       |        +--rw required-min-rx-interval?        uint32
       |        +--rw local-multiplier?                uint8
       |        +--rw holdtime?                        uint32
       |        +--rw authentication!
       |        |  +--rw key-chain?    key-chain:key-chain-ref
       |        |  +--rw meticulous?   boolean
       |        +--rw status
       |           +--rw admin-status
       |           |  +--rw status?        identityref
       |           |  +--ro last-change?   yang:date-and-time
       |           +--ro oper-status
       |              +--ro status?        identityref
       |              +--ro last-change?   yang:date-and-time
       +--rw security
       |  +--rw encryption {vpn-common:encryption}?
       |  |  +--rw enabled?   boolean
       |  |  +--rw layer?     enumeration
       |  +--rw encryption-profile
       |     +--rw (profile)?
       |        +--:(provider-profile)
       |        |  +--rw encryption-profile-ref?   leafref
       |        |  +--rw network-ref?
       |        |          -> /nw:networks/network/network-id
       |        +--:(customer-profile)
       |           +--rw customer-key-chain?
       |                   key-chain:key-chain-ref
       +--rw service
          +--rw mtu?                      uint32
          +--rw svc-pe-to-ce-bandwidth {vpn-common:inbound-bw}?
          |  +--rw bandwidth* [bw-type]
          |     +--rw bw-type      identityref
          |     +--rw (type)?
          |        +--:(per-cos)
          |        |  +--rw cos* [cos-id]
          |        |     +--rw cos-id    uint8
          |        |     +--rw cir?      uint64
          |        |     +--rw cbs?      uint64
          |        |     +--rw eir?      uint64
          |        |     +--rw ebs?      uint64
          |        |     +--rw pir?      uint64
          |        |     +--rw pbs?      uint64
          |        +--:(other)
          |           +--rw cir?   uint64
          |           +--rw cbs?   uint64
          |           +--rw eir?   uint64
          |           +--rw ebs?   uint64
          |           +--rw pir?   uint64
          |           +--rw pbs?   uint64
          +--rw svc-ce-to-pe-bandwidth {vpn-common:outbound-bw}?
          |  +--rw bandwidth* [bw-type]
          |     +--rw bw-type      identityref
          |     +--rw (type)?
          |        +--:(per-cos)
          |        |  +--rw cos* [cos-id]
          |        |     +--rw cos-id    uint8
          |        |     +--rw cir?      uint64
          |        |     +--rw cbs?      uint64
          |        |     +--rw eir?      uint64
          |        |     +--rw ebs?      uint64
          |        |     +--rw pir?      uint64
          |        |     +--rw pbs?      uint64
          |        +--:(other)
          |           +--rw cir?   uint64
          |           +--rw cbs?   uint64
          |           +--rw eir?   uint64
          |           +--rw ebs?   uint64
          |           +--rw pir?   uint64
          |           +--rw pbs?   uint64
          +--rw qos {vpn-common:qos}?
          |  +--rw qos-profiles
          |     +--rw qos-profile* [qos-profile-ref]
          |        +--rw qos-profile-ref    leafref
          |        +--rw network-ref?
          |        |       -> /nw:networks/network/network-id
          |        +--rw direction?         identityref
          +--rw access-control-list
             +--rw acl-profiles
                +--rw acl-profile* [forwarding-profile-ref]
                   +--rw forwarding-profile-ref    leafref
                   +--rw network-ref?
                           -> /nw:networks/network/network-id
  augment /nw:networks/nw:network/nw:node/sap:service/sap:sap:
    +--rw ac* [ac-ref]
       +--rw ac-ref         leafref
       +--rw node-ref?      leafref
       +--rw network-ref?   -> /nw:networks/network/network-id
]]></artwork>
]]></sourcecode>

    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This document builds on <xref target="RFC9182"/> and <xref target="RFC9291"/>.</t>
      <t>Thanks to Moti Morgenstern <contact fullname="Moti Morgenstern"/> for the review and comments.</t>
      <t>Thanks to Martin Björklund <contact fullname="Martin Björklund"/> for the yangdoctors YANG Doctors
      review, Gyan Mishra <contact fullname="Gyan Mishra"/> for an early rtg-dir RTGDIR review, Joel Halpern
      <contact fullname="Joel Halpern"/> for the rtg-dir RTGDIR review,
Giuseppe Fioccola <contact fullname="Giuseppe
      Fioccola"/> for the ops-dir OPSDIR review, and Russ Housley <contact fullname="Russ Housley"/> for the sec-dir SECDIR
      review.</t>
      <t>Thanks to Krzysztof Szarkowicz <contact fullname="Krzysztof Szarkowicz"/> for the Shepherd shepherd review.</t>
      <t>Thanks for Mahesh Jethanandani <contact fullname="Mahesh Jethanandani"/> for the AD review.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false"> toc="include">
      <name>Contributors</name>
      <contact initials="V." surname="Lopez" fullname="Victor Lopez">
        <organization>Nokia</organization>
        <address>
          <email>victor.lopez@nokia.com</email>
        </address>
      </contact>
      <contact fullname="Ivan Bykov">
        <organization>Ribbon Communications</organization>
        <address>
          <email>Ivan.Bykov@rbbn.com</email>
        </address>
      </contact>
      <contact fullname="Qin Wu">
        <organization>Huawei</organization>
        <address>
          <email>bill.wu@huawei.com</email>
        </address>
      </contact>
      <contact fullname="Ogaki Kenichi">
        <organization>KDDI</organization>
        <address>
          <email>ke-oogaki@kddi.com</email>
        </address>
      </contact>
      <contact fullname="Luis Angel Munoz">
        <organization>Vodafone</organization>
        <address>
          <email>luis-angel.munoz@vodafone.com</email>
        </address>
      </contact>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+y963IbR5Iw+p8R+w699A+QNgHxJkqiZ8eGKNrDs7pwRNne
iY39NhpAk+xRAw13N0jRlr5nOc9ynuzkpbJuXd1okJTtmSFi10MBVVlZWVlZ
mVlZmf1+f61Kqyw5jNaH0eukus6L99Hfhq+/j17EVRy9yidJFp3nRTSsqnh8
OU1mVXSUFuNFWpXra/FoVCRX1Jf6CACr2xE0G8dVcpEXN4dRWU3W1ib5eBZP
YchJEZ9X/TSpzvv5vIyvL/qz6rof65H6Yx6pv3OwVi5G07Qs03xW3cyh78nx
u+/WZovpKCkO1yYwwOHaOJ+VyaxclIdRVSySNUBsby0ukhgQfDNPiriC3mUU
zybRq3gWXyQ4xvoaYnxR5It5W7NoCHCin6BpOruIvsfm62vvkxvoPDlci/rR
WZaOk+gsKa7gf/GLl3s/nr6mP3bVH8NFlU8JOv5LaOV++6YYXyZlVegvSoYY
AUHTq6S4obHUd/Miv0qRJICT3bZMLhDnGozzLPmQjtIsrW6c5ul0nqXn6biG
mzWdve9PT52fYL447Fq8qC5zWIP+WgSf80WW8eK+yi/hfyfR83wxjidxWtDv
RY68lkzSKucv8uIinqW/0NCHMP14dpHQD8k0TrPDaMpgBiMB821ObQbjfLpW
G/RtOr6Mi0n0Nge+qMrACP/PYpbCIttDFAW3/vbv/NtgllR10G/KcVxE3+ez
X+Is+QXWI3qR5qER3iVZcg5rMo7tQXLsPrhQ3SdAgbz8ttJNw9M5i6dpUkTP
4+JikWbR92kRZ5M8MObr/H3qDFdSz8GIe/7vBff8dobtwmM9z6OfFgHQf1nE
10kKsxpfzvIsv0iT0h4ogy0yuF6M8m8vqSEDh61YFekIWBs4I4p4LB7nx3QM
30Yv83nyiwwXmMAVNRtk2MxGW4AZxE+u4ln0/OZ9fhXA/m06GuWz6CifThcz
xeEO/th7QL2/LUajWdMgf01nbeSxIcIGy4AiDj3qAN9cxO/T6D8TQOoyDcD9
zxcvTmyo75N+nmOfb99PJo1QXy7SMhrC9siiV4tZ/ksA8I/5JAaeczZZBt36
uKuywRS7fXulGvE4s7xACXWV4FqeHB8fP93eHez8dTw/JCBygOAv0VkFghO3
4Dkt8jjOSJJOk6rI5zmIHlgslMnRjAVJ2e8/L9LJRcISl/+eiJiBX4cgyiYk
gve2D/2jaZ0QEBGEfyuSKLZClOjfdEKAPJtXCR4Z0e72zlNGHnZIUh1Gl1U1
Lw8fPZrk6QC6PtrZHuzsbD97hBDO3r0YYIfB0/2DJ4+3n6ytpbNzQxPYS/1+
FI9QbI9Bcry7hEWAQ25BWJfzZAzCFecncwahJuejOewiddiVg+jdZaKajIFa
oyRalAkTtLp0pX6Un4dAQJsUWsP/TRYFNisDJ0a0kQwuBlsRnE5bjljXx9jm
IBpGwAFzYB/YRAKEUYM5ytQmEewORM1bnZJwfp7Aehe8vL2AGtHrx8B8fTnU
NoZHcXy2GW2c9F8MbN2gSrBdTTnYHCDFCatFlgAv0NlXEj6juEw00Td6BE39
s7dJCGErGdnC7TRP4b8bZ8PTTZ5uGV2n1SU1nyQVbBqatGICoM0qiwPEOsVm
E+DDY+L8jdPjEueBfDRNJ5MsWVv7IjoBGQqTGtOpvHaUz2YJ/H0Fp7csRYlb
iceEEyUa3ehdFVV5NF6UoFog6a9YtuKpg7oYTDsppukMUAcs5zjXcisqF+PL
KC41Ob5bzMasCv366zdvvzt6cnDw+NOnLQQkkOEgJ/SPAP2taJ7AN6jOzPJp
vgBANyXsNjhYCpzp23xRIS4bw7Pnb6H5Gu/KOBoDcfCHC8DsOr4BTICWJ/gd
TCY6/gAnOkgmXpJSLTZMeZwAbyc4T01z2GHCo6n9j7lQW++/+AaIMQfBEuUz
tW6wdZmik3xeMTHrELYA8DhbTJBu2O08y6+j+aLC8eZZjDpWEyNM4KABnDUO
ZgkBi0sAA71uaD1B1UHOzCMUlTX+wQ0CG/M7GCf5EIPmlmzRgHDiJ6HmONfL
vIQ/FlmVQnMzshIAL+MblIhwMhfVAuT1aZFewVpombABEmKTVoVb7rHIgH8H
pYZil2eP9/c+fQJMT2YRcwDO6CpPJ9YiwSKfJ0UChCEyFLCmcHrMKmdvAW2v
YhBowFJZro7wrdDy4lSTD/O8RGgKOq4JDDwlTR7NEVmA/jX0GURHepOgrAVC
zgCLnxegg+MIdJhlcBCGKAtgQTbbq78lMgWBnPOUq8u4CvW+toayRHSpwGom
oP7DowGQ9d87isRPn5xTh3aZOXKIFDhiSDbFpSEs7LVffy2TcZ9Fqwe101kW
bawTvvEYTbv1zVXPNlwv2sq1LdzlhPN2CfClT0DAK/tQTuE/s2n/Ilt4k1wY
O6rktUjYnPMs3Y2Xu69fbeIKIePvPtsBMHK6kB1Ya79ntd95ugvtcdlT6PPy
A7Sn0XDyzD2FNS+g1qIU+WPk4CQ5T2dyElv6hxKYWh3JErAiY5TazuiIrYM+
ij+UhMQoM8DFXRvQdeBgIgGMGMIilsxnM5ighbaDFm5MGAE0nDPYcrhF4Dc+
ra9BCuCOpQMvIcYf51e43nkFMjq7gX/OrqApjA8iqkmyg1wAoyOKszKXdRyX
yEg5UKtQyh6K/iy/4YGVDBxn+ULLZlEpYNIulyNdkzK9wBnFPn/AKKNc6Qiu
qqF6M32f7u0/ttiji/IhK7O//fTTJ9DJgseC2k7m8IiQS0Dc45YX0Q8wgfov
0/fJdVqqg6M+New9Br0PfsFzwCYXSC1YqBgB1UZEMWkPhvyryAsbGLgB3ShH
NHMUDWD3ZBNshOT+v/CJ4ri8ulDqu/0Z9PuDf6t///Ho+OBj4Pte/6te/et4
HH10QXYaJLJ6wYCPv+rTR/7n6HjXR2FgNRgQOv2eCwq/8Tp9bPgb/xmPV2js
Nh18NQj+zf+02g76X5XxXM1K/T0I/cQfu+tHnFBP/5P+/hj8qYahRv70eMf7
zvpp1+6qFs6bTLirOyqs3s5XPLd6i/autITAQL2veoHfW7vqv3v9+qfX8tO/
rTnLU/8MWn4K0bgTykhXmOigCcbp8V4DjNPjffUNcwtsjcfBte6EB7ONt1FW
AxHmNP4MkHqm64B5yvy3eeF4L+iF43/a/w2IHg3JZR/+p/5vcz8UAfU585d1
6WBP8ytXyn20vgxJTtXq6HiPtzuoR8Km8OX+V/264LKm0/e3uvqShPvar4fR
F0AgpQqy0+g/1gP+ADD5SGEr10GDYFU9zuBg+o91thTXPzWczqSEVPwLnV4z
9YOlhDQp0dwekIMDlsGTL2NnsKMO3yfPHm/DsW3p0r6mhRoKGi1aU9Q6n7lF
QN8I2BtwhA4LOP+qhHWojdevXgw3PTxZV9glhM6IIqLKemY/NUc9XX6mLl98
ER2Tmz0Ffel1Duf4xjuyLIpkCpoVGbgwhGq0ubZGbRTq5ofDiNxZZTJmW0zs
E4HCejha4YtRphysA98Hhu7gOAUdiaykyzxDle0qBn1bqYqzhNUOAkyNJuxw
AYLA4v8C/1TNoTEiWKWgQILGZY/KmM5wGuViOgWT8RfskGXYkEzkxQhsrWqh
9HnRUXHwZAJIn2YJOozi+Rz0TTLv8wwMfNR3FVakBB2urX0ZHcEn6vf/TO3i
UmlOSDe+lCKTpgO3Aagz+NwaVMj6A5j/BZ+lMIl9ASq0393efdzf3ulvPzG9
xuQNIBVQEdCiNn9lLTJ6rI60js5ujRfI0Cn73GlTvU9uIrwyK6P1Vz+cvVvf
4v+NXr+hv98e//WHk7fHL/Dvs78MX77Uf6ypFmd/efPDyxfmL9Pz6M2rV8ev
X3Bn+DZyvlpbfzX82zrb5+tvTt+dvHk9fLle38Mxu5RGyjkxL5KKdP01UI7H
RTri7fb86PT/+3939tUu3d3ZeQaiQW3ZnSf78A+07nk0Ml74n+jhWQPuSuKC
rNoMjeB5WoG5soX2RHmZX88i1LCBGb/8b6TM/xxGfxqN5zv7f1Zf4ISdL4Vm
zpdEs/o3tc5MxMBXgWE0NZ3vPUq7+A7/5vxb6G59+advMhB5UX/n6Td/XmMe
KZIYxQMQYwH2AazEeTxNsxRopl2w6L4sXXF5pgTULjKmZS35okgfEggjWndO
kHVchDBUOAcALvq1nj47eKYPiWkSozlcaglzMx3lWen4w6siARsqjS+KeFr6
RjH7ykDObxPMlx/OXrHriOWs2JPiohNrUbsdzsiNQDD2Dw5st4Ny1fk99qwe
u8+eqVFfh0f9PK4OGhFbekPycAiMACkSGxmMpCNvkaKu8vjP0Y/wIUGxHI8P
1w5tU1qJxLU1UDnwJ4Xb2hpoIvhvy/q2jW/4/Wps/b62dgLbdTIhUbbliQzN
UQZT4k/Ah68+CKdofnlTpngdBoIXr1HxT+D993wOjdm7j4417VxHV0q0Ac1L
UBQ22ab3HR4Dgj2iccQgj2GjFAnoASWOhX9PaKRB9Maz0CvrUtfxx+GSLNA8
jxVsdtypcTACQ5qbOyBymAvyiBf2yCmgAp2DGfluyXW4mKU/LzQ04gJyAcOo
MDc4P85v9MC06WHBUTHUNznKZyOEIhGieqZJsTmIzuguwwKtsAVxXqTJlY+t
cdsKf6GqgL5ZvMATX5MoAOK1Jc5dzOLpKL1Y5IsS5LxGX/wk2tXt+HWFOrDq
42RekevIWcKLZAZ0Y8UH+lnO5IRGpzUFQEmR3SDDKfZpvYkKeY0QEZ8pQm5c
9KwDWniPAAOTY07fOSjM1aJoMHKbwHfAFD4jl7rRxo8vh6/LTbl8scHQbkhL
51IrNpsH+Rj9RSJkKNAA9h3vshcJan/IYufq8gq64IpUN0C2cg56SDrKzCXN
1GjmIsAbHIv1vTOrYaC3EDvMmJGab6FQrVc/5TrqJ6d5vNWCMTQTJhGqJzFK
DH0qam7G1fbvmVhQlIEBiTdv5kjeLEymAEew69C5xsRbzE0YIWNG3FI3OvqC
Q+mUeLek9cdEGiQT5wIkDpC3ZQbInkIQpof4IvMiuFIW7f1lYWktfYQdY6SH
3DVOkvotntyl0cHWdDVGrk5/YBpw5ixufk7rf4dBULpgSAhpJpZjng1HOjDd
ewT8Cg2FfJzSDbHhqrxgnqBLz3Q6zwv8nVQbuXMX1ZUUGoT16ROcfh9PCap2
vbyi1h+Zu0kqf1z7CCyhzKGPclOk/knWCppZqhUcyboJ/i262eMB6XzYGi0p
bD3Jq52f+3hMldAlSZ5u7/bt73791Y5i+fQJ+6TnDF1fG5YfjRW+p9rAikir
pFLALDVxX5TPg2eoGGEXsHj640swfrmf+aexF55wy1k8nn6UewP0JfTxC42C
gje7/mjfLXx0bhWwQVHpiUOzIl/g5jOo/jsrfvu68TzP3KYYpTO+kbbPtg8U
fug3pYboxQF96qNzLYEtruYzZy2tf2v9j6aBviBkE/ECMWewzQicmxbR0HDi
qdLv0O/zBTBPxvctl+kcN+QbutgZHtlhJ3hvCUyCx9RVmlyj2yYB+aaCQgob
wgjImCR8DMklMwAzbh629tdd3lyPNgKXib5pv6k78tmGXEs9DeeyVdHZsN+0
UalD270DNLyeRWj2fa/TAG9Hw/MOXKJutt7ouMSs+xP/j/3fwL2P/V/1s+UF
71k/W77bwZrduwbO/mKFltZiRH+CUSJvvR2Y/8dMq/lDLT8Gh2tsGbpAoE9k
La9uvezzfzq3/Lhay14QNeSYyFq+tTX2XP3tMPovdd6U0d+ME9na2dqL7Gz/
JX7j2l5Wpxic8vp0G7H/r7Z7t9ztp/xJzh5iaOVAx72xkmmftnWhoFBQarY2
WwgR0XjwOrUJlogDhgP2TzpNsxiMgy1jSK2IR5aWlVKJKwnFkLt+/kNbhnkE
5yWGlaOrkPQFlrBaunIAgUxEx9cot4FyNNohBsbIV+fclkdlE8agHP6aZqUK
AfIW0afQd4sCTw5UELdM7IVEQrF6ZYU7GR2MFCMgxpYLnMVjKAiRfDrk1UA3
i+puEWMVvAmOdfHRobfFlHgrEKmrhB/KRHut6pcw7mn6xRe0+u9U0CAPouyh
V2IPSSCVhDRiTCAexIuxdf7GaOuR54EjMSqMCc4vtE1zlWdXxOl06uKg5JB1
BubgA3UPoFVkCuY6SzD6zNwywcgUmDSTmxOcMcZAiFchjk6PBzRUdHQs5luS
kk5hWZ2TRNkc8KX4blhfV64G90vXooI55+fVNU4EY2mBuTG6Q+IirpSZrN9o
KHNPWx7K5lYIa8seDIeesRAIM2hQTPpzEH5oDZ0XsQ7SoUBemCBd5MB+VDwi
vSnoi6I3kbIqfE/cp19CR+0AUKSxAkk57EOFmowDMaqImxt/GGqlbRscjPYI
vhQhDvUp48ajbqrlM3FhVjAgbWodCAP7JhClIvO2MNihbXZ0vMvcF19ccLyP
aSqWMXku6vGY2B1dyWkJNnlpe3r39w5A9bbcJDhf8dvRNlTxN8CYnp8l4L1R
d3NwvqHq6rIdPuoh1wYyz6VScUXAuezhaMHAJiKYhaZo/yqMKTTJxAci5RV1
oR+SXO9VJw5oC1BIYZ/ITAN2pu0EwrC+FL0GYzllrNXZ5yU3gZs4rJwpsPyV
0odLoCUawEB7HpxPijI0OlgcyWzCkdABkaPxg0XReOxtbhksT48dDLciMOHY
Z1pjTOUvBqIK0rDek2SMbgV2G6KjT5NRnW9q7zeGNBPLYdgbgOBYtxymRG4L
CYTDy6aYnn+lZr+Jm47Ds8G84gjc8Q06d6p8nGfRxo9v355uilfBPVjSeiio
CC5xJKvQW/IXHZOgFnUC719DbrHWYDD6hIJeGsK3oiYVVUUTWaE0bc057mhj
tLOph4fxpOVXLpSGQBVsNTzCIBKNAXyL8sZX+IMATo9tAMCAKjTJN3pC0W34
4QCNjdHupqjifjCHwP/q9JhBiYNJ4+tQ7KMDuIlie0GKdZlwM8V2Fcl77QB8
iu3XKBa1AhCK7SmKtUX3BIML26Pz3JHk8xVjXUexuXcN5RB+XXo3GnPdetsG
HlFdbLp/W9sYfdiM/kME/Mkk+mAsusVYGXI9Cf1REqLXbMmBTnqal3QhJ+YM
SEn37lHJzDdoKmSZvux7oZ7SooQDzYPcRYt+8gFjvy/za9ba5xZwUZNr4cAM
P1fw/ae6HJ1dqgddIYU8JD75rHIsCNTK6KSKSYMsEjjOSxhCTDNQ+eBwqtSV
AdgE6IJv8tybuBf9ZoUUYX3RYSL06TyZxqkK3uEbk/kcSWKO7bodoweQE0C9
yeAAcLIjzeMkyxztWQZPTyjUIXYr5NsaRD/JOShn9yyeqqsyHaMiV2vqAQpF
J3uXzDI/PF9loTLUokoOmZbQ6L6csp3OL/y4Z1jz4aV2pbavlu5GtQu/0nvP
/KSBOGEBJQMkwma76LWFFdhS/97T//4Y2Z7nfomXDn1Fny09irWIW46PBwFQ
7LfrdGidysCZylIa6Wkto9FH96H97QnqSpzSDOARFDa9Q1D6tyKo8qd71HJG
0XRT0ZP2KI2fFYlnn/Wfm3gy1lE+O08vFgoQS+2W0e0tYwekN86t83E2cKAO
mr4PBeK/yFFEOsPx/5of/OFqFGz63kezZ837Kyfo3kaTiPwikZ3gUqIxUtpd
iw4dfJZf2sH6DBSyg44dPir0uHGnDhx2W3TtoBQ8pT516eC069Th9fG7ozev
v3t09PJkEP7ceYiwaVQ7aQZEe3ZRL/fgf5SW3A8AfDw6/mLHsKIzScdm4I9p
Cf3oxUyvv0x7DxOhV5PA8m3rh7qcpWBPD5cNVf9Qv+eWvgrKor56mEm8uqiJ
OrHLkRJoP5TAhy2XEspZj9qIfaPqOZhttdF/Oknhcz/AUdyv8r6Mf6Lfv278
8PqEnrtL2ExDs9fQzPdkZZn2m1h3/LAT+aK8P5+B2nwZX2GwUw99dj3UStdg
Lj37cDuczdIe6JbintqK6Bk40iwB5c24MTA8Mi1Af81u1pSjkJVI3R5V1fTi
cpTTu0/peJXGNdceBguVYL6xBwmdoAJjXc3+i511ICSjX7LTjZxfRaL8y/xu
MJ78PR7T8zUCAE3T8wjf8HKQ19Gxq/SFvROanTzFby3I/NpwdTcXhUy07Q9v
KzU0d6ALLXZvDV1T02/k7steA/Rlg3Yi2IoUuA+C7d0CelBS1Q9yIZiWOfaO
W1X2gPRm/66O15JIvBap9AVoEBjyPrejtQI3RRQIxAEcKmB3gTLDCnqWzk0W
sPuQBaj8urruvwMAaMadLUYIq/7kxY24pXhNvh5YE+c8B5L3SmXypWjl8cMY
7RHQHnCFoj0PMetpKqXfsmkylpDMKZ1ZxRNhAbGm7Pro0QxEoloE62/MYQOs
Vlxrp23fjuPEf5ynGWVgwmdrg4FuH4/lxy+j/8bIr//hMxLbLBmU/gRuObSA
uUD4W/yixulAGMo+ZpqBTdcHq/obpxkbhIeB3G7aALdhmKmYeWFLhc/H+qzx
V/wpS+Jz+NNrJzarwav/Z48cQgvVMp04+NDr5X4dcOzOtWF0IK7VrBOKq+CX
81vqGnq5Qu/LNvTyLujld0Hvmi7OSBNIJxqXAOdQFj5Yc/pfaOuvtnxf7//R
ME4yTibIToglh2NXN3o6ikOruFqU/kpOpums7/300e2i17kG+KNFqiwuqz5n
rcEON/DHIb6i6oNq0ceHax5pMUbeH1ivbIeBoxUH5hlNjHQ3W7W+Jtlu3wou
j37VcTOH5AXbxUi3bzQqLJF053Te2nmvtbOOR1T3UGVTwzyeNv0EZ8KioHSH
Tb+rBIfqwz93lJeP8BGJgsB/xyojmiVFeQf+j4xgSw1NdWfHdREat5cZWp8w
h5NoE3Io4slrTkZUBYb8FAWtDrrJt4OrOaPEaVJ4tgtHaaB/e6ZTo1mKhEJp
zbhf+Wp5w7smJKfslpz3GMGdfKhqbw831cVpLWBaB+STRx5v8WeTRxgsUdhf
2rmyBtEx2iOIvL6DLUOpLVRDdTW7KGYSI+FeHdu0skINeiISe16GJOUrp2Rc
w6NHiAdGMVDstcmJtKXvBeoJQojozMFyw62fjIByRcFZbvYyUE5+mGXpe33Z
7GZ6W8XvvqXc6Hj/S698zKMY/UaI9AgrnqUcgwRUlh0MuEU5X6wLiWGEi05v
UQMa6ZHQXSuHGz2rXQ/vrYdZmRMTGTLHZWLC271wNQVXIqriyrkJINGlYyQw
qETeCFAcW3bTEsam3kPx8wj35ZM3qPpGX5Ns9JRe1dskNRMfkWvoDcFeTgKh
YBBVkVCcn4HUi8c9ea6NlzP4xCjq3UIQ9jh3oLy4UE80OGwIX7WkGYYbYII+
nYNNCEzPy1R4gvvCAWPy8GngJt/c8Fsu6kvRishCV3GaUdQD7jPJx0VB3fAv
tgxiO4LF3nvnMeYcTX9JJH0AhYE7L5LUqlJUGesj6qqSE5LxdZxS0iWcWv79
6dOmEUh8q+VFsWFUY2YlEUNXiTz04oYoh6kV39PZadJk1SY6YxaOSkFBSIB0
BiIyhaXeAnj0OLD+ukM/FIkoOsXBEXhTDXwyU7kCAT9JIkSv880W9PpEVfw+
KS3lzIQ2XWT5CB9FztRiKBEvmYasICuaicPEzTFcLIRI9tmRVpucHYqtRXnz
NWX3lY6SqYlZCb1EW7PULxrx9pCiFOmRe+KkOCKW0UG0yodWcrCXHUc2wDgm
9DUltDeAdhwIa21bKw9cYo3At6Y9Y5f0ENaJbDDkT/KrOWDlMPIIUEcrGmqU
Pbyu0ywTVpJgRCAIRRRJkgBBEhb0J+BijNR1qEP3pllCrEhsTg/hJRsUg6Gc
dxE9eOfzG5sPoiPdCmljxUkremg7qIfib2ZOhyzHS+Z69B9tYSsX2g76HGq5
FXtiefTswCYdR6bzFo5vELgVg4YpyUH1obAyCRxWcVSs2GsdRyQDKkrvzYS4
FQjT5+ji1acHBoxyf4r7QtMl5VujKw0ZKSSX90i7YTRNS+Br4Ar7oAt3vgIm
qPT7XWdE2/lMTlMQwxcXLEEnCc4ckMqncQY8oVdBdcLs3CBkk4JetvIcJSbR
CQtVojPbBaG5pQOxg032qImyFiJtLcjvRXVBDUxq961oaM1ZXiq+QlIlM0zS
GW28Gb7aFABgXhAAsSXke/h/+h47y9ElP12NSdjjQ8qJDAt8BTsdVOrSCY6o
YopJ4LflQGWcgAQnUBY2TsImj5Oc3HXlYo4PFpCJMkVFOoqEXvSPk9Orffrv
QYBKW9Hz715wtOIm+8b067wylGbHhGSU5sCj3UFpEDjOW1x5JiZEecFILsm3
hMeiQHWHQ2RKJ4pE00hpipjtcVGRXVAPxqGQfsQWHydgzDCeTwattOS1AE1n
VtmZfDEvipNu57Fx1UUaQNTmttIWX5svCH9uMejo51s4WDohWPoYBt1Bnx1D
x1MXIJ316zfLB195fBivuCGLoA2PcKtu+MhnNbx+zss2hLyfO2KyGgrnoDKD
WOqz8F5CodbGnwe9vLiOi4nl/g7iFWz1OVfO8k81IRVosgJGq7hzPFErPh0j
zLlmCUpDeQdnxKN1Z1EX2cqsIIFpmxtwEIMRERc3ThQdacThvNViR/mGqFa8
2fBA2+UCNJGZfvrVCFFMHHIdGDCSJaRmfdFZDdB0UydHhjbb6rp3J+h8fJ7a
IE8F5K9fOI31yUq6wxJs3Oun1Htrz628W6alLkzbTbn0pslyg4OZl076ErLf
NzlXdDsNNiBKTfMvo/8W975+zatcxuTdt/zQNkxbGt4ZWLMkuzvoujC6M0xf
lrQAjBoBtt8Vdr7oW+Kit6bkt7Bw9eYXutZxW6BfKHir4zYbXcyjX03qgUMw
APrwnVw01KhOnli2A2stonojn2R223YKNk7P6xy8menamZIXqhwODQ0Nv9Fz
Z9XYXMzVLhua+oMhEIMh3Xfg1Mms/yl/Sz/uQLkplg2FbtH7QNWB04KqfLqj
qq7LMNtRPy69hYMPZgw5jMs+519sBULMFpc1ECsBiScTMDXLPmXPu7Hxadw/
HgSM5qrPYxUI5Ga5zOd1KAswtp+241/SM/8CxvK6j3JALJ6190ZnXR/Oydpa
LB95XlBpkD67Jm0AXUYusauwDYo/jX6n3mmV9PPzfl6kF+lsGYNKrpdDGkd1
aoWfzq8O+rcchPp2HqlI8HEkFQFL+jqSD29EHcZskqMfw3yMPy3nPiM26AXk
xOKALosAp0V/Gn/oc1akZWOYltYwyGV7u8u6gpJAylZ1CVPEtLgIAZ+CTuPs
YH9Z76s0z+h2f2wdFQmIhkTKB7b3hzGrGFc3hR6CeyvihjzUJ3he2i3fJ8k8
xlvWbxTknYNlXZAKBL2pi7rzL+fntVMev2w85uvysI2PVJ8iiXW8CX04piKv
gJX7Py/iSUNHLHeWjm3B0zB7w0JZGS/nH4lGKktFVPUJcrXa8SWYDD6l8Mv7
p5TqyA3sbxo60d2QI52XDxSm7P2QCpSuGqXgu3slVMPG0b8v5hSxQ6GeYG19
o6cYYB6jyM3YMHN6LeuEO22CJ6Tda1mn82xRXnrYtfO2HIVm4QInsBJoRVFf
APzSX4HoFiug+6DPo4/5vG8aDmYvqsj6bnQ+cfCDfxvU7IZlQqVq+2Ky2J8A
hnZXdErD2dnHaLTqQ31JDavbvSTCg7oVH2prGu7F2qq6DEvNISBjPQ11Qr4R
Ae1/1FDaLeX4J8Qppb0i9Uij+lOIcHkivpZLPmC+x4lOMq6TeLZ7VFKuI5Zx
HMj4spZUwX4DS+m7uegbJaiz8sxKFpAysWD7MSaSEZbrKE10MA9jQGYF3p1S
hg5KuasLLg2iYZuvZ8uLgLZ8MXLbptCeHK6t9VrdMT2dg1Iaad9aYaUilfgG
QVpCidTttNVbcm/w3Vi1mLNTTdJ/zJHbdNwHThUz99BzY+tubQBohz0+jG/0
10WMtYwpqY9cwP01P9vshLyUOxxneERI9eMtOIupxrNK4qIyzqiwAs7hsnew
v0+V7XykrxTSXTxLagqqaaSbtuEeaOzP5nnKr2f4LvE77YeKXug+G8+/e7Fp
evK2evz0KZa3sFcJszG9l+QxPmuqBMuCLHfhABt9c25dz2NGZayTNSaHkAmN
4S/VHS1e8ZlQlzfDVyp4xLmHda75KAjQCnQpjfjg+z1VqVPXzbDvJ4dztPIo
THA42NkZ7HFyrcEOpVFsyu8YfGyOa97m8pPFNstRX2VOOqAWhV3QXIciVxtd
96UX/+P3SaVeNtxISmZ7bTQojH9Ql5/Q01siGgJhDsfozcdHlhiwFb1MMb31
xvDoZblJz51mPo83uyPVZK2r5iZ+1k2caVOIicV/au89//5UN9yUtF443beS
HNu671cxFj3j6ezpa2s7W4LF7jr4C3b9FKNFNJom2NNiNTeosYcOv55JfcMJ
zt28ClTzTp1QVkZekYmTvy8oEE9CwtxIr9JqIYVT4vdJMKRK/W6yhSHOfDvx
cjc6MgHZfCuR7ar7iJ4T622HAYaz+UjghhsCxNEsGxh5gs/8QvG8ahP7gR94
HLRddgB6K15z2C9bnKjsWzq9Tfj4LcLjHbfEOJ6Xi8w3090GrvYYVmyNmo3p
jd0fjM0RX3iaaCMw3Wd8lcVgGliuk5qW7w+hY4XKWiNNr4183h9f5lhc+ptQ
KwZ4uDHP55sNvxvbznYsJtN5ddMKEQyX5SCh0TedQVZFPCtRBWqCq6etW37T
BteQcsdVrq3c1Ye4LulkSXde7masXJDqb8Ul7aB374bZbjNmIZBtmImzNs0x
KqvPafo67IAlG+nndObto+gW+0j3KTvto2i1bRd12XaR1a552+m/G7ZdgOL2
tvNt+TrE+rYLgFyy7VyQTdtO/x0Ft10jqrfedrXuIea2serO3D7oFbddrXsz
ZiGQjZgpboJTT9nMPjvRAuFBvYBDMdOtGrZlrWGL8Oh8fuku8zJZTHKsf9Ms
xNHrNNbbreZKrLc+j4s+mA3EULPa6W0PfzXPggfh3Qb+ssPAH7I4+LNpMUsd
GdOKgaEnXkuiV6TzOrhd07n4g3ESdJVpvgqy0dV8Vt/jwjroh/MmYbnm+Nca
6yLHqfgjssvx0ZkCUbtct31koyKdXFgxXt+09FC5rdy2DWMInSzFEbcC3f9y
0T4DJ6BIZvGFKVjhuCadX3z/aaCzImVz9MU0wSvnPubU6OOzhgbvqtUsHClh
NxadOxRbssLbUQJdU83bglNqjS1vb+hn9x1pUxv3LSk30a5QZb2IE1SMH8sc
q7tDySpzjAXbKjOF6m1rzGlOFarAdtxI0fS62VRpYjPJcjh2cj7pkjxgd8Zg
VcEBQG9B8PFcpT2iKui8pMh1MAfTuQxmNBEx2rFJkVzjuyPJH9urCf0GS5On
d6NQUg8Y3VSHaKDHeuYMlbJBiDdQsmxLltvTAssPAbGGr43L8MfTl2ebdqvk
v6pElUCqV6+C9v8F3aEDvaQxh4xdi+OAK3tQUPk2FnjZBJu3JzLLeUViVTzj
Anj6GZw8K/TSFYMJjTl7Lgr66q3yoeDCPkchhf/YOHn7fDPSexuLDolLXIhV
LkZWqRtTeUDRmYuVCXsoDx46MHRaaV7oR9Z7BO0VpDFA57CeVImI8jzTCLYX
ksn4fuedW4beG5npoxDmEdDlOVI02KJU7WP5xnpaUK9cR0gExXwvUEpOkcoD
P6Fkb/jepf6sUyU9Xej0/Gmp3kGZ9zny4Mc/PHrsuDk5DThu9j6p6pY9R1g2
7Cd+rRh8SuM8ecME8ul4QeUjCH0YWx3StVfI4tFRe7sGfalLZ+8f36VTA7Dq
yaWG3QtrJg1KRjq/2ncOfPziU10bNzFpvIQNprfSxq72G/UxDow6Tz/0s2R2
UV2Grv/kEzC13PtaVQ1SX5E2INVuqW94UAKmLemRkxtM/Tqua5IWJMGLlK4A
IEst5di7IDQbO26GYVZqfL0CUaNRb42SfJijr7tqGkdzm7wQF/BJ3Q1Q18dl
vvOcQnLxf/puXG69p+6sWpuvG7TaYGcOOQoyWb1LR+5sGgsj8cJsX+8hn05D
Ka7RcfCTy/G8nWmwheg7zKzL+KfWowm+NYtw8FcNmS54aCK6rdvpSNDxVvim
Bay9QsrWsSzDz7FOREpGK4i/YK63kqY9pg1s6BHVNqDdq7nTinO/xcR5jflm
VQuFoK/MEQZWaGZIFAR6uKFx9qfRzg2QrXGH6n92nLcNfaVnak1A7HdZba6z
qHs+LIstMZzWP8EPGiz1phM8QJ+DcNDdHU/waIUT3Eaq/alG6wmuVyJ4gnvE
bDvB9R/NJ7jd5JYneG2U0AluN4o6neBej9o6NJ/g9Z5R9xO8pXPTCR7s0pE7
m8ZqOMGDPeTTaailJ7g9xPIT3G7d7QT3esinMXzbRaYLHtHyE7xOx/AJHqR3
h1Ms2E8+q6xTwwlu/9HtBPf+6HaCe3+sOPdbTHzpCe4hsuwEj5p6rHCC12G0
neD2p7sMsKHf4gSvA2k4wUOf7if4H9O9vOe4l11/USilny5dJj4b46TLVeGU
WF59yw+SwMtOSdUcNaQcZbMkmaggUaeoWcgTpbJamRBbyeWBgbcGjdJzIAZc
J71aGh9MO6TzW9lJbDD9X1wU7Oxyx45d957jUiXPm5ntmFAkrJyUK5KePT2P
MIsShjyOqaSeepvEeFIT7EaOXO6pfG+WL8m43i9xRY1jLmK1hxxnUworwwA5
nTxOy5BDU27txV+OTrfovxTHe6MS2XCUpvH3DaLXeaWc0ZJYGdFTub/OsOYr
ZRMbKkyGC9wO9rXCxtnL4fBoUyogPj3AiG5rAYCWTSToNaibrgddsl65zsrI
9CGacEKdii8ArPhB5DjVFMPvVOciAV251CWYTo8t/pM2zjSp4tCsHeOSSp5G
PUft6KlVMEuogwKnMQYB5lzQEUl0w7VMla+buvEhpPzUlMs+zQuV8YaT76kq
whXdE/RqWklP0Z8pDmzaaQplFsfjnorvI6siOrGyQ+Q6SaMqLDicXGGMYJlI
WSs70rMsFyqpHrGKTgvELczmJMZjG0Zfj+D5gHtfBWI6plKPWKnnWD2+YMAJ
e52sae5ub+8cTkZPD7cPdw4Pd4IA7fYH+72tMKoyWS4uVfqgH0FPzoBH1yzm
WsVkxFO3WTrtUVLgRcemVUwUmL9cjGYYGayEr5SyijkWhp9JzJMizZXgIelq
XeJsOUlOo43KVGyAYTf5CgpDTTNVCczOCaIGtW41Jguq0hAc/l1z+s1Syl1j
ZU/g/cVcckSiS1+nwlQZq9QVGN+KYPyvm8BdwoxLTiXfeBmBr43c2wjOLHXo
VVFfIbfGP3+mhY6pFix1xoZAzzi7vuNsgEEPHLu+cGyAgS//Oj79a4BAb9e6
Pl5r0w+jFbNQ39NF2O9/DbZSAMdteb6ZACH+tz9L9oL3HgIwCSR/qj92D3YO
1jKodWq2bSyDeyW/pA09RILlVGD1seueeZAfBsK9yY/PZF/K4agzi6lDtW5a
vhL9Qc7ddAZsQTnINnr+ju35KZG3+ElmIHn4Gmu/vXSCURkqtIQ1E5Xqlodp
yj1eueEkUjW9XONMw1rtMejKc1KUnn7mTE4aXAuTsdUUHRZBCa3JmvRJwqas
GNVoyyqN/J15xyPv3OJKZdPgdN5UTNWtjqpT2FIa/bUasUWLV3t405DRfpDE
0JOZzua8RllezxczJ4O/wpQeQVJ2e35tp98dBWvzAEHeeBl4vXdiHpPQ0y3N
Izq/NKica5ImzqcpKYVfkGUKE3OVQ+u9ocnCq14ldlERVf8uWqK7Vx8O8897
mK90lj8c5R2o0HCUK9dvXI5j2Ih9fK3CVq5/a+UsGF7bmqZAUfgHzPpD1b/M
58EUQDLr1hCnOmII15qivjNuTuVjd8UnD03R4KFVY/y5iR+UX2/vpi5pTrSj
O7Smm/B66E6S8qi5nZC2JRWSDbDdEb98mJYMbR8darbsgciBGN1qM9iUnTvB
+R2Wwi7PFGJUuVXxa0iF2npAl7zwDHfuXOypCdlA2anwBlStb4NrdCdcTZTE
iqJDPstiKxwkm0THQXsWsNVER7Si6IhWFR3RyqIj6ig6oq6iwwa4uuhwh+mY
3HGZ6Igczrid6IhWFR3RctFht1omOrwpr7Ydnc633I4G2aWiw2t9G1yjW+L6
4FjwIfzRHQuWSSW+Bc90C7+LMvZlPZmGmMWqTBOZiSen6joGsyEpgU2pSqRo
TqmfdOCrJXXZsj69OY+v8IV5gqfQ+qbJ8aFuHxO8/xgnXkInTJEiQt4bhQs+
fagilP/sQNCFvCvXJAVbFnqajDxuIbWZddm5Rcl4Epm4Pl/sWlq9SQpaezHp
of2t7rzwnV5vkwuAAMpwTHjYXl8mFA3w/LsX1qU1QgBo/DcjTkXJDObQsipu
sOoM9pTEKXihQxmTLGMex+XzLUAo/qH2Bsqnk4xGd/Kqj6wR5S+iR2TUEidB
SYDJbYJOIaDj96eIhRHtAUzMj12xARDvOEGR7mk/b0syKpWjfkbnEXfm7DMq
T5J6QUT+JGDwSsU4KFZGpFWFIET4B4lmoKxAGi1VZaiZYG5YhKzPwkCjnEAI
bmOSbKo7dOUKsupD1eDzPkBnDCbvYQ8MJg817hf8vqvvhdKOPlzPfZbrOaXa
PGRCf8iE7veSz0Mm9NDnIRN6c++HTOiKex4yoT9kQv+8mdAfLNWHEJoQgIcQ
mn+We7eWEJr7UvEDjRpVfBuHlVV8u7P7tNHuHPaK231XNg/szq3mgUe1lc0D
r39H86DGel10bm+olc2DBlSXmAe1Q6s7qnc0D2wgtzYPHEa4lXngCq7bmAc2
hFXNAwf/lc0Dp/eK5oFD/pXNA0fQrWweOL2XaO4ug3YzD5zTrot50DDIcvPA
4Z7bmgfezl3NPPDFRmfzwDt92swDb4xVzAOv64rmgdd7ZfPA1y1WMA988jTX
e7FH6GIeeF2Wmgf+Rl9gUF+l6hw0ajuN/LCEISIzFUwoD2yBVd7jrLm57rHB
j4X8l71eW25+uBHnm8vaeVzdj/POfF2HEed9mNL4Mm4WAHYn+UCfPnU61H/1
m/ehO8Xp5HH3OULj3xzBhtQG9daRxRV+ss72HRQEUTseW/W8OgiqT5L34+wC
b/Qup0vpZX2Wl3aaJenF5SjHeqxFMs1R4LBIDnp2RLTYDZ3xGvOjeiBW1aB1
R6PmNwVc0Qfsn8HgEfyfZTtYfz9C9b95kNu48Lv57zXdb+O8/2jw6+q5t7ij
oy/cyKFb+OxrGC532FvM2xHDu7vq7+6nv6OT/o4e+lu75+/gm7+1Y/4OXvk7
uOQ7++OF/zo741fzxNfAd3LD390H/zHMo/jT8jDIW3jfu7rejQqwmt9d91vd
6a673sbj/tEsxkru9i6+9o9GS+jkaNftu6jRBocVArIb9Wj30x6EzUBulwql
pp0sja+Wz+0iJDuZGUto04UaywwMD6Fm68KedKNpYTfyMO9mVwQBtBoVXg/5
dFXYa9MKmhNBtNptifvGq9mKcAdY3YRo6t/Vfgj2rxkPUUflojVQVk6WpdG/
H11wK4TTqp63j/vl3p2CfrnpbSJ+b4XiwxVoZPX+/MG6EoMnkboYv3eLMF18
YqpyGan4UXrB2zNWZQ+jdKmoHgY2vlCl+2K+a5JIWWzOac0xENJN4oLdznSB
BAxrVCY2hQQ7Kdqd3FKqYAIFjaKaMsrS8hLRr1S4IiUyQcylyC+ObVm5NHJ0
oivG2hawvJ11EbcNXerN1Rd1/UE2TR+x/ecX7ny2ffAEC3fmqlykDsb16VI2
BDsPz6LXZJtFG8Oz15sUB8vWnMzEiYKFn3oldHpNmDsKcai9UF2pzNb8B5GK
bFa8hhn5VRIdfLHX26L/PehRBq2eSZ3V03G1HuxpenFZWYGrFxy4bCJ0pa4C
hkRTFPeiZNbAeoUqRBp3Hr+S5mxVXH94E9GagLpxxUmmgNRFPi8wBFjnvfqO
sTixyvBuDL87KTejR9EZvoD+eYGhCG3Nz7i9ky4Is/HrqpGEwQT+lybipJ/S
6YEWMyB/WXEmrVenL8+il3tYVgKR2cIRov+IdrZ2dp9SYU/nAblUr9gf7A32
pX7F/t4BVbulmp9Z4m2sSgfxZqrepewKkAuZfsNOb8rj9wm9sDov8il1xDIy
DRjg6ET/3b19LjgqJnqIy9i5QFHOKG0STB+G4fUUP12QbIm5gCgyHjKuMdsV
vHPkPpUmThcZ0W/zTRw8cH4kXRXnmrD4rSgdJAOsfDvP4rFIDerCK6gzstnF
JxQYbvq/p8N3fyFczXt/zcIIyXoEoF7aqx2uwMSY9Uq60lwtPwNP9ofSKuhR
5SBR8gtcTMVBl4sRHbcg5d4nyPoCGQFJTVHKX8aSQD1isFPyeXMRAHpGWLWU
WJl4IRaB8DLHNUNmAXP2Cubp5C5TUNwJcUFZsIDT6WJqMUIdTdU9H8MpSLK/
hBGf34irrL72JqvXdg8zKtC7jy0Fpkj+TuH7sxs9UTM9bitHQB2VTfXawHXj
8OJQFjmdnBEaM0GsHBNcIVbhQWH7VLj4iMvFlrWJqAB+zcMOv702SRVqlWcj
fryAWJoq32q2/pLSU4Sad4mndOQhICSXRw66BK5KEafHku3qOocY6KuEShTl
tVwf6uGDKTGsX6aDfVbMDNMh1OgqjZH/dM0TSgmIJ5N6qiHEyoUl9XuFjJjV
KvrzxBeZEaU4O8NhctF839AULF4h6THOaQHwVKZ8edLs+EPFxD8CbRAmWt0g
OQIOM6LJUVwUStuh9HNy1ugsHyhWBKTCRwOuPWxy0iqqSQheqmj4k+0dEM42
uRoJRedH0AnXwCNcGZ4KIDl8wclJT48Jousk69lwuPCOSodI6lws+fhEWqSl
3sxwRNBLJJQvNkD8ovYmqSZs6GjxsiBE+iyyj0VfP6OTh8/CaUpUVLhsWXsc
YTGLubliXCdcT+sMrHPr+dTcfDKtoXgAYc9XlE2HB4FpwjJfJIV5PQXf+Rgq
6B4SNYpdX6Z4/I6lHFnyAcyQKtHPsswc2+lqjxwBF6uK7ipBrE8pnSGWXN6c
glAmO4WliC+SrUi9h8Pvkg+g1xsg87i6LI2ignKI9FDluZST3VgASAnHrVkj
xBaduAmw/aTkFJHYji0P0JKi+LzSoplpJrqVsI4sL9hZYpjw6znjGuW99O46
j/jfIlrH8bySMl6Vk7f2MNrYEQdMTztDQetmHNIygGo9n6WyyBScvwCY6B0i
YIvH/cGuFpC7T3ZQq65bWbGlLsi88XTb2N2Metq3246ei8x/SidGSJJMxpjS
larhacXQRXbfQxbNjug55qhVpMVTGWwySqw7sRb37u8oZ3yP7D+e1DZe0ytK
1/eqeIHr9i0yPF8x0ZV+Uwg6GMh+2B2xbBhFMUOFnT1rzehQ28JDCsSAqiFI
05Dd8O5IVm7oIBK9YeN3Axr0h2825fR4tvsYLFdaA5OXq7SWjjI6cQLbuFRa
1RSsCDpqEK9XLx5raxBztlsmNtcqjMtyMU1UulmrdqCuTMe0UOMxfqJ/2hpX
6dhh75ObiPyccmbqY0R5FbQOTFiAuHqdMypzEbCU2TcewQkJdsq1ynGtwBjw
rH8ZRAa4t67hdC221OtOeSppMFNAGACI+wXsxTFaLLYDZpTcAKuqJGL6PH+6
g6UKtyh/ayaAzoBDTl7QMr1Nxlfwp7VN9kydQ17OTZVMmGwuCYjY8hKCNXqC
UnLTpHJUlHDioEpmF31EgvMCmVRgyoDgI/WQFA07qiJgsnIDO1k0vZBFSSBI
a0eI+KPwvCT3EzW1XTiH0Wkbhkqv7gnkntKuK2JlXOBkQr4oWiVsms/oB9Vf
8ZLrNLKe/braiXnx650f6inum7PT79RbXPSQWo9x6Zeur3Gp78NzXDvO/4+V
LbcprGJ5HBMwb+wWhmA3fF7BHu3/vIibHjy4WWrw03Chaq6tszJecmf9T+me
jx5eKH3GrdpMgNC2tT8PL5Q6UOF3SfL7TyP1yst4SmlXyuCc+vr3wOzqQIAF
wea8SCryB7W/07Ia4pcd3kh5U7sHaa6bz7HcxVXSIYCia/j6bQLXVwlZ7xys
zrEkgG9fB0S0BErbWPSXRXFbF+Yrx2+7aHUL4b5T8PadwrZvF3OxLOCiW7SF
B2iFpId3iLPoGmRxywiLO4RX/JPpXp8pNEIbRBIbQeZU1+AIatxkFx8uvWoX
71Ko8JT7gID6p3IlSy4kKYo0QUv2J8mWRffH6J4yRau8C3dyyP68SMqKbj75
DmBuLkyonBZ6aVHDVaWg3BI2eTG+hO5FXOWFumMfm3tVmRTS5mpX+Sj2H6OP
AhGjr/fU1wePD9CZZN1CxLNZvpjp9aLp8G0Qucr4tA9dJtNSDOH36OSFl5ss
GkrmL7ypUXnG6HZW284M3hzy1o0r5tICsJUaAttErAjoyjfXOdW9gZ8K7WNG
tR7RJRcM3meQm3QECzLJgQwIQc3RdbYOzH0U0wz7mxaP5VcmHV1JqjOccT5L
qqb7jpcwJpf+8uo6CSIvz4YSyKBJqnPek+c4Ho+TeUVOFtYEGq6B4pn0tqq/
qS4Uy4PMmzR5P53bILdBVALvTdkdOkpEb5BdoiKMHMQHtjNVl2LzoLJ6YLmB
WFjRKLkwivJVlod8yxVSbd4VMRgJBWHibIDHT7afwWLyP57sP9lXK+tshyc7
BwefPn2Njkt0LW5ZLtFJDnOe5ZXMQMqyPX68y4EWlmep1bXkuIu85PsnZ/2T
M+VlwoPC8jLxT13dTNT5wc30x3Uz3Uc45R2NNufxnP1NQyfyvjo66fKBwkbe
Xa2bP5xuFP0R/VKd/U8PfqYHP9MfQe49iD39eXDqPDh1/M4PTp0/gFPnD6R0
fCaHjDYddE10sjy6emS49Wd1ySxxxigvhR3F4NpjjCL7BrgRvfdAOR8y37g5
/XwYvaQQhJ0t9ceuRq6zy8MYcuzzWGrHc4ff0JDX9crVwGLGqzAutGiljKC8
zolN9A1CsONiyMqmZxhpgaHftb7Yk6KZaqeaFnUeF61ibrt2s2dvvz2R/Oqw
hS1jG7/vXP44fciv/s9uad/dO397pbU5Exb/vpjToSVhnHwMNie2UrOfQdN0
4vZa1gnDXCf4fsTutazTebYoLz3s2m9E5SWEUaIDiT3+FQz4h8CSB4O/CxX+
YQ3+B/H7jyp+DUlv74p48EWE0FrRF/HgTviHdiegqvJHMPrFiNFl6k+6J6jA
tr97CEakaobZz5AlpAHzPxXAln6ABCCur4d39x/v4RsOnMxrrDL3fTJTObmi
DfhydiHvb3a3n25jS41kIXAdQxptVPtxmWujGuqpV1EboSdRm4drCvSXUc87
aPihXIRv5eh+3TyIq9QjL5wKd1KLAnw8sAD6h1AjxFFyjoXqY20Wkwk8ScZZ
zG/jCI4NunZUWbBDoEdJVfGCyNtmRLhI4HgoEweye54tR1mji09X9Mt5KWtH
C4DLxclI7IPPC+aQp9eIIje4N5eL9rcgbMtB0dnFYXsrPAfHj2/fiocD/7Rc
HPTLMt8GiqcH58aDc+M38HSvrKHrPnNcYkwdopUhT7F8sPYbATxY+w/W/hII
D/Koll55uUyig5NzhFsrGzCkzULF4/eLeR9fq1pdWrOZm9HSosJwY9Pwy859
50WK9p9nSLZhWpe3+Aka85HNtL7Z5dK5yWzUf69mNjrdVjbODGotZqPXbjXM
opUx+61MQa3ziS1ImuIyI5Aa/QGswNe55JEijCS7gQT4Pnt88PTTJwVKxyLT
MBTpjveQODqq32YPu8HoTr4kGkW/Lrc2sTIGVGohfhlgv5q38zTV96+XDVE1
sEDAl/yCvwTqZz4esqn1VXR6MSsNvlRCm8thczttgvAE9HhkPfGTfr3pW/IO
sU0xT+L3mKqNcyhQH0pvhGyiHj6Uq5g3BNWya8wSz3LfwDIluVOdyoYNLIRC
WTgQ22QtLWc9TkNGeQ1hKBrGA0dx+JgsBROlbJSwBcxDgGfyEIB5apMsrujN
8JVkCYinkiAAvluaFyCeeobWH8+oWnKBps6xtlzfrhii9Ar9joqg3RW2RFok
kz6eGdWHuhfdxGI5UwPe092KDzU3ergXJwmkLIpzkDtF43lud0L/hyRH9z96
qN/W+PjqH838WOIF7cBtjtbM3AbkA+apSMx6lkJkcRc3CCxeN52qzBfFOAnW
lgkVl9H9bpewXndvtlasP1a1VnwKdt2vdaJ23LJex+671uvYeeN6/Trt3VBH
9+z499AK+BdK+HWn+yK7+zShnIs5K5sPevdvonffx0tXdcTrh66gFix93wpt
LK1apaUzWXB1DnBMeKZ26CEn1mYZFso7jLnRMCmSBD/y1YmjOk3j+Zy1XT8p
FOUXBAg6Ex7rLyf9FwNyCefzMr6+6FdJXPbjqgLc8JDrj9NivEgrTHtpkCN4
clGDahklOuScZQnhgDTQaXwXs0lSZDeUCotTOauneZgKWWVC5uTTu0/UmzxH
EAdowbm8bc28qCc1F+VYp2hupZebT/0eyOVN4rMSrPUEIvq9xWRtJacPtrPs
ETDUe9UXJQO0ziQViasTvMtrZiepfD0rrTMMp8s1B1EtW2Cq9sJ5Fl/lzi0g
ZrYF08ZaSHlWPc4wnHZM/dRj0ad8x3eWxNMM2YJ/Qlo9oZ82B04KZH7EzVnz
Jub9rrUp+fUub2w3x6qd0toZXiXIDx2bNG16VZvOOCWr+oGyZU7TcZGblJlW
Zn5Kwj9NKS00YafMuGgOdl9SQWuaLZpFf0/pSg4zJ6Z8m9l0Eq+CjLzY1oms
A0g04YAprXn1kK1Nin5zxGtMZslFXqWU8FWmbGGlOyiQmAUR861vSe44ufJT
e4DNP7t6Ag4uegIN+kMo+W/yYU6ZemmSciVKwBRlsiy1kl8GLhNP7FzYQn/o
C7hMY50Zlq4RNcN5JuyUDg5M2bqQ22Vjwx6Yx+6K52BIK6vzVtQz2kbPZMSm
q032uqggbtOMRqQc+faYasQShxzskZ8F/6JsoT7Td8jRBxOFlmhwn6mDWVnd
8P/qEJUTe6npjd2U6U3M05OePUtql86xQas7owgatQijRLMppnAo4nNMk8ku
mgvg9BklyH6nn5Ork1yHKFBsPIg9ReL2EZTceolGVrSLZxb/uWd12eSj7Cp/
n+iaFRZAI0+7ORserNE7x+RIIJxeA9twNV87OFrddPxcXePXrWiirAqHi8r5
OMhpHTKZN9RvfkhdpELWJDe/wNhsNlnqAy6zaDtcwUWOZn87u/ZwQ0pLNM9C
E0Q3dQy4JfZbJ9NARJCYBlqo1e0DEnlckUVJvCsj8fj7pQLvaryqr/Fh+/8W
IXnKvq8WDXUPa15KBQjWc570q7wPZsIIjtbrdAIWgC1e0tkoB2ugP7p2nLHG
jya9YElH16Ra/4/bTo+mfuYfwo5aR4pg481var9GIkVgP43zcjPUQKMHDQAx
+G/fij2IaoJAN1YJCX3/bLh5Kq4hbG7qdza2H5UrtU9WhJ+sCH++Ivx5B/i0
MlQxIrgukUe7ZkCRR7UOLZPOMJPOMOedYc4bYJqdNqadNm/aaSBEHrbaw1Z7
2Gp33Go/525CEPh3eD/BD9rn1LAxrCbA29a/nICxyF0Vt19DvFi9T0hfjWr8
sYq+Wh+DrUVTQDpqkg6iqI0x8kKZln0sHxe6tIzHWYiQDU2AkGDdXnMdmCZ6
et3DHcJk9bo2kLX26UBWo3Vf+Vo3689hp3ygHqUo3JaHntyAys9XoicetLmA
31lM91fvfiBf0OiGSt2Ij2l4RH6QoF7XI+dJL3wUWUPdOCiaw8oZ4zBqHCV1
XC9KgbTgSGk+o3NvcBU/9HJleWy31UH3go7YjpLvEpMrbxp8AhPz8JFjtgtC
i3kjOpjTWVDwUNtsJ0/bIoh3p0jwTQfX41uUkpkSS4ehY3MSnViOvLfoNdw4
Onm7ueW1er4oyio6S3/B35+fqd+PP+CmDoA41iBUE7v/se5/msTvA71Pqbek
bKBGdv9T6D+IAMut6Bj/gw2hS72oz2heUrGhDGby/Axa43+o9fOzQOsbTobB
3lvrcQwoNADHqXX571xedAf9854XzfG+muVGKPSSpgcKlVKC6OUID2ca4gMi
4Mmj/GxgN8cgsbb2+LuqZaV6IF9JJataF7w6yTK+gjsbnqqcl6Mky3HGucle
ilA8uMyjjaARG+FjnTdUCtTxfuHCvSxgfs5rBX+5uChspb/mZ+IkLANlchlA
4GRpBDg8erkU4BdR9Lfh6++jV5wslB0c/OKEpHBaSh5RqkFL7FHnjoNnz4g7
3Oo86l+7z/atf+3t75l/cU3gLY/H4F/B2zrWS9Cr8GlL5Yg9OT4+frq9O9j5
63iunSt0tbz2p6M3L46j58ffn7w++3NEN2br1hOab3e3dx/3t3f6208G2H5d
vbOxn9lEv67xPXVfohp3Bjtfw3focCnneGG5vijA1ocuh/QQrjz8MM0OZ+Uh
3W5boNaxm6rqx998jXzGFZN5TKN60bi6ufn+a/pa396pU3kdSBch7bDuzxED
oDV9gYfkK3J+n2uP9S5RTnmv6+f6j6evS8L1k4cdxuH0efkd7PD7FryQMw7r
WL1jMaOTAAeH1N49d0T9dcuwyIKHQSr8Z3ITHWHv8DTFJRWYaaHm3zYs8HrT
bM2jM/VwDDM3t+LAhbZrSMDXbYwAWwoZITR3GfmUADcss7qK95f5vG3asKmb
xjzRd/uv4ll8QdmX6yMnCezi/iSvdn4Okd76oQENFASgQU4ikQaH0fMinVxQ
kdGJ+nsSvVZaar9fZ339GWKtOfLN7m3XmChINblYd5CeXbeT7HETyRSS0Ttd
8HgrqqNrbhR3gjiV8VzLMI0TfNnGO/vbTzVSgoXBS7T1oY6aqGN1mgMHUYXw
03IziJf2EruY6a9b8DuCzxIhZ3CLjjiiI7zPY3Lj11CA71rGP4NPjSF4Yz9P
QMUqmNl6bQTSaPX6GIDSF6JuDI/i+ExIBv/Ji4t4lv5i7pOAx999F705PRv+
9H208WaeSD11HNNsLs4I/xMsHW717zFAnaHS1eqYUVoHED8lo0P480+XVTUv
Dx89QpuqKjAioKCzdwAYPLq+eMRH8KM/81yg40vQL6Dnn6ZxmlX5If/+rXT5
s3o7fDxJq7zAEV7llzFGaTzPF+N4EqeFTxWBNOWGg5E0/DYvMFxsAJyhhscU
5Az1bQqHQDEBoTZKiqpmPwvMouDfv/37YpYCzQawV2uw3mB51ej7fPZLnCW/
gH4TvUjzRpA5th5cqNaTZAJtv62SLDnPsaR9ENuzeJpiUc24uFikWRPksqRm
gxE3+9+LtIizSf7tLH+fhuE+z6OfFk3gMmCKwfVilH97uYivk5QgEC9YpjXz
A2l6xNlKDWIdD9VJ+lYk3FTvNI5/Eq5jFDAvndmAKqSqRN4uN+VN+VE+vynS
i8sq2hhvRqiFRcTY74pFWWk7CFaqpFqfpoh8rBYkpsmXxvqcYKa8ISj4BBYf
nqNGbl6xvzXVnKVK64KrSXKgF30zSmdxQdrxFO0oDOjKFaPiP7D+Jcxdp9Hb
Usq/shjnYLEtuMw3q6blYoRl1xmAMjHg0E1mGDkG3UxhW1Sj2UB8m1xR7ejn
Zy9gj1Fb7o+BVIAYWhwzozMNxjrjnqZfr4xeJhdxFp2iTU2p+4UGWcyP73Nu
/iIfL6xKCBsiBSoEkyRGAiis+xgDoxexXsjUY5/UFCJFyflf8Pk6wucclRQx
xa+BOZLsnNjpfAELmBHuWOMZi96vk4pcJDyRyCjsSmz7TIwicpZWKT6jUZ0G
6y3iHJGqHXedzxP4z6NHHJyHgEv64ksApwq609MgoHipIwYFCVwGDNEqlaFV
Rl8+wt7SI6qHJfZNyF7j3N/pYt00gGuom/7xLLBHRYJwBXCpOYsONqEg+gvx
hET34a+qOV2VKEei/pJrUkfrDffa/23+7KeT/xgvCkCr2th8NBg8WrcdqdG6
5YH8H7kO/2/1v0v7YhvqyNbWYTyWv9B4U5Ni1qAgr7623s/jrEzkd3m5Vqc3
UHwI1BqVeYYJL5yYyiCNhZIMksxpmQx01kzViQvKu7OBdhPENW1FC+52diDv
wwNP/KY8Mbb9+L+FRJCwNU8M2LcJv8fS6xUUTP6gK2lwri9mOEbrnhbVAG9b
yTAKv8GKeuvp/CBLKYKnPxdlxrrHKtejUB9OsKQD5bT6WJTBIQLzN12kUTr5
/AwVCBRdnaG829P7Eg+2Z9rhHv+29l+GbeyJ/x78ElqRFfik9c3JvXGNGsVE
9bcJolaU/nUYq5kMvwub1ZbwLkwXDEW4P27T4MP8FQ6E+NdhrPr8fx+Oalym
FVgpkFnq3vhI0vqFmCiU0epfhoP8yf8u7NOwOst559Ejff9plWGzmcoNh29k
pBfKLyrQdOw6uf10NlSrrqZ+RVblMkf1gGx4pJG5wrcHORe0FV9rmRp727yL
AmLE83KRxRaeDYQ80p3s+18HwEAvmdgD8ZxDYA0P0z+tcDfrpygaoWfLfVZj
oBMkwxOf9F8hdHGXxhcX5BDV74Ghv0FR+hti0MWghQ+9uVwHdsanjn2MOurn
GMSRnW/AnjKz24ps4xLZvGfNgaD2NtediYZRBqTfzLIb9VCsVI8+LxOd5Ib+
9qeVencLPR5xsH4HWtmdaSeY5xgE3fxqyAeI9XNzkdRpujpBK3TGC4B0Lryo
7qvtAJPopJKbBHfGsbhJfSiycejZrtwzgBDB2r35bMuFQilm8YEptCuS6yIl
4QBQ+RY4+vHl8DWOQC/ukzJxe1szx30qsUwmPezRcf/02MR+Dtzu9nNknIUH
rryZqrS10dAqbutPAJ3oidvfftmsRMLpcf/o2LsENnhZKw+re5njfWI+76u/
fnW6Na0rrSxmqTKLayhqrSyHMjkjKtkxz+feWEp0JNN5dfO190szHoDJaT6X
mEPmUn/AT4HhF+XlvY0PsGAH5TMq+ITFrpGJdNyTehaNu2cHxX4NAP20i3hd
JcB7uAu81+pbeMSh+yie3dS7M723nDzI9GAaeXubX7aL/nKe1+5TI+YZSTV2
hM+D6WI+2jg9Ot3ErYfL2oGo9JY7wwC/e6LsOwFYuguMx7tH7kEEyAYCH0bo
mcYdNtcXfS0Tsf/mKdGqudMhqd2b5RWeEsDHmz0XIE3WCkI5vMpAZE2+7rqz
htF5iiGdaqLW0jHb4qw1pf0ZG7mi8mAgFIcFYouY05zH8aHEeJULBENWMseS
Ae7SMEw1XzEIkkb9HV94hz+TiHl53e5Q9pGa652JaYc66rsJJfCJwHLyIsod
prUbZAbkBL0m988PnIUgxBAyaLc12f08azL+jGuy2zQt+auu5knWxL7SpO5b
4fPg/6aqnz/2SkqglvFqHE2yFm3QG7BZuf45nd2/bo1Af1P6/jWd/XU1ouoc
INjVMulaaIqzelCwHxTslnXtrGCvrF/TS9DaTzB3jJ2L1nc+7nrgfFVvuTZe
14VJnzhfzMb28yy9wiGVds4q7B9blQ/om64u367KB7qvqMsHIKAafG8q++dm
FkvBt2iu9Xyl1WsdPkAvrdV7T5P87W/luq4B6Vtk2FHp2WiJiUQYnMZuz8kh
YJkxD9ShRK5KTU+JBOxEovp4LdOZ0jeXILPLyFD+a8N0Nos1kCWyUKbeTNKY
ssqpo0al6NYohqDYWJcabYPFFhoJc3JJJtlNx+k00baVrEJSkAyYyY+frrEU
mZlfg3NYtggP9uCDPXjP9uDnZIZmY3AlbvhXthb5v0ohy3bl3Wb7/cg76124
cxEjvdU9oQg01BYMLkrZobA8EGJkgqhonpe7P56+pnIKN2qCN9xMjWaAVAsY
NpMBzVyNCQGT4Ua1OTUaMC907L7MTg3DVflq+9szZmoj1kxEvPPJdsGqs3Ah
JqMvMUGJzWK0nJYJyE3sVW20hdxshExWIQPoYPmYU07SIQR0dxkNn55dFNRA
Xr7pt2D4j42Tt883wxcodeb61HxZ2E/PravgwJ2h4ff6HaR9ZUjTMKasYGOi
fgVFWjAHB+uWGpfPrHOfONO9pubUYF+3bQ17i3p3sJzZUHOWGYo3gWVBok3G
B420Lhejfo3gnyzcKb/oiF7r1a71b4c9o8sgvamMiSExB/VWRAkerc09nWf0
sMW2mdVNLi/RTKCiWm46Dq0xpvENJZF0cZjkU9jZgcmP6A1ZYNrAX+dJTHnl
1s02JS256MdUaySZmH6aj7uSi7QItGpmZmoGC5OMuZZJwqKXXaKFJ1LboOKz
cGZuCTqQ9ob5Q3O3ZIjTeL11du4tOIx3nl4sCp1H9WU6ex8NLy6K5IK/oydz
0cbL4fdWfiCDWFzxU6LEOnCZd22UXBkYWIhG4Q3j2u4sHWXRdg0+TaYjYIUM
psJB+UuPCJco9JaLYEQIg54G2OKQYFqDOOL9fXITrXth1y0i/ZUZxz3aiYiU
yjCgn/jEaxvCHYRAdlciJFqEihM1hIqk86v9TsEiCKSvNZyg0HcCjJxM5q7U
U3UwAJ76ecmOTlR5JQWL7QJOki0buFfWDz8rksZIGh42Q+y8qA6lcHm/LYlK
Uf4z9XbNxtLAsTQhVDYmN7CK6Xg5X/8kTmJTtQltYgWYVbgXfzk6ReWMcoDZ
nCOjTBPQtpXQVgZmOjsvYp3e02YnIYGqtsXiuJundyidcQ9e5tcOMQRzJd49
HyQSZbYgJnd3C+8i+qWfn/fVlGo8JR/tE9o5WMmt5iZXUpjAkjr1stiYCZjw
MimhruR5ZW8snkSU5qSrHU/UkDLu3hSNkNTJZA2CPjVap+ydI4KyP13NavVp
c0YiZD9/ZkrEChPN8zwL+OhI0uJvfSfUrgv2ZBXgzyNANLBIik8A+ZAPMzKz
CnmEooi2HXnSMJd44RabUCmZKGl/qLNO2lSa6mpSKaN5NHKC+aPR8/tkNrG+
KZIQCF0DgEsJTPmKKVZuUKpjVqZXJKVwoCBJhIT1xdQee1qqwEq2nGr8aV9L
kh3EJEY/0Ae5bHWeCt7TBSHUaIelNGzShablu4LVRB1IzdNtPMPszxTWMK7y
AlTJYpHcijZe5XdytQlyKR8PSLwVJmjR5Y7TWxF5LJpzW9zdf4eFp/lLHUU6
HnhyOZ53O8ZOjQVbJNoti2Kub85ds1s8I/102VG9pYqMWJ5lF4S6w2FPWF4E
tEqcizgzGl1gVv722hrjbxEbXIH1XyJ4X5IiQVoHg6gvnr90NB4S8+ZOwxGE
gfzNhSBVTDKm6ObcZCE2tFTEbii7/2rRzF32Fk+fJk46lhqjKv9+VJ9ko4bg
6ATMzi2L3oKkUlExtlnfELsoOnHJakR+4x9asxX0CvMu21PVLf6pJwuVxIu9
GqfTCYyhAFxZCrDrbQa0D/2cW3kVTMW9AAN2lXZLGNXTdlunvBWOcyRTRQRA
5jP+CjzbIhGJpPV1bRSH74RZuI8lttolVUBT1auJsrU797YwlID2GCoUcNCV
H7pxQ+sWCHNCGNduRkEtlgw3JxdyD+r/Tc6YtKxMJRwwDT1M9SMPtK9rHpMQ
xUiHFz3fU+PzAvg+mfSBTQBe0cmdYjBsRY3v0kkTcsnvFUgmvNNS7cR0ijlx
vCZuf+PUCJy7Zp734NMZzmxtVxIC15dlyT2YbwaGMFvCze1IOh4Nj5WdNz11
BMnv0uF1bveLCpjEQVdX1cE9u6oOOrmqcOBamW5xMdvkanJNHXxG19TBg2vK
uKYO/ulcU3WF4sEz9Tt7phwue/BNPfimfmPfVO3Qsj//+L6p1uk9+KZcLB98
U+4yWOP9Jr6poGR78E09+Ka6+qZapN1y39TBg29Kf/4pfFON3LDMNxXghI64
/ubOqYM/rnOqGbV7ck65fd3KRL+zc+rgMzinGth5qXOq5m35HZ1TK6XcAXWs
g19q77eLft3rGP3qBH42xVwZEYuOx2Xxj9imPexxhdgztbZeWFsjcgcdkDtY
ilxXb6NB7iCI3CeVeFtCvL98hP9+9Pz7U85NZCA6vDe6mPfp90a2O3IiRTWy
wAUA2+E5u1DdqqymHxvHDhi1NXEWMHtKZc6PfexGhtewTFPC+eed9yOTNL6Y
5SVKofmimOdo45C0LROwZfFrA0MNaQ+QWq5GDA52gqIDflmuTnNIhaZU+Zo+
UbzuOA75jOOyz+66JRQTLV124/Ases1uvo3h2evNLeBLylNz9jrCzP/pbFx5
vgacKP4s0cAmOHJ4BGheJRnOfZYkE3NyWpHaWEms4xTCLoMlE/M0DMRUv37X
0lobTcAkZmYqQ1oAaTnvzuNpmt14uAeze/m5vVwIMpfWXG7Es5jPWkRI6fiB
CFJqPJT4AIc9eXpCvckC+AWO0vH7nnJ/c/k29LHxXctswueaegRn+hp4dXIU
eZZ0JoK5cEC5gV07zd51ReNmplE3xI7Y0qu5RTy1FSXVeLAZwHa6yKr00noB
bh7ztvKUca3WnOGX+Kyb0gCg9p9U10mC6d4v0iv4X4enZkl6cTnKC1Ol8DjE
X2U/Bx0YzjqPrqMcJh3PluDJZzywOV59EMtraMBCyuKGrU22ZJHMs3is6jsa
RKmXr9SIN1VcVMOz/z0dvvuLCeSn1wmubBC58jo0TyRZP7+e1STA8uU4OUd7
d0sjxcsyjT+k08XUWp58zMkgx9riMPhZRijOV6vSphoJzsedrOk9SuBcSMix
jC4xLFISFnFAYvQsXmT5KCCvu6zpCRZY4aqKC35Gs6UFr5RI1OanEr8oKgyy
LInVMxpHlLdKcEt6kDueNDFoLGmjeEhC5oa+IlmiZqzvfgwQ3rjIKYv5hAS0
k4LjXY64UUZHVVjyMr5K88LSBXs1coIsw3o3o0Q7QChBZg+zhSmMrcgstBC7
Ec86vfLKZhp3cm1zct1XFk+UOAP1ArTPne+80eVBKYEr5cVlPLnCfCQqP2tM
wtFaVd5GRDU8VXtudgUFihy2NhzrXGCAgRmmVYJ3k3mRXqRGmWtPfeMei076
Gy/5DWrYPbzfdbJNmvPNyYvTYPU7OXHScz4CadW8s86cTbQ4Ur6QErkmaoat
S4V64hnW6wUJ9IYJYmQmyWSsvTRhG+ctsQM3M+gef6iY67Bk22IGh6tk0NDq
KnwLegzMyX5CZllRnMVGrSksUoG3syQCYq4mfJXGuKAxrPN4kcUFqnBOUr60
1Jl+55gPZlbpPLJZDoegIZhfJkgVCtrfO9g/xB3z6NXpyzM8O39MC5BpWGaJ
aK7rCkYbWEBz08uiwx8p3PSkznZk3Hx+3jv4DLx3sBLv0URXYkAaoisXKv+G
QdnmyiAzNnKjxT7208al7LiUmR4/2d45ZDyHSgs+E9sShXIdyxAzDYUELjOh
g6ww5c4SsZitnGmOj4/ZZomtLmbJFlU7dlR3lddGpS8C+nG6FtchbnBgsnnv
JhvskhXzDodtk07Zvmyry51dnZ3VjStf/3ioesdf44jH1J2qdaNyUj/ICrdg
HfCb49s8aqSnkwtBu2zQZAEVs6/KXP7atthHXFi6VO94WZFhRGOpkynqKimQ
8fjS3vZsrNQHszTkvd2lFHLXpK4e4z7hARJjwqTu+3/ffeJEa5yoBGhchg8m
jFAxzGmKSZw0aF1Vfpyg9HXgqz0vtpEHXxzWU1a0kw9j8iXw+sZ8EJh8aKnj
qu0BzfGqus/tejq5C28u15dflzJyaO0+oYrQz8lxH30PAK9BkT5V+cqj/WgD
yNPfDx9W5rh6Otgd7Ib3wTVIPyqWfAl75jLPajtiAnJtGmcH+87WPS94Yv0J
iOWqjB7bHmeVh2p7MNjZ3l4P7WOUiWW0DrJoLLWE+dMed4cFCzlLkGbbLVg/
NQcqOijFHeuOBMw5lF5c4AVIg0xw18wnRNP9Pd2lCwqdL9H4GNb9psDh8UXC
l6l8jJFQxnL34jby17jGmc1+f8IRBNI4Lib95ENVxH2sarDCpd8L7oyDQe+I
e2uH1qqoAK9hSE/34d+5kkAAgOQ4p5QtduK6qEqnNWKRxx6YZ9kr8mZ5Zry5
2pfSM1KyZ2igOdOPtA7IjFUEhcOrigB9nGuxTESr7cY5isrl2+0dANUUUyTm
IBlPIod2WZEgaiPQYy7r2IfONZpC2X6maRc7ZqJDBLiTd2i9T5J5nGFcXYAg
OwcOuxkhtbvzdP9xm5jqTjdK5UUrkjrH338eH58OX578eCwbveyBCEXn72zs
6IbGh3d6TK66mA9Ksp2900m0ju0eBxlaI8ZVYEg/VlE5PCa1YxWF0AIkZVmp
9IjOEY7z03jqUWwQekBg43yWwNmSFhNx6v0FzxiHwX7To3B/sB/eUHj2ESuu
wDvRx2hvMDh4/Hjvfvhnmc6kAPGaoEstyeK5m7FVFoZ1UNB55mTslAtyCOHW
MIwB/PUIpNgPpy+G78ILqN10dQZ856ylOMKSlDxCvyRFjnYqoAnExex1oF44
eKqp/MZr7ytB9ftsuVPs0/0Qfd18vfi9VRgL74jjUhmAdG5TZ+eS0cmM0vV2
8TV2su4S67Ct2ztB/+suE7PzzCyfnYT5hGZp7u+xUY10oQQzwbm+VGN40GsO
ppSDnWI3MYxDAWueX7es9crL/Nstb93H1PJgByhUV1lVmEk9yIR/PT80uY5U
oSUzYCgHmmS15qsVE1pLXpfSpJmiAxrTHWJ2V60CuZfg6kYg+TCneCJy/ijp
QT4gDVu6ExP6NTfbkt/Ye6H26Ah/xCr0yE5sMYS3zF13yx96nzRuEayKftIe
fAE43Tr4AmF7l9y/3/W2OXTlPgPd8Vvk3qOk6XSzVLvtdpQp/+q7ISqom6Zr
6wBIKV/VbXBK7m4/3T7EDooHEX+DIbXYf7xHLaIfASAuijkPif58jdTXmn9n
TWhnMNjbfXLwZN2ImPvSghBdxosIIbfH5IOZ5osZh556Ft95LgaL6a5STgMX
NZhU6YzL6f3O0393adle6qo3Vvd8FDw0zuKCjEdCV5lnMyfS3p6xeL6U3NUO
FFc3IxI6gd+VzsksYr3n8Qe+frpYTJspijr1BG/Zf2eSujEcPnFBZUYKqvuA
IkGqNNrd59mivPy951PfIYQWS4puO4RNCNTa2YYIcBoVjpCbEc//JJdvaOjX
qvtZGovcNHOVh0CohUUry214UCN+ODZHFBK5NlbFJCzxq48zt+pkWy3S5hNN
Lr6lKCftDKueJVeRdM54CzYbK85Jb8Vnt57ztTH4NlQ9HbGLTbAku23iyh9I
fwi9+vMxaNgedyk76ZNq5cqT6rHPclQd/5OFU/s97fLCOBxYRqPfsT6OZpe0
tENVXTo0hO4W1UUfMFkuRjpFx7r0Mhpjx0o4/HxAV7JpUIf502S/keZdJ0B9
NfNyfn6Py4ngPsN6vjk7/W7lBUVc7rKi/qCeOURTJcveNNH3gFkZO3O3fMye
B98cdvu7z/afHTyB/zbeBDSnl605vuR+kBL9nlWoDA4lLAj1D+/F2sbLs2G5
aVyXOPlIVzEmnzUGSM2r8DJw8FzM7rLaxGtXxC0zUdfEgVtiCnfhEYwNy85X
dy5kVCQuBAkzG9Zh9Ep19elCkVsFE0y1FY0WFaiNVmTo5O8AYDYmxq379Umr
tsotdUi67jw6KNPyHvcmgvsMe/PkrH9ytvLmRGTusjlro/oZUnCyod3JgYI1
Fm06cetnLkEmKCvv0iO+WO9R7/5Ob0v+3O2R2Sw/wL9dMR/y8yob9tnOU/L0
HhF20d+Gr7+PXsRVHL3KJzBRuwS2y5rmg5cm8rQHA7mad7ink2rqtUm27Wgw
iHYOnjx5srvz+BaSjYdU7j5V+01i21S4r6gv+PLM24DjOBtLITkuVV5dglDI
6u/jPocw+6kugrZcSaDjyFCUcQSsO4EpLKPfByNSSy5OR4aq2oR6W3okULEe
83j8HrR/P4HHTw3hOA6KihpoEFMQrndtkFZUmEo/c2QUVdE8xk3sazCd88XF
Zf123o5YX0lMAuXvUUqik+7+hSQYnCuLSBjqLhIy4DHED79YSm0/b4ioV0Vx
n1RFcJ+BrPhvCUqloEfvQfrbZLKYTUCFsa6+Nn58+/Z0c+XVwBncZTlw1E5X
d88eHzw99GbVMpGwUBdv5Z74Nc17oXXvQGwMRFz5ZGwKRuwo6W/nVfZUv8JL
VtEm4dFyxic1gUmvIuR18KCgTVwJa4PrH7/HxziX+SKbRDwWxmPDyC7e8qpt
EJ3hGwgdgui8AfLC/5ulY/3eTk7IpX6aB9eMNfI/hmvGXxnLIaeXxvsZ7y6X
CzPPAVivBByA6j+GD9FxdZU7qdVk6yZRpnibuoU3pvS/SoZ0UytUGoP7OwNV
qov7PwUVpoHDfimXNZ9XzUCtrChxOY4nQIwsnvV1+HA3J9fwtQk41jEz8nzR
y1tBCTDwmb4Zx+OYLvkC+EPbAeCAEf+h6l/mc+/3lohKkV8u7lInynkFwZ9Q
QRnhAlApgP2Lm0CP0flEuMT9VZ4o+pWy5BOMZFw2rdrliDVAvZaVpPeoqx10
CdKWCaZGD0mKhBAXZdPultU/uM3qH/yhVv/gYfVXW/1m6fxwC/GZbyHcMeph
XKWz1oH4mIYrCLWhtQvVRoZVlWSaY3A36/nOKK1XJnJXIpC9mxIVAm7D9nZQ
e/xX2/gqBIGh24FY5LUiHR72eq80gcmNfrCWoDULSz90resEloSx1dFpnfPt
gtt82XG7GDcfSrdQtwZ6B6LKLGphk7qOGrErcR3kCxZINtvL+vtRrT7gCtR9
J49ZGDGSwPKigLK0qA3k335EltxektbKDfezfwifQZ0CAhsaN4n7h6vJ3+Zq
0jJsLuMp1bN0RcsSdPu622oiGbtRRcqy85XG/uMnTw75BlLVdD9VyT8eHUl+
k2NMLXYa9Hebjzq1lr5fb+qvnrXb0fCDJ25jxPfg8cFjxvdqj9MCCL6MJiyY
g3fjcKfH/aPjTR14I9MzCLj3J5wNUpbFk090llZxcZFU9Ma+u6J7VCQqz5Re
Oyk1TQn6g8quKrauhwsfTuHs2q3a6TuCyTkPtLat8bJSHXKCr9S/AMIPRWYB
uxWcDmF0E2HwWKjILH8+1acWuPnSs7pFtn73VkvPp+Vyqz4ruu1a4YKLP+F9
R0ittPeamBg/2kW9ZAO2wfBzS7ibcLBX73ufWxE/Hbaj9TqGP8sS2D4EiDwE
iDhAVggQCR/zTQpYJ/XrIebkIebk88acOCmJ3M9DyMkdxGOrBncPYSf3EXiy
NPTkfoJP7if8pHMASnjb37MY/keJaXFp+F0ud/b0GJuEAazdYiov7DEm5Uoe
Url91f76I0fJ1FYTG9zzwv8Dxd14AS0PUTT/klE0xGF132nwuRKtmDZndh/f
4mw2WU0kyIbHDhvzHq4jOIYWfEcRWKFmx3kHYleXdcd/UvP1u/jw8+gr5tGm
eh63xk143ynnxC+tVUU3Q77umt99bKvWjaWt6zLaGew2AcDWO4O9Fl2qSPMC
9tvqTHkL49q7CNFjKy6wY8H+0eLRuihAbWeb/aDwzfCVmyzgXCK7lmaQ+O6F
8+pd3Rm5NaRWePOO9xs2DP887pLW/LsXOqWTXXvKeclZplg7ZprCKB/qL2AD
F/bqWes0HRe5/7a1MVkowOfMhOaVrspog3du05SQJJmESCv2MOutlPMt9Jcp
lJvLIjWl93yKL+mfpxPoTbsXsABt8DouSA1/IXVTog1AoT1R7MHg6SCQLBY5
UlOz+D2oqfMhWlQU4lnuUO0hOz2WjYbGSV5UfwAq8s0ypdVH9a6oUy/wvNg7
q1fYJLpeTmQNKXm8FXdWqjqhlfcbCeynT3rngNOLoyM6aXGQStLZ8fqJTc6s
rZC5UZn01Zt9Ja1nyUVepW7BWHsjWYxxYw0NkEOzNTBokD8AC2CGASdpV9vG
yUBF6bJxjj/MOTcrUl9G8JdPFyfAS/50inVZOFU+xlJNmEAmpEqgWIIKzKB8
gnHQyh5hx75KaWrHD0oAAt6Um/7ni5nngvltFmHnqbUKn/wjUMyz5qNQYrN1
uiyg8YV9PAqEsW03ySytmKlzE0ndYKNBk/aFxrHFq6NT5+tssLrvPSYMpunW
Yt/521Jn5ONcb5VXPlO8+jXZtVpVr/q65fF0+XrRNclcJUCF83U4wbOlrPiL
LVJiX8UoTmaxxYMboCdtRtNkfBlD66nrF7nf1XTrElpallwuKwXHrCBdKwMs
ri283JSXMIATnQDTjQMQRYnhuWr50nimRhfo+qqmGMihRTEOR4Y1Rlwtj7da
Hm31qdt8uodaGbXUc86tmEOsVtuzY3iVZyWsVDlPYo/MN4bdXT+bsxJcqxzQ
ckSG26Fb0IpVN1ltCA9MIKYQdkQftmoa5A7946H+qx5w1+LJt1Pd4dYjCEui
2WACWBIiXwRDB1e9SxCSWlD5ZqDtORJ+mgIN7uuE5Y85Z580UOXOZisMsUBz
3jkASvVl8ykg3axscOx+mVlPnAx/A6WKm7nD2w1S3bRcRbgPj6wh7vegDtSl
KeJz9Nhak1I33FbRQ/dWXuy7QfQGpdF1iqV/ODu0zrpbO8bZpqF7RN9nPhg8
kmn9h8Kro/tbuRjxUj67YWjWPMyLvLDUW574nPD1by5bd6AhIhbIojxk6n51
SdJwGmrvXobaG9D1TvIhxnKI6E+GLeDvS3W60EWpqp5QL9yn4Pl9Q9zpTmp5
wnHHHct8gRm3KWrWXUO+3liabNt0qr2ss9hM2rRy3N1xrvFdqyXubn8EbkFT
kzGgVGXt+vPBpisabt8FtKr0LPZa4ImiEs11YreV11Vgde3gEFi3uvBnPakl
rKyPzh5kreXndcOjXThyQFiHsq7B2bU04ZqbVLWq4vElRnNF47QYL0Ce+o85
rTtn78XqkqybS18Mhx+Jfh3cZ8aeWjIa2VTDV755pBnRUM7i7aDN1Mlqarui
bLKc6npsfYFB0cRFQQvw6DLNJoB36S/1ZQpHSDG+bNExXCzmBuhYATVaWGDB
uX3fdpV38OmpUQC2OPLSGRzYqfKtsXpjSHUqzUtd+XwrSgYXgy0MpUFkkg8V
3VUUifjNLJXx6Jj76ZLTymVXomI8POKIO663qK6JTd90htF1sYhP0TCIVlhw
gt2EZ8NTj2OB9rPq+tBsnr7aPCG/gPMeFqnu0JM9MhG5IVqVNbv2tl48InCR
0D38Yp7PuOAbk3N1nMuva2wIY8w4zpbFM5qNSGGPFW8tbdwi5VZ/1/nYIef3
UN60+CWjVWS6RRF/VbLder11d/Mbm4B1s348bletRRpJlJsRmRzwpRV+XaZU
mM9wJ6jLfKDjKgiCV1iezV1ZB/0+oK1PJX+iocLyrRPd6zzRZUXodbnypZXU
P+8p89lPF29YgBwe0rMPm7j6yJSDL+v2ojeYtGgakczZ7gOOgFev0wnWgA2M
yK6EauEbhQ2FckY3sDU7uAPVhnn17ocGpyywaHk1PtTI1Q/xn/Ny+SEOjZZj
89f8LOwzrw0o2kvHx7MIWDS1xgGUj9WC7uml5Gu1fvaydrRhgL6sHFaq5EKy
Fj7BV+reIL7KTbiSBBd3jYfp0iAn/PiX8PagGvDXXrdP3r/b3wrhHaFGEWZu
KjDZKxIy/+qjdXmFzjWD++pCxC530IxrwDAbEhh9p0w+843h0cvNMD/G42xF
fgRYnfnRgh7ix3PtpbszW+Kh/bKVL8OD1dlzqU0VLy5IL1l/NLs+VCpPaf0t
hnpAxRlOJlZximbzSeRq39ak6uvUZqtbWX85Ub3uDeQy3ncpcn5kKKDqKDgr
6rk7jfHYH587B6Va9tqqd6ysYauuQiZjhvlHilPxZbV8TrYz3D6J/fODFOFx
3eDsxAn0Zz5JhCPIzdMbDKwmXNX3URnPD+H/++rb3pKTl8eNPQWKJNENuxpR
HIA1Iiq5V4s8xJoMs6QS6CWrwkx5o8pPEuAsL41XPF51jV/qdb3H9RxyZzYj
JX6zFDOebroai9GCjtB3jxkaWWkPy023VrSciy6FDt6TfcCQBV13XhQuekDT
kJarIR2XtRc7ZeJ62batDOM3ykh/h2jXgr2UfVNhB9n61mnX3swSjDOeYm0E
sbB1UVldybF5+0q4uI4qtevtdLzFcUXBbUWAntVX0Ja2Ow8mW78mI/j//siS
gtbi1oIiHjv82sFbhH4fbQSLE8cEGN7R+fJp7dPan47evDiOjl+/OPvz2v+F
z9ra2hf6zg51qhK9zhyDsbZGl+ClvoHiRyrJxCqKWiXTOUaKqdmN+M0XOo1/
lcvGvcET3I3fnPRfDNKkOseFBUD94nz8dH/7ySgtP30a4Fhgk9DvPKl1fikH
LRcZFeBQUT0TfDrHr2WUS20N4zAvZuq5eqL0TIyRSmMCQu9SJli3Ob6g17rG
MN6i11wgr5BKr4/fHb15/R3g/s3b744Odvd3Pn0iH8Xb4zP7l6fb+9uAM4Zp
lYnlzriMrxIVU4NRBjHboIlVqoxvLDbYo3d29hcFcH/38e6nT1vRu5dnMsT+
/gF+o14E/vWHkyP1y7PtbRh8k/BSA9Jo0wVFmXs38BRUhqRVL8Qj97WIp0vz
i8SN18OjV5sw3L8jIntIBYSiriRU7cgEpsSKFgq6caWoLq5Vuv6OC01SDpDQ
dASEC2VtzYtElOwEgz9HSqeL8Y30FWwy8vo0wNHPbHIdOcQeXfSUzio9fSw8
Q8VnzItu4iNWBZi51GtFYHOb8WQ7IqBr2CSIzaMxJn2gv3A/0F/RBlfFUT5M
vNDaUhYVPwFaIxFAZWQ2B5HiHQsJdRs4VlsQaZHAn/T2Gmh6tchAb8aREBBg
Sm5c8Ucms6u0yGcktQD4T+hgtmmiOC6ZgGRgDOm1AZKKZuA05mPcxQ6FYL6g
jTNHZzjQnbc3gslrASd4fhFzYvHzi5gmkZyfQxe8rhOszZjkAleykBQZfhTH
NYox3h74osLCv4yywYsGsfhNaAb/D0eJEC3N6N+HxA69dtujd4iNDjkAyHIX
ylMabXSY5SF8kFGUaE5n59mCNCIsF0+WG1fWwtLBdGvv3g7HciCQHH9PxZD/
//aedjluG8n/egrs+IfsRHQsxVKcufKpFK+TeC9OuaLs1lalvFvUDDXiejRk
yBnJiqXXuhe4F7tufDa+SJDjZLMpsSqxhkQ3gEajP4BGo4KutWpShUZE8gvn
PR3HByKurHnorlkDrJYlnqjfE169/lXR/VoJLkYXSfXYZ1CcQGqmcJ0IlvDs
cqpuYAKT9CaTeHCigE+wzhcLHqv5Qcv+qm7z60W2LvJW2iQg7rn8x5HJZ4r6
JyubGLgKIXqqaKKYSDRupmkIZhB0IX+HgcpNiRE4ApER9Ti1y3OhUuEbaC1+
MRfKHD5UYrJIdEC0PbP4t+cvre6hsudXrAPVmzJfPtpDA5FH5pBxWap4WnnQ
VhpHRN9r9mDVlQr8RlN6hXckw3t+fRb0/1Ra0t+hJS3xnyxgcnDN9vD0u5NH
8qZ5PrMYHlnO5zDzZRilIewM4+0N64Eq53EpOffhV8W13puaUhxC4WA3UE/w
EzENNAXq3qxQDFRN+QvaCHyY9uhp6Vyu2SvzVoS5yZ2wefHzBigI9howRbmu
Gr6bgp1voLXmzI0ad2tlBreOV4tCnpk+rYzrC5J6zjmHcHJIznviFxFFJHCf
+BUH4NcXG25VlDyvbr7itFXRwNgsxclSOKO1sijWe/g/KaT3pL5bVWsuGLGr
j0LS4PFvJjzNFP2rP9qiafx6b14jH+h52c6WFY8vN4uecjBxzpmgl13iTu1K
kWBt6OzyHuxaGyeqOZbIwHobTEwAjKllW3mVg3vUFOJkA9nvVIpasiXfxMCe
IOPpkxY62y5jfxY94pFtKFLo1qmvxhUCPScVa9JgDBGcD1ZDy/cwxdy9KGtJ
BSFiMiViJB38WI1eYoiKUepXiyavodsovloj/7la5zOPi0Ip7vj2s+GUR0o9
IKwlRgj5ytW/UN+D4VudwxslOE0GGDFddnZOoV0NmK6EMx/uni1qzL6BWVvw
X0wbgP+CA7W7F+39I6Tdjdj9lebr/hdfgBF/7pso9abBBQqYOictH8Y9tXih
ZrWUDHLDXqVKkK7SzHKVOJNvWpnywvg+hzjWph1Q17Kt9nxlLs888X/FSZvi
fY2aei1InLdyPYELr5PTF69eMcFzIpMXOgDVuSgLBS7AtJiDPAC1I+FkaXbN
j1jl5/BzzhY8d1nDvVVMulnVNyR3La42GXMZiSxRVSCzUc59W13jyCm9qqrA
Iw7VWhlMxqpWqQz0miQldLEELVvMcuxIqXFIshgPmCt3QaB5wbWgGCQtRKX3
dPTlIfhIwFsfPsCIZfAfMEFr+dpOIJZ0HWU0kpj9PCpTHAJegBIQsRrgL786
+f7E85WB+fl7GTsBbpHA0xSLslXuspbJ7K8/vFJL05NVO0GJKUo2YgxKbs/w
z69e/vg1+/vr79gPssBEMvfnR8+e3d2BYOaePBQHpDD3Nw0mgV+fT/lySDt9
f7mcrtrpDWjIKXGwuSMlMKJy4qvqs/VUuIuvXp5+w3U/1Auvvv/s5L+kOlVd
4x1AlcKbhmuTbY3R7XJZYSA5qCpWZOHvXvN33DvHKmxCCTIcPTkAj1hSjYCa
+PQJUyCEWIgPuuZQ5HvVkWGEfMNTXk0ZM6/4YZWcm8vAvUiMY0AvqC7XZqYi
D9vf4ZFky7KMH7xHNnsp/IOWfXiATCzdhfYOvj1gf3vz3enOznfgimxaLYwE
U4tyMEHqcrZWEql4n62rupJ0YjDxyPkvEi5Uix2nhy9e7ouAq5cHIO1lPTlI
L5mjxJzcPCvAepXePF+HkuINg5HkirBWcGrGc2d8iUbQDdcsS558TNNFA8qF
7huJUlXFL1oG32qleEUsHzwWgyseluftlX1Q+3GGz2P9l37MK+D5x/IFPLfs
DZDh0+fPn3/KrEe8evPyAIoY3I93bqHX+58KpJ9Onh4+mdxyNPjwtH5M/ryF
j/sTVRKpfLuzC3/uYoF/gMbnH3Y1sH7wp/koS+7uWN+dHy/QcfC+4S8O9hUn
6nT/4POn8suuTZ1dDSKLHh598YxQeufDlD2Q/MXAuFsWzyc/wt/LanGjmHgC
YyYWefNluVg9n8wKPA8zuRMLf6AM1AaBWNqDmR30Gf2VTuBoardJRWFMqkqu
+3FuFpsSeq2VO1rFe5AM/Hih4q7WMBefONJDpT0GyunFyvAeSjuZyuVgXAgW
Sb7lGgN8+UmOmNk0EPtKUyiNLrEuak5zTCxTWGOXH2Ha5HUrM2k5H+EzLq0j
ct5mElYwr9b7P0/sIyMT8dLFgVjyRRbDNMuulvlq4p4+mczwNRj0AHN4+MT6
GgkgIF2WTOF29nK9gVf7gI9WN8FtrroAPsxmRaZ9dp8Y9NNPTnv9SIzJ2XW0
0/CpRgMejBSv59j3skGogydPnz2BZ+KUsMM13lJqeP2a8X7Vf6h+YdiR1wka
PxTiQfI90M1QRwHIAGC00T/fiJ//PAl0DvlfRcUESVMBfT0oN/LmbQqjW1t6
b/eUsOgRD7Nsn0oFsq2En78uG9yK0uKIFu2QQ+K7JXn0l7epMkgIULP1hO1B
tTLxu7zX2cGDjg6e8hP2v6MeojYM9FAM6o7YdvOVZT5TqhIVkcgiDUY1X1Q4
eZHnp0o16kXqgkc5g9GFNolUecqtn8sVuZBjJTKVOLZgPgMrNQO7vLnhbilr
y8sS14D4K0ujksMCvPIDXxVaG3dT5GCfgdUAcwamHCzkG+6UTl3mholrVoQM
UvkNROI+mYlvLZR8g3sydYRLjofKs/BHCubNegG4qe2Zf+coTlw9H4O9qn3U
5hetxWVPp3+OFeA3gReQYj/JGGDGHghKVmMSpFoEHMxYBa5RwFxh6hLZn4OO
kLEJpk0Ih1TchnBNiA4jwqcl+eirobAiYtuoXQHOdW9U9fLuu+/edtIzZl38
YTvMzQ6/d7bhEWR2y/YIkYBFqeCAS3nXb4xIUBUiI8Ckiz8VU6gDjFgyiYYM
fzyCMpemXiEqr6gKfBvRflr9KDUoHUUZuKXCFX4o2rpagcv28HXRtujGfVXN
bx6hctRLqb7GcxbyrcVvFXTJY3usqGd16uqs2qzmIS+QqsyYDuSRS6AEtdgJ
aUIVhhURnFf1srUVZF67/BbQLlJL4h8P9gNivEOXyhKORpUDH1AI1CSbnKhz
VkDSQLXENdY5MADqm5dPPjv6LNROk/+D0kcRtr64CcA01dIruVmVoebwBEiZ
OH0GRWGu82CNID2jupwNVOesR6v1DWeITu4oiJNw4UGQpxf1Sh+eGsaVPj0Q
T4eO3NPHB4PHblktcIcyAGcZLtF5gTYD//YbjFagbxEblz4xHZjHLFyrFG4G
OSK+LgJkVsU7lMIINbnjfUiT4NlBogzHDNJUFGNQpi/XHzwwx2B3dl6t/ADj
tVpctN0aZAExPBg5h4uzPISGVyOlvAqpbOX+pl4LN6G3D1+8PJAr34ePeL73
qpELiWrzXsf78PtkScJlfk5W7G+1NJxXBnSQg7jq1CoJ9cXLQUQqvaDHJmdw
eC1ysAOW7GQBNdzlQSDMvdtl1XDvdlH4wOKOxXvCtzqwWVCfrveZp0N0pknM
REF5N2ROBIRlUrcP/5O7fRjqdlxHaJEV0A86kQOKfFvAYf24XX+BiSoxghL3
5ksRBkcTKlRCtv+qpvjyc/ixrS3+9PDZFwn2273ldm+5/QaWmzXPAjPzq1Lc
BvOGzjQ0Y7hxxr7eLJfsRwzu+/Dg5EX2PViB+OvOmoUikmNqBVfsmLNEkaNE
PHiNfZplzXXPAVFe8FaV5cc/dRRdZm430OU02kDWJFP8E/ZTOX9LYHQN5Rx/
ivgnDydd1tkaWTwF5Pao/fPBW+N08hV1IWRRhOK12ZgBUNSbmsnFd3780X0I
llCbRIi2+nwbK0Ha6vRPtNWth5ZAqXYMv8hx/lAxfgW7f3353bFdWDeR3JHs
lWB+IZdktGw3BaPdc4CJtjoeDMxP42X88MFNpKDhNx4vLQt/QuqRV0v3wasD
CRYen8z6p/pbwQkArq36qsJwko/RVAtPR1PVk95UUY+8Ir11Bo4xkZA3bzMR
6NmJhDMbeKb+MwCJfV8PbU90/jgYcKXP78cQDDxv1kVV+1h4Sv/u9rcZOvMN
1OWAy/yf3dC49phV1ytvLPprrpuiLlbzbLGszuzBTKkZr3jLFNug+NPNT4Iu
10VWnWdVUy7KVR+DAifzk7xTXo8E6sRf1ldH2chKOGxyTU0xxzhQfuRHefTF
HKSnzZgxOXob5mP81M99RmyI1JSEA1IGAS+Qx8tw7dtVY3WYkqQakY6oDxSM
BG5srS+gi3ixAGKQ4eRHT/ugxTGHIstnRFWQFK998HigNMfRLQFCtb2z4YY8
HCaoL2nJd0VR53jW6lhi3j/qA0EqcOwxEFEMTyt4Wh5fRtW8Lw+7+EjCNEWe
KcOEPzwieV7h5SDZz5t8HgEUt4NSwRPpvWGhZZv3848UUOLiyT6uljOe35wb
uHL241NK5WjnD30TAeIZKizp3F9RmLIfh1T8dkv/HsePSqjIxNHfxYWg+hqh
Y93FAPMYQ24lHDMLqg8IZ9ocNSSF6gM6X27aC6d13bytVKEZuIAGlgKNXzIZ
uJrRHQE2YgQ0jLnPLKKYpYTJL4nrLyUf5mm1U7KaptGC9BIv1/gJtJCCRm7n
0kP6+UEIKnYN1XEnlHvtkjutnoWA1AU4IdNQV9Wz/qBSmdB1iHy2pTcqg9vs
diVk3rGxGM/YzlxDDRXXjeYpf1jIGZFdMItQsnXZfzukUXSRJcu50yq9fB1q
Bu11tA1y3ey4p5jd1GHtrEyqWQdxJZv5SXczq7RmVts185pmEzLOZIinlMsv
Yl3tpQtSIouuXmiXYlbMkdkiMkpyMF9/9UeYbOqRj7c2mOaAsAjUpFvm7ToT
p7gRRFg03I5cCcvLIzbZ9fPFdpVWPRtcfcdiSGiknHS6gdy5lhbRi5RmST1E
WrOdmEZeaDDuJdofjPKXe4mmJ1FkGkZtJBoYT926VZhsH14hTa6HVZ2J5PqP
jkOlBMLpw7qqH0W+G+6mHj7mNrjpxAgWRD9KKHScjJKn/UFfKIZXd1uXPO7C
a0i5T7QJH1npC+OglPMeWDLWFFb+LXmhG8fBFvUfjKhfiStxUywWWhR+NT43
90yKn8uVMyfYiDmhYdqkOcGGTSGWMoUYKRefQvrvyBQKUJxOIddA9jH6UyiA
smcK2ShjU0j/zYJTKNrUcVPIgx3Bwi6OIVPIgx1av+QMUEZyu9tlDU5s+Lze
gK5a6lKRKeYV7JjxyXpFg9RtsQEPsGyCaHUjrmZ66ni+tl/6PG+yYsUB+OV0
8eox+PbjV/xJQsXvl3nwsymxKi150dkCQ0+0KjEuOnkcbFBzXR92wrnBL8hG
4Iv681WxDjqqTies0OdVZrG/4Tg3AEKiiNi2wok8a8r5gqT4PO6AcAOcSBM9
CEUnYtDhVOAbJCIXocETMPCWMEV1vIXlu1tf3AWGALAkZXx78rLAPZlsWa7e
8ZSlkeUHUiy8lUgLK983ZPA61yoE7lAI0ePz8PBGRqqsr55aVMMXd75IMztf
glmDJqVm6aunUaYWvtJ5+T5bFqvF+sLiXucJ6B57VQg3gWYmWibWqG7T5aGD
JaDr+WSc38BglTN/OhJMql2ccwOIyNwWO3xBbLR1ohhu5sj69QiwqJVDalG5
b2L1aGbTKYAk+sK3i3yhpvpbV3zjH/9xXGgfUgPL0uZ1RDQEgcXGRpDJfJBE
7ozVhft9Ybb3IdSTVJXkGh1tM7+Y1d1MgyUyGmfXyz8eRAw/6UV4i8lrTEo7
NBHt0t105NgxdddNB1o6QlJhEPX6a4wTJ6VoVrD9quV6KmnaF00b7AntQxAq
DjSw7yM6LsYY00HPjFAIOg+WMCAbwCFREICwN+DoEzUWAmSLzlD9M7HfFHvn
LcIogf3lSx8JXcqMFFRP+jLnLdHgR64GP4qYOzENHqDPUXhrb0sNzgZocNqo
7oCwTg2uRyKowR1idmlw/Udcg9MiIzW4V0tIg9NCLEmDOxDeOMQ1uA/J0jV4
B3BMgwdBErkzVldEgwch1JNUVa8Gp1X0a3BaOk2DOxDqiQaJ2I1JaQfr1+A+
HcMaPEjvBC0WhFPPkHGKaHD6R5oGd/5I0+DOHwP7PqLjvRrcaUifBmcxiAEa
3MfRpcHpky4DKPYRGtxHEtHgoWfoRuWvEWFNnv5ga/L0qFknQB3a4YasO7vo
kV50b6hToDjdiTAYZDNR7KHYjX4qiPkUQTnL21k+L+YZ7kcIK8lVw9aAoR1q
igJF4Qf0+v06u6jqYOSk6nXnmo3fMMRLuqiN4HgEJAXFhfDYGmFo1ET7RRF3
qdYvb0d8xeMTNUBnlI4DoYFUpGi8nCJtRwQpRdgtWfqr6Qhsv7Wo2TEHmIWR
jZoMlLK1tWSbMBShoAGfzyPxDd1I++MNAsDDoh8Cje0IhrAnoCw9pq1sq7Ya
t2+g6FBPn7PomDVh0XHUHTw9THSwgaKDDRUdbLDoYImig6WKDopwuOiwq0k8
E9MnOpjFGeNEBxsqOli/6KCl+kSH0+Vh09ECHjkdTWN7RYdTekxb2ci2Su7/
iCfnAoWiJ+doGwafnKPA9goWBQ7LCgo7+NSdpcG6Tt05VBt86s6BTzx156n/
lKNsTlWDT91Fmtpz6s7j4/SmWuM+/NQdRTL61J1tyow5dUcxjDt1RzEMPXVn
tX/wqTsLeuCpO4v8g0/dUejhp+4s6J4DcTaDpp26o/iTTt1FKuk/dWdxz9hT
d87MHXbqzhUbyafuHO3TderOqWPIqTsHdOCpOwd68Kk7B37IqTuXPPHDQ7SG
lFN3DkjvqTt3ols3/ETXXqL80MMQzHTFuo0pXlxDPKy4CncXcJ2yTK5+5tWj
vnIOV2d5lczXPo68wjuU+BVKvQ0kP/W9S1P9Vxafh3YXL+eH6X2Ewr95AyM7
WH5pRrjCDWzrnkFBFJ567LTzfBTibq8sXy4wVvrispde5Ok/J7gqysXFWYXJ
PZriskKBI0Ry0HdXooUWtOqLxhI6KIZa0BrQmPmxZSj+gBcpLqMmvgP5+zM0
/+OVjMmMkWCgU7qPyYlxa9qXmhCDcEdiigkjh0akwvBa2J8HgzBvYgu3tMWZ
xUoj019sY4Vr8NGJL8bZ36bZY1JejLO8NeCoZBdjbW4D2p+BQvFfco6LAaZ2
CH1SdostjWxGTYGheS0cQyQxqUWSbU2xD0xnoeGG57LQoGMSWdyawRiUxaLX
mKa4E/NX6PIpZrRpw4BtqqgdbT/dW1Pb7Hh71knvrpN6xq0bJ7kZPbRJoUaf
g+E0KO5d0E5HXQtayGl5ml8RRNDpVDgQ6kk12L1uBd2JYLO6fYmP3a64F2FX
MNyFiMGn+g9BeM95YInGRef2QfKeyK2NbsAmw+22uyEDtkLG74NssQnyx8os
1F7kl/yskZ8DCPuU6e+B3vlIwMQBXYu3pqOF1b2RQwriy4RNFKdr/4aMSbeJ
imeM1klWOWn6xlE20F5zO3fHSgptRda3zDNCLkealbbGs9XqzlbrOuOEcp9E
ThPHI2XxdoI4VQqPFMFbyN/7fGX3gorZrbgXVA7wvaD6HQiq+2yB/65sgffS
7/ch/e4F2H+0APsY6TY7G2nVJDcHmXkCM1tDnOWzd3i5dGElpezcxjS1lc16
ky+T06lQWJX5qncPxUB46UTxCYoX1sXINp1jjKz/HsbIFthgdjFN62Bkp9yw
lrHBLZOLNSZJq6ZJwrq62r/iSVo/YT/Ni1acNfWPsym1JAvYbU7jqbbaNLMi
uKkunsDWugYefUCtb6Ge/DF0id6lYDDNrSBQr2joSncriBOwqDV0V9rbfuiu
9LcaOjbvu9Lg9ldtWy5/Cg2NawDg6yT9TsHBjipnm2UlpuK9VPpNpFJbzDao
RDzRZO5EsiSUeR1OrUTMV38EdSme9kl0Lbx36rZBSZKQbHwov8VyJegj7apc
nAUDF0H1iK7bQdKLjRVg5CB3tBeaILpozCK3n56JqvjEyumn31+uNxGp4qXy
loiuZnilPL/20Fwsb5/kWvHLtrOzaytjudGaCgrUobxG/q1dTtcmP4sP4Wzm
FivZCQG8QcCpO6vMwXMW4gQoAA2D/9Mz58zjBl1Y7q24SczDxUsl+bG4iVWI
lj9rB5UvBuIvBuKvB+KvE/DzkalARzXBcWEO7eKImEO1hJJFMs4iGWedjLOO
4DQzbcZnWh2badVmfT/V7qfa/VTbcqr9XNn7QPA7PJ/IrZBtZGKQIsDb9BpJ
mpOC2aNiw0VSUvgwIaOFefwxxGjx65iD0zOzw6DD0kFa7rMZLtvIW9Wt7KR2
sWWIkJEiQMjAPZcOPR3wMECYrA5ohKzek0TWxOtJPmvzWl1qLP6G/3YoNcQ1
IbTT6ovqGAv0Tvao86oLv9dpnSN3w+Ilsiezd6vqGrwH3uF258NUBE8X8+eT
83zZFnjX7I8XZcvm1WzDiXK2KZfzlqGT8uFPP3z94sv9Zwd3dwy0lnpx8OX+
3d1jhMsxsmRdsdfVuoT/NYti1YILvsKR5rdIN8VVWVxzYJzH2AYbMG/W5Yp9
9a//+9/m3RLUpoZELwvatK6aVmLZY9/AS/a6bC+anJeDX0XeLG8YLl3CpNAF
/1IVS/ZtvqytttiFdr4pN21Rg3r9uqxms2qZ65JV3VrosPk/bNqWfQue9LK4
0QXB1SMFrZ79T/PLTfvLujpnp7/kzbvqupz9ouFOL4oaJP7cA8QCr/OLor1g
fynW8A6qzlelBjz5swb5f8i00fOGBQMA [rfced] Please review the "type" attribute of each sourcecode element
in the XML file to ensure correctness. If the current list of preferred
values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable type, then feel free to let us know.
Also, it is acceptable to leave the "type" attribute not set.
-->

<!-- [rfced] Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.

 Hold Time vs. holdtime
 Network Slice Service vs. Network Slice
-->

<!--[rfced] Abbreviations

a) Both the expansion and the acronym for the following terms are used
throughout the document. Would you like to update to using the expansion
upon first usage and the acronym for the rest of the document for consistency?

 attachment circuit (AC)
 Customer Edge (CE)
 Layer 2 VPN (L2VPN)
 Layer 3 VPN (L3VPN)
 Provider Edge (PE)
 Service Attachment Point (SAP)

b) FYI - We have added expansions for the following abbreviation
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

 Class of Service (CoS)
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

</rfc>