rfc9835.original.xml   rfc9835.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-ntw-attachment-circuit-16" number="9835" category="std" consensus="
6) --> true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" ver
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft sion="3" updates="" obsoletes="" xml:lang="en">
-ietf-opsawg-ntw-attachment-circuit-16" category="std" consensus="true" submissi
onType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.25.0 -->
<front> <front>
<title abbrev="A YANG Network Model for ACs">A Network YANG Data Model for A ttachment Circuits</title> <title abbrev="A YANG Network Model for ACs">A Network YANG Data Model for A ttachment Circuits</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ntw-attachment-ci <seriesInfo name="RFC" value="9835"/>
rcuit-16"/> <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="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>
<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="Bo Wu"> <author fullname="Bo Wu" initials="B" surname="Wu">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<email>lana.wubo@huawei.com</email> <email>lana.wubo@huawei.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>Operations and Management Area Working Group</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 95?>
<t>This document specifies a network model for attachment circuits. The model ca <abstract>
n be used for the provisioning of attachment circuits prior or during service pr <t>This document specifies a network model for attachment circuits. The model ca
ovisioning (e.g., VPN, Network Slice Service). A companion service model is spec n be used for the provisioning of attachment circuits prior to or during service
ified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service provisioning (e.g., VPN, Network Slice Service). A companion service model is s
(ACaaS) (I-D.ietf-opsawg-teas-attachment-circuit).</t> pecified in "YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service
(ACaaS)" (RFC9834).</t>
<t>The module augments the base network ('ietf-network') and the Service A ttachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs).</t> <t>The module augments the base network ('ietf-network') and the Service A ttachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs).</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 101?> <?line 101?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Connectivity services are provided by networks to customers via <t>Connectivity services are provided by networks to customers via
dedicated terminating points, such as Service Functions <xref target="RFC7665 "/>, dedicated terminating points, such as Service Functions <xref target="RFC7665 "/>,
customer edges (CEs), peer Autonomous System Border Routers (ASBRs), Customer Edges (CEs), peer Autonomous System Border Routers (ASBRs),
data centers gateways, or Internet Exchange Points.</t> data center gateways, or Internet Exchange Points.</t>
<t>The procedure to provision a service in a service provider network may <t>The procedure to provision a service in a service provider network may
depend on the practices adopted by a service provider, including the flow put in depend on the practices adopted by a service provider, including the flow put in
place for the provisioning of advanced network services and how they are bound place for the provisioning of advanced network services and how they are bound
to an attachment circuit (AC). For example, the same attachment circuit may host to an attachment circuit (AC). For example, the same attachment circuit may host
multiple services (e.g., Layer 2 Virtual Private Network (VPN), or Layer 3 VPN, multiple services (e.g., Layer 2 VPN (L2VPN), Layer 3 VPN (L3VPN), or Network S
or Network Slice Service <xref target="RFC9543"/>). In order to avoid service i lice Service <xref target="RFC9543"/>). In order to avoid service interference a
nterference and redundant information in various locations, a service provider m nd redundant information in various locations, a service provider may expose an
ay expose an interface to manage ACs network-wide. Customers can then request a interface to manage ACs network-wide. Customers can then request a standalone at
standalone attachment circuit to be put in place, and then refer to that attachm tachment circuit to be put in place and refer to that attachment circuit when r
ent circuit when requesting services to be bound to that AC. <xref target="I-D.i equesting services to be bound to that AC. <xref target="RFC9834"/> specifies a
etf-opsawg-teas-attachment-circuit"/> specifies a data model for managing attach data model for managing Attachment Circuits as a Service (ACaaS).</t>
ment circuits as a service.</t> <t><xref target="sec-module"/> specifies a network model for attachment ci
<t><xref target="sec-module"/> specifies a network model for attachment ci rcuits ("ietf-ac-ntw"). The model can be used for the provisioning of ACs in a p
rcuits ("ietf-ac-ntw"). The model can be used for the provisioning of ACs in a p rovider network prior to or during service provisioning. For example, <xref targ
rovider network prior or during service provisioning. For example, <xref target= et="RFC9836"/> specifies augmentations to the L2VPN Network Model (L2NM) <xref t
"I-D.ietf-opsawg-ac-lxsm-lxnm-glue"/> specifies augmentations to the L2VPN Netwo arget="RFC9291"/> and the L3VPN Network Model (L3NM) <xref target="RFC9182"/> to
rk Model (L2NM) <xref target="RFC9291"/> and the L3VPN Network Model (L3NM) <xre bind LxVPNs to ACs that are provisioned using the procedure defined in this doc
f target="RFC9182"/> to bind LxVPNs to ACs that are provisioned using the proced ument.</t>
ure defined in this document.</t> <t>This document leverages <xref target="RFC9182"/> and <xref target="RFC9
<t>The document leverages <xref target="RFC9182"/> and <xref target="RFC92 291"/> by adopting an AC provisioning structure that uses data nodes that are de
91"/> by adopting an AC provisioning structure that uses data nodes that are def fined in those RFCs. Some refinements were introduced to cover not only conventi
ined in those RFCs. Some refinements were introduced to cover not only conventio onal service provider networks but also specifics of other target deployments (e
nal service provider networks, but also specifics of other target deployments (e .g., cloud network).</t>
.g., cloud network).</t>
<t>The AC network model is designed as augmentations of both the 'ietf-net work' model <xref target="RFC8345"/> and the Service Attachment Point (SAP) mode l <xref target="RFC9408"/>. An attachment circuit can be bound to a single or mu ltiple SAPs. Likewise, the model is designed to accommodate deployments where a SAP can be bound to one or multiple ACs (e.g., a parent AC and its child ACs).</ t> <t>The AC network model is designed as augmentations of both the 'ietf-net work' model <xref target="RFC8345"/> and the Service Attachment Point (SAP) mode l <xref target="RFC9408"/>. An attachment circuit can be bound to a single or mu ltiple SAPs. Likewise, the model is designed to accommodate deployments where a SAP can be bound to one or multiple ACs (e.g., a parent AC and its child ACs).</ t>
<figure anchor="sap-ac-ntw"> <figure anchor="sap-ac-ntw">
<name>Attachment Circuits Examples</name> <name>Attachment Circuits Examples</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="496" width="536" viewBox="0 0 536 496" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="496" width="536" viewBox="0 0 536 496" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
<path d="M 8,240 L 8,256" fill="none" stroke="black"/> <path d="M 8,240 L 8,256" fill="none" stroke="black"/>
<path d="M 40,224 L 40,240" fill="none" stroke="black"/> <path d="M 40,224 L 40,240" fill="none" stroke="black"/>
<path d="M 80,176 L 80,224" fill="none" stroke="black"/> <path d="M 80,176 L 80,224" fill="none" stroke="black"/>
<path d="M 80,256 L 80,272" fill="none" stroke="black"/> <path d="M 80,256 L 80,272" fill="none" stroke="black"/>
<path d="M 80,304 L 80,400" fill="none" stroke="black"/> <path d="M 80,304 L 80,400" fill="none" stroke="black"/>
skipping to change at line 277 skipping to change at line 268
| .-. | | .-. .-. .-. | | .-. | | .-. .-. .-. |
'-------------+sap+-' '-+sap+-+sap+-+sap+-' '-------------+sap+-' '-+sap+-+sap+-+sap+-'
'+' '+' '+' '+' '+' '+' '+' '+'
|ac | |ac |ac |ac | |ac |ac
.+-. | .+-. | .+-. | .+-. |
|CE3+-----ac-----' |CE4+---' |CE3+-----ac-----' |CE4+---'
'--' '--' '--' '--'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>The AC network model uses the AC common model defined in <xref target=" I-D.ietf-opsawg-teas-common-ac"/>.</t> <t>The AC network model uses the AC common model defined in <xref target=" RFC9833"/>.</t>
<t>The YANG 1.1 <xref target="RFC7950"/> data model in this document confo rms to the Network Management Datastore Architecture (NMDA) defined in <xref tar get="RFC8342"/>.</t> <t>The YANG 1.1 <xref target="RFC7950"/> data model in this document confo rms to the Network Management Datastore Architecture (NMDA) defined in <xref tar get="RFC8342"/>.</t>
<t>Sample examples are provided in <xref target="sec-examples"/>.</t> <t>Some examples are provided in <xref target="sec-examples"/>.</t>
<section anchor="editorial-note-to-be-removed-by-rfc-editor">
<name>Editorial Note (To be removed by RFC Editor)</name>
<t>Note to the RFC Editor: This section is to be removed prior to 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>CCCC --&gt; the assigned RFC number for <xref target="I-D.ietf-op
sawg-teas-common-ac"/></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>XXXX --&gt; the assigned RFC number for this I-D</t>
</li>
<li>
<t>2025-01-07 --&gt; the actual date of the publication of this 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 key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
<t>The reader should be familiar with the terms defined in <xref section="2" sec </t>
tionFormat="of" target="RFC9408"/>.</t> <t>The reader should be familiar with the terms defined in <xref section="
2" sectionFormat="of" target="RFC9408"/>.</t>
<t>This document uses the term "network model" as defined in <xref section ="2.1" sectionFormat="of" target="RFC8969"/>.</t> <t>This document uses the term "network model" as defined in <xref section ="2.1" sectionFormat="of" target="RFC8969"/>.</t>
<t>The meanings of the symbols in the YANG tree diagrams are defined in <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>LxSM refers to both the Layer 2 Service Model (L2SM) <xref target="RFC8 466"/> and the Layer 3 Service Model (L3SM) <xref target="RFC8299"/>.</t> <t>LxSM refers to both the Layer 2 Service Model (L2SM) <xref target="RFC8 466"/> and the Layer 3 Service Model (L3SM) <xref target="RFC8299"/>.</t>
<t>LxNM refers to both the L2VPN Network Model (L2NM) <xref target="RFC929 1"/> and the L3VPN Network Model (L3NM) <xref target="RFC9182"/>.</t> <t>LxNM refers to both the L2VPN Network Model (L2NM) <xref target="RFC929 1"/> and the L3VPN Network Model (L3NM) <xref target="RFC9182"/>.</t>
<t>LxVPN refers to both L2VPN and L3VPN.</t> <t>LxVPN refers to both L2VPN and L3VPN.</t>
<t>The following are used in the module prefixes:</t> <t>The following are used in the module prefixes:</t>
<dl> <dl spacing="normal" newline="false">
<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>sap:</dt> <dt>sap:</dt>
<dd> <dd>
<t>Service Attchment Point</t> <t>Service Attachment Point</t>
</dd> </dd>
<dt>svc:</dt> <dt>svc:</dt>
<dd> <dd>
<t>Service</t> <t>Service</t>
</dd> </dd>
</dl> </dl>
<t>In addition, this document uses the following terms:</t> <t>In addition, this document uses the following terms:</t>
<dl> <dl spacing="normal" newline="false">
<dt>Bearer:</dt> <dt>Bearer:</dt>
<dd> <dd>
<t>A physical or logical link that connects a customer node (or site) to a provider network.</t> <t>A physical or logical link that connects a customer node (or site) to a provider network.</t>
</dd>
<dt/>
<dd>
<t>A bearer can be a wireless or wired link. One or multiple technolog ies can be used to build a bearer. The bearer type can be specified by a custome r.</t> <t>A bearer can be a wireless or wired link. One or multiple technolog ies can be used to build a bearer. The bearer type can be specified by a custome r.</t>
</dd>
<dt/>
<dd>
<t>The operator allocates a unique bearer reference to identify a bear er within its network (e.g., customer line identifier). Such a reference can be retrieved by a customer and then used in subsequent service placement requests t o unambiguously identify where a service is to be bound.</t> <t>The operator allocates a unique bearer reference to identify a bear er within its network (e.g., customer line identifier). Such a reference can be retrieved by a customer and then used in subsequent service placement requests t o unambiguously identify where a service is to be bound.</t>
</dd> <t>The concept of a bearer can be generalized to refer to the required
<dt/> underlying connection for the provisioning of an attachment circuit.</t>
<dd>
<t>The concept of bearer can be generalized to refer to the required u
nderlying connection for the provisioning of an attachment circuit.</t>
</dd>
<dt/>
<dd>
<t>One or multiple attachment circuits may be hosted over the same bea rer (e.g., multiple Virtual Local Area Networks (VLANs) on the same bearer that is provided by a physical link).</t> <t>One or multiple attachment circuits may be hosted over the same bea rer (e.g., multiple Virtual Local Area Networks (VLANs) on the same bearer that is provided by a physical link).</t>
</dd> </dd>
<dt>Network controller:</dt> <dt>Network controller:</dt>
<dd> <dd>
<t>Denotes a functional entity responsible for the management of the s ervice provider network. One or multiple network controllers can be deployed in a service provider network.</t> <t>Denotes a functional entity responsible for the management of the s ervice provider network. One or multiple network controllers can be deployed in a service provider network.</t>
</dd> </dd>
<dt>Service orchestrator:</dt> <dt>Service orchestrator:</dt>
<dd> <dd>
<t>Refers to a functional entity that interacts with the customer of a network service.</t> <t>Refers to a functional entity that interacts with the customer of a network service.</t>
</dd>
<dt/>
<dd>
<t>A service orchestrator is typically responsible for the attachment circuits, the Provider Edge (PE) selection, and requesting the activation of the requested services to a network controller.</t> <t>A service orchestrator is typically responsible for the attachment circuits, the Provider Edge (PE) selection, and requesting the activation of the requested services to a network controller.</t>
</dd>
<dt/>
<dd>
<t>A service orchestrator may interact with one or more network contro llers.</t> <t>A service orchestrator may interact with one or more network contro llers.</t>
</dd> </dd>
<dt>Service provider network:</dt> <dt>Service provider network:</dt>
<dd> <dd>
<t>A network that is able to provide network services (e.g., LxVPN or Network Slice Services).</t> <t>A network that is able to provide network services (e.g., LxVPN or Network Slice Services).</t>
</dd> </dd>
<dt>Service provider:</dt> <dt>Service provider:</dt>
<dd> <dd>
<t>An entity that offers network services (e.g., LxVPN or Network Slic e Services).</t> <t>An entity that offers network services (e.g., LxVPN or Network Slic e Services).</t>
</dd> </dd>
skipping to change at line 396 skipping to change at line 352
<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-common</td> <td align="left">ac-common</td>
<td align="left">ietf-ac-common</td> <td align="left">ietf-ac-common</td>
<td align="left">RFC CCCC</td> <td align="left"><xref target="RFC9833"/></td>
</tr> </tr>
<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 section="5.2" target="RFC9834"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">dot1q-types</td> <td align="left">dot1q-types</td>
<td align="left">ieee802-dot1q-types</td> <td align="left">ieee802-dot1q-types</td>
<td align="left"> <td align="left">
<xref target="IEEE802.1Qcp"/></td> <xref target="IEEE802.1Qcp"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">if</td> <td align="left">if</td>
<td align="left">ietf-interfaces</td> <td align="left">ietf-interfaces</td>
skipping to change at line 471 skipping to change at line 427
<xref target="RFC9181"/></td> <xref target="RFC9181"/></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="sec-module"/>)</t> <t>"ietf-ac-ntw" (<xref target="sec-module"/>)</t>
</li> </li>
<li> <li>
<t>"ietf-ac-glue" (<xref target="I-D.ietf-opsawg-ac-lxsm-lxnm-glue"/>) </t> <t>"ietf-ac-glue" <xref target="RFC9836"/></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"/>
<path d="M 56,80 L 56,112" fill="none" stroke="black"/> <path d="M 56,80 L 56,112" fill="none" stroke="black"/>
<path d="M 72,144 L 72,176" fill="none" stroke="black"/> <path d="M 72,144 L 72,176" fill="none" stroke="black"/>
<path d="M 144,48 L 144,80" fill="none" stroke="black"/> <path d="M 144,48 L 144,80" fill="none" stroke="black"/>
skipping to change at line 559 skipping to change at line 515
<section anchor="sample-uses-of-the-attachment-circuit-data-models"> <section anchor="sample-uses-of-the-attachment-circuit-data-models">
<name>Sample Uses of the Attachment Circuit Data Models</name> <name>Sample Uses of the Attachment Circuit 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 a sample target topology that involve ACs :</t> <t><xref target="uc"/> depicts a sample target topology that involve ACs :</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>ACs are terminated by a SAP at the network side. See <xref target ="sap-ac-ntw"/> for an example of SAPs within a PE.</t> <t>ACs are terminated by a SAP at the network side. See <xref target ="sap-ac-ntw"/> for an example of SAPs within a PE.</t>
</li> </li>
<li> <li>
<t>A CE can be either a physical device or a logical entity. Such lo gical entity is typically a software component (e.g., a virtual service function that is hosted within the provider's network or a third-party infrastructure). A CE is seen by the network as a peer SAP <xref target="RFC9408"/>.</t> <t>A CE can be either a physical device or a logical entity. Such a logical entity is typically a software component (e.g., a virtual Service Functi on that is hosted within the provider's network or a third-party infrastructure) . A CE is seen by the network as a peer SAP <xref target="RFC9408"/>.</t>
</li> </li>
<li> <li>
<t>CEs may be either dedicated to one single connectivity service or host multiple connectivity services (e.g., CEs with roles of service functions <xref target="RFC7665"/>).</t> <t>CEs may be either dedicated to one single connectivity service or host multiple connectivity services (e.g., CEs with roles of Service Functions <xref target="RFC7665"/>).</t>
</li> </li>
<li> <li>
<t>A network provider may bind a single AC to one or multiple peer S APs (e.g., CE1 and CE2 are tagged as peer SAPs for the same AC). For example, an d as discussed in <xref target="RFC4364"/>, multiple CEs can be attached to a PE over the same attachment circuit. This scenario is typically implemented when t he Layer 2 infrastructure between the CE and the network is a multipoint service .</t> <t>A network provider may bind a single AC to one or multiple peer S APs (e.g., CE1 and CE2 are tagged as peer SAPs for the same AC). For example, an d as discussed in <xref target="RFC4364"/>, multiple CEs can be attached to a PE over the same attachment circuit. This scenario is typically implemented when t he Layer 2 infrastructure between the CE and the network is a multipoint service .</t>
</li> </li>
<li> <li>
<t>A single CE may terminate multiple ACs, which can be associated w ith the same bearer or distinct bearers (e.g., CE4).</t> <t>A single CE may terminate multiple ACs, which can be associated w ith the same bearer or distinct bearers (e.g., CE4).</t>
</li> </li>
<li> <li>
<t>Customers may request protection schemes in which the ACs associa ted with their endpoints are terminated by the same PE (e.g., CE3), distinct PEs (e.g., CE4), etc. The network provider uses this request to decide where to ter minate the AC in the service provider network and also whether to enable specifi c capabilities (e.g., Virtual Router Redundancy Protocol (VRRP)).</t> <t>Customers may request protection schemes in which the ACs associa ted with their endpoints are terminated by the same PE (e.g., CE3), distinct PEs (e.g., CE4), etc. The network provider uses this request to decide where to ter minate the AC in the service provider network and also whether to enable specifi c capabilities (e.g., Virtual Router Redundancy Protocol (VRRP)).</t>
</li> </li>
</ul> </ul>
<t>The "ietf-ac-ntw" is a network model that is used to manage the PE si de of ACs at a provider network.</t> <t>"ietf-ac-ntw" is a network model that is used to manage the PE side o f ACs at a provider network.</t>
<figure anchor="uc"> <figure anchor="uc">
<name>Examples of ACs</name> <name>Examples of ACs</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="304" width="512" viewBox="0 0 512 304" 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="304" width="512" viewBox="0 0 512 304" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 8,80 L 8,112" fill="none" stroke="black"/> <path d="M 8,80 L 8,112" fill="none" stroke="black"/>
<path d="M 8,160 L 8,192" fill="none" stroke="black"/> <path d="M 8,160 L 8,192" fill="none" stroke="black"/>
<path d="M 72,64 L 72,96" fill="none" stroke="black"/> <path d="M 72,64 L 72,96" fill="none" stroke="black"/>
<path d="M 72,144 L 72,176" fill="none" stroke="black"/> <path d="M 72,144 L 72,176" fill="none" stroke="black"/>
<path d="M 112,80 L 112,176" fill="none" stroke="black"/> <path d="M 112,80 L 112,176" fill="none" stroke="black"/>
<path d="M 176,112 L 176,144" fill="none" stroke="black"/> <path d="M 176,112 L 176,144" fill="none" stroke="black"/>
skipping to change at line 696 skipping to change at line 652
'--' | '--' |
| | | |
'-----------AC----------' '-----------AC----------'
(bx) = bearer Id x (bx) = bearer Id x
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="positioning-the-ac-network-model-in-the-overall-service-d elivery-process"> <section anchor="positioning-the-ac-network-model-in-the-overall-service-d elivery-process">
<name>Positioning the AC Network Model in the Overall Service Delivery P rocess</name> <name>Positioning the AC Network Model in the Overall Service Delivery P rocess</name>
<t><xref target="_u-ex"/> shows the positioning of the AC network model in the overall service delivery process. The "ietf-ac-ntw" module is a network m odel which augments the SAP with a comprehensive set of parameters to reflect th e attachment circuits that are in place in a network. The model also maintains t he mapping with the service references that are used to expose those ACs to cust omer using the 'ietf-ac-svc' module defined in <xref target="I-D.ietf-opsawg-tea s-attachment-circuit"/>. Whether the same naming conventions to reference an AC are used in the service and network layers is deployment-specific.</t> <t><xref target="_u-ex"/> shows the positioning of the AC network model in the overall service delivery process. The "ietf-ac-ntw" module is a network m odel that augments the SAP with a comprehensive set of parameters to reflect the attachment circuits that are in place in a network. The model also maintains th e mapping with the service references that are used to expose those ACs to custo mers using the "ietf-ac-svc" module defined in <xref target="RFC9834"/>. Whether the same naming conventions to reference an AC are used in the service and netw ork layers is deployment-specific.</t>
<figure anchor="_u-ex"> <figure anchor="_u-ex">
<name>An Example of the Network AC Model Usage</name> <name>An Example of the Network AC Model Usage</name>
<!--[rfced] We note that Figure 4 uses "CE#1" and "CE#2", while other
figures in the document use "CE1" and "CE2". May we update the CEs in
Figure 4 to match the other figures in the document?
If so, both artworks (svg and ascii-art) will be updated accordingly.
-->
<artset> <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"/>
<path d="M 136,512 L 136,528" fill="none" stroke="black"/> <path d="M 136,512 L 136,528" fill="none" stroke="black"/>
<path d="M 176,320 L 176,352" fill="none" stroke="black"/> <path d="M 176,320 L 176,352" fill="none" stroke="black"/>
skipping to change at line 935 skipping to change at line 899
</section> </section>
<section anchor="description-of-the-attachment-circuit-yang-module"> <section anchor="description-of-the-attachment-circuit-yang-module">
<name>Description of the Attachment Circuit YANG Module</name> <name>Description of the Attachment Circuit YANG Module</name>
<t>The full tree diagram of the "ietf-ac-ntw" module is provided in <xref target="AC-Ntw-Tree"/>. Subtrees are provided in the following subsections <t>The full tree diagram of the "ietf-ac-ntw" module is provided in <xref target="AC-Ntw-Tree"/>. Subtrees are provided in the following subsections
for the reader's convenience.</t> for the reader's convenience.</t>
<section anchor="overall-structure-of-the-module"> <section anchor="overall-structure-of-the-module">
<name>Overall Structure of the Module</name> <name>Overall Structure of the Module</name>
<t>The overall tree structure of the "ietf-ac-ntw" module is shown in <x ref target="o-ntw-tree"/>.</t> <t>The overall tree structure of the "ietf-ac-ntw" module is shown in <x ref target="o-ntw-tree"/>.</t>
<figure anchor="o-ntw-tree"> <figure anchor="o-ntw-tree">
<name>Overall Tree Structure</name> <name>Overall Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
augment /nw:networks/nw:network: augment /nw:networks/nw:network:
+--rw specific-provisioning-profiles +--rw specific-provisioning-profiles
| ... | ...
+--rw ac-profile* [name] +--rw ac-profile* [name]
... ...
augment /nw:networks/nw:network/nw:node: augment /nw:networks/nw:network/nw:node:
+--rw ac* [name] +--rw ac* [name]
+--rw name string +--rw name string
+--rw svc-ref? ac-svc:attachment-circuit-reference +--rw svc-ref? ac-svc:attachment-circuit-reference
+--rw profile* [ac-profile-ref] +--rw profile* [ac-profile-ref]
| +--rw ac-profile-ref leafref | +--rw ac-profile-ref leafref
| +--rw network-ref? -> /nw:networks/network/network-id | +--rw network-ref? -> /nw:networks/network/network-id
+--rw parent-ref +--rw parent-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
+--ro child-ref +--ro child-ref
| +--ro ac-ref* leafref | +--ro ac-ref* leafref
| +--ro node-ref? leafref | +--ro node-ref? leafref
| +--ro network-ref? -> /nw:networks/network/network-id | +--ro network-ref? -> /nw:networks/network/network-id
+--rw peer-sap-id* string +--rw peer-sap-id* string
+--rw group* [group-id] +--rw group* [group-id]
| +--rw group-id string | +--rw group-id string
| +--rw precedence? identityref | +--rw precedence? identityref
+--rw status +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw description? string +--rw description? string
+--rw l2-connection {ac-common:layer2-ac}? +--rw l2-connection {ac-common:layer2-ac}?
| ... | ...
+--rw ip-connection {ac-common:layer3-ac}? +--rw ip-connection {ac-common:layer3-ac}?
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
augment /nw:networks/nw:network/nw:node/sap:service/sap:sap: augment /nw:networks/nw:network/nw:node/sap:service/sap:sap:
+--rw ac* [ac-ref] +--rw ac* [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
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>A node can host one or more SAPs. Per <xref target="RFC9408"/>, a SAP is an abstraction of the network <t>A node can host one or more SAPs. Per <xref target="RFC9408"/>, a SAP is an abstraction of the network
reference point (the PE side of an AC, in the context of this document) where ne reference point (the PE side of an AC, in the context of this document) where ne
twork services can be delivered and/or are delivered to customers. Each SAP term twork services can be and/or are delivered to customers. Each SAP terminates one
inates one or multiple ACs. Each AC in turn may be terminated by one or more pee or multiple ACs. In turn, each AC may be terminated by one or more peer SAPs ('
r SAPs ('peer-sap'). In order to expose such AC/SAP binding information, the SAP peer-sap'). In order to expose such AC/SAP binding information, the SAP model <x
model <xref target="RFC9408"/> is augmented with required AC-related informatio ref target="RFC9408"/> is augmented with the required AC-related information.</t
n.</t> >
<t>Unlike the AC service model <xref target="I-D.ietf-opsawg-teas-attach <t>Unlike the AC service model <xref target="RFC9834"/>, an AC is unique
ment-circuit"/>, an AC is uniquely identified by a name within the scope of a no ly identified by a name within the scope of a node, not a network. A textual des
de, not a network. A textual description of the AC may be provided ('description cription of the AC may be provided ('description').</t>
').</t>
<t>Also, in order to ease the correlation between the AC exposed at the service layer and the AC that is actually provisioned in the network operation, a reference to the AC exposed to the customer ('svc-ref') is stored in the "ietf -ac-ntw" module.</t> <t>Also, in order to ease the correlation between the AC exposed at the service layer and the AC that is actually provisioned in the network operation, a reference to the AC exposed to the customer ('svc-ref') is stored in the "ietf -ac-ntw" module.</t>
<t>ACs that are terminated by a SAP are listed in the 'ac' container und er '/nw:networks/nw:network/nw:node/sap:service/sap:sap'. A controller may indic ate a filter based on the service type (e.g., Network Slice or L3VPN) to retriev e the list of available SAPs, and thus ACs, for that service.</t> <t>ACs that are terminated by a SAP are listed in the 'ac' container und er '/nw:networks/nw:network/nw:node/sap:service/sap:sap'. A controller may indic ate a filter based on the service type (e.g., Network Slice or L3VPN) to retriev e the list of available SAPs, and thus ACs, for that service.</t>
<t>In order to factorize common data that is provisioned for a group of ACs, a set of profiles (<xref target="sec-profiles"/>) can be defined at the net work level, and then called under the node level. The information contained in a profile is thus inherited, unless the corresponding data node is refined at the AC level. In such a case, the value provided at the AC level takes precedence o ver the global one.</t> <t>In order to factorize common data that is provisioned for a group of ACs, a set of profiles (<xref target="sec-profiles"/>) can be defined at the net work level and then called under the node level. The information contained in a profile is thus inherited, unless the corresponding data node is refined at the AC level. In such a case, the value provided at the AC level takes precedence ov er the global one.</t>
<t>In contexts where the same AC is terminated by multiple peer SAPs (e. g., an AC with multiple CEs) but a subset of them have specific information, the module allows operators to:</t> <t>In contexts where the same AC is terminated by multiple peer SAPs (e. g., an AC with multiple CEs) but a subset of them have specific information, the module allows operators to:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Define a parent AC that may list all these CEs as peer SAPs.</t> <t>Define a parent AC that may list all these CEs as peer SAPs.</t>
</li> </li>
<li> <li>
<t>Create individual ACs that are bound to the parent AC using 'pare nt-ref'.</t> <t>Create individual ACs that are bound to the parent AC using 'pare nt-ref'.</t>
</li> </li>
<li> <li>
<t>Indicate for each individual AC one or a subset of the CEs as pee r SAPs. All these individual ACs will inherit the properties of the parent AC.</ t> <t>Indicate for each individual AC one or a subset of the CEs as pee r SAPs. All these individual ACs will inherit the properties of the parent AC.</ t>
</li> </li>
</ul> </ul>
<t>Whenever a parent AC is deleted, then all child ACs of that AC <bcp14 >MUST</bcp14> be deleted. Child ACs are referenced using 'child-ref'.</t> <t>Whenever a parent AC is deleted, then all child ACs of that AC <bcp14 >MUST</bcp14> be deleted. Child ACs are referenced using 'child-ref'.</t>
<t>An AC may belong to one or multiple groups <xref target="RFC9181"/>. For example, the 'group-id' is used to associate redundancy or protection constr aints with ACs.</t> <t>An AC may belong to one or multiple groups <xref target="RFC9181"/>. For example, the 'group-id' is used to associate redundancy or protection constr aints with ACs.</t>
<t>The status of an AC can be tracked using 'status'. Both operational s tatus and administrative status are maintained. A mismatch between the administr ative status vs. the operational status can be used as a trigger to detect anoma lies.</t> <t>The status of an AC can be tracked using 'status'. Both operational s tatus and administrative status are maintained. A mismatch between the administr ative status vs. the operational status can be used as a trigger to detect anoma lies.</t>
<t>An AC can be characterized using Layer 2 connectivity (<xref target=" sec-l2"/>), Layer 3 connectivity (<xref target="sec-l3"/>), routing protocols (< xref target="sec-rtg"/>), Operations, Administration, and Maintenance (OAM) (<xr ef target="sec-oam"/>), security (<xref target="sec-sec"/>), and service (<xref target="sec-svc"/>) considerations. Features are used to tag conditional protion s to accomodate various deployments (support of layer 2 ACs, Layer 3 ACs, IPv4, IPv6, routing protocols, BFD, etc.).</t> <t>An AC can be characterized using Layer 2 connectivity (<xref target=" sec-l2"/>), Layer 3 connectivity (<xref target="sec-l3"/>), routing protocols (< xref target="sec-rtg"/>), Operations, Administration, and Maintenance (OAM) (<xr ef target="sec-oam"/>), security (<xref target="sec-sec"/>), and service (<xref target="sec-svc"/>) considerations. Features are used to tag conditional portion s to accommodate various deployments (support of Layer 2 ACs, Layer 3 ACs, IPv4, IPv6, routing protocols, Bidirectional Forwarding Detection (BFD), etc.).</t>
</section> </section>
<section anchor="references"> <section anchor="references">
<name>References</name> <name>References</name>
<t>The AC network module defines a set of groupings depicted in <xref ta rget="references-tree"/> for referencing purposes. These references are used wit hin or outside the AC network module. The use of such groupings is consistent wi th the design in <xref target="RFC8345"/>.</t> <t>The AC network module defines a set of groupings depicted in <xref ta rget="references-tree"/> for referencing purposes. These references are used wit hin or outside the AC network module. The use of such groupings is consistent wi th the design in <xref target="RFC8345"/>.</t>
<figure anchor="references-tree"> <figure anchor="references-tree">
<name>References Groupings</name> <name>References Groupings</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping attachment-circuit-reference: grouping attachment-circuit-reference:
+-- ac-ref? leafref +-- ac-ref? leafref
+-- node-ref? leafref +-- node-ref? leafref
+-- network-ref? -> /nw:networks/network/network-id +-- network-ref? -> /nw:networks/network/network-id
grouping attachment-circuit-references: grouping attachment-circuit-references:
+-- ac-ref* leafref +-- ac-ref* leafref
+-- node-ref? leafref +-- node-ref? leafref
+-- network-ref? -> /nw:networks/network/network-id +-- network-ref? -> /nw:networks/network/network-id
grouping ac-profile-reference: grouping ac-profile-reference:
+-- ac-profile-ref? leafref +-- ac-profile-ref? leafref
skipping to change at line 1042 skipping to change at line 1006
+-- network-ref? -> /nw:networks/network/network-id +-- network-ref? -> /nw:networks/network/network-id
grouping failure-detection-profile-reference: grouping failure-detection-profile-reference:
+-- failure-detection-profile-ref? leafref +-- failure-detection-profile-ref? leafref
+-- network-ref? -> /nw:networks/network/network-id +-- network-ref? -> /nw:networks/network/network-id
grouping forwarding-profile-reference: grouping forwarding-profile-reference:
+-- forwarding-profile-ref? leafref +-- forwarding-profile-ref? leafref
+-- network-ref? -> /nw:networks/network/network-id +-- network-ref? -> /nw:networks/network/network-id
grouping routing-profile-reference: grouping routing-profile-reference:
+-- routing-profile-ref? leafref +-- routing-profile-ref? leafref
+-- network-ref? -> /nw:networks/network/network-id +-- network-ref? -> /nw:networks/network/network-id
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The groupings shown in <xref target="references-tree"/> contain the i nformation necessary to reference:</t> <t>The groupings shown in <xref target="references-tree"/> contain the i nformation necessary to reference:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>an attachment circuit that is terminated by a specific node in a given network,</t> <t>an attachment circuit that is terminated by a specific node in a given network,</t>
</li> </li>
<li> <li>
<t>an attachment circuit profile of a specific network (<xref target ="sec-profiles"/>), and</t> <t>an attachment circuit profile of a specific network (<xref target ="sec-profiles"/>), and</t>
</li> </li>
<li> <li>
<t>specific provisioning profiles that are bound to a specific netwo rk (<xref target="sec-profiles"/>).</t> <t>specific provisioning profiles that are bound to a specific netwo rk (<xref target="sec-profiles"/>).</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="sec-profiles"> <section anchor="sec-profiles">
<name>Provisioning Profiles</name> <name>Provisioning Profiles</name>
<t>The AC and specific provisioning profiles tree structure is shown in <xref target="profiles-tree"/>.</t> <t>The AC and specific provisioning profiles tree structure is shown in <xref target="profiles-tree"/>.</t>
<figure anchor="profiles-tree"> <figure anchor="profiles-tree">
<name>Profiles Tree Structure</name> <name>Profiles Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
augment /nw:networks/nw:network: augment /nw:networks/nw:network:
+--rw specific-provisioning-profiles +--rw specific-provisioning-profiles
| +--rw valid-provider-identifiers | +--rw valid-provider-identifiers
| +--rw encryption-profile-identifier* [id] | +--rw encryption-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw qos-profile-identifier* [id] | +--rw qos-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw failure-detection-profile-identifier* [id] | +--rw failure-detection-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw forwarding-profile-identifier* [id] | +--rw forwarding-profile-identifier* [id]
skipping to change at line 1148 skipping to change at line 1112
| +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw vrrp {vpn-common:rtg-vrrp}?
| +--rw address-family? identityref | +--rw address-family? identityref
| +--rw ping-reply? boolean | +--rw ping-reply? boolean
+--rw oam +--rw oam
+--rw bfd {vpn-common:bfd}? +--rw bfd {vpn-common:bfd}?
+--rw session-type? identityref +--rw session-type? identityref
+--rw desired-min-tx-interval? uint32 +--rw desired-min-tx-interval? uint32
+--rw required-min-rx-interval? uint32 +--rw required-min-rx-interval? uint32
+--rw local-multiplier? uint8 +--rw local-multiplier? uint8
+--rw holdtime? uint32 +--rw holdtime? uint32
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>Similar to <xref target="RFC9182"/> and <xref target="RFC9291"/>, the exact definition of the specific provisioning profiles is local to each service provider. The model only includes an identifier for these profiles in order to ease identifying and binding local policies when building an AC. As shown in <xr ef target="profiles-tree"/>, the following identifiers can be included:</t> <t>Similar to <xref target="RFC9182"/> and <xref target="RFC9291"/>, the exact definition of the specific provisioning profiles is local to each service provider. The model only includes an identifier for these profiles in order to ease identifying and binding local policies when building an AC. As shown in <xr ef target="profiles-tree"/>, the following identifiers can be included:</t>
<dl> <dl>
<dt>'encryption-profile-identifier':</dt> <dt>'encryption-profile-identifier':</dt>
<dd> <dd>
<t>An encryption profile refers to a set of policies related to the encryption schemes and setup that can be applied on the AC. See also <xref targe t="sec-sec"/>.</t> <t>An encryption profile refers to a set of policies related to the encryption schemes and setup that can be applied on the AC. See also <xref targe t="sec-sec"/>.</t>
</dd> </dd>
<dt>'qos-profile-identifier':</dt> <dt>'qos-profile-identifier':</dt>
<dd> <dd>
<t>A Quality of Service (QoS) profile refers to a set of policies su ch as classification, marking, and actions (e.g., <xref target="RFC3644"/>). See also <xref target="sec-svc"/>.</t> <t>A Quality of Service (QoS) profile refers to a set of policies su ch as classification, marking, and actions (e.g., <xref target="RFC3644"/>). See also <xref target="sec-svc"/>.</t>
</dd> </dd>
<dt>'failure-detection-profile-identifier':</dt> <dt>'failure-detection-profile-identifier':</dt>
<dd> <dd>
<t>A failure detection profile refers to a set of failure detection policies such as Bidirectional Forwarding Detection (BFD) policies <xref target= "RFC5880"/> that can be invoked when building an AC. Such a profile can be, for example, referenced in static routes (<xref target="sec-static-rtg"/>) or under the OAM level (<xref target="sec-oam"/>). The use of this profile is similar to the detailed examples depicted in Appendices A.11.3 and A.12 of <xref target="I- D.ietf-opsawg-teas-attachment-circuit"/>.</t> <t>A failure detection profile refers to a set of failure detection policies such as Bidirectional Forwarding Detection (BFD) policies <xref target= "RFC5880"/> that can be invoked when building an AC. Such a profile can be, for example, referenced in static routes (<xref target="sec-static-rtg"/>) or under the OAM level (<xref target="sec-oam"/>). The use of this profile is similar to the detailed examples depicted in Appendices <xref section="A.11.3" sectionForma t="bare" target="RFC9834"/> and <xref section="A.12" sectionFormat="bare" target ="RFC9834"/> of <xref target="RFC9834"/>.</t>
</dd> </dd>
<dt>'forwarding-profile-identifier':</dt> <dt>'forwarding-profile-identifier':</dt>
<dd> <dd>
<t>A forwarding profile refers to the policies that apply to the for warding of packets conveyed over an AC. Such policies may consist of, for exampl e, applying Access Control Lists (ACLs) as in <xref target="sec-svc"/>.</t> <t>A forwarding profile refers to the policies that apply to the for warding of packets conveyed over an AC. Such policies may consist of, for exampl e, applying Access Control Lists (ACLs) as in <xref target="sec-svc"/>.</t>
</dd> </dd>
<dt>'routing-profile-identifier':</dt> <dt>'routing-profile-identifier':</dt>
<dd> <dd>
<t>A routing profile refers to a set of routing policies that will b e invoked (e.g., BGP policies) for an AC. Refer to <xref target="sec-rtg"/>.</t> <t>A routing profile refers to a set of routing policies that will b e invoked (e.g., BGP policies) for an AC. Refer to <xref target="sec-rtg"/>.</t>
</dd> </dd>
</dl> </dl>
<t>The 'ac-profile' defines parameters that can be factorized among a se t of ACs. Each profile is identified by 'name' that is unique in a network. Some of the data nodes can be adjusted at the node level. These adjusted values take precedence over the values in the profile.</t> <t>The 'ac-profile' defines parameters that can be factorized among a se t of ACs. Each profile is identified by a 'name' that is unique in a network. So me of the data nodes can be adjusted at the node level. These adjusted values ta ke precedence over the values in the profile.</t>
</section> </section>
<section anchor="sec-l2"> <section anchor="sec-l2">
<name>L2 Connection</name> <name>L2 Connection</name>
<t>The 'l2-connection' container is used to manage the Layer 2 propertie s of an AC (mainly, the PE side of an AC). The Layer 2 connection tree structure is shown in <xref target="l2-tree"/>.</t> <t>The 'l2-connection' container is used to manage the Layer 2 propertie s of an AC (mainly, the PE side of an AC). The Layer 2 connection tree structure is shown in <xref target="l2-tree"/>.</t>
<figure anchor="l2-tree"> <figure anchor="l2-tree">
<name>Layer 2 Connection Tree Structure</name> <name>Layer 2 Connection Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
augment /nw:networks/nw:network/nw:node: augment /nw:networks/nw:network/nw:node:
+--rw ac* [name] +--rw ac* [name]
+--rw name string +--rw name string
+ ... + ...
+--rw l2-connection {ac-common:layer2-ac}? +--rw l2-connection {ac-common:layer2-ac}?
| +--rw encapsulation | +--rw encapsulation
| | +--rw encap-type? identityref | | +--rw encap-type? identityref
| | +--rw dot1q | | +--rw dot1q
| | | +--rw tag-type? identityref | | | +--rw tag-type? identityref
| | | +--rw cvlan-id? uint16 | | | +--rw cvlan-id? uint16
skipping to change at line 1260 skipping to change at line 1224
+--rw ip-connection {ac-common:layer3-ac}? +--rw ip-connection {ac-common:layer3-ac}?
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The 'encapsulation' container specifies the Layer 2 encapsulation to use (if any) and allows the configuration of the relevant tags. Also, the model supports tag manipulation operations (e.g., tag rewrite).</t> <t>The 'encapsulation' container specifies the Layer 2 encapsulation to use (if any) and allows the configuration of the relevant tags. Also, the model supports tag manipulation operations (e.g., tag rewrite).</t>
<t>The 'l2-tunnel-service' container is used to specify the required par ameters to set a Layer 2 tunneling service (e.g., a Virtual Private LAN Service (VPLS), a Virtual eXtensible Local Area Network (VXLAN), or a pseudowire (<xref section="6.1" sectionFormat="of" target="RFC8077"/>)). 'l2vpn-id' is used to ide ntify a L2VPN service that is associated with an Integrated Routing and Bridging (IRB) interface.</t> <t>The 'l2-tunnel-service' container is used to specify the required par ameters to set a Layer 2 tunneling service (e.g., a Virtual Private LAN Service (VPLS), a Virtual eXtensible Local Area Network (VXLAN), or a pseudowire (<xref section="6.1" sectionFormat="of" target="RFC8077"/>)). 'l2vpn-id' is used to ide ntify a L2VPN service that is associated with an Integrated Routing and Bridging (IRB) interface.</t>
<t>Specific Layer 2 sub-interfaces may be required to be configured in s ome implementations/deployments. Such a Layer-2-specific interface can be includ ed in 'l2-termination-point'.</t> <t>Specific Layer 2 sub-interfaces may be required to be configured in s ome implementations/deployments. Such a Layer-2-specific interface can be includ ed in 'l2-termination-point'.</t>
<t>To accommodate implementations that require internal bridging, a loca l bridge reference can be specified in 'local-bridge-reference'. Such a referenc e may be a local bridge domain.</t> <t>To accommodate implementations that require internal bridging, a loca l bridge reference can be specified in 'local-bridge-reference'. Such a referenc e may be a local bridge domain.</t>
<t>A reference to the bearer used by this AC is maintained using 'bearer -reference'.</t> <t>A reference to the bearer used by this AC is maintained using 'bearer -reference'.</t>
</section> </section>
<section anchor="sec-l3"> <section anchor="sec-l3">
<name>IP Connection</name> <name>IP Connection</name>
<t>This 'ip-connection' container is used to group Layer 3 connectivity information, particularly the IP addressing information, of an AC.</t> <t>This 'ip-connection' container is used to group Layer 3 connectivity information, particularly the IP addressing information, of an AC.</t>
<t>The Layer 3 connection tree structure is shown in <xref target="l3-t ree"/>.</t> <t>The Layer 3 connection tree structure is shown in <xref target="l3-t ree"/>.</t>
<figure anchor="l3-tree"> <figure anchor="l3-tree">
<name>IP Connection Tree Structure</name> <name>IP Connection Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
augment /nw:networks/nw:network/nw:node: augment /nw:networks/nw:network/nw:node:
+--rw ac* [name] +--rw ac* [name]
+--rw name string +--rw name string
+ ... + ...
+--rw l2-connection {ac-common:layer2-ac}? +--rw l2-connection {ac-common:layer2-ac}?
| ... | ...
+--rw ip-connection {ac-common:layer3-ac}? +--rw ip-connection {ac-common:layer3-ac}?
| +--rw l3-termination-point? string | +--rw l3-termination-point? string
| +--rw ipv4 {vpn-common:ipv4}? | +--rw ipv4 {vpn-common:ipv4}?
| | +--rw local-address? | | +--rw local-address?
skipping to change at line 1373 skipping to change at line 1337
| +--rw network-ref? | +--rw network-ref?
| -> /nw:networks/network/network-id | -> /nw:networks/network/network-id
+--rw routing-protocols +--rw routing-protocols
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>A distinct Layer 3 interface other than the interface indicated under the 'l2-connection' container may be needed to terminate the Layer 3 connectivi ty. The identifier of such an interface is included in 'l3-termination-point'. F or example, this data node can be used to carry the identifier of a bridge domai n interface.</t> <t>A distinct Layer 3 interface other than the interface indicated under the 'l2-connection' container may be needed to terminate the Layer 3 connectivi ty. The identifier of such an interface is included in 'l3-termination-point'. F or example, this data node can be used to carry the identifier of a bridge domai n interface.</t>
<t>This container can include IPv4, IPv6, or both if dual-stack is enabl ed. For both IPv4 and IPv6, the IP connection supports three IP address assignme nt modes for customer addresses: provider DHCP, DHCP relay, and static addressin g. Note that for the IPv6 case, Stateless Address Autoconfiguration (SLAAC) <xre f target="RFC4862"/> can be used.</t> <t>This container can include IPv4, IPv6, or both if dual-stack is enabl ed. For both IPv4 and IPv6, the IP connection supports three IP address assignme nt modes for customer addresses: provider DHCP, DHCP relay, and static addressin g. Note that for the IPv6 case, Stateless Address Autoconfiguration (SLAAC) <xre f target="RFC4862"/> can be used.</t>
<t>For both IPv4 and IPv6, 'address-allocation-type' is used to indicate the IP address allocation mode to activate for an AC. The allocated address rep resents the PE interface address configuration. When 'address-allocation-type' i s set to 'provider-dhcp', DHCP assignments can be made locally or by an external DHCP server. Such behavior is controlled by setting 'dhcp-service-type'.</t> <t>For both IPv4 and IPv6, 'address-allocation-type' is used to indicate the IP address allocation mode to activate for an AC. The allocated address rep resents the PE interface address configuration. When 'address-allocation-type' i s set to 'provider-dhcp', DHCP assignments can be made locally or by an external DHCP server. Such behavior is controlled by setting 'dhcp-service-type'.</t>
<t>For IPv6, if 'address-allocation-type' is set to 'slaac', the Prefix Information option of Router Advertisements that will be issued for SLAAC purpos es will carry the IPv6 prefix that is determined by 'local-address' and 'prefix- length'. For example, if 'local-address' is set to '2001:db8:0:1::1' and 'prefix -length' is set to '64', the IPv6 prefix that will be used is '2001:db8:0:1::/64 '.</t> <t>For IPv6, if 'address-allocation-type' is set to 'slaac', the Prefix Information option of Router Advertisements that will be issued for SLAAC purpos es will carry the IPv6 prefix that is determined by 'local-address' and 'prefix- length'. For example, if 'local-address' is set to '2001:db8:0:1::1' and 'prefix -length' is set to '64', the IPv6 prefix that will be used is '2001:db8:0:1::/64 '.</t>
<t>In some deployment contexts (e.g., network merging), multiple IP subn ets may be used in a transition period. For such deployments, multiple ACs (typi cally, two) with overlapping information may be maintained during a transition p eriod. The correlation between these ACs may rely upon the same 'svc-ref'.</t> <t>In some deployment contexts (e.g., network merging), multiple IP subn ets may be used in a transition period. For such deployments, multiple ACs (typi cally, two) with overlapping information may be maintained during a transition p eriod. The correlation between these ACs may rely upon the same 'svc-ref'.</t>
</section> </section>
<section anchor="sec-rtg"> <section anchor="sec-rtg">
<name>Routing</name> <name>Routing</name>
<t>The overall routing subtree structure is shown in <xref target="rtg-t ree"/>.</t> <t>The overall routing subtree structure is shown in <xref target="rtg-t ree"/>.</t>
<figure anchor="rtg-tree"> <figure anchor="rtg-tree">
<name>Routing Tree Structure</name> <name>Routing Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw module: ietf-ac-ntw
augment /nw:networks/nw:network: augment /nw:networks/nw:network:
+--rw ac-profile* [name] +--rw ac-profile* [name]
+--rw name string +--rw name string
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw bgp {vpn-common:rtg-bgp}? | +--rw bgp {vpn-common:rtg-bgp}?
| | ... | | ...
skipping to change at line 1442 skipping to change at line 1406
| +--rw rip {vpn-common:rtg-rip}? | +--rw rip {vpn-common:rtg-rip}?
| | ... | | ...
| +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw vrrp {vpn-common:rtg-vrrp}?
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>Multiple routing instances ('routing-protocol') can be defined, each uniquely identified <t>Multiple routing instances ('routing-protocol') can be defined, each uniquely identified
by an 'id'. Specifically, each instance is uniquely identified to accommodate sc enarios by an 'id'. Specifically, each instance is uniquely identified to accommodate sc enarios
where multiple instances of the same routing protocol have to be configured on t he same AC.</t> where multiple instances of the same routing protocol have to be configured on t he same AC.</t>
<t>The type of a routing instance is indicated in 'type'. <t>The type of a routing instance is indicated in 'type'.
The values of this attribute are those defined in <xref target="RFC9181"/> (the The values of this attribute are those defined in <xref target="RFC9181"/> (the
'routing-protocol-type' identity). Specific data nodes are then provided 'routing-protocol-type' identity). Specific data nodes are then provided
as a function of the 'type'. See more details in the following subsections.</t> as a function of the 'type'. See more details in the following subsections.</t>
<t>One or multiple routing profiles ('routing-profile') can be provided for <t>One or multiple routing profiles ('routing-profile') can be provided for
a given routing instance.</t> a given routing instance.</t>
<section anchor="sec-static-rtg"> <section anchor="sec-static-rtg">
<name>Static Routing</name> <name>Static Routing</name>
<t>The static routing subtree structure is shown in <xref target="stat ic-tree"/>.</t> <t>The static routing subtree structure is shown in <xref target="stat ic-tree"/>.</t>
<figure anchor="static-tree"> <figure anchor="static-tree">
<name>Static Routing Tree Structure</name> <name>Static Routing Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw module: ietf-ac-ntw
... ...
augment /nw:networks/nw:network/nw:node: augment /nw:networks/nw:network/nw:node:
+--rw ac* [name] +--rw ac* [name]
+--rw name string +--rw name string
... ...
+--rw l2-connection {ac-common:layer2-ac}? +--rw l2-connection {ac-common:layer2-ac}?
| ... | ...
+--rw ip-connection {ac-common:layer3-ac}? +--rw ip-connection {ac-common:layer3-ac}?
| ... | ...
skipping to change at line 1538 skipping to change at line 1502
| +--rw rip {vpn-common:rtg-rip}? | +--rw rip {vpn-common:rtg-rip}?
| | ... | | ...
| +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw vrrp {vpn-common:rtg-vrrp}?
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The following data nodes can be defined for a given IP prefix:</t> <t>The following data nodes can be defined for a given IP prefix:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'lan-tag':</dt> <dt>'lan-tag':</dt>
<dd> <dd>
<t>Indicates a local tag (e.g., "myfavorite-lan") that is used to <t>Indicates a local tag (e.g., 'myfavorite-lan') that is used
enforce local policies.</t> to enforce local policies.</t>
</dd> </dd>
<dt>'next-hop':</dt> <dt>'next-hop':</dt>
<dd> <dd>
<t>Indicates the next hop to be used for the static route.</t> <t>Indicates the next hop to be used for the static route.</t>
</dd> <t>It can be identified by an IP address, a predefined next-hop
<dt/> type (e.g., 'discard' or 'local-link'), etc.</t>
<dd>
<t>It can be identified by an IP address, a predefined next-hop ty
pe (e.g., 'discard' or 'local-link'), etc.</t>
</dd> </dd>
<dt>'bfd':</dt> <dt>'bfd':</dt>
<dd> <dd>
<t>Indicates whether BFD is enabled or disabled for this static ro <t>Indicates whether BFD is enabled or disabled for this static
ute entry. A BFD profile may also be provided.</t> route entry. A BFD profile may also be provided.</t>
</dd> </dd>
<dt>'metric':</dt> <dt>'metric':</dt>
<dd> <dd>
<t>Indicates the metric associated with the static route entry. Th <t>Indicates the metric associated with the static route
is metric is used when the route is exported into an IGP.</t> entry. This metric is used when the route is exported into an
IGP.</t>
</dd> </dd>
<dt>'preference':</dt> <dt>'preference':</dt>
<dd> <dd>
<t>Indicates the preference associated with the static route entry .</t> <t>Indicates the preference associated with the static route entry .</t>
</dd>
<dt/>
<dd>
<t>This preference is used to select a preferred route among route s to the same destination prefix.</t> <t>This preference is used to select a preferred route among route s to the same destination prefix.</t>
</dd> </dd>
<dt>'status':</dt> <dt>'status':</dt>
<dd> <dd>
<t>Used to convey the status of a static route entry. This data no de can also be used to control the (de)activation of individual static route ent ries.</t> <t>Used to convey the status of a static route entry. This data no de can also be used to control the (de)activation of individual static route ent ries.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-bgp-rtg"> <section anchor="sec-bgp-rtg">
<name>BGP</name> <name>BGP</name>
<t>The BGP routing subtree structure is shown in <xref target="bgp-tre e"/>.</t> <t>The BGP routing subtree structure is shown in <xref target="bgp-tre e"/>.</t>
<figure anchor="bgp-tree"> <figure anchor="bgp-tree">
<name>BGP Routing Tree Structure</name> <name>BGP Routing Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw module: ietf-ac-ntw
augment /nw:networks/nw:network: augment /nw:networks/nw:network:
+--rw ac-profile* [name] +--rw ac-profile* [name]
+--rw name string +--rw name string
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw bgp {vpn-common:rtg-bgp}? | +--rw bgp {vpn-common:rtg-bgp}?
| | +--rw peer-groups | | +--rw peer-groups
skipping to change at line 1786 skipping to change at line 1749
| +--rw rip {vpn-common:rtg-rip}? | +--rw rip {vpn-common:rtg-rip}?
| | ... | | ...
| +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw vrrp {vpn-common:rtg-vrrp}?
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The following data nodes are supported for each 'peer-group':</t> <t>The following data nodes are supported for each 'peer-group':</t>
<dl> <dl>
<dt>'name':</dt> <dt>'name':</dt>
<dd> <dd>
<t>Defines a name for the peer group.</t> <t>Defines a name for the peer group.</t>
</dd> </dd>
<dt>'local-address':</dt> <dt>'local-address':</dt>
<dd> <dd>
<t>Specifies an address or a reference to an interface to use when <t>Specifies an address or a reference to an interface to use
establishing the BGP transport session.</t> when establishing the BGP transport session.</t>
</dd> </dd>
<dt>'description':</dt> <dt>'description':</dt>
<dd> <dd>
<t>Includes a description of the peer group.</t> <t>Includes a description of the peer group.</t>
</dd> </dd>
<dt>'apply-policy':</dt> <dt>'apply-policy':</dt>
<dd> <dd>
<t>Lists a set of import/export policies <xref target="RFC9067"/> to apply for this group.</t> <t>Lists a set of import/export policies <xref target="RFC9067"/> to apply for this group.</t>
</dd> </dd>
<dt>'local-as':</dt> <dt>'local-as':</dt>
<dd> <dd>
<t>Indicates a local AS Number (ASN).</t> <t>Indicates a local AS Number (ASN).</t>
</dd> </dd>
<dt>'peer-as':</dt> <dt>'peer-as':</dt>
<dd> <dd>
<t>Indicates the peer's ASN.</t> <t>Indicates the peer's ASN.</t>
</dd> </dd>
<dt>'address-family':</dt> <dt>'address-family':</dt>
<dd> <dd>
<t>Indicates the address family of the peer. It can <t>Indicates the address family of the peer. It can be set to
be set to 'ipv4', 'ipv6', or 'dual-stack'.</t> 'ipv4', 'ipv6', or 'dual-stack'.</t>
</dd> <t>This address family might be used together with the service
<dt/> type that uses an AC (e.g., 'vpn-type' <xref target="RFC9182"/>)
<dd> to derive the appropriate Address Family Identifiers (AFIs) /
<t>This address family might be used together with the service typ Subsequent Address Family Identifiers (SAFIs) that will be part
e that uses an AC (e.g., 'vpn-type' <xref target="RFC9182"/>) to derive the appr of the derived device configurations (e.g., unicast IPv4 MPLS
opriate Address Family Identifiers (AFIs) / Subsequent Address Family Identifier L3VPN (AFI,SAFI = 1,128) as defined in <xref section="4.3.4"
s (SAFIs) that will be part of the derived device configurations (e.g., unicast sectionFormat="of" target="RFC4364"/>).</t>
IPv4 MPLS L3VPN (AFI,SAFI = 1,128) as defined in <xref section="4.3.4" sectionFo
rmat="of" target="RFC4364"/>).</t>
</dd> </dd>
<dt>'role':</dt> <dt>'role':</dt>
<dd> <dd>
<t>Specifies the BGP role in a session. Role values are taken f <t>Specifies the BGP role in a session. Role values are taken
rom the list defined in <xref section="4" sectionFormat="of" target="RFC9234"/>. from the list defined in <xref section="4" sectionFormat="of"
</t> target="RFC9234"/>.</t>
</dd> </dd>
<dt>'multihop':</dt> <dt>'multihop':</dt>
<dd> <dd>
<t>Indicates the number of allowed IP hops to reach a BGP peer.</t > <t>Indicates the number of allowed IP hops to reach a BGP peer.</t >
</dd> </dd>
<dt>'as-override':</dt> <dt>'as-override':</dt>
<dd> <dd>
<t>If set, this parameter indicates whether ASN override <t>If set, this parameter indicates whether ASN override is
is enabled, i.e., replacing the ASN of the customer specified in enabled, i.e., replacing the ASN of the customer specified in
the AS_PATH BGP attribute with the ASN identified in the 'local- the AS_PATH BGP attribute with the ASN identified in the 'local-
as' attribute.</t> as' attribute.</t>
</dd> </dd>
<dt>'allow-own-as':</dt> <dt>'allow-own-as':</dt>
<dd> <dd>
<t>Used in some topologies (e.g., hub-and-spoke) to <t>Used in some topologies (e.g., hub-and-spoke) to allow the
allow the provider's ASN to be included in the AS_PATH BGP provider's ASN to be included in the AS_PATH BGP attribute
attribute received from a peer. Loops are prevented by setting received from a peer. Loops are prevented by setting
'allow-own-as' to a maximum number of the provider's ASN 'allow-own-as' to a maximum number of the provider's ASN
occurrences. By default, this parameter is set to '0' (that is, occurrences. By default, this parameter is set to '0' (that is,
reject any AS_PATH attribute that includes the provider's ASN).</t> reject any AS_PATH attribute that includes the provider's
ASN).</t>
</dd> </dd>
<dt>'prepend-global-as':</dt> <dt>'prepend-global-as':</dt>
<dd> <dd>
<t>When distinct ASNs are configured at the <t>When distinct ASNs are configured at the node and AC levels,
node and AC levels, this parameter controls whether this parameter controls whether the ASN provided at the node
the ASN provided at the node level is prepended to the AS_PATH level is prepended to the AS_PATH attribute.</t>
attribute.</t>
</dd> </dd>
<dt>'send-default-route':</dt> <dt>'send-default-route':</dt>
<dd> <dd>
<t>Controls whether default routes can be advertised to the peer.< /t> <t>Controls whether default routes can be advertised to the peer.< /t>
</dd> </dd>
<dt>'site-of-origin':</dt> <dt>'site-of-origin':</dt>
<dd> <dd>
<t>Meant to uniquely identify the set of routes <t>Meant to uniquely identify the set of routes learned from a
learned from a site via a particular AC. It is used site via a particular AC. It is used to prevent routing loops
to prevent routing loops (<xref section="7" sectionFormat="of" target="RFC436 (<xref section="7" sectionFormat="of" target="RFC4364"/>). The
4"/>). The Site of Site of Origin attribute is encoded as a Route Origin Extended
Origin attribute is encoded as a Route Origin Extended Community.</t> Community.</t>
</dd> </dd>
<dt>'ipv6-site-of-origin':</dt> <dt>'ipv6-site-of-origin':</dt>
<dd> <dd>
<t>Carries an IPv6 Address Specific BGP Extended <t>Carries an IPv6 Address Specific BGP Extended Community that
Community that is used to indicate the Site of Origin <xref target="RFC5701" is used to indicate the Site of Origin <xref target="RFC5701"/>.
/>. It is used to prevent routing loops.</t> It is used to prevent routing loops.</t>
</dd> </dd>
<dt>'redistribute-connected':</dt> <dt>'redistribute-connected':</dt>
<dd> <dd>
<t>Controls whether the AC is advertised to other PEs.</t> <t>Controls whether the AC is advertised to other PEs.</t>
</dd> </dd>
</dl> <dt>'bgp-max-prefix':</dt>
<t>'bgp-max-prefix': Controls the behavior when a prefix maximum is <dd> Controls the behavior when a prefix maximum is reached.</dd>
reached.</t>
<dl>
<dt>'max-prefix':</dt> <dt>'max-prefix':</dt>
<dd> <dd>
<t>Indicates the maximum number of BGP prefixes <t>Indicates the maximum number of BGP prefixes allowed in a
allowed in a session for this group. If the limit is reached, the session for this group. If the limit is reached, the action
action indicated in 'violate-action' will be followed.</t> indicated in 'violate-action' will be followed.</t>
</dd> </dd>
<dt>'warning-threshold':</dt> <dt>'warning-threshold':</dt>
<dd> <dd>
<t>A warning notification is triggered when this limit is reached. </t> <t>A warning notification is triggered when this limit is reached. </t>
</dd> </dd>
<dt>'violate-action':</dt> <dt>'violate-action':</dt>
<dd> <dd>
<t>Indicates which action to execute when the <t>Indicates which action to execute when the maximum number of
maximum number of BGP prefixes is reached. Examples of such BGP prefixes is reached. Examples of such actions include
actions include sending a warning message, discarding extra sending a warning message, discarding extra paths from the peer,
paths from the peer, or restarting the session.</t> or restarting the session.</t>
</dd> </dd>
<dt>'restart-timer':</dt> <dt>'restart-timer':</dt>
<dd> <dd>
<t>Indicates, in seconds, the time interval after <t>Indicates, in seconds, the time interval after which the BGP
which the BGP session will be reestablished.</t> session will be reestablished.</t>
</dd> </dd>
<dt>'bgp-timers':</dt> <dt>'bgp-timers':</dt>
<dd> <dd>
<t>Two timers can be captured in this container: (1) <t>Two timers can be captured in this container: (1)
'hold-time', which is the time interval that will be used for the 'hold-time', which is the time interval that will be used for
Hold Timer (<xref section="4.2" sectionFormat="of" target="RFC4271"/>) when e the Hold Timer (<xref section="4.2" sectionFormat="of"
stablishing a BGP target="RFC4271"/>) when establishing a BGP session and (2)
session and (2) 'keepalive', which is the time interval for the 'keepalive', which is the time interval for the KeepaliveTimer
KeepaliveTimer between a PE and a BGP peer (<xref section="4.4" sectionFormat between a PE and a BGP peer (<xref section="4.4"
="of" target="RFC4271"/>).</t> sectionFormat="of" target="RFC4271"/>).</t>
</dd>
<dt/>
<dd>
<t>Both timers are expressed in seconds.</t> <t>Both timers are expressed in seconds.</t>
</dd> </dd>
<dt>'bfd':</dt> <dt>'bfd':</dt>
<dd> <dd>
<t>Indicates whether BFD is enabled or disabled for this nighbor. <t>Indicates whether BFD is enabled or disabled for this
A BFD profile to apply may also be provided.</t> neighbor. A BFD profile to apply may also be provided.</t>
</dd> </dd>
<dt>'authentication':</dt> <dt>'authentication':</dt>
<dd> <dd>
<t>The module adheres to the recommendations in <t>The module adheres to the recommendations in <xref
<xref section="13.2" sectionFormat="of" target="RFC4364"/>, as it allows enab section="13.2" sectionFormat="of" target="RFC4364"/>, as it
ling the TCP allows enabling the TCP Authentication Option (TCP-AO) <xref
Authentication Option (TCP-AO) <xref target="RFC5925"/> and accommodates the target="RFC5925"/> and accommodates the installed base that
installed base that makes use of MD5.</t> makes use of MD5.</t>
</dd> <t>This version of the model assumes that parameters specific to
<dt/> the TCP-AO are preconfigured as part of the key chain that is
<dd> referenced in the model. No assumption is made about how such a
<t>This version of the model assumes that parameters specific to t key chain is preconfigured. However, the structure of the key
he chain should cover data nodes beyond those in <xref
TCP-AO are preconfigured as part of the key chain that is target="RFC8177"/>, mainly SendID and RecvID (<xref
referenced in the model. No assumption is made about how such a section="3.1" sectionFormat="of" target="RFC5925"/>).</t>
key chain is preconfigured. However, the structure of the key
chain should cover data nodes beyond those in <xref target="RFC8177"/>, main
ly
SendID and RecvID (<xref section="3.1" sectionFormat="of" target="RFC5925"/>
).</t>
</dd> </dd>
</dl> </dl>
<t>For each neighbor, the following data nodes are supported in additi on to similar parameters that are provided for a peer group:</t> <t>For each neighbor, the following data nodes are supported in additi on to similar parameters that are provided for a peer group:</t>
<dl>
<dl spacing="normal" newline="false">
<dt>'remote-address':</dt> <dt>'remote-address':</dt>
<dd> <dd>
<t>Specifies the remote IP address of a BGP neighbor.</t> <t>Specifies the remote IP address of a BGP neighbor.</t>
</dd> </dd>
<dt>'peer-group':</dt> <dt>'peer-group':</dt>
<dd> <dd>
<t>A name of a peer group.</t> <t>A name of a peer group.</t>
</dd> <t>Parameters that are provided at the 'neighbor' level take
<dt/> precedence over the ones provided in the peer group.</t>
<dd>
<t>Parameters that are provided at the 'neighbor' level takes prec
edence over the ones provided in the peer group.</t>
</dd> </dd>
<dt>'status':</dt> <dt>'status':</dt>
<dd> <dd>
<t>Indicates the status of the BGP session.</t> <t>Indicates the status of the BGP session.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-ospf-rtg"> <section anchor="sec-ospf-rtg">
<name>OSPF</name> <name>OSPF</name>
<t>The OSPF routing subtree structure is shown in <xref target="ospf-t ree"/>.</t> <t>The OSPF routing subtree structure is shown in <xref target="ospf-t ree"/>.</t>
<figure anchor="ospf-tree"> <figure anchor="ospf-tree">
<name>OSPF Routing Tree Structure</name> <name>OSPF Routing Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw module: ietf-ac-ntw
augment /nw:networks/nw:network: augment /nw:networks/nw:network:
+--rw ac-profile* [name] +--rw ac-profile* [name]
+--rw name string +--rw name string
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw bgp {vpn-common:rtg-bgp}? | +--rw bgp {vpn-common:rtg-bgp}?
| | ... | | ...
skipping to change at line 2043 skipping to change at line 2012
| +--rw rip {vpn-common:rtg-rip}? | +--rw rip {vpn-common:rtg-rip}?
| | ... | | ...
| +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw vrrp {vpn-common:rtg-vrrp}?
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The following OSPF data nodes are supported:</t> <t>The following OSPF data nodes are supported:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'address-family':</dt> <dt>'address-family':</dt>
<dd> <dd>
<t>Indicates whether IPv4, IPv6, or both address <t>Indicates whether IPv4, IPv6, or both address families are to
families are to be activated.</t> be activated.</t>
</dd> <t>When the IPv4 or dual-stack address family is requested, it
<dt/> is up to the implementation (e.g., network orchestrator) to
<dd> decide whether OSPFv2 <xref target="RFC4577"/> or OSPFv3 <xref
<t>When the IPv4 or dual-stack address family is requested, it is target="RFC6565"/> is used to announce IPv4 routes.</t>
up
to the implementation (e.g., network orchestrator) to decide
whether OSPFv2 <xref target="RFC4577"/> or OSPFv3 <xref target="RFC6565"/> i
s used to announce
IPv4 routes.</t>
</dd> </dd>
<dt>'area-id':</dt> <dt>'area-id':</dt>
<dd> <dd>
<t>Indicates the OSPF Area ID.</t> <t>Indicates the OSPF Area ID.</t>
</dd> </dd>
<dt>'metric':</dt> <dt>'metric':</dt>
<dd> <dd>
<t>Associates a metric with OSPF routes.</t> <t>Associates a metric with OSPF routes.</t>
</dd> </dd>
<dt>'sham-links':</dt> <dt>'sham-links':</dt>
<dd> <dd>
<t>Used to create OSPF sham links between two ACs sharing the same <t>Used to create OSPF sham links between two ACs sharing the
area and having a backdoor link same area and having a backdoor link (<xref section="4.2.7"
(<xref section="4.2.7" sectionFormat="of" target="RFC4577"/> and <xref sectio sectionFormat="of" target="RFC4577"/> and <xref section="5"
n="5" sectionFormat="of" target="RFC6565"/>).</t> sectionFormat="of" target="RFC6565"/>).</t>
</dd> </dd>
<dt>'max-lsa':</dt> <dt>'max-lsa':</dt>
<dd> <dd>
<t>Sets the maximum number of Link State Advertisements <t>Sets the maximum number of Link State Advertisements (LSAs)
(LSAs) that the OSPF instance will accept.</t> that the OSPF instance will accept.</t>
</dd> </dd>
<dt>'passive':</dt> <dt>'passive':</dt>
<dd> <dd>
<t>Controls whether an OSPF interface is passive or active.</t> <t>Controls whether an OSPF interface is passive or active.</t>
</dd> </dd>
<dt>'authentication':</dt> <dt>'authentication':</dt>
<dd> <dd>
<t>Controls the authentication schemes to be enabled <t>Controls the authentication schemes to be enabled for the
for the OSPF instance. The module supports authentication options that are co OSPF instance. The module supports authentication options that
mmon to both OSPF versions: the Authentication are common to both OSPF versions: the Authentication Trailer for
Trailer for OSPFv2 <xref target="RFC5709"/> <xref target="RFC7474"/> and OSPF OSPFv2 <xref target="RFC5709"/> <xref target="RFC7474"/> and
v3 <xref target="RFC7166"/>; as such, the model does not support <xref target="R OSPFv3 <xref target="RFC7166"/>; as such, the model does not
FC4552"/>.</t> support <xref target="RFC4552"/>.</t>
</dd> </dd>
<dt>'status':</dt> <dt>'status':</dt>
<dd> <dd>
<t>Indicates the status of the OSPF routing instance.</t> <t>Indicates the status of the OSPF routing instance.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-isis-rtg"> <section anchor="sec-isis-rtg">
<name>IS-IS</name> <name>IS-IS</name>
<t>The IS-IS routing subtree structure is shown in <xref target="isis- tree"/>.</t> <t>The IS-IS routing subtree structure is shown in <xref target="isis- tree"/>.</t>
<figure anchor="isis-tree"> <figure anchor="isis-tree">
<name>IS-IS Routing Tree Structure</name> <name>IS-IS Routing Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw module: ietf-ac-ntw
augment /nw:networks/nw:network: augment /nw:networks/nw:network:
+--rw ac-profile* [name] +--rw ac-profile* [name]
+--rw name string +--rw name string
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw bgp {vpn-common:rtg-bgp}? | +--rw bgp {vpn-common:rtg-bgp}?
| | ... | | ...
skipping to change at line 2180 skipping to change at line 2151
| +--rw rip {vpn-common:rtg-rip}? | +--rw rip {vpn-common:rtg-rip}?
| | ... | | ...
| +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw vrrp {vpn-common:rtg-vrrp}?
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The following IS-IS data nodes are supported:</t> <t>The following IS-IS data nodes are supported:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'address-family':</dt> <dt>'address-family':</dt>
<dd> <dd>
<t>Indicates whether IPv4, IPv6, or both address families are to b e activated.</t> <t>Indicates whether IPv4, IPv6, or both address families are to b e activated.</t>
</dd> </dd>
<dt>'area-address':</dt> <dt>'area-address':</dt>
<dd> <dd>
<t>Indicates the IS-IS area address.</t> <t>Indicates the IS-IS area address.</t>
</dd> </dd>
<dt>'level':</dt> <dt>'level':</dt>
<dd> <dd>
skipping to change at line 2206 skipping to change at line 2177
<dt>'metric':</dt> <dt>'metric':</dt>
<dd> <dd>
<t>Associates a metric with IS-IS routes.</t> <t>Associates a metric with IS-IS routes.</t>
</dd> </dd>
<dt>'passive':</dt> <dt>'passive':</dt>
<dd> <dd>
<t>Controls whether an IS-IS interface is passive or active.</t> <t>Controls whether an IS-IS interface is passive or active.</t>
</dd> </dd>
<dt>'authentication':</dt> <dt>'authentication':</dt>
<dd> <dd>
<t>Controls the authentication schemes to be enabled <t>Controls the authentication schemes to be enabled for the
for the IS-IS instance. Both the specification of a key chain IS-IS instance. Both the specification of a key chain <xref
<xref target="RFC8177"/> and the direct specification of key and authentication target="RFC8177"/> and the direct specification of key and
algorithms are supported.</t> authentication algorithms are supported.</t>
</dd> </dd>
<dt>'status':</dt> <dt>'status':</dt>
<dd> <dd>
<t>Indicates the status of the IS-IS routing instance.</t> <t>Indicates the status of the IS-IS routing instance.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-rip-rtg"> <section anchor="sec-rip-rtg">
<name>RIP</name> <name>RIP</name>
<t>The RIP routing subtree structure is shown in <xref target="rip-tre e"/>.</t> <t>The RIP routing subtree structure is shown in <xref target="rip-tre e"/>.</t>
<figure anchor="rip-tree"> <figure anchor="rip-tree">
<name>RIP Routing Tree Structure</name> <name>RIP Routing Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw module: ietf-ac-ntw
augment /nw:networks/nw:network: augment /nw:networks/nw:network:
+--rw ac-profile* [name] +--rw ac-profile* [name]
+--rw name string +--rw name string
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw bgp {vpn-common:rtg-bgp}? | +--rw bgp {vpn-common:rtg-bgp}?
| | ... | | ...
skipping to change at line 2307 skipping to change at line 2279
| | +--ro status? identityref | | +--ro status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
| +--rw vrrp | +--rw vrrp
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The following RIP data nodes are supported:</t> <t>The following RIP data nodes are supported:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'address-family':</dt> <dt>'address-family':</dt>
<dd> <dd>
<t>Indicates whether IPv4, IPv6, or both address <t>Indicates whether IPv4, IPv6, or both address families are to
families are to be activated. This parameter is used to determine be activated. This parameter is used to determine whether RIPv2
whether RIPv2 <xref target="RFC2453"/>, RIP Next Generation (RIPng) <xref tar <xref target="RFC2453"/>, RIP Next Generation (RIPng) <xref
get="RFC2080"/>, or both are target="RFC2080"/>, or both are to be enabled.</t>
to be enabled.</t>
</dd> </dd>
<dt>'timers':</dt> <dt>'timers':</dt>
<dd> <dd>
<t>Indicates the following timers (expressed in seconds): <t>Indicates the following timers (expressed in seconds):</t>
</t> <dl spacing="normal" newline="false">
<ul spacing="normal">
<li>
<dl>
<dt>'update-interval':</dt> <dt>'update-interval':</dt>
<dd> <dd>
<t>The interval at which RIP updates are sent.</t> <t>The interval at which RIP updates are sent.</t>
</dd> </dd>
</dl>
</li>
<li>
<dl>
<dt>'invalid-interval':</dt> <dt>'invalid-interval':</dt>
<dd> <dd>
<t>The interval before a RIP route is declared invalid.</t > <t>The interval before a RIP route is declared invalid.</t >
</dd> </dd>
</dl>
</li>
<li>
<dl>
<dt>'holddown-interval':</dt> <dt>'holddown-interval':</dt>
<dd> <dd>
<t>The interval before better RIP routes are released.</t> <t>The interval before better RIP routes are released.</t>
</dd> </dd>
</dl>
</li>
<li>
<dl>
<dt>'flush-interval':</dt> <dt>'flush-interval':</dt>
<dd> <dd>
<t>The interval before a route is removed from the routing table.</t> <t>The interval before a route is removed from the routing table.</t>
</dd> </dd>
</dl> </dl>
</li>
</ul>
</dd> </dd>
<dt>'default-metric':</dt> <dt>'default-metric':</dt>
<dd> <dd>
<t>Sets the default RIP metric.</t> <t>Sets the default RIP metric.</t>
</dd> </dd>
<dt>'authentication':</dt> <dt>'authentication':</dt>
<dd> <dd>
<t>Controls the authentication schemes to be enabled for the RIP i nstance.</t> <t>Controls the authentication schemes to be enabled for the RIP i nstance.</t>
</dd> </dd>
<dt>'status':</dt> <dt>'status':</dt>
<dd> <dd>
<t>Indicates the status of the RIP routing instance.</t> <t>Indicates the status of the RIP routing instance.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-VRRP-rtg"> <section anchor="sec-VRRP-rtg">
<name>VRRP</name> <name>VRRP</name>
<t>The VRRP subtree structure is shown in <xref target="vrrp-tree"/>.< /t> <t>The VRRP subtree structure is shown in <xref target="vrrp-tree"/>.< /t>
<figure anchor="vrrp-tree"> <figure anchor="vrrp-tree">
<name>VRRP Tree Structure</name> <name>VRRP Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw module: ietf-ac-ntw
augment /nw:networks/nw:network: augment /nw:networks/nw:network:
+--rw ac-profile* [name] +--rw ac-profile* [name]
+--rw name string +--rw name string
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw bgp {vpn-common:rtg-bgp}? | +--rw bgp {vpn-common:rtg-bgp}?
| | ... | | ...
skipping to change at line 2445 skipping to change at line 2400
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The following VRRP data nodes are supported:</t> <t>The following VRRP data nodes are supported:</t>
<dl> <dl newline="false" spacing="normal">
<dt>'address-family':</dt> <dt>'address-family':</dt>
<dd> <dd>
<t>Indicates whether IPv4, IPv6, or both address <t>Indicates whether IPv4, IPv6, or both address
families are to be activated. Note that VRRP version 3 <xref target="RFC9568 "/> families are to be activated. Note that VRRP version 3 <xref target="RFC9568 "/>
supports both IPv4 and IPv6.</t> supports both IPv4 and IPv6.</t>
</dd> </dd>
<dt>'vrrp-group':</dt> <dt>'vrrp-group':</dt>
<dd> <dd>
<t>Used to identify the VRRP group.</t> <t>Used to identify the VRRP group.</t>
</dd> </dd>
skipping to change at line 2489 skipping to change at line 2444
</dl> </dl>
<t>Note that no authentication data node is included for VRRP, as ther e <t>Note that no authentication data node is included for VRRP, as ther e
isn't any type of VRRP authentication at this time (see <xref section="9" sectio nFormat="of" target="RFC9568"/>).</t> isn't any type of VRRP authentication at this time (see <xref section="9" sectio nFormat="of" target="RFC9568"/>).</t>
</section> </section>
</section> </section>
<section anchor="sec-oam"> <section anchor="sec-oam">
<name>OAM</name> <name>OAM</name>
<t>The OAM subtree structure is shown in <xref target="oam-tree"/>.</t> <t>The OAM subtree structure is shown in <xref target="oam-tree"/>.</t>
<figure anchor="oam-tree"> <figure anchor="oam-tree">
<name>OAM Tree Structure</name> <name>OAM Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
augment /nw:networks/nw:network: augment /nw:networks/nw:network:
+--rw ac-profile* [name] +--rw ac-profile* [name]
+--rw name string +--rw name string
+--rw routing-protocols +--rw routing-protocols
| ... | ...
+--rw oam +--rw oam
+--rw bfd {vpn-common:bfd}? +--rw bfd {vpn-common:bfd}?
+--rw session-type? identityref +--rw session-type? identityref
+--rw desired-min-tx-interval? uint32 +--rw desired-min-tx-interval? uint32
+--rw required-min-rx-interval? uint32 +--rw required-min-rx-interval? uint32
skipping to change at line 2539 skipping to change at line 2494
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The following OAM data nodes can be specified for each BFD session:</ t> <t>The following OAM data nodes can be specified for each BFD session:</ t>
<dl> <dl spacing="normal" newline="false">
<dt>'dest-addr':</dt> <dt>'dest-addr':</dt>
<dd> <dd>
<t>Specifies the BFD peer address. This data node is mapped to 'remo te-address' of BFD container in <xref target="I-D.ietf-opsawg-teas-attachment-ci rcuit"/>. 'dest-address' is used here to ease the mapping with the underlying de vice model defind in <xref target="RFC9127"/>.</t> <t>Specifies the BFD peer address. This data node is mapped to 'remo te-address' of the BFD container in <xref target="RFC9834"/>. 'dest-address' is used here to ease the mapping with the underlying device model defined in <xref target="RFC9127"/>.</t>
</dd> </dd>
<dt>'source-address':</dt> <dt>'source-address':</dt>
<dd> <dd>
<t>Specifies the local IP address or interface to use for the sessio n. This data node is mapped to 'local-address' of BFD container in <xref target= "I-D.ietf-opsawg-teas-attachment-circuit"/>. 'source-address' is used here to ea se the mapping with the underlying device model defind in <xref target="RFC9127" />.</t> <t>Specifies the local IP address or interface to use for the sessio n. This data node is mapped to 'local-address' of the BFD container in <xref tar get="RFC9834"/>. 'source-address' is used here to ease the mapping with the unde rlying device model defined in <xref target="RFC9127"/>.</t>
</dd> </dd>
<dt>'failure-detection-profile-ref':</dt> <dt>'failure-detection-profile-ref':</dt>
<dd> <dd>
<t>Refers to a BFD profile in <xref target="sec-profiles"/>.</t> <t>Refers to a BFD profile in <xref target="sec-profiles"/>.</t>
</dd> </dd>
<dt>'network-ref':</dt> <dt>'network-ref':</dt>
<dd> <dd>
<t>Includes a network reference to uniquely identify a BFD profile.< /t> <t>Includes a network reference to uniquely identify a BFD profile.< /t>
</dd> </dd>
<dt>'session-type':</dt> <dt>'session-type':</dt>
<dd> <dd>
<t>Indicates which BFD flavor is used to set up the session (e.g., c lassic BFD <xref target="RFC5880"/>, Seamless BFD <xref target="RFC7880"/>). By default, it is assumed that the BFD session will follow the behavior specified i n <xref target="RFC5880"/>.</t> <t>Indicates which BFD flavor is used to set up the session (e.g., c lassic BFD <xref target="RFC5880"/>, Seamless BFD <xref target="RFC7880"/>). By default, it is assumed that the BFD session will follow the behavior specified i n <xref target="RFC5880"/>.</t>
</dd> </dd>
<dt>'desired-min-tx-interval':</dt> <dt>'desired-min-tx-interval':</dt>
<dd> <dd>
<t>The minimum interval, in microseconds, to use when transmitting B FD Control packets, less any jitter applied.</t> <t>The minimum interval, in microseconds, to use when transmitting B FD Control packets, less any jitter applied.</t>
</dd> </dd>
<dt>'required-min-rx-interval':</dt> <dt>'required-min-rx-interval':</dt>
<dd> <dd>
<t>The minimum interval, in microseconds, between received BFD Contr ol packets less any jitter applied by the sender.</t> <t>The minimum interval, in microseconds, between received BFD Contr ol packets, less any jitter applied by the sender.</t>
</dd> </dd>
<dt>'local-multiplier':</dt> <dt>'local-multiplier':</dt>
<dd> <dd>
<t>The negotiated transmit interval, multiplied by this value, provi des the detection time for the peer.</t> <t>The negotiated transmit interval, multiplied by this value, provi des the detection time for the peer.</t>
</dd> </dd>
<dt>'holdtime':</dt> <dt>'holdtime':</dt>
<dd> <dd>
<t>Used to indicate the expected BFD holddown time, in milliseconds. </t> <t>Used to indicate the expected BFD holddown time, in milliseconds. </t>
</dd> </dd>
<dt>'authentication':</dt> <dt>'authentication':</dt>
<dd> <dd>
<t>Includes the required information to enable the BFD authenticatio n modes discussed in <xref section="6.7" sectionFormat="of" target="RFC5880"/>. In particular, 'meticulous' controls the activation of meticulous mode as discus sed in Sections 6.7.3 and 6.7.4 of <xref target="RFC5880"/>.</t> <t>Includes the required information to enable the BFD authenticatio n modes discussed in <xref section="6.7" sectionFormat="of" target="RFC5880"/>. In particular, 'meticulous' controls the activation of meticulous mode as discus sed in Sections <xref target="RFC5880" sectionFormat="bare" section="6.7.3"/> an d <xref target="RFC5880" sectionFormat="bare" section="6.7.4"/> of <xref target= "RFC5880"/>.</t>
</dd> </dd>
<dt>'status':</dt> <dt>'status':</dt>
<dd> <dd>
<t>Indicates the status of BFD.</t> <t>Indicates the status of BFD.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-sec"> <section anchor="sec-sec">
<name>Security</name> <name>Security</name>
<t>The security subtree structure is shown in <xref target="sec-tree"/>. The 'security' container specifies the the encryption to be applied to traffic for a given AC. The model can be used to directly control the encryption to be a pplied (e.g., Layer 2 or Layer 3 encryption) or invoke a local encryption profil e.</t> <t>The security subtree structure is shown in <xref target="sec-tree"/>. The 'security' container specifies the encryption to be applied to traffic for a given AC. The model can be used to directly control the encryption to be appli ed (e.g., Layer 2 or Layer 3 encryption) or invoke a local encryption profile.</ t>
<figure anchor="sec-tree"> <figure anchor="sec-tree">
<name>Security Tree Structure</name> <name>Security Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
augment /nw:networks/nw:network/nw:node: augment /nw:networks/nw:network/nw:node:
+--rw ac* [name] +--rw ac* [name]
+--rw name string +--rw name string
+ ... + ...
+--rw l2-connection {ac-common:layer2-ac}? +--rw l2-connection {ac-common:layer2-ac}?
| ... | ...
+--rw ip-connection {ac-common:layer3-ac}? +--rw ip-connection {ac-common:layer3-ac}?
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| ... | ...
skipping to change at line 2618 skipping to change at line 2574
| +--rw encryption {vpn-common:encryption}? | +--rw encryption {vpn-common:encryption}?
| | +--rw enabled? boolean | | +--rw enabled? boolean
| | +--rw layer? enumeration | | +--rw layer? enumeration
| +--rw encryption-profile | +--rw encryption-profile
| +--rw (profile)? | +--rw (profile)?
| +--:(provider-profile) | +--:(provider-profile)
| | +--rw encryption-profile-ref? leafref | | +--rw encryption-profile-ref? leafref
| | +--rw network-ref? | | +--rw network-ref?
| | -> /nw:networks/network/network-id | | -> /nw:networks/network/network-id
| +--:(customer-profile) | +--:(customer-profile)
| +--rw customer-key-chain? key-chain:key-chain-ref | +--rw customer-key-chain? key-chain:key-chain-ref
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="sec-svc"> <section anchor="sec-svc">
<name>Service</name> <name>Service</name>
<t>The service subtree structure is shown in <xref target="svc-tree"/>.< /t> <t>The service subtree structure is shown in <xref target="svc-tree"/>.< /t>
<figure anchor="svc-tree"> <figure anchor="svc-tree">
<name>Service Tree Structure</name> <name>Service Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
augment /nw:networks/nw:network/nw:node: augment /nw:networks/nw:network/nw:node:
+--rw ac* [name] +--rw ac* [name]
+--rw name string +--rw name string
+ ... + ...
+--rw l2-connection {ac-common:layer2-ac}? +--rw l2-connection {ac-common:layer2-ac}?
| ... | ...
+--rw ip-connection {ac-common:layer3-ac}? +--rw ip-connection {ac-common:layer3-ac}?
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| ... | ...
skipping to change at line 2699 skipping to change at line 2655
| +--rw qos-profile-ref leafref | +--rw qos-profile-ref leafref
| +--rw network-ref? | +--rw network-ref?
| | -> /nw:networks/network/network-id | | -> /nw:networks/network/network-id
| +--rw direction? identityref | +--rw direction? identityref
+--rw access-control-list +--rw access-control-list
+--rw acl-profiles +--rw acl-profiles
+--rw acl-profile* [forwarding-profile-ref] +--rw acl-profile* [forwarding-profile-ref]
+--rw forwarding-profile-ref leafref +--rw forwarding-profile-ref leafref
+--rw network-ref? +--rw network-ref?
-> /nw:networks/network/network-id -> /nw:networks/network/network-id
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The description of the service data nodes is as follows:</t> <t>The service data nodes are defined as follows:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'mtu':</dt> <dt>'mtu':</dt>
<dd> <dd>
<t>Specifies the Layer 2 MTU, in bytes, for the AC.</t> <t>Specifies the Layer 2 MTU, in bytes, for the AC.</t>
</dd> </dd>
<dt>'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth':</dt> <dt>'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth':</dt>
<dd> <dd>
<t>Specify the service bandwidth for the AC.</t> <t>Specify the service bandwidth for the AC.</t>
</dd> <dl newline="false" spacing="normal">
<dt/> <dt>'svc-pe-to-ce-bandwidth':</dt> <dd>Indicates the inbound bandw
<dd> idth of the connection (i.e., download bandwidth from the service provider to th
<t>'svc-pe-to-ce-bandwidth' indicates the inbound bandwidth of the c e site).</dd>
onnection (i.e., download bandwidth from the service provider to the site).</t> <dt>'svc-ce-to-pe-bandwidth':</dt> <dd>Indicates the outbound band
</dd> width of the connection (i.e., upload bandwidth from the site to the service pro
<dt/> vider).</dd>
<dd> </dl>
<t>'svc-ce-to-pe-bandwidth' indicates the outbound bandwidth of the
connection (i.e., upload bandwidth from the site to the service provider).</t>
</dd>
<dt/>
<dd>
<t>'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth' can be repr esented using the Committed Information Rate (CIR), the Committed Burst Size (CB S), the Excess Information Rate (EIR), the Excess Burst Size (EBS), the Peak Inf ormation Rate (PIR), and the Peak Burst Size (PBS). CIR, EIR, and PIR are expres sed in bps, while CBS, EBS, and PBS are expressed in bytes.</t> <t>'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth' can be repr esented using the Committed Information Rate (CIR), the Committed Burst Size (CB S), the Excess Information Rate (EIR), the Excess Burst Size (EBS), the Peak Inf ormation Rate (PIR), and the Peak Burst Size (PBS). CIR, EIR, and PIR are expres sed in bps, while CBS, EBS, and PBS are expressed in bytes.</t>
</dd>
<dt/>
<dd>
<t>The following types, defined in <xref target="RFC9181"/>, can be used to indicate the bandwidth type:</t> <t>The following types, defined in <xref target="RFC9181"/>, can be used to indicate the bandwidth type:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'bw-per-cos':</dt> <dt>'bw-per-cos':</dt>
<dd> <dd>
<t>The bandwidth is per CoS.</t> <t>The bandwidth is per Class of Service (CoS).</t>
</dd> </dd>
<dt>'bw-per-port':</dt> <dt>'bw-per-port':</dt>
<dd> <dd>
<t>The bandwidth is per port.</t> <t>The bandwidth is per port.</t>
</dd> </dd>
<!--[rfced] To improve readability, may we update "to" to "for"?
Original:
'bw-per-site': The bandwidth is to all peer SAPs that belong to
the same site.
Perhaps:
'bw-per-site': The bandwidth is for all peer SAPs that belong to
the same site.
-->
<dt>'bw-per-site':</dt> <dt>'bw-per-site':</dt>
<dd> <dd>
<t>The bandwidth is to all peer SAPs that belong to the same sit e.</t> <t>The bandwidth is to all peer SAPs that belong to the same sit e.</t>
</dd> </dd>
<dt>'bw-per-service':</dt> <dt>'bw-per-service':</dt>
<dd> <dd>
<t>The bandwidth is per service instance that is bound to an AC. </t> <t>The bandwidth is per service instance that is bound to an AC. </t>
</dd> </dd>
</dl> </dl>
</dd> </dd>
skipping to change at line 2754 skipping to change at line 2711
</dd> </dd>
<dt>'qos':</dt> <dt>'qos':</dt>
<dd> <dd>
<t>Specifies a list of QoS profiles to apply for this AC.</t> <t>Specifies a list of QoS profiles to apply for this AC.</t>
</dd> </dd>
<dt>'access-control-list':</dt> <dt>'access-control-list':</dt>
<dd> <dd>
<t>Specifies a list of ACL profiles to apply for this AC.</t> <t>Specifies a list of ACL profiles to apply for this AC.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="sec-module"> <section anchor="sec-module">
<name>YANG Module</name> <name>YANG Module</name>
<t>This module uses types defined in <xref target="RFC6991"/>, <xref targe <t>This module uses types defined in <xref target="RFC6991"/>, <xref targe
t="RFC8177"/>, <xref target="RFC8294"/>, <xref target="RFC8343"/>, <xref target= t="RFC8177"/>, <xref target="RFC8294"/>, <xref target="RFC8343"/>, <xref target=
"RFC9067"/>, <xref target="RFC9181"/>, <xref target="I-D.ietf-opsawg-teas-common "RFC9067"/>, <xref target="RFC9181"/>, <xref target="RFC9833"/>, and <xref targe
-ac"/>, and <xref target="IEEE802.1Qcp"/>.</t> t="IEEE802.1Qcp"/>.</t>
<sourcecode type="yang"><![CDATA[
<CODE BEGINS> file "ietf-ac-ntw@2025-01-07.yang" <!--[rfced] FYI, this YANG module has been updated per the
formatting option of pyang. Please let us know any concerns.
-->
<sourcecode type="yang" name="ietf-ac-ntw@2025-08-11.yang" markers="true">
<![CDATA[
module ietf-ac-ntw { module ietf-ac-ntw {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ac-ntw"; namespace "urn:ietf:params:xml:ns:yang:ietf-ac-ntw";
prefix ac-ntw; prefix ac-ntw;
import ietf-vpn-common { import ietf-vpn-common {
prefix vpn-common; prefix vpn-common;
reference reference
"RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3
VPNs"; VPNs";
skipping to change at line 2812 skipping to change at line 2773
} }
import ietf-network { import ietf-network {
prefix nw; prefix nw;
reference reference
"RFC 8345: A YANG Data Model for Network Topologies, "RFC 8345: A YANG Data Model for Network Topologies,
Section 6.1"; Section 6.1";
} }
import ietf-sap-ntw { import ietf-sap-ntw {
prefix sap; prefix sap;
reference reference
"RFC 9408: A YANG Network Model for Service Attachment "RFC 9408: A YANG Network Data Model for Service Attachment
Points (SAPs)"; Points (SAPs)";
} }
import ietf-ac-common { import ietf-ac-common {
prefix ac-common; prefix ac-common;
reference reference
"RFC CCCC: A Common YANG Data Model for Attachment Circuits"; "RFC 9833: A Common YANG Data Model for Attachment Circuits";
} }
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)";
} }
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
skipping to change at line 2857 skipping to change at line 2818
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 9835; 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 Network Data Model for Attachment Circuits"; "RFC 9835: A YANG Network Data Model for Attachment Circuits";
} }
// References // References
/* A set of groupings to ease referencing cross-modules */ /* A set of groupings to ease referencing cross-modules */
grouping attachment-circuit-reference { grouping attachment-circuit-reference {
description description
"This grouping can be used to reference an attachment circuit "This grouping can be used to reference an attachment circuit
in a specific node."; in a specific node.";
leaf ac-ref { leaf ac-ref {
type leafref { type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../" path "/nw:networks/nw:network[nw:network-id=current()/../"
+ "network-ref]/nw:node[nw:node-id=current()/../" + "network-ref]/nw:node[nw:node-id=current()/../"
+ "node-ref]/ac-ntw:ac/ac-ntw:name"; + "node-ref]/ac-ntw:ac/ac-ntw:name";
require-instance false; require-instance false;
} }
description description
"An absolute reference to an attachment circuit."; "An absolute reference to an attachment circuit.";
} }
uses nw:node-ref; uses nw:node-ref;
} }
grouping attachment-circuit-references { grouping attachment-circuit-references {
description description
"This grouping can be used to reference a list of attachment "This grouping can be used to reference a list of attachment
circuits in a specific node."; circuits in a specific node.";
leaf-list ac-ref { leaf-list ac-ref {
type leafref { type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../" path "/nw:networks/nw:network[nw:network-id=current()/../"
+ "network-ref]/nw:node[nw:node-id=current()/../" + "network-ref]/nw:node[nw:node-id=current()/../"
+ "node-ref]/ac-ntw:ac/ac-ntw:name"; + "node-ref]/ac-ntw:ac/ac-ntw:name";
require-instance false; require-instance false;
} }
description description
"An absolute reference to an attachment circuit."; "An absolute reference to an attachment circuit.";
} }
uses nw:node-ref; uses nw:node-ref;
} }
grouping ac-profile-reference { grouping ac-profile-reference {
description description
"This grouping can be used to reference an attachment circuit "This grouping can be used to reference an attachment circuit
profile."; profile.";
leaf ac-profile-ref { leaf ac-profile-ref {
type leafref { type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../" path "/nw:networks/nw:network[nw:network-id=current()/../"
+ "network-ref]/ac-ntw:ac-profile/ac-ntw:name"; + "network-ref]/ac-ntw:ac-profile/ac-ntw:name";
require-instance false; require-instance false;
} }
description description
"An absolute reference to an attachment circuit."; "An absolute reference to an attachment circuit.";
} }
uses nw:network-ref; uses nw:network-ref;
} }
grouping encryption-profile-reference { grouping encryption-profile-reference {
description description
"This grouping can be used to reference encryption "This grouping can be used to reference an encryption
profile."; profile.";
leaf encryption-profile-ref { leaf encryption-profile-ref {
type leafref { type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../" path "/nw:networks/nw:network[nw:network-id=current()/../"
+ "network-ref]" + "network-ref]"
+ "/ac-ntw:specific-provisioning-profiles" + "/ac-ntw:specific-provisioning-profiles"
+ "/ac-ntw:valid-provider-identifiers" + "/ac-ntw:valid-provider-identifiers"
+ "/ac-ntw:encryption-profile-identifier/ac-ntw:id"; + "/ac-ntw:encryption-profile-identifier/ac-ntw:id";
require-instance false; require-instance false;
} }
description description
"An absolute reference to an encryption profile."; "An absolute reference to an encryption profile.";
} }
uses nw:network-ref; uses nw:network-ref;
} }
grouping qos-profile-reference { grouping qos-profile-reference {
description description
"This grouping can be used to reference a QoS profile."; "This grouping can be used to reference a QoS profile.";
leaf qos-profile-ref { leaf qos-profile-ref {
type leafref { type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../" path "/nw:networks/nw:network[nw:network-id=current()/../"
+ "network-ref]" + "network-ref]"
+ "/ac-ntw:specific-provisioning-profiles" + "/ac-ntw:specific-provisioning-profiles"
+ "/ac-ntw:valid-provider-identifiers" + "/ac-ntw:valid-provider-identifiers"
+ "/ac-ntw:qos-profile-identifier/ac-ntw:id"; + "/ac-ntw:qos-profile-identifier/ac-ntw:id";
require-instance false; require-instance false;
} }
description description
"An absolute reference to a QoS profile."; "An absolute reference to a QoS profile.";
} }
uses nw:network-ref; uses nw:network-ref;
} }
grouping failure-detection-profile-reference { grouping failure-detection-profile-reference {
description description
"This grouping can be used to reference a failure detection "This grouping can be used to reference a failure detection
profile."; profile.";
leaf failure-detection-profile-ref { leaf failure-detection-profile-ref {
type leafref { type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../" path "/nw:networks/nw:network[nw:network-id=current()/../"
+ "network-ref]" + "network-ref]"
+ "/ac-ntw:specific-provisioning-profiles" + "/ac-ntw:specific-provisioning-profiles"
+ "/ac-ntw:valid-provider-identifiers" + "/ac-ntw:valid-provider-identifiers"
+ "/ac-ntw:failure-detection-profile-identifier/ac-ntw:id"; + "/ac-ntw:failure-detection-profile-identifier/ac-ntw:id";
require-instance false; require-instance false;
} }
description description
"An absolute reference to a failure detection profile."; "An absolute reference to a failure detection profile.";
} }
uses nw:network-ref; uses nw:network-ref;
} }
grouping forwarding-profile-reference { grouping forwarding-profile-reference {
description description
"This grouping can be used to reference a forwarding profile."; "This grouping can be used to reference a forwarding profile.";
leaf forwarding-profile-ref { leaf forwarding-profile-ref {
type leafref { type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../" path "/nw:networks/nw:network[nw:network-id=current()/../"
+ "network-ref]" + "network-ref]"
+ "/ac-ntw:specific-provisioning-profiles" + "/ac-ntw:specific-provisioning-profiles"
+ "/ac-ntw:valid-provider-identifiers" + "/ac-ntw:valid-provider-identifiers"
+ "/ac-ntw:forwarding-profile-identifier/ac-ntw:id"; + "/ac-ntw:forwarding-profile-identifier/ac-ntw:id";
require-instance false; require-instance false;
} }
description description
"An absolute reference to a forwarding profile."; "An absolute reference to a forwarding profile.";
} }
uses nw:network-ref; uses nw:network-ref;
} }
grouping routing-profile-reference { grouping routing-profile-reference {
description description
"This grouping can be used to reference a routing profile."; "This grouping can be used to reference a routing profile.";
leaf routing-profile-ref { leaf routing-profile-ref {
type leafref { type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../" path "/nw:networks/nw:network[nw:network-id=current()/../"
+ "network-ref]" + "network-ref]"
+ "/ac-ntw:specific-provisioning-profiles" + "/ac-ntw:specific-provisioning-profiles"
+ "/ac-ntw:valid-provider-identifiers" + "/ac-ntw:valid-provider-identifiers"
+ "/ac-ntw:routing-profile-identifier/ac-ntw:id"; + "/ac-ntw:routing-profile-identifier/ac-ntw:id";
require-instance false; require-instance false;
} }
description description
"An absolute reference to a routing profile."; "An absolute reference to a routing profile.";
} }
uses nw:network-ref; uses nw:network-ref;
} }
// Layer 2 connection // Layer 2 connection
skipping to change at line 3041 skipping to change at line 3002
+ "'vpn-common:dot1q')" { + "'vpn-common:dot1q')" {
description description
"Only applies when the type of the tagged interface is "Only applies when the type of the tagged interface is
'dot1q'."; 'dot1q'.";
} }
description description
"Tagged interface."; "Tagged interface.";
uses ac-common:dot1q; uses ac-common:dot1q;
container tag-operations { container tag-operations {
description description
"Sets the tag manipulation policy for this AC. It defines "Sets the tag manipulation policy for this AC. It
a set of tag manipulations that allow for the insertion, defines a set of tag manipulations that allow for the
removal, or rewriting of 802.1Q VLAN tags. These insertion, removal, or rewriting of 802.1Q VLAN tags.
operations are indicated for the CE-PE direction. These operations are indicated for the CE-PE direction.
By default, tag operations are symmetric. As such, the By default, tag operations are symmetric. As such, the
reverse tag operation is assumed on the PE-CE reverse tag operation is assumed on the PE-CE
direction."; direction.";
choice op-choice { choice op-choice {
description description
"Selects the tag rewriting policy for an AC."; "Selects the tag rewriting policy for an AC.";
leaf pop { leaf pop {
type empty; type empty;
description description
"Pop the outer tag."; "Pop the outer tag.";
} }
skipping to change at line 3067 skipping to change at line 3028
type empty; type empty;
description description
"Pushes one or two tags defined by the tag-1 and "Pushes one or two tags defined by the tag-1 and
tag-2 leaves. It is assumed that, absent any tag-2 leaves. It is assumed that, absent any
policy, the default value of 0 will be used for policy, the default value of 0 will be used for
the Priority Code Point (PCP) setting."; the Priority Code Point (PCP) setting.";
} }
leaf translate { leaf translate {
type empty; type empty;
description description
"Translates the outer tag to one or two tags. PCP "Translates the outer tag to one or two tags. PCP
bits are preserved."; bits are preserved.";
} }
} }
leaf tag-1 { leaf tag-1 {
when 'not(../pop)'; when 'not(../pop)';
type dot1q-types:vlanid; type dot1q-types:vlanid;
description description
"A first tag to be used for push or translate "A first tag to be used for push or translate
operations. This tag will be used as the outermost tag operations. This tag will be used as the outermost
as a result of the tag operation."; tag as a result of the tag operation.";
} }
leaf tag-1-type { leaf tag-1-type {
type dot1q-types:dot1q-tag-type; type dot1q-types:dot1q-tag-type;
default "dot1q-types:s-vlan"; default "dot1q-types:s-vlan";
description description
"Specifies a specific 802.1Q tag type of tag-1."; "Specifies a specific 802.1Q tag type of tag-1.";
} }
leaf tag-2 { leaf tag-2 {
when '(../translate)'; when '(../translate)';
type dot1q-types:vlanid; type dot1q-types:vlanid;
skipping to change at line 3122 skipping to change at line 3083
+ "'vpn-common:qinq')" { + "'vpn-common:qinq')" {
description description
"Only applies when the type of the tagged interface is "Only applies when the type of the tagged interface is
'QinQ'."; 'QinQ'.";
} }
description description
"Includes QinQ parameters."; "Includes QinQ parameters.";
uses ac-common:qinq; uses ac-common:qinq;
container tag-operations { container tag-operations {
description description
"Sets the tag manipulation policy for this AC. It defines "Sets the tag manipulation policy for this AC. It
a set of tag manipulations that allow for the insertion, defines a set of tag manipulations that allow for the
removal, or rewriting of 802.1Q VLAN tags. These insertion, removal, or rewriting of 802.1Q VLAN tags.
operations are indicated for the CE-PE direction. These operations are indicated for the CE-PE direction.
By default, tag operations are symmetric. As such, the By default, tag operations are symmetric. As such, the
reverse tag operation is assumed on the PE-CE reverse tag operation is assumed on the PE-CE
direction."; direction.";
choice op-choice { choice op-choice {
description description
"Selects the tag rewriting policy for a AC."; "Selects the tag rewriting policy for an AC.";
leaf pop { leaf pop {
type uint8 { type uint8 {
range "1|2"; range "1|2";
} }
description description
"Pops one or two tags as a function of the indicated "Pops one or two tags as a function of the indicated
pop value."; pop value.";
} }
leaf push { leaf push {
type empty; type empty;
description description
"Pushes one or two tags defined by the tag-1 and "Pushes one or two tags defined by the tag-1 and
tag-2 leaves. It is assumed that, absent any tag-2 leaves. It is assumed that, absent any
policy, the default value of 0 will be used for policy, the default value of 0 will be used for
PCP setting."; PCP setting.";
} }
leaf translate { leaf translate {
type uint8 { type uint8 {
range "1|2"; range "1|2";
} }
description description
"Translates one or two outer tags. PCP bits are "Translates one or two outer tags. PCP bits are
preserved. The following operations are supported: preserved. The following operations are supported:
- translate 1 with tag-1 leaf is provided: only the - translate 1 with tag-1 leaf is provided: only the
outermost tag is translated to the value in tag-1. outermost tag is translated to the value in tag-1.
- translate 2 with both tag-1 and tag-2 leaves are - translate 2 with both tag-1 and tag-2 leaves are
provided: both outer and inner tags are translated provided: both outer and inner tags are translated
to the values in tag-1 and tag-2, respectively. to the values in tag-1 and tag-2, respectively.
- translate 2 with tag-1 leaf is provided: the - translate 2 with tag-1 leaf is provided: the
outer tag is popped while the inner tag is outer tag is popped while the inner tag is
translated to the value in tag-1."; translated to the value in tag-1.";
} }
} }
leaf tag-1 { leaf tag-1 {
when 'not(../pop)'; when 'not(../pop)';
type dot1q-types:vlanid; type dot1q-types:vlanid;
description description
"A first tag to be used for push or translate "A first tag to be used for push or translate
operations. This tag will be used as the outermost tag operations. This tag will be used as the outermost
as a result of the tag operation."; tag as a result of the tag operation.";
} }
leaf tag-1-type { leaf tag-1-type {
type dot1q-types:dot1q-tag-type; type dot1q-types:dot1q-tag-type;
default "dot1q-types:s-vlan"; default "dot1q-types:s-vlan";
description description
"Specifies a specific 802.1Q tag type of tag-1."; "Specifies a specific 802.1Q tag type of tag-1.";
} }
leaf tag-2 { leaf tag-2 {
when 'not(../pop)'; when 'not(../pop)';
type dot1q-types:vlanid; type dot1q-types:vlanid;
skipping to change at line 3351 skipping to change at line 3312
IP addresses are allocated by DHCP, which is provided IP addresses are allocated by DHCP, which is provided
by the operator."; by the operator.";
leaf dhcp-service-type { leaf dhcp-service-type {
type enumeration { type enumeration {
enum server { enum server {
description description
"Local DHCP server."; "Local DHCP server.";
} }
enum relay { enum relay {
description description
"Local DHCP relay. DHCP requests are relayed to a "Local DHCP relay. DHCP requests are relayed to a
provider's server."; provider's server.";
} }
} }
description description
"Indicates the type of DHCP service to be enabled on "Indicates the type of DHCP service to be enabled on
this access."; this access.";
} }
choice service-type { choice service-type {
description description
"Choice based on the DHCP service type."; "Choice based on the DHCP service type.";
skipping to change at line 3396 skipping to change at line 3357
} }
} }
} }
case static-addresses { case static-addresses {
description description
"Lists the static IPv4 addresses that are used."; "Lists the static IPv4 addresses that are used.";
list address { list address {
key "address-id"; key "address-id";
ordered-by user; ordered-by user;
description description
"Lists the IPv4 addresses that are used. The first "Lists the IPv4 addresses that are used. The first
address of the list is the primary address of the address of the list is the primary address of the
connection."; connection.";
leaf address-id { leaf address-id {
type string; type string;
description description
"An identifier of the static IPv4 address."; "An identifier of the static IPv4 address.";
} }
leaf customer-address { leaf customer-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
skipping to change at line 3493 skipping to change at line 3454
IP addresses are allocated by DHCP, which is provided IP addresses are allocated by DHCP, which is provided
by the operator."; by the operator.";
leaf dhcp-service-type { leaf dhcp-service-type {
type enumeration { type enumeration {
enum server { enum server {
description description
"Local DHCP server."; "Local DHCP server.";
} }
enum relay { enum relay {
description description
"Local DHCP relay. DHCP requests are relayed to "Local DHCP relay. DHCP requests are relayed to
a provider's server."; a provider's server.";
} }
} }
description description
"Indicates the type of DHCP service to be enabled on "Indicates the type of DHCP service to be enabled on
this access."; this access.";
} }
choice service-type { choice service-type {
description description
"Choice based on the DHCP service type."; "Choice based on the DHCP service type.";
skipping to change at line 3538 skipping to change at line 3499
} }
} }
} }
case static-addresses { case static-addresses {
description description
"Lists the static IPv6 addresses that are used."; "Lists the static IPv6 addresses that are used.";
list address { list address {
key "address-id"; key "address-id";
ordered-by user; ordered-by user;
description description
"Lists the IPv6 addresses that are used. The first "Lists the IPv6 addresses that are used. The first
address of the list is the primary address of address of the list is the primary address of
the connection."; the connection.";
leaf address-id { leaf address-id {
type string; type string;
description description
"An identifier of the static IPv6 address."; "An identifier of the static IPv6 address.";
} }
leaf customer-address { leaf customer-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
skipping to change at line 3589 skipping to change at line 3550
/* Routing */ /* Routing */
//BGP base parameters //BGP base parameters
grouping bgp-base { grouping bgp-base {
description description
"Configuration specific to BGP."; "Configuration specific to BGP.";
leaf description { leaf description {
type string; type string;
description description
"Includes a description of the BGP session. This description "Includes a description of the BGP session. This description
is meant to be used for diagnostic purposes. The semantic is meant to be used for diagnostic purposes. The semantics
of the description is local to an implementation."; of the description are local to an implementation.";
} }
uses rt-pol:apply-policy-group; uses rt-pol:apply-policy-group;
leaf local-as { leaf local-as {
type inet:as-number; type inet:as-number;
description description
"Indicates a local AS Number (ASN), if an ASN distinct from "Indicates a local AS Number (ASN), if an ASN distinct from
the ASN configured at the AC level is needed."; the ASN configured at the AC level is needed.";
} }
leaf peer-as { leaf peer-as {
type inet:as-number; type inet:as-number;
skipping to change at line 3649 skipping to change at line 3610
"If set, specifies the maximum number of occurrences of the "If set, specifies the maximum number of occurrences of the
provider's ASN that are permitted within the AS_PATH provider's ASN that are permitted within the AS_PATH
before it is rejected."; before it is rejected.";
} }
leaf prepend-global-as { leaf prepend-global-as {
type boolean; type boolean;
description description
"In some situations, the ASN that is provided at the node "In some situations, the ASN that is provided at the node
level may be distinct from the ASN configured at the AC. level may be distinct from the ASN configured at the AC.
When such ASNs are provided, they are both prepended to the When such ASNs are provided, they are both prepended to the
BGP route updates for this AC. To disable that behavior, BGP route updates for this AC. To disable that behavior,
'prepend-global-as' must be set to 'false'. In such a 'prepend-global-as' must be set to 'false'. In such a
case, the ASN that is provided at the node level is not case, the ASN that is provided at the node level is not
prepended to the BGP route updates for this access."; prepended to the BGP route updates for this access.";
} }
leaf send-default-route { leaf send-default-route {
type boolean; type boolean;
description description
"Defines whether default routes can be advertised to a peer. "Defines whether default routes can be advertised to a peer.
If set to 'true', the default routes are advertised to If set to 'true', the default routes are advertised to
a peer."; a peer.";
} }
leaf site-of-origin { leaf site-of-origin {
when "derived-from-or-self(../address-family, " when "derived-from-or-self(../address-family, "
+ "'vpn-common:ipv4' or 'vpn-common:dual-stack')" { + "'vpn-common:ipv4' or 'vpn-common:dual-stack')" {
description description
"Only applies if IPv4 is activated."; "Only applies if IPv4 is activated.";
} }
type rt-types:route-origin; type rt-types:route-origin;
description description
"The Site of Origin attribute is encoded as a Route Origin "The Site of Origin attribute is encoded as a Route Origin
Extended Community. It is meant to uniquely identify the Extended Community. It is meant to uniquely identify the
set of routes learned from a site via a particular AC and set of routes learned from a site via a particular AC and
is used to prevent routing loops."; is used to prevent routing loops.";
reference reference
"RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs), "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs),
Section 7"; Section 7";
} }
leaf ipv6-site-of-origin { leaf ipv6-site-of-origin {
when "derived-from-or-self(../address-family, " when "derived-from-or-self(../address-family, "
+ "'vpn-common:ipv6' or 'vpn-common:dual-stack')" { + "'vpn-common:ipv6' or 'vpn-common:dual-stack')" {
description description
skipping to change at line 3708 skipping to change at line 3669
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates the address family."; "Indicates the address family.";
} }
leaf enabled { leaf enabled {
type boolean; type boolean;
description description
"Enables, when set to 'true', the redistribution of "Enables, when set to 'true', the redistribution of
Connected routes."; connected routes.";
} }
} }
container bgp-max-prefix { container bgp-max-prefix {
description description
"Controls the behavior when a prefix maximum is reached."; "Controls the behavior when a prefix maximum is reached.";
leaf max-prefix { leaf max-prefix {
type uint32; type uint32;
description description
"Indicates the maximum number of BGP prefixes allowed in "Indicates the maximum number of BGP prefixes allowed in
the BGP session. the BGP session.
skipping to change at line 3826 skipping to change at line 3787
uses bgp-base; uses bgp-base;
} }
grouping bgp-base-peer-group-list { grouping bgp-base-peer-group-list {
description description
"Grouping for a list of basic BGP peer groups."; "Grouping for a list of basic BGP peer groups.";
list peer-group { list peer-group {
key "name"; key "name";
description description
"List of BGP peer groups uniquely identified by a name."; "List of BGP peer groups uniquely identified by a name.";
uses bgp-base-peer-group; uses bgp-base-peer-group;
} }
} }
grouping bgp-peer-group { grouping bgp-peer-group {
description description
"Grouping for BGP peer group."; "Grouping for BGP peer group.";
leaf name { leaf name {
type string; type string;
description description
"Name of the BGP peer group"; "Name of the BGP peer group";
} }
leaf local-address { leaf local-address {
type union { type union {
type inet:ip-address; type inet:ip-address;
type if:interface-ref; type if:interface-ref;
} }
description description
"Sets the local IP address to use for the BGP transport "Sets the local IP address to use for the BGP transport
session. This may be expressed as either an IP address session. This may be expressed as either an IP
or a reference to an interface."; address or a reference to an interface.";
} }
uses bgp-base; uses bgp-base;
uses ac-common:bgp-authentication; uses ac-common:bgp-authentication;
} }
grouping bgp-peer-group-list { grouping bgp-peer-group-list {
description description
"Grouping for a list of BGP peer groups."; "Grouping for a list of BGP peer groups.";
list peer-group { list peer-group {
key "name"; key "name";
description description
"List of BGP peer groups uniquely identified by a name."; "List of BGP peer groups uniquely identified by a name.";
uses bgp-peer-group; uses bgp-peer-group;
} }
} }
// RIP base parameters // RIP base parameters
grouping rip-base { grouping rip-base {
description description
"Configuration specific to RIP routing."; "Configuration specific to RIP routing.";
leaf address-family { leaf address-family {
type identityref { type identityref {
skipping to change at line 3898 skipping to change at line 3859
"Indicates the RIP update time, i.e., the amount of time "Indicates the RIP update time, i.e., the amount of time
for which RIP updates are sent."; for which RIP updates are sent.";
} }
leaf invalid-interval { leaf invalid-interval {
type uint16 { type uint16 {
range "1..32767"; range "1..32767";
} }
units "seconds"; units "seconds";
description description
"The interval before a route is declared invalid after no "The interval before a route is declared invalid after no
updates are received. This value is at least three times updates are received. This value is at least three times
the value for the 'update-interval' argument."; the value for the 'update-interval' argument.";
} }
leaf holddown-interval { leaf holddown-interval {
type uint16 { type uint16 {
range "1..32767"; range "1..32767";
} }
units "seconds"; units "seconds";
description description
"Specifies the interval before better routes released."; "Specifies the interval before better routes are
released.";
} }
leaf flush-interval { leaf flush-interval {
type uint16 { type uint16 {
range "1..32767"; range "1..32767";
} }
units "seconds"; units "seconds";
description description
"Indicates the RIP flush timer, i.e., the amount of time "Indicates the RIP flush timer, i.e., the amount of time
that must elapse before a route is removed from the that must elapse before a route is removed from the
routing table."; routing table.";
skipping to change at line 3986 skipping to change at line 3948
type uint32 { type uint32 {
range "1..4294967294"; range "1..4294967294";
} }
description description
"Maximum number of allowed Link State Advertisements "Maximum number of allowed Link State Advertisements
(LSAs) that the OSPF instance will accept."; (LSAs) that the OSPF instance will accept.";
} }
leaf passive { leaf passive {
type boolean; type boolean;
description description
"Enables when set to 'true' a passive interface. It is "When set to 'true', enables a passive interface. It is
active when set to 'false'. A passive interface's prefix active when set to 'false'. A passive interface's
will be advertised, but no neighbor adjacencies will be prefix will be advertised, but no neighbor adjacencies
formed on the interface."; will be formed on the interface.";
} }
} }
container isis { container isis {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:isis-routing')" { + "'vpn-common:isis-routing')" {
description description
"Only applies when the protocol is IS-IS."; "Only applies when the protocol is IS-IS.";
} }
if-feature "vpn-common:rtg-isis"; if-feature "vpn-common:rtg-isis";
description description
skipping to change at line 4017 skipping to change at line 3979
"Can be 'level-1', 'level-2', or 'level-1-2'."; "Can be 'level-1', 'level-2', or 'level-1-2'.";
reference reference
"RFC 9181: A Common YANG Data Model for Layer 2 "RFC 9181: A Common YANG Data Model for Layer 2
and Layer 3 VPNs"; and Layer 3 VPNs";
} }
leaf metric { leaf metric {
type uint32 { type uint32 {
range "0 .. 16777215"; range "0 .. 16777215";
} }
description description
"Metric of the AC. It is used in the routing state "Metric of the AC. It is used in the routing state
calculation and path selection."; calculation and path selection.";
} }
leaf passive { leaf passive {
type boolean; type boolean;
description description
"When set to 'false', the interface is active. In such "When set to 'false', the interface is active. In such
mode, the interface sends or receives IS-IS protocol mode, the interface sends or receives IS-IS protocol
control packets. control packets.
When set to 'true', the interface is passive. That is, When set to 'true', the interface is passive. That
it suppresses the sending of IS-IS updates through the is, it suppresses the sending of IS-IS updates through
specified interface."; the specified interface.";
} }
} }
container rip { container rip {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:rip-routing')" { + "'vpn-common:rip-routing')" {
description description
"Only applies when the protocol is RIP."; "Only applies when the protocol is RIP.";
} }
if-feature "vpn-common:rtg-rip"; if-feature "vpn-common:rtg-rip";
description description
skipping to change at line 4068 skipping to change at line 4030
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates whether IPv4, IPv6, or both address families "Indicates whether IPv4, IPv6, or both address families
are to be enabled."; are to be enabled.";
} }
leaf ping-reply { leaf ping-reply {
type boolean; type boolean;
description description
"Controls whether the VRRP speaker should reply to ping "Controls whether the VRRP speaker should reply to ping
requests. Such behavior is enabled, if set to 'true'."; requests. Such behavior is enabled, if set to 'true'.";
} }
} }
} }
} }
grouping routing { grouping routing {
description description
"Defines routing protocols."; "Defines routing protocols.";
list routing-protocol { list routing-protocol {
key "id"; key "id";
skipping to change at line 4179 skipping to change at line 4141
description description
"The remote IP address of this entry's BGP peer."; "The remote IP address of this entry's BGP peer.";
} }
leaf local-address { leaf local-address {
type union { type union {
type inet:ip-address; type inet:ip-address;
type if:interface-ref; type if:interface-ref;
} }
description description
"Sets the local IP address to use for the BGP transport "Sets the local IP address to use for the BGP transport
session. This may be expressed as either an IP address session. This may be expressed as either an IP
or a reference to an interface."; address or a reference to an interface.";
} }
leaf peer-group { leaf peer-group {
type leafref { type leafref {
path "../../peer-groups/peer-group/name"; path "../../peer-groups/peer-group/name";
} }
description description
"The peer group with which this neighbor is "The peer group with which this neighbor is
associated."; associated.";
} }
uses bgp-base; uses bgp-base;
skipping to change at line 4223 skipping to change at line 4185
(VPNs), Section 4.2.7 (VPNs), Section 4.2.7
RFC 6565: OSPFv3 as a Provider Edge to Customer Edge RFC 6565: OSPFv3 as a Provider Edge to Customer Edge
(PE-CE) Routing Protocol, Section 5"; (PE-CE) Routing Protocol, Section 5";
list sham-link { list sham-link {
key "target-site"; key "target-site";
description description
"Creates a sham link with another site."; "Creates a sham link with another site.";
leaf target-site { leaf target-site {
type string; type string;
description description
"Target site for the sham link connection. The site "Target site for the sham link connection. The site
is referred to by its identifier."; is referred to by its identifier.";
} }
leaf metric { leaf metric {
type uint16; type uint16;
description description
"Metric of the sham link. It is used in the routing "Metric of the sham link. It is used in the routing
state calculation and path selection."; state calculation and path selection.";
reference reference
"RFC 4577: OSPF as the Provider/Customer Edge "RFC 4577: OSPF as the Provider/Customer Edge
Protocol for BGP/MPLS IP Virtual Private Protocol for BGP/MPLS IP Virtual Private
Networks (VPNs), Section 4.2.7.3 Networks (VPNs), Section 4.2.7.3
RFC 6565: OSPFv3 as a Provider Edge to Customer Edge RFC 6565: OSPFv3 as a Provider Edge to Customer Edge
(PE-CE) Routing Protocol, Section 5.2"; (PE-CE) Routing Protocol, Section 5.2";
} }
} }
} }
skipping to change at line 4251 skipping to change at line 4213
type uint32 { type uint32 {
range "1..4294967294"; range "1..4294967294";
} }
description description
"Maximum number of allowed Link State Advertisements "Maximum number of allowed Link State Advertisements
(LSAs) that the OSPF instance will accept."; (LSAs) that the OSPF instance will accept.";
} }
leaf passive { leaf passive {
type boolean; type boolean;
description description
"Enables when set to 'true' a passive interface. It is "When set to 'true', enables a passive interface. It is
active when set to 'false'. A passive interface's prefix active when set to 'false'. A passive interface's
will be advertised, but no neighbor adjacencies will be prefix will be advertised, but no neighbor adjacencies
formed on the interface."; will be formed on the interface.";
} }
uses ac-common:ospf-authentication; uses ac-common:ospf-authentication;
uses ac-common:service-status; uses ac-common:service-status;
} }
container isis { container isis {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:isis-routing')" { + "'vpn-common:isis-routing')" {
description description
"Only applies when the protocol is IS-IS."; "Only applies when the protocol is IS-IS.";
} }
skipping to change at line 4284 skipping to change at line 4246
"Can be 'level-1', 'level-2', or 'level-1-2'."; "Can be 'level-1', 'level-2', or 'level-1-2'.";
reference reference
"RFC 9181: A Common YANG Data Model for Layer 2 and "RFC 9181: A Common YANG Data Model for Layer 2 and
Layer 3 VPNs"; Layer 3 VPNs";
} }
leaf metric { leaf metric {
type uint32 { type uint32 {
range "0 .. 16777215"; range "0 .. 16777215";
} }
description description
"Metric of the AC. It is used in the routing state "Metric of the AC. It is used in the routing state
calculation and path selection."; calculation and path selection.";
} }
leaf passive { leaf passive {
type boolean; type boolean;
description description
"When set to 'false', the interface is active. In such "When set to 'false', the interface is active. In such
mode, the interface sends or receives IS-IS protocol mode, the interface sends or receives IS-IS protocol
control packets. control packets.
When set to 'true', the interface is passive. That is, When set to 'true', the interface is passive. That
it suppresses the sending of IS-IS updates through the is, it suppresses the sending of IS-IS updates through
specified interface."; the specified interface.";
} }
uses ac-common:isis-authentication; uses ac-common:isis-authentication;
uses ac-common:service-status; uses ac-common:service-status;
} }
container rip { container rip {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:rip-routing')" { + "'vpn-common:rip-routing')" {
description description
"Only applies when the protocol is RIP. "Only applies when the protocol is RIP.
For IPv4, the model assumes that RIP version 2 For IPv4, the model assumes that RIP version 2
skipping to change at line 4320 skipping to change at line 4282
description description
"Configuration specific to RIP routing."; "Configuration specific to RIP routing.";
uses rip-base; uses rip-base;
uses ac-common:rip-authentication; uses ac-common:rip-authentication;
uses ac-common:service-status; uses ac-common:service-status;
} }
container vrrp { container vrrp {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:vrrp-routing')" { + "'vpn-common:vrrp-routing')" {
description description
"Only applies when the protocol is the VRRP."; "Only applies when the protocol is VRRP.";
} }
if-feature "vpn-common:rtg-vrrp"; if-feature "vpn-common:rtg-vrrp";
description description
"Configuration specific to VRRP."; "Configuration specific to VRRP.";
reference reference
"RFC 9568: Virtual Router Redundancy Protocol (VRRP) "RFC 9568: Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6"; Version 3 for IPv4 and IPv6";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
skipping to change at line 4448 skipping to change at line 4410
grouping bfd-routing { grouping bfd-routing {
description description
"Defines a basic BFD grouping for routing configuration."; "Defines a basic BFD grouping for routing configuration.";
container bfd { container bfd {
if-feature "vpn-common:bfd"; if-feature "vpn-common:bfd";
description description
"BFD control for this neighbor."; "BFD control for this neighbor.";
leaf enabled { leaf enabled {
type boolean; type boolean;
description description
"Enables BFD if set to 'true'. BFD is disabled of set to "Enables BFD if set to 'true'. BFD is disabled if set to
'false'."; 'false'.";
} }
uses failure-detection-profile-reference; uses failure-detection-profile-reference;
} }
} }
grouping oam { grouping oam {
description description
"Defines the Operations, Administration, and Maintenance "Defines the Operations, Administration, and Maintenance
(OAM) mechanisms used."; (OAM) mechanisms used.";
container bfd { container bfd {
if-feature "vpn-common:bfd"; if-feature "vpn-common:bfd";
description description
"Container for BFD."; "Container for BFD.";
list session { list session {
key "dest-addr"; key "dest-addr";
description description
"List of IP sessions."; "List of IP sessions.";
leaf dest-addr { leaf dest-addr {
type inet:ip-address; type inet:ip-address;
description description
"IP address of the peer."; "IP address of the peer.";
} }
leaf source-address { leaf source-address {
type union { type union {
type inet:ip-address; type inet:ip-address;
type if:interface-ref; type if:interface-ref;
} }
description description
"Sets the local IP address to use for the BFD session. "Sets the local IP address to use for the BFD session.
This may be expressed as either an IP address or This may be expressed as either an IP address or
a reference to an interface."; a reference to an interface.";
} }
uses failure-detection-profile-reference; uses failure-detection-profile-reference;
uses bfd; uses bfd;
container authentication { container authentication {
presence "Enables BFD authentication"; presence "Enables BFD authentication";
description description
"Parameters for BFD authentication."; "Parameters for BFD authentication.";
leaf key-chain { leaf key-chain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
skipping to change at line 4520 skipping to change at line 4482
description description
"Security parameters for an AC."; "Security parameters for an AC.";
container encryption { container encryption {
if-feature "vpn-common:encryption"; if-feature "vpn-common:encryption";
description description
"Container for AC encryption."; "Container for AC encryption.";
leaf enabled { leaf enabled {
type boolean; type boolean;
description description
"If set to 'true', traffic encryption on the connection is "If set to 'true', traffic encryption on the connection is
required. Otherwise, it is disabled."; required. Otherwise, it is disabled.";
} }
leaf layer { leaf layer {
when "../enabled = 'true'" { when "../enabled = 'true'" {
description description
"Included only when encryption is enabled."; "Included only when encryption is enabled.";
} }
type enumeration { type enumeration {
enum layer2 { enum layer2 {
description description
"Encryption occurs at Layer 2."; "Encryption occurs at Layer 2.";
} }
enum layer3 { enum layer3 {
description description
"Encryption occurs at Layer 3. For example, IPsec "Encryption occurs at Layer 3. For example, IPsec
may be used when a customer requests Layer 3 may be used when a customer requests Layer 3
encryption."; encryption.";
} }
} }
description description
"Indicates the layer on which encryption is applied."; "Indicates the layer on which encryption is applied.";
} }
} }
container encryption-profile { container encryption-profile {
when "../encryption/enabled = 'true'" { when "../encryption/enabled = 'true'" {
skipping to change at line 4774 skipping to change at line 4736
description description
"Augments SAPs with AC provisioning details."; "Augments SAPs with AC provisioning details.";
list ac { list ac {
key "ac-ref"; key "ac-ref";
description description
"Specifies the ACs that are terminated by the SAP."; "Specifies the ACs that are terminated by the SAP.";
uses ac-ntw:attachment-circuit-reference; uses ac-ntw:attachment-circuit-reference;
} }
} }
} }
<CODE ENDS>
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<!--[rfced] *AD - We note that there is some text in the
Security Considerations section that differs from the template on
<https://wiki.ietf.org/group/ops/yang-security-guidelines>. Please
review and let us know if the text is acceptable.
For example:
- This sentence is not present; should it be added?
"There are no particularly sensitive RPC or action operations."
If so, should it be at the end of the section?
(Your reply to this question will also be applied to RFC 9836.)
From the guidelines page:
"If the data model contains any particularly sensitive RPC or action
operations, then those operations must be listed here, along with an
explanation of the associated specific sensitivity or vulnerability
concerns. Otherwise, state: 'There are no particularly sensitive RPC or
action operations.'"
- The last two paragraphs (after the readable nodes section) do
not seem to be within a section of the template.
-->
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This section is modeled after the template described in in <xref sectio <!-- DNE begins -->
n="3.7" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t> <t>This section is modeled after the template described in <xref section="
3.7" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t>
<t>The "ietf-ac-ntw" YANG module defines a data model that is <t>The "ietf-ac-ntw" 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 protocols have to NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These protocols have to
use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref t arget="RFC8446"/>, and use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref t arget="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 The following
subtrees and data nodes have particular sensitivities/vulnerabilities:</t> subtrees and data nodes have particular sensitivities/vulnerabilities:</t><!-- D
<dl> NE ends -->
<dl spacing="normal" newline="false">
<dt>'specific-provisioning-profiles':</dt> <dt>'specific-provisioning-profiles':</dt>
<dd> <dd>
<t>This container includes a set of sensitive data that <t>This container includes a set of sensitive data that
influence how an AC is delivered. For example, an influences how an AC is delivered. For example, an
attacker who has access to these data nodes may be able to attacker who has access to these data nodes may be able to
manipulate routing policies, QoS policies, or encryption manipulate routing policies, QoS policies, or encryption
properties. These data nodes are defined with "nacm:default-deny- properties. These data nodes are defined with "nacm:default-deny-
write" tagging <xref target="I-D.ietf-opsawg-teas-common-ac"/>.</t> write" tagging <xref target="RFC9833"/>.</t>
</dd> </dd>
<dt>'ac':</dt> <dt>'ac':</dt>
<dd> <dd>
<t>An attacker who is able to access network nodes can <t>An attacker who is able to access network nodes can
undertake various attacks, such as modify the attributes of an AC (e.g., undertake various attacks, such as modify the attributes of an AC (e.g.,
QoS, bandwidth, routing protocols, keying material), leading to QoS, bandwidth, routing protocols, keying material), leading to
malfunctioning of services that are delivered over that AC and therefore to Ser vice Level malfunctioning of services that are delivered over that AC and therefore to Ser vice Level
Agreement (SLA) violations. In addition, an attacker could Agreement (SLA) violations. In addition, an attacker could
attempt to add a new AC. attempt to add a new AC.
: In addition to using NACM to prevent unauthorized access, such By also using NACM to prevent unauthorized access, such
activity can be detected by adequately monitoring and tracking activity can be detected by adequately monitoring and tracking
network configuration changes.</t> network configuration changes.</t>
</dd> </dd>
</dl> </dl>
<!-- DNE begins -->
<t>Some of the readable data nodes in this YANG module may be considered <t>Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. Specifically, the following notification) to these data nodes. Specifically, the following
subtrees and data nodes have particular sensitivities/vulnerabilities:</t> subtrees and data nodes have particular sensitivities/vulnerabilities:</t><!-- D
<dl> NE ends -->
<dl spacing="normal" newline="false">
<dt>'ac':</dt> <dt>'ac':</dt>
<dd> <dd>
<t>Unauthorized access to this subtree can disclose the identity <t>Unauthorized access to this subtree can disclose the identity
of a customer 'peer-sap-id'.</t> of a customer 'peer-sap-id'.</t>
</dd> </dd>
<dt>'l2-connection' and 'ip-connection':</dt> <dt>'l2-connection' and 'ip-connection':</dt>
<dd> <dd>
<t>An attacker can retrieve <t>An attacker can retrieve
privacy-related information, which can be used to track a privacy-related information, which can be used to track a
customer. Disclosing such information may be considered a customer. Disclosing such information may be considered a
violation of the customer-provider trust relationship.</t> violation of the customer-provider trust relationship.</t>
</dd> </dd>
<dt>'keying-material' and 'customer-key-chain':</dt> <dt>'keying-material' and 'customer-key-chain':</dt>
<dd> <dd>
<t>An attacker can retrieve the cryptographic keys <t>An attacker can retrieve the cryptographic keys
protecting an AC (routing, in particular). These keys could protecting an AC (routing, in particular). These keys could
be used to inject spoofed routing advertisements.</t> be used to inject spoofed routing advertisements.</t>
</dd> </dd>
</dl> </dl>
<t>Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-cha in') rely upon <xref target="RFC8177"/> for authentication purposes. As such, th e AC network module inherits the security considerations discussed in <xref sect ion="5" sectionFormat="of" target="RFC8177"/>. Also, these data nodes support su pplying explicit keys as strings in ASCII format. The use of keys in hexadecimal string format would afford greater key entropy with the same number of key-stri ng octets. However, such a format is not included in this version of the AC netw ork model, because it is not supported by the underlying device modules (e.g., < xref target="RFC8695"/>).</t> <t>Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-cha in') rely upon <xref target="RFC8177"/> for authentication purposes. As such, th e AC network module inherits the security considerations discussed in <xref sect ion="5" sectionFormat="of" target="RFC8177"/>. Also, these data nodes support su pplying explicit keys as strings in ASCII format. The use of keys in hexadecimal string format would afford greater key entropy with the same number of key-stri ng octets. However, such a format is not included in this version of the AC netw ork model, because it is not supported by the underlying device modules (e.g., < xref target="RFC8695"/>).</t>
<t><xref target="sec-sec"/> specifies the the encryption to be applied to traffic for a given AC.</t> <t><xref target="sec-sec"/> specifies the encryption to be applied to traf fic for a given AC.</t>
</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[
URI: urn:ietf:params:xml:ns:yang:ietf-ac-ntw <dl spacing="compact" newline="false">
Registrant Contact: The IESG. <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-ntw</dd>
XML: N/A; the requested URI is an XML namespace. <dt>Registrant Contact:</dt><dd>The IESG.</dd>
]]></artwork> <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
<t>IANA is requested to register the following YANG module in the "YANG Mo </dl>
dule <t>IANA has registered the following YANG module in the "YANG Module
Names" subregistry <xref target="RFC6020"/> within the "YANG Parameters" regi Names" registry <xref target="RFC6020"/> within the "YANG Parameters" registr
stry:</t> y group:</t>
<artwork><![CDATA[
Name: ietf-ac-ntw <dl spacing="compact" newline="false">
Namespace: urn:ietf:params:xml:ns:yang:ietf-ac-ntw <dt>Name:</dt><dd>ietf-ac-ntw</dd>
Prefix: ac-ntw <dt>Maintained by IANA?</dt><dd>N</dd>
Maintained by IANA? N <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-ntw</dd>
Reference: RFC XXXX <dt>Prefix:</dt><dd>ac-ntw</dd>
]]></artwork> <dt>Reference:</dt><dd>RFC 9835</dd>
</dl>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-netmod-rfc8407bis" to ="YANG-GUIDELINES"/>
<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="IEEE802.1Qcp" target="https://doi.org/10.1109/IEEESTD .2018.8467507"> <reference anchor="IEEE802.1Qcp">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks--Bridg es and Bridged Networks--Amendment 30: YANG Data Model</title> <title>IEEE Standard for Local and metropolitan area networks--Bridg es and Bridged Networks--Amendment 30: YANG Data Model</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date year="2018" month="September"/> <date year="2018" month="September"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.1Qcp-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8467507"/>
</reference> </reference>
<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="23" month="January" year="2025"/>
<abstract>
<t> Delivery of network services assumes that appropriate setup
is
provisioned over the links that connect customer termination points
and a provider network. The required setup to allow successful data
exchange over these links is referred to as an attachment circuit
(AC), while the underlying link is referred to as "bearer".
This document specifies a YANG service data model for ACs. This <!-- [RFC9834]
model can be used for the provisioning of ACs before or during companion doc RFC9834 - draft-ietf-opsawg-teas-attachment-circuit-20
service provisioning (e.g., Network Slice Service). RFC Ed Queue as of 03/03/25.
-->
<reference anchor="RFC9834" target="https://www.rfc-editor.org/info/rfc9834">
<front>
<title>YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (
ACaaS)</title>
<author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" 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>
The document also specifies a YANG service model for managing bearers <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
over which ACs are established. 291.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
182.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
345.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
408.xml"/>
</t> <!-- [RFC9833]
</abstract> companion doc RFC9833
</front> draft-ietf-opsawg-teas-common-ac-15
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-attach RFC Ed Queue as of 03/03/25.
ment-circuit-20"/> -->
</reference>
<reference anchor="RFC9291"> <reference anchor="RFC9833" target="https://www.rfc-editor.org/info/rfc9833">
<front> <front>
<title>A YANG Network Data Model for Layer 2 VPNs</title> <title>A Common YANG Data Model for Attachment Circuits</title>
<author fullname="M. Boucadair" initials="M." role="editor" surname= <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
"Boucadair"/> e="editor">
<author fullname="O. Gonzalez de Dios" initials="O." role="editor" s <organization>Orange</organization>
urname="Gonzalez de Dios"/> </author>
<author fullname="S. Barguil" initials="S." surname="Barguil"/> <author initials="R." surname="Roberts" fullname="Richard Roberts" role="e
<author fullname="L. Munoz" initials="L." surname="Munoz"/> ditor">
<date month="September" year="2022"/> <organization>Juniper</organization>
<abstract> </author>
<t>This document defines an L2VPN Network Model (L2NM) that can be <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez
used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) serv de Dios">
ices within a network (e.g., a service provider network). The L2NM complements t <organization>Telefonica</organization>
he L2VPN Service Model (L2SM) by providing a network-centric view of the service </author>
that is internal to a service provider. The L2NM is particularly meant to be us <author initials="S." surname="Barguil Giraldo" fullname="Samier Barguil G
ed by a network controller to derive the configuration information that will be iraldo">
sent to relevant network devices.</t> <organization>Nokia</organization>
<t>Also, this document defines a YANG module to manage Ethernet se </author>
gments and the initial versions of two IANA-maintained modules that include a se <author initials="B." surname="Wu" fullname="Bo Wu">
t of identities of BGP Layer 2 encapsulation types and pseudowire types.</t> <organization>Huawei Technologies</organization>
</abstract> </author>
</front> <date month='August' year='2025'/>
<seriesInfo name="RFC" value="9291"/> </front>
<seriesInfo name="DOI" value="10.17487/RFC9291"/> <seriesInfo name="RFC" value="9833"/>
</reference> <seriesInfo name="DOI" value="10.17487/RFC9833"/>
<reference anchor="RFC9182"> </reference>
<front>
<title>A YANG Network Data Model for Layer 3 VPNs</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="S. Barguil" initials="S." surname="Barguil"/> 950.xml"/>
<author fullname="O. Gonzalez de Dios" initials="O." role="editor" s <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
urname="Gonzalez de Dios"/> 342.xml"/>
<author fullname="M. Boucadair" initials="M." role="editor" surname= <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
"Boucadair"/> 119.xml"/>
<author fullname="L. Munoz" initials="L." surname="Munoz"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="A. Aguado" initials="A." surname="Aguado"/> 174.xml"/>
<date month="February" year="2022"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<abstract> 343.xml"/>
<t>As a complement to the Layer 3 Virtual Private Network Service <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
Model (L3SM), which is used for communication between customers and service prov 991.xml"/>
iders, this document defines an L3VPN Network Model (L3NM) that can be used for <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a se 177.xml"/>
rvice provider network. The model provides a network-centric view of L3VPN servi <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ces.</t> 341.xml"/>
<t>The L3NM is meant to be used by a network controller to derive <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
the configuration information that will be sent to relevant network devices. The 294.xml"/>
model can also facilitate communication between a service orchestrator and a ne <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
twork controller/orchestrator.</t> 067.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</front> 181.xml"/>
<seriesInfo name="RFC" value="9182"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<seriesInfo name="DOI" value="10.17487/RFC9182"/> 364.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<reference anchor="RFC8345"> 880.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<title>A YANG Data Model for Network Topologies</title> 077.xml"/>
<author fullname="A. Clemm" initials="A." surname="Clemm"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<author fullname="J. Medved" initials="J." surname="Medved"/> 701.xml"/>
<author fullname="R. Varga" initials="R." surname="Varga"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="N. Bahadur" initials="N." surname="Bahadur"/> 271.xml"/>
<author fullname="H. Ananthakrishnan" initials="H." surname="Anantha <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
krishnan"/> 925.xml"/>
<author fullname="X. Liu" initials="X." surname="Liu"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<date month="March" year="2018"/> 577.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<t>This document defines an abstract (generic, or base) YANG data 565.xml"/>
model for network/service topologies and inventories. The data model serves as a <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
base model that is augmented with technology-specific details in other, more sp 709.xml"/>
ecific topology and inventory data models.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</abstract> 474.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name="RFC" value="8345"/> 166.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC8345"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
</reference> 453.xml"/>
<reference anchor="RFC9408"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 080.xml"/>
<title>A YANG Network Data Model for Service Attachment Points (SAPs <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
)</title> 568.xml"/>
<author fullname="M. Boucadair" initials="M." role="editor" surname= <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
"Boucadair"/> 688.xml"/>
<author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzal <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
ez de Dios"/> 020.xml"/>
<author fullname="S. Barguil" initials="S." surname="Barguil"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="Q. Wu" initials="Q." surname="Wu"/> 241.xml"/>
<author fullname="V. Lopez" initials="V." surname="Lopez"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="June" year="2023"/> 040.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<t>This document defines a YANG data model for representing an abs 252.xml"/>
tract view of the provider network topology that contains the points from which <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
its services can be attached (e.g., basic connectivity, VPN, network slices). Al 446.xml"/>
so, the model can be used to retrieve the points where the services are actually <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
being delivered to customers (including peer networks).</t> 000.xml"/>
<t>This document augments the 'ietf-network' data model defined in
RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs ar
e the network reference points to which network services, such as Layer 3 Virtua
l Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be att
ached. One or multiple services can be bound to the same SAP. Both User-to-Netwo
rk Interface (UNI) and Network-to-Network Interface (NNI) are supported in the S
AP data model.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9408"/>
<seriesInfo name="DOI" value="10.17487/RFC9408"/>
</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>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-common
-ac-15"/>
</reference>
<reference anchor="RFC7950">
<front>
<title>The YANG 1.1 Data Modeling Language</title>
<author fullname="M. Bjorklund" initials="M." role="editor" surname=
"Bjorklund"/>
<date month="August" year="2016"/>
<abstract>
<t>YANG is a data modeling language used to model configuration da
ta, state data, Remote Procedure Calls, and notifications for network management
protocols. This document describes the syntax and semantics of version 1.1 of t
he YANG language. YANG version 1.1 is a maintenance release of the YANG language
, addressing ambiguities and defects in the original specification. There are a
small number of backward incompatibilities from YANG version 1. This document al
so specifies the YANG mappings to the Network Configuration Protocol (NETCONF).<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="7950"/>
<seriesInfo name="DOI" value="10.17487/RFC7950"/>
</reference>
<reference anchor="RFC8342">
<front>
<title>Network Management Datastore Architecture (NMDA)</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwae
lder"/>
<author fullname="P. Shafer" initials="P." surname="Shafer"/>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<author fullname="R. Wilton" initials="R." surname="Wilton"/>
<date month="March" year="2018"/>
<abstract>
<t>Datastores are a fundamental concept binding the data models wr
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="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8343">
<front>
<title>A YANG Data Model for Interface Management</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<date month="March" year="2018"/>
<abstract>
<t>This document defines a YANG data model for the management of n
etwork interfaces. It is expected that interface-type-specific data models augme
nt the generic interfaces data model defined in this document. The data model in
cludes definitions for configuration and system state (status information and co
unters for the collection of statistics).</t>
<t>The YANG data model in this document conforms to the Network Ma
nagement Datastore Architecture (NMDA) defined in RFC 8342.</t>
<t>This document obsoletes RFC 7223.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8343"/>
<seriesInfo name="DOI" value="10.17487/RFC8343"/>
</reference>
<reference anchor="RFC6991">
<front>
<title>Common YANG Data Types</title>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
ame="Schoenwaelder"/>
<date month="July" year="2013"/>
<abstract>
<t>This document introduces a collection of common data types to b
e used with the YANG data modeling language. This document obsoletes RFC 6021.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="6991"/>
<seriesInfo name="DOI" value="10.17487/RFC6991"/>
</reference>
<reference anchor="RFC8177">
<front>
<title>YANG Data Model for Key Chains</title>
<author fullname="A. Lindem" initials="A." role="editor" surname="Li
ndem"/>
<author fullname="Y. Qu" initials="Y." surname="Qu"/>
<author fullname="D. Yeung" initials="D." surname="Yeung"/>
<author fullname="I. Chen" initials="I." surname="Chen"/>
<author fullname="J. Zhang" initials="J." surname="Zhang"/>
<date month="June" year="2017"/>
<abstract>
<t>This document describes the key chain YANG data model. Key chai
ns are commonly used for routing protocol authentication and other applications
requiring symmetric keys. A key chain is a list containing one or more elements
containing a Key ID, key string, send/accept lifetimes, and the associated authe
ntication or encryption algorithm. By properly overlapping the send and accept l
ifetimes of multiple key chain elements, key strings and algorithms may be grace
fully updated. By representing them in a YANG data model, key distribution can b
e automated.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8177"/>
<seriesInfo name="DOI" value="10.17487/RFC8177"/>
</reference>
<reference anchor="RFC8341">
<front>
<title>Network Configuration Access Control Model</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<date month="March" year="2018"/>
<abstract>
<t>The standardization of network configuration interfaces for use
with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol 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="RFC8294">
<front>
<title>Common YANG Data Types for the Routing Area</title>
<author fullname="X. Liu" initials="X." surname="Liu"/>
<author fullname="Y. Qu" initials="Y." surname="Qu"/>
<author fullname="A. Lindem" initials="A." surname="Lindem"/>
<author fullname="C. Hopps" initials="C." surname="Hopps"/>
<author fullname="L. Berger" initials="L." surname="Berger"/>
<date month="December" year="2017"/>
<abstract>
<t>This document defines a collection of common data types using t
he YANG data modeling language. These derived common types are designed to be im
ported by other modules defined in the routing area.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8294"/>
<seriesInfo name="DOI" value="10.17487/RFC8294"/>
</reference>
<reference anchor="RFC9067">
<front>
<title>A YANG Data Model for Routing Policy</title>
<author fullname="Y. Qu" initials="Y." surname="Qu"/>
<author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
<author fullname="A. Lindem" initials="A." surname="Lindem"/>
<author fullname="X. Liu" initials="X." surname="Liu"/>
<date month="October" year="2021"/>
<abstract>
<t>This document defines a YANG data model for configuring and man
aging routing policies in a vendor-neutral way. The model provides a generic rou
ting policy framework that can be extended for specific routing protocols using
the YANG 'augment' mechanism.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9067"/>
<seriesInfo name="DOI" value="10.17487/RFC9067"/>
</reference>
<reference anchor="RFC9181">
<front>
<title>A Common YANG Data Model for Layer 2 and Layer 3 VPNs</title>
<author fullname="S. Barguil" initials="S." surname="Barguil"/>
<author fullname="O. Gonzalez de Dios" initials="O." role="editor" s
urname="Gonzalez de Dios"/>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="Q. Wu" initials="Q." surname="Wu"/>
<date month="February" year="2022"/>
<abstract>
<t>This document defines a common YANG module that is meant to be
reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN networ
k models.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9181"/>
<seriesInfo name="DOI" value="10.17487/RFC9181"/>
</reference>
<reference anchor="RFC4364">
<front>
<title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
<author fullname="E. Rosen" initials="E." surname="Rosen"/>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<date month="February" year="2006"/>
<abstract>
<t>This document describes a method by which a Service Provider 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="RFC5880">
<front>
<title>Bidirectional Forwarding Detection (BFD)</title>
<author fullname="D. Katz" initials="D." surname="Katz"/>
<author fullname="D. Ward" initials="D." surname="Ward"/>
<date month="June" year="2010"/>
<abstract>
<t>This document describes a protocol intended to detect faults in
the bidirectional path between two forwarding engines, including interfaces, da
ta link(s), and to the extent possible the forwarding engines themselves, with p
otentially very low latency. It operates independently of media, data protocols,
and routing protocols. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5880"/>
<seriesInfo name="DOI" value="10.17487/RFC5880"/>
</reference>
<reference anchor="RFC8077">
<front>
<title>Pseudowire Setup and Maintenance Using the Label Distribution
Protocol (LDP)</title>
<author fullname="L. Martini" initials="L." role="editor" surname="M
artini"/>
<author fullname="G. Heron" initials="G." role="editor" surname="Her
on"/>
<date month="February" year="2017"/>
<abstract>
<t>Layer 2 services (such as Frame Relay, Asynchronous Transfer Mo
de, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Lay
er 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs
). It is also possible to use pseudowires to provide low-rate Time-Division Mult
iplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enable
d network. This document specifies a protocol for establishing and maintaining t
he pseudowires, using extensions to the Label Distribution Protocol (LDP). Proce
dures for encapsulating Layer 2 PDUs are specified in other documents.</t>
<t>This document is a rewrite of RFC 4447 for publication as an In
ternet Standard.</t>
</abstract>
</front>
<seriesInfo name="STD" value="84"/>
<seriesInfo name="RFC" value="8077"/>
<seriesInfo name="DOI" value="10.17487/RFC8077"/>
</reference>
<reference anchor="RFC5701">
<front>
<title>IPv6 Address Specific BGP Extended Community Attribute</title
>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<date month="November" year="2009"/>
<abstract>
<t>Current specifications of BGP Extended Communities (RFC 4360) s
upport the IPv4 Address Specific Extended Community, but do not support an IPv6
Address Specific Extended Community. The lack of an IPv6 Address Specific Extend
ed Community may be a problem when an application uses the IPv4 Address Specific
Extended Community, and one wants to use this application in a pure IPv6 enviro
nment. This document defines a new BGP attribute, the IPv6 Address Specific Exte
nded Community, that addresses this problem. The IPv6 Address Specific Extended
Community is similar to the IPv4 Address Specific Extended Community, except tha
t it carries an IPv6 address rather than an IPv4 address. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5701"/>
<seriesInfo name="DOI" value="10.17487/RFC5701"/>
</reference>
<reference anchor="RFC4271">
<front>
<title>A Border Gateway Protocol 4 (BGP-4)</title>
<author fullname="Y. Rekhter" initials="Y." role="editor" surname="R
ekhter"/>
<author fullname="T. Li" initials="T." role="editor" surname="Li"/>
<author fullname="S. Hares" initials="S." role="editor" surname="Har
es"/>
<date month="January" year="2006"/>
<abstract>
<t>This document discusses the Border Gateway Protocol (BGP), whic
h is an inter-Autonomous System routing protocol.</t>
<t>The primary function of a BGP speaking system is to exchange ne
twork reachability information with other BGP systems. This network reachability
information includes information on the list of Autonomous Systems (ASes) that
reachability information traverses. This information is sufficient for construct
ing a graph of AS connectivity for this reachability from which routing loops ma
y be pruned, and, at the AS level, some policy decisions may be enforced.</t>
<t>BGP-4 provides a set of mechanisms for supporting Classless Int
er-Domain Routing (CIDR). These mechanisms include support for advertising a set
of destinations as an IP prefix, and eliminating the concept of network "class"
within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes,
including aggregation of AS paths.</t>
<t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4271"/>
<seriesInfo name="DOI" value="10.17487/RFC4271"/>
</reference>
<reference anchor="RFC5925">
<front>
<title>The TCP Authentication Option</title>
<author fullname="J. Touch" initials="J." surname="Touch"/>
<author fullname="A. Mankin" initials="A." surname="Mankin"/>
<author fullname="R. Bonica" initials="R." surname="Bonica"/>
<date month="June" year="2010"/>
<abstract>
<t>This document specifies the TCP Authentication Option (TCP-AO),
which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO spec
ifies the use of stronger Message Authentication Codes (MACs), protects against
replays even for long-lived TCP connections, and provides more details on the as
sociation of security with TCP connections than TCP MD5. TCP-AO is compatible wi
th either a static Master Key Tuple (MKT) configuration or an external, out-of-b
and MKT management mechanism; in either case, TCP-AO also protects connections w
hen using the same MKT across repeated instances of a connection, using traffic
keys derived from the MKT, and coordinates MKT changes between endpoints. The re
sult is intended to support current infrastructure uses of TCP MD5, such as to p
rotect long-lived connections (as used, e.g., in BGP and LDP), and to support a
larger set of MACs with minimal other system and operational changes. TCP-AO use
s a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are
never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully c
ompatible with the proposed requirements for the replacement of TCP MD5. [STANDA
RDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5925"/>
<seriesInfo name="DOI" value="10.17487/RFC5925"/>
</reference>
<reference anchor="RFC4577">
<front>
<title>OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP V
irtual Private Networks (VPNs)</title>
<author fullname="E. Rosen" initials="E." surname="Rosen"/>
<author fullname="P. Psenak" initials="P." surname="Psenak"/>
<author fullname="P. Pillay-Esnault" initials="P." surname="Pillay-E
snault"/>
<date month="June" year="2006"/>
<abstract>
<t>Many Service Providers offer Virtual Private Network (VPN) serv
ices to their customers, using a technique in which customer edge routers (CE ro
uters) are routing peers of provider edge routers (PE routers). The Border Gatew
ay Protocol (BGP) is used to distribute the customer's routes across the provide
r's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tun
nel customer packets across the provider's backbone. This is known as a "BGP/MPL
S IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing
protocol on the interface between a PE router and a CE router is BGP. This docu
ment extends that specification by allowing the routing protocol on the PE/CE in
terface to be the Open Shortest Path First (OSPF) protocol.</t>
<t>This document updates RFC 4364. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4577"/>
<seriesInfo name="DOI" value="10.17487/RFC4577"/>
</reference>
<reference anchor="RFC6565">
<front>
<title>OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Pr
otocol</title>
<author fullname="P. Pillay-Esnault" initials="P." surname="Pillay-E
snault"/>
<author fullname="P. Moyer" initials="P." surname="Moyer"/>
<author fullname="J. Doyle" initials="J." surname="Doyle"/>
<author fullname="E. Ertekin" initials="E." surname="Ertekin"/>
<author fullname="M. Lundberg" initials="M." surname="Lundberg"/>
<date month="June" year="2012"/>
<abstract>
<t>Many Service Providers (SPs) offer Virtual Private Network (VPN
) services to their customers using a technique in which Customer Edge (CE) rout
ers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol
(BGP) is used to distribute the customer's routes across the provider's IP back
bone network, and Multiprotocol Label Switching (MPLS) is used to tunnel custome
r packets across the provider's backbone. Support currently exists for both IPv4
and IPv6 VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as PE-
CE protocol is specified. This document extends those specifications to support
OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functional
ity is identical to that of OSPFv2 except for the differences described in this
document. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6565"/>
<seriesInfo name="DOI" value="10.17487/RFC6565"/>
</reference>
<reference anchor="RFC5709">
<front>
<title>OSPFv2 HMAC-SHA Cryptographic Authentication</title>
<author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
<author fullname="V. Manral" initials="V." surname="Manral"/>
<author fullname="M. Fanto" initials="M." surname="Fanto"/>
<author fullname="R. White" initials="R." surname="White"/>
<author fullname="M. Barnes" initials="M." surname="Barnes"/>
<author fullname="T. Li" initials="T." surname="Li"/>
<author fullname="R. Atkinson" initials="R." surname="Atkinson"/>
<date month="October" year="2009"/>
<abstract>
<t>This document describes how the National Institute of Standards
and Technology (NIST) Secure Hash Standard family of algorithms can be used wit
h OSPF version 2's built-in, cryptographic authentication mechanism. This update
s, but does not supercede, the cryptographic authentication mechanism specified
in RFC 2328. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5709"/>
<seriesInfo name="DOI" value="10.17487/RFC5709"/>
</reference>
<reference anchor="RFC7474">
<front>
<title>Security Extension for OSPFv2 When Using Manual Key Managemen
t</title>
<author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
<author fullname="S. Hartman" initials="S." surname="Hartman"/>
<author fullname="D. Zhang" initials="D." surname="Zhang"/>
<author fullname="A. Lindem" initials="A." role="editor" surname="Li
ndem"/>
<date month="April" year="2015"/>
<abstract>
<t>The current OSPFv2 cryptographic authentication mechanism as de
fined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- sessi
on replay attacks when using manual keying. Additionally, the existing cryptogra
phic authentication mechanism does not cover the IP header. This omission can be
exploited to carry out various types of attacks.</t>
<t>This document defines changes to the authentication sequence nu
mber mechanism that will protect OSPFv2 from both inter-session and intra- sessi
on replay attacks when using manual keys for securing OSPFv2 protocol packets. A
dditionally, we also describe some changes in the cryptographic hash computation
that will eliminate attacks resulting from OSPFv2 not protecting the IP header.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7474"/>
<seriesInfo name="DOI" value="10.17487/RFC7474"/>
</reference>
<reference anchor="RFC7166">
<front>
<title>Supporting Authentication Trailer for OSPFv3</title>
<author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
<author fullname="V. Manral" initials="V." surname="Manral"/>
<author fullname="A. Lindem" initials="A." surname="Lindem"/>
<date month="March" year="2014"/>
<abstract>
<t>Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechan
ism for authenticating protocol packets. This behavior is different from authent
ication mechanisms present in other routing protocols (OSPFv2, Intermediate Syst
em to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Ge
neration (RIPng)). In some environments, it has been found that IPsec is difficu
lt to configure and maintain and thus cannot be used. This document defines an a
lternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does
not depend only upon IPsec for authentication.</t>
<t>The OSPFv3 Authentication Trailer was originally defined in RFC
6506. This document obsoletes RFC 6506 by providing a revised definition, inclu
ding clarifications and refinements of the procedures.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7166"/>
<seriesInfo name="DOI" value="10.17487/RFC7166"/>
</reference>
<reference anchor="RFC2453">
<front>
<title>RIP Version 2</title>
<author fullname="G. Malkin" initials="G." surname="Malkin"/>
<date month="November" year="1998"/>
<abstract>
<t>This document specifies an extension of the Routing Information
Protocol (RIP) to expand the amount of useful information carried in RIP messag
es and to add a measure of security. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="56"/>
<seriesInfo name="RFC" value="2453"/>
<seriesInfo name="DOI" value="10.17487/RFC2453"/>
</reference>
<reference anchor="RFC2080">
<front>
<title>RIPng for IPv6</title>
<author fullname="G. Malkin" initials="G." surname="Malkin"/>
<author fullname="R. Minnear" initials="R." surname="Minnear"/>
<date month="January" year="1997"/>
<abstract>
<t>This document specifies a routing protocol for an IPv6 internet
. It is based on protocols and algorithms currently in wide use in the IPv4 Inte
rnet [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2080"/>
<seriesInfo name="DOI" value="10.17487/RFC2080"/>
</reference>
<reference anchor="RFC9568">
<front>
<title>Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4
and IPv6</title>
<author fullname="A. Lindem" initials="A." surname="Lindem"/>
<author fullname="A. Dogra" initials="A." surname="Dogra"/>
<date month="April" year="2024"/>
<abstract>
<t>This document defines version 3 of the Virtual Router Redundanc
y Protocol (VRRP) for IPv4 and IPv6. It obsoletes RFC 5798, which previously spe
cified VRRP (version 3). RFC 5798 obsoleted RFC 3768, which specified VRRP (vers
ion 2) for IPv4. VRRP specifies an election protocol that dynamically assigns re
sponsibility for a Virtual Router to one of the VRRP Routers on a LAN. The VRRP
Router controlling the IPv4 or IPv6 address(es) associated with a Virtual Router
is called the Active Router, and it forwards packets routed to these IPv4 or IP
v6 addresses. Active Routers are configured with virtual IPv4 or IPv6 addresses,
and Backup Routers infer the address family of the virtual addresses being adve
rtised based on the IP protocol version. Within a VRRP Router, the Virtual Route
rs in each of the IPv4 and IPv6 address families are independent of one another
and always treated as separate Virtual Router instances. The election process pr
ovides dynamic failover in the forwarding responsibility should the Active Route
r become unavailable. For IPv4, the advantage gained from using VRRP is a higher
-availability default path without requiring configuration of dynamic routing or
router discovery protocols on every end-host. For IPv6, the advantage gained fr
om using VRRP for IPv6 is a quicker switchover to Backup Routers than can be obt
ained with standard IPv6 Neighbor Discovery mechanisms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9568"/>
<seriesInfo name="DOI" value="10.17487/RFC9568"/>
</reference>
<reference anchor="RFC3688">
<front>
<title>The IETF XML Registry</title>
<author fullname="M. Mealling" initials="M." surname="Mealling"/>
<date month="January" year="2004"/>
<abstract>
<t>This document describes an IANA maintained registry for IETF 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="RFC7665"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 665.xml"/>
<title>Service Function Chaining (SFC) Architecture</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="J. Halpern" initials="J." role="editor" surname="H 543.xml"/>
alpern"/> <!-- [RFC9836]
<author fullname="C. Pignataro" initials="C." role="editor" surname= draft-ietf-opsawg-ac-lxsm-lxnm-glue-14
"Pignataro"/> IESG State: RFC Ed Queue as of 03/03/25. -->
<date month="October" year="2015"/> <reference anchor="RFC9836"
<abstract> target="https://www.rfc-editor.org/info/rfc9836">
<t>This document describes an architecture for the specification, <front>
creation, and ongoing maintenance of Service Function Chains (SFCs) in a network <title>A YANG Data Model for Augmenting VPN Service and Network Models wit
. It includes architectural concepts, principles, and components used in the con h Attachment
struction of composite services through deployment of SFCs, with a focus on thos Circuits</title>
e to be standardized in the IETF. This document does not propose solutions, prot <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
ocols, or extensions to existing protocols.</t> e="editor">
</abstract> <organization>Orange</organization>
</front> </author>
<seriesInfo name="RFC" value="7665"/> <author initials="R." surname="Roberts" fullname="Richard Roberts">
<seriesInfo name="DOI" value="10.17487/RFC7665"/> <organization>Juniper</organization>
</reference> </author>
<reference anchor="RFC9543"> <author initials="S." surname="Barguil" fullname="Samier Barguil">
<front> <organization>Nokia</organization>
<title>A Framework for Network Slices in Networks Built from IETF Te </author>
chnologies</title> <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez
<author fullname="A. Farrel" initials="A." role="editor" surname="Fa de Dios">
rrel"/> <organization>Telefonica</organization>
<author fullname="J. Drake" initials="J." role="editor" surname="Dra </author>
ke"/> <date month="August" year="2025" />
<author fullname="R. Rokui" initials="R." surname="Rokui"/> </front>
<author fullname="S. Homma" initials="S." surname="Homma"/> <seriesInfo name="RFC" value="9836" />
<author fullname="K. Makhijani" initials="K." surname="Makhijani"/> <seriesInfo name="DOI" value="10.17487/RFC9836"/>
<author fullname="L. Contreras" initials="L." surname="Contreras"/> </reference>
<author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
<date month="March" year="2024"/>
<abstract>
<t>This document describes network slicing in the context of netwo
rks built from IETF technologies. It defines the term "IETF Network Slice" to de
scribe this type of network slice and establishes the general principles of netw
ork slicing in the IETF context.</t>
<t>The document discusses the general framework for requesting and
operating IETF Network Slices, the characteristics of an IETF Network Slice, th
e necessary system components and interfaces, and the mapping of abstract reques
ts to more specific technologies. The document also discusses related considerat
ions with monitoring and security.</t>
<t>This document also provides definitions of related terms to ena
ble consistent usage in other IETF documents that describe or use aspects of IET
F Network Slices.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9543"/>
<seriesInfo name="DOI" value="10.17487/RFC9543"/>
</reference>
<reference anchor="I-D.ietf-opsawg-ac-lxsm-lxnm-glue">
<front>
<title>A YANG Data Model for Augmenting VPN Service and Network Mode
ls with 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="Samier Barguil" initials="S." surname="Barguil">
<organization>Nokia</organization>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O. G." surname="
de Dios">
<organization>Telefonica</organization>
</author>
<date day="9" month="January" year="2025"/>
<abstract>
<t> The document specifies a module that updates existing servic
e (i.e.,
the Layer 2 Service Model (L2SM) and the Layer 3 Service Model
(L3SM)) and network (i.e., the Layer 2 Network Model (L2NM) and the
Layer 3 Network Model (L3NM)) Virtual Private Network (VPN) modules
with the required information to bind specific VPN services to
attachment circuits (ACs) that are created using the AC service
("ietf-ac-svc") and network ("ietf-ac-ntw") models.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ac-lxsm-lxn
m-glue-13"/>
</reference>
<reference anchor="RFC8969">
<front>
<title>A Framework for Automating Service and Network Management wit
h YANG</title>
<author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="D. Lopez" initials="D." surname="Lopez"/>
<author fullname="C. Xie" initials="C." surname="Xie"/>
<author fullname="L. Geng" initials="L." surname="Geng"/>
<date month="January" year="2021"/>
<abstract>
<t>Data models provide a programmatic approach to represent servic
es and networks. Concretely, they can be used to derive configuration informatio
n for network and service components, and state information that will be monitor
ed and tracked. Data models can be used during the service and network managemen
t life cycle (e.g., service instantiation, service provisioning, service optimiz
ation, service monitoring, service diagnosing, and service assurance). Data mode
ls are also instrumental in the automation of network management, and they can p
rovide closed-loop control for adaptive and deterministic service creation, deli
very, and maintenance.</t>
<t>This document describes a framework for service and network man
agement automation that takes advantage of YANG modeling technologies. This fram
ework is drawn from a network operator perspective irrespective of the origin of
a data model; thus, it can accommodate YANG modules that are developed outside
the IETF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8969"/>
<seriesInfo name="DOI" value="10.17487/RFC8969"/>
</reference>
<reference anchor="RFC8340">
<front>
<title>YANG Tree Diagrams</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="L. Berger" initials="L." role="editor" surname="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="RFC8466">
<front>
<title>A YANG Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery</title>
<author fullname="B. Wen" initials="B." surname="Wen"/>
<author fullname="G. Fioccola" initials="G." role="editor" surname="
Fioccola"/>
<author fullname="C. Xie" initials="C." surname="Xie"/>
<author fullname="L. Jalil" initials="L." surname="Jalil"/>
<date month="October" year="2018"/>
<abstract>
<t>This document defines a YANG data model that can be used to 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="RFC3644">
<front>
<title>Policy Quality of Service (QoS) Information Model</title>
<author fullname="Y. Snir" initials="Y." surname="Snir"/>
<author fullname="Y. Ramberg" initials="Y." surname="Ramberg"/>
<author fullname="J. Strassner" initials="J." surname="Strassner"/>
<author fullname="R. Cohen" initials="R." surname="Cohen"/>
<author fullname="B. Moore" initials="B." surname="Moore"/>
<date month="November" year="2003"/>
<abstract>
<t>This document presents an object-oriented information model for
representing Quality of Service (QoS) network management policies. This documen
t is based on the IETF Policy Core Information Model and its extensions. It defi
nes an information model for QoS enforcement for differentiated and integrated s
ervices using policy. It is important to note that this document defines an info
rmation model, which by definition is independent of any particular data storage
mechanism and access protocol.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3644"/>
<seriesInfo name="DOI" value="10.17487/RFC3644"/>
</reference>
<reference anchor="RFC4862">
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<author fullname="S. Thomson" initials="S." surname="Thomson"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="T. Jinmei" initials="T." surname="Jinmei"/>
<date month="September" year="2007"/>
<abstract>
<t>This document specifies the steps a host takes in deciding how
to autoconfigure its interfaces in IP version 6. The autoconfiguration process i
ncludes generating a link-local address, generating global addresses via statele
ss address autoconfiguration, and the Duplicate Address Detection procedure to v
erify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4862"/>
<seriesInfo name="DOI" value="10.17487/RFC4862"/>
</reference>
<reference anchor="RFC9234">
<front>
<title>Route Leak Prevention and Detection Using Roles in UPDATE and
OPEN Messages</title>
<author fullname="A. Azimov" initials="A." surname="Azimov"/>
<author fullname="E. Bogomazov" initials="E." surname="Bogomazov"/>
<author fullname="R. Bush" initials="R." surname="Bush"/>
<author fullname="K. Patel" initials="K." surname="Patel"/>
<author fullname="K. Sriram" initials="K." surname="Sriram"/>
<date month="May" year="2022"/>
<abstract>
<t>Route leaks are the propagation of BGP prefixes that violate as
sumptions of BGP topology relationships, e.g., announcing a route learned from o
ne transit provider to another transit provider or a lateral (i.e., non-transit)
peer or announcing a route learned from one lateral peer to another lateral pee
r or a transit provider. These are usually the result of misconfigured or absent
BGP route filtering or lack of coordination between autonomous systems (ASes).
Existing approaches to leak prevention rely on marking routes by operator config
uration, with no check that the configuration corresponds to that of the Externa
l BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the p
eering relationship. This document enhances the BGP OPEN message to establish an
agreement of the peering relationship on each eBGP session between autonomous s
ystems in order to enforce appropriate configuration on both sides. Propagated r
outes are then marked according to the agreed relationship, allowing both preven
tion and detection of route leaks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9234"/>
<seriesInfo name="DOI" value="10.17487/RFC9234"/>
</reference>
<reference anchor="RFC4552">
<front>
<title>Authentication/Confidentiality for OSPFv3</title>
<author fullname="M. Gupta" initials="M." surname="Gupta"/>
<author fullname="N. Melam" initials="N." surname="Melam"/>
<date month="June" year="2006"/>
<abstract>
<t>This document describes means and mechanisms to provide authent
ication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulat
ing Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4552"/>
<seriesInfo name="DOI" value="10.17487/RFC4552"/>
</reference>
<reference anchor="RFC9127">
<front>
<title>YANG Data Model for Bidirectional Forwarding Detection (BFD)<
/title>
<author fullname="R. Rahman" initials="R." role="editor" surname="Ra
hman"/>
<author fullname="L. Zheng" initials="L." role="editor" surname="Zhe
ng"/>
<author fullname="M. Jethanandani" initials="M." role="editor" surna
me="Jethanandani"/>
<author fullname="S. Pallagatti" initials="S." surname="Pallagatti"/
>
<author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
<date month="October" year="2021"/>
<abstract>
<t>This document defines a YANG data model that can be used to con
figure and manage Bidirectional Forwarding Detection (BFD).</t>
<t>The YANG modules in this document conform to the Network Manage
ment Datastore Architecture (NMDA) (RFC 8342).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9127"/>
<seriesInfo name="DOI" value="10.17487/RFC9127"/>
</reference>
<reference anchor="RFC7880">
<front>
<title>Seamless Bidirectional Forwarding Detection (S-BFD)</title>
<author fullname="C. Pignataro" initials="C." surname="Pignataro"/>
<author fullname="D. Ward" initials="D." surname="Ward"/>
<author fullname="N. Akiya" initials="N." surname="Akiya"/>
<author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
<author fullname="S. Pallagatti" initials="S." surname="Pallagatti"/
>
<date month="July" year="2016"/>
<abstract>
<t>This document defines Seamless Bidirectional Forwarding Detecti
on (S-BFD), a simplified mechanism for using BFD with a large proportion of nego
tiation aspects eliminated, thus providing benefits such as quick provisioning,
as well as improved control and flexibility for network nodes initiating path mo
nitoring.</t>
<t>This document updates RFC 5880.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7880"/>
<seriesInfo name="DOI" value="10.17487/RFC7880"/>
</reference>
<reference anchor="I-D.ietf-netmod-rfc8407bis">
<front>
<title>Guidelines for Authors and Reviewers of Documents Containing
YANG Data Models</title>
<author fullname="Andy Bierman" initials="A." surname="Bierman">
<organization>YumaWorks</organization>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="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
guidelines for writing the IANA considerations for RFCs that specify
IANA-maintained modules. The document also updates RFC 6020 by
clarifying how modules and their revisions are handled by IANA.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 969.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis- 340.xml"/>
22"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</reference> 466.xml"/>
<reference anchor="RFC6241"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 299.xml"/>
<title>Network Configuration Protocol (NETCONF)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<author fullname="R. Enns" initials="R." role="editor" surname="Enns 644.xml"/>
"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="M. Bjorklund" initials="M." role="editor" surname= 862.xml"/>
"Bjorklund"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn 234.xml"/>
ame="Schoenwaelder"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="A. Bierman" initials="A." role="editor" surname="B 552.xml"/>
ierman"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<date month="June" year="2011"/> 127.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<t>The Network Configuration Protocol (NETCONF) defined in this do 880.xml"/>
cument provides mechanisms to install, manipulate, and delete the configuration <!-- [I-D.ietf-netmod-rfc8407bis]
of network devices. It uses an Extensible Markup Language (XML)-based data encod draft-ietf-netmod-rfc8407bis-22
ing for the configuration data as well as the protocol messages. The NETCONF pro IESG State: Publication Requested as of 03/03/25. -->
tocol operations are realized as remote procedure calls (RPCs). This document ob <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
soletes RFC 4741. [STANDARDS-TRACK]</t> ietf-netmod-rfc8407bis.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</front> 695.xml"/>
<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="RFC8695">
<front>
<title>A YANG Data Model for the Routing Information Protocol (RIP)<
/title>
<author fullname="X. Liu" initials="X." surname="Liu"/>
<author fullname="P. Sarda" initials="P." surname="Sarda"/>
<author fullname="V. Choudhary" initials="V." surname="Choudhary"/>
<date month="February" year="2020"/>
<abstract>
<t>This document describes a data model for the management of the
Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. Th
e data model includes definitions for configuration, operational state, and Remo
te Procedure Calls (RPCs).</t>
<t>The YANG data model in this document conforms to the Network Ma
nagement Datastore Architecture (NMDA).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8695"/>
<seriesInfo name="DOI" value="10.17487/RFC8695"/>
</reference>
</references> </references>
</references> </references>
<?line 4195?>
<section anchor="sec-examples"> <section anchor="sec-examples">
<name>Examples</name> <name>Examples</name>
<section anchor="vpls"> <section anchor="vpls">
<name>VPLS</name> <name>VPLS</name>
<t>Let us consider the example depicted in <xref target="ex-topo"/> with two customer terminating points (CE1 and CE2). Let us also assume that the bear ers to attach these CEs to the provider network are already in place. References to the identify these bearers are shown in the figure.</t> <t>Let us consider the example depicted in <xref target="ex-topo"/> with two customer terminating points (CE1 and CE2). Let us also assume that the bear ers to attach these CEs to the provider network are already in place. References to identify these bearers are shown in the figure.</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 5814 skipping to change at line 5088
<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>
<artwork><![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": {
"type": "ietf-vpn-common:dot1q", "type": "ietf-vpn-common:dot1q",
"dot1q": { "dot1q": {
"tag-type": "ietf-vpn-common:c-vlan", "tag-type": "ietf-vpn-common:c-vlan",
skipping to change at line 5887 skipping to change at line 5161
"ac-group-profile": [ "ac-group-profile": [
"an-ac-profile" "an-ac-profile"
], ],
"l2-connection": { "l2-connection": {
"bearer-reference": "5678" "bearer-reference": "5678"
} }
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The provisioned AC at PE1 can be retrieved using the AC network model as depicted in <xref target="ex-acntw-query"/>. A similar query can be used for the AC at PE2.</t> <t>The provisioned AC at PE1 can be retrieved using the AC network model as depicted in <xref target="ex-acntw-query"/>. A similar query can be used for the AC at PE2.</t>
<figure anchor="ex-acntw-query"> <figure anchor="ex-acntw-query">
<name>Example of AC Network Response (Message Body)</name> <name>Example of AC Network Response (Message Body)</name>
<artwork><![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"
], ],
"status":{ "status":{
"admin-status":{ "admin-status":{
skipping to change at line 5952 skipping to change at line 5226
"network-ref":"example:an-id", "network-ref":"example:an-id",
"direction":"ietf-vpn-common:both" "direction":"ietf-vpn-common:both"
} }
] ]
} }
} }
} }
} }
] ]
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>Also, the AC network model can be used to retrieve the list of SAPs t o which the ACs are bound as shown in <xref target="ex-acntw-query"/>.</t> <t>Also, the AC network model can be used to retrieve the list of SAPs t o which the ACs are bound as shown in <xref target="ex-acntw-query"/>.</t>
<figure anchor="ex-acntw-query-2"> <figure anchor="ex-acntw-query-2">
<name>Example of AC Network Response to Retrieve the SAP (Message Body )</name> <name>Example of AC Network Response to Retrieve the SAP (Message Body )</name>
<artwork><![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",
"peer-sap-id":[ "peer-sap-id":[
"ce-1" "ce-1"
], ],
skipping to change at line 5999 skipping to change at line 5273
"ac-ref":"ac-1", "ac-ref":"ac-1",
"node-ref":"example:pe2", "node-ref":"example:pe2",
"network-ref":"example:an-id" "network-ref":"example:an-id"
} }
] ]
} }
] ]
} }
] ]
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="parent-ac"> <section anchor="parent-ac">
<name>Parent AC</name> <name>Parent AC</name>
<t>In reference to the topology depicted in <xref target="sap-ac-ntw"/>, PE2 has a SAP which terminates an AC with two peer SAPs (CE2 and CE5). In order to control data that is specific to each of these peer SAPs over the same AC, c hild ACs can be instantiated as depicted in <xref target="ex-parent-ac"/>.</t> <t>In reference to the topology depicted in <xref target="sap-ac-ntw"/>, PE2 has a SAP that terminates an AC with two peer SAPs (CE2 and CE5). In order to control data that is specific to each of these peer SAPs over the same AC, ch ild ACs can be instantiated as depicted in <xref target="ex-parent-ac"/>.</t>
<figure anchor="ex-parent-ac"> <figure anchor="ex-parent-ac">
<name>Example of Child ACs</name> <name>Example of Child ACs</name>
<artwork><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-ac-ntw:ac":[ "ietf-ac-ntw:ac":[
{ {
"name":"ac-1", "name":"ac-1",
"peer-sap-id":[ "peer-sap-id":[
"CE2", "CE2",
"CE5" "CE5"
], ],
"status":{ "status":{
"admin-status":{ "admin-status":{
skipping to change at line 6059 skipping to change at line 5333
"ac-ref":"ac-1", "ac-ref":"ac-1",
"node-ref":"example:pe2", "node-ref":"example:pe2",
"network-ref":"example:an-id" "network-ref":"example:an-id"
}, },
"peer-sap-id":[ "peer-sap-id":[
"CE5" "CE5"
] ]
} }
] ]
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="ex-parent-ac-sap"/> shows how to bind the parent AC to a SAP.</t> <t><xref target="ex-parent-ac-sap"/> shows how to bind the parent AC to a SAP.</t>
<figure anchor="ex-parent-ac-sap"> <figure anchor="ex-parent-ac-sap">
<name>Example of Binding Parent AC to SAPs</name> <name>Example of Binding Parent ACs to SAPs</name>
<artwork><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-sap-ntw:service":[ "ietf-sap-ntw:service":[
{ {
"service-type":"ietf-vpn-common:l3vpn", "service-type":"ietf-vpn-common:l3vpn",
"sap":[ "sap":[
{ {
"sap-id":"sap#14587", "sap-id":"sap#14587",
"description":"A SAP", "description":"A SAP",
"parent-termination-point":"GE0/6/4", "parent-termination-point":"GE0/6/4",
"attachment-interface":"GE0/6/4.2", "attachment-interface":"GE0/6/4.2",
skipping to change at line 6092 skipping to change at line 5366
"ac-ref":"ac-1", "ac-ref":"ac-1",
"node-ref":"example:pe2", "node-ref":"example:pe2",
"network-ref":"example:an-id" "network-ref":"example:an-id"
} }
] ]
} }
] ]
} }
] ]
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="AC-Ntw-Tree"> <section anchor="AC-Ntw-Tree">
<name>Full Tree</name> <name>Full Tree</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-ntw module: ietf-ac-ntw
augment /nw:networks/nw:network: augment /nw:networks/nw:network:
+--rw specific-provisioning-profiles +--rw specific-provisioning-profiles
| +--rw valid-provider-identifiers | +--rw valid-provider-identifiers
| +--rw encryption-profile-identifier* [id] | +--rw encryption-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw qos-profile-identifier* [id] | +--rw qos-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw failure-detection-profile-identifier* [id] | +--rw failure-detection-profile-identifier* [id]
skipping to change at line 6715 skipping to change at line 5989
+--rw acl-profiles +--rw acl-profiles
+--rw acl-profile* [forwarding-profile-ref] +--rw acl-profile* [forwarding-profile-ref]
+--rw forwarding-profile-ref leafref +--rw forwarding-profile-ref leafref
+--rw network-ref? +--rw network-ref?
-> /nw:networks/network/network-id -> /nw:networks/network/network-id
augment /nw:networks/nw:network/nw:node/sap:service/sap:sap: augment /nw:networks/nw:network/nw:node/sap:service/sap:sap:
+--rw ac* [ac-ref] +--rw ac* [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
]]></artwork> ]]></sourcecode>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>This document builds on <xref target="RFC9182"/> and <xref target="RFC9 291"/>.</t> <t>This document builds on <xref target="RFC9182"/> and <xref target="RFC9 291"/>.</t>
<t>Thanks to Moti Morgenstern for the review and comments.</t> <t>Thanks to <contact fullname="Moti Morgenstern"/> for the review and com
<t>Thanks to Martin Björklund for the yangdoctors review, Gyan Mishra for ments.</t>
an early rtg-dir review, Joel Halpern for the rtg-dir review, <t>Thanks to <contact fullname="Martin Björklund"/> for the YANG Doctors
Giuseppe Fioccola for the ops-dir review, and Russ Housley for the sec-dir revie review, <contact fullname="Gyan Mishra"/> for an early RTGDIR review,
w.</t> <contact fullname="Joel Halpern"/> for the RTGDIR review, <contact fullnam
<t>Thanks to Krzysztof Szarkowicz for the Shepherd review.</t> e="Giuseppe
<t>Thanks for Mahesh Jethanandani for the AD review.</t> Fioccola"/> for the OPSDIR review, and <contact fullname="Russ Housley"/>
for the SECDIR
review.</t>
<t>Thanks to <contact fullname="Krzysztof Szarkowicz"/> for the shepherd r
eview.</t>
<t>Thanks for <contact fullname="Mahesh Jethanandani"/> for the AD review.
</t>
</section> </section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse"> <section anchor="contributors" numbered="false" toc="include">
<name>Contributors</name> <name>Contributors</name>
<contact initials="V." surname="Lopez" fullname="Victor Lopez"> <contact initials="V." surname="Lopez" fullname="Victor Lopez">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>victor.lopez@nokia.com</email> <email>victor.lopez@nokia.com</email>
</address> </address>
</contact> </contact>
<contact fullname="Ivan Bykov"> <contact fullname="Ivan Bykov">
<organization>Ribbon Communications</organization> <organization>Ribbon Communications</organization>
<address> <address>
skipping to change at line 6760 skipping to change at line 6038
</address> </address>
</contact> </contact>
<contact fullname="Luis Angel Munoz"> <contact fullname="Luis Angel Munoz">
<organization>Vodafone</organization> <organization>Vodafone</organization>
<address> <address>
<email>luis-angel.munoz@vodafone.com</email> <email>luis-angel.munoz@vodafone.com</email>
</address> </address>
</contact> </contact>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+y963IbR5Iw+p8R+w699A+QNgHxJkqiZ8eGKNrDs7pwRNne
iY39NhpAk+xRAw13N0jRlr5nOc9ynuzkpbJuXd1okJTtmSFi10MBVVlZWVlZ
mVlZmf1+f61Kqyw5jNaH0eukus6L99Hfhq+/j17EVRy9yidJFp3nRTSsqnh8
OU1mVXSUFuNFWpXra/FoVCRX1Jf6CACr2xE0G8dVcpEXN4dRWU3W1ib5eBZP
YchJEZ9X/TSpzvv5vIyvL/qz6rof65H6Yx6pv3OwVi5G07Qs03xW3cyh78nx
u+/WZovpKCkO1yYwwOHaOJ+VyaxclIdRVSySNUBsby0ukhgQfDNPiriC3mUU
zybRq3gWXyQ4xvoaYnxR5It5W7NoCHCin6BpOruIvsfm62vvkxvoPDlci/rR
WZaOk+gsKa7gf/GLl3s/nr6mP3bVH8NFlU8JOv5LaOV++6YYXyZlVegvSoYY
AUHTq6S4obHUd/Miv0qRJICT3bZMLhDnGozzLPmQjtIsrW6c5ul0nqXn6biG
mzWdve9PT52fYL447Fq8qC5zWIP+WgSf80WW8eK+yi/hfyfR83wxjidxWtDv
RY68lkzSKucv8uIinqW/0NCHMP14dpHQD8k0TrPDaMpgBiMB821ObQbjfLpW
G/RtOr6Mi0n0Nge+qMrACP/PYpbCIttDFAW3/vbv/NtgllR10G/KcVxE3+ez
X+Is+QXWI3qR5qER3iVZcg5rMo7tQXLsPrhQ3SdAgbz8ttJNw9M5i6dpUkTP
4+JikWbR92kRZ5M8MObr/H3qDFdSz8GIe/7vBff8dobtwmM9z6OfFgHQf1nE
10kKsxpfzvIsv0iT0h4ogy0yuF6M8m8vqSEDh61YFekIWBs4I4p4LB7nx3QM
30Yv83nyiwwXmMAVNRtk2MxGW4AZxE+u4ln0/OZ9fhXA/m06GuWz6CifThcz
xeEO/th7QL2/LUajWdMgf01nbeSxIcIGy4AiDj3qAN9cxO/T6D8TQOoyDcD9
zxcvTmyo75N+nmOfb99PJo1QXy7SMhrC9siiV4tZ/ksA8I/5JAaeczZZBt36
uKuywRS7fXulGvE4s7xACXWV4FqeHB8fP93eHez8dTw/JCBygOAv0VkFghO3
4Dkt8jjOSJJOk6rI5zmIHlgslMnRjAVJ2e8/L9LJRcISl/+eiJiBX4cgyiYk
gve2D/2jaZ0QEBGEfyuSKLZClOjfdEKAPJtXCR4Z0e72zlNGHnZIUh1Gl1U1
Lw8fPZrk6QC6PtrZHuzsbD97hBDO3r0YYIfB0/2DJ4+3n6ytpbNzQxPYS/1+
FI9QbI9Bcry7hEWAQ25BWJfzZAzCFecncwahJuejOewiddiVg+jdZaKajIFa
oyRalAkTtLp0pX6Un4dAQJsUWsP/TRYFNisDJ0a0kQwuBlsRnE5bjljXx9jm
IBpGwAFzYB/YRAKEUYM5ytQmEewORM1bnZJwfp7Aehe8vL2AGtHrx8B8fTnU
NoZHcXy2GW2c9F8MbN2gSrBdTTnYHCDFCatFlgAv0NlXEj6juEw00Td6BE39
s7dJCGErGdnC7TRP4b8bZ8PTTZ5uGV2n1SU1nyQVbBqatGICoM0qiwPEOsVm
E+DDY+L8jdPjEueBfDRNJ5MsWVv7IjoBGQqTGtOpvHaUz2YJ/H0Fp7csRYlb
iceEEyUa3ehdFVV5NF6UoFog6a9YtuKpg7oYTDsppukMUAcs5zjXcisqF+PL
KC41Ob5bzMasCv366zdvvzt6cnDw+NOnLQQkkOEgJ/SPAP2taJ7AN6jOzPJp
vgBANyXsNjhYCpzp23xRIS4bw7Pnb6H5Gu/KOBoDcfCHC8DsOr4BTICWJ/gd
TCY6/gAnOkgmXpJSLTZMeZwAbyc4T01z2GHCo6n9j7lQW++/+AaIMQfBEuUz
tW6wdZmik3xeMTHrELYA8DhbTJBu2O08y6+j+aLC8eZZjDpWEyNM4KABnDUO
ZgkBi0sAA71uaD1B1UHOzCMUlTX+wQ0CG/M7GCf5EIPmlmzRgHDiJ6HmONfL
vIQ/FlmVQnMzshIAL+MblIhwMhfVAuT1aZFewVpombABEmKTVoVb7rHIgH8H
pYZil2eP9/c+fQJMT2YRcwDO6CpPJ9YiwSKfJ0UChCEyFLCmcHrMKmdvAW2v
YhBowFJZro7wrdDy4lSTD/O8RGgKOq4JDDwlTR7NEVmA/jX0GURHepOgrAVC
zgCLnxegg+MIdJhlcBCGKAtgQTbbq78lMgWBnPOUq8u4CvW+toayRHSpwGom
oP7DowGQ9d87isRPn5xTh3aZOXKIFDhiSDbFpSEs7LVffy2TcZ9Fqwe101kW
bawTvvEYTbv1zVXPNlwv2sq1LdzlhPN2CfClT0DAK/tQTuE/s2n/Ilt4k1wY
O6rktUjYnPMs3Y2Xu69fbeIKIePvPtsBMHK6kB1Ya79ntd95ugvtcdlT6PPy
A7Sn0XDyzD2FNS+g1qIU+WPk4CQ5T2dyElv6hxKYWh3JErAiY5TazuiIrYM+
ij+UhMQoM8DFXRvQdeBgIgGMGMIilsxnM5ighbaDFm5MGAE0nDPYcrhF4Dc+
ra9BCuCOpQMvIcYf51e43nkFMjq7gX/OrqApjA8iqkmyg1wAoyOKszKXdRyX
yEg5UKtQyh6K/iy/4YGVDBxn+ULLZlEpYNIulyNdkzK9wBnFPn/AKKNc6Qiu
qqF6M32f7u0/ttiji/IhK7O//fTTJ9DJgseC2k7m8IiQS0Dc45YX0Q8wgfov
0/fJdVqqg6M+New9Br0PfsFzwCYXSC1YqBgB1UZEMWkPhvyryAsbGLgB3ShH
NHMUDWD3ZBNshOT+v/CJ4ri8ulDqu/0Z9PuDf6t///Ho+OBj4Pte/6te/et4
HH10QXYaJLJ6wYCPv+rTR/7n6HjXR2FgNRgQOv2eCwq/8Tp9bPgb/xmPV2js
Nh18NQj+zf+02g76X5XxXM1K/T0I/cQfu+tHnFBP/5P+/hj8qYahRv70eMf7
zvpp1+6qFs6bTLirOyqs3s5XPLd6i/autITAQL2veoHfW7vqv3v9+qfX8tO/
rTnLU/8MWn4K0bgTykhXmOigCcbp8V4DjNPjffUNcwtsjcfBte6EB7ONt1FW
AxHmNP4MkHqm64B5yvy3eeF4L+iF43/a/w2IHg3JZR/+p/5vcz8UAfU585d1
6WBP8ytXyn20vgxJTtXq6HiPtzuoR8Km8OX+V/264LKm0/e3uvqShPvar4fR
F0AgpQqy0+g/1gP+ADD5SGEr10GDYFU9zuBg+o91thTXPzWczqSEVPwLnV4z
9YOlhDQp0dwekIMDlsGTL2NnsKMO3yfPHm/DsW3p0r6mhRoKGi1aU9Q6n7lF
QN8I2BtwhA4LOP+qhHWojdevXgw3PTxZV9glhM6IIqLKemY/NUc9XX6mLl98
ER2Tmz0Ffel1Duf4xjuyLIpkCpoVGbgwhGq0ubZGbRTq5ofDiNxZZTJmW0zs
E4HCejha4YtRphysA98Hhu7gOAUdiaykyzxDle0qBn1bqYqzhNUOAkyNJuxw
AYLA4v8C/1TNoTEiWKWgQILGZY/KmM5wGuViOgWT8RfskGXYkEzkxQhsrWqh
9HnRUXHwZAJIn2YJOozi+Rz0TTLv8wwMfNR3FVakBB2urX0ZHcEn6vf/TO3i
UmlOSDe+lCKTpgO3Aagz+NwaVMj6A5j/BZ+lMIl9ASq0393efdzf3ulvPzG9
xuQNIBVQEdCiNn9lLTJ6rI60js5ujRfI0Cn73GlTvU9uIrwyK6P1Vz+cvVvf
4v+NXr+hv98e//WHk7fHL/Dvs78MX77Uf6ypFmd/efPDyxfmL9Pz6M2rV8ev
X3Bn+DZyvlpbfzX82zrb5+tvTt+dvHk9fLle38Mxu5RGyjkxL5KKdP01UI7H
RTri7fb86PT/+3939tUu3d3ZeQaiQW3ZnSf78A+07nk0Ml74n+jhWQPuSuKC
rNoMjeB5WoG5soX2RHmZX88i1LCBGb/8b6TM/xxGfxqN5zv7f1Zf4ISdL4Vm
zpdEs/o3tc5MxMBXgWE0NZ3vPUq7+A7/5vxb6G59+advMhB5UX/n6Td/XmMe
KZIYxQMQYwH2AazEeTxNsxRopl2w6L4sXXF5pgTULjKmZS35okgfEggjWndO
kHVchDBUOAcALvq1nj47eKYPiWkSozlcaglzMx3lWen4w6siARsqjS+KeFr6
RjH7ykDObxPMlx/OXrHriOWs2JPiohNrUbsdzsiNQDD2Dw5st4Ny1fk99qwe
u8+eqVFfh0f9PK4OGhFbekPycAiMACkSGxmMpCNvkaKu8vjP0Y/wIUGxHI8P
1w5tU1qJxLU1UDnwJ4Xb2hpoIvhvy/q2jW/4/Wps/b62dgLbdTIhUbbliQzN
UQZT4k/Ah68+CKdofnlTpngdBoIXr1HxT+D993wOjdm7j4417VxHV0q0Ac1L
UBQ22ab3HR4Dgj2iccQgj2GjFAnoASWOhX9PaKRB9Maz0CvrUtfxx+GSLNA8
jxVsdtypcTACQ5qbOyBymAvyiBf2yCmgAp2DGfluyXW4mKU/LzQ04gJyAcOo
MDc4P85v9MC06WHBUTHUNznKZyOEIhGieqZJsTmIzuguwwKtsAVxXqTJlY+t
cdsKf6GqgL5ZvMATX5MoAOK1Jc5dzOLpKL1Y5IsS5LxGX/wk2tXt+HWFOrDq
42RekevIWcKLZAZ0Y8UH+lnO5IRGpzUFQEmR3SDDKfZpvYkKeY0QEZ8pQm5c
9KwDWniPAAOTY07fOSjM1aJoMHKbwHfAFD4jl7rRxo8vh6/LTbl8scHQbkhL
51IrNpsH+Rj9RSJkKNAA9h3vshcJan/IYufq8gq64IpUN0C2cg56SDrKzCXN
1GjmIsAbHIv1vTOrYaC3EDvMmJGab6FQrVc/5TrqJ6d5vNWCMTQTJhGqJzFK
DH0qam7G1fbvmVhQlIEBiTdv5kjeLEymAEew69C5xsRbzE0YIWNG3FI3OvqC
Q+mUeLek9cdEGiQT5wIkDpC3ZQbInkIQpof4IvMiuFIW7f1lYWktfYQdY6SH
3DVOkvotntyl0cHWdDVGrk5/YBpw5ixufk7rf4dBULpgSAhpJpZjng1HOjDd
ewT8Cg2FfJzSDbHhqrxgnqBLz3Q6zwv8nVQbuXMX1ZUUGoT16ROcfh9PCap2
vbyi1h+Zu0kqf1z7CCyhzKGPclOk/knWCppZqhUcyboJ/i262eMB6XzYGi0p
bD3Jq52f+3hMldAlSZ5u7/bt73791Y5i+fQJ+6TnDF1fG5YfjRW+p9rAikir
pFLALDVxX5TPg2eoGGEXsHj640swfrmf+aexF55wy1k8nn6UewP0JfTxC42C
gje7/mjfLXx0bhWwQVHpiUOzIl/g5jOo/jsrfvu68TzP3KYYpTO+kbbPtg8U
fug3pYboxQF96qNzLYEtruYzZy2tf2v9j6aBviBkE/ECMWewzQicmxbR0HDi
qdLv0O/zBTBPxvctl+kcN+QbutgZHtlhJ3hvCUyCx9RVmlyj2yYB+aaCQgob
wgjImCR8DMklMwAzbh629tdd3lyPNgKXib5pv6k78tmGXEs9DeeyVdHZsN+0
UalD270DNLyeRWj2fa/TAG9Hw/MOXKJutt7ouMSs+xP/j/3fwL2P/V/1s+UF
71k/W77bwZrduwbO/mKFltZiRH+CUSJvvR2Y/8dMq/lDLT8Gh2tsGbpAoE9k
La9uvezzfzq3/Lhay14QNeSYyFq+tTX2XP3tMPovdd6U0d+ME9na2dqL7Gz/
JX7j2l5Wpxic8vp0G7H/r7Z7t9ztp/xJzh5iaOVAx72xkmmftnWhoFBQarY2
WwgR0XjwOrUJlogDhgP2TzpNsxiMgy1jSK2IR5aWlVKJKwnFkLt+/kNbhnkE
5yWGlaOrkPQFlrBaunIAgUxEx9cot4FyNNohBsbIV+fclkdlE8agHP6aZqUK
AfIW0afQd4sCTw5UELdM7IVEQrF6ZYU7GR2MFCMgxpYLnMVjKAiRfDrk1UA3
i+puEWMVvAmOdfHRobfFlHgrEKmrhB/KRHut6pcw7mn6xRe0+u9U0CAPouyh
V2IPSSCVhDRiTCAexIuxdf7GaOuR54EjMSqMCc4vtE1zlWdXxOl06uKg5JB1
BubgA3UPoFVkCuY6SzD6zNwywcgUmDSTmxOcMcZAiFchjk6PBzRUdHQs5luS
kk5hWZ2TRNkc8KX4blhfV64G90vXooI55+fVNU4EY2mBuTG6Q+IirpSZrN9o
KHNPWx7K5lYIa8seDIeesRAIM2hQTPpzEH5oDZ0XsQ7SoUBemCBd5MB+VDwi
vSnoi6I3kbIqfE/cp19CR+0AUKSxAkk57EOFmowDMaqImxt/GGqlbRscjPYI
vhQhDvUp48ajbqrlM3FhVjAgbWodCAP7JhClIvO2MNihbXZ0vMvcF19ccLyP
aSqWMXku6vGY2B1dyWkJNnlpe3r39w5A9bbcJDhf8dvRNlTxN8CYnp8l4L1R
d3NwvqHq6rIdPuoh1wYyz6VScUXAuezhaMHAJiKYhaZo/yqMKTTJxAci5RV1
oR+SXO9VJw5oC1BIYZ/ITAN2pu0EwrC+FL0GYzllrNXZ5yU3gZs4rJwpsPyV
0odLoCUawEB7HpxPijI0OlgcyWzCkdABkaPxg0XReOxtbhksT48dDLciMOHY
Z1pjTOUvBqIK0rDek2SMbgV2G6KjT5NRnW9q7zeGNBPLYdgbgOBYtxymRG4L
CYTDy6aYnn+lZr+Jm47Ds8G84gjc8Q06d6p8nGfRxo9v355uilfBPVjSeiio
CC5xJKvQW/IXHZOgFnUC719DbrHWYDD6hIJeGsK3oiYVVUUTWaE0bc057mhj
tLOph4fxpOVXLpSGQBVsNTzCIBKNAXyL8sZX+IMATo9tAMCAKjTJN3pC0W34
4QCNjdHupqjifjCHwP/q9JhBiYNJ4+tQ7KMDuIlie0GKdZlwM8V2Fcl77QB8
iu3XKBa1AhCK7SmKtUX3BIML26Pz3JHk8xVjXUexuXcN5RB+XXo3GnPdetsG
HlFdbLp/W9sYfdiM/kME/Mkk+mAsusVYGXI9Cf1REqLXbMmBTnqal3QhJ+YM
SEn37lHJzDdoKmSZvux7oZ7SooQDzYPcRYt+8gFjvy/za9ba5xZwUZNr4cAM
P1fw/ae6HJ1dqgddIYU8JD75rHIsCNTK6KSKSYMsEjjOSxhCTDNQ+eBwqtSV
AdgE6IJv8tybuBf9ZoUUYX3RYSL06TyZxqkK3uEbk/kcSWKO7bodoweQE0C9
yeAAcLIjzeMkyxztWQZPTyjUIXYr5NsaRD/JOShn9yyeqqsyHaMiV2vqAQpF
J3uXzDI/PF9loTLUokoOmZbQ6L6csp3OL/y4Z1jz4aV2pbavlu5GtQu/0nvP
/KSBOGEBJQMkwma76LWFFdhS/97T//4Y2Z7nfomXDn1Fny09irWIW46PBwFQ
7LfrdGidysCZylIa6Wkto9FH96H97QnqSpzSDOARFDa9Q1D6tyKo8qd71HJG
0XRT0ZP2KI2fFYlnn/Wfm3gy1lE+O08vFgoQS+2W0e0tYwekN86t83E2cKAO
mr4PBeK/yFFEOsPx/5of/OFqFGz63kezZ837Kyfo3kaTiPwikZ3gUqIxUtpd
iw4dfJZf2sH6DBSyg44dPir0uHGnDhx2W3TtoBQ8pT516eC069Th9fG7ozev
v3t09PJkEP7ceYiwaVQ7aQZEe3ZRL/fgf5SW3A8AfDw6/mLHsKIzScdm4I9p
Cf3oxUyvv0x7DxOhV5PA8m3rh7qcpWBPD5cNVf9Qv+eWvgrKor56mEm8uqiJ
OrHLkRJoP5TAhy2XEspZj9qIfaPqOZhttdF/Oknhcz/AUdyv8r6Mf6Lfv278
8PqEnrtL2ExDs9fQzPdkZZn2m1h3/LAT+aK8P5+B2nwZX2GwUw99dj3UStdg
Lj37cDuczdIe6JbintqK6Bk40iwB5c24MTA8Mi1Af81u1pSjkJVI3R5V1fTi
cpTTu0/peJXGNdceBguVYL6xBwmdoAJjXc3+i511ICSjX7LTjZxfRaL8y/xu
MJ78PR7T8zUCAE3T8wjf8HKQ19Gxq/SFvROanTzFby3I/NpwdTcXhUy07Q9v
KzU0d6ALLXZvDV1T02/k7steA/Rlg3Yi2IoUuA+C7d0CelBS1Q9yIZiWOfaO
W1X2gPRm/66O15JIvBap9AVoEBjyPrejtQI3RRQIxAEcKmB3gTLDCnqWzk0W
sPuQBaj8urruvwMAaMadLUYIq/7kxY24pXhNvh5YE+c8B5L3SmXypWjl8cMY
7RHQHnCFoj0PMetpKqXfsmkylpDMKZ1ZxRNhAbGm7Pro0QxEoloE62/MYQOs
Vlxrp23fjuPEf5ynGWVgwmdrg4FuH4/lxy+j/8bIr//hMxLbLBmU/gRuObSA
uUD4W/yixulAGMo+ZpqBTdcHq/obpxkbhIeB3G7aALdhmKmYeWFLhc/H+qzx
V/wpS+Jz+NNrJzarwav/Z48cQgvVMp04+NDr5X4dcOzOtWF0IK7VrBOKq+CX
81vqGnq5Qu/LNvTyLujld0Hvmi7OSBNIJxqXAOdQFj5Yc/pfaOuvtnxf7//R
ME4yTibIToglh2NXN3o6ikOruFqU/kpOpums7/300e2i17kG+KNFqiwuqz5n
rcEON/DHIb6i6oNq0ceHax5pMUbeH1ivbIeBoxUH5hlNjHQ3W7W+Jtlu3wou
j37VcTOH5AXbxUi3bzQqLJF053Te2nmvtbOOR1T3UGVTwzyeNv0EZ8KioHSH
Tb+rBIfqwz93lJeP8BGJgsB/xyojmiVFeQf+j4xgSw1NdWfHdREat5cZWp8w
h5NoE3Io4slrTkZUBYb8FAWtDrrJt4OrOaPEaVJ4tgtHaaB/e6ZTo1mKhEJp
zbhf+Wp5w7smJKfslpz3GMGdfKhqbw831cVpLWBaB+STRx5v8WeTRxgsUdhf
2rmyBtEx2iOIvL6DLUOpLVRDdTW7KGYSI+FeHdu0skINeiISe16GJOUrp2Rc
w6NHiAdGMVDstcmJtKXvBeoJQojozMFyw62fjIByRcFZbvYyUE5+mGXpe33Z
7GZ6W8XvvqXc6Hj/S698zKMY/UaI9AgrnqUcgwRUlh0MuEU5X6wLiWGEi05v
UQMa6ZHQXSuHGz2rXQ/vrYdZmRMTGTLHZWLC271wNQVXIqriyrkJINGlYyQw
qETeCFAcW3bTEsam3kPx8wj35ZM3qPpGX5Ns9JRe1dskNRMfkWvoDcFeTgKh
YBBVkVCcn4HUi8c9ea6NlzP4xCjq3UIQ9jh3oLy4UE80OGwIX7WkGYYbYII+
nYNNCEzPy1R4gvvCAWPy8GngJt/c8Fsu6kvRishCV3GaUdQD7jPJx0VB3fAv
tgxiO4LF3nvnMeYcTX9JJH0AhYE7L5LUqlJUGesj6qqSE5LxdZxS0iWcWv79
6dOmEUh8q+VFsWFUY2YlEUNXiTz04oYoh6kV39PZadJk1SY6YxaOSkFBSIB0
BiIyhaXeAnj0OLD+ukM/FIkoOsXBEXhTDXwyU7kCAT9JIkSv880W9PpEVfw+
KS3lzIQ2XWT5CB9FztRiKBEvmYasICuaicPEzTFcLIRI9tmRVpucHYqtRXnz
NWX3lY6SqYlZCb1EW7PULxrx9pCiFOmRe+KkOCKW0UG0yodWcrCXHUc2wDgm
9DUltDeAdhwIa21bKw9cYo3At6Y9Y5f0ENaJbDDkT/KrOWDlMPIIUEcrGmqU
Pbyu0ywTVpJgRCAIRRRJkgBBEhb0J+BijNR1qEP3pllCrEhsTg/hJRsUg6Gc
dxE9eOfzG5sPoiPdCmljxUkremg7qIfib2ZOhyzHS+Z69B9tYSsX2g76HGq5
FXtiefTswCYdR6bzFo5vELgVg4YpyUH1obAyCRxWcVSs2GsdRyQDKkrvzYS4
FQjT5+ji1acHBoxyf4r7QtMl5VujKw0ZKSSX90i7YTRNS+Br4Ar7oAt3vgIm
qPT7XWdE2/lMTlMQwxcXLEEnCc4ckMqncQY8oVdBdcLs3CBkk4JetvIcJSbR
CQtVojPbBaG5pQOxg032qImyFiJtLcjvRXVBDUxq961oaM1ZXiq+QlIlM0zS
GW28Gb7aFABgXhAAsSXke/h/+h47y9ElP12NSdjjQ8qJDAt8BTsdVOrSCY6o
YopJ4LflQGWcgAQnUBY2TsImj5Oc3HXlYo4PFpCJMkVFOoqEXvSPk9Orffrv
QYBKW9Hz715wtOIm+8b067wylGbHhGSU5sCj3UFpEDjOW1x5JiZEecFILsm3
hMeiQHWHQ2RKJ4pE00hpipjtcVGRXVAPxqGQfsQWHydgzDCeTwattOS1AE1n
VtmZfDEvipNu57Fx1UUaQNTmttIWX5svCH9uMejo51s4WDohWPoYBt1Bnx1D
x1MXIJ316zfLB195fBivuCGLoA2PcKtu+MhnNbx+zss2hLyfO2KyGgrnoDKD
WOqz8F5CodbGnwe9vLiOi4nl/g7iFWz1OVfO8k81IRVosgJGq7hzPFErPh0j
zLlmCUpDeQdnxKN1Z1EX2cqsIIFpmxtwEIMRERc3ThQdacThvNViR/mGqFa8
2fBA2+UCNJGZfvrVCFFMHHIdGDCSJaRmfdFZDdB0UydHhjbb6rp3J+h8fJ7a
IE8F5K9fOI31yUq6wxJs3Oun1Htrz628W6alLkzbTbn0pslyg4OZl076ErLf
NzlXdDsNNiBKTfMvo/8W975+zatcxuTdt/zQNkxbGt4ZWLMkuzvoujC6M0xf
lrQAjBoBtt8Vdr7oW+Kit6bkt7Bw9eYXutZxW6BfKHir4zYbXcyjX03qgUMw
APrwnVw01KhOnli2A2stonojn2R223YKNk7P6xy8menamZIXqhwODQ0Nv9Fz
Z9XYXMzVLhua+oMhEIMh3Xfg1Mms/yl/Sz/uQLkplg2FbtH7QNWB04KqfLqj
qq7LMNtRPy69hYMPZgw5jMs+519sBULMFpc1ECsBiScTMDXLPmXPu7Hxadw/
HgSM5qrPYxUI5Ga5zOd1KAswtp+241/SM/8CxvK6j3JALJ6190ZnXR/Oydpa
LB95XlBpkD67Jm0AXUYusauwDYo/jX6n3mmV9PPzfl6kF+lsGYNKrpdDGkd1
aoWfzq8O+rcchPp2HqlI8HEkFQFL+jqSD29EHcZskqMfw3yMPy3nPiM26AXk
xOKALosAp0V/Gn/oc1akZWOYltYwyGV7u8u6gpJAylZ1CVPEtLgIAZ+CTuPs
YH9Z76s0z+h2f2wdFQmIhkTKB7b3hzGrGFc3hR6CeyvihjzUJ3he2i3fJ8k8
xlvWbxTknYNlXZAKBL2pi7rzL+fntVMev2w85uvysI2PVJ8iiXW8CX04piKv
gJX7Py/iSUNHLHeWjm3B0zB7w0JZGS/nH4lGKktFVPUJcrXa8SWYDD6l8Mv7
p5TqyA3sbxo60d2QI52XDxSm7P2QCpSuGqXgu3slVMPG0b8v5hSxQ6GeYG19
o6cYYB6jyM3YMHN6LeuEO22CJ6Tda1mn82xRXnrYtfO2HIVm4QInsBJoRVFf
APzSX4HoFiug+6DPo4/5vG8aDmYvqsj6bnQ+cfCDfxvU7IZlQqVq+2Ky2J8A
hnZXdErD2dnHaLTqQ31JDavbvSTCg7oVH2prGu7F2qq6DEvNISBjPQ11Qr4R
Ae1/1FDaLeX4J8Qppb0i9Uij+lOIcHkivpZLPmC+x4lOMq6TeLZ7VFKuI5Zx
HMj4spZUwX4DS+m7uegbJaiz8sxKFpAysWD7MSaSEZbrKE10MA9jQGYF3p1S
hg5KuasLLg2iYZuvZ8uLgLZ8MXLbptCeHK6t9VrdMT2dg1Iaad9aYaUilfgG
QVpCidTttNVbcm/w3Vi1mLNTTdJ/zJHbdNwHThUz99BzY+tubQBohz0+jG/0
10WMtYwpqY9cwP01P9vshLyUOxxneERI9eMtOIupxrNK4qIyzqiwAs7hsnew
v0+V7XykrxTSXTxLagqqaaSbtuEeaOzP5nnKr2f4LvE77YeKXug+G8+/e7Fp
evK2evz0KZa3sFcJszG9l+QxPmuqBMuCLHfhABt9c25dz2NGZayTNSaHkAmN
4S/VHS1e8ZlQlzfDVyp4xLmHda75KAjQCnQpjfjg+z1VqVPXzbDvJ4dztPIo
THA42NkZ7HFyrcEOpVFsyu8YfGyOa97m8pPFNstRX2VOOqAWhV3QXIciVxtd
96UX/+P3SaVeNtxISmZ7bTQojH9Ql5/Q01siGgJhDsfozcdHlhiwFb1MMb31
xvDoZblJz51mPo83uyPVZK2r5iZ+1k2caVOIicV/au89//5UN9yUtF443beS
HNu671cxFj3j6ezpa2s7W4LF7jr4C3b9FKNFNJom2NNiNTeosYcOv55JfcMJ
zt28ClTzTp1QVkZekYmTvy8oEE9CwtxIr9JqIYVT4vdJMKRK/W6yhSHOfDvx
cjc6MgHZfCuR7ar7iJ4T622HAYaz+UjghhsCxNEsGxh5gs/8QvG8ahP7gR94
HLRddgB6K15z2C9bnKjsWzq9Tfj4LcLjHbfEOJ6Xi8w3090GrvYYVmyNmo3p
jd0fjM0RX3iaaCMw3Wd8lcVgGliuk5qW7w+hY4XKWiNNr4183h9f5lhc+ptQ
KwZ4uDHP55sNvxvbznYsJtN5ddMKEQyX5SCh0TedQVZFPCtRBWqCq6etW37T
BteQcsdVrq3c1Ye4LulkSXde7masXJDqb8Ul7aB374bZbjNmIZBtmImzNs0x
KqvPafo67IAlG+nndObto+gW+0j3KTvto2i1bRd12XaR1a552+m/G7ZdgOL2
tvNt+TrE+rYLgFyy7VyQTdtO/x0Ft10jqrfedrXuIea2serO3D7oFbddrXsz
ZiGQjZgpboJTT9nMPjvRAuFBvYBDMdOtGrZlrWGL8Oh8fuku8zJZTHKsf9Ms
xNHrNNbbreZKrLc+j4s+mA3EULPa6W0PfzXPggfh3Qb+ssPAH7I4+LNpMUsd
GdOKgaEnXkuiV6TzOrhd07n4g3ESdJVpvgqy0dV8Vt/jwjroh/MmYbnm+Nca
6yLHqfgjssvx0ZkCUbtct31koyKdXFgxXt+09FC5rdy2DWMInSzFEbcC3f9y
0T4DJ6BIZvGFKVjhuCadX3z/aaCzImVz9MU0wSvnPubU6OOzhgbvqtUsHClh
NxadOxRbssLbUQJdU83bglNqjS1vb+hn9x1pUxv3LSk30a5QZb2IE1SMH8sc
q7tDySpzjAXbKjOF6m1rzGlOFarAdtxI0fS62VRpYjPJcjh2cj7pkjxgd8Zg
VcEBQG9B8PFcpT2iKui8pMh1MAfTuQxmNBEx2rFJkVzjuyPJH9urCf0GS5On
d6NQUg8Y3VSHaKDHeuYMlbJBiDdQsmxLltvTAssPAbGGr43L8MfTl2ebdqvk
v6pElUCqV6+C9v8F3aEDvaQxh4xdi+OAK3tQUPk2FnjZBJu3JzLLeUViVTzj
Anj6GZw8K/TSFYMJjTl7Lgr66q3yoeDCPkchhf/YOHn7fDPSexuLDolLXIhV
LkZWqRtTeUDRmYuVCXsoDx46MHRaaV7oR9Z7BO0VpDFA57CeVImI8jzTCLYX
ksn4fuedW4beG5npoxDmEdDlOVI02KJU7WP5xnpaUK9cR0gExXwvUEpOkcoD
P6Fkb/jepf6sUyU9Xej0/Gmp3kGZ9zny4Mc/PHrsuDk5DThu9j6p6pY9R1g2
7Cd+rRh8SuM8ecME8ul4QeUjCH0YWx3StVfI4tFRe7sGfalLZ+8f36VTA7Dq
yaWG3QtrJg1KRjq/2ncOfPziU10bNzFpvIQNprfSxq72G/UxDow6Tz/0s2R2
UV2Grv/kEzC13PtaVQ1SX5E2INVuqW94UAKmLemRkxtM/Tqua5IWJMGLlK4A
IEst5di7IDQbO26GYVZqfL0CUaNRb42SfJijr7tqGkdzm7wQF/BJ3Q1Q18dl
vvOcQnLxf/puXG69p+6sWpuvG7TaYGcOOQoyWb1LR+5sGgsj8cJsX+8hn05D
Ka7RcfCTy/G8nWmwheg7zKzL+KfWowm+NYtw8FcNmS54aCK6rdvpSNDxVvim
Bay9QsrWsSzDz7FOREpGK4i/YK63kqY9pg1s6BHVNqDdq7nTinO/xcR5jflm
VQuFoK/MEQZWaGZIFAR6uKFx9qfRzg2QrXGH6n92nLcNfaVnak1A7HdZba6z
qHs+LIstMZzWP8EPGiz1phM8QJ+DcNDdHU/waIUT3Eaq/alG6wmuVyJ4gnvE
bDvB9R/NJ7jd5JYneG2U0AluN4o6neBej9o6NJ/g9Z5R9xO8pXPTCR7s0pE7
m8ZqOMGDPeTTaailJ7g9xPIT3G7d7QT3esinMXzbRaYLHtHyE7xOx/AJHqR3
h1Ms2E8+q6xTwwlu/9HtBPf+6HaCe3+sOPdbTHzpCe4hsuwEj5p6rHCC12G0
neD2p7sMsKHf4gSvA2k4wUOf7if4H9O9vOe4l11/USilny5dJj4b46TLVeGU
WF59yw+SwMtOSdUcNaQcZbMkmaggUaeoWcgTpbJamRBbyeWBgbcGjdJzIAZc
J71aGh9MO6TzW9lJbDD9X1wU7Oxyx45d957jUiXPm5ntmFAkrJyUK5KePT2P
MIsShjyOqaSeepvEeFIT7EaOXO6pfG+WL8m43i9xRY1jLmK1hxxnUworwwA5
nTxOy5BDU27txV+OTrfovxTHe6MS2XCUpvH3DaLXeaWc0ZJYGdFTub/OsOYr
ZRMbKkyGC9wO9rXCxtnL4fBoUyogPj3AiG5rAYCWTSToNaibrgddsl65zsrI
9CGacEKdii8ArPhB5DjVFMPvVOciAV251CWYTo8t/pM2zjSp4tCsHeOSSp5G
PUft6KlVMEuogwKnMQYB5lzQEUl0w7VMla+buvEhpPzUlMs+zQuV8YaT76kq
whXdE/RqWklP0Z8pDmzaaQplFsfjnorvI6siOrGyQ+Q6SaMqLDicXGGMYJlI
WSs70rMsFyqpHrGKTgvELczmJMZjG0Zfj+D5gHtfBWI6plKPWKnnWD2+YMAJ
e52sae5ub+8cTkZPD7cPdw4Pd4IA7fYH+72tMKoyWS4uVfqgH0FPzoBH1yzm
WsVkxFO3WTrtUVLgRcemVUwUmL9cjGYYGayEr5SyijkWhp9JzJMizZXgIelq
XeJsOUlOo43KVGyAYTf5CgpDTTNVCczOCaIGtW41Jguq0hAc/l1z+s1Syl1j
ZU/g/cVcckSiS1+nwlQZq9QVGN+KYPyvm8BdwoxLTiXfeBmBr43c2wjOLHXo
VVFfIbfGP3+mhY6pFix1xoZAzzi7vuNsgEEPHLu+cGyAgS//Oj79a4BAb9e6
Pl5r0w+jFbNQ39NF2O9/DbZSAMdteb6ZACH+tz9L9oL3HgIwCSR/qj92D3YO
1jKodWq2bSyDeyW/pA09RILlVGD1seueeZAfBsK9yY/PZF/K4agzi6lDtW5a
vhL9Qc7ddAZsQTnINnr+ju35KZG3+ElmIHn4Gmu/vXSCURkqtIQ1E5Xqlodp
yj1eueEkUjW9XONMw1rtMejKc1KUnn7mTE4aXAuTsdUUHRZBCa3JmvRJwqas
GNVoyyqN/J15xyPv3OJKZdPgdN5UTNWtjqpT2FIa/bUasUWLV3t405DRfpDE
0JOZzua8RllezxczJ4O/wpQeQVJ2e35tp98dBWvzAEHeeBl4vXdiHpPQ0y3N
Izq/NKica5ImzqcpKYVfkGUKE3OVQ+u9ocnCq14ldlERVf8uWqK7Vx8O8897
mK90lj8c5R2o0HCUK9dvXI5j2Ih9fK3CVq5/a+UsGF7bmqZAUfgHzPpD1b/M
58EUQDLr1hCnOmII15qivjNuTuVjd8UnD03R4KFVY/y5iR+UX2/vpi5pTrSj
O7Smm/B66E6S8qi5nZC2JRWSDbDdEb98mJYMbR8darbsgciBGN1qM9iUnTvB
+R2Wwi7PFGJUuVXxa0iF2npAl7zwDHfuXOypCdlA2anwBlStb4NrdCdcTZTE
iqJDPstiKxwkm0THQXsWsNVER7Si6IhWFR3RyqIj6ig6oq6iwwa4uuhwh+mY
3HGZ6Igczrid6IhWFR3RctFht1omOrwpr7Ydnc633I4G2aWiw2t9G1yjW+L6
4FjwIfzRHQuWSSW+Bc90C7+LMvZlPZmGmMWqTBOZiSen6joGsyEpgU2pSqRo
TqmfdOCrJXXZsj69OY+v8IV5gqfQ+qbJ8aFuHxO8/xgnXkInTJEiQt4bhQs+
fagilP/sQNCFvCvXJAVbFnqajDxuIbWZddm5Rcl4Epm4Pl/sWlq9SQpaezHp
of2t7rzwnV5vkwuAAMpwTHjYXl8mFA3w/LsX1qU1QgBo/DcjTkXJDObQsipu
sOoM9pTEKXihQxmTLGMex+XzLUAo/qH2Bsqnk4xGd/Kqj6wR5S+iR2TUEidB
SYDJbYJOIaDj96eIhRHtAUzMj12xARDvOEGR7mk/b0syKpWjfkbnEXfm7DMq
T5J6QUT+JGDwSsU4KFZGpFWFIET4B4lmoKxAGi1VZaiZYG5YhKzPwkCjnEAI
bmOSbKo7dOUKsupD1eDzPkBnDCbvYQ8MJg817hf8vqvvhdKOPlzPfZbrOaXa
PGRCf8iE7veSz0Mm9NDnIRN6c++HTOiKex4yoT9kQv+8mdAfLNWHEJoQgIcQ
mn+We7eWEJr7UvEDjRpVfBuHlVV8u7P7tNHuHPaK231XNg/szq3mgUe1lc0D
r39H86DGel10bm+olc2DBlSXmAe1Q6s7qnc0D2wgtzYPHEa4lXngCq7bmAc2
hFXNAwf/lc0Dp/eK5oFD/pXNA0fQrWweOL2XaO4ug3YzD5zTrot50DDIcvPA
4Z7bmgfezl3NPPDFRmfzwDt92swDb4xVzAOv64rmgdd7ZfPA1y1WMA988jTX
e7FH6GIeeF2Wmgf+Rl9gUF+l6hw0ajuN/LCEISIzFUwoD2yBVd7jrLm57rHB
j4X8l71eW25+uBHnm8vaeVzdj/POfF2HEed9mNL4Mm4WAHYn+UCfPnU61H/1
m/ehO8Xp5HH3OULj3xzBhtQG9daRxRV+ss72HRQEUTseW/W8OgiqT5L34+wC
b/Qup0vpZX2Wl3aaJenF5SjHeqxFMs1R4LBIDnp2RLTYDZ3xGvOjeiBW1aB1
R6PmNwVc0Qfsn8HgEfyfZTtYfz9C9b95kNu48Lv57zXdb+O8/2jw6+q5t7ij
oy/cyKFb+OxrGC532FvM2xHDu7vq7+6nv6OT/o4e+lu75+/gm7+1Y/4OXvk7
uOQ7++OF/zo741fzxNfAd3LD390H/zHMo/jT8jDIW3jfu7rejQqwmt9d91vd
6a673sbj/tEsxkru9i6+9o9GS+jkaNftu6jRBocVArIb9Wj30x6EzUBulwql
pp0sja+Wz+0iJDuZGUto04UaywwMD6Fm68KedKNpYTfyMO9mVwQBtBoVXg/5
dFXYa9MKmhNBtNptifvGq9mKcAdY3YRo6t/Vfgj2rxkPUUflojVQVk6WpdG/
H11wK4TTqp63j/vl3p2CfrnpbSJ+b4XiwxVoZPX+/MG6EoMnkboYv3eLMF18
YqpyGan4UXrB2zNWZQ+jdKmoHgY2vlCl+2K+a5JIWWzOac0xENJN4oLdznSB
BAxrVCY2hQQ7Kdqd3FKqYAIFjaKaMsrS8hLRr1S4IiUyQcylyC+ObVm5NHJ0
oivG2hawvJ11EbcNXerN1Rd1/UE2TR+x/ecX7ny2ffAEC3fmqlykDsb16VI2
BDsPz6LXZJtFG8Oz15sUB8vWnMzEiYKFn3oldHpNmDsKcai9UF2pzNb8B5GK
bFa8hhn5VRIdfLHX26L/PehRBq2eSZ3V03G1HuxpenFZWYGrFxy4bCJ0pa4C
hkRTFPeiZNbAeoUqRBp3Hr+S5mxVXH94E9GagLpxxUmmgNRFPi8wBFjnvfqO
sTixyvBuDL87KTejR9EZvoD+eYGhCG3Nz7i9ky4Is/HrqpGEwQT+lybipJ/S
6YEWMyB/WXEmrVenL8+il3tYVgKR2cIRov+IdrZ2dp9SYU/nAblUr9gf7A32
pX7F/t4BVbulmp9Z4m2sSgfxZqrepewKkAuZfsNOb8rj9wm9sDov8il1xDIy
DRjg6ET/3b19LjgqJnqIy9i5QFHOKG0STB+G4fUUP12QbIm5gCgyHjKuMdsV
vHPkPpUmThcZ0W/zTRw8cH4kXRXnmrD4rSgdJAOsfDvP4rFIDerCK6gzstnF
JxQYbvq/p8N3fyFczXt/zcIIyXoEoF7aqx2uwMSY9Uq60lwtPwNP9ofSKuhR
5SBR8gtcTMVBl4sRHbcg5d4nyPoCGQFJTVHKX8aSQD1isFPyeXMRAHpGWLWU
WJl4IRaB8DLHNUNmAXP2Cubp5C5TUNwJcUFZsIDT6WJqMUIdTdU9H8MpSLK/
hBGf34irrL72JqvXdg8zKtC7jy0Fpkj+TuH7sxs9UTM9bitHQB2VTfXawHXj
8OJQFjmdnBEaM0GsHBNcIVbhQWH7VLj4iMvFlrWJqAB+zcMOv702SRVqlWcj
fryAWJoq32q2/pLSU4Sad4mndOQhICSXRw66BK5KEafHku3qOocY6KuEShTl
tVwf6uGDKTGsX6aDfVbMDNMh1OgqjZH/dM0TSgmIJ5N6qiHEyoUl9XuFjJjV
KvrzxBeZEaU4O8NhctF839AULF4h6THOaQHwVKZ8edLs+EPFxD8CbRAmWt0g
OQIOM6LJUVwUStuh9HNy1ugsHyhWBKTCRwOuPWxy0iqqSQheqmj4k+0dEM42
uRoJRedH0AnXwCNcGZ4KIDl8wclJT48Jousk69lwuPCOSodI6lws+fhEWqSl
3sxwRNBLJJQvNkD8ovYmqSZs6GjxsiBE+iyyj0VfP6OTh8/CaUpUVLhsWXsc
YTGLubliXCdcT+sMrHPr+dTcfDKtoXgAYc9XlE2HB4FpwjJfJIV5PQXf+Rgq
6B4SNYpdX6Z4/I6lHFnyAcyQKtHPsswc2+lqjxwBF6uK7ipBrE8pnSGWXN6c
glAmO4WliC+SrUi9h8Pvkg+g1xsg87i6LI2ignKI9FDluZST3VgASAnHrVkj
xBaduAmw/aTkFJHYji0P0JKi+LzSoplpJrqVsI4sL9hZYpjw6znjGuW99O46
j/jfIlrH8bySMl6Vk7f2MNrYEQdMTztDQetmHNIygGo9n6WyyBScvwCY6B0i
YIvH/cGuFpC7T3ZQq65bWbGlLsi88XTb2N2Metq3246ei8x/SidGSJJMxpjS
larhacXQRXbfQxbNjug55qhVpMVTGWwySqw7sRb37u8oZ3yP7D+e1DZe0ytK
1/eqeIHr9i0yPF8x0ZV+Uwg6GMh+2B2xbBhFMUOFnT1rzehQ28JDCsSAqiFI
05Dd8O5IVm7oIBK9YeN3Axr0h2825fR4tvsYLFdaA5OXq7SWjjI6cQLbuFRa
1RSsCDpqEK9XLx5raxBztlsmNtcqjMtyMU1UulmrdqCuTMe0UOMxfqJ/2hpX
6dhh75ObiPyccmbqY0R5FbQOTFiAuHqdMypzEbCU2TcewQkJdsq1ynGtwBjw
rH8ZRAa4t67hdC221OtOeSppMFNAGACI+wXsxTFaLLYDZpTcAKuqJGL6PH+6
g6UKtyh/ayaAzoBDTl7QMr1Nxlfwp7VN9kydQ17OTZVMmGwuCYjY8hKCNXqC
UnLTpHJUlHDioEpmF31EgvMCmVRgyoDgI/WQFA07qiJgsnIDO1k0vZBFSSBI
a0eI+KPwvCT3EzW1XTiH0Wkbhkqv7gnkntKuK2JlXOBkQr4oWiVsms/oB9Vf
8ZLrNLKe/braiXnx650f6inum7PT79RbXPSQWo9x6Zeur3Gp78NzXDvO/4+V
LbcprGJ5HBMwb+wWhmA3fF7BHu3/vIibHjy4WWrw03Chaq6tszJecmf9T+me
jx5eKH3GrdpMgNC2tT8PL5Q6UOF3SfL7TyP1yst4SmlXyuCc+vr3wOzqQIAF
wea8SCryB7W/07Ia4pcd3kh5U7sHaa6bz7HcxVXSIYCia/j6bQLXVwlZ7xys
zrEkgG9fB0S0BErbWPSXRXFbF+Yrx2+7aHUL4b5T8PadwrZvF3OxLOCiW7SF
B2iFpId3iLPoGmRxywiLO4RX/JPpXp8pNEIbRBIbQeZU1+AIatxkFx8uvWoX
71Ko8JT7gID6p3IlSy4kKYo0QUv2J8mWRffH6J4yRau8C3dyyP68SMqKbj75
DmBuLkyonBZ6aVHDVaWg3BI2eTG+hO5FXOWFumMfm3tVmRTS5mpX+Sj2H6OP
AhGjr/fU1wePD9CZZN1CxLNZvpjp9aLp8G0Qucr4tA9dJtNSDOH36OSFl5ss
GkrmL7ypUXnG6HZW284M3hzy1o0r5tICsJUaAttErAjoyjfXOdW9gZ8K7WNG
tR7RJRcM3meQm3QECzLJgQwIQc3RdbYOzH0U0wz7mxaP5VcmHV1JqjOccT5L
qqb7jpcwJpf+8uo6CSIvz4YSyKBJqnPek+c4Ho+TeUVOFtYEGq6B4pn0tqq/
qS4Uy4PMmzR5P53bILdBVALvTdkdOkpEb5BdoiKMHMQHtjNVl2LzoLJ6YLmB
WFjRKLkwivJVlod8yxVSbd4VMRgJBWHibIDHT7afwWLyP57sP9lXK+tshyc7
BwefPn2Njkt0LW5ZLtFJDnOe5ZXMQMqyPX68y4EWlmep1bXkuIu85PsnZ/2T
M+VlwoPC8jLxT13dTNT5wc30x3Uz3Uc45R2NNufxnP1NQyfyvjo66fKBwkbe
Xa2bP5xuFP0R/VKd/U8PfqYHP9MfQe49iD39eXDqPDh1/M4PTp0/gFPnD6R0
fCaHjDYddE10sjy6emS49Wd1ySxxxigvhR3F4NpjjCL7BrgRvfdAOR8y37g5
/XwYvaQQhJ0t9ceuRq6zy8MYcuzzWGrHc4ff0JDX9crVwGLGqzAutGiljKC8
zolN9A1CsONiyMqmZxhpgaHftb7Yk6KZaqeaFnUeF61ibrt2s2dvvz2R/Oqw
hS1jG7/vXP44fciv/s9uad/dO397pbU5Exb/vpjToSVhnHwMNie2UrOfQdN0
4vZa1gnDXCf4fsTutazTebYoLz3s2m9E5SWEUaIDiT3+FQz4h8CSB4O/CxX+
YQ3+B/H7jyp+DUlv74p48EWE0FrRF/HgTviHdiegqvJHMPrFiNFl6k+6J6jA
tr97CEakaobZz5AlpAHzPxXAln6ABCCur4d39x/v4RsOnMxrrDL3fTJTObmi
DfhydiHvb3a3n25jS41kIXAdQxptVPtxmWujGuqpV1EboSdRm4drCvSXUc87
aPihXIRv5eh+3TyIq9QjL5wKd1KLAnw8sAD6h1AjxFFyjoXqY20Wkwk8ScZZ
zG/jCI4NunZUWbBDoEdJVfGCyNtmRLhI4HgoEweye54tR1mji09X9Mt5KWtH
C4DLxclI7IPPC+aQp9eIIje4N5eL9rcgbMtB0dnFYXsrPAfHj2/fiocD/7Rc
HPTLMt8GiqcH58aDc+M38HSvrKHrPnNcYkwdopUhT7F8sPYbATxY+w/W/hII
D/Koll55uUyig5NzhFsrGzCkzULF4/eLeR9fq1pdWrOZm9HSosJwY9Pwy859
50WK9p9nSLZhWpe3+Aka85HNtL7Z5dK5yWzUf69mNjrdVjbODGotZqPXbjXM
opUx+61MQa3ziS1ImuIyI5Aa/QGswNe55JEijCS7gQT4Pnt88PTTJwVKxyLT
MBTpjveQODqq32YPu8HoTr4kGkW/Lrc2sTIGVGohfhlgv5q38zTV96+XDVE1
sEDAl/yCvwTqZz4esqn1VXR6MSsNvlRCm8thczttgvAE9HhkPfGTfr3pW/IO
sU0xT+L3mKqNcyhQH0pvhGyiHj6Uq5g3BNWya8wSz3LfwDIluVOdyoYNLIRC
WTgQ22QtLWc9TkNGeQ1hKBrGA0dx+JgsBROlbJSwBcxDgGfyEIB5apMsrujN
8JVkCYinkiAAvluaFyCeeobWH8+oWnKBps6xtlzfrhii9Ar9joqg3RW2RFok
kz6eGdWHuhfdxGI5UwPe092KDzU3ergXJwmkLIpzkDtF43lud0L/hyRH9z96
qN/W+PjqH838WOIF7cBtjtbM3AbkA+apSMx6lkJkcRc3CCxeN52qzBfFOAnW
lgkVl9H9bpewXndvtlasP1a1VnwKdt2vdaJ23LJex+671uvYeeN6/Trt3VBH
9+z499AK+BdK+HWn+yK7+zShnIs5K5sPevdvonffx0tXdcTrh66gFix93wpt
LK1apaUzWXB1DnBMeKZ26CEn1mYZFso7jLnRMCmSBD/y1YmjOk3j+Zy1XT8p
FOUXBAg6Ex7rLyf9FwNyCefzMr6+6FdJXPbjqgLc8JDrj9NivEgrTHtpkCN4
clGDahklOuScZQnhgDTQaXwXs0lSZDeUCotTOauneZgKWWVC5uTTu0/UmzxH
EAdowbm8bc28qCc1F+VYp2hupZebT/0eyOVN4rMSrPUEIvq9xWRtJacPtrPs
ETDUe9UXJQO0ziQViasTvMtrZiepfD0rrTMMp8s1B1EtW2Cq9sJ5Fl/lzi0g
ZrYF08ZaSHlWPc4wnHZM/dRj0ad8x3eWxNMM2YJ/Qlo9oZ82B04KZH7EzVnz
Jub9rrUp+fUub2w3x6qd0toZXiXIDx2bNG16VZvOOCWr+oGyZU7TcZGblJlW
Zn5Kwj9NKS00YafMuGgOdl9SQWuaLZpFf0/pSg4zJ6Z8m9l0Eq+CjLzY1oms
A0g04YAprXn1kK1Nin5zxGtMZslFXqWU8FWmbGGlOyiQmAUR861vSe44ufJT
e4DNP7t6Ag4uegIN+kMo+W/yYU6ZemmSciVKwBRlsiy1kl8GLhNP7FzYQn/o
C7hMY50Zlq4RNcN5JuyUDg5M2bqQ22Vjwx6Yx+6K52BIK6vzVtQz2kbPZMSm
q032uqggbtOMRqQc+faYasQShxzskZ8F/6JsoT7Td8jRBxOFlmhwn6mDWVnd
8P/qEJUTe6npjd2U6U3M05OePUtql86xQas7owgatQijRLMppnAo4nNMk8ku
mgvg9BklyH6nn5Ork1yHKFBsPIg9ReL2EZTceolGVrSLZxb/uWd12eSj7Cp/
n+iaFRZAI0+7ORserNE7x+RIIJxeA9twNV87OFrddPxcXePXrWiirAqHi8r5
OMhpHTKZN9RvfkhdpELWJDe/wNhsNlnqAy6zaDtcwUWOZn87u/ZwQ0pLNM9C
E0Q3dQy4JfZbJ9NARJCYBlqo1e0DEnlckUVJvCsj8fj7pQLvaryqr/Fh+/8W
IXnKvq8WDXUPa15KBQjWc570q7wPZsIIjtbrdAIWgC1e0tkoB2ugP7p2nLHG
jya9YElH16Ra/4/bTo+mfuYfwo5aR4pg481var9GIkVgP43zcjPUQKMHDQAx
+G/fij2IaoJAN1YJCX3/bLh5Kq4hbG7qdza2H5UrtU9WhJ+sCH++Ivx5B/i0
MlQxIrgukUe7ZkCRR7UOLZPOMJPOMOedYc4bYJqdNqadNm/aaSBEHrbaw1Z7
2Gp33Go/525CEPh3eD/BD9rn1LAxrCbA29a/nICxyF0Vt19DvFi9T0hfjWr8
sYq+Wh+DrUVTQDpqkg6iqI0x8kKZln0sHxe6tIzHWYiQDU2AkGDdXnMdmCZ6
et3DHcJk9bo2kLX26UBWo3Vf+Vo3689hp3ygHqUo3JaHntyAys9XoicetLmA
31lM91fvfiBf0OiGSt2Ij2l4RH6QoF7XI+dJL3wUWUPdOCiaw8oZ4zBqHCV1
XC9KgbTgSGk+o3NvcBU/9HJleWy31UH3go7YjpLvEpMrbxp8AhPz8JFjtgtC
i3kjOpjTWVDwUNtsJ0/bIoh3p0jwTQfX41uUkpkSS4ehY3MSnViOvLfoNdw4
Onm7ueW1er4oyio6S3/B35+fqd+PP+CmDoA41iBUE7v/se5/msTvA71Pqbek
bKBGdv9T6D+IAMut6Bj/gw2hS72oz2heUrGhDGby/Axa43+o9fOzQOsbTobB
3lvrcQwoNADHqXX571xedAf9854XzfG+muVGKPSSpgcKlVKC6OUID2ca4gMi
4Mmj/GxgN8cgsbb2+LuqZaV6IF9JJataF7w6yTK+gjsbnqqcl6Mky3HGucle
ilA8uMyjjaARG+FjnTdUCtTxfuHCvSxgfs5rBX+5uChspb/mZ+IkLANlchlA
4GRpBDg8erkU4BdR9Lfh6++jV5wslB0c/OKEpHBaSh5RqkFL7FHnjoNnz4g7
3Oo86l+7z/atf+3t75l/cU3gLY/H4F/B2zrWS9Cr8GlL5Yg9OT4+frq9O9j5
63iunSt0tbz2p6M3L46j58ffn7w++3NEN2br1hOab3e3dx/3t3f6208G2H5d
vbOxn9lEv67xPXVfohp3Bjtfw3focCnneGG5vijA1ocuh/QQrjz8MM0OZ+Uh
3W5boNaxm6rqx998jXzGFZN5TKN60bi6ufn+a/pa396pU3kdSBch7bDuzxED
oDV9gYfkK3J+n2uP9S5RTnmv6+f6j6evS8L1k4cdxuH0efkd7PD7FryQMw7r
WL1jMaOTAAeH1N49d0T9dcuwyIKHQSr8Z3ITHWHv8DTFJRWYaaHm3zYs8HrT
bM2jM/VwDDM3t+LAhbZrSMDXbYwAWwoZITR3GfmUADcss7qK95f5vG3asKmb
xjzRd/uv4ll8QdmX6yMnCezi/iSvdn4Okd76oQENFASgQU4ikQaH0fMinVxQ
kdGJ+nsSvVZaar9fZ339GWKtOfLN7m3XmChINblYd5CeXbeT7HETyRSS0Ttd
8HgrqqNrbhR3gjiV8VzLMI0TfNnGO/vbTzVSgoXBS7T1oY6aqGN1mgMHUYXw
03IziJf2EruY6a9b8DuCzxIhZ3CLjjiiI7zPY3Lj11CA71rGP4NPjSF4Yz9P
QMUqmNl6bQTSaPX6GIDSF6JuDI/i+ExIBv/Ji4t4lv5i7pOAx999F705PRv+
9H208WaeSD11HNNsLs4I/xMsHW717zFAnaHS1eqYUVoHED8lo0P480+XVTUv
Dx89QpuqKjAioKCzdwAYPLq+eMRH8KM/81yg40vQL6Dnn6ZxmlX5If/+rXT5
s3o7fDxJq7zAEV7llzFGaTzPF+N4EqeFTxWBNOWGg5E0/DYvMFxsAJyhhscU
5Az1bQqHQDEBoTZKiqpmPwvMouDfv/37YpYCzQawV2uw3mB51ej7fPZLnCW/
gH4TvUjzRpA5th5cqNaTZAJtv62SLDnPsaR9ENuzeJpiUc24uFikWRPksqRm
gxE3+9+LtIizSf7tLH+fhuE+z6OfFk3gMmCKwfVilH97uYivk5QgEC9YpjXz
A2l6xNlKDWIdD9VJ+lYk3FTvNI5/Eq5jFDAvndmAKqSqRN4uN+VN+VE+vynS
i8sq2hhvRqiFRcTY74pFWWk7CFaqpFqfpoh8rBYkpsmXxvqcYKa8ISj4BBYf
nqNGbl6xvzXVnKVK64KrSXKgF30zSmdxQdrxFO0oDOjKFaPiP7D+Jcxdp9Hb
Usq/shjnYLEtuMw3q6blYoRl1xmAMjHg0E1mGDkG3UxhW1Sj2UB8m1xR7ejn
Zy9gj1Fb7o+BVIAYWhwzozMNxjrjnqZfr4xeJhdxFp2iTU2p+4UGWcyP73Nu
/iIfL6xKCBsiBSoEkyRGAiis+xgDoxexXsjUY5/UFCJFyflf8Pk6wucclRQx
xa+BOZLsnNjpfAELmBHuWOMZi96vk4pcJDyRyCjsSmz7TIwicpZWKT6jUZ0G
6y3iHJGqHXedzxP4z6NHHJyHgEv64ksApwq609MgoHipIwYFCVwGDNEqlaFV
Rl8+wt7SI6qHJfZNyF7j3N/pYt00gGuom/7xLLBHRYJwBXCpOYsONqEg+gvx
hET34a+qOV2VKEei/pJrUkfrDffa/23+7KeT/xgvCkCr2th8NBg8WrcdqdG6
5YH8H7kO/2/1v0v7YhvqyNbWYTyWv9B4U5Ni1qAgr7623s/jrEzkd3m5Vqc3
UHwI1BqVeYYJL5yYyiCNhZIMksxpmQx01kzViQvKu7OBdhPENW1FC+52diDv
wwNP/KY8Mbb9+L+FRJCwNU8M2LcJv8fS6xUUTP6gK2lwri9mOEbrnhbVAG9b
yTAKv8GKeuvp/CBLKYKnPxdlxrrHKtejUB9OsKQD5bT6WJTBIQLzN12kUTr5
/AwVCBRdnaG829P7Eg+2Z9rhHv+29l+GbeyJ/x78ElqRFfik9c3JvXGNGsVE
9bcJolaU/nUYq5kMvwub1ZbwLkwXDEW4P27T4MP8FQ6E+NdhrPr8fx+Oalym
FVgpkFnq3vhI0vqFmCiU0epfhoP8yf8u7NOwOst559Ejff9plWGzmcoNh29k
pBfKLyrQdOw6uf10NlSrrqZ+RVblMkf1gGx4pJG5wrcHORe0FV9rmRp727yL
AmLE83KRxRaeDYQ80p3s+18HwEAvmdgD8ZxDYA0P0z+tcDfrpygaoWfLfVZj
oBMkwxOf9F8hdHGXxhcX5BDV74Ghv0FR+hti0MWghQ+9uVwHdsanjn2MOurn
GMSRnW/AnjKz24ps4xLZvGfNgaD2NtediYZRBqTfzLIb9VCsVI8+LxOd5Ib+
9qeVencLPR5xsH4HWtmdaSeY5xgE3fxqyAeI9XNzkdRpujpBK3TGC4B0Lryo
7qvtAJPopJKbBHfGsbhJfSiycejZrtwzgBDB2r35bMuFQilm8YEptCuS6yIl
4QBQ+RY4+vHl8DWOQC/ukzJxe1szx30qsUwmPezRcf/02MR+Dtzu9nNknIUH
rryZqrS10dAqbutPAJ3oidvfftmsRMLpcf/o2LsENnhZKw+re5njfWI+76u/
fnW6Na0rrSxmqTKLayhqrSyHMjkjKtkxz+feWEp0JNN5dfO190szHoDJaT6X
mEPmUn/AT4HhF+XlvY0PsGAH5TMq+ITFrpGJdNyTehaNu2cHxX4NAP20i3hd
JcB7uAu81+pbeMSh+yie3dS7M723nDzI9GAaeXubX7aL/nKe1+5TI+YZSTV2
hM+D6WI+2jg9Ot3ErYfL2oGo9JY7wwC/e6LsOwFYuguMx7tH7kEEyAYCH0bo
mcYdNtcXfS0Tsf/mKdGqudMhqd2b5RWeEsDHmz0XIE3WCkI5vMpAZE2+7rqz
htF5iiGdaqLW0jHb4qw1pf0ZG7mi8mAgFIcFYouY05zH8aHEeJULBENWMseS
Ae7SMEw1XzEIkkb9HV94hz+TiHl53e5Q9pGa652JaYc66rsJJfCJwHLyIsod
prUbZAbkBL0m988PnIUgxBAyaLc12f08azL+jGuy2zQt+auu5knWxL7SpO5b
4fPg/6aqnz/2SkqglvFqHE2yFm3QG7BZuf45nd2/bo1Af1P6/jWd/XU1ouoc
INjVMulaaIqzelCwHxTslnXtrGCvrF/TS9DaTzB3jJ2L1nc+7nrgfFVvuTZe
14VJnzhfzMb28yy9wiGVds4q7B9blQ/om64u367KB7qvqMsHIKAafG8q++dm
FkvBt2iu9Xyl1WsdPkAvrdV7T5P87W/luq4B6Vtk2FHp2WiJiUQYnMZuz8kh
YJkxD9ShRK5KTU+JBOxEovp4LdOZ0jeXILPLyFD+a8N0Nos1kCWyUKbeTNKY
ssqpo0al6NYohqDYWJcabYPFFhoJc3JJJtlNx+k00baVrEJSkAyYyY+frrEU
mZlfg3NYtggP9uCDPXjP9uDnZIZmY3AlbvhXthb5v0ohy3bl3Wb7/cg76124
cxEjvdU9oQg01BYMLkrZobA8EGJkgqhonpe7P56+pnIKN2qCN9xMjWaAVAsY
NpMBzVyNCQGT4Ua1OTUaMC907L7MTg3DVflq+9szZmoj1kxEvPPJdsGqs3Ah
JqMvMUGJzWK0nJYJyE3sVW20hdxshExWIQPoYPmYU07SIQR0dxkNn55dFNRA
Xr7pt2D4j42Tt883wxcodeb61HxZ2E/PravgwJ2h4ff6HaR9ZUjTMKasYGOi
fgVFWjAHB+uWGpfPrHOfONO9pubUYF+3bQ17i3p3sJzZUHOWGYo3gWVBok3G
B420Lhejfo3gnyzcKb/oiF7r1a71b4c9o8sgvamMiSExB/VWRAkerc09nWf0
sMW2mdVNLi/RTKCiWm46Dq0xpvENJZF0cZjkU9jZgcmP6A1ZYNrAX+dJTHnl
1s02JS256MdUaySZmH6aj7uSi7QItGpmZmoGC5OMuZZJwqKXXaKFJ1LboOKz
cGZuCTqQ9ob5Q3O3ZIjTeL11du4tOIx3nl4sCp1H9WU6ex8NLy6K5IK/oydz
0cbL4fdWfiCDWFzxU6LEOnCZd22UXBkYWIhG4Q3j2u4sHWXRdg0+TaYjYIUM
psJB+UuPCJco9JaLYEQIg54G2OKQYFqDOOL9fXITrXth1y0i/ZUZxz3aiYiU
yjCgn/jEaxvCHYRAdlciJFqEihM1hIqk86v9TsEiCKSvNZyg0HcCjJxM5q7U
U3UwAJ76ecmOTlR5JQWL7QJOki0buFfWDz8rksZIGh42Q+y8qA6lcHm/LYlK
Uf4z9XbNxtLAsTQhVDYmN7CK6Xg5X/8kTmJTtQltYgWYVbgXfzk6ReWMcoDZ
nCOjTBPQtpXQVgZmOjsvYp3e02YnIYGqtsXiuJundyidcQ9e5tcOMQRzJd49
HyQSZbYgJnd3C+8i+qWfn/fVlGo8JR/tE9o5WMmt5iZXUpjAkjr1stiYCZjw
MimhruR5ZW8snkSU5qSrHU/UkDLu3hSNkNTJZA2CPjVap+ydI4KyP13NavVp
c0YiZD9/ZkrEChPN8zwL+OhI0uJvfSfUrgv2ZBXgzyNANLBIik8A+ZAPMzKz
CnmEooi2HXnSMJd44RabUCmZKGl/qLNO2lSa6mpSKaN5NHKC+aPR8/tkNrG+
KZIQCF0DgEsJTPmKKVZuUKpjVqZXJKVwoCBJhIT1xdQee1qqwEq2nGr8aV9L
kh3EJEY/0Ae5bHWeCt7TBSHUaIelNGzShablu4LVRB1IzdNtPMPszxTWMK7y
AlTJYpHcijZe5XdytQlyKR8PSLwVJmjR5Y7TWxF5LJpzW9zdf4eFp/lLHUU6
HnhyOZ53O8ZOjQVbJNoti2Kub85ds1s8I/102VG9pYqMWJ5lF4S6w2FPWF4E
tEqcizgzGl1gVv722hrjbxEbXIH1XyJ4X5IiQVoHg6gvnr90NB4S8+ZOwxGE
gfzNhSBVTDKm6ObcZCE2tFTEbii7/2rRzF32Fk+fJk46lhqjKv9+VJ9ko4bg
6ATMzi2L3oKkUlExtlnfELsoOnHJakR+4x9asxX0CvMu21PVLf6pJwuVxIu9
GqfTCYyhAFxZCrDrbQa0D/2cW3kVTMW9AAN2lXZLGNXTdlunvBWOcyRTRQRA
5jP+CjzbIhGJpPV1bRSH74RZuI8lttolVUBT1auJsrU797YwlID2GCoUcNCV
H7pxQ+sWCHNCGNduRkEtlgw3JxdyD+r/Tc6YtKxMJRwwDT1M9SMPtK9rHpMQ
xUiHFz3fU+PzAvg+mfSBTQBe0cmdYjBsRY3v0kkTcsnvFUgmvNNS7cR0ijlx
vCZuf+PUCJy7Zp734NMZzmxtVxIC15dlyT2YbwaGMFvCze1IOh4Nj5WdNz11
BMnv0uF1bveLCpjEQVdX1cE9u6oOOrmqcOBamW5xMdvkanJNHXxG19TBg2vK
uKYO/ulcU3WF4sEz9Tt7phwue/BNPfimfmPfVO3Qsj//+L6p1uk9+KZcLB98
U+4yWOP9Jr6poGR78E09+Ka6+qZapN1y39TBg29Kf/4pfFON3LDMNxXghI64
/ubOqYM/rnOqGbV7ck65fd3KRL+zc+rgMzinGth5qXOq5m35HZ1TK6XcAXWs
g19q77eLft3rGP3qBH42xVwZEYuOx2Xxj9imPexxhdgztbZeWFsjcgcdkDtY
ilxXb6NB7iCI3CeVeFtCvL98hP9+9Pz7U85NZCA6vDe6mPfp90a2O3IiRTWy
wAUA2+E5u1DdqqymHxvHDhi1NXEWMHtKZc6PfexGhtewTFPC+eed9yOTNL6Y
5SVKofmimOdo45C0LROwZfFrA0MNaQ+QWq5GDA52gqIDflmuTnNIhaZU+Zo+
UbzuOA75jOOyz+66JRQTLV124/Ases1uvo3h2evNLeBLylNz9jrCzP/pbFx5
vgacKP4s0cAmOHJ4BGheJRnOfZYkE3NyWpHaWEms4xTCLoMlE/M0DMRUv37X
0lobTcAkZmYqQ1oAaTnvzuNpmt14uAeze/m5vVwIMpfWXG7Es5jPWkRI6fiB
CFJqPJT4AIc9eXpCvckC+AWO0vH7nnJ/c/k29LHxXctswueaegRn+hp4dXIU
eZZ0JoK5cEC5gV07zd51ReNmplE3xI7Y0qu5RTy1FSXVeLAZwHa6yKr00noB
bh7ztvKUca3WnOGX+Kyb0gCg9p9U10mC6d4v0iv4X4enZkl6cTnKC1Ol8DjE
X2U/Bx0YzjqPrqMcJh3PluDJZzywOV59EMtraMBCyuKGrU22ZJHMs3is6jsa
RKmXr9SIN1VcVMOz/z0dvvuLCeSn1wmubBC58jo0TyRZP7+e1STA8uU4OUd7
d0sjxcsyjT+k08XUWp58zMkgx9riMPhZRijOV6vSphoJzsedrOk9SuBcSMix
jC4xLFISFnFAYvQsXmT5KCCvu6zpCRZY4aqKC35Gs6UFr5RI1OanEr8oKgyy
LInVMxpHlLdKcEt6kDueNDFoLGmjeEhC5oa+IlmiZqzvfgwQ3rjIKYv5hAS0
k4LjXY64UUZHVVjyMr5K88LSBXs1coIsw3o3o0Q7QChBZg+zhSmMrcgstBC7
Ec86vfLKZhp3cm1zct1XFk+UOAP1ArTPne+80eVBKYEr5cVlPLnCfCQqP2tM
wtFaVd5GRDU8VXtudgUFihy2NhzrXGCAgRmmVYJ3k3mRXqRGmWtPfeMei076
Gy/5DWrYPbzfdbJNmvPNyYvTYPU7OXHScz4CadW8s86cTbQ4Ur6QErkmaoat
S4V64hnW6wUJ9IYJYmQmyWSsvTRhG+ctsQM3M+gef6iY67Bk22IGh6tk0NDq
KnwLegzMyX5CZllRnMVGrSksUoG3syQCYq4mfJXGuKAxrPN4kcUFqnBOUr60
1Jl+55gPZlbpPLJZDoegIZhfJkgVCtrfO9g/xB3z6NXpyzM8O39MC5BpWGaJ
aK7rCkYbWEBz08uiwx8p3PSkznZk3Hx+3jv4DLx3sBLv0URXYkAaoisXKv+G
QdnmyiAzNnKjxT7208al7LiUmR4/2d45ZDyHSgs+E9sShXIdyxAzDYUELjOh
g6ww5c4SsZitnGmOj4/ZZomtLmbJFlU7dlR3lddGpS8C+nG6FtchbnBgsnnv
JhvskhXzDodtk07Zvmyry51dnZ3VjStf/3ioesdf44jH1J2qdaNyUj/ICrdg
HfCb49s8aqSnkwtBu2zQZAEVs6/KXP7atthHXFi6VO94WZFhRGOpkynqKimQ
8fjS3vZsrNQHszTkvd2lFHLXpK4e4z7hARJjwqTu+3/ffeJEa5yoBGhchg8m
jFAxzGmKSZw0aF1Vfpyg9HXgqz0vtpEHXxzWU1a0kw9j8iXw+sZ8EJh8aKnj
qu0BzfGqus/tejq5C28u15dflzJyaO0+oYrQz8lxH30PAK9BkT5V+cqj/WgD
yNPfDx9W5rh6Otgd7Ib3wTVIPyqWfAl75jLPajtiAnJtGmcH+87WPS94Yv0J
iOWqjB7bHmeVh2p7MNjZ3l4P7WOUiWW0DrJoLLWE+dMed4cFCzlLkGbbLVg/
NQcqOijFHeuOBMw5lF5c4AVIg0xw18wnRNP9Pd2lCwqdL9H4GNb9psDh8UXC
l6l8jJFQxnL34jby17jGmc1+f8IRBNI4Lib95ENVxH2sarDCpd8L7oyDQe+I
e2uH1qqoAK9hSE/34d+5kkAAgOQ4p5QtduK6qEqnNWKRxx6YZ9kr8mZ5Zry5
2pfSM1KyZ2igOdOPtA7IjFUEhcOrigB9nGuxTESr7cY5isrl2+0dANUUUyTm
IBlPIod2WZEgaiPQYy7r2IfONZpC2X6maRc7ZqJDBLiTd2i9T5J5nGFcXYAg
OwcOuxkhtbvzdP9xm5jqTjdK5UUrkjrH338eH58OX578eCwbveyBCEXn72zs
6IbGh3d6TK66mA9Ksp2900m0ju0eBxlaI8ZVYEg/VlE5PCa1YxWF0AIkZVmp
9IjOEY7z03jqUWwQekBg43yWwNmSFhNx6v0FzxiHwX7To3B/sB/eUHj2ESuu
wDvRx2hvMDh4/Hjvfvhnmc6kAPGaoEstyeK5m7FVFoZ1UNB55mTslAtyCOHW
MIwB/PUIpNgPpy+G78ILqN10dQZ856ylOMKSlDxCvyRFjnYqoAnExex1oF44
eKqp/MZr7ytB9ftsuVPs0/0Qfd18vfi9VRgL74jjUhmAdG5TZ+eS0cmM0vV2
8TV2su4S67Ct2ztB/+suE7PzzCyfnYT5hGZp7u+xUY10oQQzwbm+VGN40GsO
ppSDnWI3MYxDAWueX7es9crL/Nstb93H1PJgByhUV1lVmEk9yIR/PT80uY5U
oSUzYCgHmmS15qsVE1pLXpfSpJmiAxrTHWJ2V60CuZfg6kYg+TCneCJy/ijp
QT4gDVu6ExP6NTfbkt/Ye6H26Ah/xCr0yE5sMYS3zF13yx96nzRuEayKftIe
fAE43Tr4AmF7l9y/3/W2OXTlPgPd8Vvk3qOk6XSzVLvtdpQp/+q7ISqom6Zr
6wBIKV/VbXBK7m4/3T7EDooHEX+DIbXYf7xHLaIfASAuijkPif58jdTXmn9n
TWhnMNjbfXLwZN2ImPvSghBdxosIIbfH5IOZ5osZh556Ft95LgaL6a5STgMX
NZhU6YzL6f3O0393adle6qo3Vvd8FDw0zuKCjEdCV5lnMyfS3p6xeL6U3NUO
FFc3IxI6gd+VzsksYr3n8Qe+frpYTJspijr1BG/Zf2eSujEcPnFBZUYKqvuA
IkGqNNrd59mivPy951PfIYQWS4puO4RNCNTa2YYIcBoVjpCbEc//JJdvaOjX
qvtZGovcNHOVh0CohUUry214UCN+ODZHFBK5NlbFJCzxq48zt+pkWy3S5hNN
Lr6lKCftDKueJVeRdM54CzYbK85Jb8Vnt57ztTH4NlQ9HbGLTbAku23iyh9I
fwi9+vMxaNgedyk76ZNq5cqT6rHPclQd/5OFU/s97fLCOBxYRqPfsT6OZpe0
tENVXTo0hO4W1UUfMFkuRjpFx7r0Mhpjx0o4/HxAV7JpUIf502S/keZdJ0B9
NfNyfn6Py4ngPsN6vjk7/W7lBUVc7rKi/qCeOURTJcveNNH3gFkZO3O3fMye
B98cdvu7z/afHTyB/zbeBDSnl605vuR+kBL9nlWoDA4lLAj1D+/F2sbLs2G5
aVyXOPlIVzEmnzUGSM2r8DJw8FzM7rLaxGtXxC0zUdfEgVtiCnfhEYwNy85X
dy5kVCQuBAkzG9Zh9Ep19elCkVsFE0y1FY0WFaiNVmTo5O8AYDYmxq379Umr
tsotdUi67jw6KNPyHvcmgvsMe/PkrH9ytvLmRGTusjlro/oZUnCyod3JgYI1
Fm06cetnLkEmKCvv0iO+WO9R7/5Ob0v+3O2R2Sw/wL9dMR/y8yob9tnOU/L0
HhF20d+Gr7+PXsRVHL3KJzBRuwS2y5rmg5cm8rQHA7mad7ink2rqtUm27Wgw
iHYOnjx5srvz+BaSjYdU7j5V+01i21S4r6gv+PLM24DjOBtLITkuVV5dglDI
6u/jPocw+6kugrZcSaDjyFCUcQSsO4EpLKPfByNSSy5OR4aq2oR6W3okULEe
83j8HrR/P4HHTw3hOA6KihpoEFMQrndtkFZUmEo/c2QUVdE8xk3sazCd88XF
Zf123o5YX0lMAuXvUUqik+7+hSQYnCuLSBjqLhIy4DHED79YSm0/b4ioV0Vx
n1RFcJ+BrPhvCUqloEfvQfrbZLKYTUCFsa6+Nn58+/Z0c+XVwBncZTlw1E5X
d88eHzw99GbVMpGwUBdv5Z74Nc17oXXvQGwMRFz5ZGwKRuwo6W/nVfZUv8JL
VtEm4dFyxic1gUmvIuR18KCgTVwJa4PrH7/HxziX+SKbRDwWxmPDyC7e8qpt
EJ3hGwgdgui8AfLC/5ulY/3eTk7IpX6aB9eMNfI/hmvGXxnLIaeXxvsZ7y6X
CzPPAVivBByA6j+GD9FxdZU7qdVk6yZRpnibuoU3pvS/SoZ0UytUGoP7OwNV
qov7PwUVpoHDfimXNZ9XzUCtrChxOY4nQIwsnvV1+HA3J9fwtQk41jEz8nzR
y1tBCTDwmb4Zx+OYLvkC+EPbAeCAEf+h6l/mc+/3lohKkV8u7lInynkFwZ9Q
QRnhAlApgP2Lm0CP0flEuMT9VZ4o+pWy5BOMZFw2rdrliDVAvZaVpPeoqx10
CdKWCaZGD0mKhBAXZdPultU/uM3qH/yhVv/gYfVXW/1m6fxwC/GZbyHcMeph
XKWz1oH4mIYrCLWhtQvVRoZVlWSaY3A36/nOKK1XJnJXIpC9mxIVAm7D9nZQ
e/xX2/gqBIGh24FY5LUiHR72eq80gcmNfrCWoDULSz90resEloSx1dFpnfPt
gtt82XG7GDcfSrdQtwZ6B6LKLGphk7qOGrErcR3kCxZINtvL+vtRrT7gCtR9
J49ZGDGSwPKigLK0qA3k335EltxektbKDfezfwifQZ0CAhsaN4n7h6vJ3+Zq
0jJsLuMp1bN0RcsSdPu622oiGbtRRcqy85XG/uMnTw75BlLVdD9VyT8eHUl+
k2NMLXYa9Hebjzq1lr5fb+qvnrXb0fCDJ25jxPfg8cFjxvdqj9MCCL6MJiyY
g3fjcKfH/aPjTR14I9MzCLj3J5wNUpbFk090llZxcZFU9Ma+u6J7VCQqz5Re
Oyk1TQn6g8quKrauhwsfTuHs2q3a6TuCyTkPtLat8bJSHXKCr9S/AMIPRWYB
uxWcDmF0E2HwWKjILH8+1acWuPnSs7pFtn73VkvPp+Vyqz4ruu1a4YKLP+F9
R0ittPeamBg/2kW9ZAO2wfBzS7ibcLBX73ufWxE/Hbaj9TqGP8sS2D4EiDwE
iDhAVggQCR/zTQpYJ/XrIebkIebk88acOCmJ3M9DyMkdxGOrBncPYSf3EXiy
NPTkfoJP7if8pHMASnjb37MY/keJaXFp+F0ud/b0GJuEAazdYiov7DEm5Uoe
Url91f76I0fJ1FYTG9zzwv8Dxd14AS0PUTT/klE0xGF132nwuRKtmDZndh/f
4mw2WU0kyIbHDhvzHq4jOIYWfEcRWKFmx3kHYleXdcd/UvP1u/jw8+gr5tGm
eh63xk143ynnxC+tVUU3Q77umt99bKvWjaWt6zLaGew2AcDWO4O9Fl2qSPMC
9tvqTHkL49q7CNFjKy6wY8H+0eLRuihAbWeb/aDwzfCVmyzgXCK7lmaQ+O6F
8+pd3Rm5NaRWePOO9xs2DP887pLW/LsXOqWTXXvKeclZplg7ZprCKB/qL2AD
F/bqWes0HRe5/7a1MVkowOfMhOaVrspog3du05SQJJmESCv2MOutlPMt9Jcp
lJvLIjWl93yKL+mfpxPoTbsXsABt8DouSA1/IXVTog1AoT1R7MHg6SCQLBY5
UlOz+D2oqfMhWlQU4lnuUO0hOz2WjYbGSV5UfwAq8s0ypdVH9a6oUy/wvNg7
q1fYJLpeTmQNKXm8FXdWqjqhlfcbCeynT3rngNOLoyM6aXGQStLZ8fqJTc6s
rZC5UZn01Zt9Ja1nyUVepW7BWHsjWYxxYw0NkEOzNTBokD8AC2CGASdpV9vG
yUBF6bJxjj/MOTcrUl9G8JdPFyfAS/50inVZOFU+xlJNmEAmpEqgWIIKzKB8
gnHQyh5hx75KaWrHD0oAAt6Um/7ni5nngvltFmHnqbUKn/wjUMyz5qNQYrN1
uiyg8YV9PAqEsW03ySytmKlzE0ndYKNBk/aFxrHFq6NT5+tssLrvPSYMpunW
Yt/521Jn5ONcb5VXPlO8+jXZtVpVr/q65fF0+XrRNclcJUCF83U4wbOlrPiL
LVJiX8UoTmaxxYMboCdtRtNkfBlD66nrF7nf1XTrElpallwuKwXHrCBdKwMs
ri283JSXMIATnQDTjQMQRYnhuWr50nimRhfo+qqmGMihRTEOR4Y1Rlwtj7da
Hm31qdt8uodaGbXUc86tmEOsVtuzY3iVZyWsVDlPYo/MN4bdXT+bsxJcqxzQ
ckSG26Fb0IpVN1ltCA9MIKYQdkQftmoa5A7946H+qx5w1+LJt1Pd4dYjCEui
2WACWBIiXwRDB1e9SxCSWlD5ZqDtORJ+mgIN7uuE5Y85Z580UOXOZisMsUBz
3jkASvVl8ykg3axscOx+mVlPnAx/A6WKm7nD2w1S3bRcRbgPj6wh7vegDtSl
KeJz9Nhak1I33FbRQ/dWXuy7QfQGpdF1iqV/ODu0zrpbO8bZpqF7RN9nPhg8
kmn9h8Kro/tbuRjxUj67YWjWPMyLvLDUW574nPD1by5bd6AhIhbIojxk6n51
SdJwGmrvXobaG9D1TvIhxnKI6E+GLeDvS3W60EWpqp5QL9yn4Pl9Q9zpTmp5
wnHHHct8gRm3KWrWXUO+3liabNt0qr2ss9hM2rRy3N1xrvFdqyXubn8EbkFT
kzGgVGXt+vPBpisabt8FtKr0LPZa4ImiEs11YreV11Vgde3gEFi3uvBnPakl
rKyPzh5kreXndcOjXThyQFiHsq7B2bU04ZqbVLWq4vElRnNF47QYL0Ce+o85
rTtn78XqkqybS18Mhx+Jfh3cZ8aeWjIa2VTDV755pBnRUM7i7aDN1Mlqarui
bLKc6npsfYFB0cRFQQvw6DLNJoB36S/1ZQpHSDG+bNExXCzmBuhYATVaWGDB
uX3fdpV38OmpUQC2OPLSGRzYqfKtsXpjSHUqzUtd+XwrSgYXgy0MpUFkkg8V
3VUUifjNLJXx6Jj76ZLTymVXomI8POKIO663qK6JTd90htF1sYhP0TCIVlhw
gt2EZ8NTj2OB9rPq+tBsnr7aPCG/gPMeFqnu0JM9MhG5IVqVNbv2tl48InCR
0D38Yp7PuOAbk3N1nMuva2wIY8w4zpbFM5qNSGGPFW8tbdwi5VZ/1/nYIef3
UN60+CWjVWS6RRF/VbLder11d/Mbm4B1s348bletRRpJlJsRmRzwpRV+XaZU
mM9wJ6jLfKDjKgiCV1iezV1ZB/0+oK1PJX+iocLyrRPd6zzRZUXodbnypZXU
P+8p89lPF29YgBwe0rMPm7j6yJSDL+v2ojeYtGgakczZ7gOOgFev0wnWgA2M
yK6EauEbhQ2FckY3sDU7uAPVhnn17ocGpyywaHk1PtTI1Q/xn/Ny+SEOjZZj
89f8LOwzrw0o2kvHx7MIWDS1xgGUj9WC7uml5Gu1fvaydrRhgL6sHFaq5EKy
Fj7BV+reIL7KTbiSBBd3jYfp0iAn/PiX8PagGvDXXrdP3r/b3wrhHaFGEWZu
KjDZKxIy/+qjdXmFzjWD++pCxC530IxrwDAbEhh9p0w+843h0cvNMD/G42xF
fgRYnfnRgh7ix3PtpbszW+Kh/bKVL8OD1dlzqU0VLy5IL1l/NLs+VCpPaf0t
hnpAxRlOJlZximbzSeRq39ak6uvUZqtbWX85Ub3uDeQy3ncpcn5kKKDqKDgr
6rk7jfHYH587B6Va9tqqd6ysYauuQiZjhvlHilPxZbV8TrYz3D6J/fODFOFx
3eDsxAn0Zz5JhCPIzdMbDKwmXNX3URnPD+H/++rb3pKTl8eNPQWKJNENuxpR
HIA1Iiq5V4s8xJoMs6QS6CWrwkx5o8pPEuAsL41XPF51jV/qdb3H9RxyZzYj
JX6zFDOebroai9GCjtB3jxkaWWkPy023VrSciy6FDt6TfcCQBV13XhQuekDT
kJarIR2XtRc7ZeJ62batDOM3ykh/h2jXgr2UfVNhB9n61mnX3swSjDOeYm0E
sbB1UVldybF5+0q4uI4qtevtdLzFcUXBbUWAntVX0Ja2Ow8mW78mI/j//siS
gtbi1oIiHjv82sFbhH4fbQSLE8cEGN7R+fJp7dPan47evDiOjl+/OPvz2v+F
z9ra2hf6zg51qhK9zhyDsbZGl+ClvoHiRyrJxCqKWiXTOUaKqdmN+M0XOo1/
lcvGvcET3I3fnPRfDNKkOseFBUD94nz8dH/7ySgtP30a4Fhgk9DvPKl1fikH
LRcZFeBQUT0TfDrHr2WUS20N4zAvZuq5eqL0TIyRSmMCQu9SJli3Ob6g17rG
MN6i11wgr5BKr4/fHb15/R3g/s3b744Odvd3Pn0iH8Xb4zP7l6fb+9uAM4Zp
lYnlzriMrxIVU4NRBjHboIlVqoxvLDbYo3d29hcFcH/38e6nT1vRu5dnMsT+
/gF+o14E/vWHkyP1y7PtbRh8k/BSA9Jo0wVFmXs38BRUhqRVL8Qj97WIp0vz
i8SN18OjV5sw3L8jIntIBYSiriRU7cgEpsSKFgq6caWoLq5Vuv6OC01SDpDQ
dASEC2VtzYtElOwEgz9HSqeL8Y30FWwy8vo0wNHPbHIdOcQeXfSUzio9fSw8
Q8VnzItu4iNWBZi51GtFYHOb8WQ7IqBr2CSIzaMxJn2gv3A/0F/RBlfFUT5M
vNDaUhYVPwFaIxFAZWQ2B5HiHQsJdRs4VlsQaZHAn/T2Gmh6tchAb8aREBBg
Sm5c8Ucms6u0yGcktQD4T+hgtmmiOC6ZgGRgDOm1AZKKZuA05mPcxQ6FYL6g
jTNHZzjQnbc3gslrASd4fhFzYvHzi5gmkZyfQxe8rhOszZjkAleykBQZfhTH
NYox3h74osLCv4yywYsGsfhNaAb/D0eJEC3N6N+HxA69dtujd4iNDjkAyHIX
ylMabXSY5SF8kFGUaE5n59mCNCIsF0+WG1fWwtLBdGvv3g7HciCQHH9PxZD/
//aedjluG8n/egrs+IfsRHQsxVKcufKpFK+TeC9OuaLs1lalvFvUDDXiejRk
yBnJiqXXuhe4F7tufDa+SJDjZLMpsSqxhkQ3gEajP4BGo4KutWpShUZE8gvn
PR3HByKurHnorlkDrJYlnqjfE169/lXR/VoJLkYXSfXYZ1CcQGqmcJ0IlvDs
cqpuYAKT9CaTeHCigE+wzhcLHqv5Qcv+qm7z60W2LvJW2iQg7rn8x5HJZ4r6
JyubGLgKIXqqaKKYSDRupmkIZhB0IX+HgcpNiRE4ApER9Ti1y3OhUuEbaC1+
MRfKHD5UYrJIdEC0PbP4t+cvre6hsudXrAPVmzJfPtpDA5FH5pBxWap4WnnQ
VhpHRN9r9mDVlQr8RlN6hXckw3t+fRb0/1Ra0t+hJS3xnyxgcnDN9vD0u5NH
8qZ5PrMYHlnO5zDzZRilIewM4+0N64Eq53EpOffhV8W13puaUhxC4WA3UE/w
EzENNAXq3qxQDFRN+QvaCHyY9uhp6Vyu2SvzVoS5yZ2wefHzBigI9howRbmu
Gr6bgp1voLXmzI0ad2tlBreOV4tCnpk+rYzrC5J6zjmHcHJIznviFxFFJHCf
+BUH4NcXG25VlDyvbr7itFXRwNgsxclSOKO1sijWe/g/KaT3pL5bVWsuGLGr
j0LS4PFvJjzNFP2rP9qiafx6b14jH+h52c6WFY8vN4uecjBxzpmgl13iTu1K
kWBt6OzyHuxaGyeqOZbIwHobTEwAjKllW3mVg3vUFOJkA9nvVIpasiXfxMCe
IOPpkxY62y5jfxY94pFtKFLo1qmvxhUCPScVa9JgDBGcD1ZDy/cwxdy9KGtJ
BSFiMiViJB38WI1eYoiKUepXiyavodsovloj/7la5zOPi0Ip7vj2s+GUR0o9
IKwlRgj5ytW/UN+D4VudwxslOE0GGDFddnZOoV0NmK6EMx/uni1qzL6BWVvw
X0wbgP+CA7W7F+39I6Tdjdj9lebr/hdfgBF/7pso9abBBQqYOictH8Y9tXih
ZrWUDHLDXqVKkK7SzHKVOJNvWpnywvg+hzjWph1Q17Kt9nxlLs888X/FSZvi
fY2aei1InLdyPYELr5PTF69eMcFzIpMXOgDVuSgLBS7AtJiDPAC1I+FkaXbN
j1jl5/BzzhY8d1nDvVVMulnVNyR3La42GXMZiSxRVSCzUc59W13jyCm9qqrA
Iw7VWhlMxqpWqQz0miQldLEELVvMcuxIqXFIshgPmCt3QaB5wbWgGCQtRKX3
dPTlIfhIwFsfPsCIZfAfMEFr+dpOIJZ0HWU0kpj9PCpTHAJegBIQsRrgL786
+f7E85WB+fl7GTsBbpHA0xSLslXuspbJ7K8/vFJL05NVO0GJKUo2YgxKbs/w
z69e/vg1+/vr79gPssBEMvfnR8+e3d2BYOaePBQHpDD3Nw0mgV+fT/lySDt9
f7mcrtrpDWjIKXGwuSMlMKJy4qvqs/VUuIuvXp5+w3U/1Auvvv/s5L+kOlVd
4x1AlcKbhmuTbY3R7XJZYSA5qCpWZOHvXvN33DvHKmxCCTIcPTkAj1hSjYCa
+PQJUyCEWIgPuuZQ5HvVkWGEfMNTXk0ZM6/4YZWcm8vAvUiMY0AvqC7XZqYi
D9vf4ZFky7KMH7xHNnsp/IOWfXiATCzdhfYOvj1gf3vz3enOznfgimxaLYwE
U4tyMEHqcrZWEql4n62rupJ0YjDxyPkvEi5Uix2nhy9e7ouAq5cHIO1lPTlI
L5mjxJzcPCvAepXePF+HkuINg5HkirBWcGrGc2d8iUbQDdcsS558TNNFA8qF
7huJUlXFL1oG32qleEUsHzwWgyseluftlX1Q+3GGz2P9l37MK+D5x/IFPLfs
DZDh0+fPn3/KrEe8evPyAIoY3I93bqHX+58KpJ9Onh4+mdxyNPjwtH5M/ryF
j/sTVRKpfLuzC3/uYoF/gMbnH3Y1sH7wp/koS+7uWN+dHy/QcfC+4S8O9hUn
6nT/4POn8suuTZ1dDSKLHh598YxQeufDlD2Q/MXAuFsWzyc/wt/LanGjmHgC
YyYWefNluVg9n8wKPA8zuRMLf6AM1AaBWNqDmR30Gf2VTuBoardJRWFMqkqu
+3FuFpsSeq2VO1rFe5AM/Hih4q7WMBefONJDpT0GyunFyvAeSjuZyuVgXAgW
Sb7lGgN8+UmOmNk0EPtKUyiNLrEuak5zTCxTWGOXH2Ha5HUrM2k5H+EzLq0j
ct5mElYwr9b7P0/sIyMT8dLFgVjyRRbDNMuulvlq4p4+mczwNRj0AHN4+MT6
GgkgIF2WTOF29nK9gVf7gI9WN8FtrroAPsxmRaZ9dp8Y9NNPTnv9SIzJ2XW0
0/CpRgMejBSv59j3skGogydPnz2BZ+KUsMM13lJqeP2a8X7Vf6h+YdiR1wka
PxTiQfI90M1QRwHIAGC00T/fiJ//PAl0DvlfRcUESVMBfT0oN/LmbQqjW1t6
b/eUsOgRD7Nsn0oFsq2En78uG9yK0uKIFu2QQ+K7JXn0l7epMkgIULP1hO1B
tTLxu7zX2cGDjg6e8hP2v6MeojYM9FAM6o7YdvOVZT5TqhIVkcgiDUY1X1Q4
eZHnp0o16kXqgkc5g9GFNolUecqtn8sVuZBjJTKVOLZgPgMrNQO7vLnhbilr
y8sS14D4K0ujksMCvPIDXxVaG3dT5GCfgdUAcwamHCzkG+6UTl3mholrVoQM
UvkNROI+mYlvLZR8g3sydYRLjofKs/BHCubNegG4qe2Zf+coTlw9H4O9qn3U
5hetxWVPp3+OFeA3gReQYj/JGGDGHghKVmMSpFoEHMxYBa5RwFxh6hLZn4OO
kLEJpk0Ih1TchnBNiA4jwqcl+eirobAiYtuoXQHOdW9U9fLuu+/edtIzZl38
YTvMzQ6/d7bhEWR2y/YIkYBFqeCAS3nXb4xIUBUiI8Ckiz8VU6gDjFgyiYYM
fzyCMpemXiEqr6gKfBvRflr9KDUoHUUZuKXCFX4o2rpagcv28HXRtujGfVXN
bx6hctRLqb7GcxbyrcVvFXTJY3usqGd16uqs2qzmIS+QqsyYDuSRS6AEtdgJ
aUIVhhURnFf1srUVZF67/BbQLlJL4h8P9gNivEOXyhKORpUDH1AI1CSbnKhz
VkDSQLXENdY5MADqm5dPPjv6LNROk/+D0kcRtr64CcA01dIruVmVoebwBEiZ
OH0GRWGu82CNID2jupwNVOesR6v1DWeITu4oiJNw4UGQpxf1Sh+eGsaVPj0Q
T4eO3NPHB4PHblktcIcyAGcZLtF5gTYD//YbjFagbxEblz4xHZjHLFyrFG4G
OSK+LgJkVsU7lMIINbnjfUiT4NlBogzHDNJUFGNQpi/XHzwwx2B3dl6t/ADj
tVpctN0aZAExPBg5h4uzPISGVyOlvAqpbOX+pl4LN6G3D1+8PJAr34ePeL73
qpELiWrzXsf78PtkScJlfk5W7G+1NJxXBnSQg7jq1CoJ9cXLQUQqvaDHJmdw
eC1ysAOW7GQBNdzlQSDMvdtl1XDvdlH4wOKOxXvCtzqwWVCfrveZp0N0pknM
REF5N2ROBIRlUrcP/5O7fRjqdlxHaJEV0A86kQOKfFvAYf24XX+BiSoxghL3
5ksRBkcTKlRCtv+qpvjyc/ixrS3+9PDZFwn2273ldm+5/QaWmzXPAjPzq1Lc
BvOGzjQ0Y7hxxr7eLJfsRwzu+/Dg5EX2PViB+OvOmoUikmNqBVfsmLNEkaNE
PHiNfZplzXXPAVFe8FaV5cc/dRRdZm430OU02kDWJFP8E/ZTOX9LYHQN5Rx/
ivgnDydd1tkaWTwF5Pao/fPBW+N08hV1IWRRhOK12ZgBUNSbmsnFd3780X0I
llCbRIi2+nwbK0Ha6vRPtNWth5ZAqXYMv8hx/lAxfgW7f3353bFdWDeR3JHs
lWB+IZdktGw3BaPdc4CJtjoeDMxP42X88MFNpKDhNx4vLQt/QuqRV0v3wasD
CRYen8z6p/pbwQkArq36qsJwko/RVAtPR1PVk95UUY+8Ir11Bo4xkZA3bzMR
6NmJhDMbeKb+MwCJfV8PbU90/jgYcKXP78cQDDxv1kVV+1h4Sv/u9rcZOvMN
1OWAy/yf3dC49phV1ytvLPprrpuiLlbzbLGszuzBTKkZr3jLFNug+NPNT4Iu
10VWnWdVUy7KVR+DAifzk7xTXo8E6sRf1ldH2chKOGxyTU0xxzhQfuRHefTF
HKSnzZgxOXob5mP81M99RmyI1JSEA1IGAS+Qx8tw7dtVY3WYkqQakY6oDxSM
BG5srS+gi3ixAGKQ4eRHT/ugxTGHIstnRFWQFK998HigNMfRLQFCtb2z4YY8
HCaoL2nJd0VR53jW6lhi3j/qA0EqcOwxEFEMTyt4Wh5fRtW8Lw+7+EjCNEWe
KcOEPzwieV7h5SDZz5t8HgEUt4NSwRPpvWGhZZv3848UUOLiyT6uljOe35wb
uHL241NK5WjnD30TAeIZKizp3F9RmLIfh1T8dkv/HsePSqjIxNHfxYWg+hqh
Y93FAPMYQ24lHDMLqg8IZ9ocNSSF6gM6X27aC6d13bytVKEZuIAGlgKNXzIZ
uJrRHQE2YgQ0jLnPLKKYpYTJL4nrLyUf5mm1U7KaptGC9BIv1/gJtJCCRm7n
0kP6+UEIKnYN1XEnlHvtkjutnoWA1AU4IdNQV9Wz/qBSmdB1iHy2pTcqg9vs
diVk3rGxGM/YzlxDDRXXjeYpf1jIGZFdMItQsnXZfzukUXSRJcu50yq9fB1q
Bu11tA1y3ey4p5jd1GHtrEyqWQdxJZv5SXczq7RmVts185pmEzLOZIinlMsv
Yl3tpQtSIouuXmiXYlbMkdkiMkpyMF9/9UeYbOqRj7c2mOaAsAjUpFvm7ToT
p7gRRFg03I5cCcvLIzbZ9fPFdpVWPRtcfcdiSGiknHS6gdy5lhbRi5RmST1E
WrOdmEZeaDDuJdofjPKXe4mmJ1FkGkZtJBoYT926VZhsH14hTa6HVZ2J5PqP
jkOlBMLpw7qqH0W+G+6mHj7mNrjpxAgWRD9KKHScjJKn/UFfKIZXd1uXPO7C
a0i5T7QJH1npC+OglPMeWDLWFFb+LXmhG8fBFvUfjKhfiStxUywWWhR+NT43
90yKn8uVMyfYiDmhYdqkOcGGTSGWMoUYKRefQvrvyBQKUJxOIddA9jH6UyiA
smcK2ShjU0j/zYJTKNrUcVPIgx3Bwi6OIVPIgx1av+QMUEZyu9tlDU5s+Lze
gK5a6lKRKeYV7JjxyXpFg9RtsQEPsGyCaHUjrmZ66ni+tl/6PG+yYsUB+OV0
8eox+PbjV/xJQsXvl3nwsymxKi150dkCQ0+0KjEuOnkcbFBzXR92wrnBL8hG
4Iv681WxDjqqTies0OdVZrG/4Tg3AEKiiNi2wok8a8r5gqT4PO6AcAOcSBM9
CEUnYtDhVOAbJCIXocETMPCWMEV1vIXlu1tf3AWGALAkZXx78rLAPZlsWa7e
8ZSlkeUHUiy8lUgLK983ZPA61yoE7lAI0ePz8PBGRqqsr55aVMMXd75IMztf
glmDJqVm6aunUaYWvtJ5+T5bFqvF+sLiXucJ6B57VQg3gWYmWibWqG7T5aGD
JaDr+WSc38BglTN/OhJMql2ccwOIyNwWO3xBbLR1ohhu5sj69QiwqJVDalG5
b2L1aGbTKYAk+sK3i3yhpvpbV3zjH/9xXGgfUgPL0uZ1RDQEgcXGRpDJfJBE
7ozVhft9Ybb3IdSTVJXkGh1tM7+Y1d1MgyUyGmfXyz8eRAw/6UV4i8lrTEo7
NBHt0t105NgxdddNB1o6QlJhEPX6a4wTJ6VoVrD9quV6KmnaF00b7AntQxAq
DjSw7yM6LsYY00HPjFAIOg+WMCAbwCFREICwN+DoEzUWAmSLzlD9M7HfFHvn
LcIogf3lSx8JXcqMFFRP+jLnLdHgR64GP4qYOzENHqDPUXhrb0sNzgZocNqo
7oCwTg2uRyKowR1idmlw/Udcg9MiIzW4V0tIg9NCLEmDOxDeOMQ1uA/J0jV4
B3BMgwdBErkzVldEgwch1JNUVa8Gp1X0a3BaOk2DOxDqiQaJ2I1JaQfr1+A+
HcMaPEjvBC0WhFPPkHGKaHD6R5oGd/5I0+DOHwP7PqLjvRrcaUifBmcxiAEa
3MfRpcHpky4DKPYRGtxHEtHgoWfoRuWvEWFNnv5ga/L0qFknQB3a4YasO7vo
kV50b6hToDjdiTAYZDNR7KHYjX4qiPkUQTnL21k+L+YZ7kcIK8lVw9aAoR1q
igJF4Qf0+v06u6jqYOSk6nXnmo3fMMRLuqiN4HgEJAXFhfDYGmFo1ET7RRF3
qdYvb0d8xeMTNUBnlI4DoYFUpGi8nCJtRwQpRdgtWfqr6Qhsv7Wo2TEHmIWR
jZoMlLK1tWSbMBShoAGfzyPxDd1I++MNAsDDoh8Cje0IhrAnoCw9pq1sq7Ya
t2+g6FBPn7PomDVh0XHUHTw9THSwgaKDDRUdbLDoYImig6WKDopwuOiwq0k8
E9MnOpjFGeNEBxsqOli/6KCl+kSH0+Vh09ECHjkdTWN7RYdTekxb2ci2Su7/
iCfnAoWiJ+doGwafnKPA9goWBQ7LCgo7+NSdpcG6Tt05VBt86s6BTzx156n/
lKNsTlWDT91Fmtpz6s7j4/SmWuM+/NQdRTL61J1tyow5dUcxjDt1RzEMPXVn
tX/wqTsLeuCpO4v8g0/dUejhp+4s6J4DcTaDpp26o/iTTt1FKuk/dWdxz9hT
d87MHXbqzhUbyafuHO3TderOqWPIqTsHdOCpOwd68Kk7B37IqTuXPPHDQ7SG
lFN3DkjvqTt3ols3/ETXXqL80MMQzHTFuo0pXlxDPKy4CncXcJ2yTK5+5tWj
vnIOV2d5lczXPo68wjuU+BVKvQ0kP/W9S1P9Vxafh3YXL+eH6X2Ewr95AyM7
WH5pRrjCDWzrnkFBFJ567LTzfBTibq8sXy4wVvrispde5Ok/J7gqysXFWYXJ
PZriskKBI0Ry0HdXooUWtOqLxhI6KIZa0BrQmPmxZSj+gBcpLqMmvgP5+zM0
/+OVjMmMkWCgU7qPyYlxa9qXmhCDcEdiigkjh0akwvBa2J8HgzBvYgu3tMWZ
xUoj019sY4Vr8NGJL8bZ36bZY1JejLO8NeCoZBdjbW4D2p+BQvFfco6LAaZ2
CH1SdostjWxGTYGheS0cQyQxqUWSbU2xD0xnoeGG57LQoGMSWdyawRiUxaLX
mKa4E/NX6PIpZrRpw4BtqqgdbT/dW1Pb7Hh71knvrpN6xq0bJ7kZPbRJoUaf
g+E0KO5d0E5HXQtayGl5ml8RRNDpVDgQ6kk12L1uBd2JYLO6fYmP3a64F2FX
MNyFiMGn+g9BeM95YInGRef2QfKeyK2NbsAmw+22uyEDtkLG74NssQnyx8os
1F7kl/yskZ8DCPuU6e+B3vlIwMQBXYu3pqOF1b2RQwriy4RNFKdr/4aMSbeJ
imeM1klWOWn6xlE20F5zO3fHSgptRda3zDNCLkealbbGs9XqzlbrOuOEcp9E
ThPHI2XxdoI4VQqPFMFbyN/7fGX3gorZrbgXVA7wvaD6HQiq+2yB/65sgffS
7/ch/e4F2H+0APsY6TY7G2nVJDcHmXkCM1tDnOWzd3i5dGElpezcxjS1lc16
ky+T06lQWJX5qncPxUB46UTxCYoX1sXINp1jjKz/HsbIFthgdjFN62Bkp9yw
lrHBLZOLNSZJq6ZJwrq62r/iSVo/YT/Ni1acNfWPsym1JAvYbU7jqbbaNLMi
uKkunsDWugYefUCtb6Ge/DF0id6lYDDNrSBQr2joSncriBOwqDV0V9rbfuiu
9LcaOjbvu9Lg9ldtWy5/Cg2NawDg6yT9TsHBjipnm2UlpuK9VPpNpFJbzDao
RDzRZO5EsiSUeR1OrUTMV38EdSme9kl0Lbx36rZBSZKQbHwov8VyJegj7apc
nAUDF0H1iK7bQdKLjRVg5CB3tBeaILpozCK3n56JqvjEyumn31+uNxGp4qXy
loiuZnilPL/20Fwsb5/kWvHLtrOzaytjudGaCgrUobxG/q1dTtcmP4sP4Wzm
FivZCQG8QcCpO6vMwXMW4gQoAA2D/9Mz58zjBl1Y7q24SczDxUsl+bG4iVWI
lj9rB5UvBuIvBuKvB+KvE/DzkalARzXBcWEO7eKImEO1hJJFMs4iGWedjLOO
4DQzbcZnWh2badVmfT/V7qfa/VTbcqr9XNn7QPA7PJ/IrZBtZGKQIsDb9BpJ
mpOC2aNiw0VSUvgwIaOFefwxxGjx65iD0zOzw6DD0kFa7rMZLtvIW9Wt7KR2
sWWIkJEiQMjAPZcOPR3wMECYrA5ohKzek0TWxOtJPmvzWl1qLP6G/3YoNcQ1
IbTT6ovqGAv0Tvao86oLv9dpnSN3w+Ilsiezd6vqGrwH3uF258NUBE8X8+eT
83zZFnjX7I8XZcvm1WzDiXK2KZfzlqGT8uFPP3z94sv9Zwd3dwy0lnpx8OX+
3d1jhMsxsmRdsdfVuoT/NYti1YILvsKR5rdIN8VVWVxzYJzH2AYbMG/W5Yp9
9a//+9/m3RLUpoZELwvatK6aVmLZY9/AS/a6bC+anJeDX0XeLG8YLl3CpNAF
/1IVS/ZtvqytttiFdr4pN21Rg3r9uqxms2qZ65JV3VrosPk/bNqWfQue9LK4
0QXB1SMFrZ79T/PLTfvLujpnp7/kzbvqupz9ouFOL4oaJP7cA8QCr/OLor1g
fynW8A6qzlelBjz5swb5f8i00fOGBQMA
<!-- [rfced] Please review the "type" attribute of each sourcecode element
in the XML file to ensure correctness. If the current list of preferred
values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable type, then feel free to let us know.
Also, it is acceptable to leave the "type" attribute not set.
-->
<!-- [rfced] Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.
Hold Time vs. holdtime
Network Slice Service vs. Network Slice
-->
<!--[rfced] Abbreviations
a) Both the expansion and the acronym for the following terms are used
throughout the document. Would you like to update to using the expansion
upon first usage and the acronym for the rest of the document for consistency?
attachment circuit (AC)
Customer Edge (CE)
Layer 2 VPN (L2VPN)
Layer 3 VPN (L3VPN)
Provider Edge (PE)
Service Attachment Point (SAP)
b) FYI - We have added expansions for the following abbreviation
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Class of Service (CoS)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</rfc> </rfc>
 End of changes. 222 change blocks. 
2605 lines changed or deleted 782 lines changed or added

This html diff was produced by rfcdiff 1.48.