<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?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-ac-lxsm-lxnm-glue-14" number="9836" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.25.0 -->version="3" xml:lang="en" updates="" obsoletes=""> <front> <title abbrev="AC Glue for VPN Models">A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits</title> <seriesInfoname="Internet-Draft" value="draft-ietf-opsawg-ac-lxsm-lxnm-glue-14"/>name="RFC" value="9836"/> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair" role="editor"> <organization>Orange</organization> <address> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="RichardRoberts">Roberts" initials="R." surname="Roberts"> <organization>Juniper</organization> <address> <email>rroberts@juniper.net</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="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"> <organization>Telefonica</organization> <address> <email>oscar.gonzalezdedios@telefonica.com</email> </address> </author> <date year="2025"month="January" day="23"/> <area>Operations and Management</area> <workgroup>OPSAWG</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 60?><t>This document defines a YANG data model, referred to as the "AC Glue" model, to augment the Layer 2/3 Service Model (LxSM) and Layer 2/3 Network Model (LxNM) with references to attachment circuits (ACs). The AC Glue model enables a provider to associate Layer 2/3 VPN (LxVPN) services(LxVPNs)with the underlying AC infrastructure, thereby facilitating consistent provisioning and management of new or existing ACs in conjunction with LxVPN services. Specifically, by introducing an integrated approach to AC and LxVPN management, this model supports Attachment Circuit-as-a-Service (ACaaS) and provides a standardized mechanism for aligning AC/VPN requests with the network configurations required to deliver them.</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 72?> <section anchor="introduction"> <name>Introduction</name> <t>To facilitate data transfer within the provider network, it is assumed that the appropriate setup is provisioned over the links that connect customer termination points and a provider network (usually via a Provider Edge (PE)), allowingsuccessfullydata to be successfully exchanged over these links. The required setup is referred to in this document as an attachment circuit (AC), while the underlying link is referred to as "bearer".</t> <t>The document specifies a YANG module ("ietf-ac-glue", <xref target="sec-glue"/>) that updates existing service and network Virtual Private Network (VPN) modules with the required information to bind specific services to ACs that are created using the AC service model <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>.target="RFC9834"/>. Specifically, the following modules are augmented:</t> <ul spacing="normal"> <li> <t>The Layer 2 Service Model (L2SM) <xref target="RFC8466"/></t> </li> <li> <t>The Layer 3 Service Model (L3SM) <xref target="RFC8299"/></t> </li> <li> <t>The Layer 2 Network Model (L2NM) <xref target="RFC9291"/></t> </li> <li> <t>The Layer 3 Network Model (L3NM) <xref target="RFC9182"/></t> </li> </ul> <t>Likewise, the document augments the L2NM and L3NM with references to the ACs that are managed using the AC network model <xreftarget="I-D.ietf-opsawg-ntw-attachment-circuit"/>.</t>target="RFC9835"/>.</t> <t>This approach allows operators to separate AC provisioning from actual VPN service provisioning. Refer to <xref target="sep"/> for more discussion.</t> <t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t> <t>Examples to illustrate the use of the "ietf-ac-glue"modelmodule are provided in <xref target="sec-example"/>.</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>XXXX --> the assigned RFC number for this I-D</t> </li> <li> <t>SSSS --> the assigned RFC number for <xref target="I-D.ietf-opsawg-teas-attachment-circuit"/></t> </li> <li> <t>NNNN --> the assigned RFC number for <xref target="I-D.ietf-opsawg-ntw-attachment-circuit"/></t> </li> <li> <t>2025-01-07 --> 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 meanings of the symbols in the YANG tree diagrams are defined in <xref target="RFC8340"/>.</t> <t>This document uses terms defined in <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>.</t>target="RFC9834"/>.</t> <t>LxSM refers to both the L2SM and the L3SM.</t> <t>LxNM refers to both the L2NM and the L3NM.</t> <t>The following terms are used in themodulesmodule's prefixes:</t> <dl> <dt>ac:</dt> <dd> <t>Attachment circuit</t> </dd> <dt>ntw:</dt> <dd> <t>Network</t> </dd> <dt>ref:</dt> <dd> <t>Reference</t> </dd> <dt>svc:</dt> <dd> <t>Service</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-svc</td> <td align="left">ietf-ac-svc</td> <tdalign="left">Section 5.2 of RFC SSSS</td>align="left"><xref target="RFC9834" sectionFormat="of" section="5.2"/></td> </tr> <tr> <td align="left">ac-ntw</td> <td align="left">ietf-ac-ntw</td> <tdalign="left">RFC NNNN</td>align="left"><xref target="RFC9835"/></td> </tr> <tr> <td align="left">l2nm</td> <tdalign="left">ietf-l3vpn-ntw</td>align="left">ietf-l2vpn-ntw</td> <td align="left"> <xref target="RFC9291"/></td> </tr> <tr> <td align="left">l2vpn-svc</td> <td align="left">ietf-l2vpn-svc</td> <tdalign="left"> <xrefalign="left"><xref target="RFC8466"/></td> </tr> <tr> <td align="left">l3nm</td> <td align="left">ietf-l3vpn-ntw</td> <td align="left"> <xref target="RFC9182"/></td> </tr> <tr> <td align="left">l3vpn-svc</td> <td align="left">ietf-l3vpn-svc</td> <td align="left"> <xref target="RFC8299"/></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" (<xrefsection="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" (<xrefsection="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="I-D.ietf-opsawg-ntw-attachment-circuit"/>)</t><xref target="RFC9835"/></t> </li> <li> <t>"ietf-ac-glue" (<xref target="sec-glue"/>)</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 (L2VPN) or Layer 3 VPN (L3VPN) 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-data-models"> <name>Sample Uses of the 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 two target topology flavors that involve ACs. These topologies have the following characteristics:</t> <ul spacing="normal"> <li> <t>A Customer Edge (CE) can be either a physical device or a logical entity. Such logical entity is typically a software component (e.g., a virtual 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 Service Attachment Point (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 <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> <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> <t>These ACs can be referenced when creating VPN services. Refer to the examples provided in <xref target="sec-example"/> to illustrate how VPN services can be bound to ACs.</t> </section> <section anchor="sep"> <name>Separate AC ProvisioningFromfrom Actual VPN Service Provisioning</name> <t>The procedure to provision a service in a service provider network may depend on the practices adopted by a service provider. This includes the flow put in place for the provisioning of advanced network services and how they are bound to an attachment circuit. For example, a single attachment circuit may be used to host multiple connectivity services (e.g., Layer 2 VPN ("ietf-l2vpn-svc"), Layer 3 VPN ("ietf-l3vpn-svc"), Network Slice Service ("ietf-network-slice-service")). <!--[rfced] May we clarify that the modules in [RFC9834] would be used to manage ACs across the network? Original: In order to avoid service interference and redundant information in various locations, a service provider may expose an interface to manage ACs network-wide using [I-D.ietf-opsawg-teas-attachment-circuit]. Perhaps: In order to avoid service interference and redundant information in various locations, a service provider may expose an interface to manage ACs network-wide using the modules in [RFC9834]. --> In order to avoid service interference and redundant information in various locations, a service provider may expose an interface to manage ACs network-wide using <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>.target="RFC9834"/>. Customers can request for an attachment circuit ("ietf-ac-svc") to be put inplace,place and then refer to that AC when requesting VPN services that are bound to the AC ("ietf-ac-glue").</t> <t>Also, internal references ("ietf-ac-ntw") used within a service provider network to implement ACs can be used by network controllers to glue the L2NM ("ietf-l2vpn-ntw") or the L3NM ("ietf-l3vpn-ntw") services with relevant ACs.</t> <t><xref target="_u-ex"/> shows the positioning of the AC models in the overall service delivery process.</t> <!--[rfced] We note that Figure 3 uses "CE#1" and "CE#2", while other figures in the document use "CE1" and "CE2". May we update the CEs in Figure 3 to match the other figures in the document? If so, both artworks (svg and ascii-art) will be updated accordingly. --> <figure anchor="_u-ex"> <name>An Example of AC Models Usage</name> <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> </section> </section> <section anchor="module-tree-structure"> <name>Module Tree Structure</name> <t><xref target="RFC8299"/> specifies that a 'site-network-access' attachment is achieved through a 'bearer' with an 'ip-connection' on top. From that standpoint, a 'site-network-access' is mapped to an attachment circuit with bothLayersLayer 2 and 3 properties per <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>.target="RFC9834"/>. <xref target="RFC8466"/> specifies that a 'site-network-access' represents a logical Layer 2 connection to a site. A 'site-network-access' can thus be mapped to an attachment circuit with Layer 2 properties <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>.target="RFC9834"/>. Similarly, 'vpn-network-access' defined in both <xref target="RFC9182"/> and <xref target="RFC9291"/> is mapped to an attachment circuit per <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>target="RFC9834"/> or <xreftarget="I-D.ietf-opsawg-ntw-attachment-circuit"/>.</t>target="RFC9835"/>.</t> <t>As such, ACs created using the "ietf-ac-svc" module <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>target="RFC9834"/> can be referenced in other VPN-related modules (e.g., LxSM and LxNM). Also, ACs managed using the "ietf-ac-ntw" module <xreftarget="I-D.ietf-opsawg-ntw-attachment-circuit"/>target="RFC9835"/> can be referenced in VPN-related network modules (mainly, the LxNM). The required augmentations to that aim are shown in <xref target="tree"/>.</t> <figure anchor="tree"> <name>AC Glue Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-ac-glue augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site /l2vpn-svc:site-network-accesses: +--rw ac-svc-ref* ac-svc:attachment-circuit-reference augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site /l2vpn-svc:site-network-accesses /l2vpn-svc:site-network-access: +--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}? augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site /l3vpn-svc:site-network-accesses: +--rw ac-svc-ref* ac-svc:attachment-circuit-reference augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site /l3vpn-svc:site-network-accesses /l3vpn-svc:site-network-access: +--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}? augment /l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service /l2nm:vpn-nodes/l2nm:vpn-node/l2nm:vpn-network-accesses: +--rw ac-svc-ref* ac-svc:attachment-circuit-reference +--rw ac-ntw-ref* [ac-ref] +--rw ac-ref leafref +--rw node-ref? leafref +--rw network-ref? -> /nw:networks/network/network-id augment /l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service /l2nm:vpn-nodes/l2nm:vpn-node/l2nm:vpn-network-accesses /l2nm:vpn-network-access: +--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}? +--rw ac-ntw-ref {ac-glue}? +--rw ac-ref? leafref +--rw node-ref? leafref +--rw network-ref? -> /nw:networks/network/network-id augment /l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service /l3nm:vpn-nodes/l3nm:vpn-node/l3nm:vpn-network-accesses: +--rw ac-svc-ref* ac-svc:attachment-circuit-reference +--rw ac-ntw-ref* [ac-ref] +--rw ac-ref leafref +--rw node-ref? leafref +--rw network-ref? -> /nw:networks/network/network-id augment /l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service /l3nm:vpn-nodes/l3nm:vpn-node/l3nm:vpn-network-accesses /l3nm:vpn-network-access: +--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}? +--rw ac-ntw-ref {ac-glue}? +--rw ac-ref? leafref +--rw node-ref? leafref +--rw network-ref? -> /nw:networks/network/network-id]]></artwork>]]></sourcecode> </figure> <!-- [rfced] We have a couple questions about this paragraph: Original: This approach is consistent with the design in [I-D.ietf-teas-ietf-network-slice-nbi-yang] where an AC service reference, called 'ac-svc-name', is used to indicate the names of AC services. As per [I-D.ietf-teas-ietf-network-slice-nbi-yang], when both 'ac-svc-name' and the attributes of 'attachment- circuits' are defined, the 'ac-svc-name' takes precedence. a) [I-D.ietf-teas-ietf-network-slice-nbi-yang] does not appear to contain the term "ac-svc-name". It does contain the term "ac-svc-ref". Should "ac-svc-name" be updated to "ac-svc-ref"? b) Additionally, we note that this text was indented. As it is unclear to us why it was indented, we have removed the indentation. Was the intent for this to be a "Note"? If yes, this text can be used in the <aside> element, which is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). Perhaps: | This approach is consistent with the design in | [I-D.ietf-teas-ietf-network-slice-nbi-yang] where an AC service | reference, called 'ac-svc-ref', is used to indicate the names of | AC services. As per [I-D.ietf-teas-ietf-network-slice-nbi-yang], | when both 'ac-svc-ref' and the attributes of 'attachment- | circuits' are defined, the 'ac-svc-ref' takes precedence. --> <t>When an AC is referenced within a specific network access,thenthat AC information takes precedence over any overlapping information that is also enclosed for this network access.</t><ul empty="true"> <li><t>This approach is consistent with the design in <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/> where an AC service reference, called 'ac-svc-name', is used to indicate the names of AC services. As per <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/>, when both 'ac-svc-name' and the attributes of 'attachment-circuits' are defined, the 'ac-svc-name' takes precedence.</t></li> </ul><t>The "ietf-ac-glue" module includes provisions to reference ACs within or outside a VPN network access to accommodate deployment contexts where an AC reference may be created before or after a VPN instance is created. <xref target="ref-within-access"/> illustrates how an AC reference can be included as part of a specific VPN network access, while <xref target="ref-outside-access"/> shows how AC references can be indicated outside individual VPN network access entries.</t> </section> <section anchor="sec-glue"> <name>The AC Glue ("ietf-ac-glue") YANG Module</name> <t>This modules augments the L2SM <xref target="RFC8466"/>, the L3SM <xref target="RFC8299"/>, the L2NM <xref target="RFC9291"/>, and the L3NM <xref target="RFC9182"/>.</t> <t>This module uses references defined in <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>target="RFC9834"/> and <xreftarget="I-D.ietf-opsawg-ntw-attachment-circuit"/>.</t>target="RFC9835"/>.</t> <sourcecodetype="yang"><![CDATA[ <CODE BEGINS> file "ietf-ac-glue@2025-01-07.yang"type="yang" name="ietf-ac-glue@2025-08-11.yang" markers="true"><![CDATA[ module ietf-ac-glue { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ac-glue"; prefix ac-glue; import ietf-l3vpn-svc { prefix l3vpn-svc; reference "RFC 8299: YANG Data Model for L3VPN Service Delivery"; } import ietf-l2vpn-svc { prefix l2vpn-svc; reference "RFC 8466: A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery"; } import ietf-l3vpn-ntw { prefix l3nm; reference "RFC 9182: A YANG Network Data Model for Layer 3 VPNs"; } import ietf-l2vpn-ntw { prefix l2nm; reference "RFC 9291: A YANG Network Data Model for Layer 2 VPNs"; } import ietf-ac-svc { prefix ac-svc; reference "RFCSSSS:9834: YANG Data Models for Bearers and'Attachment Circuits'-as-a-ServiceAttachment Circuits-as-a-Service (ACaaS)"; } import ietf-ac-ntw { prefix ac-ntw; reference "RFCNNNN:9835: A Network YANG Data Model for Attachment Circuits"; } 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: Samier Barguil <mailto:ssamier.barguil_giraldo@nokia.com> Author: Oscar Gonzalez de Dios <mailto:oscar.gonzalezdedios@telefonica.com>"; description "This YANG module defines a YANG data model for augmenting the LxSM and the LxNM with attachment circuit references. 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 RFCXXXX;9836; see the RFC itself for full legal notices."; revision2025-01-072025-08-11 { description "Initial revision."; reference "RFCXXXX:9836: A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits"; } feature ac-glue { description "The VPN implementation supports binding a specific VPN network access or site access to an attachment circuit."; } grouping single-ac-svc-ref { description "A grouping with a single reference to a service AC."; leaf ac-svc-ref { type ac-svc:attachment-circuit-reference; description "A reference to the AC as exposed at the service that was provisioned using the ACaaS module."; } } grouping single-ac-svc-ntw-ref { description "A grouping with single AC references."; leaf ac-svc-ref { type ac-svc:attachment-circuit-reference; description "A reference to the AC as exposed at the service that was provisioned using the ACaaS module."; } container ac-ntw-ref { description "A reference to the AC that was provisioned using the AC network module."; uses ac-ntw:attachment-circuit-reference; } } grouping ac-svc-ref { description "A set of service-specific AC-related data."; leaf-list ac-svc-ref { type ac-svc:attachment-circuit-reference; description "A reference to the AC as exposed at the service that was provisioned using the ACaaS module."; } } grouping ac-svc-ntw-ref { description "A set of AC-related data."; leaf-list ac-svc-ref { type ac-svc:attachment-circuit-reference; description "A reference to the AC as exposed at the service that was provisioned using the ACaaS module."; } list ac-ntw-ref { key "ac-ref"; description "A reference to the AC that was provisioned using the AC network module."; uses ac-ntw:attachment-circuit-reference; } } augment "/l2vpn-svc:l2vpn-svc" + "/l2vpn-svc:sites/l2vpn-svc:site" + "/l2vpn-svc:site-network-accesses" { description "Augments VPN site network accesses with AC provisioning details. Concretely, it binds a site to a set of attachment circuits with Layer 2 properties that were created using the ACaaS module."; uses ac-svc-ref; } augment "/l2vpn-svc:l2vpn-svc" + "/l2vpn-svc:sites/l2vpn-svc:site" + "/l2vpn-svc:site-network-accesses" + "/l2vpn-svc:site-network-access" { if-feature "ac-glue"; description "Augments VPN site network access with AC provisioning details. Concretely, it glues a 'site-network-access' to an attachment circuit with Layer 2 properties that was created using the ACaaS module. The ACaaS information takes precedence over any overlapping information that is also provided for a site network access."; uses single-ac-svc-ref; } augment "/l3vpn-svc:l3vpn-svc" + "/l3vpn-svc:sites/l3vpn-svc:site" + "/l3vpn-svc:site-network-accesses" { description "Augments VPN site network accesses with AC provisioning details. Concretely, it binds a site to a set of attachment circuits with bothLayersLayer 2 and Layer 3 properties that were created using the ACaaS module."; uses ac-svc-ref; } augment "/l3vpn-svc:l3vpn-svc" + "/l3vpn-svc:sites/l3vpn-svc:site" + "/l3vpn-svc:site-network-accesses" + "/l3vpn-svc:site-network-access" { if-feature "ac-glue"; description "Augments VPN site network access with AC provisioning details. Concretely, it glues a 'site-network-access' to an attachment circuit with both Layer 2 and Layer 3 properties that was created using the ACaaS module. The ACaaS information takes precedence over any overlapping information that is also provided for a site network access."; uses single-ac-svc-ref; } augment "/l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service" + "/l2nm:vpn-nodes/l2nm:vpn-node" + "/l2nm:vpn-network-accesses" { description "Augments VPN network accesses with both service and network AC provisioning details. Concretely, it binds a site to (1) a set of attachment circuits with Layer 2 properties that were created using the ACaaS module and (2) a set of attachment circuits with Layer 2 properties that were provisioned using the AC network model."; uses ac-svc-ntw-ref; } augment "/l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service" + "/l2nm:vpn-nodes/l2nm:vpn-node" + "/l2nm:vpn-network-accesses" + "/l2nm:vpn-network-access" { if-feature "ac-glue"; description "Augments VPN network access with service and network references to an AC. Concretely, it glues a VPN network access to (1) an attachment circuit with Layer 2 properties that was created using the ACaaS module and (2) an attachment circuit with Layer 2 properties that was created using the AC network module. The AC service and network information takes precedence over any overlapping information that is also provided for a VPN network access."; uses single-ac-svc-ntw-ref; } augment "/l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service" + "/l3nm:vpn-nodes/l3nm:vpn-node" + "/l3nm:vpn-network-accesses" { description "Augments VPN network accesses with both service and network AC provisioning details. Concretely, it binds a site to (1) a set of attachment circuits with both Layer 2 and Layer 3 properties that were created using the ACaaS module and (2) a set of attachment circuits with both Layer 2 and Layer 3 properties that were provisioned using the AC network model."; uses ac-svc-ntw-ref; } augment "/l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service" + "/l3nm:vpn-nodes/l3nm:vpn-node" + "/l3nm:vpn-network-accesses" + "/l3nm:vpn-network-access" { if-feature "ac-glue"; description "Augments VPN network access with service and network references to an AC. Concretely, it glues a VPN network access to (1) an attachment circuit with both Layer 2 and Layer 3 properties that was created using the ACaaS module and (2) an attachment circuit with both Layer 2 and Layer 3 properties that was created using the AC network module. The AC service and network information takes precedence over any overlapping information that is also provided for a VPN network access."; uses single-ac-svc-ntw-ref; } }<CODE ENDS>]]></sourcecode> </section> <section anchor="security-considerations"> <name>Security Considerations</name><t>This<!-- DNE begins --><t>This section is modeled after the template described in <xref section="3.7" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t> <t>The "ietf-ac-common" 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).TheseAll writable data nodesmayare likely to beconsideredreasonably 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, theThe following subtrees and data nodes have particularsensitivities/vulnerabilities:</t> <dl>sensitivities/vulnerabilities:</t><!-- DNE ends --> <dl spacing="normal" newline="false"> <dt>'ac-svc-ref' and 'ac-ntw-ref':</dt><dd> <t>An<dd>An attacker who is able to access network nodes can undertake various attacks, such as deleting a running VPN service, interrupting all the traffic of a client. Specifically, an attacker may modify (including delete) the ACs that are bound to a running service, leading to malfunctioning of the service and therefore to Service Level Agreement (SLA) violations.:Such activity can be detected by adequately monitoring and tracking network configurationchanges.</t>changes. </dd> </dl><t>Some<!-- 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 particularsensitivities/vulnerabilities:</t> <dl>sensitivities/vulnerabilities:</t><!-- DNE ends --> <dl spacing="normal" newline="false"> <dt>'ac-svc-ref' and 'ac-ntw-ref':</dt><dd> <t>These<dd><t>These references do not exposeper seprivacy-relatedinformation, howeverinformation per se; however, 'ac-svc-ref' may be used to track the set of VPN instances in which a given customer is involved.</t></dd> <dt/> <dd><t>Note that, unlike 'ac-svc-ref', 'ac-ntw-ref' is unique within the scope of a node and may multiplex many peer CEs.</t> </dd> </dl> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>IANAis requested to registerhas 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-glue Registrant Contact: The IESG. XML: N/A;<dl spacing="compact" newline="false"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-glue</dd> <dt>Registrant Contact:</dt><dd>The IESG.</dd> <dt>XML:</dt><dd>N/A; the requested URI is an XMLnamespace. ]]></artwork>namespace.</dd> </dl> <t>IANAis requested to registerhas registered the following YANG module in the "YANG Module Names" registry <xref target="RFC6020"/> within the "YANG Parameters" registry group:</t><artwork><![CDATA[ Name: ietf-ac-glue Namespace: urn:ietf:params:xml:ns:yang:ietf-ac-glue Prefix: ac-glue Maintained<dl spacing="compact" newline="false"> <dt>Name:</dt><dd>ietf-ac-glue</dd> <dt>Maintained byIANA? N Reference: RFC XXXX ]]></artwork>IANA?</dt><dd>N</dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-glue</dd> <dt>Prefix:</dt><dd>ac-glue</dd> <dt>Reference:</dt><dd>RFC 9836</dd> </dl> </section> </middle> <back> <displayreference target="I-D.ietf-netmod-rfc8407bis" to="YANG-GUIDELINES"/> <displayreference target="I-D.ietf-teas-ietf-network-slice-nbi-yang" to="YANG-NSS"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> <!-- [RFC9834] in EDIT as of 03/03/25. --> <referenceanchor="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-ServiceAttachment 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 deDios" initials="O. G." surname="deDios"> <organization>Telefonica</organization> </author> <authorfullname="Samier Barguil"initials="S."surname="Barguil">surname="Barguil" fullname="Samier Barguil"> <organization>Nokia</organization> </author> <authorfullname="Bo Wu"initials="B."surname="Wu">surname="Wu" fullname="Bo Wu"> <organization>Huawei Technologies</organization> </author> <dateday="9" 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-19"/> </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>month='August' year='2025'/> </front> <seriesInfo name="RFC"value="8466"/>value="9834"/> <seriesInfo name="DOI"value="10.17487/RFC8466"/>value="10.17487/RFC9834"/> </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<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.9291.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9182.xml"/> <!-- [RFC9835] inRFCs 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 modelEDIT asinput 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="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 viewofL3VPN 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>03/03/25. --> <referenceanchor="I-D.ietf-opsawg-ntw-attachment-circuit">anchor="RFC9835" target="https://www.rfc-editor.org/info/rfc9835"> <front> <title>A Network 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> <authorfullname="Richard Roberts"initials="R."surname="Roberts">surname="Roberts" fullname="Richard Roberts"> <organization>Juniper</organization> </author> <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez deDios" initials="O. G." surname="deDios"> <organization>Telefonica</organization> </author> <authorfullname="Samier Barguil"initials="S."surname="Barguil">surname="Barguil" fullname="Samier Barguil"> <organization>Nokia</organization> </author> <authorfullname="Bo Wu"initials="B."surname="Wu">surname="Wu" fullname="Bo Wu"> <organization>Huawei Technologies</organization> </author> <dateday="9" month="January" year="2025"/> <abstract> <t> This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit). 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> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ntw-attachment-circuit-15"/> </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="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="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>month='August' year='2025'/> </front> <seriesInfoname="BCP" value="81"/> <seriesInfoname="RFC"value="3688"/>value="9835"/> <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/RFC9835"/> </reference> <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.8341.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="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<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <!-- [RFC9833] draft-ietf-opsawg-teas-common-ac-15 IESG State: RFC Ed Queue as ofthe YANG language.</t> </abstract> </front> <seriesInfo name="BCP" value="215"/> <seriesInfo name="RFC" value="8340"/> <seriesInfo name="DOI" value="10.17487/RFC8340"/> </reference>03/03/25. --> <referenceanchor="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 deDios" initials="O. G." surname="deDios"> <organization>Telefonica</organization> </author> <authorfullname="Samier Barguil"initials="S."surname="Barguil">surname="Barguil" fullname="Samier Barguil"> <organization>Nokia</organization> </author> <authorfullname="Bo Wu"initials="B."surname="Wu">surname="Wu" fullname="Bo Wu"> <organization>Huawei Technologies</organization> </author> <dateday="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="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 RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, such 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>month="August" year="2025" /> </front> <seriesInfo name="RFC"value="9408"/>value="9833"/> <seriesInfo name="DOI"value="10.17487/RFC9408"/>value="10.17487/RFC9833"/> </reference><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<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9408.xml"/> <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.4364.xml"/> <!-- [I-D.ietf-teas-ietf-network-slice-nbi-yang] draft-ietf-teas-ietf-network-slice-nbi-yang-22 IESG State: IESG Evaluation as ofcomposite services through deployment03/03/25. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-teas-ietf-network-slice-nbi-yang.xml"/> <!-- [I-D.ietf-netmod-rfc8407bis] draft-ietf-netmod-rfc8407bis-22 IESG State: IESG State: Publication Requested as ofSFCs, 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="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="I-D.ietf-teas-ietf-network-slice-nbi-yang"> <front> <title>A YANG Data Model for the RFC 9543 Network Slice Service</title> <author fullname="Bo Wu" initials="B." surname="Wu"> <organization>Huawei Technologies</organization> </author> <author fullname="Dhruv Dhody" initials="D." surname="Dhody"> <organization>Huawei Technologies</organization> </author> <author fullname="Reza Rokui" initials="R." surname="Rokui"> <organization>Ciena</organization> </author> <author fullname="Tarek Saad" initials="T." surname="Saad"> <organization>Cisco Systems, Inc</organization> </author> <author fullname="John Mullooly" initials="J." surname="Mullooly"> <organization>Cisco Systems, Inc</organization> </author> <date day="21" month="January" year="2025"/> <abstract> <t> This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network-slice-nbi-yang-18"/> </reference>03/03/25. --> <referenceanchor="I-D.ietf-netmod-rfc8407bis">anchor="I-D.ietf-netmod-rfc8407bis" target="https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-22"> <front> <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title> <authorfullname="Andy Bierman"initials="A."surname="Bierman">surname="Bierman" fullname="Andy Bierman"> <organization>YumaWorks</organization> </author> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair"initials="M." surname="Boucadair">role="editor"> <organization>Orange</organization> </author> <authorfullname="Qin Wu"initials="Q."surname="Wu">surname="Wu" fullname="Qin Wu"> <organization>Huawei</organization> </author> <dateday="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>day="14" year="2025" /> </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> </front> <seriesInfo name="RFC" value="9000"/> <seriesInfo name="DOI" value="10.17487/RFC9000"/> </reference> <reference anchor="RFC4664"> <front> <title>Framework for Layer 2 Virtual Private Networks (L2VPNs)</title> <author fullname="L. Andersson" initials="L." role="editor" surname="Andersson"/> <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/> <date month="September" year="2006"/> <abstract> <t>This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="4664"/> <seriesInfo name="DOI" value="10.17487/RFC4664"/>value="draft-ietf-netmod-rfc8407bis-22" /> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4664.xml"/> </references> </references><?line 675?><section anchor="sec-example"> <name>Examples</name> <section anchor="ref-within-access"> <name>A Service AC Referencewithin TheWithin the VPN Network Access</name> <t>Let us consider the example depicted in <xreftarget="ex-vpws"/>target="ex-vpws"/>, which is inspired from <xref section="2.1" sectionFormat="of" target="RFC4664"/>. Each PE is servicing two CEs. Let us also assume that the service references to identify attachment circuits with these CEs are shown inthe figure.</t><xref target="ex-vpws"/>.</t> <figure anchor="ex-vpws"> <name>VPWS Topology Example</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="240" width="464" viewBox="0 0 464 240" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,48 L 8,96" fill="none" stroke="black"/> <path d="M 8,176 L 8,224" fill="none" stroke="black"/> <path d="M 56,32 L 56,80" fill="none" stroke="black"/> <path d="M 56,160 L 56,208" fill="none" stroke="black"/> <path d="M 80,64 L 80,96" fill="none" stroke="black"/> <path d="M 80,160 L 80,192" fill="none" stroke="black"/> <path d="M 120,80 L 120,176" fill="none" stroke="black"/> <path d="M 168,80 L 168,104" fill="none" stroke="black"/> <path d="M 168,120 L 168,176" fill="none" stroke="black"/> <path d="M 200,80 L 200,176" fill="none" stroke="black"/> <path d="M 248,80 L 248,176" fill="none" stroke="black"/> <path d="M 296,80 L 296,176" fill="none" stroke="black"/> <path d="M 344,80 L 344,176" fill="none" stroke="black"/> <path d="M 384,64 L 384,96" fill="none" stroke="black"/> <path d="M 384,160 L 384,192" fill="none" stroke="black"/> <path d="M 408,48 L 408,96" fill="none" stroke="black"/> <path d="M 408,176 L 408,224" fill="none" stroke="black"/> <path d="M 456,32 L 456,80" fill="none" stroke="black"/> <path d="M 456,160 L 456,208" fill="none" stroke="black"/> <path d="M 24,32 L 56,32" fill="none" stroke="black"/> <path d="M 424,32 L 456,32" fill="none" stroke="black"/> <path d="M 64,64 L 80,64" fill="none" stroke="black"/> <path d="M 384,64 L 400,64" fill="none" stroke="black"/> <path d="M 120,80 L 168,80" fill="none" stroke="black"/> <path d="M 200,80 L 248,80" fill="none" stroke="black"/> <path d="M 296,80 L 344,80" fill="none" stroke="black"/> <path d="M 8,96 L 40,96" fill="none" stroke="black"/> <path d="M 80,96 L 112,96" fill="none" stroke="black"/> <path d="M 128,96 L 152,96" fill="none" stroke="black"/> <path d="M 312,96 L 384,96" fill="none" stroke="black"/> <path d="M 408,96 L 440,96" fill="none" stroke="black"/> <path d="M 168,112 L 192,112" fill="none" stroke="black"/> <path d="M 208,112 L 240,112" fill="none" stroke="black"/> <path d="M 256,112 L 288,112" fill="none" stroke="black"/> <path d="M 176,126 L 192,126" fill="none" stroke="black"/> <path d="M 176,130 L 192,130" fill="none" stroke="black"/> <path d="M 208,126 L 240,126" fill="none" stroke="black"/> <path d="M 208,130 L 240,130" fill="none" stroke="black"/> <path d="M 256,126 L 288,126" fill="none" stroke="black"/> <path d="M 256,130 L 288,130" fill="none" stroke="black"/> <path d="M 176,144 L 192,144" fill="none" stroke="black"/> <path d="M 208,144 L 240,144" fill="none" stroke="black"/> <path d="M 256,144 L 288,144" fill="none" stroke="black"/> <path d="M 24,160 L 56,160" fill="none" stroke="black"/> <path d="M 80,160 L 112,160" fill="none" stroke="black"/> <path d="M 128,160 L 152,160" fill="none" stroke="black"/> <path d="M 312,160 L 336,160" fill="none" stroke="black"/> <path d="M 352,160 L 384,160" fill="none" stroke="black"/> <path d="M 424,160 L 456,160" fill="none" stroke="black"/> <path d="M 120,176 L 168,176" fill="none" stroke="black"/> <path d="M 200,176 L 248,176" fill="none" stroke="black"/> <path d="M 296,176 L 344,176" fill="none" stroke="black"/> <path d="M 64,192 L 80,192" fill="none" stroke="black"/> <path d="M 384,192 L 400,192" fill="none" stroke="black"/> <path d="M 8,224 L 40,224" fill="none" stroke="black"/> <path d="M 408,224 L 440,224" fill="none" stroke="black"/> <path d="M 24,32 C 15.16936,32 8,39.16936 8,48" fill="none" stroke="black"/> <path d="M 424,32 C 415.16936,32 408,39.16936 408,48" fill="none" stroke="black"/> <path d="M 40,96 C 48.83064,96 56,88.83064 56,80" fill="none" stroke="black"/> <path d="M 440,96 C 448.83064,96 456,88.83064 456,80" fill="none" stroke="black"/> <path d="M 24,160 C 15.16936,160 8,167.16936 8,176" fill="none" stroke="black"/> <path d="M 424,160 C 415.16936,160 408,167.16936 408,176" fill="none" stroke="black"/> <path d="M 40,224 C 48.83064,224 56,216.83064 56,208" fill="none" stroke="black"/> <path d="M 440,224 C 448.83064,224 456,216.83064 456,208" fill="none" stroke="black"/> <g class="text"> <text x="88" y="52">AC1</text> <text x="368" y="52">AC2</text> <text x="32" y="68">CE1</text> <text x="152" y="68">2001:db8:100::1</text> <text x="312" y="68">2001:db8:200::1</text> <text x="432" y="68">CE2</text> <text x="224" y="100">P</text> <text x="144" y="116">VPWS\</text> <text x="320" y="116">/VPWS</text> <text x="144" y="132">PE1</text> <text x="320" y="132">PE2</text> <text x="160" y="148">/</text> <text x="308" y="148">\\</text> <text x="32" y="196">CE3</text> <text x="432" y="196">CE4</text> <text x="88" y="212">AC3</text> <text x="376" y="212">AC4</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .----. .----. | | AC1 AC2 | | | CE1 |--+ 2001:db8:100::1 2001:db8:200::1 +--| CE2 | | | | .-----. .-----. .-----. | | | '----' +----|---- | | P | | ----+----+ '----' |VPWS\----|-----|-----|/VPWS| | PE1 |===|=====|=====| PE2 | | /|---|-----|-----|\\ | .----. +----|---- | | | | ----|----+ .----. | | | '-----' '-----' '-----' | | | | CE3 |--+ +--| CE4 | | | AC3 AC4 | | '----' '----' ]]></artwork> </artset> </figure> <t>As shown in <xref target="ex-vpws-query"/>, the service AC references can be explicitly indicated in the L2NM query for the realization of the Virtual Private Wire Service (VPWS) (<xref section="3.1.1" sectionFormat="of" target="RFC4664"/>).</t> <figure anchor="ex-vpws-query"> <name>Example of VPWS Creation with AC Service References</name> <sourcecode type="json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-l2vpn-ntw:l2vpn-ntw":{ "vpn-services":{ "vpn-service":[ { "vpn-id":"vpws12345", "vpn-description":"Sample VPWS with AC service \ references", "customer-name":"customer-12345", "vpn-type":"ietf-vpn-common:vpws", "bgp-ad-enabled":true, "signaling-type":"ietf-vpn-common:ldp-signaling", "global-parameters-profiles":{ "global-parameters-profile":[ { "profile-id":"simple-profile", "local-autonomous-system":65550, "rd-auto":{ "auto":[ null ] }, "vpn-target":[ { "id":1, "route-targets":[ { "route-target":"0:65535:1" } ], "route-target-type":"both" } ] } ] }, "vpn-nodes":{ "vpn-node":[ { "vpn-node-id":"pe1", "ne-id":"2001:db8:100::1", "active-global-parameters-profiles":{ "global-parameters-profile":[ { "profile-id":"simple-profile" } ] }, "bgp-auto-discovery":{ "vpn-id":"587" }, "signaling-option":{ "advertise-mtu":true, "ldp-or-l2tp":{ "saii":1, "remote-targets":[ { "taii":2 } ], "t-ldp-pw-type":"ethernet" } }, "vpn-network-accesses":{ "vpn-network-access":[ { "id":"1/1/1.1", "interface-id":"1/1/1", "description":"Interface to CE1", "active-vpn-node-profile":"simple-\ profile", "status":{ "admin-status":{ "status":"ietf-vpn-common:\ admin-up" }, "ietf-ac-glue:ac-svc-ref":"AC1" } }, { "id":"1/1/3.1", "interface-id":"1/1/3", "description":"Interface to CE3", "active-vpn-node-profile":"simple-\ profile", "status":{ "admin-status":{ "status":"ietf-vpn-common:\ admin-up" }, "ietf-ac-glue:ac-svc-ref":"AC3" } } ] } }, { "vpn-node-id":"pe2", "ne-id":"2001:db8:200::1", "active-global-parameters-profiles":{ "global-parameters-profile":[ { "profile-id":"simple-profile" } ] }, "bgp-auto-discovery":{ "vpn-id":"587" }, "signaling-option":{ "advertise-mtu":true, "ldp-or-l2tp":{ "saii":2, "remote-targets":[ { "taii":1 } ], "t-ldp-pw-type":"ethernet" } }, "vpn-network-accesses":{ "vpn-network-access":[ { "id":"2/1/2.1", "interface-id":"2/1/2", "description":"Interface to CE2", "active-vpn-node-profile":"simple-\ profile", "status":{ "admin-status":{ "status":"ietf-vpn-common:\ admin-up" }, "ietf-ac-glue:ac-svc-ref":"AC2" } }, { "id":"2/1/4.1", "interface-id":"2/1/4", "description":"Interface to CE4", "active-vpn-node-profile":"simple-\ profile", "status":{ "admin-status":{ "status":"ietf-vpn-common:\ admin-up" }, "ietf-ac-glue:ac-svc-ref":"AC4" } } ] } } ] } } ] } } } ]]></sourcecode> </figure> </section> <section anchor="ref-outside-access"> <name>Network and Service AC References</name> <t>Let us consider the example depicted in <xref target="ex-topo"/> with two customer termination points (CE1 and CE2). Let us also assume that the bearers to attach these CEs to the service provider network are already in place. References to identify these bearers are shown inthe figure.</t><xref target="ex-topo"/>.</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 <xreftarget="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> <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" } } ] } } ]]></sourcecode> </figure> <t>Let us now consider that the customer wants to request aVPLSVirtual Private LAN Service (VPLS) instance between the sites as shown in <xref target="ex-vpls"/>.</t> <figure anchor="ex-vpls"> <name>Example of VPLS</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="160" width="488" viewBox="0 0 488 160" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,96 L 8,112" fill="none" stroke="black"/> <path d="M 48,80 L 48,96" fill="none" stroke="black"/> <path d="M 80,104 L 80,128" fill="none" stroke="black"/> <path d="M 104,64 L 104,112" fill="none" stroke="black"/> <path d="M 152,64 L 152,112" fill="none" stroke="black"/> <path d="M 184,64 L 184,144" fill="none" stroke="black"/> <path d="M 304,64 L 304,144" fill="none" stroke="black"/> <path d="M 336,64 L 336,112" fill="none" stroke="black"/> <path d="M 384,64 L 384,112" fill="none" stroke="black"/> <path d="M 416,104 L 416,128" fill="none" stroke="black"/> <path d="M 440,96 L 440,112" fill="none" stroke="black"/> <path d="M 480,80 L 480,96" fill="none" stroke="black"/> <path d="M 112,32 L 184,32" fill="none" stroke="black"/> <path d="M 304,32 L 376,32" fill="none" stroke="black"/> <path d="M 104,64 L 152,64" fill="none" stroke="black"/> <path d="M 184,64 L 304,64" fill="none" stroke="black"/> <path d="M 336,64 L 384,64" fill="none" stroke="black"/> <path d="M 24,80 L 48,80" fill="none" stroke="black"/> <path d="M 152,78 L 184,78" fill="none" stroke="black"/> <path d="M 152,82 L 184,82" fill="none" stroke="black"/> <path d="M 304,78 L 336,78" fill="none" stroke="black"/> <path d="M 304,82 L 336,82" fill="none" stroke="black"/> <path d="M 456,80 L 480,80" fill="none" stroke="black"/> <path d="M 48,96 L 104,96" fill="none" stroke="black"/> <path d="M 384,96 L 440,96" fill="none" stroke="black"/> <path d="M 8,112 L 32,112" fill="none" stroke="black"/> <path d="M 104,112 L 152,112" fill="none" stroke="black"/> <path d="M 336,112 L 384,112" fill="none" stroke="black"/> <path d="M 440,112 L 464,112" fill="none" stroke="black"/> <path d="M 184,144 L 304,144" fill="none" stroke="black"/> <path d="M 24,80 C 15.16936,80 8,87.16936 8,96" fill="none" stroke="black"/> <path d="M 456,80 C 447.16936,80 440,87.16936 440,96" fill="none" stroke="black"/> <path d="M 32,112 C 40.83064,112 48,104.83064 48,96" fill="none" stroke="black"/> <path d="M 464,112 C 472.83064,112 480,104.83064 480,96" fill="none" stroke="black"/> <polygon class="arrowhead" points="424,104 412,98.4 412,109.6" fill="black" transform="rotate(270,416,104)"/> <polygon class="arrowhead" points="88,104 76,98.4 76,109.6" fill="black" transform="rotate(270,80,104)"/> <g class="text"> <text x="104" y="36">|</text> <text x="220" y="36">VPLS</text> <text x="268" y="36">"1543"</text> <text x="384" y="36">|</text> <text x="80" y="84">AC1</text> <text x="128" y="84">PE1</text> <text x="360" y="84">PE2</text> <text x="416" y="84">AC2</text> <text x="32" y="100">CE1</text> <text x="128" y="100">"450"</text> <text x="244" y="100">MPLS</text> <text x="360" y="100">"451"</text> <text x="464" y="100">CE2</text> <text x="244" y="132">Core</text> <text x="80" y="148">Bearer:1234</text> <text x="424" y="148">Bearer:5678</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ |---------- VPLS "1543" ----------| .-----. .--------------. .-----. .---. AC1 | PE1 +===+ +===+ PE2 | AC2 .---. | CE1+------+"450"| | MPLS | |"451"+------+ CE2| '---' ^ '-----' | | '-----' ^ '---' | | Core | | Bearer:1234 '--------------' Bearer:5678 ]]></artwork> </artset> </figure> <t>To that aim, existing ACs are referenced during the creation of the VPLS instance using the L2NM <xref target="RFC9291"/> and the "ietf-ac-glue" module as shown in <xref target="ex-vpls-req"/>.</t> <figure anchor="ex-vpls-req"> <name>Example of a VPLS Request Using L2NM and AC Glue (Message Body)</name> <sourcecode type="json"><![CDATA[ { "ietf-l2vpn-ntw:l2vpn-ntw": { "vpn-services": { "vpn-service": [ { "vpn-id": "1543", "vpn-name": "CORPO-EXAMPLE", "customer-name": "EXAMPLE", "vpn-type": "ietf-vpn-common:vpls", "vpn-service-topology": "ietf-vpn-common:hub-spoke", "bgp-ad-enabled": false, "signaling-type": "ietf-vpn-common:ldp-signaling", "global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile", "ce-vlan-preservation": true, "ce-vlan-cos-preservation": true } ] }, "vpn-nodes": { "vpn-node": [ { "vpn-node-id": "450", "ne-id": "2001:db8:5::1", "role": "ietf-vpn-common:hub-role", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "signaling-option": { "ldp-or-l2tp": { "t-ldp-pw-type": "vpls-type", "pw-peer-list": [ { "peer-addr": "2001:db8:50::1", "vc-id": "1543" } ] } }, "vpn-network-accesses": { "ietf-ac-glue:ac-svc-ref": ["ac-1"] } }, { "vpn-node-id": "451", "ne-id": "2001:db8:50::1", "role": "ietf-vpn-common:spoke-role", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "signaling-option": { "ldp-or-l2tp": { "t-ldp-pw-type": "vpls-type", "pw-peer-list": [ { "peer-addr": "2001:db8:5::1", "vc-id": "1543" } ] } }, "vpn-network-accesses": { "ietf-ac-glue:ac-svc-ref": ["ac-2"] } } ] } } ] } } } ]]></sourcecode> </figure> <t>Note that before implementing the VPLS instance creation request, the provider service orchestrator may first check if the VPLS service can be provided to the customer using the target delivery locations. The orchestrator uses the SAP model <xref target="RFC9408"/> as exemplified in <xref target="ex-sap-query"/>. This example assumes that the query concerns only PE1. A similar query can be issued for PE2.</t> <figure anchor="ex-sap-query"> <name>Example of SAP Response (Message Body)</name> <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" } } ] } ] } ]]></sourcecode> </figure> <t>The response in <xref target="ex-sap-query"/> indicates that the VPLS service can be delivered to CE1. <!--[rfced] May we clarify that the "ietf-ac-ntw" module in [RFC9835] is used? Original: [I-D.ietf-opsawg-ntw-attachment-circuit] can be also used to access AC-related details that are bound to the target SAP (Figure 12). Perhaps: The "ietf-ac-ntw" module [RFC9835] can be also used to access AC-related details that are bound to the target SAP (Figure 12). --> <xreftarget="I-D.ietf-opsawg-ntw-attachment-circuit"/>target="RFC9835"/> can be also used to access AC-related details that are bound to the target SAP (<xref target="ex-acntw-query-2"/>).</t> <figure anchor="ex-acntw-query-2"> <name>Example of AC Network Response with SAP (Message Body)</name> <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" } ] } ] } ] } ]]></sourcecode> </figure> <t>The provisioned AC at PE1 can be retrieved using the AC network model <xreftarget="I-D.ietf-opsawg-ntw-attachment-circuit"/>target="RFC9835"/> as depicted in <xref target="ex-acntw-query"/>.</t> <figure anchor="ex-acntw-query"> <name>Example of AC Network Response (Message Body)</name> <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" } ] } } } } ] } ]]></sourcecode> </figure> </section> </section> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>Thanks toBo Wu<contact fullname="Bo Wu"/> andQin Wu<contact fullname="Qin Wu"/> for the review and comments.</t> <t>Thanks toMartin Björklund<contact fullname="Martin Björklund"/> for theyangdoctorsYANG Doctors review,Gyan Mishra<contact fullname="Gyan Mishra"/> for thertg-dirRTGDIR review,Ron Bonica<contact fullname="Ron Bonica"/> for theopsdirOPSDIR review,Reese Enghardt<contact fullname="Reese Enghardt"/> for thegenartGENART review, andPrachi Jain<contact fullname="Prachi Jain"/> for thesec-dirSECDIR review.</t> <t>Thanks toMahesh Jethanandani<contact fullname="Mahesh Jethanandani"/> for the AD review.</t> <t>Thanks toGunter<contact fullname="Gunter Van deVeldeVelde"/> for the IESG review.</t> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA+19bXfbxrHwd5xz/8Ne+oOkmqAlUnYcpk7DyIof99iyKrlJ e5q0BwRXFGoQYPBCmbV0f9bzB54/9szMvmAXWJCgnDRprtFTRwT2ZXZ2ZnZm Z3bW932viIqYj1lvwv46OXvBngdFwF6nMx6zqzRjk3K+4EkRJXP27fkZu+TZ Kgo5C5IZO+PFTZq9E4VzdhMV12xSFEF4jTXYSZSFZVTkPS+YTjO+wi5O2Iu4 5NQwtiZq9rwwKPg8zdZjlhczz5ulYRIsAKZZFlwVfsSLKz9d5sHN3A9CP36f L+CfZOHPoS3/6NjLy+kiyvMoTYr1Eqq9PH37jZeUiynPxt4M2h57YZrkPMnL fMyKrOQeQDPygowHANWbJc+CAmrnNKzXQRLMOQ6h5+H45llaLrHY+eXkuxc9 7x1fw+vZ2GM+u4wRGRIp+OLVCMZFfwzlH5OySBfUPP5SOLPfvsnCa54XmX6R SzQDeqIVz9bUl3y3zNJVhIOFOTHL5pxmqtHGVczfR9Mojoq1VTxaLOPoKgob sBnDGb04P7c+wXixWy8oi+s0Qxx4DJ6rMo7FlL1Or+G/M/Z1WobBLIgy+p5m 8yCJ/kVdjWG4QTLn9CFLkfb4LCpSUZIvgiges4VoZjBVzXyVUqVBmC68Zq8X UXgdZDN2kcKcF7mjzz+WSQTzbPaRZaL0V/8U3wYJLxxtXwaLiGfs6yCbl1HM XkRZEM9SRxdn6bsoMDvIqeZgKmr+Yy5qfpVguZaBvMnDIGMv0uRfQcz/BfPP nkepazxvecyvgAZCq8cUqw/msvoM8JrmXxW6qOgUmaHIoimQIMygl6QZUuIK uMSLkivjl+f7PgumSJghYObtdZQz4M2S2HvGr6KEA8sIsTFDsbFAfu6zjF/x LAMiKFIW5Ky45pr1e6pMkQINEcHS91fBGnA8fDTSZC5E0P6r95evD4gvqyKW 4MEiZ1CExA/1zJMQ4MK+K2EUSmHE9icn+cGAvb3mnpJGBBHjSTCNaTzEYDPo i8DP0zACEVJ176HkklyUY+/wO5f941DKBOrGa5SY0ANgNAsAg2VYlBnvY4mM T9feVRAiSwYkWVE6RXmBgJrcTcNeaHHE0iuW8BsgBAYcnReihxy6wBkFIg6R NAQgBJWGcsAulzwkZo/jdZ9N11CpyNJZGYpu8Cefg/yBSQuWAAPgDYc/OfEI 9dRaBQkOA2hBIC4vl8sU2Mgh+/0g9wNfyRNAfRBcismUOEZ05wW8AOaN/gWd LzgwchLlC1ojgjiaJ2KYjxCCjP9YgpzMPY3sRJICIOAqmpdKjmPBSFKglKFY fDEQNL2IZrOYe94D9lKigWSg9zZlel64IGmg/SQHoiK0Rgl1qglE9t5nUcEA H0AsJcq+4joQVE2oXGZEPzkvyiXyKhTUkwyFUwkbi6PkXS7qwmgSHsJ/yxyW CfzOs0WUSEnN2DKF+RKrVdCAhu2XeYnzzFZRAN/P1ffT2Zyz/fPTg4M+NgJF 0htEbl6GQCM5CqG1GDR/j7MwN6DLJXwDhqyj8Yvt0MBwVCbbE6ZMcREguA6O RIYU8NxcRzGvcxB2Wm8bmupNOSzeWW+AUolXveSCzCuxBCRaQqv7PVIiQHtA naHXZx8+5Fz8uLs7EEgvl6gq5BVv5ZWu4yncfhtlBSAXkBqtcFaVKNoH8jyQ veWVLNB0qAUrMCgMYRrB1ElgQ08LE+I4SQMwPhaCgoIsWeYIDzYIEkWBJbjv w4f/fuk/H5g6UsGR7TSmfYnpu7u6GMAGr1JFBgp47FiKZg5ajvc7mnEp/hri eYjiGYC4+Obk6fGTJ3d3VvmmOB8Z5Yeff14rP2zI9uGZLv/58POjRvv18iOj /NHTIZT3XkXv+E2UC+FrUKQYo1ifsB+xykADrrVEIN+YGyENa3OjyKR1bpLi xj01cnnVwpe4M2cp6aZpRjDkfBmgjMaerHXiKksXDNZopExD7luFBuwCB4Tt IPEv7+5IxC5SGMssykHUYEHJULUlvcnOKG+BoDVq5DR4lfJMhgSIL2h+Aupt VHBaAdn+2evnkwOpPiBjKGoYHQ8JD6fvA9BMBdajOC5JL5aCAcQQLIKkUFgM LcHEeZHiULaMXM5Fg9T4gwcgBlHZjABVZym0uw9Cf4qcugBZN8OlEYCRhQ48 j8rIQVYfQP9CdEDrxNERAWu0AjI/JVQvy2ksVexBXYNCNSyIYLVaxkHIr9MY hfQqgPFIMku4EHjUMBWaCdIE1MHSiOulLC7XmyJaEILMXgWkCQ4DVqdFkEG9 HMlLYRKsJ5B3RSlWTk3f2Dko4J53HoM8obUMlgdbZEioiI1AUjD2O/YXeJjv fynWP6CpOc4yYk4YZER0REvAGlTjEp6tNXYRc9TqGTz3abWNQanR4eHwsX94 5B9+VjUtuA6XDoVQA/vilTHpqHOcpMkKTWplcD5HVojot+C+BQ+QY3M9Q+vF NI1zJtUPYs4i48i3AShtCyGzLY76g+Cow0qyaLIDJspJochrTNh9HQGZCmq5 kJCC9FO54OF6QIOiHyDsqexZS9kzs+zZayl8KvoSUOLgAOiZGr9aqJbQZvSe I+UF4dgbmwqohBWsm+IGPyn55EEd/H2hhLvn5SuqrLRUAgGNMUI/ycAkncl1 UXZpSn3xqjIUZtXqH6agsuTLNJlhYbC3QU2G76ZiArpMfp3eJGIKsK27OxjP 7Tm1esvk85pK31Zgs1vvFmjPB+BvlSTEvy+lRHo8GCL4SO/IX7I0IEOXxr/x MzIKfo6HyUJ8jEerZULfrYVXFMJPutPqp6UCUMlRe3O0LotCdnOjenNCQ/gw Zg8QNYy2qp71XitNBWgHZivK2KTC/rmkit4d8toFj4VJcB0tkfjeoP2F62e1 zQVM9+EDIARV3VXEb2BhnPFlFErNIDNbmAIZcS7IcAWiNC1zbKxaKXNSmPTi BPb2Ik16bB840sleogAUBTVUVxTKLSKCalZzeoRz2p1PD0xQmq0NP6I1mE5q rbP8tGqLNXvfUsI973/gYUGQr+Yeqz02Phuf2d/Nf5ufb81/5eeBr5894/Ne 9XrgmbUbzZkvdihpzAf7PRqjtSm32vx7Naz2h0reOrtrLWkM036YMcO69Lbn 751L3u5Wcs8JGlIMM6bP84TK8dcx+4sUszn7K9ETyQ6DuZUIsSVAD4Q7rQ8+ 7Tg864Vo/GQoQt6auqZiZym8YVXVQn26NtRSg4H7Ngf2SWjZbCTXswH7mqrl DtOiKRckCItgLdRDuS4QIEr9R3ulrS0lEUQ7YBlGiygOMjQLAyY62hWOGOxm oa9w2qvS5hKq7fSHqAgqqbXPQsukELJawAaJaerKfR+tLEilyzSDKvVAb8rY WI45kAAMJ1e2mmHf8ffLNK9PYh1D35QZLh5oMPW1Da/MVrS6QKFUVqm1RSgc Iyd5v8VwIT3AMkbfSyWKNCdZ3UDGLnBTO4Zl2qG2QZRoMeEGOJhP7M851xqp tXqCTYVT/VbuUYkW3yQcEfK6jIsIa5+orSzchcrZ/slpfoALbxma6+0NGFpB Ngf6KdJlGqfzNbuKgxXZv0hAUbJK4xVRNu3hImGJgrjncx2seM1CQbcAUAvP cE8nFKvzxAYGYTlgYYDEx3hECkLAltfrHPdJADbCOu5GMuwH36H2XqyBaUqw 1O2XZAuul2KLBXc306vihvZyUhAVCeqm+3wwHyCbreRmkvbUqC1cMVYYUJor hbK29biX6xklyKBANvOXIMbWtS3ngwEO+JSRuQqcJWdb1Q5ox5vDmNVOjaFF n+M+I9u/nJwfSJvi8+PDp2QA/A7azJX4kVhDf0NIBADsAWNlKDdirrYzoxXi Rw0WwMbhsYWiEFepXCELOxO7MmksyLCOtFxC+NmTJ49BnRiImVbD1JukBHFE G6cSOmAOCS5uhyhoBEom5wYER8RLJ6dDMgWKYI6yEfBXFRW2LUfHD7YLqP+G NuuJgYToh/Jyt8U01Y5HT47v7vpV9zheSZJCm5Jbn+z8tNoxpm6aW6rS5M9h EUMV1aZI9PpxsbfHbq6lKqukmE05lrYLFKSkr8IpbldJiIlO5IxIzEvsQj1E udrA5tUQSSLeXEfAQmqkDhuKxijXI8DljPZmQ7WUGLNzLKZcsbagTbVwwPQX Uu/NAZdo3AHuRedqZ8/RO1gWPJmp3XacdEvGafhgUjQco4N+BeX5qQVhn/Ei JMHVJExhll9HuQaafBchfMSJysQulEajXMSkWLA2/ExfAJFcnKfYBPEoNCI8 XXr7GbC/DMg/HFX8pva5L9IS+gQzalYmsyAJ1+hOKNIwjdn+txcX5weI9Q2K u3wGdTWT9Ov/aivuVBBvobhsZ7C9+IBK7U+PDnT30J8q+dBuxdXArSg1OYF/ HmoI4C0Kgrq67Wzg/NRsACgDG9hrmhwK2PqzR8X2p8MDpQjv1TCm2n94fiqa UrvhGl4LY7dWw20YGzkx1mXA7RgbSpTvbW6gjrHjBsbYxgYUxkYSYw8bGHPW r9Bfa/S2tbZhmDwUUDdBbK/dANkFX5faraZUt9qmeUVYVxbVf3n70/cH7JmS vC9n7H1lT5WhNKP29F69UPf3NtpRuZCzUtgbJgutQ+TrUmFGleNaOy1QzHHV 3YZN/prb4Dq9sbVx2f00LZOZdLgJv8Cl4V05N70r36B3ZVJ5V5SiZBX68AB9 KsJeBOhgWKUQ2dpCQY1D1ozMHw2ZjQsXaMSw8rBUaX2gwxL0wSxdytWn2YJc +GHlicuZNHSuQBFmyxJVZ+Fn0EqK5UGC+Qtmq4CmQ8GhUYaLCOIRaq1pGdTI c7p061qPUgUczl+pP9LuLjS3g0JoGl7Su6t3I3sHfcsSU99HxnczoklHcKmS EgN+jh992XUP1jr2MgEtRMWGrNJoZswpULranUWMZXLNLCznL0yD2jiMU+Ek yPsuakDUCAtNxWdkVzh90LGwy4mZFKQ3qCYIO303j3ClLyFjVIa201VvGZgH 0jVlEldfKYmJ4G/BuGDMAE/diLfUQZ3PK7eTJi2p4NQ896huTECf6QuMJMCS hkW7b9mwB4KupPW0geFQYii12BRRpbSOjSCTAuyPWDoyaBtKOzIsIhTdS0Yj l7JFg+KzvUGQ8ZivAgHAgCxjkGkgztA9IFgZaIG8RJJfJYLEtrNSBNE2QN9e PYBQyKQ876St4WNrbO2qmlyDtEW9de2Ra85DvdJUn3QjVtBALhq0WbzPbJbu AxTtrNvXvRgE3Lf2E7EBpN3aBtfGoQysoWzFkR7WNhzd2gGh90doPURXd1BD KNCjhVD6LRGaB0vju8KW1YvGm2A8q5fWZ0fkmZrtz4081deJGVQmI0w29G6y zMMuzNNZeRtYrQ7a3teqUfPP00UAssHsTvy3+lDvroHBtvd1MPeMcT801No9 C0xC8nOuOMHGhNMswAr2XHSoUCf5rRWMZyCBHXSscCvBE4U7VRCBMlnXCtKc kcZClwpWuU4Vzk7fnrw5++bRyauXA/fz0V24NwIaK82AcC/cIdu9RbeqpKgH DdyenD44qkjRGqRlIYunKgn1hgj0nr/NVnUjYa8hgdXbjQ9VuYzQ9tjWVfOh el8b1hnoDdrNlTBpogkLTXHFn3Mgvg1eL++BDDlgbzHO5FJtCaJeUjnmjXBL ob+xPdBQuF6DA4or3TNVSdwzDK8jvqIw2Swt59cs8PbEgrsnNCFQvvaipa/U /zTZIzsoXQ6EKUZ9UdQw7cz1W/vFEOVgueTtporokCJSyGDIwaLA1WyE+tKS Z7QlBv/dUak2gyG6IinjywxMZNpp1D4FZeVUuBC7wNgC7uu7m0L1tbgGC2PK uyFA92OMesfA0sp9uEcaRA0kI9KIsG1GghDGzUiTLhO366Sw3cK90MzIMTL6 ui8sgkYkrtPZthNEzY0QwE6Ku7R4xMAnnyiGxMtoF2X4ms5BdO6QNbTF1Wu4 9HbBghtEEzgj4FUAiUqFii2WEJoB48rRKeP0lXkYRAuy/oxYKAxwo3n4H/14 opexpYpi2KE6SfJI2wdj/ZfxDpklr/22ZHXtW42KMdJMLhfZjQy+AkRc/Q7e iV/jJhJ9jbt/I5w7FHYP6Q/dhsQ+yEm4+4M1upEe3UiPblQb3WjD6Eb/pln4 eeHcofDPMgvDZDHW9p34SSDIbYfGmzrVyK8U/Wj/NH79xHNj1EWhRHX/FlAj Pyj4dAkMCVRPzIMr+G2XQVgVIlvLyBHIYv6X7FFyM5Zv80fyD/VfP5r94jhu a+PnoqjmnNS/1yblD7/wpIxwUkZ6UkaNSRltnJSRPSkja1JGnwj/F8NxWxv/ qwnfUI/Q+qNzAVWQIx1wtW24DWbfd9c69E6duZMeOr2HroIGdIABIb0v9vzV Vr912i14J2L1oR1CMYWvBMma/ohBzafgeLOGjH6iuAWoElOUmj43YvcMCuKX zD46BX8bB2p1JAkQGgxXxtxoDZjUc8fOcTKN/HWQzEEJFtEX9YhEiZs+w7ga gG9PEhseHdjrIxDKqxUlIixKBM+okwVVYzko8crK3AWwvnCpkD1l9V7FSRbi nLfoca9J+eSx1UdHhNZuN1WfvkEtJNaKYtSeR+1bJBW/Yi80UyQtwXSmZZGj 3yogX5A9r2T5hRRwS2drZnwZp2t9boq/BzvZnJiqD+lTVBbblF/hGTSMkrsq KLQPO4sS3EAIKYZXlkSzHVrxBXxSmqAxqp3JOXlB6/1JG0mOXUSEAYeRS7Xi l+YI+/LEq+hV4qLqVvh9sEM7VlV3p2LtFBbxzSqaKS91DZ0cj/xzcnWTQaZk Q92/Jk6nyM0fdGpLeSdPEelDovbhSTBJzT2Pvj7+Yx3k6FfeMtPc71uHgKyt gYHVrYiRMnBxz/NLasNhh82ASsoyZD7v9ydvnp+yr09fvDy7/JJd4TxaiPyq Oio2wAo9T7GIGcP+AYQ/fvVBElKIwNHg6At4R0Jiid7eXpklY6wzxuCERT5+ v4jHST7GWmNr5rCeOoskXn2BprEIUK95y6hjXVy//oLe2loJYz08JYQTOHYm iKGMJ9q19Vz6Gwmcu3r/Q3f/ww79A12NmTtFjQ4FsM9mN/eq9WFtSs5y0BFo peTUkZYsNsCL5KvhVf064aYQhXwDvppdDzd3DUzVrethe9fygIrVr3i3oWc8 adYgEhEVq442IOftVRHGzTlSWYP2rNwRTOaOaIO1gSPxbgOseOwNsaQQ5Mx9 5EhmJADw7HQs1HAP0w4xkSWI7bcmFWITWG7Yd9An6j0vMLmQGBYdBw4FSnrQ xHd8OoY/f39dFMt8/OgRHjLDTCzveEZSawAQPLqZPxLC69GXYnRQ8RVoPlDz 95gSpkjH4vtXqsqXniioDjKzlpQ9xqNa2pSUR3Y/EXmB4C9XSh5Hm64kPI22 7BQ8bU3l2/LtNNrdkG3H0X6H5Dpf0kyCBhRm0bKiDFrDzGOfteQ5C01yQZVu S50EEeDoJVIfCXFsildL40DO8km6XGfR/Lpg++EBnV+m7FhgEpTGeRrAe46U CmoE9H0VkRYj+yVk6YMfIUA6ABTGMaNmcTlGNZZOilOFC47Rz6R2UtBbMqPz P7BE52mZydioaZQE2ZpRCoG+GI7M/0Q/QKVBnOjsVKROLzH2uUCNZ1lmeYmh MkUqdIe8nP6TS9ZRsUOoLCc5l2eI5Vl70hWEGnLBQUNFqr98DhxDZUV9PL0E gAFIALM6LXk8CBUKKvzt5ewVn9OKo9RdhYNYxDICLFT8uTx8Lb/vK54usBnO K36WUPtoDx0olBL5KBVBnSg3ySmqVE6UbXgG/ws87YHwSojgNYgvHl8RmWGu FzBAEfYkpcjCQY/UhYzLYEXjqLsQrHWiRoGHp9YpAktUGvQ2CFwEqm0FdyeZ ay4Ou2Sd04L6CrR7jMU0lS7ncFAtJttAxYIJc1TnN8JjI5QuydLqFZQ1fRtG hfu8pjXjjJWs4KQ8c5R3hsIl/Wrzoh3kSVWLECEjLSvjRHgL9XlANUO498Aa HTA8J8K77JN8Ics3QSKgrP5lnFpQHTgL1DFBARbZ+zeBIXfNU31mfhVQAdTB NDmQuy3Y0/s2O2LQsrl+k1hjWiZm1gbX7jAqSFoBqEC03YUKHCYMOwFFBww2 J70br8hzqRKDvubiyYn2Z6KSZU63T4dafytz7kRaBxbRB3r/l+CJMTWcOlu8 42vWE5u9vXuA/Muxitq577l8zz3d7UOrgMsRvalsY8e+t4Gq1A4SxYHjUmmv oNXB6VrGU4V0kF1xPsDIuzDjoIavKQ0fLtK5jJBRqx8Sr6rnygkpMiY2Q2DE bAE6VWVXPrYmBakZkqzwxS88Bd0Lq9mKrnylNPXM7aV7zeO9ZnEuslq545tU 5c0xTa3zWYmFLdPpqXJv9ZedHRuqiVb/hj7JRNafC4EWWTV0Qxd1NcMaakSw McZhU9lfMYMbhKDn12LwLVF+Px+z/zuno3vh/xBmF1zeLr3rcyunVu2tVhOs pYZagn+r3L9rSEp9gWgPSWkreU+Z4BYHNJVG6lVVTPVdz33ZVU7sHx1oKmqK jJ9cGSDQ94cH3eXTpj6b+mJFzs3Eoy7ZJBXZXyfBdCn28fLKJao2EFotlzh6 fVtFl9G8JjK98QOUt5uisqOoqkjN6qRGZVu1Ine24fr2lls6uvC4XVxqVHUN BqmJy9bdtw1CcwMf7BrSVF9s20Oa2kr+9gRn60KsmnBKt270/fFQbASizST/ KNn6y9NUl2K/WdlaJwTVQFM97CpsK5nlkrmdlNJWKmyTwb9J2XsnY2hOz55f fmlGMWLGOR6WGWZ9OME4vpnypMtgICPrNrEk7v9RaBeiq+CLZSwCxpBipyo6 SDnyRoPPUHRUcXYAPbTiZ1fh0+PDz6ZRLqOOHGkf3R5cI026RJgnQg118m7J izO6kAEb8acB/jSu9ljKrEp5nw4doftVHseUGcKeDI+PZOTSxeml+eXpIaV5 lunwdEMyG17qofcVRWZICUnwOgsKnYiJGOWhosvL/6MykQ0fDzEk6+2rS9X+ 8fETGaTl/enPL09UJrjDw0O8O4GSg4iuyNG7KCkIB/3G6NLTuc8lvbrPVk8E Q5+IBAsqmf/Z5KS6LGCE4/cYq64OKWSqbBljiE7nsFCyAakUfaJRWMZBps62 Si+zxiAALHI5BMQfEiZOHmW1yMQwmBWslJQ0q6UdhXWZr1+HfVCoYlLo4aMb Ev+vkpDbGaaNcLaGi1clyMCGboA3EJpHJC3oL2QD+ovtRwMOMyrGQpddqSxr Ua78wdBRUMbFgbjNI+cmECp8UnIe4oInmHhiRUGUqzJOYIhTIQnJq7+obFae rKIsTWhdgMa/y1CHMHAiyQ3ve/IFhLSqI6poBFZhsW1uQ6eiA4TsNPK6YTMU P2GSHQVLEnFCfT6ne40Yv7rCu1Xgq86gqPuklL+bLskAusAIazG7BlzUSUVv 2IxCG+VVe6TwJvOsUbZ8HWoLQlEE7e5VLoc9CmQfg94mV5h3eAnNNaXzo4kW AbJI62ocApRQb5fQPSoo/XXKGdFQJWQE1oVTOyuTRHrgZX2VPUPkWsnKpSgZ x0LSZsEVes8ozjWMI6RzG3eeWmKqASB1UWTHGgiVImaFKopzf6BT8TWzwVTg aaBiHsxEjIXsZxHEKhmkkSLFXB3xbKUIB4YmVWjZK77iKqZoMofJJYG8f/lq cgACO40NyoDpoJSfgcpKJINxQZUGkpJpmWb8xzJALQYGmtBVE/ImJwreqkx3 59VFTFy8I+N3LtOFvlUAWH1G825QnUtQNPjXpMUaC2/j35eFEBolmaQi5k7E 3ahcOASWokPJ3bjKzXnRx38kl/elwMRgExXUc+Bi8MFG9vM6st9PxntCOpoR xymOQSVmQhGkwobwzo9VEK61i9TQpPoYx435h+1ea9mviD5kY0YaZTNc3Uhb CTiG+UyqO6Io8xelx50NBPji7hLgpT6Igjh6x63u+9aI6cBCEv1YcjPdbB6C bJTeM4FreSfZWqfpeo9qzFokQT05FQHmLydnk4buBk3Q+yrDpRh2xud4VCOr Sdo/X7xUSY16CVgoMPWiZLaWEHoSTyLw8i+vX7ELWaAnlYbRk6dP6T4FUiyh ODQKs9o1ppqWeNEkUv2JCNAUZMFenl6+IDxDx/Dq7NHkC8mnamw0Arr2CmHT Md0DAc2u+LDivSRejFh9bO4Mu+gxjSaBhCeHw0M8xVLNqqh3joMHwZWZVcRl lxXCzuhWQlbHypkazI7YFJczjBkz3r0OIhWbB+ITUfIH6EDgXvLdmOm4Nok8 3/fZFNkFqE0nIRTHFVQmQJGYukprfGLcniGRoSK+lFIq1dAPD5rnQDzvFcdM 5lqwmgkJZQJrZWvw9/5qeZPT0SGpeAEDL+n8O13VVJkjQ3GnA2neTzAH8ICd 4hmmc5mwGWGnRe4mJe5iEgoyycR9c0xfN+fIEI7Hj0RQ57p9u0QIYUw5bJ3B J/ojfdg+ACFzhw3sXEQdHlHD07cxTE6OtlWZnAxZdXPDLSVfvcWULsPDw6Px bPp0fHR4OB6LdvS7oXj30PdvKfnobdXnrQaEYK/+sv6+rfqk5C2YC4ayxNzi Pyppz3l1s4ROb/RQpnvRXmr53H57/t3l97oJ9e8jfH1bLwvTD8N89uwZ/l// C2+HrFkWnke39Xa//56A15PUBJ7ZwN+qTDn1STKui9iz/rL+vrUnaSQmqcsj J+nYnKTJyWhrvcnJsWOSOj9ykmqnJyXnqgOUODnsrcpEL+XMhvOTE+s2H9mY D7I9W6vTT1UspuNQF6gVeMFugXm69fkuyYl0bIqa0hk8QfeK5QkEpSXW7yf8 DoROld0Sx3NgXgIzGhzVBdCBzez/zMG2emY/7OzN29Mx2/t+D+9nBGmayc0j 1IfotM5nnw9ZrdIzz6NNxlqaxMrz1BurIKueuUVava596Y3/ZvHChxpniMLR rDfu4TQcDUfHj3t9ZyFjdxNKy/sOaPLrly98X6/f/amm2wGF0uLo1CXAoH9v Ahtj66AsIRR/i32qMY7WUWM6X/rBzBfZvwErtDXQKIUbV0BVybyt9Xi29HUh RzfzOJ0Gsb/U2oUPRjoekLNnskOF+gTrx9WMbExWFdNOV1xz3VwD1qoapmKN /aAs0iRdgKHs52tQwRa98ZPHjx8fbqiYzaiWe2hVMVGmZTj6Scq4cbjFfH5o /Xi3AUSiFLpUYwsEG4eALSFSj9p7kqUyTBkve8y3D7pDx46GYXYPcXJGj8dH ve3V77YU+WGnUSnWwA3+jZ23d9syla4KjaLNye5pH1ELj2mn0T1YStUVPLXk R5sYKZHFaurZpiq0mcL9XeVG1cDuAqTDsKvmN4mULdU3kt39uJmkOEgTH28R SenU6hb06FXw8dPP2gHe1Ge1JqRyjdwi7WYr9Gvl3F8UZctCY1XANSXNQCko llvaJnCCKOokiPgi/XkkUUEQDP8dcqfwETnLGyVz6BaPBATg/eTOtoWi4T7u QFw1X/JPwnREsEeP4H+DTcLDqKASpPtV1U4Vbd3vpZlnHYzNTk1ICaYFpRY/ Slx8hNbIyOG1RX+pQMmLoCi3zZoB+WwRgUK9UyWzm4Z2+HEjFeCUyw4rOttI yxaw5ibUuNoABegnJz+F8rAVjp0IfnR/gh99PMF3a+ITwf/HEvzopyD4e6o1 LTpvy6h2UEmHO6mkw08qacvzSSXVFe6jkg5/cZX06JNK+vOqpENYZof3W6Gp 6sev0N2a+LRC/8eu0MNflUqKVHt8f4I//niC79bEJ4L/jyX441+fStppG9Zr +aVK0isMdHY7GYVfULkajWs6yPF0Qtchpon2QCkn3kXlRhIhDip4AQNzXMEO Kp6hlmFyx4AGvGZbRpFQMIIOO1JX0iKs8qbcfeOu5IPNIQvqGl8M8aPwBCMY QaZNaL/bFiNpYwxAW+sL6AbmuM3gB9Gs6m6XOAfjqccNVLfWVB89eXsNPcKT //DZs2c1Z7h4RQ59o+2BiHCQ99E87B0/PuxV7vrX568uZavwf/h41FMlEdPC C05O8L+bvvn6nabM/ChLGtEKt/XCmEQs481v+Iuqidx+Y/RUyi+1C28qx7ws +vjJZ08dXIE0pvhhB6977RiECMW/z00c6r4/fTumvOhR3reIFC0D/1SgKh36 5e8jcaOhpq56GEAQ1pOIklsdZb15jYgjnwfId7lW04EcjM6qljam1Npq0egJ /zGUxsglh+uzFw+Nm3V06/Ij8E2wzEsR81r7iJo/KfysseLM0uLox9ra2BMv 622QqaKcy82WQn8VB0ljme2F+JrUCvb48WGb5DX+Nhamng4YsAdLliA7qjl4 e7g0LcFGS31QZKYw6TfRrLhuIsP8VLcvmqt4b3rTOmj4tOSZj9G1DgWjB6SA tYaHx08P4amvlvY6ZC5Td41xhTSu5W9qXD+meXMQ8NLYrGnSoPHdMUy3ftyr KvT+lF7+41z8/MfEqRX2ZlGmmayJGqfruK53/NCF0E1tQ1nvICy2iIfQN3V6 WwNnvW+iDPMfaXFkFt0gh8R3S/LoLz90lUHy8k0dLoPw4NrSaw65v3GAww0D vMTDPrNf0QhxSXSMUEyq16ZHBmGV6z8XOiMGHtPhQTq12Kv0vCS9MXU9qYBp Pe4moHTeaXUHMCiiry6rTOlTULs4l3HhmKikuc6tlnFeX+maWtRtpRkw0Ufv 6PHxqMeq93aU4/11MIww7aaDUaDpJx2MptBpk7y63KSCVfd49St9CGkSNW3j IolZmamDraGycFTookVt1QHYRr54nba2dgmBkxyBy37conw5YxGV1mWHImo+ tgMRDfFgMbra55YE3q9/U8Lq5M3F+Rv/9C8TIK9Tu1gtMJD1nKWqaMDmUoNY aJZWSRALqWe7al6XUz9fpu/sbY9GICG7AtOO27pGLYqw2XZ7GOHGCML6Or/B 0dJFeTEdKWx7vCBQPOmn/lJkPVZqstudoEuHpGw0atxT3zFiverYqMK8ugze 8qIxEnSOQSTqu/afPXZ7z3pZGjunGsmIvjnqqE0st8Jlb421bFpWbTR63rSX 1dzjcexldfEEukHfhTDF07bzt5lInZU67V85x9v0q7mHZ7nH2iam5ihCigOB TD/c24a9JVoMIOww/WYrojYHAGP1YDbLbJLd5vEF28gQ1C3l3LuFrt3FbsTl 9m65Ed66gcr+JpR5x/zWBUwdhC4ywcnpDpnQguBWoUDryiex8Eks/KJi4Tcu FYZdpEK72tEwR8XXu1ZzVCncDgNCWpMX0rgUJiqp9qjN69uoXsNwca/163S2 PkDLQp9hVhd56ez8yj6w7QZtVUgztm/v5qpN4jQLrznd6pWKpARXtOMBL8N3 LDIMElVBbhHrLDjSOaHN58peEcEdmNOALhVieLZEpBCg86ZWz5QkBytdTs71 xjVlVzk+fIqWDqa4xow24lIOZdjkwVKdKhuI2yGU30b4V/LKvhdOJrD7Q54l OUuTeI32MF4enos7u1URea8YNCCT/IBl3GI3ScJDMNBsahzIMk9saUOj7bCS bZ30oNHtJ7uwZxH8FCwfOFhY8Lsq5ZIXqJw3gz+bwS813/QEswzgCVqYMEe3 xga+doZDrRenh4+euOKRDZe5iR+F2OX12lFHLKl2yTKJXODg4fHcD6+jeIZF 89ZTX9DMJg90u7M5XboW0m6+0R+cQkQTt0OKIJtccNAd8GaXprAQN43Lzw5m 0acqDQZxcbnkXcHmJ8gt97g0nfydKreDzJBhZtAX6fccuU4MIYLj3ZcuJOyP xuEP3ac0P3HmJ87clTP7O02nC0/1WaAhtUyCmCHfCBnwKWRAT4Qj1mfzzB0P HPFwW+YuTueYXcZRz3J/tvIFbum4tdWffrYcY6uuvBujl8fFQi2KsLq4Ylx3 /9il1D3FGNopRO94Q4h1z7iy2KghvLVdlOBWJ1eHtcKSio71AvRKFR6jlw0K YSHB6lw/zDSgeMlIQe4DKdMzjreorjZmCN1praAUXLVQG2NQrTvX7XRgSnh5 mBxn+8gW5as2Stgkn+uS+QerSSfZb4tua2cIt5FeY4gepm67T+sOdjMoz+yl 7sqrja8WMdEEgQq0yRJX4ARWkrETThFShU90jZ6galUERT2Agm1ZFRz+yppD 1kaYVjpqqKJ4i3q4BWsPuGji0vi4i9i7d4iCqE5xCq1hCjT8LTLNMWBXJMZv dsAUotEcnR2k4SR2K06jZd9nw7aPUV3Ku+2BG7LqpmVtQzUj6qNj0Ac9Hxdx aoULbF0pO66TzeXxAZuE75L0JuYzkfoZGheJTPnsWY+8gGIVDZJ3FErwdcq+ K2mD50+wuMGfVeaaVcRvZIrUhUg3aFZ8jan8Evb1P//f/83exWgXqZqYVmyW hgXeSSpa6bMX8JK9jvLrLKh6KOY+zIUuc5FCc3RPqy4Ca7NRwrvgGCF6mszx 2tpCl5rzBK/WVO0gyOcZLOQR+2MAIKpimHmsaq02mGueX7M/cjD1EqgfJJGu NnnuqvGiRAWWfQvDmoGFyuMZ1zUw75yu8/8BkX2YWcDBAAA=[rfced] FYI - We updated artwork to sourcecode in Section 5. Please confirm that this is correct. In addition, please consider whether the "type" attribute of each sourcecode element has been set correctly. The current list of preferred values for "type" is available at <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. --> <!--[rfced] Abbreviations a) FYI - We have added expansion 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. Virtual Private LAN Service (VPLS) b) 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) Layer 2 VPN (L2VPN) Layer 3 VPN (L3VPN) --> <!-- [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>