rfc9836.original.xml   rfc9836.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.3. -ietf-opsawg-ac-lxsm-lxnm-glue-14" number="9836" category="std" consensus="true"
6) --> submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version=
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft "3" xml:lang="en" updates="" obsoletes="">
-ietf-opsawg-ac-lxsm-lxnm-glue-14" category="std" consensus="true" submissionTyp
e="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.25.0 -->
<front> <front>
<title abbrev="AC Glue for VPN Models">A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits</title> <title abbrev="AC Glue for VPN Models">A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ac-lxsm-lxnm-glue <seriesInfo name="RFC" value="9836"/>
-14"/> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair" role=
<author fullname="Mohamed Boucadair" role="editor"> "editor">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Richard Roberts"> <author fullname="Richard Roberts" initials="R." surname="Roberts">
<organization>Juniper</organization> <organization>Juniper</organization>
<address> <address>
<email>rroberts@juniper.net</email> <email>rroberts@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Samier Barguil Giraldo"> <author fullname="Samier Barguil Giraldo" initials="S." surname="Barguil Gir aldo">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>samier.barguil_giraldo@nokia.com</email> <email>samier.barguil_giraldo@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Oscar Gonzalez de Dios"> <author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dios">
<organization>Telefonica</organization> <organization>Telefonica</organization>
<address> <address>
<email>oscar.gonzalezdedios@telefonica.com</email> <email>oscar.gonzalezdedios@telefonica.com</email>
</address> </address>
</author> </author>
<date year="2025" month="January" day="23"/> <date year="2025" month="August"/>
<area>Operations and Management</area> <area>OPS</area>
<workgroup>OPSAWG</workgroup> <workgroup>opsawg</workgroup>
<keyword>Slice Service</keyword> <keyword>Slice Service</keyword>
<keyword>L3VPN</keyword> <keyword>L3VPN</keyword>
<keyword>L2VPN</keyword> <keyword>L2VPN</keyword>
<keyword>Automation</keyword> <keyword>Automation</keyword>
<keyword>Network Automation</keyword> <keyword>Network Automation</keyword>
<keyword>Orchestration</keyword> <keyword>Orchestration</keyword>
<keyword>service delivery</keyword> <keyword>service delivery</keyword>
<keyword>Service provisioning</keyword> <keyword>Service provisioning</keyword>
<keyword>service segmentation</keyword> <keyword>service segmentation</keyword>
<keyword>service flexibility</keyword> <keyword>service flexibility</keyword>
<keyword>service simplification</keyword> <keyword>service simplification</keyword>
<keyword>Network Service</keyword> <keyword>Network Service</keyword>
<keyword>3GPP</keyword> <keyword>3GPP</keyword>
<keyword>Network Slicing</keyword> <keyword>Network Slicing</keyword>
<abstract>
<?line 60?>
<abstract>
<t>This document defines a YANG data model, referred to as the "AC Glue" model, to <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) wi th references to attachment circuits (ACs). The augment the Layer 2/3 Service Model (LxSM) and Layer 2/3 Network Model (LxNM) wi th references to attachment circuits (ACs). The
AC Glue model enables a provider to associate Layer 2/3 AC Glue model enables a provider to associate Layer 2/3
VPN services (LxVPNs) with the underlying AC infrastructure, thereby VPN (LxVPN) services with the underlying AC infrastructure, thereby
facilitating consistent provisioning and management of new or existing ACs in facilitating consistent provisioning and management of new or existing ACs in
conjunction with LxVPN services. Specifically, by introducing an integrated appr oach to AC conjunction with LxVPN services. Specifically, by introducing an integrated appr oach to AC
and LxVPN management, this model supports Attachment Circuit-as-a-Service and LxVPN management, this model supports Attachment Circuit-as-a-Service
(ACaaS) and provides a standardized mechanism for aligning AC/VPN requests (ACaaS) and provides a standardized mechanism for aligning AC/VPN requests
with the network configurations required to deliver them.</t> with the network configurations required to deliver them.</t>
</abstract> </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 (ops
awg@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> </front>
<middle> <middle>
<?line 72?> <?line 72?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>To facilitate data transfer within the provider network, it is assumed that the appropriate setup <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 is provisioned over the links that connect customer termination
points and a provider network (usually via a Provider Edge (PE)), points and a provider network (usually via a Provider Edge (PE)),
allowing successfully data exchanged over these links. The required allowing data to be successfully exchanged over these links. The required
setup is referred to in this document as an attachment circuit (AC), setup is referred to in this document as an attachment circuit (AC),
while the underlying link is referred to as "bearer".</t> 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 <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 b ind specific network Virtual Private Network (VPN) modules with the required information to b ind specific
services to ACs that are created using the AC service model <xref target="I-D.ie tf-opsawg-teas-attachment-circuit"/>. Specifically, the following modules are au gmented:</t> services to ACs that are created using the AC service model <xref target="RFC983 4"/>. Specifically, the following modules are augmented:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The Layer 2 Service Model (L2SM) <xref target="RFC8466"/></t> <t>The Layer 2 Service Model (L2SM) <xref target="RFC8466"/></t>
</li> </li>
<li> <li>
<t>The Layer 3 Service Model (L3SM) <xref target="RFC8299"/></t> <t>The Layer 3 Service Model (L3SM) <xref target="RFC8299"/></t>
</li> </li>
<li> <li>
<t>The Layer 2 Network Model (L2NM) <xref target="RFC9291"/></t> <t>The Layer 2 Network Model (L2NM) <xref target="RFC9291"/></t>
</li> </li>
<li> <li>
<t>The Layer 3 Network Model (L3NM) <xref target="RFC9182"/></t> <t>The Layer 3 Network Model (L3NM) <xref target="RFC9182"/></t>
</li> </li>
</ul> </ul>
<t>Likewise, the document augments the L2NM and L3NM with references to th e ACs that are managed using the AC network model <xref target="I-D.ietf-opsawg- ntw-attachment-circuit"/>.</t> <t>Likewise, the document augments the L2NM and L3NM with references to th e ACs that are managed using the AC network model <xref 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>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 <t>The YANG data model in this document conforms to the Network
Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t > Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t >
<t>Examples to illustrate the use of the "ietf-ac-glue" model are provided <t>Examples to illustrate the use of the "ietf-ac-glue" module are provide
in <xref target="sec-example"/>.</t> d 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 public
ation.</t>
<t>This document contains placeholder values that need to be replaced wi
th 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 --&gt; the assigned RFC number for this I-D</t>
</li>
<li>
<t>SSSS --&gt; the assigned RFC number for <xref target="I-D.ietf-op
sawg-teas-attachment-circuit"/></t>
</li>
<li>
<t>NNNN --&gt; the assigned RFC number for <xref target="I-D.ietf-op
sawg-ntw-attachment-circuit"/></t>
</li>
<li>
<t>2025-01-07 --&gt; the actual date of the publication of this docu
ment</t>
</li>
</ul>
</section>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The meanings of the symbols in the YANG tree diagrams are defined in <x ref target="RFC8340"/>.</t> <t>The meanings of the symbols in the YANG tree diagrams are defined in <x ref target="RFC8340"/>.</t>
<t>This document uses terms defined in <xref target="I-D.ietf-opsawg-teas- attachment-circuit"/>.</t> <t>This document uses terms defined in <xref target="RFC9834"/>.</t>
<t>LxSM refers to both the L2SM and the L3SM.</t> <t>LxSM refers to both the L2SM and the L3SM.</t>
<t>LxNM refers to both the L2NM and the L3NM.</t> <t>LxNM refers to both the L2NM and the L3NM.</t>
<t>The following terms are used in the modules prefixes:</t> <t>The following terms are used in the module's prefixes:</t>
<dl> <dl>
<dt>ac:</dt> <dt>ac:</dt>
<dd> <dd>
<t>Attachment circuit</t> <t>Attachment circuit</t>
</dd> </dd>
<dt>ntw:</dt> <dt>ntw:</dt>
<dd> <dd>
<t>Network</t> <t>Network</t>
</dd> </dd>
<dt>ref:</dt> <dt>ref:</dt>
skipping to change at line 158 skipping to change at line 129
<dt>ref:</dt> <dt>ref:</dt>
<dd> <dd>
<t>Reference</t> <t>Reference</t>
</dd> </dd>
<dt>svc:</dt> <dt>svc:</dt>
<dd> <dd>
<t>Service</t> <t>Service</t>
</dd> </dd>
</dl> </dl>
<t>The names of data nodes are prefixed using the prefix associated with t he corresponding imported YANG module as shown in <xref target="pref"/>:</t> <t>The names of data nodes are prefixed using the prefix associated with t he corresponding imported YANG module as shown in <xref target="pref"/>:</t>
<table anchor="pref"> <table anchor="pref">
<name>Modules and Their Associated Prefixes</name> <name>Modules and Their Associated Prefixes</name>
<thead> <thead>
<tr> <tr>
<th align="left">Prefix</th> <th align="left">Prefix</th>
<th align="left">Module</th> <th align="left">Module</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">ac-svc</td> <td align="left">ac-svc</td>
<td align="left">ietf-ac-svc</td> <td align="left">ietf-ac-svc</td>
<td align="left">Section 5.2 of RFC SSSS</td> <td align="left"><xref target="RFC9834" sectionFormat="of" section=" 5.2"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">ac-ntw</td> <td align="left">ac-ntw</td>
<td align="left">ietf-ac-ntw</td> <td align="left">ietf-ac-ntw</td>
<td align="left">RFC NNNN</td> <td align="left"><xref target="RFC9835"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">l2nm</td> <td align="left">l2nm</td>
<td align="left">ietf-l3vpn-ntw</td> <td align="left">ietf-l2vpn-ntw</td>
<td align="left"> <td align="left"> <xref target="RFC9291"/></td>
<xref target="RFC9291"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">l2vpn-svc</td> <td align="left">l2vpn-svc</td>
<td align="left">ietf-l2vpn-svc</td> <td align="left">ietf-l2vpn-svc</td>
<td align="left"> <td align="left"><xref target="RFC8466"/></td>
<xref target="RFC8466"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">l3nm</td> <td align="left">l3nm</td>
<td align="left">ietf-l3vpn-ntw</td> <td align="left">ietf-l3vpn-ntw</td>
<td align="left"> <td align="left"> <xref target="RFC9182"/></td>
<xref target="RFC9182"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">l3vpn-svc</td> <td align="left">l3vpn-svc</td>
<td align="left">ietf-l3vpn-svc</td> <td align="left">ietf-l3vpn-svc</td>
<td align="left"> <td align="left">
<xref target="RFC8299"/></td> <xref target="RFC8299"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="relationship-to-other-ac-data-models"> <section anchor="relationship-to-other-ac-data-models">
<name>Relationship to Other AC Data Models</name> <name>Relationship to Other AC Data Models</name>
<t><xref target="ac-overview"/> depicts the relationship between the vario us AC data models:</t> <t><xref target="ac-overview"/> depicts the relationship between the vario us AC data models:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>"ietf-ac-common" (<xref target="I-D.ietf-opsawg-teas-common-ac"/>)< /t> <t>"ietf-ac-common" <xref target="RFC9833"/></t>
</li> </li>
<li> <li>
<t>"ietf-bearer-svc" (<xref section="5.1" sectionFormat="of" target="I -D.ietf-opsawg-teas-attachment-circuit"/>)</t> <t>"ietf-bearer-svc" (<xref section="6.1" sectionFormat="of" target="R FC9834"/>)</t>
</li> </li>
<li> <li>
<t>"ietf-ac-svc" (<xref section="5.2" sectionFormat="of" target="I-D.i etf-opsawg-teas-attachment-circuit"/>)</t> <t>"ietf-ac-svc" (<xref section="6.2" sectionFormat="of" target="RFC98 34"/>)</t>
</li> </li>
<li> <li>
<t>"ietf-ac-ntw" (<xref target="I-D.ietf-opsawg-ntw-attachment-circuit "/>)</t> <t>"ietf-ac-ntw" <xref target="RFC9835"/></t>
</li> </li>
<li> <li>
<t>"ietf-ac-glue" (<xref target="sec-glue"/>)</t> <t>"ietf-ac-glue" (<xref target="sec-glue"/>)</t>
</li> </li>
</ul> </ul>
<figure anchor="ac-overview"> <figure anchor="ac-overview">
<name>AC Data Models</name> <name>AC Data Models</name>
<artset> <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"> <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 32,144 L 32,240" fill="none" stroke="black"/>
skipping to change at line 286 skipping to change at line 255
| '------------------------ ietf-ac-ntw | '------------------------ ietf-ac-ntw
| ^ | ^
| | | |
| | | |
'------------ ietf-ac-glue ----------' '------------ ietf-ac-glue ----------'
X --> Y: X imports Y X --> Y: X imports Y
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </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 re quest and the actual AC provisioned in the network, "ietf-ac-ntw" leverages the AC references exposed by the "ietf-ac-svc" module. Furthermore, to bind Layer 2 VPN or Layer 3 VPN services with ACs, the "ietf-ac-glue" module augments the LxS M 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> <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 re quest 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-sv c" module and AC network references exposed by the "ietf-ac-ntw" module.</t>
</section> </section>
<section anchor="sample-uses-of-the-data-models"> <section anchor="sample-uses-of-the-data-models">
<name>Sample Uses of the Data Models</name> <name>Sample Uses of the Data Models</name>
<section anchor="acs-terminated-by-one-or-multiple-customer-edges-ces"> <section anchor="acs-terminated-by-one-or-multiple-customer-edges-ces">
<name>ACs Terminated by One or Multiple Customer Edges (CEs)</name> <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> <t><xref target="uc"/> depicts two target topology flavors that involve ACs. These topologies have the following characteristics:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <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 i nfrastructure). A CE is seen by the network as a peer Service Attachment Point ( SAP) <xref target="RFC9408"/>.</t> <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 i nfrastructure). A CE is seen by the network as a peer Service Attachment Point ( SAP) <xref target="RFC9408"/>.</t>
</li> </li>
skipping to change at line 431 skipping to change at line 400
'--' | '--' |
| | | |
'-----------AC----------' '-----------AC----------'
(bx) = bearer Id x (bx) = bearer Id x
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </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> <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>
<section anchor="sep"> <section anchor="sep">
<name>Separate AC Provisioning From Actual VPN Service Provisioning</nam <name>Separate AC Provisioning from Actual VPN Service Provisioning</nam
e> e>
<t>The procedure to provision a service in a service provider network ma <t>The procedure to provision a service in a service provider network ma
y depend on the practices adopted by a service provider. This includes the flow y 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 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 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" 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-se ), Layer 3 VPN ("ietf-l3vpn-svc"), Network Slice Service ("ietf-network-slice-se
rvice")). In order to avoid service interference and redundant information in va rvice")).
rious locations, a service provider may expose an interface to manage ACs networ
k-wide using <xref target="I-D.ietf-opsawg-teas-attachment-circuit"/>. Customers <!--[rfced] May we clarify that the modules in [RFC9834] would be used
can request an attachment circuit ("ietf-ac-svc") to be put in place, and then to manage ACs across the network?
refer to that AC when requesting VPN services that are bound to the AC ("ietf-ac
-glue").</t> 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 vario
us locations, a service provider may expose an interface to manage ACs network-w
ide using <xref target="RFC9834"/>. Customers can request for an attachment circ
uit ("ietf-ac-svc") to be put in 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 provi der 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>Also, internal references ("ietf-ac-ntw") used within a service provi der 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> <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"> <figure anchor="_u-ex">
<name>An Example of AC Models Usage</name> <name>An Example of AC Models Usage</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="688" width="512" viewBox="0 0 512 688" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="688" width="512" viewBox="0 0 512 688" class="diagr am" 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 8,608 L 8,624" fill="none" stroke="black"/>
<path d="M 48,592 L 48,608" 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 96,480 L 96,496" fill="none" stroke="black"/>
<path d="M 104,368 L 104,384" 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 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,400 L 136,464" fill="none" stroke="black"/>
skipping to change at line 614 skipping to change at line 609
'--------------------------------' '--------------------------------'
Site A Site B Site A Site B
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="module-tree-structure"> <section anchor="module-tree-structure">
<name>Module Tree Structure</name> <name>Module Tree Structure</name>
<t><xref target="RFC8299"/> specifies that a 'site-network-access' attachm ent is achieved through a <t><xref target="RFC8299"/> specifies that a 'site-network-access' attachm ent is achieved through a
'bearer' with an 'ip-connection' on top. From that standpoint, a 'site-network-a 'bearer' with an 'ip-connection' on top. From that standpoint, a 'site-network-a
ccess' is mapped to an attachment circuit with both Layers 2 and 3 properties pe ccess' is mapped to an attachment circuit with both Layer 2 and 3 properties per
r <xref target="I-D.ietf-opsawg-teas-attachment-circuit"/>. <xref target="RFC846 <xref target="RFC9834"/>. <xref target="RFC8466"/> specifies that a 'site-netwo
6"/> specifies that a 'site-network-access' represents a logical Layer 2 connect rk-access' represents a logical Layer 2 connection to a site. A 'site-network-ac
ion to a site. A 'site-network-access' can thus be mapped to an attachment circu cess' can thus be mapped to an attachment circuit with Layer 2 properties <xref
it with Layer 2 properties <xref target="I-D.ietf-opsawg-teas-attachment-circui target="RFC9834"/>. Similarly, 'vpn-network-access' defined in both <xref targe
t"/>. Similarly, 'vpn-network-access' defined in both <xref target="RFC9182"/> a t="RFC9182"/> and <xref target="RFC9291"/> is mapped to an attachment circuit pe
nd <xref target="RFC9291"/> is mapped to an attachment circuit per <xref target= r <xref target="RFC9834"/> or <xref target="RFC9835"/>.</t>
"I-D.ietf-opsawg-teas-attachment-circuit"/> or <xref target="I-D.ietf-opsawg-ntw <t>As such, ACs created using the "ietf-ac-svc" module <xref target="RFC98
-attachment-circuit"/>.</t> 34"/> can be referenced in other
<t>As such, ACs created using the "ietf-ac-svc" module <xref target="I-D.i VPN-related modules (e.g., LxSM and LxNM). Also, ACs managed using the "ietf-ac-
etf-opsawg-teas-attachment-circuit"/> can be referenced in other ntw" module <xref target="RFC9835"/> can be referenced in VPN-related network mo
VPN-related modules (e.g., LxSM and LxNM). Also, ACs managed using the "ietf-ac- dules (mainly, the LxNM). The required augmentations to that aim are shown in <x
ntw" module <xref target="I-D.ietf-opsawg-ntw-attachment-circuit"/> can be refer ref target="tree"/>.</t>
enced in VPN-related network modules (mainly, the LxNM). The required augmentati
ons to that aim are shown in <xref target="tree"/>.</t>
<figure anchor="tree"> <figure anchor="tree">
<name>AC Glue Tree Structure</name> <name>AC Glue Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-glue module: ietf-ac-glue
augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site
/l2vpn-svc:site-network-accesses: /l2vpn-svc:site-network-accesses:
+--rw ac-svc-ref* ac-svc:attachment-circuit-reference +--rw ac-svc-ref* ac-svc:attachment-circuit-reference
augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site
/l2vpn-svc:site-network-accesses /l2vpn-svc:site-network-accesses
/l2vpn-svc:site-network-access: /l2vpn-svc:site-network-access:
+--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}? +--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}?
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
/l3vpn-svc:site-network-accesses: /l3vpn-svc:site-network-accesses:
+--rw ac-svc-ref* ac-svc:attachment-circuit-reference +--rw ac-svc-ref* ac-svc:attachment-circuit-reference
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
/l3vpn-svc:site-network-accesses /l3vpn-svc:site-network-accesses
/l3vpn-svc:site-network-access: /l3vpn-svc:site-network-access:
+--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}? +--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}?
augment /l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service augment /l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service
/l2nm:vpn-nodes/l2nm:vpn-node/l2nm:vpn-network-accesses: /l2nm:vpn-nodes/l2nm:vpn-node/l2nm:vpn-network-accesses:
+--rw ac-svc-ref* ac-svc:attachment-circuit-reference +--rw ac-svc-ref* ac-svc:attachment-circuit-reference
+--rw ac-ntw-ref* [ac-ref] +--rw ac-ntw-ref* [ac-ref]
+--rw ac-ref leafref +--rw ac-ref leafref
+--rw node-ref? leafref +--rw node-ref? leafref
+--rw network-ref? -> /nw:networks/network/network-id +--rw network-ref? -> /nw:networks/network/network-id
augment /l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service augment /l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service
/l2nm:vpn-nodes/l2nm:vpn-node/l2nm:vpn-network-accesses /l2nm:vpn-nodes/l2nm:vpn-node/l2nm:vpn-network-accesses
/l2nm:vpn-network-access: /l2nm:vpn-network-access:
+--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}? +--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}?
+--rw ac-ntw-ref {ac-glue}? +--rw ac-ntw-ref {ac-glue}?
+--rw ac-ref? leafref +--rw ac-ref? leafref
+--rw node-ref? leafref +--rw node-ref? leafref
+--rw network-ref? -> /nw:networks/network/network-id +--rw network-ref? -> /nw:networks/network/network-id
augment /l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service augment /l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service
/l3nm:vpn-nodes/l3nm:vpn-node/l3nm:vpn-network-accesses: /l3nm:vpn-nodes/l3nm:vpn-node/l3nm:vpn-network-accesses:
+--rw ac-svc-ref* ac-svc:attachment-circuit-reference +--rw ac-svc-ref* ac-svc:attachment-circuit-reference
+--rw ac-ntw-ref* [ac-ref] +--rw ac-ntw-ref* [ac-ref]
+--rw ac-ref leafref +--rw ac-ref leafref
+--rw node-ref? leafref +--rw node-ref? leafref
+--rw network-ref? -> /nw:networks/network/network-id +--rw network-ref? -> /nw:networks/network/network-id
augment /l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service augment /l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service
/l3nm:vpn-nodes/l3nm:vpn-node/l3nm:vpn-network-accesses /l3nm:vpn-nodes/l3nm:vpn-node/l3nm:vpn-network-accesses
/l3nm:vpn-network-access: /l3nm:vpn-network-access:
+--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}? +--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}?
+--rw ac-ntw-ref {ac-glue}? +--rw ac-ntw-ref {ac-glue}?
+--rw ac-ref? leafref +--rw ac-ref? leafref
+--rw node-ref? leafref +--rw node-ref? leafref
+--rw network-ref? -> /nw:networks/network/network-id +--rw network-ref? -> /nw:networks/network/network-id
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>When an AC is referenced within a specific network access, then that AC
information takes precedence over any overlapping information that is also encl <!-- [rfced] We have a couple questions about this paragraph:
osed for this network access.</t>
<ul empty="true"> Original:
<li> This approach is consistent with the design in
<t>This approach is consistent with the design in <xref target="I-D.ie [I-D.ietf-teas-ietf-network-slice-nbi-yang] where an AC service
tf-teas-ietf-network-slice-nbi-yang"/> where an AC service reference, called 'ac reference, called 'ac-svc-name', is used to indicate the names of
-svc-name', is used to indicate the names of AC services. As per <xref target="I AC services. As per [I-D.ietf-teas-ietf-network-slice-nbi-yang],
-D.ietf-teas-ietf-network-slice-nbi-yang"/>, when both 'ac-svc-name' and the att when both 'ac-svc-name' and the attributes of 'attachment-
ributes of 'attachment-circuits' are defined, the 'ac-svc-name' takes precedence circuits' are defined, the 'ac-svc-name' takes precedence.
.</t>
</li> a) [I-D.ietf-teas-ietf-network-slice-nbi-yang] does not appear to contain
</ul> 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, that AC info
rmation takes precedence over any overlapping information that is also enclosed
for this network access.</t>
<t>This approach is consistent with the design in <xref target="I-D.ietf-t
eas-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.i
etf-teas-ietf-network-slice-nbi-yang"/>, when both 'ac-svc-name' and the attribu
tes of 'attachment-circuits' are defined, the 'ac-svc-name' takes precedence.</t
>
<t>The "ietf-ac-glue" module includes provisions to reference ACs within o r outside a VPN network access to accommodate deployment contexts where an AC re ference 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 h ow AC references can be indicated outside individual VPN network access entries. </t> <t>The "ietf-ac-glue" module includes provisions to reference ACs within o r outside a VPN network access to accommodate deployment contexts where an AC re ference 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 h ow AC references can be indicated outside individual VPN network access entries. </t>
</section> </section>
<section anchor="sec-glue"> <section anchor="sec-glue">
<name>The AC Glue ("ietf-ac-glue") YANG Module</name> <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 targe t="RFC9182"/>.</t> <t>This modules augments the L2SM <xref target="RFC8466"/>, the L3SM <xref target="RFC8299"/>, the L2NM <xref target="RFC9291"/>, and the L3NM <xref targe t="RFC9182"/>.</t>
<t>This module uses references defined in <xref target="I-D.ietf-opsawg-te <t>This module uses references defined in <xref target="RFC9834"/> and <xr
as-attachment-circuit"/> and <xref target="I-D.ietf-opsawg-ntw-attachment-circui ef target="RFC9835"/>.</t>
t"/>.</t> <sourcecode type="yang" name="ietf-ac-glue@2025-08-11.yang" markers="true"
<sourcecode type="yang"><![CDATA[ ><![CDATA[
<CODE BEGINS> file "ietf-ac-glue@2025-01-07.yang"
module ietf-ac-glue { module ietf-ac-glue {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ac-glue"; namespace "urn:ietf:params:xml:ns:yang:ietf-ac-glue";
prefix ac-glue; prefix ac-glue;
import ietf-l3vpn-svc { import ietf-l3vpn-svc {
prefix l3vpn-svc; prefix l3vpn-svc;
reference reference
"RFC 8299: YANG Data Model for L3VPN Service Delivery"; "RFC 8299: YANG Data Model for L3VPN Service Delivery";
} }
skipping to change at line 711 skipping to change at line 732
"RFC 9182: A YANG Network Data Model for Layer 3 VPNs"; "RFC 9182: A YANG Network Data Model for Layer 3 VPNs";
} }
import ietf-l2vpn-ntw { import ietf-l2vpn-ntw {
prefix l2nm; prefix l2nm;
reference reference
"RFC 9291: A YANG Network Data Model for Layer 2 VPNs"; "RFC 9291: A YANG Network Data Model for Layer 2 VPNs";
} }
import ietf-ac-svc { import ietf-ac-svc {
prefix ac-svc; prefix ac-svc;
reference reference
"RFC SSSS: YANG Data Models for Bearers and 'Attachment "RFC 9834: YANG Data Models for Bearers and Attachment
Circuits'-as-a-Service (ACaaS)"; Circuits-as-a-Service (ACaaS)";
} }
import ietf-ac-ntw { import ietf-ac-ntw {
prefix ac-ntw; prefix ac-ntw;
reference reference
"RFC NNNN: A Network YANG Data Model for Attachment Circuits"; "RFC 9835: A Network YANG Data Model for Attachment Circuits";
} }
organization organization
"IETF OPSAWG (Operations and Management Area Working Group)"; "IETF OPSAWG (Operations and Management Area Working Group)";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Editor: Mohamed Boucadair Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Richard Roberts Author: Richard Roberts
<mailto:rroberts@juniper.net> <mailto:rroberts@juniper.net>
Author: Samier Barguil Author: Samier Barguil
<mailto:ssamier.barguil_giraldo@nokia.com> <mailto:ssamier.barguil_giraldo@nokia.com>
Author: Oscar Gonzalez de Dios Author: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com>"; <mailto:oscar.gonzalezdedios@telefonica.com>";
description description
"This YANG module defines a YANG model for augmenting the LxSM "This YANG module defines a YANG data model for augmenting the
and the LxNM with attachment circuit references. LxSM and the LxNM with attachment circuit references.
Copyright (c) 2025 IETF Trust and the persons identified as Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC 9836; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2025-01-07 { revision 2025-08-11 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A YANG Data Model for Augmenting VPN Service "RFC 9836: A YANG Data Model for Augmenting VPN Service
and Network Models with Attachment Circuits"; and Network Models with Attachment Circuits";
} }
feature ac-glue { feature ac-glue {
description description
"The VPN implementation supports binding a specific VPN "The VPN implementation supports binding a specific VPN
network access or site access to an attachment circuit."; network access or site access to an attachment circuit.";
} }
grouping single-ac-svc-ref { grouping single-ac-svc-ref {
description description
"A grouping with single reference to a service AC."; "A grouping with a single reference to a service AC.";
leaf ac-svc-ref { leaf ac-svc-ref {
type ac-svc:attachment-circuit-reference; type ac-svc:attachment-circuit-reference;
description description
"A reference to the AC as exposed at the service that was "A reference to the AC as exposed at the service that was
provisioned using the ACaaS module."; provisioned using the ACaaS module.";
} }
} }
grouping single-ac-svc-ntw-ref { grouping single-ac-svc-ntw-ref {
description description
skipping to change at line 827 skipping to change at line 848
network module."; network module.";
uses ac-ntw:attachment-circuit-reference; uses ac-ntw:attachment-circuit-reference;
} }
} }
augment "/l2vpn-svc:l2vpn-svc" augment "/l2vpn-svc:l2vpn-svc"
+ "/l2vpn-svc:sites/l2vpn-svc:site" + "/l2vpn-svc:sites/l2vpn-svc:site"
+ "/l2vpn-svc:site-network-accesses" { + "/l2vpn-svc:site-network-accesses" {
description description
"Augments VPN site network accesses with AC provisioning "Augments VPN site network accesses with AC provisioning
details. Concretely, it binds a site to a set of details. Concretely, it binds a site to a set of
attachment circuits with Layer 2 properties that were attachment circuits with Layer 2 properties that were
created using the ACaaS module."; created using the ACaaS module.";
uses ac-svc-ref; uses ac-svc-ref;
} }
augment "/l2vpn-svc:l2vpn-svc" augment "/l2vpn-svc:l2vpn-svc"
+ "/l2vpn-svc:sites/l2vpn-svc:site" + "/l2vpn-svc:sites/l2vpn-svc:site"
+ "/l2vpn-svc:site-network-accesses" + "/l2vpn-svc:site-network-accesses"
+ "/l2vpn-svc:site-network-access" { + "/l2vpn-svc:site-network-access" {
if-feature "ac-glue"; if-feature "ac-glue";
description description
"Augments VPN site network access with AC provisioning "Augments VPN site network access with AC provisioning
details. Concretely, it glues a 'site-network-access' details. Concretely, it glues a 'site-network-access'
to an attachment circuit with Layer 2 properties that was to an attachment circuit with Layer 2 properties that was
created using the ACaaS module. created using the ACaaS module.
The ACaaS information takes precedence over any overlapping The ACaaS information takes precedence over any overlapping
information that is also provided for a site network access."; information that is also provided for a site network access.";
uses single-ac-svc-ref; uses single-ac-svc-ref;
} }
augment "/l3vpn-svc:l3vpn-svc" augment "/l3vpn-svc:l3vpn-svc"
+ "/l3vpn-svc:sites/l3vpn-svc:site" + "/l3vpn-svc:sites/l3vpn-svc:site"
+ "/l3vpn-svc:site-network-accesses" { + "/l3vpn-svc:site-network-accesses" {
description description
"Augments VPN site network accesses with AC provisioning "Augments VPN site network accesses with AC provisioning
details. Concretely, it binds a site to a set of attachment details. Concretely, it binds a site to a set of attachment
circuits with both Layers 2 and 3 properties that were circuits with both Layer 2 and Layer 3 properties that were
created using the ACaaS module."; created using the ACaaS module.";
uses ac-svc-ref; uses ac-svc-ref;
} }
augment "/l3vpn-svc:l3vpn-svc" augment "/l3vpn-svc:l3vpn-svc"
+ "/l3vpn-svc:sites/l3vpn-svc:site" + "/l3vpn-svc:sites/l3vpn-svc:site"
+ "/l3vpn-svc:site-network-accesses" + "/l3vpn-svc:site-network-accesses"
+ "/l3vpn-svc:site-network-access" { + "/l3vpn-svc:site-network-access" {
if-feature "ac-glue"; if-feature "ac-glue";
description description
"Augments VPN site network access with AC provisioning "Augments VPN site network access with AC provisioning
details. Concretely, it glues a 'site-network-access' to an details. Concretely, it glues a 'site-network-access' to an
attachment circuit with both Layer 2 and Layer 3 properties attachment circuit with both Layer 2 and Layer 3 properties
that was created using the ACaaS module. that was created using the ACaaS module.
The ACaaS information takes precedence over any overlapping The ACaaS information takes precedence over any overlapping
information that is also provided for a site network access."; information that is also provided for a site network access.";
uses single-ac-svc-ref; uses single-ac-svc-ref;
} }
augment "/l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service" augment "/l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service"
+ "/l2nm:vpn-nodes/l2nm:vpn-node" + "/l2nm:vpn-nodes/l2nm:vpn-node"
+ "/l2nm:vpn-network-accesses" { + "/l2nm:vpn-network-accesses" {
description description
"Augments VPN network accesses with both service and network "Augments VPN network accesses with both service and network
AC provisioning details. Concretely, it binds a site to (1) AC provisioning details. Concretely, it binds a site to (1)
a set of attachment circuits with Layer 2 properties that were a set of attachment circuits with Layer 2 properties that were
created using the ACaaS module and (2) a set of attachment created using the ACaaS module and (2) a set of attachment
circuits with Layer 2 properties that were provisioned using circuits with Layer 2 properties that were provisioned using
the AC network model."; the AC network model.";
uses ac-svc-ntw-ref; uses ac-svc-ntw-ref;
} }
augment "/l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service" augment "/l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service"
+ "/l2nm:vpn-nodes/l2nm:vpn-node" + "/l2nm:vpn-nodes/l2nm:vpn-node"
+ "/l2nm:vpn-network-accesses" + "/l2nm:vpn-network-accesses"
+ "/l2nm:vpn-network-access" { + "/l2nm:vpn-network-access" {
if-feature "ac-glue"; if-feature "ac-glue";
description description
"Augments VPN network access with service and network "Augments VPN network access with service and network
references to an AC. Concretely, it glues a VPN network references to an AC. Concretely, it glues a VPN network
access to (1) an attachment circuit with Layer 2 properties access to (1) an attachment circuit with Layer 2 properties
that was created using the ACaaS module and (2) an attachment that was created using the ACaaS module and (2) an attachment
circuit with Layer 2 properties that was created using the AC circuit with Layer 2 properties that was created using the AC
network module. network module.
The AC service and network information takes precedence over The AC service and network information takes precedence over
any overlapping information that is also provided for a VPN any overlapping information that is also provided for a VPN
network access."; network access.";
uses single-ac-svc-ntw-ref; uses single-ac-svc-ntw-ref;
} }
augment "/l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service" augment "/l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service"
+ "/l3nm:vpn-nodes/l3nm:vpn-node" + "/l3nm:vpn-nodes/l3nm:vpn-node"
+ "/l3nm:vpn-network-accesses" { + "/l3nm:vpn-network-accesses" {
description description
"Augments VPN network accesses with both service and network "Augments VPN network accesses with both service and network
AC provisioning details. Concretely, it binds a site to (1) AC provisioning details. Concretely, it binds a site to (1)
a set of attachment circuits with both Layer 2 and Layer 3 a set of attachment circuits with both Layer 2 and Layer 3
properties that were created using the ACaaS module and (2) properties that were created using the ACaaS module and (2)
a set of attachment circuits with both Layer 2 and Layer 3 a set of attachment circuits with both Layer 2 and Layer 3
properties that were provisioned using the AC network model."; properties that were provisioned using the AC network model.";
uses ac-svc-ntw-ref; uses ac-svc-ntw-ref;
} }
augment "/l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service" augment "/l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service"
+ "/l3nm:vpn-nodes/l3nm:vpn-node" + "/l3nm:vpn-nodes/l3nm:vpn-node"
+ "/l3nm:vpn-network-accesses" + "/l3nm:vpn-network-accesses"
+ "/l3nm:vpn-network-access" { + "/l3nm:vpn-network-access" {
if-feature "ac-glue"; if-feature "ac-glue";
description description
"Augments VPN network access with service and network "Augments VPN network access with service and network
references to an AC. Concretely, it glues a VPN network references to an AC. Concretely, it glues a VPN network
access to (1) an attachment circuit with both Layer 2 and access to (1) an attachment circuit with both Layer 2 and
Layer 3 properties that was created using the ACaaS module Layer 3 properties that was created using the ACaaS module
and (2) an attachment circuit with both Layer 2 and Layer 3 and (2) an attachment circuit with both Layer 2 and Layer 3
properties that was created using the AC network module. properties that was created using the AC network module.
The AC service and network information takes precedence over The AC service and network information takes precedence over
any overlapping information that is also provided for a VPN any overlapping information that is also provided for a VPN
network access."; network access.";
uses single-ac-svc-ntw-ref; uses single-ac-svc-ntw-ref;
} }
} }
<CODE ENDS>
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This section is modeled after the template described in <xref section=" <!-- DNE begins --><t>This section is modeled after the template described
3.7" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t> 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 <t>The "ietf-ac-common" YANG module defines a data model that is
designed to be accessed via YANG-based management protocols, such as designed to be accessed via YANG-based management protocols, such as
NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These pr otocols have to NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These pr otocols have to
use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref targ et="RFC8446"/>, and use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref targ et="RFC8446"/>, and
QUIC <xref target="RFC9000"/>) and have to use mutual authentication.</t> QUIC <xref target="RFC9000"/>) and have to use mutual authentication.</t>
<t>The Network Configuration Access Control Model (NACM) <xref target="RFC 8341"/> <t>The Network Configuration Access Control Model (NACM) <xref target="RFC 8341"/>
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.</t> RESTCONF protocol operations and content.</t>
<t>There are a number of data nodes defined in this YANG module that are <t>There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., "config true", which is the
default). These data nodes may be considered sensitive or vulnerable default). All writable data nodes are likely to be reasonably sensitive or v
ulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
and delete operations to these data nodes without proper protection and delete operations to these data nodes without proper protection
or authentication can have a negative effect on network operations. or authentication can have a negative effect on network operations.
Specifically, the following subtrees and data nodes have particular The following subtrees and data nodes have particular
sensitivities/vulnerabilities:</t> sensitivities/vulnerabilities:</t><!-- DNE ends -->
<dl> <dl spacing="normal" newline="false">
<dt>'ac-svc-ref' and 'ac-ntw-ref':</dt> <dt>'ac-svc-ref' and 'ac-ntw-ref':</dt>
<dd> <dd>An attacker who is able to access network nodes can undertake
<t>An attacker who is able to access network nodes can various attacks, such as deleting a running VPN service, interrupting
undertake various attacks, such as deleting a running VPN all the traffic of a client. Specifically, an attacker may modify
service, interrupting all the traffic of a client. Specifically, (including delete) the ACs that are bound to a running service,
an attacker may modify (including delete) the ACs that are bound to a running se leading to malfunctioning of the service and therefore to Service
rvice, leading to Level Agreement (SLA) violations. Such activity can be detected by
malfunctioning of the service and therefore to Service Level adequately monitoring and tracking network configuration changes.
Agreement (SLA) violations.
: Such activity can be detected by adequately monitoring and tracking
network configuration changes.</t>
</dd> </dd>
</dl> </dl>
<t>Some of the readable data nodes in this YANG module may be considered <!-- DNE begins --><t>Some of the readable data nodes in this YANG module
sensitive or vulnerable in some network environments. It is thus may be considered
important to control read access (e.g., via get, get-config, or sensitive or vulnerable in some network environments. It is thus
notification) to these data nodes. Specifically, the following important to control read access (e.g., via get, get-config, or
subtrees and data nodes have particular sensitivities/vulnerabilities:</t> notification) to these data nodes. Specifically, the following subtrees
<dl> and data nodes have particular sensitivities/vulnerabilities:</t><!-- DNE
ends -->
<dl spacing="normal" newline="false">
<dt>'ac-svc-ref' and 'ac-ntw-ref':</dt> <dt>'ac-svc-ref' and 'ac-ntw-ref':</dt>
<dd> <dd><t>These references do not expose privacy-related
<t>These references do not expose per se information per se; however, 'ac-svc-ref' may be used to track the set o
privacy-related information, however 'ac-svc-ref' may be used to track f VPN
the set of VPN instances in which a given customer is involved.</t> instances in which a given customer is involved.</t>
</dd> <t>Note that, unlike 'ac-svc-ref', 'ac-ntw-ref' is unique within the
<dt/> scope of a node and may multiplex many peer CEs.</t>
<dd>
<t>Note that, unlike 'ac-svc-ref', 'ac-ntw-ref' is unique within the s
cope of
a node and may multiplex many peer CEs.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to register the following URI in the "ns" subregistry within <t>IANA has registered the following URI in the "ns" subregistry within
the "IETF XML Registry" <xref target="RFC3688"/>:</t> the "IETF XML Registry" <xref target="RFC3688"/>:</t>
<artwork><![CDATA[ <dl spacing="compact" newline="false">
URI: urn:ietf:params:xml:ns:yang:ietf-ac-glue <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-glue</dd>
Registrant Contact: The IESG. <dt>Registrant Contact:</dt><dd>The IESG.</dd>
XML: N/A; the requested URI is an XML namespace. <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
]]></artwork> </dl>
<t>IANA is requested to register the following YANG module in the "YANG Mo <t>IANA has registered the following YANG module in the "YANG Module
dule
Names" registry <xref target="RFC6020"/> within the "YANG Parameters" registr y group:</t> Names" registry <xref target="RFC6020"/> within the "YANG Parameters" registr y group:</t>
<artwork><![CDATA[ <dl spacing="compact" newline="false">
Name: ietf-ac-glue <dt>Name:</dt><dd>ietf-ac-glue</dd>
Namespace: urn:ietf:params:xml:ns:yang:ietf-ac-glue <dt>Maintained by IANA?</dt><dd>N</dd>
Prefix: ac-glue <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-glue</dd>
Maintained by IANA? N <dt>Prefix:</dt><dd>ac-glue</dd>
Reference: RFC XXXX <dt>Reference:</dt><dd>RFC 9836</dd>
]]></artwork> </dl>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-netmod-rfc8407bis" to="YANG-GUIDELINES"/>
<displayreference target="I-D.ietf-teas-ietf-network-slice-nbi-yang" to="YAN
G-NSS"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="I-D.ietf-opsawg-teas-attachment-circuit">
<front>
<title>YANG Data Models for Bearers and 'Attachment Circuits'-as-a-S
ervice (ACaaS)</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Richard Roberts" initials="R." surname="Roberts">
<organization>Juniper</organization>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O. G." surname="
de Dios">
<organization>Telefonica</organization>
</author>
<author fullname="Samier Barguil" initials="S." surname="Barguil">
<organization>Nokia</organization>
</author>
<author fullname="Bo Wu" initials="B." surname="Wu">
<organization>Huawei Technologies</organization>
</author>
<date day="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 <!-- [RFC9834]
model can be used for the provisioning of ACs before or during in EDIT as of 03/03/25.
service provisioning (e.g., Network Slice Service). -->
<reference anchor="RFC9834" target="https://www.rfc-editor.org/info/rfc9834">
The document also specifies a YANG service model for managing bearers <front>
over which ACs are established. <title>YANG Data Models for Bearers and Attachment Circuits-as-a-Service (
ACaaS)</title>
<author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
e="editor">
<organization>Orange</organization>
</author>
<author initials="R." surname="Roberts" fullname="Richard Roberts" role="e
ditor">
<organization>Juniper</organization>
</author>
<author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez
de Dios">
<organization>Telefonica</organization>
</author>
<author initials="S." surname="Barguil" fullname="Samier Barguil">
<organization>Nokia</organization>
</author>
<author initials="B." surname="Wu" fullname="Bo Wu">
<organization>Huawei Technologies</organization>
</author>
<date month='August' year='2025'/>
</front>
<seriesInfo name="RFC" value="9834"/>
<seriesInfo name="DOI" value="10.17487/RFC9834"/>
</reference>
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 466.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-attach 299.xml"/>
ment-circuit-19"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</reference> 291.xml"/>
<reference anchor="RFC8466"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 182.xml"/>
<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 con
figure a Layer 2 provider-provisioned VPN service. It is up to a management syst
em to take this as an input and generate specific configuration models to config
ure the different network elements to deliver the service. How this configuratio
n of network elements is done is out of scope for this document.</t>
<t>The YANG data model defined in this document includes support f
or point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual P
rivate LAN Services (VPLSs) that use Pseudowires signaled using the Label Distri
bution 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 Ne
twork Management Datastore Architecture defined in RFC 8342.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8466"/>
<seriesInfo name="DOI" value="10.17487/RFC8466"/>
</reference>
<reference anchor="RFC8299">
<front>
<title>YANG Data Model for L3VPN Service Delivery</title>
<author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/>
<author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
<author fullname="L. Tomotaki" initials="L." surname="Tomotaki"/>
<author fullname="K. Ogaki" initials="K." surname="Ogaki"/>
<date month="January" year="2018"/>
<abstract>
<t>This document defines a YANG data model that can be used for co
mmunication between customers and network operators and to deliver a Layer 3 pro
vider-provisioned VPN service. This document is limited to BGP PE-based VPNs as
described in RFCs 4026, 4110, and 4364. This model is intended to be instantiate
d at the management system to deliver the overall service. It is not a configura
tion model to be used directly on network elements. This model provides an abstr
acted view of the Layer 3 IP VPN service configuration components. It will be up
to the management system to take this model as input and use specific configura
tion 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 docum
ent.</t>
<t>This document obsoletes RFC 8049; it replaces the unimplementab
le 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" s
urname="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) serv
ices within a network (e.g., a service provider network). The L2NM complements t
he 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 us
ed 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 se
gments and the initial versions of two IANA-maintained modules that include a se
t 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" s
urname="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 prov
iders, 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 se
rvice provider network. The model provides a network-centric view of L3VPN servi
ces.</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 ne
twork controller/orchestrator.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9182"/>
<seriesInfo name="DOI" value="10.17487/RFC9182"/>
</reference>
<reference anchor="I-D.ietf-opsawg-ntw-attachment-circuit">
<front>
<title>A Network YANG Data Model for Attachment Circuits</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Richard Roberts" initials="R." surname="Roberts">
<organization>Juniper</organization>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O. G." surname="
de Dios">
<organization>Telefonica</organization>
</author>
<author fullname="Samier Barguil" initials="S." surname="Barguil">
<organization>Nokia</organization>
</author>
<author fullname="Bo Wu" initials="B." surname="Wu">
<organization>Huawei Technologies</organization>
</author>
<date day="9" month="January" year="2025"/>
<abstract>
<t> This document specifies a network model for attachment circu
its. 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 <!-- [RFC9835]
Attachment Point (SAP) models with the detailed information for the in EDIT as of 03/03/25.
provisioning of attachment circuits in Provider Edges (PEs). -->
<reference 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" rol
e="editor">
<organization>Orange</organization>
</author>
<author initials="R." surname="Roberts" fullname="Richard Roberts">
<organization>Juniper</organization>
</author>
<author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez
de Dios">
<organization>Telefonica</organization>
</author>
<author initials="S." surname="Barguil" fullname="Samier Barguil">
<organization>Nokia</organization>
</author>
<author initials="B." surname="Wu" fullname="Bo Wu">
<organization>Huawei Technologies</organization>
</author>
<date month='August' year='2025'/>
</front>
<seriesInfo name="RFC" value="9835"/>
<seriesInfo name="DOI" value="10.17487/RFC9835"/>
</reference>
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 342.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ntw-attachm 341.xml"/>
ent-circuit-15"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
</reference> 688.xml"/>
<reference anchor="RFC8342"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 020.xml"/>
<title>Network Management Datastore Architecture (NMDA)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> 241.xml"/>
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwae <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
lder"/> 040.xml"/>
<author fullname="P. Shafer" initials="P." surname="Shafer"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="K. Watsen" initials="K." surname="Watsen"/> 252.xml"/>
<author fullname="R. Wilton" initials="R." surname="Wilton"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="March" year="2018"/> 446.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>Datastores are a fundamental concept binding the data models wr 000.xml"/>
itten in the YANG data modeling language to network management protocols such as
the Network Configuration Protocol (NETCONF) and RESTCONF. This document define
s 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 requ
ires a structured and secure operating environment that promotes human usability
and multi-vendor interoperability. There is a need for standard mechanisms to r
estrict NETCONF or RESTCONF protocol access for particular users to a preconfigu
red 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 st
andards which use Extensible Markup Language (XML) related items such as Namespa
ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew
ork (RDF) Schemas.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference>
<reference anchor="RFC6020">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)</title>
<author fullname="M. Bjorklund" initials="M." role="editor" surname=
"Bjorklund"/>
<date month="October" year="2010"/>
<abstract>
<t>YANG is a data modeling language used to model configuration an
d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON
F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6020"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC8340"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 340.xml"/>
<title>YANG Tree Diagrams</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="L. Berger" initials="L." role="editor" surname="Be
rger"/>
<date month="March" year="2018"/>
<abstract>
<t>This document captures the current syntax used in YANG module t
ree diagrams. The purpose of this document is to provide a single location for t
his definition. This syntax may be updated from time to time based on the evolut
ion of the YANG language.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="215"/>
<seriesInfo name="RFC" value="8340"/>
<seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference>
<reference anchor="I-D.ietf-opsawg-teas-common-ac">
<front>
<title>A Common YANG Data Model for Attachment Circuits</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Richard Roberts" initials="R." surname="Roberts">
<organization>Juniper</organization>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O. G." surname="
de Dios">
<organization>Telefonica</organization>
</author>
<author fullname="Samier Barguil" initials="S." surname="Barguil">
<organization>Nokia</organization>
</author>
<author fullname="Bo Wu" initials="B." surname="Wu">
<organization>Huawei Technologies</organization>
</author>
<date day="23" month="January" year="2025"/>
<abstract>
<t> The document specifies a common attachment circuits (ACs) YA
NG 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> <!-- [RFC9833]
</abstract> draft-ietf-opsawg-teas-common-ac-15
</front> IESG State: RFC Ed Queue as of 03/03/25.
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-common -->
-ac-15"/> <reference anchor="RFC9833" target="https://www.rfc-editor.org/info/rfc9833">
</reference> <front>
<reference anchor="RFC9408"> <title>A Common YANG Data Model for Attachment Circuits</title>
<front> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
<title>A YANG Network Data Model for Service Attachment Points (SAPs e="editor">
)</title> <organization>Orange</organization>
<author fullname="M. Boucadair" initials="M." role="editor" surname= </author>
"Boucadair"/> <author initials="R." surname="Roberts" fullname="Richard Roberts" role="e
<author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzal ditor">
ez de Dios"/> <organization>Juniper</organization>
<author fullname="S. Barguil" initials="S." surname="Barguil"/> </author>
<author fullname="Q. Wu" initials="Q." surname="Wu"/> <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez
<author fullname="V. Lopez" initials="V." surname="Lopez"/> de Dios">
<date month="June" year="2023"/> <organization>Telefonica</organization>
<abstract> </author>
<t>This document defines a YANG data model for representing an abs <author initials="S." surname="Barguil" fullname="Samier Barguil">
tract view of the provider network topology that contains the points from which <organization>Nokia</organization>
its services can be attached (e.g., basic connectivity, VPN, network slices). Al </author>
so, the model can be used to retrieve the points where the services are actually <author initials="B." surname="Wu" fullname="Bo Wu">
being delivered to customers (including peer networks).</t> <organization>Huawei Technologies</organization>
<t>This document augments the 'ietf-network' data model defined in </author>
RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs ar <date month="August" year="2025" />
e the network reference points to which network services, such as Layer 3 Virtua </front>
l Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be att <seriesInfo name="RFC" value="9833"/>
ached. One or multiple services can be bound to the same SAP. Both User-to-Netwo <seriesInfo name="DOI" value="10.17487/RFC9833"/>
rk Interface (UNI) and Network-to-Network Interface (NNI) are supported in the S </reference>
AP data model.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9408"/>
<seriesInfo name="DOI" value="10.17487/RFC9408"/>
</reference>
<reference anchor="RFC7665">
<front>
<title>Service Function Chaining (SFC) Architecture</title>
<author fullname="J. Halpern" initials="J." role="editor" surname="H
alpern"/>
<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 con
struction of composite services through deployment of SFCs, with a focus on thos
e to be standardized in the IETF. This document does not propose solutions, prot
ocols, 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 ma
y use an IP backbone to provide IP Virtual Private Networks (VPNs) for its custo
mers. 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 router
s at different sites do not peer with each other. Data packets are tunneled thro
ugh 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</tit
le>
<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> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</abstract> 408.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network- 665.xml"/>
slice-nbi-yang-18"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</reference> 364.xml"/>
<reference anchor="I-D.ietf-netmod-rfc8407bis">
<front>
<title>Guidelines for Authors and Reviewers of Documents Containing
YANG Data Models</title>
<author fullname="Andy Bierman" initials="A." surname="Bierman">
<organization>YumaWorks</organization>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
</author>
<date day="14" month="January" year="2025"/>
<abstract>
<t> This memo provides guidelines for authors and reviewers of
specifications containing YANG modules, including IANA-maintained
modules. Recommendations and procedures are defined, which are
intended to increase interoperability and usability of Network
Configuration Protocol (NETCONF) and RESTCONF protocol
implementations that utilize YANG modules. This document obsoletes
RFC 8407.
Also, this document updates RFC 8126 by providing additional <!-- [I-D.ietf-teas-ietf-network-slice-nbi-yang]
guidelines for writing the IANA considerations for RFCs that specify draft-ietf-teas-ietf-network-slice-nbi-yang-22
IANA-maintained modules. The document also updates RFC 6020 by IESG State: IESG Evaluation as of 03/03/25.
clarifying how modules and their revisions are handled by IANA. -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-teas-ietf-network-slice-nbi-yang.xml"/>
</t> <!-- [I-D.ietf-netmod-rfc8407bis]
</abstract> draft-ietf-netmod-rfc8407bis-22
</front> IESG State: IESG State: Publication Requested as of 03/03/25.
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis- -->
22"/> <reference anchor="I-D.ietf-netmod-rfc8407bis" target="https://datatracker.ietf.
</reference> org/doc/html/draft-ietf-netmod-rfc8407bis-22">
<reference anchor="RFC6241"> <front>
<front> <title>Guidelines for Authors and Reviewers of Documents Containing YANG D
<title>Network Configuration Protocol (NETCONF)</title> ata Models</title>
<author fullname="R. Enns" initials="R." role="editor" surname="Enns <author initials="A." surname="Bierman" fullname="Andy Bierman">
"/> <organization>YumaWorks</organization>
<author fullname="M. Bjorklund" initials="M." role="editor" surname= </author>
"Bjorklund"/> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn e="editor">
ame="Schoenwaelder"/> <organization>Orange</organization>
<author fullname="A. Bierman" initials="A." role="editor" surname="B </author>
ierman"/> <author initials="Q." surname="Wu" fullname="Qin Wu">
<date month="June" year="2011"/> <organization>Huawei</organization>
<abstract> </author>
<t>The Network Configuration Protocol (NETCONF) defined in this do <date month="January" day="14" year="2025" />
cument provides mechanisms to install, manipulate, and delete the configuration </front>
of network devices. It uses an Extensible Markup Language (XML)-based data encod <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis-22" />
ing for the configuration data as well as the protocol messages. The NETCONF pro </reference>
tocol operations are realized as remote procedure calls (RPCs). This document ob
soletes RFC 4741. [STANDARDS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</abstract> 664.xml"/>
</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 c
oncepts 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="L
onvick"/>
<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, a
nd host-based client authentication methods. Additional authentication methods a
re described in separate documents. The SSH authentication protocol runs on top
of the SSH transport layer protocol and provides a single authenticated tunnel f
or 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</titl
e>
<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 Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</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="I
yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<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 communica
tion, low-latency connection establishment, and network path migration. QUIC inc
ludes security measures that ensure confidentiality, integrity, and availability
in a range of deployment circumstances. Accompanying documents describe the int
egration 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)</titl
e>
<author fullname="L. Andersson" initials="L." role="editor" surname=
"Andersson"/>
<author fullname="E. Rosen" initials="E." role="editor" surname="Ros
en"/>
<date month="September" year="2006"/>
<abstract>
<t>This document provides a framework for Layer 2 Provider Provisi
oned Virtual Private Networks (L2VPNs). This framework is intended to aid in sta
ndardizing protocols and mechanisms to support interoperable L2VPNs. This memo p
rovides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4664"/>
<seriesInfo name="DOI" value="10.17487/RFC4664"/>
</reference>
</references> </references>
</references> </references>
<?line 675?>
<section anchor="sec-example"> <section anchor="sec-example">
<name>Examples</name> <name>Examples</name>
<section anchor="ref-within-access"> <section anchor="ref-within-access">
<name>A Service AC Reference within The VPN Network Access</name> <name>A Service AC Reference Within the VPN Network Access</name>
<t>Let us consider the example depicted in <xref target="ex-vpws"/> whic <t>Let us consider the example depicted in <xref target="ex-vpws"/>, whi
h is inspired from <xref section="2.1" sectionFormat="of" target="RFC4664"/>. Ea ch is inspired from <xref section="2.1" sectionFormat="of" target="RFC4664"/>. E
ch PE is servicing two CEs. Let us also assume that the service references to id ach PE is servicing two CEs. Let us also assume that the service references to i
entify attachment circuits with these CEs are shown in the figure.</t> dentify attachment circuits with these CEs are shown in <xref target="ex-vpws"/>
.</t>
<figure anchor="ex-vpws"> <figure anchor="ex-vpws">
<name>VPWS Topology Example</name> <name>VPWS Topology Example</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="240" width="464" viewBox="0 0 464 240" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="240" width="464" viewBox="0 0 464 240" class="diagr am" 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,48 L 8,96" fill="none" stroke="black"/>
<path d="M 8,176 L 8,224" 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,32 L 56,80" fill="none" stroke="black"/>
<path d="M 56,160 L 56,208" 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,64 L 80,96" fill="none" stroke="black"/>
<path d="M 80,160 L 80,192" fill="none" stroke="black"/> <path d="M 80,160 L 80,192" fill="none" stroke="black"/>
skipping to change at line 1739 skipping to change at line 1459
} }
] ]
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="ref-outside-access"> <section anchor="ref-outside-access">
<name>Network and Service AC References</name> <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 bear ers to attach these CEs to the service provider network are already in place. Re ferences to identify these bearers are shown in the figure.</t> <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 bear ers to attach these CEs to the service provider network are already in place. Re ferences to identify these bearers are shown in <xref target="ex-topo"/>.</t>
<figure anchor="ex-topo"> <figure anchor="ex-topo">
<name>Topology Example</name> <name>Topology Example</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="128" width="488" viewBox="0 0 488 128" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="128" width="488" viewBox="0 0 488 128" class="diagr am" 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 8,64 L 8,80" fill="none" stroke="black"/>
<path d="M 48,48 L 48,64" 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 80,72 L 80,96" fill="none" stroke="black"/>
<path d="M 104,32 L 104,80" 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 152,32 L 152,80" fill="none" stroke="black"/>
<path d="M 184,32 L 184,112" fill="none" stroke="black"/> <path d="M 184,32 L 184,112" fill="none" stroke="black"/>
skipping to change at line 1802 skipping to change at line 1522
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
.-----. .--------------. .-----. .-----. .--------------. .-----.
.---. | PE1 +===+ +===+ PE2 | .---. .---. | PE1 +===+ +===+ PE2 | .---.
| CE1+------+"450"| | MPLS | |"451"+------+ CE2| | CE1+------+"450"| | MPLS | |"451"+------+ CE2|
'---' ^ '-----' | | '-----' ^ '---' '---' ^ '-----' | | '-----' ^ '---'
| | Core | | | | Core | |
Bearer:1234 '--------------' Bearer:5678 Bearer:1234 '--------------' Bearer:5678
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>The AC service model <xref target="I-D.ietf-opsawg-teas-attachment-ci rcuit"/> can be used by the provider to manage and expose the ACs over existing bearers as shown in <xref target="ex-ac"/>.</t> <t>The AC service model <xref target="RFC9834"/> can be used by the prov ider to manage and expose the ACs over existing bearers as shown in <xref target ="ex-ac"/>.</t>
<figure anchor="ex-ac"> <figure anchor="ex-ac">
<name>ACs Created Using ACaaS</name> <name>ACs Created Using ACaaS</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-ac-svc:attachment-circuits": { "ietf-ac-svc:attachment-circuits": {
"ac-group-profile": [ "ac-group-profile": [
{ {
"name": "an-ac-profile", "name": "an-ac-profile",
"l2-connection": { "l2-connection": {
"encapsulation": { "encapsulation": {
skipping to change at line 1877 skipping to change at line 1597
], ],
"l2-connection": { "l2-connection": {
"bearer-reference": "5678" "bearer-reference": "5678"
} }
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>Let us now consider that the customer wants to request a VPLS instanc e between the sites as shown in <xref target="ex-vpls"/>.</t> <t>Let us now consider that the customer wants to request a Virtual Priv ate LAN Service (VPLS) instance between the sites as shown in <xref target="ex-v pls"/>.</t>
<figure anchor="ex-vpls"> <figure anchor="ex-vpls">
<name>Example of VPLS</name> <name>Example of VPLS</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="160" width="488" viewBox="0 0 488 160" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="160" width="488" viewBox="0 0 488 160" class="diagr am" 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 8,96 L 8,112" fill="none" stroke="black"/>
<path d="M 48,80 L 48,96" 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 80,104 L 80,128" fill="none" stroke="black"/>
<path d="M 104,64 L 104,112" 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 152,64 L 152,112" fill="none" stroke="black"/>
<path d="M 184,64 L 184,144" fill="none" stroke="black"/> <path d="M 184,64 L 184,144" fill="none" stroke="black"/>
skipping to change at line 1950 skipping to change at line 1670
.-----. .--------------. .-----. .-----. .--------------. .-----.
.---. AC1 | PE1 +===+ +===+ PE2 | AC2 .---. .---. AC1 | PE1 +===+ +===+ PE2 | AC2 .---.
| CE1+------+"450"| | MPLS | |"451"+------+ CE2| | CE1+------+"450"| | MPLS | |"451"+------+ CE2|
'---' ^ '-----' | | '-----' ^ '---' '---' ^ '-----' | | '-----' ^ '---'
| | Core | | | | Core | |
Bearer:1234 '--------------' Bearer:5678 Bearer:1234 '--------------' Bearer:5678
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>To that aim, existing ACs are referenced during the creation of the V PLS instance using the L2NM <xref target="RFC9291"/> and the "ietf-ac-glue" as s hown in <xref target="ex-vpls-req"/>.</t> <t>To that aim, existing ACs are referenced during the creation of the V PLS instance using the L2NM <xref target="RFC9291"/> and the "ietf-ac-glue" modu le as shown in <xref target="ex-vpls-req"/>.</t>
<figure anchor="ex-vpls-req"> <figure anchor="ex-vpls-req">
<name>Example of a VPLS Request Using L2NM and AC Glue (Message Body)< /name> <name>Example of a VPLS Request Using L2NM and AC Glue (Message Body)< /name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-l2vpn-ntw:l2vpn-ntw": { "ietf-l2vpn-ntw:l2vpn-ntw": {
"vpn-services": { "vpn-services": {
"vpn-service": [ "vpn-service": [
{ {
"vpn-id": "1543", "vpn-id": "1543",
"vpn-name": "CORPO-EXAMPLE", "vpn-name": "CORPO-EXAMPLE",
skipping to change at line 2077 skipping to change at line 1797
"sap-status":{ "sap-status":{
"status":"ietf-vpn-common:op-up" "status":"ietf-vpn-common:op-up"
} }
} }
] ]
} }
] ]
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>The response in <xref target="ex-sap-query"/> indicates that the VPLS <t>The response in <xref target="ex-sap-query"/> indicates that the VPLS
service can be delivered to CE1. <xref target="I-D.ietf-opsawg-ntw-attachment-c service can be delivered to CE1.
ircuit"/> can be also used to access AC-related details that are bound to the ta
rget SAP (<xref target="ex-acntw-query-2"/>).</t> <!--[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).
-->
<xref target="RFC9835"/> can be also used to access AC-related details th
at are bound to the target SAP (<xref target="ex-acntw-query-2"/>).</t>
<figure anchor="ex-acntw-query-2"> <figure anchor="ex-acntw-query-2">
<name>Example of AC Network Response with SAP (Message Body)</name> <name>Example of AC Network Response with SAP (Message Body)</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-sap-ntw:service":[ "ietf-sap-ntw:service":[
{ {
"service-type":"ietf-vpn-common:vpls", "service-type":"ietf-vpn-common:vpls",
"sap":[ "sap":[
{ {
"sap-id":"sap#1", "sap-id":"sap#1",
skipping to change at line 2124 skipping to change at line 1859
"network-ref":"example:an-id" "network-ref":"example:an-id"
} }
] ]
} }
] ]
} }
] ]
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>The provisioned AC at PE1 can be retrieved using the AC network model <xref target="I-D.ietf-opsawg-ntw-attachment-circuit"/> as depicted in <xref ta rget="ex-acntw-query"/>.</t> <t>The provisioned AC at PE1 can be retrieved using the AC network model <xref target="RFC9835"/> as depicted in <xref target="ex-acntw-query"/>.</t>
<figure anchor="ex-acntw-query"> <figure anchor="ex-acntw-query">
<name>Example of AC Network Response (Message Body)</name> <name>Example of AC Network Response (Message Body)</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-ac-ntw:ac":[ "ietf-ac-ntw:ac":[
{ {
"name":"ac-11", "name":"ac-11",
"svc-ref":"ac-1", "svc-ref":"ac-1",
"peer-sap-id":[ "peer-sap-id":[
"ce-1" "ce-1"
skipping to change at line 2193 skipping to change at line 1928
} }
} }
] ]
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>Thanks to Bo Wu and Qin Wu for the review and comments.</t> <t>Thanks to <contact fullname="Bo Wu"/> and <contact fullname="Qin Wu"/>
<t>Thanks to Martin Björklund for the yangdoctors review, Gyan Mishra for for the review and comments.</t>
the rtg-dir review, Ron Bonica for the opsdir review, <t>Thanks to <contact fullname="Martin Björklund"/> for the YANG Doctors
Reese Enghardt for the genart review, and Prachi Jain for the sec-dir review.</t review, <contact fullname="Gyan Mishra"/> for the RTGDIR review,
> <contact fullname="Ron Bonica"/> for the OPSDIR review, <contact fullname=
<t>Thanks to Mahesh Jethanandani for the AD review.</t> "Reese Enghardt"/>
<t>Thanks to Gunter Van de Velde for the IESG review.</t> for the GENART review, and <contact fullname="Prachi Jain"/> for the SECDI
R review.</t>
<t>Thanks to <contact fullname="Mahesh Jethanandani"/> for the AD review.<
/t>
<t>Thanks to <contact fullname="Gunter Van de Velde"/> for the IESG review
.</t>
</section> </section>
</back> </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> </rfc>
 End of changes. 86 change blocks. 
1035 lines changed or deleted 441 lines changed or added

This html diff was produced by rfcdiff 1.48.