<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="utf-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.3.6) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-opsawg-ntw-attachment-circuit-16" number="9835" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.25.0 -->version="3" updates="" obsoletes="" xml:lang="en"> <front> <title abbrev="A YANG Network Model for ACs">A Network YANG Data Model for Attachment Circuits</title> <seriesInfoname="Internet-Draft" value="draft-ietf-opsawg-ntw-attachment-circuit-16"/>name="RFC" value="9835"/> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair" role="editor"> <organization>Orange</organization> <address> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="RichardRoberts">Roberts" initials="R." surname="Roberts"> <organization>Juniper</organization> <address> <email>rroberts@juniper.net</email> </address> </author> <author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"> <organization>Telefonica</organization> <address> <email>oscar.gonzalezdedios@telefonica.com</email> </address> </author> <author fullname="Samier Barguil Giraldo" initials="S." surname="Barguil Giraldo"> <organization>Nokia</organization> <address> <email>samier.barguil_giraldo@nokia.com</email> </address> </author> <author fullname="BoWu">Wu" initials="B" surname="Wu"> <organization>Huawei Technologies</organization> <address> <email>lana.wubo@huawei.com</email> </address> </author> <date year="2025"month="January" day="23"/> <area>Operations and Management</area> <workgroup>Operations and Management Area Working Group</workgroup>month="August"/> <area>OPS</area> <workgroup>opsawg</workgroup> <keyword>Slice Service</keyword> <keyword>L3VPN</keyword> <keyword>L2VPN</keyword> <keyword>Automation</keyword> <keyword>Network Automation</keyword> <keyword>Orchestration</keyword> <keyword>service delivery</keyword> <keyword>Service provisioning</keyword> <keyword>service segmentation</keyword> <keyword>service flexibility</keyword> <keyword>service simplification</keyword> <keyword>Network Service</keyword> <keyword>3GPP</keyword> <keyword>Network Slicing</keyword> <abstract><?line 95?><t>This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior to or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified inthe YANG"YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service(ACaaS) (I-D.ietf-opsawg-teas-attachment-circuit).</t>(ACaaS)" (RFC9834).</t> <t>The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs).</t> </abstract><note removeInRFC="true"> <name>Discussion Venues</name> <t>Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/opsawg/"/>.</t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/boucadair/attachment-circuit-model"/>.</t> </note></front> <middle> <?line 101?> <section anchor="introduction"> <name>Introduction</name> <t>Connectivity services are provided by networks to customers via dedicated terminating points, such as Service Functions <xref target="RFC7665"/>,customer edgesCustomer Edges (CEs), peer Autonomous System Border Routers (ASBRs), datacenterscenter gateways, or Internet Exchange Points.</t> <t>The procedure to provision a service in a service provider network may depend on the practices adopted by a service provider, including the flow put in place for the provisioning of advanced network services and how they are bound to an attachment circuit (AC). For example, the same attachment circuit may host multiple services (e.g., Layer 2Virtual Private Network (VPN), orVPN (L2VPN), Layer 3VPN,VPN (L3VPN), or Network Slice Service <xref target="RFC9543"/>). In order to avoid service interference and redundant information in various locations, a service provider may expose an interface to manage ACs network-wide. Customers can then request a standalone attachment circuit to be put inplace,place andthenrefer to that attachment circuit when requesting services to be bound to that AC. <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>target="RFC9834"/> specifies a data model for managingattachment circuitsAttachment Circuits as aservice.</t>Service (ACaaS).</t> <t><xref target="sec-module"/> specifies a network model for attachment circuits ("ietf-ac-ntw"). The model can be used for the provisioning of ACs in a provider network prior to or during service provisioning. For example, <xreftarget="I-D.ietf-opsawg-ac-lxsm-lxnm-glue"/>target="RFC9836"/> specifies augmentations to the L2VPN Network Model (L2NM) <xref target="RFC9291"/> and the L3VPN Network Model (L3NM) <xref target="RFC9182"/> to bind LxVPNs to ACs that are provisioned using the procedure defined in this document.</t><t>The<t>This document leverages <xref target="RFC9182"/> and <xref target="RFC9291"/> by adopting an AC provisioning structure that uses data nodes that are defined in those RFCs. Some refinements were introduced to cover not only conventional service providernetworks,networks but also specifics of other target deployments (e.g., cloud network).</t> <t>The AC network model is designed as augmentations of both the 'ietf-network' model <xref target="RFC8345"/> and the Service Attachment Point (SAP) model <xref target="RFC9408"/>. An attachment circuit can be bound to a single or multiple SAPs. Likewise, the model is designed to accommodate deployments where a SAP can be bound to one or multiple ACs (e.g., a parent AC and its child ACs).</t> <figure anchor="sap-ac-ntw"> <name>Attachment Circuits Examples</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="496" width="536" viewBox="0 0 536 496" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,240 L 8,256" fill="none" stroke="black"/> <path d="M 40,224 L 40,240" fill="none" stroke="black"/> <path d="M 80,176 L 80,224" fill="none" stroke="black"/> <path d="M 80,256 L 80,272" fill="none" stroke="black"/> <path d="M 80,304 L 80,400" fill="none" stroke="black"/> <path d="M 112,112 L 112,160" fill="none" stroke="black"/> <path d="M 144,48 L 144,64" fill="none" stroke="black"/> <path d="M 160,64 L 160,112" fill="none" stroke="black"/> <path d="M 176,32 L 176,48" fill="none" stroke="black"/> <path d="M 192,464 L 192,480" fill="none" stroke="black"/> <path d="M 208,112 L 208,160" fill="none" stroke="black"/> <path d="M 208,416 L 208,448" fill="none" stroke="black"/> <path d="M 224,448 L 224,464" fill="none" stroke="black"/> <path d="M 240,96 L 240,112" fill="none" stroke="black"/> <path d="M 240,176 L 240,272" fill="none" stroke="black"/> <path d="M 240,304 L 240,400" fill="none" stroke="black"/> <path d="M 272,80 L 272,96" fill="none" stroke="black"/> <path d="M 296,176 L 296,272" fill="none" stroke="black"/> <path d="M 296,304 L 296,400" fill="none" stroke="black"/> <path d="M 328,96 L 328,160" fill="none" stroke="black"/> <path d="M 328,416 L 328,464" fill="none" stroke="black"/> <path d="M 360,464 L 360,480" fill="none" stroke="black"/> <path d="M 376,416 L 376,448" fill="none" stroke="black"/> <path d="M 384,96 L 384,112" fill="none" stroke="black"/> <path d="M 392,448 L 392,464" fill="none" stroke="black"/> <path d="M 416,80 L 416,96" fill="none" stroke="black"/> <path d="M 424,416 L 424,464" fill="none" stroke="black"/> <path d="M 456,176 L 456,272" fill="none" stroke="black"/> <path d="M 456,304 L 456,320" fill="none" stroke="black"/> <path d="M 456,360 L 456,400" fill="none" stroke="black"/> <path d="M 496,336 L 496,352" fill="none" stroke="black"/> <path d="M 528,320 L 528,336" fill="none" stroke="black"/> <path d="M 160,32 L 176,32" fill="none" stroke="black"/> <path d="M 144,64 L 160,64" fill="none" stroke="black"/> <path d="M 256,80 L 272,80" fill="none" stroke="black"/> <path d="M 400,80 L 416,80" fill="none" stroke="black"/> <path d="M 272,96 L 384,96" fill="none" stroke="black"/> <path d="M 112,112 L 208,112" fill="none" stroke="black"/> <path d="M 240,112 L 256,112" fill="none" stroke="black"/> <path d="M 384,112 L 400,112" fill="none" stroke="black"/> <path d="M 80,176 L 96,176" fill="none" stroke="black"/> <path d="M 128,176 L 192,176" fill="none" stroke="black"/> <path d="M 224,176 L 240,176" fill="none" stroke="black"/> <path d="M 296,176 L 312,176" fill="none" stroke="black"/> <path d="M 344,176 L 456,176" fill="none" stroke="black"/> <path d="M 24,224 L 40,224" fill="none" stroke="black"/> <path d="M 40,240 L 64,240" fill="none" stroke="black"/> <path d="M 8,256 L 24,256" fill="none" stroke="black"/> <path d="M 80,272 L 240,272" fill="none" stroke="black"/> <path d="M 296,272 L 456,272" fill="none" stroke="black"/> <path d="M 80,304 L 240,304" fill="none" stroke="black"/> <path d="M 296,304 L 456,304" fill="none" stroke="black"/> <path d="M 512,320 L 528,320" fill="none" stroke="black"/> <path d="M 472,336 L 496,336" fill="none" stroke="black"/> <path d="M 496,352 L 512,352" fill="none" stroke="black"/> <path d="M 80,400 L 192,400" fill="none" stroke="black"/> <path d="M 224,400 L 240,400" fill="none" stroke="black"/> <path d="M 296,400 L 312,400" fill="none" stroke="black"/> <path d="M 344,400 L 360,400" fill="none" stroke="black"/> <path d="M 392,400 L 408,400" fill="none" stroke="black"/> <path d="M 440,400 L 456,400" fill="none" stroke="black"/> <path d="M 208,448 L 224,448" fill="none" stroke="black"/> <path d="M 376,448 L 392,448" fill="none" stroke="black"/> <path d="M 224,464 L 264,464" fill="none" stroke="black"/> <path d="M 288,464 L 328,464" fill="none" stroke="black"/> <path d="M 392,464 L 424,464" fill="none" stroke="black"/> <path d="M 192,480 L 208,480" fill="none" stroke="black"/> <path d="M 360,480 L 376,480" fill="none" stroke="black"/> <path d="M 160,32 C 151.16936,32 144,39.16936 144,48" fill="none" stroke="black"/> <path d="M 160,64 C 168.83064,64 176,56.83064 176,48" fill="none" stroke="black"/> <path d="M 256,80 C 247.16936,80 240,87.16936 240,96" fill="none" stroke="black"/> <path d="M 400,80 C 391.16936,80 384,87.16936 384,96" fill="none" stroke="black"/> <path d="M 256,112 C 264.83064,112 272,104.83064 272,96" fill="none" stroke="black"/> <path d="M 400,112 C 408.83064,112 416,104.83064 416,96" fill="none" stroke="black"/> <path d="M 112,160 C 103.16936,160 96,167.16936 96,176" fill="none" stroke="black"/> <path d="M 112,160 C 120.83064,160 128,167.16936 128,176" fill="none" stroke="black"/> <path d="M 208,160 C 199.16936,160 192,167.16936 192,176" fill="none" stroke="black"/> <path d="M 208,160 C 216.83064,160 224,167.16936 224,176" fill="none" stroke="black"/> <path d="M 328,160 C 319.16936,160 312,167.16936 312,176" fill="none" stroke="black"/> <path d="M 328,160 C 336.83064,160 344,167.16936 344,176" fill="none" stroke="black"/> <path d="M 112,192 C 103.16936,192 96,184.83064 96,176" fill="none" stroke="black"/> <path d="M 112,192 C 120.83064,192 128,184.83064 128,176" fill="none" stroke="black"/> <path d="M 208,192 C 199.16936,192 192,184.83064 192,176" fill="none" stroke="black"/> <path d="M 208,192 C 216.83064,192 224,184.83064 224,176" fill="none" stroke="black"/> <path d="M 328,192 C 319.16936,192 312,184.83064 312,176" fill="none" stroke="black"/> <path d="M 328,192 C 336.83064,192 344,184.83064 344,176" fill="none" stroke="black"/> <path d="M 24,224 C 15.16936,224 8,231.16936 8,240" fill="none" stroke="black"/> <path d="M 80,224 C 71.16936,224 64,231.16936 64,240" fill="none" stroke="black"/> <path d="M 80,224 C 88.83064,224 96,231.16936 96,240" fill="none" stroke="black"/> <path d="M 24,256 C 32.83064,256 40,248.83064 40,240" fill="none" stroke="black"/> <path d="M 80,256 C 71.16936,256 64,248.83064 64,240" fill="none" stroke="black"/> <path d="M 80,256 C 88.83064,256 96,248.83064 96,240" fill="none" stroke="black"/> <path d="M 456,320 C 447.16936,320 440,327.16936 440,336" fill="none" stroke="black"/> <path d="M 456,320 C 464.83064,320 472,327.16936 472,336" fill="none" stroke="black"/> <path d="M 512,320 C 503.16936,320 496,327.16936 496,336" fill="none" stroke="black"/> <path d="M 456,352 C 447.16936,352 440,344.83064 440,336" fill="none" stroke="black"/> <path d="M 456,352 C 464.83064,352 472,344.83064 472,336" fill="none" stroke="black"/> <path d="M 512,352 C 520.83064,352 528,344.83064 528,336" fill="none" stroke="black"/> <path d="M 208,384 C 199.16936,384 192,391.16936 192,400" fill="none" stroke="black"/> <path d="M 208,384 C 216.83064,384 224,391.16936 224,400" fill="none" stroke="black"/> <path d="M 328,384 C 319.16936,384 312,391.16936 312,400" fill="none" stroke="black"/> <path d="M 328,384 C 336.83064,384 344,391.16936 344,400" fill="none" stroke="black"/> <path d="M 376,384 C 367.16936,384 360,391.16936 360,400" fill="none" stroke="black"/> <path d="M 376,384 C 384.83064,384 392,391.16936 392,400" fill="none" stroke="black"/> <path d="M 424,384 C 415.16936,384 408,391.16936 408,400" fill="none" stroke="black"/> <path d="M 424,384 C 432.83064,384 440,391.16936 440,400" fill="none" stroke="black"/> <path d="M 208,416 C 199.16936,416 192,408.83064 192,400" fill="none" stroke="black"/> <path d="M 208,416 C 216.83064,416 224,408.83064 224,400" fill="none" stroke="black"/> <path d="M 328,416 C 319.16936,416 312,408.83064 312,400" fill="none" stroke="black"/> <path d="M 328,416 C 336.83064,416 344,408.83064 344,400" fill="none" stroke="black"/> <path d="M 376,416 C 367.16936,416 360,408.83064 360,400" fill="none" stroke="black"/> <path d="M 376,416 C 384.83064,416 392,408.83064 392,400" fill="none" stroke="black"/> <path d="M 424,416 C 415.16936,416 408,408.83064 408,400" fill="none" stroke="black"/> <path d="M 424,416 C 432.83064,416 440,408.83064 440,400" fill="none" stroke="black"/> <path d="M 208,448 C 199.16936,448 192,455.16936 192,464" fill="none" stroke="black"/> <path d="M 376,448 C 367.16936,448 360,455.16936 360,464" fill="none" stroke="black"/> <path d="M 208,480 C 216.83064,480 224,472.83064 224,464" fill="none" stroke="black"/> <path d="M 376,480 C 384.83064,480 392,472.83064 392,464" fill="none" stroke="black"/> <g class="text"> <text x="160" y="52">CE6</text> <text x="140" y="84">ac</text> <text x="256" y="100">CE5</text> <text x="400" y="100">CE2</text> <text x="340" y="132">ac</text> <text x="112" y="180">sap</text> <text x="208" y="180">sap</text> <text x="328" y="180">sap</text> <text x="160" y="212">PE1</text> <text x="376" y="212">PE2</text> <text x="24" y="244">CE1</text> <text x="80" y="244">sap</text> <text x="52" y="260">ac</text> <text x="484" y="324">ac</text> <text x="168" y="340">PE3</text> <text x="376" y="340">PE4</text> <text x="456" y="340">sap</text> <text x="512" y="340">CE5</text> <text x="208" y="404">sap</text> <text x="328" y="404">sap</text> <text x="376" y="404">sap</text> <text x="424" y="404">sap</text> <text x="220" y="436">ac</text> <text x="388" y="436">ac</text> <text x="436" y="436">ac</text> <text x="208" y="468">CE3</text> <text x="276" y="468">ac</text> <text x="376" y="468">CE4</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .--. |CE6| '-+' ac | .--. .--. | |CE5+------+------+CE2| .-----+-----. '--' | '--' | | |ac | | | .+. .+. .+. .-+sap+-------+sap+-. .-+sap+-------------. | '-' '-' | | '-' | | PE1 | | PE2 | .--. .+. | | | |CE1+--+sap| | | | '--' ac '+' | | | '-------------------' '-------------------' .-------------------. .-------------------. | | | .+. ac .--. | PE3 | | PE4 |sap+--+CE5| | | | '-' '--' | | | | | .-. | | .-. .-. .-. | '-------------+sap+-' '-+sap+-+sap+-+sap+-' '+' '+' '+' '+' |ac | |ac |ac .+-. | .+-. | |CE3+-----ac-----' |CE4+---' '--' '--' ]]></artwork> </artset> </figure> <t>The AC network model uses the AC common model defined in <xreftarget="I-D.ietf-opsawg-teas-common-ac"/>.</t>target="RFC9833"/>.</t> <t>The YANG 1.1 <xref target="RFC7950"/> data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t><t>Sample<t>Some examples are provided in <xref target="sec-examples"/>.</t><section anchor="editorial-note-to-be-removed-by-rfc-editor"> <name>Editorial Note (To be removed by RFC Editor)</name> <t>Note to the RFC Editor: This section is to be removed prior to publication.</t> <t>This document contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed.</t> <t>Please apply the following replacements:</t> <ul spacing="normal"> <li> <t>CCCC --> the assigned RFC number for <xref target="I-D.ietf-opsawg-teas-common-ac"/></t> </li> <li> <t>SSSS --> the assigned RFC number for <xref target="I-D.ietf-opsawg-teas-attachment-circuit"/></t> </li> <li> <t>XXXX --> the assigned RFC number for this I-D</t> </li> <li> <t>2025-01-07 --> the actual date of the publication of this document</t> </li> </ul> </section></section> <section anchor="conventions-and-definitions"> <name>Conventions and Definitions</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> <t>The reader should be familiar with the terms defined in <xref section="2" sectionFormat="of" target="RFC9408"/>.</t> <t>This document uses the term "network model" as defined in <xref section="2.1" sectionFormat="of" target="RFC8969"/>.</t> <t>The meanings of the symbols in the YANG tree diagrams are defined in <xref target="RFC8340"/>.</t> <t>LxSM refers to both the Layer 2 Service Model (L2SM) <xref target="RFC8466"/> and the Layer 3 Service Model (L3SM) <xref target="RFC8299"/>.</t> <t>LxNM refers to both the L2VPN Network Model (L2NM) <xref target="RFC9291"/> and the L3VPN Network Model (L3NM) <xref target="RFC9182"/>.</t> <t>LxVPN refers to both L2VPN and L3VPN.</t> <t>The following are used in the module prefixes:</t><dl><dl spacing="normal" newline="false"> <dt>ac:</dt> <dd> <t>Attachment circuit</t> </dd> <dt>ntw:</dt> <dd> <t>Network</t> </dd> <dt>sap:</dt> <dd> <t>ServiceAttchmentAttachment Point</t> </dd> <dt>svc:</dt> <dd> <t>Service</t> </dd> </dl> <t>In addition, this document uses the following terms:</t><dl><dl spacing="normal" newline="false"> <dt>Bearer:</dt> <dd> <t>A physical or logical link that connects a customer node (or site) to a provider network.</t></dd> <dt/> <dd><t>A bearer can be a wireless or wired link. One or multiple technologies can be used to build a bearer. The bearer type can be specified by a customer.</t></dd> <dt/> <dd><t>The operator allocates a unique bearer reference to identify a bearer within its network (e.g., customer line identifier). Such a reference can be retrieved by a customer and then used in subsequent service placement requests to unambiguously identify where a service is to be bound.</t></dd> <dt/> <dd><t>The concept of a bearer can be generalized to refer to the required underlying connection for the provisioning of an attachment circuit.</t></dd> <dt/> <dd><t>One or multiple attachment circuits may be hosted over the same bearer (e.g., multiple Virtual Local Area Networks (VLANs) on the same bearer that is provided by a physical link).</t> </dd> <dt>Network controller:</dt> <dd> <t>Denotes a functional entity responsible for the management of the service provider network. One or multiple network controllers can be deployed in a service provider network.</t> </dd> <dt>Service orchestrator:</dt> <dd> <t>Refers to a functional entity that interacts with the customer of a network service.</t></dd> <dt/> <dd><t>A service orchestrator is typically responsible for the attachment circuits, the Provider Edge (PE) selection, and requesting the activation of the requested services to a network controller.</t></dd> <dt/> <dd><t>A service orchestrator may interact with one or more network controllers.</t> </dd> <dt>Service provider network:</dt> <dd> <t>A network that is able to provide network services (e.g., LxVPN or Network Slice Services).</t> </dd> <dt>Service provider:</dt> <dd> <t>An entity that offers network services (e.g., LxVPN or Network Slice Services).</t> </dd> </dl> <t>The names of data nodes are prefixed using the prefix associated with the corresponding imported YANG module as shown in <xref target="pref"/>:</t> <table anchor="pref"> <name>Modules and Their Associated Prefixes</name> <thead> <tr> <th align="left">Prefix</th> <th align="left">Module</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">ac-common</td> <td align="left">ietf-ac-common</td> <tdalign="left">RFC CCCC</td>align="left"><xref target="RFC9833"/></td> </tr> <tr> <td align="left">ac-svc</td> <td align="left">ietf-ac-svc</td> <tdalign="left">Section 5.2 of RFC SSSS</td>align="left"><xref section="5.2" target="RFC9834"/></td> </tr> <tr> <td align="left">dot1q-types</td> <td align="left">ieee802-dot1q-types</td> <td align="left"> <xref target="IEEE802.1Qcp"/></td> </tr> <tr> <td align="left">if</td> <td align="left">ietf-interfaces</td> <td align="left"> <xref target="RFC8343"/></td> </tr> <tr> <td align="left">inet</td> <td align="left">ietf-inet-types</td> <td align="left"> <xref section="4" sectionFormat="of" target="RFC6991"/></td> </tr> <tr> <td align="left">key-chain</td> <td align="left">ietf-key-chain</td> <td align="left"> <xref target="RFC8177"/></td> </tr> <tr> <td align="left">nacm</td> <td align="left">ietf-netconf-acm</td> <td align="left"> <xref target="RFC8341"/></td> </tr> <tr> <td align="left">nw</td> <td align="left">ietf-network</td> <td align="left"> <xref target="RFC8345"/></td> </tr> <tr> <td align="left">rt-types</td> <td align="left">ietf-routing-types</td> <td align="left"> <xref target="RFC8294"/></td> </tr> <tr> <td align="left">rt-pol</td> <td align="left">ietf-routing-policy</td> <td align="left"> <xref target="RFC9067"/></td> </tr> <tr> <td align="left">sap</td> <td align="left">ietf-sap-ntw</td> <td align="left"> <xref target="RFC9408"/></td> </tr> <tr> <td align="left">vpn-common</td> <td align="left">ietf-vpn-common</td> <td align="left"> <xref target="RFC9181"/></td> </tr> </tbody> </table> </section> <section anchor="relationship-to-other-ac-data-models"> <name>Relationship to Other AC Data Models</name> <t><xref target="ac-overview"/> depicts the relationship between the various AC data models:</t> <ul spacing="normal"> <li> <t>"ietf-ac-common"(<xref target="I-D.ietf-opsawg-teas-common-ac"/>)</t><xref target="RFC9833"/></t> </li> <li> <t>"ietf-bearer-svc" (<xrefsection="5.1"section="6.1" sectionFormat="of"target="I-D.ietf-opsawg-teas-attachment-circuit"/>)</t>target="RFC9834"/>)</t> </li> <li> <t>"ietf-ac-svc" (<xrefsection="5.2"section="6.2" sectionFormat="of"target="I-D.ietf-opsawg-teas-attachment-circuit"/>)</t>target="RFC9834"/>)</t> </li> <li> <t>"ietf-ac-ntw" (<xref target="sec-module"/>)</t> </li> <li> <t>"ietf-ac-glue"(<xref target="I-D.ietf-opsawg-ac-lxsm-lxnm-glue"/>)</t><xref target="RFC9836"/></t> </li> </ul> <figure anchor="ac-overview"> <name>AC Data Models</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="288" width="368" viewBox="0 0 368 288" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 32,144 L 32,240" fill="none" stroke="black"/> <path d="M 56,80 L 56,112" fill="none" stroke="black"/> <path d="M 72,144 L 72,176" fill="none" stroke="black"/> <path d="M 144,48 L 144,80" fill="none" stroke="black"/> <path d="M 192,40 L 192,112" fill="none" stroke="black"/> <path d="M 240,48 L 240,80" fill="none" stroke="black"/> <path d="M 328,80 L 328,160" fill="none" stroke="black"/> <path d="M 328,192 L 328,240" fill="none" stroke="black"/> <path d="M 56,80 L 144,80" fill="none" stroke="black"/> <path d="M 240,80 L 328,80" fill="none" stroke="black"/> <path d="M 104,128 L 128,128" fill="none" stroke="black"/> <path d="M 72,176 L 264,176" fill="none" stroke="black"/> <path d="M 32,240 L 128,240" fill="none" stroke="black"/> <path d="M 248,240 L 328,240" fill="none" stroke="black"/> <path d="M 24,272 L 40,272" fill="none" stroke="black"/> <polygon class="arrowhead" points="336,192 324,186.4 324,197.6" fill="black" transform="rotate(270,328,192)"/> <polygon class="arrowhead" points="248,48 236,42.4 236,53.6" fill="black" transform="rotate(270,240,48)"/> <polygon class="arrowhead" points="200,40 188,34.4 188,45.6" fill="black" transform="rotate(270,192,40)"/> <polygon class="arrowhead" points="152,48 140,42.4 140,53.6" fill="black" transform="rotate(270,144,48)"/> <polygon class="arrowhead" points="112,128 100,122.4 100,133.6" fill="black" transform="rotate(180,104,128)"/> <polygon class="arrowhead" points="80,144 68,138.4 68,149.6" fill="black" transform="rotate(270,72,144)"/> <polygon class="arrowhead" points="48,272 36,266.4 36,277.6" fill="black" transform="rotate(0,40,272)"/> <polygon class="arrowhead" points="40,144 28,138.4 28,149.6" fill="black" transform="rotate(270,32,144)"/> <g class="text"> <text x="188" y="36">ietf-ac-common</text> <text x="48" y="132">ietf-ac-svc</text> <text x="200" y="132">ietf-bearer-svc</text> <text x="320" y="180">ietf-ac-ntw</text> <text x="188" y="244">ietf-ac-glue</text> <text x="8" y="276">X</text> <text x="60" y="276">Y:</text> <text x="80" y="276">X</text> <text x="120" y="276">imports</text> <text x="160" y="276">Y</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ ietf-ac-common ^ ^ ^ | | | .----------' | '----------. | | | | | | ietf-ac-svc <--- ietf-bearer-svc | ^ ^ | | | | | '------------------------ ietf-ac-ntw | ^ | | | | '------------ ietf-ac-glue ----------' X --> Y: X imports Y ]]></artwork> </artset> </figure> <t>The "ietf-ac-common" module is imported by the "ietf-bearer-svc", "ietf-ac-svc", and "ietf-ac-ntw" modules. Bearers managed using the "ietf-bearer-svc" module may be referenced by service ACs managed using the "ietf-ac-svc" module. Similarly, a bearer managed using the "ietf-bearer-svc" module may list the set of ACs that use that bearer. To facilitate correlation between an AC service request and the actual AC provisioned in the network, "ietf-ac-ntw" leverages the AC references exposed by the "ietf-ac-svc" module. Furthermore, to bind Layer 2 VPN or Layer 3 VPN services with ACs, the "ietf-ac-glue" module augments the LxSM and LxNM with AC service references exposed by the "ietf-ac-svc" module and AC network references exposed by the "ietf-ac-ntw" module.</t> </section> <section anchor="sample-uses-of-the-attachment-circuit-data-models"> <name>Sample Uses of the Attachment Circuit Data Models</name> <section anchor="acs-terminated-by-one-or-multiple-customer-edges-ces"> <name>ACs Terminated by One or Multiple Customer Edges (CEs)</name> <t><xref target="uc"/> depicts a sample target topology that involve ACs:</t> <ul spacing="normal"> <li> <t>ACs are terminated by a SAP at the network side. See <xref target="sap-ac-ntw"/> for an example of SAPs within a PE.</t> </li> <li> <t>A CE can be either a physical device or a logical entity. Such a logical entity is typically a software component (e.g., a virtualservice functionService Function that is hosted within the provider's network or a third-party infrastructure). A CE is seen by the network as a peer SAP <xref target="RFC9408"/>.</t> </li> <li> <t>CEs may be either dedicated to one single connectivity service or host multiple connectivity services (e.g., CEs with roles ofservice functionsService Functions <xref target="RFC7665"/>).</t> </li> <li> <t>A network provider may bind a single AC to one or multiple peer SAPs (e.g., CE1 and CE2 are tagged as peer SAPs for the same AC). For example, and as discussed in <xref target="RFC4364"/>, multiple CEs can be attached to a PE over the same attachment circuit. This scenario is typically implemented when the Layer 2 infrastructure between the CE and the network is a multipoint service.</t> </li> <li> <t>A single CE may terminate multiple ACs, which can be associated with the same bearer or distinct bearers (e.g., CE4).</t> </li> <li> <t>Customers may request protection schemes in which the ACs associated with their endpoints are terminated by the same PE (e.g., CE3), distinct PEs (e.g., CE4), etc. The network provider uses this request to decide where to terminate the AC in the service provider network and also whether to enable specific capabilities (e.g., Virtual Router Redundancy Protocol (VRRP)).</t> </li> </ul><t>The "ietf-ac-ntw"<t>"ietf-ac-ntw" is a network model that is used to manage the PE side of ACs at a provider network.</t> <figure anchor="uc"> <name>Examples of ACs</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="304" width="512" viewBox="0 0 512 304" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,80 L 8,112" fill="none" stroke="black"/> <path d="M 8,160 L 8,192" fill="none" stroke="black"/> <path d="M 72,64 L 72,96" fill="none" stroke="black"/> <path d="M 72,144 L 72,176" fill="none" stroke="black"/> <path d="M 112,80 L 112,176" fill="none" stroke="black"/> <path d="M 176,112 L 176,144" fill="none" stroke="black"/> <path d="M 192,32 L 192,104" fill="none" stroke="black"/> <path d="M 192,152 L 192,224" fill="none" stroke="black"/> <path d="M 200,112 L 200,144" fill="none" stroke="black"/> <path d="M 280,208 L 280,240" fill="none" stroke="black"/> <path d="M 288,248 L 288,272" fill="none" stroke="black"/> <path d="M 304,208 L 304,240" fill="none" stroke="black"/> <path d="M 352,64 L 352,112" fill="none" stroke="black"/> <path d="M 352,144 L 352,192" fill="none" stroke="black"/> <path d="M 360,32 L 360,56" fill="none" stroke="black"/> <path d="M 360,200 L 360,224" fill="none" stroke="black"/> <path d="M 376,64 L 376,112" fill="none" stroke="black"/> <path d="M 376,144 L 376,192" fill="none" stroke="black"/> <path d="M 448,80 L 448,112" fill="none" stroke="black"/> <path d="M 448,160 L 448,192" fill="none" stroke="black"/> <path d="M 480,192 L 480,272" fill="none" stroke="black"/> <path d="M 504,64 L 504,96" fill="none" stroke="black"/> <path d="M 504,144 L 504,176" fill="none" stroke="black"/> <path d="M 192,32 L 360,32" fill="none" stroke="black"/> <path d="M 24,64 L 72,64" fill="none" stroke="black"/> <path d="M 352,64 L 376,64" fill="none" stroke="black"/> <path d="M 464,64 L 504,64" fill="none" stroke="black"/> <path d="M 72,80 L 112,80" fill="none" stroke="black"/> <path d="M 376,80 L 400,80" fill="none" stroke="black"/> <path d="M 424,80 L 448,80" fill="none" stroke="black"/> <path d="M 376,96 L 400,96" fill="none" stroke="black"/> <path d="M 424,96 L 448,96" fill="none" stroke="black"/> <path d="M 8,112 L 56,112" fill="none" stroke="black"/> <path d="M 176,112 L 200,112" fill="none" stroke="black"/> <path d="M 352,112 L 376,112" fill="none" stroke="black"/> <path d="M 448,112 L 488,112" fill="none" stroke="black"/> <path d="M 112,128 L 136,128" fill="none" stroke="black"/> <path d="M 160,128 L 176,128" fill="none" stroke="black"/> <path d="M 24,144 L 72,144" fill="none" stroke="black"/> <path d="M 176,144 L 200,144" fill="none" stroke="black"/> <path d="M 352,144 L 376,144" fill="none" stroke="black"/> <path d="M 464,144 L 504,144" fill="none" stroke="black"/> <path d="M 376,160 L 400,160" fill="none" stroke="black"/> <path d="M 424,160 L 448,160" fill="none" stroke="black"/> <path d="M 72,176 L 112,176" fill="none" stroke="black"/> <path d="M 376,176 L 400,176" fill="none" stroke="black"/> <path d="M 424,176 L 448,176" fill="none" stroke="black"/> <path d="M 8,192 L 56,192" fill="none" stroke="black"/> <path d="M 352,192 L 376,192" fill="none" stroke="black"/> <path d="M 448,192 L 488,192" fill="none" stroke="black"/> <path d="M 280,208 L 304,208" fill="none" stroke="black"/> <path d="M 192,224 L 280,224" fill="none" stroke="black"/> <path d="M 304,224 L 360,224" fill="none" stroke="black"/> <path d="M 280,240 L 304,240" fill="none" stroke="black"/> <path d="M 288,272 L 376,272" fill="none" stroke="black"/> <path d="M 400,272 L 480,272" fill="none" stroke="black"/> <path d="M 24,64 C 15.16936,64 8,71.16936 8,80" fill="none" stroke="black"/> <path d="M 464,64 C 455.16936,64 448,71.16936 448,80" fill="none" stroke="black"/> <path d="M 56,112 C 64.83064,112 72,104.83064 72,96" fill="none" stroke="black"/> <path d="M 488,112 C 496.83064,112 504,104.83064 504,96" fill="none" stroke="black"/> <path d="M 24,144 C 15.16936,144 8,151.16936 8,160" fill="none" stroke="black"/> <path d="M 464,144 C 455.16936,144 448,151.16936 448,160" fill="none" stroke="black"/> <path d="M 56,192 C 64.83064,192 72,184.83064 72,176" fill="none" stroke="black"/> <path d="M 488,192 C 496.83064,192 504,184.83064 504,176" fill="none" stroke="black"/> <g class="text"> <text x="412" y="68">(b1)</text> <text x="412" y="84">AC</text> <text x="40" y="100">CE1</text> <text x="364" y="100">PE</text> <text x="412" y="100">AC</text> <text x="480" y="100">CE3</text> <text x="412" y="116">(b2)</text> <text x="148" y="132">AC</text> <text x="188" y="132">PE</text> <text x="272" y="132">Network</text> <text x="360" y="132">|</text> <text x="412" y="148">(b3)</text> <text x="412" y="164">AC</text> <text x="40" y="180">CE2</text> <text x="364" y="180">PE</text> <text x="412" y="180">AC</text> <text x="480" y="180">CE4</text> <text x="412" y="196">(b3)</text> <text x="292" y="228">PE</text> <text x="388" y="276">AC</text> <text x="20" y="292">(bx)</text> <text x="48" y="292">=</text> <text x="84" y="292">bearer</text> <text x="124" y="292">Id</text> <text x="144" y="292">x</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .--------------------. | | .------. | .--. (b1) .-----. | +----. | | +---AC---+ | | CE1 | | | |PE+---AC---+ CE3 | '------' | .--. '--' (b2) '-----' +---AC--+PE| Network | .------. | '--' .--. (b3) .-----. | | | | | +---AC---+ | | CE2 +----' | |PE+---AC---+ CE4 | '------' | '--' (b3) '---+-' | .--. | | '----------+PE+------' | '--' | | | '-----------AC----------' (bx) = bearer Id x ]]></artwork> </artset> </figure> </section> <section anchor="positioning-the-ac-network-model-in-the-overall-service-delivery-process"> <name>Positioning the AC Network Model in the Overall Service Delivery Process</name> <t><xref target="_u-ex"/> shows the positioning of the AC network model in the overall service delivery process. The "ietf-ac-ntw" module is a network modelwhichthat augments the SAP with a comprehensive set of parameters to reflect the attachment circuits that are in place in a network. The model also maintains the mapping with the service references that are used to expose those ACs tocustomercustomers using the'ietf-ac-svc'"ietf-ac-svc" module defined in <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>.target="RFC9834"/>. Whether the same naming conventions to reference an AC are used in the service and network layers is deployment-specific.</t> <figure anchor="_u-ex"> <name>An Example of the Network AC Model Usage</name> <!--[rfced] We note that Figure 4 uses "CE#1" and "CE#2", while other figures in the document use "CE1" and "CE2". May we update the CEs in Figure 4 to match the other figures in the document? If so, both artworks (svg and ascii-art) will be updated accordingly. --> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="688" width="512" viewBox="0 0 512 688" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,608 L 8,624" fill="none" stroke="black"/> <path d="M 48,592 L 48,608" fill="none" stroke="black"/> <path d="M 96,480 L 96,496" fill="none" stroke="black"/> <path d="M 104,368 L 104,384" fill="none" stroke="black"/> <path d="M 120,576 L 120,640" fill="none" stroke="black"/> <path d="M 136,400 L 136,464" fill="none" stroke="black"/> <path d="M 136,512 L 136,528" fill="none" stroke="black"/> <path d="M 176,320 L 176,352" fill="none" stroke="black"/> <path d="M 176,480 L 176,496" fill="none" stroke="black"/> <path d="M 208,144 L 208,160" fill="none" stroke="black"/> <path d="M 208,256 L 208,272" fill="none" stroke="black"/> <path d="M 208,400 L 208,568" fill="none" stroke="black"/> <path d="M 232,368 L 232,384" fill="none" stroke="black"/> <path d="M 272,64 L 272,128" fill="none" stroke="black"/> <path d="M 272,176 L 272,240" fill="none" stroke="black"/> <path d="M 272,288 L 272,320" fill="none" stroke="black"/> <path d="M 296,368 L 296,384" fill="none" stroke="black"/> <path d="M 336,144 L 336,160" fill="none" stroke="black"/> <path d="M 336,256 L 336,272" fill="none" stroke="black"/> <path d="M 368,320 L 368,352" fill="none" stroke="black"/> <path d="M 368,400 L 368,568" fill="none" stroke="black"/> <path d="M 384,576 L 384,640" fill="none" stroke="black"/> <path d="M 424,368 L 424,384" fill="none" stroke="black"/> <path d="M 456,608 L 456,624" fill="none" stroke="black"/> <path d="M 496,592 L 496,608" fill="none" stroke="black"/> <path d="M 224,32 L 320,32" fill="none" stroke="black"/> <path d="M 224,64 L 320,64" fill="none" stroke="black"/> <path d="M 224,128 L 320,128" fill="none" stroke="black"/> <path d="M 224,176 L 320,176" fill="none" stroke="black"/> <path d="M 224,240 L 320,240" fill="none" stroke="black"/> <path d="M 224,288 L 320,288" fill="none" stroke="black"/> <path d="M 176,320 L 368,320" fill="none" stroke="black"/> <path d="M 120,352 L 216,352" fill="none" stroke="black"/> <path d="M 312,352 L 408,352" fill="none" stroke="black"/> <path d="M 120,400 L 216,400" fill="none" stroke="black"/> <path d="M 312,400 L 408,400" fill="none" stroke="black"/> <path d="M 112,464 L 160,464" fill="none" stroke="black"/> <path d="M 112,512 L 160,512" fill="none" stroke="black"/> <path d="M 120,576 L 384,576" fill="none" stroke="black"/> <path d="M 24,592 L 48,592" fill="none" stroke="black"/> <path d="M 472,592 L 496,592" fill="none" stroke="black"/> <path d="M 48,608 L 120,608" fill="none" stroke="black"/> <path d="M 384,608 L 456,608" fill="none" stroke="black"/> <path d="M 8,624 L 32,624" fill="none" stroke="black"/> <path d="M 456,624 L 480,624" fill="none" stroke="black"/> <path d="M 120,640 L 384,640" fill="none" stroke="black"/> <path d="M 224,32 C 215.16936,32 208,39.16936 208,48" fill="none" stroke="black"/> <path d="M 320,32 C 328.83064,32 336,39.16936 336,48" fill="none" stroke="black"/> <path d="M 224,64 C 215.16936,64 208,56.83064 208,48" fill="none" stroke="black"/> <path d="M 320,64 C 328.83064,64 336,56.83064 336,48" fill="none" stroke="black"/> <path d="M 224,128 C 215.16936,128 208,135.16936 208,144" fill="none" stroke="black"/> <path d="M 320,128 C 328.83064,128 336,135.16936 336,144" fill="none" stroke="black"/> <path d="M 224,176 C 215.16936,176 208,168.83064 208,160" fill="none" stroke="black"/> <path d="M 320,176 C 328.83064,176 336,168.83064 336,160" fill="none" stroke="black"/> <path d="M 224,240 C 215.16936,240 208,247.16936 208,256" fill="none" stroke="black"/> <path d="M 320,240 C 328.83064,240 336,247.16936 336,256" fill="none" stroke="black"/> <path d="M 224,288 C 215.16936,288 208,280.83064 208,272" fill="none" stroke="black"/> <path d="M 320,288 C 328.83064,288 336,280.83064 336,272" fill="none" stroke="black"/> <path d="M 120,352 C 111.16936,352 104,359.16936 104,368" fill="none" stroke="black"/> <path d="M 216,352 C 224.83064,352 232,359.16936 232,368" fill="none" stroke="black"/> <path d="M 312,352 C 303.16936,352 296,359.16936 296,368" fill="none" stroke="black"/> <path d="M 408,352 C 416.83064,352 424,359.16936 424,368" fill="none" stroke="black"/> <path d="M 120,400 C 111.16936,400 104,392.83064 104,384" fill="none" stroke="black"/> <path d="M 216,400 C 224.83064,400 232,392.83064 232,384" fill="none" stroke="black"/> <path d="M 312,400 C 303.16936,400 296,392.83064 296,384" fill="none" stroke="black"/> <path d="M 408,400 C 416.83064,400 424,392.83064 424,384" fill="none" stroke="black"/> <path d="M 112,464 C 103.16936,464 96,471.16936 96,480" fill="none" stroke="black"/> <path d="M 160,464 C 168.83064,464 176,471.16936 176,480" fill="none" stroke="black"/> <path d="M 112,512 C 103.16936,512 96,504.83064 96,496" fill="none" stroke="black"/> <path d="M 160,512 C 168.83064,512 176,504.83064 176,496" fill="none" stroke="black"/> <path d="M 24,592 C 15.16936,592 8,599.16936 8,608" fill="none" stroke="black"/> <path d="M 472,592 C 463.16936,592 456,599.16936 456,608" fill="none" stroke="black"/> <path d="M 32,624 C 40.83064,624 48,616.83064 48,608" fill="none" stroke="black"/> <path d="M 480,624 C 488.83064,624 496,616.83064 496,608" fill="none" stroke="black"/> <g class="text"> <text x="268" y="52">Customer</text> <text x="108" y="84">Customer</text> <text x="176" y="84">Service</text> <text x="236" y="84">Models</text> <text x="72" y="100">ietf-l2vpn-svc,</text> <text x="200" y="100">ietf-l3vpn-svc,</text> <text x="392" y="100">ietf-network-slice-service,</text> <text x="100" y="116">ietf-ac-svc,</text> <text x="208" y="116">ietf-ac-glue,</text> <text x="296" y="116">and</text> <text x="376" y="116">ietf-bearer-svc</text> <text x="272" y="148">Service</text> <text x="272" y="164">Orchestration</text> <text x="112" y="196">Network</text> <text x="172" y="196">Models</text> <text x="72" y="212">ietf-l2vpn-ntw,</text> <text x="200" y="212">ietf-l3vpn-ntw,</text> <text x="336" y="212">ietf-sap-ntw,</text> <text x="448" y="212">ietf-ac-glue,</text> <text x="96" y="228">and</text> <text x="160" y="228">ietf-ac-ntw</text> <text x="264" y="260">Network</text> <text x="272" y="276">Orchestration</text> <text x="56" y="308">Network</text> <text x="144" y="308">Configuration</text> <text x="224" y="308">Model</text> <text x="164" y="372">Domain</text> <text x="364" y="372">Domain</text> <text x="168" y="388">Orchestration</text> <text x="360" y="388">Orchestration</text> <text x="36" y="420">Device</text> <text x="64" y="436">Configuration</text> <text x="36" y="452">Models</text> <text x="132" y="484">Config</text> <text x="136" y="500">Manager</text> <text x="156" y="548">NETCONF/CLI.</text> <text x="288" y="548">...................</text> <text x="376" y="548">.</text> <text x="136" y="564">|</text> <text x="84" y="596">Bearer</text> <text x="420" y="596">Bearer</text> <text x="28" y="612">CE#1</text> <text x="248" y="612">Network</text> <text x="476" y="612">CE#2</text> <text x="28" y="660">Site</text> <text x="56" y="660">A</text> <text x="476" y="660">Site</text> <text x="504" y="660">B</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .-------------. | Customer | '------+------' Customer Service Models | ietf-l2vpn-svc, ietf-l3vpn-svc, | ietf-network-slice-service, ietf-ac-svc, ietf-ac-glue, | and ietf-bearer-svc .------+------. | Service | | Orchestration | '------+------' Network Models | ietf-l2vpn-ntw, ietf-l3vpn-ntw, | ietf-sap-ntw, ietf-ac-glue, and ietf-ac-ntw | .------+------. | Network | | Orchestration | '------+------' Network Configuration Model | .-----------+-----------. | | .-------+-----. .-------+-----. | Domain | | Domain | | Orchestration | | Orchestration | '--+--------+-' '-------+-----' Device | | | Configuration | | | Models | | | .---+---. | | | Config | | | | Manager | | | '---+---' | | | | | NETCONF/CLI....................... | | | .--------------------------------. .---. Bearer | | Bearer .---. |CE#1+--------+ Network +--------+CE#2| '---' | | '---' '--------------------------------' Site A Site B ]]></artwork> </artset> </figure> <t>Similar to <xref target="RFC9408"/>, the "ietf-ac-ntw" module can be used for both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI). For example, all the ACs shown in <xref target="fig-inter-pn"/> have a 'role' set to 'ietf-sap-ntw:nni'. Typically, ASBRs of each network are directly connected to ASBRs of a neighboring network via one or multiple links (bearers). ASBRs of "Network#1" behave as a PE and treat the other adjacent ASBRs as if it were a CE.</t> <figure anchor="fig-inter-pn"> <name>An Example of the Network AC Model Usage Between Provider Networks</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="240" width="376" viewBox="0 0 376 240" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,32 L 8,224" fill="none" stroke="black"/> <path d="M 176,32 L 176,224" fill="none" stroke="black"/> <path d="M 256,32 L 256,112" fill="none" stroke="black"/> <path d="M 256,144 L 256,224" fill="none" stroke="black"/> <path d="M 368,32 L 368,112" fill="none" stroke="black"/> <path d="M 368,144 L 368,224" fill="none" stroke="black"/> <path d="M 8,32 L 176,32" fill="none" stroke="black"/> <path d="M 256,32 L 368,32" fill="none" stroke="black"/> <path d="M 176,48 L 200,48" fill="none" stroke="black"/> <path d="M 224,48 L 256,48" fill="none" stroke="black"/> <path d="M 176,80 L 200,80" fill="none" stroke="black"/> <path d="M 224,80 L 256,80" fill="none" stroke="black"/> <path d="M 256,112 L 368,112" fill="none" stroke="black"/> <path d="M 256,144 L 368,144" fill="none" stroke="black"/> <path d="M 176,192 L 200,192" fill="none" stroke="black"/> <path d="M 224,192 L 256,192" fill="none" stroke="black"/> <path d="M 8,224 L 176,224" fill="none" stroke="black"/> <path d="M 256,224 L 368,224" fill="none" stroke="black"/> <g class="text"> <text x="212" y="52">AC</text> <text x="212" y="84">AC</text> <text x="312" y="84">Network#2</text> <text x="88" y="116">Network#1</text> <text x="212" y="196">AC</text> <text x="312" y="196">Network#3</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .--------------------. .-------------. | +---AC----+ | | | | | | +---AC----+ Network#2 | | | | | | Network#1 | '-------------' | | | | .-------------. | | | | | | | | | +---AC----+ Network#3 | | | | | '--------------------' '-------------' ]]></artwork> </artset> </figure> </section> </section> <section anchor="description-of-the-attachment-circuit-yang-module"> <name>Description of the Attachment Circuit YANG Module</name> <t>The full tree diagram of the "ietf-ac-ntw" module is provided in <xref target="AC-Ntw-Tree"/>. Subtrees are provided in the following subsections for the reader's convenience.</t> <section anchor="overall-structure-of-the-module"> <name>Overall Structure of the Module</name> <t>The overall tree structure of the "ietf-ac-ntw" module is shown in <xref target="o-ntw-tree"/>.</t> <figure anchor="o-ntw-tree"> <name>Overall Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ augment /nw:networks/nw:network: +--rw specific-provisioning-profiles | ... +--rw ac-profile* [name] ... augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string +--rw svc-ref? ac-svc:attachment-circuit-reference +--rw profile* [ac-profile-ref] | +--rw ac-profile-ref leafref | +--rw network-ref? -> /nw:networks/network/network-id +--rw parent-ref | +--rw ac-ref? leafref | +--rw node-ref? leafref | +--rw network-ref? -> /nw:networks/network/network-id +--ro child-ref | +--ro ac-ref* leafref | +--ro node-ref? leafref | +--ro network-ref? -> /nw:networks/network/network-id +--rw peer-sap-id* string +--rw group* [group-id] | +--rw group-id string | +--rw precedence? identityref +--rw status | +--rw admin-status | | +--rw status? identityref | | +--ro last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref | +--ro last-change? yang:date-and-time +--rw description? string +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | ... +--rw oam | ... +--rw security | ... +--rw service ... augment /nw:networks/nw:network/nw:node/sap:service/sap:sap: +--rw ac* [ac-ref] +--rw ac-ref leafref +--rw node-ref? leafref +--rw network-ref? -> /nw:networks/network/network-id]]></artwork>]]></sourcecode> </figure> <t>A node can host one or more SAPs. Per <xref target="RFC9408"/>, a SAP is an abstraction of the network reference point (the PE side of an AC, in the context of this document) where network services can bedeliveredand/or are delivered to customers. Each SAP terminates one or multiple ACs.EachIn turn, each ACin turnmay be terminated by one or more peer SAPs ('peer-sap'). In order to expose such AC/SAP binding information, the SAP model <xref target="RFC9408"/> is augmented with the required AC-related information.</t> <t>Unlike the AC service model <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>,target="RFC9834"/>, an AC is uniquely identified by a name within the scope of a node, not a network. A textual description of the AC may be provided ('description').</t> <t>Also, in order to ease the correlation between the AC exposed at the service layer and the AC that is actually provisioned in the network operation, a reference to the AC exposed to the customer ('svc-ref') is stored in the "ietf-ac-ntw" module.</t> <t>ACs that are terminated by a SAP are listed in the 'ac' container under '/nw:networks/nw:network/nw:node/sap:service/sap:sap'. A controller may indicate a filter based on the service type (e.g., Network Slice or L3VPN) to retrieve the list of available SAPs, and thus ACs, for that service.</t> <t>In order to factorize common data that is provisioned for a group of ACs, a set of profiles (<xref target="sec-profiles"/>) can be defined at the networklevel,level and then called under the node level. The information contained in a profile is thus inherited, unless the corresponding data node is refined at the AC level. In such a case, the value provided at the AC level takes precedence over the global one.</t> <t>In contexts where the same AC is terminated by multiple peer SAPs (e.g., an AC with multiple CEs) but a subset of them have specific information, the module allows operators to:</t> <ul spacing="normal"> <li> <t>Define a parent AC that may list all these CEs as peer SAPs.</t> </li> <li> <t>Create individual ACs that are bound to the parent AC using 'parent-ref'.</t> </li> <li> <t>Indicate for each individual AC one or a subset of the CEs as peer SAPs. All these individual ACs will inherit the properties of the parent AC.</t> </li> </ul> <t>Whenever a parent AC is deleted, then all child ACs of that AC <bcp14>MUST</bcp14> be deleted. Child ACs are referenced using 'child-ref'.</t> <t>An AC may belong to one or multiple groups <xref target="RFC9181"/>. For example, the 'group-id' is used to associate redundancy or protection constraints with ACs.</t> <t>The status of an AC can be tracked using 'status'. Both operational status and administrative status are maintained. A mismatch between the administrative status vs. the operational status can be used as a trigger to detect anomalies.</t> <t>An AC can be characterized using Layer 2 connectivity (<xref target="sec-l2"/>), Layer 3 connectivity (<xref target="sec-l3"/>), routing protocols (<xref target="sec-rtg"/>), Operations, Administration, and Maintenance (OAM) (<xref target="sec-oam"/>), security (<xref target="sec-sec"/>), and service (<xref target="sec-svc"/>) considerations. Features are used to tag conditionalprotionsportions toaccomodateaccommodate various deployments (support oflayerLayer 2 ACs, Layer 3 ACs, IPv4, IPv6, routing protocols,BFD,Bidirectional Forwarding Detection (BFD), etc.).</t> </section> <section anchor="references"> <name>References</name> <t>The AC network module defines a set of groupings depicted in <xref target="references-tree"/> for referencing purposes. These references are used within or outside the AC network module. The use of such groupings is consistent with the design in <xref target="RFC8345"/>.</t> <figure anchor="references-tree"> <name>References Groupings</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ grouping attachment-circuit-reference: +-- ac-ref? leafref +-- node-ref? leafref +-- network-ref? -> /nw:networks/network/network-id grouping attachment-circuit-references: +-- ac-ref* leafref +-- node-ref? leafref +-- network-ref? -> /nw:networks/network/network-id grouping ac-profile-reference: +-- ac-profile-ref? leafref +-- network-ref? -> /nw:networks/network/network-id grouping encryption-profile-reference: +-- encryption-profile-ref? leafref +-- network-ref? -> /nw:networks/network/network-id grouping qos-profile-reference: +-- qos-profile-ref? leafref +-- network-ref? -> /nw:networks/network/network-id grouping failure-detection-profile-reference: +-- failure-detection-profile-ref? leafref +-- network-ref? -> /nw:networks/network/network-id grouping forwarding-profile-reference: +-- forwarding-profile-ref? leafref +-- network-ref? -> /nw:networks/network/network-id grouping routing-profile-reference: +-- routing-profile-ref? leafref +-- network-ref? -> /nw:networks/network/network-id]]></artwork>]]></sourcecode> </figure> <t>The groupings shown in <xref target="references-tree"/> contain the information necessary to reference:</t> <ul spacing="normal"> <li> <t>an attachment circuit that is terminated by a specific node in a given network,</t> </li> <li> <t>an attachment circuit profile of a specific network (<xref target="sec-profiles"/>), and</t> </li> <li> <t>specific provisioning profiles that are bound to a specific network (<xref target="sec-profiles"/>).</t> </li> </ul> </section> <section anchor="sec-profiles"> <name>Provisioning Profiles</name> <t>The AC and specific provisioning profiles tree structure is shown in <xref target="profiles-tree"/>.</t> <figure anchor="profiles-tree"> <name>Profiles Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ augment /nw:networks/nw:network: +--rw specific-provisioning-profiles | +--rw valid-provider-identifiers | +--rw encryption-profile-identifier* [id] | | +--rw id string | +--rw qos-profile-identifier* [id] | | +--rw id string | +--rw failure-detection-profile-identifier* [id] | | +--rw id string | +--rw forwarding-profile-identifier* [id] | | +--rw id string | +--rw routing-profile-identifier* [id] | +--rw id string +--rw ac-profile* [name] +--rw name string +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw bgp {vpn-common:rtg-bgp}? | | +--rw peer-groups | | +--rw peer-group* [name] | | +--rw name string | | +--rw description? string | | +--rw apply-policy | | | +--rw import-policy* leafref | | | +--rw default-import-policy? | | | | default-policy-type | | | +--rw export-policy* leafref | | | +--rw default-export-policy? | | | default-policy-type | | +--rw local-as? inet:as-number | | +--rw peer-as inet:as-number | | +--rw address-family? identityref | | +--rw role? identityref | | +--rw multihop? uint8 | | +--rw as-override? boolean | | +--rw allow-own-as? uint8 | | +--rw prepend-global-as? boolean | | +--rw send-default-route? boolean | | +--rw site-of-origin? | | | rt-types:route-origin | | +--rw ipv6-site-of-origin? | | | rt-types:ipv6-route-origin | | +--rw redistribute-connected* [address-family] | | | +--rw address-family identityref | | | +--rw enabled? boolean | | +--rw bgp-max-prefix | | | +--rw max-prefix? uint32 | | | +--rw warning-threshold? decimal64 | | | +--rw violate-action? enumeration | | | +--rw restart-timer? uint32 | | +--rw bgp-timers | | +--rw keepalive? uint16 | | +--rw hold-time? uint16 | +--rw ospf {vpn-common:rtg-ospf}? | | +--rw address-family? identityref | | +--rw area-id yang:dotted-quad | | +--rw metric? uint16 | | +--rw max-lsa? uint32 | | +--rw passive? boolean | +--rw isis {vpn-common:rtg-isis}? | | +--rw address-family? identityref | | +--rw area-address area-address | | +--rw level? identityref | | +--rw metric? uint32 | | +--rw passive? boolean | +--rw rip {vpn-common:rtg-rip}? | | +--rw address-family? identityref | | +--rw timers | | | +--rw update-interval? uint16 | | | +--rw invalid-interval? uint16 | | | +--rw holddown-interval? uint16 | | | +--rw flush-interval? uint16 | | +--rw default-metric? uint8 | +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw address-family? identityref | +--rw ping-reply? boolean +--rw oam +--rw bfd {vpn-common:bfd}? +--rw session-type? identityref +--rw desired-min-tx-interval? uint32 +--rw required-min-rx-interval? uint32 +--rw local-multiplier? uint8 +--rw holdtime? uint32]]></artwork>]]></sourcecode> </figure> <t>Similar to <xref target="RFC9182"/> and <xref target="RFC9291"/>, the exact definition of the specific provisioning profiles is local to each service provider. The model only includes an identifier for these profiles in order to ease identifying and binding local policies when building an AC. As shown in <xref target="profiles-tree"/>, the following identifiers can be included:</t> <dl> <dt>'encryption-profile-identifier':</dt> <dd> <t>An encryption profile refers to a set of policies related to the encryption schemes and setup that can be applied on the AC. See also <xref target="sec-sec"/>.</t> </dd> <dt>'qos-profile-identifier':</dt> <dd> <t>A Quality of Service (QoS) profile refers to a set of policies such as classification, marking, and actions (e.g., <xref target="RFC3644"/>). See also <xref target="sec-svc"/>.</t> </dd> <dt>'failure-detection-profile-identifier':</dt> <dd> <t>A failure detection profile refers to a set of failure detection policies such as Bidirectional Forwarding Detection (BFD) policies <xref target="RFC5880"/> that can be invoked when building an AC. Such a profile can be, for example, referenced in static routes (<xref target="sec-static-rtg"/>) or under the OAM level (<xref target="sec-oam"/>). The use of this profile is similar to the detailed examples depicted in AppendicesA.11.3<xref section="A.11.3" sectionFormat="bare" target="RFC9834"/> andA.12<xref section="A.12" sectionFormat="bare" target="RFC9834"/> of <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>.</t>target="RFC9834"/>.</t> </dd> <dt>'forwarding-profile-identifier':</dt> <dd> <t>A forwarding profile refers to the policies that apply to the forwarding of packets conveyed over an AC. Such policies may consist of, for example, applying Access Control Lists (ACLs) as in <xref target="sec-svc"/>.</t> </dd> <dt>'routing-profile-identifier':</dt> <dd> <t>A routing profile refers to a set of routing policies that will be invoked (e.g., BGP policies) for an AC. Refer to <xref target="sec-rtg"/>.</t> </dd> </dl> <t>The 'ac-profile' defines parameters that can be factorized among a set of ACs. Each profile is identified by a 'name' that is unique in a network. Some of the data nodes can be adjusted at the node level. These adjusted values take precedence over the values in the profile.</t> </section> <section anchor="sec-l2"> <name>L2 Connection</name> <t>The 'l2-connection' container is used to manage the Layer 2 properties of an AC (mainly, the PE side of an AC). The Layer 2 connection tree structure is shown in <xref target="l2-tree"/>.</t> <figure anchor="l2-tree"> <name>Layer 2 Connection Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string + ... +--rw l2-connection {ac-common:layer2-ac}? | +--rw encapsulation | | +--rw encap-type? identityref | | +--rw dot1q | | | +--rw tag-type? identityref | | | +--rw cvlan-id? uint16 | | | +--rw tag-operations | | | +--rw (op-choice)? | | | | +--:(pop) | | | | | +--rw pop? empty | | | | +--:(push) | | | | | +--rw push? empty | | | | +--:(translate) | | | | +--rw translate? empty | | | +--rw tag-1? dot1q-types:vlanid | | | +--rw tag-1-type? | | | | dot1q-types:dot1q-tag-type | | | +--rw tag-2? dot1q-types:vlanid | | | +--rw tag-2-type? | | | dot1q-types:dot1q-tag-type | | +--rw priority-tagged | | | +--rw tag-type? identityref | | +--rw qinq | | +--rw tag-type? identityref | | +--rw svlan-id? uint16 | | +--rw cvlan-id? uint16 | | +--rw tag-operations | | +--rw (op-choice)? | | | +--:(pop) | | | | +--rw pop? uint8 | | | +--:(push) | | | | +--rw push? empty | | | +--:(translate) | | | +--rw translate? uint8 | | +--rw tag-1? dot1q-types:vlanid | | +--rw tag-1-type? | | | dot1q-types:dot1q-tag-type | | +--rw tag-2? dot1q-types:vlanid | | +--rw tag-2-type? | | dot1q-types:dot1q-tag-type | +--rw (l2-service)? | | +--:(l2-tunnel-service) | | | +--rw l2-tunnel-service | | | +--rw type? identityref | | | +--rw pseudowire | | | | +--rw vcid? uint32 | | | | +--rw far-end? union | | | +--rw vpls | | | | +--rw vcid? uint32 | | | | +--rw far-end* union | | | +--rw vxlan | | | +--rw vni-id? uint32 | | | +--rw peer-mode? identityref | | | +--rw peer-ip-address* inet:ip-address | | +--:(l2vpn) | | +--rw l2vpn-id? vpn-common:vpn-id | +--rw l2-termination-point? string | +--rw local-bridge-reference? string | +--rw bearer-reference? string | | {ac-common:server-assigned-reference}? | +--rw lag-interface {vpn-common:lag-interface}? | +--rw lag-interface-id? string | +--rw member-link-list | +--rw member-link* [name] | +--rw name string +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | ... +--rw oam | ... +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>The 'encapsulation' container specifies the Layer 2 encapsulation to use (if any) and allows the configuration of the relevant tags. Also, the model supports tag manipulation operations (e.g., tag rewrite).</t> <t>The 'l2-tunnel-service' container is used to specify the required parameters to set a Layer 2 tunneling service (e.g., a Virtual Private LAN Service (VPLS), a Virtual eXtensible Local Area Network (VXLAN), or a pseudowire (<xref section="6.1" sectionFormat="of" target="RFC8077"/>)). 'l2vpn-id' is used to identify a L2VPN service that is associated with an Integrated Routing and Bridging (IRB) interface.</t> <t>Specific Layer 2 sub-interfaces may be required to be configured in some implementations/deployments. Such a Layer-2-specific interface can be included in 'l2-termination-point'.</t> <t>To accommodate implementations that require internal bridging, a local bridge reference can be specified in 'local-bridge-reference'. Such a reference may be a local bridge domain.</t> <t>A reference to the bearer used by this AC is maintained using 'bearer-reference'.</t> </section> <section anchor="sec-l3"> <name>IP Connection</name> <t>This 'ip-connection' container is used to group Layer 3 connectivity information, particularly the IP addressing information, of an AC.</t> <t>The Layer 3 connection tree structure is shown in <xref target="l3-tree"/>.</t> <figure anchor="l3-tree"> <name>IP Connection Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string + ... +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | +--rw l3-termination-point? string | +--rw ipv4 {vpn-common:ipv4}? | | +--rw local-address? | | | inet:ipv4-address | | +--rw prefix-length? uint8 | | +--rw address-allocation-type? | | | identityref | | +--rw (allocation-type)? | | +--:(dynamic) | | | +--rw (address-assign)? | | | | +--:(number) | | | | | +--rw number-of-dynamic-address? uint16 | | | | +--:(explicit) | | | | +--rw customer-addresses | | | | +--rw address-pool* [pool-id] | | | | +--rw pool-id string | | | | +--rw start-address | | | | | inet:ipv4-address | | | | +--rw end-address? | | | | inet:ipv4-address | | | +--rw (provider-dhcp)? | | | | +--:(dhcp-service-type) | | | | | +--rw dhcp-service-type? | | | | | enumeration | | | | +--:(service-type) | | | | +--rw (service-type)? | | | | +--:(relay) | | | | +--rw server-ip-address* | | | | inet:ipv4-address | | | +--rw (dhcp-relay)? | | | +--:(customer-dhcp-servers) | | | +--rw customer-dhcp-servers | | | +--rw server-ip-address* | | | inet:ipv4-address | | +--:(static-addresses) | | +--rw address* [address-id] | | +--rw address-id string | | +--rw customer-address? | | | inet:ipv4-address | | +--rw failure-detection-profile-ref? leafref | | +--rw network-ref? | | -> /nw:networks/network/network-id | +--rw ipv6 {vpn-common:ipv6}? | +--rw local-address? | | inet:ipv6-address | +--rw prefix-length? uint8 | +--rw address-allocation-type? | | identityref | +--rw (allocation-type)? | +--:(dynamic) | | +--rw (address-assign)? | | | +--:(number) | | | | +--rw number-of-dynamic-address? uint16 | | | +--:(explicit) | | | +--rw customer-addresses | | | +--rw address-pool* [pool-id] | | | +--rw pool-id string | | | +--rw start-address | | | | inet:ipv6-address | | | +--rw end-address? | | | inet:ipv6-address | | +--rw (provider-dhcp)? | | | +--:(dhcp-service-type) | | | | +--rw dhcp-service-type? | | | | enumeration | | | +--:(service-type) | | | +--rw (service-type)? | | | +--:(relay) | | | +--rw server-ip-address* | | | inet:ipv6-address | | +--rw (dhcp-relay)? | | +--:(customer-dhcp-servers) | | +--rw customer-dhcp-servers | | +--rw server-ip-address* | | inet:ipv6-address | +--:(static-addresses) | +--rw address* [address-id] | +--rw address-id string | +--rw customer-address? | | inet:ipv6-address | +--rw failure-detection-profile-ref? leafref | +--rw network-ref? | -> /nw:networks/network/network-id +--rw routing-protocols | ... +--rw oam | ... +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>A distinct Layer 3 interface other than the interface indicated under the 'l2-connection' container may be needed to terminate the Layer 3 connectivity. The identifier of such an interface is included in 'l3-termination-point'. For example, this data node can be used to carry the identifier of a bridge domain interface.</t> <t>This container can include IPv4, IPv6, or both if dual-stack is enabled. For both IPv4 and IPv6, the IP connection supports three IP address assignment modes for customer addresses: provider DHCP, DHCP relay, and static addressing. Note that for the IPv6 case, Stateless Address Autoconfiguration (SLAAC) <xref target="RFC4862"/> can be used.</t> <t>For both IPv4 and IPv6, 'address-allocation-type' is used to indicate the IP address allocation mode to activate for an AC. The allocated address represents the PE interface address configuration. When 'address-allocation-type' is set to 'provider-dhcp', DHCP assignments can be made locally or by an external DHCP server. Such behavior is controlled by setting 'dhcp-service-type'.</t> <t>For IPv6, if 'address-allocation-type' is set to 'slaac', the Prefix Information option of Router Advertisements that will be issued for SLAAC purposes will carry the IPv6 prefix that is determined by 'local-address' and 'prefix-length'. For example, if 'local-address' is set to '2001:db8:0:1::1' and 'prefix-length' is set to '64', the IPv6 prefix that will be used is '2001:db8:0:1::/64'.</t> <t>In some deployment contexts (e.g., network merging), multiple IP subnets may be used in a transition period. For such deployments, multiple ACs (typically, two) with overlapping information may be maintained during a transition period. The correlation between these ACs may rely upon the same 'svc-ref'.</t> </section> <section anchor="sec-rtg"> <name>Routing</name> <t>The overall routing subtree structure is shown in <xref target="rtg-tree"/>.</t> <figure anchor="rtg-tree"> <name>Routing Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-ac-ntw augment /nw:networks/nw:network: +--rw ac-profile* [name] +--rw name string +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw bgp {vpn-common:rtg-bgp}? | | ... | +--rw ospf {vpn-common:rtg-ospf}? | | ... | +--rw isis {vpn-common:rtg-isis}? | | ... | +--rw rip {vpn-common:rtg-rip}? | | ... | +--rw vrrp {vpn-common:rtg-vrrp}? | ... +--rw oam ... augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string ... +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profile* [routing-profile-ref] | | +--rw routing-profile-ref leafref | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw type? identityref | +--rw static | | ... | +--rw bgp {vpn-common:rtg-bgp}? | | ... | +--rw ospf {vpn-common:rtg-ospf}? | | ... | +--rw isis {vpn-common:rtg-isis}? | | ... | +--rw rip {vpn-common:rtg-rip}? | | ... | +--rw vrrp {vpn-common:rtg-vrrp}? | ... +--rw oam | ... +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>Multiple routing instances ('routing-protocol') can be defined, each uniquely identified by an 'id'. Specifically, each instance is uniquely identified to accommodate scenarios where multiple instances of the same routing protocol have to be configured on the same AC.</t> <t>The type of a routing instance is indicated in 'type'. The values of this attribute are those defined in <xref target="RFC9181"/> (the 'routing-protocol-type' identity). Specific data nodes are then provided as a function of the 'type'. See more details in the following subsections.</t> <t>One or multiple routing profiles ('routing-profile') can be provided for a given routing instance.</t> <section anchor="sec-static-rtg"> <name>Static Routing</name> <t>The static routing subtree structure is shown in <xref target="static-tree"/>.</t> <figure anchor="static-tree"> <name>Static Routing Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-ac-ntw ... augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string ... +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profile* [routing-profile-ref] | | +--rw routing-profile-ref leafref | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw type? identityref | +--rw static | | +--rw cascaded-lan-prefixes | | +--rw ipv4-lan-prefix* [lan next-hop] | | | {vpn-common:ipv4}? | | | +--rw lan inet:ipv4-prefix | | | +--rw lan-tag? string | | | +--rw next-hop union | | | +--rw metric? uint32 | | | +--rw bfd {vpn-common:bfd}? | | | | +--rw enabled? | | | | | boolean | | | | +--rw failure-detection-profile-ref? | | | | | leafref | | | | +--rw network-ref? | | | | -> /nw:networks/network/network-id | | | +--rw preference? uint32 | | | +--rw status | | | +--rw admin-status | | | | +--rw status? identityref | | | | +--ro last-change? yang:date-and-time | | | +--ro oper-status | | | +--ro status? identityref | | | +--ro last-change? yang:date-and-time | | +--rw ipv6-lan-prefix* [lan next-hop] | | {vpn-common:ipv6}? | | +--rw lan inet:ipv6-prefix | | +--rw lan-tag? string | | +--rw next-hop union | | +--rw metric? uint32 | | +--rw bfd {vpn-common:bfd}? | | | +--rw enabled? | | | | boolean | | | +--rw failure-detection-profile-ref? | | | | leafref | | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw preference? uint32 | | +--rw status | | +--rw admin-status | | | +--rw status? identityref | | | +--ro last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref | | +--ro last-change? yang:date-and-time | +--rw bgp {vpn-common:rtg-bgp}? | | ... | +--rw ospf {vpn-common:rtg-ospf}? | | ... | +--rw isis {vpn-common:rtg-isis}? | | ... | +--rw rip {vpn-common:rtg-rip}? | | ... | +--rw vrrp {vpn-common:rtg-vrrp}? | ... +--rw oam | ... +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>The following data nodes can be defined for a given IP prefix:</t><dl><dl spacing="normal" newline="false"> <dt>'lan-tag':</dt> <dd> <t>Indicates a local tag (e.g.,"myfavorite-lan")'myfavorite-lan') that is used to enforce local policies.</t> </dd> <dt>'next-hop':</dt> <dd> <t>Indicates the next hop to be used for the static route.</t></dd> <dt/> <dd><t>It can be identified by an IP address, a predefined next-hop type (e.g., 'discard' or 'local-link'), etc.</t> </dd> <dt>'bfd':</dt> <dd> <t>Indicates whether BFD is enabled or disabled for this static route entry. A BFD profile may also be provided.</t> </dd> <dt>'metric':</dt> <dd> <t>Indicates the metric associated with the static route entry. This metric is used when the route is exported into an IGP.</t> </dd> <dt>'preference':</dt> <dd> <t>Indicates the preference associated with the static route entry.</t></dd> <dt/> <dd><t>This preference is used to select a preferred route among routes to the same destination prefix.</t> </dd> <dt>'status':</dt> <dd> <t>Used to convey the status of a static route entry. This data node can also be used to control the (de)activation of individual static route entries.</t> </dd> </dl> </section> <section anchor="sec-bgp-rtg"> <name>BGP</name> <t>The BGP routing subtree structure is shown in <xref target="bgp-tree"/>.</t> <figure anchor="bgp-tree"> <name>BGP Routing Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-ac-ntw augment /nw:networks/nw:network: +--rw ac-profile* [name] +--rw name string +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw bgp {vpn-common:rtg-bgp}? | | +--rw peer-groups | | +--rw peer-group* [name] | | +--rw name string | | +--rw description? string | | +--rw apply-policy | | | +--rw import-policy* leafref | | | +--rw default-import-policy? | | | | default-policy-type | | | +--rw export-policy* leafref | | | +--rw default-export-policy? | | | default-policy-type | | +--rw local-as? inet:as-number | | +--rw peer-as inet:as-number | | +--rw address-family? identityref | | +--rw role? identityref | | +--rw multihop? uint8 | | +--rw as-override? boolean | | +--rw allow-own-as? uint8 | | +--rw prepend-global-as? boolean | | +--rw send-default-route? boolean | | +--rw site-of-origin? | | | rt-types:route-origin | | +--rw ipv6-site-of-origin? | | | rt-types:ipv6-route-origin | | +--rw redistribute-connected* [address-family] | | | +--rw address-family identityref | | | +--rw enabled? boolean | | +--rw bgp-max-prefix | | | +--rw max-prefix? uint32 | | | +--rw warning-threshold? decimal64 | | | +--rw violate-action? enumeration | | | +--rw restart-timer? uint32 | | +--rw bgp-timers | | +--rw keepalive? uint16 | | +--rw hold-time? uint16 | +--rw ospf {vpn-common:rtg-ospf}? | | ... | +--rw isis {vpn-common:rtg-isis}? | | ... | +--rw rip {vpn-common:rtg-rip}? | | ... | +--rw vrrp {vpn-common:rtg-vrrp}? | ... +--rw oam ... augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string ... +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profile* [routing-profile-ref] | | +--rw routing-profile-ref leafref | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw type? identityref | +--rw static | | ... | +--rw bgp {vpn-common:rtg-bgp}? | | +--rw peer-groups | | | +--rw peer-group* [name] | | | +--rw name string | | | +--rw local-address? union | | | +--rw description? string | | | +--rw apply-policy | | | | +--rw import-policy* leafref | | | | +--rw default-import-policy? | | | | | default-policy-type | | | | +--rw export-policy* leafref | | | | +--rw default-export-policy? | | | | default-policy-type | | | +--rw local-as? inet:as-number | | | +--rw peer-as inet:as-number | | | +--rw address-family? identityref | | | +--rw role? identityref | | | +--rw multihop? uint8 | | | +--rw as-override? boolean | | | +--rw allow-own-as? uint8 | | | +--rw prepend-global-as? boolean | | | +--rw send-default-route? boolean | | | +--rw site-of-origin? | | | | rt-types:route-origin | | | +--rw ipv6-site-of-origin? | | | | rt-types:ipv6-route-origin | | | +--rw redistribute-connected* [address-family] | | | | +--rw address-family identityref | | | | +--rw enabled? boolean | | | +--rw bgp-max-prefix | | | | +--rw max-prefix? uint32 | | | | +--rw warning-threshold? decimal64 | | | | +--rw violate-action? enumeration | | | | +--rw restart-timer? uint32 | | | +--rw bgp-timers | | | | +--rw keepalive? uint16 | | | | +--rw hold-time? uint16 | | | +--rw authentication | | | +--rw enabled? boolean | | | +--rw keying-material | | | +--rw (option)? | | | +--:(ao) | | | | +--rw enable-ao? boolean | | | | +--rw ao-keychain? | | | | key-chain:key-chain-ref | | | +--:(md5) | | | | +--rw md5-keychain? | | | | key-chain:key-chain-ref | | | +--:(explicit) | | | +--rw key-id? uint32 | | | +--rw key? string | | | +--rw crypto-algorithm? | | | identityref | | +--rw neighbor* [remote-address] | | +--rw remote-address inet:ip-address | | +--rw local-address? union | | +--rw peer-group? | | | -> ../../peer-groups/peer-group/name | | +--rw description? string | | +--rw apply-policy | | | +--rw import-policy* leafref | | | +--rw default-import-policy? | | | | default-policy-type | | | +--rw export-policy* leafref | | | +--rw default-export-policy? | | | default-policy-type | | +--rw local-as? inet:as-number | | +--rw peer-as inet:as-number | | +--rw address-family? identityref | | +--rw role? identityref | | +--rw multihop? uint8 | | +--rw as-override? boolean | | +--rw allow-own-as? uint8 | | +--rw prepend-global-as? boolean | | +--rw send-default-route? boolean | | +--rw site-of-origin? | | | rt-types:route-origin | | +--rw ipv6-site-of-origin? | | | rt-types:ipv6-route-origin | | +--rw redistribute-connected* [address-family] | | | +--rw address-family identityref | | | +--rw enabled? boolean | | +--rw bgp-max-prefix | | | +--rw max-prefix? uint32 | | | +--rw warning-threshold? decimal64 | | | +--rw violate-action? enumeration | | | +--rw restart-timer? uint32 | | +--rw bgp-timers | | | +--rw keepalive? uint16 | | | +--rw hold-time? uint16 | | +--rw bfd {vpn-common:bfd}? | | | +--rw enabled? boolean | | | +--rw failure-detection-profile-ref? leafref | | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw authentication | | | +--rw enabled? boolean | | | +--rw keying-material | | | +--rw (option)? | | | +--:(ao) | | | | +--rw enable-ao? boolean | | | | +--rw ao-keychain? | | | | key-chain:key-chain-ref | | | +--:(md5) | | | | +--rw md5-keychain? | | | | key-chain:key-chain-ref | | | +--:(explicit) | | | +--rw key-id? uint32 | | | +--rw key? string | | | +--rw crypto-algorithm? identityref | | +--rw status | | +--rw admin-status | | | +--rw status? identityref | | | +--ro last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref | | +--ro last-change? yang:date-and-time | +--rw ospf {vpn-common:rtg-ospf}? | | ... | +--rw isis {vpn-common:rtg-isis}? | | ... | +--rw rip {vpn-common:rtg-rip}? | | ... | +--rw vrrp {vpn-common:rtg-vrrp}? | ... +--rw oam | ... +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>The following data nodes are supported for each 'peer-group':</t> <dl> <dt>'name':</dt> <dd> <t>Defines a name for the peer group.</t> </dd> <dt>'local-address':</dt> <dd> <t>Specifies an address or a reference to an interface to use when establishing the BGP transport session.</t> </dd> <dt>'description':</dt> <dd> <t>Includes a description of the peer group.</t> </dd> <dt>'apply-policy':</dt> <dd> <t>Lists a set of import/export policies <xref target="RFC9067"/> to apply for this group.</t> </dd> <dt>'local-as':</dt> <dd> <t>Indicates a local AS Number (ASN).</t> </dd> <dt>'peer-as':</dt> <dd> <t>Indicates the peer's ASN.</t> </dd> <dt>'address-family':</dt> <dd> <t>Indicates the address family of the peer. It can be set to 'ipv4', 'ipv6', or 'dual-stack'.</t></dd> <dt/> <dd><t>This address family might be used together with the service type that uses an AC (e.g., 'vpn-type' <xref target="RFC9182"/>) to derive the appropriate Address Family Identifiers (AFIs) / Subsequent Address Family Identifiers (SAFIs) that will be part of the derived device configurations (e.g., unicast IPv4 MPLS L3VPN (AFI,SAFI = 1,128) as defined in <xref section="4.3.4" sectionFormat="of" target="RFC4364"/>).</t> </dd> <dt>'role':</dt> <dd> <t>Specifies the BGP role in a session. Role values are taken from the list defined in <xref section="4" sectionFormat="of" target="RFC9234"/>.</t> </dd> <dt>'multihop':</dt> <dd> <t>Indicates the number of allowed IP hops to reach a BGP peer.</t> </dd> <dt>'as-override':</dt> <dd> <t>If set, this parameter indicates whether ASN override is enabled, i.e., replacing the ASN of the customer specified in the AS_PATH BGP attribute with the ASN identified in the 'local- as' attribute.</t> </dd> <dt>'allow-own-as':</dt> <dd> <t>Used in some topologies (e.g., hub-and-spoke) to allow the provider's ASN to be included in the AS_PATH BGP attribute received from a peer. Loops are prevented by setting 'allow-own-as' to a maximum number of the provider's ASN occurrences. By default, this parameter is set to '0' (that is, reject any AS_PATH attribute that includes the provider's ASN).</t> </dd> <dt>'prepend-global-as':</dt> <dd> <t>When distinct ASNs are configured at the node and AC levels, this parameter controls whether the ASN provided at the node level is prepended to the AS_PATH attribute.</t> </dd> <dt>'send-default-route':</dt> <dd> <t>Controls whether default routes can be advertised to the peer.</t> </dd> <dt>'site-of-origin':</dt> <dd> <t>Meant to uniquely identify the set of routes learned from a site via a particular AC. It is used to prevent routing loops (<xref section="7" sectionFormat="of" target="RFC4364"/>). The Site of Origin attribute is encoded as a Route Origin Extended Community.</t> </dd> <dt>'ipv6-site-of-origin':</dt> <dd> <t>Carries an IPv6 Address Specific BGP Extended Community that is used to indicate the Site of Origin <xref target="RFC5701"/>. It is used to prevent routing loops.</t> </dd> <dt>'redistribute-connected':</dt> <dd> <t>Controls whether the AC is advertised to other PEs.</t> </dd></dl> <t>'bgp-max-prefix':<dt>'bgp-max-prefix':</dt> <dd> Controls the behavior when a prefix maximum isreached.</t> <dl>reached.</dd> <dt>'max-prefix':</dt> <dd> <t>Indicates the maximum number of BGP prefixes allowed in a session for this group. If the limit is reached, the action indicated in 'violate-action' will be followed.</t> </dd> <dt>'warning-threshold':</dt> <dd> <t>A warning notification is triggered when this limit is reached.</t> </dd> <dt>'violate-action':</dt> <dd> <t>Indicates which action to execute when the maximum number of BGP prefixes is reached. Examples of such actions include sending a warning message, discarding extra paths from the peer, or restarting the session.</t> </dd> <dt>'restart-timer':</dt> <dd> <t>Indicates, in seconds, the time interval after which the BGP session will be reestablished.</t> </dd> <dt>'bgp-timers':</dt> <dd> <t>Two timers can be captured in this container: (1) 'hold-time', which is the time interval that will be used for the Hold Timer (<xref section="4.2" sectionFormat="of" target="RFC4271"/>) when establishing a BGP session and (2) 'keepalive', which is the time interval for the KeepaliveTimer between a PE and a BGP peer (<xref section="4.4" sectionFormat="of" target="RFC4271"/>).</t></dd> <dt/> <dd><t>Both timers are expressed in seconds.</t> </dd> <dt>'bfd':</dt> <dd> <t>Indicates whether BFD is enabled or disabled for thisnighbor.neighbor. A BFD profile to apply may also be provided.</t> </dd> <dt>'authentication':</dt> <dd> <t>The module adheres to the recommendations in <xref section="13.2" sectionFormat="of" target="RFC4364"/>, as it allows enabling the TCP Authentication Option (TCP-AO) <xref target="RFC5925"/> and accommodates the installed base that makes use of MD5.</t></dd> <dt/> <dd><t>This version of the model assumes that parameters specific to the TCP-AO are preconfigured as part of the key chain that is referenced in the model. No assumption is made about how such a key chain is preconfigured. However, the structure of the key chain should cover data nodes beyond those in <xref target="RFC8177"/>, mainly SendID and RecvID (<xref section="3.1" sectionFormat="of" target="RFC5925"/>).</t> </dd> </dl> <t>For each neighbor, the following data nodes are supported in addition to similar parameters that are provided for a peer group:</t><dl><dl spacing="normal" newline="false"> <dt>'remote-address':</dt> <dd> <t>Specifies the remote IP address of a BGP neighbor.</t> </dd> <dt>'peer-group':</dt> <dd> <t>A name of a peer group.</t></dd> <dt/> <dd><t>Parameters that are provided at the 'neighbor' leveltakestake precedence over the ones provided in the peer group.</t> </dd> <dt>'status':</dt> <dd> <t>Indicates the status of the BGP session.</t> </dd> </dl> </section> <section anchor="sec-ospf-rtg"> <name>OSPF</name> <t>The OSPF routing subtree structure is shown in <xref target="ospf-tree"/>.</t> <figure anchor="ospf-tree"> <name>OSPF Routing Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-ac-ntw augment /nw:networks/nw:network: +--rw ac-profile* [name] +--rw name string +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw bgp {vpn-common:rtg-bgp}? | | ... | +--rw ospf {vpn-common:rtg-ospf}? | | +--rw address-family? identityref | | +--rw area-id yang:dotted-quad | | +--rw metric? uint16 | | +--rw max-lsa? uint32 | +--rw isis {vpn-common:rtg-isis}? | | ... | +--rw rip {vpn-common:rtg-rip}? | | ... | +--rw vrrp {vpn-common:rtg-vrrp}? | ... +--rw oam ... augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string ... +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profile* [routing-profile-ref] | | +--rw routing-profile-ref leafref | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw type? identityref | +--rw static | | ... | +--rw bgp {vpn-common:rtg-bgp}? | | ... | +--rw ospf {vpn-common:rtg-ospf}? | | +--rw address-family? identityref | | +--rw area-id yang:dotted-quad | | +--rw metric? uint16 | | +--rw sham-links {vpn-common:rtg-ospf-sham-link}? | | | +--rw sham-link* [target-site] | | | +--rw target-site string | | | +--rw metric? uint16 | | +--rw max-lsa? uint32 | | +--rw passive? boolean | | +--rw authentication | | | +--rw enabled? boolean | | | +--rw keying-material | | | +--rw (option)? | | | +--:(auth-key-chain) | | | | +--rw key-chain? | | | | key-chain:key-chain-ref | | | +--:(auth-key-explicit) | | | +--rw key-id? uint32 | | | +--rw key? string | | | +--rw crypto-algorithm? identityref | | +--rw status | | +--rw admin-status | | | +--rw status? identityref | | | +--ro last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref | | +--ro last-change? yang:date-and-time | +--rw isis {vpn-common:rtg-isis}? | | ... | +--rw rip {vpn-common:rtg-rip}? | | ... | +--rw vrrp {vpn-common:rtg-vrrp}? | ... +--rw oam | ... +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>The following OSPF data nodes are supported:</t><dl><dl spacing="normal" newline="false"> <dt>'address-family':</dt> <dd> <t>Indicates whether IPv4, IPv6, or both address families are to be activated.</t></dd> <dt/> <dd><t>When the IPv4 or dual-stack address family is requested, it is up to the implementation (e.g., network orchestrator) to decide whether OSPFv2 <xref target="RFC4577"/> or OSPFv3 <xref target="RFC6565"/> is used to announce IPv4 routes.</t> </dd> <dt>'area-id':</dt> <dd> <t>Indicates the OSPF Area ID.</t> </dd> <dt>'metric':</dt> <dd> <t>Associates a metric with OSPF routes.</t> </dd> <dt>'sham-links':</dt> <dd> <t>Used to create OSPF sham links between two ACs sharing the same area and having a backdoor link (<xref section="4.2.7" sectionFormat="of" target="RFC4577"/> and <xref section="5" sectionFormat="of" target="RFC6565"/>).</t> </dd> <dt>'max-lsa':</dt> <dd> <t>Sets the maximum number of Link State Advertisements (LSAs) that the OSPF instance will accept.</t> </dd> <dt>'passive':</dt> <dd> <t>Controls whether an OSPF interface is passive or active.</t> </dd> <dt>'authentication':</dt> <dd> <t>Controls the authentication schemes to be enabled for the OSPF instance. The module supports authentication options that are common to both OSPF versions: the Authentication Trailer for OSPFv2 <xref target="RFC5709"/> <xref target="RFC7474"/> and OSPFv3 <xref target="RFC7166"/>; as such, the model does not support <xref target="RFC4552"/>.</t> </dd> <dt>'status':</dt> <dd> <t>Indicates the status of the OSPF routing instance.</t> </dd> </dl> </section> <section anchor="sec-isis-rtg"> <name>IS-IS</name> <t>The IS-IS routing subtree structure is shown in <xref target="isis-tree"/>.</t> <figure anchor="isis-tree"> <name>IS-IS Routing Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-ac-ntw augment /nw:networks/nw:network: +--rw ac-profile* [name] +--rw name string +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw bgp {vpn-common:rtg-bgp}? | | ... | +--rw ospf {vpn-common:rtg-ospf}? | | ... | +--rw isis {vpn-common:rtg-isis}? | | +--rw address-family? identityref | | +--rw area-address area-address | | +--rw level? identityref | | +--rw metric? uint32 | | +--rw passive? boolean | +--rw rip {vpn-common:rtg-rip}? | | ... | +--rw vrrp {vpn-common:rtg-vrrp}? | ... +--rw oam ... augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string ... +--rw l2-connection | ... +--rw ip-connection | ... +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profile* [routing-profile-ref] | | +--rw routing-profile-ref leafref | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw type? identityref | +--rw static | | ... | +--rw bgp {vpn-common:rtg-bgp}? | | ... | +--rw ospf {vpn-common:rtg-ospf}? | | ... | +--rw isis {vpn-common:rtg-isis}? | | +--rw address-family? identityref | | +--rw area-address area-address | | +--rw level? identityref | | +--rw metric? uint32 | | +--rw passive? boolean | | +--rw authentication | | | +--rw enabled? boolean | | | +--rw keying-material | | | +--rw (option)? | | | +--:(auth-key-chain) | | | | +--rw key-chain? | | | | key-chain:key-chain-ref | | | +--:(auth-key-explicit) | | | +--rw key-id? uint32 | | | +--rw key? string | | | +--rw crypto-algorithm? identityref | | +--rw status | | +--rw admin-status | | | +--rw status? identityref | | | +--ro last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref | | +--ro last-change? yang:date-and-time | +--rw rip {vpn-common:rtg-rip}? | | ... | +--rw vrrp {vpn-common:rtg-vrrp}? | ... +--rw oam | ... +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>The following IS-IS data nodes are supported:</t><dl><dl spacing="normal" newline="false"> <dt>'address-family':</dt> <dd> <t>Indicates whether IPv4, IPv6, or both address families are to be activated.</t> </dd> <dt>'area-address':</dt> <dd> <t>Indicates the IS-IS area address.</t> </dd> <dt>'level':</dt> <dd> <t>Indicates the IS-IS level: Level 1, Level 2, or both.</t> </dd> <dt>'metric':</dt> <dd> <t>Associates a metric with IS-IS routes.</t> </dd> <dt>'passive':</dt> <dd> <t>Controls whether an IS-IS interface is passive or active.</t> </dd> <dt>'authentication':</dt> <dd> <t>Controls the authentication schemes to be enabled for the IS-IS instance. Both the specification of a key chain <xref target="RFC8177"/> and the direct specification of key and authentication algorithms are supported.</t> </dd> <dt>'status':</dt> <dd> <t>Indicates the status of the IS-IS routing instance.</t> </dd> </dl> </section> <section anchor="sec-rip-rtg"> <name>RIP</name> <t>The RIP routing subtree structure is shown in <xref target="rip-tree"/>.</t> <figure anchor="rip-tree"> <name>RIP Routing Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-ac-ntw augment /nw:networks/nw:network: +--rw ac-profile* [name] +--rw name string +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw bgp {vpn-common:rtg-bgp}? | | ... | +--rw ospf {vpn-common:rtg-ospf}? | | ... | +--rw isis {vpn-common:rtg-isis}? | | ... | +--rw rip {vpn-common:rtg-rip}? | | +--rw address-family? identityref | | +--rw timers | | | +--rw update-interval? uint16 | | | +--rw invalid-interval? uint16 | | | +--rw holddown-interval? uint16 | | | +--rw flush-interval? uint16 | | +--rw default-metric? uint8 | +--rw vrrp {vpn-common:rtg-vrrp}? | ... +--rw oam ... augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string ... +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profile* [routing-profile-ref] | | +--rw routing-profile-ref leafref | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw type? identityref | +--rw static | | ... | +--rw bgp {vpn-common:rtg-bgp}? | | ... | +--rw ospf {vpn-common:rtg-ospf}? | | ... | +--rw isis {vpn-common:rtg-isis}? | | ... | +--rw rip {vpn-common:rtg-rip}? | | +--rw address-family? identityref | | +--rw timers | | | +--rw update-interval? uint16 | | | +--rw invalid-interval? uint16 | | | +--rw holddown-interval? uint16 | | | +--rw flush-interval? uint16 | | +--rw default-metric? uint8 | | +--rw authentication | | | +--rw enabled? boolean | | | +--rw keying-material | | | +--rw (option)? | | | +--:(auth-key-chain) | | | | +--rw key-chain? | | | | key-chain:key-chain-ref | | | +--:(auth-key-explicit) | | | +--rw key? string | | | +--rw crypto-algorithm? identityref | | +--rw status | | +--rw admin-status | | | +--rw status? identityref | | | +--ro last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref | | +--ro last-change? yang:date-and-time | +--rw vrrp | ... +--rw oam | ... +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>The following RIP data nodes are supported:</t><dl><dl spacing="normal" newline="false"> <dt>'address-family':</dt> <dd> <t>Indicates whether IPv4, IPv6, or both address families are to be activated. This parameter is used to determine whether RIPv2 <xref target="RFC2453"/>, RIP Next Generation (RIPng) <xref target="RFC2080"/>, or both are to be enabled.</t> </dd> <dt>'timers':</dt> <dd> <t>Indicates the following timers (expressed inseconds): </t> <ul spacing="normal"> <li> <dl>seconds):</t> <dl spacing="normal" newline="false"> <dt>'update-interval':</dt> <dd> <t>The interval at which RIP updates are sent.</t> </dd></dl> </li> <li> <dl><dt>'invalid-interval':</dt> <dd> <t>The interval before a RIP route is declared invalid.</t> </dd></dl> </li> <li> <dl><dt>'holddown-interval':</dt> <dd> <t>The interval before better RIP routes are released.</t> </dd></dl> </li> <li> <dl><dt>'flush-interval':</dt> <dd> <t>The interval before a route is removed from the routing table.</t> </dd> </dl></li> </ul></dd> <dt>'default-metric':</dt> <dd> <t>Sets the default RIP metric.</t> </dd> <dt>'authentication':</dt> <dd> <t>Controls the authentication schemes to be enabled for the RIP instance.</t> </dd> <dt>'status':</dt> <dd> <t>Indicates the status of the RIP routing instance.</t> </dd> </dl> </section> <section anchor="sec-VRRP-rtg"> <name>VRRP</name> <t>The VRRP subtree structure is shown in <xref target="vrrp-tree"/>.</t> <figure anchor="vrrp-tree"> <name>VRRP Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-ac-ntw augment /nw:networks/nw:network: +--rw ac-profile* [name] +--rw name string +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw bgp {vpn-common:rtg-bgp}? | | ... | +--rw ospf {vpn-common:rtg-ospf}? | | ... | +--rw isis {vpn-common:rtg-isis}? | | ... | +--rw rip {vpn-common:rtg-rip}? | | ... | +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw address-family? identityref | +--rw ping-reply? boolean +--rw oam ... augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string ... +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profile* [routing-profile-ref] | | +--rw routing-profile-ref leafref | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw type? identityref | +--rw static | | ... | +--rw bgp {vpn-common:rtg-bgp}? | | ... | +--rw ospf {vpn-common:rtg-ospf}? | | ... | +--rw isis {vpn-common:rtg-isis}? | | ... | +--rw rip {vpn-common:rtg-rip}? | | ... | +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw address-family? identityref | +--rw vrrp-group? uint8 | +--rw backup-peer? inet:ip-address | +--rw virtual-ip-address* inet:ip-address | +--rw priority? uint8 | +--rw ping-reply? boolean | +--rw status | +--rw admin-status | | +--rw status? identityref | | +--ro last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref | +--ro last-change? yang:date-and-time +--rw oam | ... +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>The following VRRP data nodes are supported:</t><dl><dl newline="false" spacing="normal"> <dt>'address-family':</dt> <dd> <t>Indicates whether IPv4, IPv6, or both address families are to be activated. Note that VRRP version 3 <xref target="RFC9568"/> supports both IPv4 and IPv6.</t> </dd> <dt>'vrrp-group':</dt> <dd> <t>Used to identify the VRRP group.</t> </dd> <dt>'backup-peer':</dt> <dd> <t>Carries the IP address of the peer.</t> </dd> <dt>'virtual-ip-address':</dt> <dd> <t>Includes virtual IP addresses for a single VRRP group.</t> </dd> <dt>'priority':</dt> <dd> <t>Assigns the VRRP election priority for the backup virtual router.</t> </dd> <dt>'ping-reply':</dt> <dd> <t>Controls whether the VRRP speaker should reply to ping requests.</t> </dd> <dt>'status':</dt> <dd> <t>Indicates the status of the VRRP instance.</t> </dd> </dl> <t>Note that no authentication data node is included for VRRP, as there isn't any type of VRRP authentication at this time (see <xref section="9" sectionFormat="of" target="RFC9568"/>).</t> </section> </section> <section anchor="sec-oam"> <name>OAM</name> <t>The OAM subtree structure is shown in <xref target="oam-tree"/>.</t> <figure anchor="oam-tree"> <name>OAM Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ augment /nw:networks/nw:network: +--rw ac-profile* [name] +--rw name string +--rw routing-protocols | ... +--rw oam +--rw bfd {vpn-common:bfd}? +--rw session-type? identityref +--rw desired-min-tx-interval? uint32 +--rw required-min-rx-interval? uint32 +--rw local-multiplier? uint8 +--rw holdtime? uint32 augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string + ... +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | ... +--rw oam | +--rw bfd {vpn-common:bfd}? | +--rw session* [dest-addr] | +--rw dest-addr inet:ip-address | +--rw source-address? union | +--rw failure-detection-profile-ref? leafref | +--rw network-ref? | | -> /nw:networks/network/network-id | +--rw session-type? identityref | +--rw desired-min-tx-interval? uint32 | +--rw required-min-rx-interval? uint32 | +--rw local-multiplier? uint8 | +--rw holdtime? uint32 | +--rw authentication! | | +--rw key-chain? key-chain:key-chain-ref | | +--rw meticulous? boolean | +--rw status | +--rw admin-status | | +--rw status? identityref | | +--ro last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref | +--ro last-change? yang:date-and-time +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>The following OAM data nodes can be specified for each BFD session:</t><dl><dl spacing="normal" newline="false"> <dt>'dest-addr':</dt> <dd> <t>Specifies the BFD peer address. This data node is mapped to 'remote-address' of the BFD container in <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>.target="RFC9834"/>. 'dest-address' is used here to ease the mapping with the underlying device modeldefinddefined in <xref target="RFC9127"/>.</t> </dd> <dt>'source-address':</dt> <dd> <t>Specifies the local IP address or interface to use for the session. This data node is mapped to 'local-address' of the BFD container in <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>.target="RFC9834"/>. 'source-address' is used here to ease the mapping with the underlying device modeldefinddefined in <xref target="RFC9127"/>.</t> </dd> <dt>'failure-detection-profile-ref':</dt> <dd> <t>Refers to a BFD profile in <xref target="sec-profiles"/>.</t> </dd> <dt>'network-ref':</dt> <dd> <t>Includes a network reference to uniquely identify a BFD profile.</t> </dd> <dt>'session-type':</dt> <dd> <t>Indicates which BFD flavor is used to set up the session (e.g., classic BFD <xref target="RFC5880"/>, Seamless BFD <xref target="RFC7880"/>). By default, it is assumed that the BFD session will follow the behavior specified in <xref target="RFC5880"/>.</t> </dd> <dt>'desired-min-tx-interval':</dt> <dd> <t>The minimum interval, in microseconds, to use when transmitting BFD Control packets, less any jitter applied.</t> </dd> <dt>'required-min-rx-interval':</dt> <dd> <t>The minimum interval, in microseconds, between received BFD Controlpacketspackets, less any jitter applied by the sender.</t> </dd> <dt>'local-multiplier':</dt> <dd> <t>The negotiated transmit interval, multiplied by this value, provides the detection time for the peer.</t> </dd> <dt>'holdtime':</dt> <dd> <t>Used to indicate the expected BFD holddown time, in milliseconds.</t> </dd> <dt>'authentication':</dt> <dd> <t>Includes the required information to enable the BFD authentication modes discussed in <xref section="6.7" sectionFormat="of" target="RFC5880"/>. In particular, 'meticulous' controls the activation of meticulous mode as discussed in Sections6.7.3<xref target="RFC5880" sectionFormat="bare" section="6.7.3"/> and6.7.4<xref target="RFC5880" sectionFormat="bare" section="6.7.4"/> of <xref target="RFC5880"/>.</t> </dd> <dt>'status':</dt> <dd> <t>Indicates the status of BFD.</t> </dd> </dl> </section> <section anchor="sec-sec"> <name>Security</name> <t>The security subtree structure is shown in <xref target="sec-tree"/>. The 'security' container specifies thetheencryption to be applied to traffic for a given AC. The model can be used to directly control the encryption to be applied (e.g., Layer 2 or Layer 3 encryption) or invoke a local encryption profile.</t> <figure anchor="sec-tree"> <name>Security Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string + ... +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | ... +--rw oam | ... +--rw security | +--rw encryption {vpn-common:encryption}? | | +--rw enabled? boolean | | +--rw layer? enumeration | +--rw encryption-profile | +--rw (profile)? | +--:(provider-profile) | | +--rw encryption-profile-ref? leafref | | +--rw network-ref? | | -> /nw:networks/network/network-id | +--:(customer-profile) | +--rw customer-key-chain? key-chain:key-chain-ref +--rw service ...]]></artwork>]]></sourcecode> </figure> </section> <section anchor="sec-svc"> <name>Service</name> <t>The service subtree structure is shown in <xref target="svc-tree"/>.</t> <figure anchor="svc-tree"> <name>Service Tree Structure</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string + ... +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | ... +--rw oam | ... +--rw security | ... +--rw service +--rw mtu? uint32 +--rw svc-pe-to-ce-bandwidth {vpn-common:inbound-bw}? | +--rw bandwidth* [bw-type] | +--rw bw-type identityref | +--rw (type)? | +--:(per-cos) | | +--rw cos* [cos-id] | | +--rw cos-id uint8 | | +--rw cir? uint64 | | +--rw cbs? uint64 | | +--rw eir? uint64 | | +--rw ebs? uint64 | | +--rw pir? uint64 | | +--rw pbs? uint64 | +--:(other) | +--rw cir? uint64 | +--rw cbs? uint64 | +--rw eir? uint64 | +--rw ebs? uint64 | +--rw pir? uint64 | +--rw pbs? uint64 +--rw svc-ce-to-pe-bandwidth {vpn-common:outbound-bw}? | +--rw bandwidth* [bw-type] | +--rw bw-type identityref | +--rw (type)? | +--:(per-cos) | | +--rw cos* [cos-id] | | +--rw cos-id uint8 | | +--rw cir? uint64 | | +--rw cbs? uint64 | | +--rw eir? uint64 | | +--rw ebs? uint64 | | +--rw pir? uint64 | | +--rw pbs? uint64 | +--:(other) | +--rw cir? uint64 | +--rw cbs? uint64 | +--rw eir? uint64 | +--rw ebs? uint64 | +--rw pir? uint64 | +--rw pbs? uint64 +--rw qos {vpn-common:qos}? | +--rw qos-profiles | +--rw qos-profile* [qos-profile-ref] | +--rw qos-profile-ref leafref | +--rw network-ref? | | -> /nw:networks/network/network-id | +--rw direction? identityref +--rw access-control-list +--rw acl-profiles +--rw acl-profile* [forwarding-profile-ref] +--rw forwarding-profile-ref leafref +--rw network-ref? -> /nw:networks/network/network-id]]></artwork>]]></sourcecode> </figure> <t>Thedescription of theservice data nodesisare defined as follows:</t><dl><dl spacing="normal" newline="false"> <dt>'mtu':</dt> <dd> <t>Specifies the Layer 2 MTU, in bytes, for the AC.</t> </dd> <dt>'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth':</dt> <dd> <t>Specify the service bandwidth for the AC.</t></dd> <dt/> <dd> <t>'svc-pe-to-ce-bandwidth' indicates<dl newline="false" spacing="normal"> <dt>'svc-pe-to-ce-bandwidth':</dt> <dd>Indicates the inbound bandwidth of the connection (i.e., download bandwidth from the service provider to thesite).</t> </dd> <dt/> <dd> <t>'svc-ce-to-pe-bandwidth' indicatessite).</dd> <dt>'svc-ce-to-pe-bandwidth':</dt> <dd>Indicates the outbound bandwidth of the connection (i.e., upload bandwidth from the site to the serviceprovider).</t> </dd> <dt/> <dd>provider).</dd> </dl> <t>'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth' can be represented using the Committed Information Rate (CIR), the Committed Burst Size (CBS), the Excess Information Rate (EIR), the Excess Burst Size (EBS), the Peak Information Rate (PIR), and the Peak Burst Size (PBS). CIR, EIR, and PIR are expressed in bps, while CBS, EBS, and PBS are expressed in bytes.</t></dd> <dt/> <dd><t>The following types, defined in <xref target="RFC9181"/>, can be used to indicate the bandwidth type:</t><dl><dl spacing="normal" newline="false"> <dt>'bw-per-cos':</dt> <dd> <t>The bandwidth is perCoS.</t>Class of Service (CoS).</t> </dd> <dt>'bw-per-port':</dt> <dd> <t>The bandwidth is per port.</t> </dd> <!--[rfced] To improve readability, may we update "to" to "for"? Original: 'bw-per-site': The bandwidth is to all peer SAPs that belong to the same site. Perhaps: 'bw-per-site': The bandwidth is for all peer SAPs that belong to the same site. --> <dt>'bw-per-site':</dt> <dd> <t>The bandwidth is to all peer SAPs that belong to the same site.</t> </dd> <dt>'bw-per-service':</dt> <dd> <t>The bandwidth is per service instance that is bound to an AC.</t> </dd> </dl> </dd> <dt>'qos':</dt> <dd> <t>Specifies a list of QoS profiles to apply for this AC.</t> </dd> <dt>'access-control-list':</dt> <dd> <t>Specifies a list of ACL profiles to apply for this AC.</t> </dd> </dl> </section> </section> <section anchor="sec-module"> <name>YANG Module</name> <t>This module uses types defined in <xref target="RFC6991"/>, <xref target="RFC8177"/>, <xref target="RFC8294"/>, <xref target="RFC8343"/>, <xref target="RFC9067"/>, <xref target="RFC9181"/>, <xreftarget="I-D.ietf-opsawg-teas-common-ac"/>,target="RFC9833"/>, and <xref target="IEEE802.1Qcp"/>.</t> <!--[rfced] FYI, this YANG module has been updated per the formatting option of pyang. Please let us know any concerns. --> <sourcecodetype="yang"><![CDATA[ <CODE BEGINS> file "ietf-ac-ntw@2025-01-07.yang"type="yang" name="ietf-ac-ntw@2025-08-11.yang" markers="true"><![CDATA[ module ietf-ac-ntw { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ac-ntw"; prefix ac-ntw; import ietf-vpn-common { prefix vpn-common; reference "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 VPNs"; } import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types, Section 4"; } import ietf-key-chain { prefix key-chain; reference "RFC 8177: YANG Data Model for Key Chains"; } import ietf-routing-types { prefix rt-types; reference "RFC 8294: Common YANG Data Types for the Routing Area"; } import ietf-routing-policy { prefix rt-pol; reference "RFC 9067: A YANG Data Model for Routing Policy"; } import ietf-interfaces { prefix if; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ieee802-dot1q-types { prefix dot1q-types; reference "IEEE Std 802.1Qcp: Bridges and Bridged Networks-- Amendment 30: YANG Data Model"; } import ietf-network { prefix nw; reference "RFC 8345: A YANG Data Model for Network Topologies, Section 6.1"; } import ietf-sap-ntw { prefix sap; reference "RFC 9408: A YANG Network Data Model for Service Attachment Points (SAPs)"; } import ietf-ac-common { prefix ac-common; reference "RFCCCCC:9833: A Common YANG Data Model for Attachment Circuits"; } import ietf-ac-svc { prefix ac-svc; reference "RFCSSSS:9834: YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)"; } organization "IETF OPSAWG (Operations and Management Area Working Group)"; contact "WG Web: <https://datatracker.ietf.org/wg/opsawg/> WG List: <mailto:opsawg@ietf.org> Editor: Mohamed Boucadair <mailto:mohamed.boucadair@orange.com> Author: Richard Roberts <mailto:rroberts@juniper.net> Author: Oscar Gonzalez de Dios <mailto:oscar.gonzalezdedios@telefonica.com> Author: Samier Barguil <mailto:ssamier.barguil_giraldo@nokia.com> Author: Bo Wu <mailto:lana.wubo@huawei.com>"; description "This YANG module defines a YANG network model for the management of attachment circuits (ACs). Copyright (c) 2025 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFCXXXX;9835; see the RFC itself for full legal notices."; revision2025-01-072025-08-11 { description "Initial revision."; reference "RFCXXXX:9835: A YANG Network Data Model for Attachment Circuits"; } // References /* A set of groupings to ease referencing cross-modules */ grouping attachment-circuit-reference { description "This grouping can be used to reference an attachment circuit in a specific node."; leaf ac-ref { type leafref { path "/nw:networks/nw:network[nw:network-id=current()/../" + "network-ref]/nw:node[nw:node-id=current()/../" + "node-ref]/ac-ntw:ac/ac-ntw:name"; require-instance false; } description "An absolute reference to an attachment circuit."; } uses nw:node-ref; } grouping attachment-circuit-references { description "This grouping can be used to reference a list of attachment circuits in a specific node."; leaf-list ac-ref { type leafref { path "/nw:networks/nw:network[nw:network-id=current()/../" + "network-ref]/nw:node[nw:node-id=current()/../" + "node-ref]/ac-ntw:ac/ac-ntw:name"; require-instance false; } description "An absolute reference to an attachment circuit."; } uses nw:node-ref; } grouping ac-profile-reference { description "This grouping can be used to reference an attachment circuit profile."; leaf ac-profile-ref { type leafref { path "/nw:networks/nw:network[nw:network-id=current()/../" + "network-ref]/ac-ntw:ac-profile/ac-ntw:name"; require-instance false; } description "An absolute reference to an attachment circuit."; } uses nw:network-ref; } grouping encryption-profile-reference { description "This grouping can be used to reference an encryption profile."; leaf encryption-profile-ref { type leafref { path "/nw:networks/nw:network[nw:network-id=current()/../" + "network-ref]" + "/ac-ntw:specific-provisioning-profiles" + "/ac-ntw:valid-provider-identifiers" + "/ac-ntw:encryption-profile-identifier/ac-ntw:id"; require-instance false; } description "An absolute reference to an encryption profile."; } uses nw:network-ref; } grouping qos-profile-reference { description "This grouping can be used to reference a QoS profile."; leaf qos-profile-ref { type leafref { path "/nw:networks/nw:network[nw:network-id=current()/../" + "network-ref]" + "/ac-ntw:specific-provisioning-profiles" + "/ac-ntw:valid-provider-identifiers" + "/ac-ntw:qos-profile-identifier/ac-ntw:id"; require-instance false; } description "An absolute reference to a QoS profile."; } uses nw:network-ref; } grouping failure-detection-profile-reference { description "This grouping can be used to reference a failure detection profile."; leaf failure-detection-profile-ref { type leafref { path "/nw:networks/nw:network[nw:network-id=current()/../" + "network-ref]" + "/ac-ntw:specific-provisioning-profiles" + "/ac-ntw:valid-provider-identifiers" + "/ac-ntw:failure-detection-profile-identifier/ac-ntw:id"; require-instance false; } description "An absolute reference to a failure detection profile."; } uses nw:network-ref; } grouping forwarding-profile-reference { description "This grouping can be used to reference a forwarding profile."; leaf forwarding-profile-ref { type leafref { path "/nw:networks/nw:network[nw:network-id=current()/../" + "network-ref]" + "/ac-ntw:specific-provisioning-profiles" + "/ac-ntw:valid-provider-identifiers" + "/ac-ntw:forwarding-profile-identifier/ac-ntw:id"; require-instance false; } description "An absolute reference to a forwarding profile."; } uses nw:network-ref; } grouping routing-profile-reference { description "This grouping can be used to reference a routing profile."; leaf routing-profile-ref { type leafref { path "/nw:networks/nw:network[nw:network-id=current()/../" + "network-ref]" + "/ac-ntw:specific-provisioning-profiles" + "/ac-ntw:valid-provider-identifiers" + "/ac-ntw:routing-profile-identifier/ac-ntw:id"; require-instance false; } description "An absolute reference to a routing profile."; } uses nw:network-ref; } // Layer 2 connection grouping l2-connection { description "Defines Layer 2 protocols and parameters that are required to enable AC connectivity on the network side."; container encapsulation { description "Container for Layer 2 encapsulation."; leaf encap-type { type identityref { base vpn-common:encapsulation-type; } description "Tagged interface type."; } container dot1q { when "derived-from-or-self(../encap-type, " + "'vpn-common:dot1q')" { description "Only applies when the type of the tagged interface is 'dot1q'."; } description "Tagged interface."; uses ac-common:dot1q; container tag-operations { description "Sets the tag manipulation policy for this AC. It defines a set of tag manipulations that allow for the insertion, removal, or rewriting of 802.1Q VLAN tags. These operations are indicated for the CE-PE direction. By default, tag operations are symmetric. As such, the reverse tag operation is assumed on the PE-CE direction."; choice op-choice { description "Selects the tag rewriting policy for an AC."; leaf pop { type empty; description "Pop the outer tag."; } leaf push { type empty; description "Pushes one or two tags defined by the tag-1 and tag-2 leaves. It is assumed that, absent any policy, the default value of 0 will be used for the Priority Code Point (PCP) setting."; } leaf translate { type empty; description "Translates the outer tag to one or two tags. PCP bits are preserved."; } } leaf tag-1 { when 'not(../pop)'; type dot1q-types:vlanid; description "A first tag to be used for push or translate operations. This tag will be used as the outermost tag as a result of the tag operation."; } leaf tag-1-type { type dot1q-types:dot1q-tag-type; default "dot1q-types:s-vlan"; description "Specifies a specific 802.1Q tag type of tag-1."; } leaf tag-2 { when '(../translate)'; type dot1q-types:vlanid; description "A second tag to be used for translation."; } leaf tag-2-type { type dot1q-types:dot1q-tag-type; default "dot1q-types:c-vlan"; description "Specifies a specific 802.1Q tag type of tag-2."; } } } container priority-tagged { when "derived-from-or-self(../encap-type, " + "'vpn-common:priority-tagged')" { description "Only applies when the type of the tagged interface is 'priority-tagged'."; } description "Priority tagged container."; uses ac-common:priority-tagged; } container qinq { when "derived-from-or-self(../encap-type, " + "'vpn-common:qinq')" { description "Only applies when the type of the tagged interface is 'QinQ'."; } description "Includes QinQ parameters."; uses ac-common:qinq; container tag-operations { description "Sets the tag manipulation policy for this AC. It defines a set of tag manipulations that allow for the insertion, removal, or rewriting of 802.1Q VLAN tags. These operations are indicated for the CE-PE direction. By default, tag operations are symmetric. As such, the reverse tag operation is assumed on the PE-CE direction."; choice op-choice { description "Selects the tag rewriting policy foraan AC."; leaf pop { type uint8 { range "1|2"; } description "Pops one or two tags as a function of the indicated pop value."; } leaf push { type empty; description "Pushes one or two tags defined by the tag-1 and tag-2 leaves. It is assumed that, absent any policy, the default value of 0 will be used for PCP setting."; } leaf translate { type uint8 { range "1|2"; } description "Translates one or two outer tags. PCP bits are preserved. The following operations are supported: - translate 1 with tag-1 leaf is provided: only the outermost tag is translated to the value in tag-1. - translate 2 with both tag-1 and tag-2 leaves are provided: both outer and inner tags are translated to the values in tag-1 and tag-2, respectively. - translate 2 with tag-1 leaf is provided: the outer tag is popped while the inner tag is translated to the value in tag-1."; } } leaf tag-1 { when 'not(../pop)'; type dot1q-types:vlanid; description "A first tag to be used for push or translate operations. This tag will be used as the outermost tag as a result of the tag operation."; } leaf tag-1-type { type dot1q-types:dot1q-tag-type; default "dot1q-types:s-vlan"; description "Specifies a specific 802.1Q tag type of tag-1."; } leaf tag-2 { when 'not(../pop)'; type dot1q-types:vlanid; description "A second tag to be used for push or translate operations."; } leaf tag-2-type { type dot1q-types:dot1q-tag-type; default "dot1q-types:c-vlan"; description "Specifies a specific 802.1Q tag type of tag-2."; } } } } choice l2-service { description "The Layer 2 connectivity service can be provided by indicating a pointer to an L2VPN or by specifying a Layer 2 tunnel service."; container l2-tunnel-service { description "Defines a Layer 2 tunnel termination."; uses ac-common:l2-tunnel-service; } case l2vpn { leaf l2vpn-id { type vpn-common:vpn-id; description "Indicates the L2VPN service associated with an Integrated Routing and Bridging (IRB) interface."; } } } } grouping l2-connection-if-ref { description "Specifies Layer 2 connection parameters with interface references."; uses l2-connection; leaf l2-termination-point { type string; description "Specifies a reference to a local Layer 2 termination point, such as a Layer 2 sub-interface."; } leaf local-bridge-reference { type string; description "Specifies a local bridge reference to accommodate, e.g., implementations that require internal bridging. A reference may be a local bridge domain."; } leaf bearer-reference { if-feature "ac-common:server-assigned-reference"; type string; description "This is an internal reference for the service provider to identify the bearer associated with this AC."; } container lag-interface { if-feature "vpn-common:lag-interface"; description "Container for configuration of Link Aggregation Group (LAG) interface attributes."; leaf lag-interface-id { type string; description "LAG interface identifier."; } container member-link-list { description "Container for the member link list."; list member-link { key "name"; description "Member link."; leaf name { type string; description "Member link name."; } } } } } // IPv4 connection grouping ipv4-connection { description "IPv4-specific connection parameters."; leaf local-address { type inet:ipv4-address; description "The IPv4 address used at the provider's interface."; } uses ac-common:ipv4-allocation-type; choice allocation-type { description "Choice of the IPv4 address allocation."; case dynamic { description "When the addresses are allocated by DHCP or other dynamic means local to the infrastructure."; choice address-assign { description "A choice for how IPv4 addresses are assigned."; case number { leaf number-of-dynamic-address { type uint16; description "Specifies the number of IP addresses to be assigned to the customer on this access."; } } case explicit { container customer-addresses { description "Container for customer addresses to be allocated using DHCP."; list address-pool { key "pool-id"; description "Describes IP addresses to be dynamically allocated. When only 'start-address' is present, it represents a single address. When both 'start-address' and 'end-address' are specified, it implies a range inclusive of both addresses."; leaf pool-id { type string; description "A pool identifier for the address range from 'start-address' to 'end-address'."; } leaf start-address { type inet:ipv4-address; mandatory true; description "Indicates the first address in the pool."; } leaf end-address { type inet:ipv4-address; description "Indicates the last address in the pool."; } } } } } choice provider-dhcp { description "Parameters related to DHCP-allocated addresses. IP addresses are allocated by DHCP, which is provided by the operator."; leaf dhcp-service-type { type enumeration { enum server { description "Local DHCP server."; } enum relay { description "Local DHCP relay. DHCP requests are relayed to a provider's server."; } } description "Indicates the type of DHCP service to be enabled on this access."; } choice service-type { description "Choice based on the DHCP service type."; case relay { description "Container for a list of the provider's DHCP servers (i.e., 'dhcp-service-type' is set to 'relay')."; leaf-list server-ip-address { type inet:ipv4-address; description "IPv4 addresses of the provider's DHCP server, for use by the local DHCP relay."; } } } } choice dhcp-relay { description "The DHCP relay is provided by the operator."; container customer-dhcp-servers { description "Container for a list of the customer's DHCP servers."; leaf-list server-ip-address { type inet:ipv4-address; description "IPv4 addresses of the customer's DHCP server."; } } } } case static-addresses { description "Lists the static IPv4 addresses that are used."; list address { key "address-id"; ordered-by user; description "Lists the IPv4 addresses that are used. The first address of the list is the primary address of the connection."; leaf address-id { type string; description "An identifier of the static IPv4 address."; } leaf customer-address { type inet:ipv4-address; description "An IPv4 address of the customer side."; } uses failure-detection-profile-reference; } } } } grouping ipv6-connection { description "IPv6-specific connection parameters."; leaf local-address { type inet:ipv6-address; description "IPv6 address of the provider side."; } uses ac-common:ipv6-allocation-type; choice allocation-type { description "Choice of the IPv6 address allocation."; case dynamic { description "When the addresses are allocated by DHCP or other dynamic means local to the infrastructure."; choice address-assign { description "A choice for how IPv6 addresses are assigned."; case number { leaf number-of-dynamic-address { type uint16; description "Specifies the number of IP addresses to be assigned to the customer on this access."; } } case explicit { container customer-addresses { description "Container for customer addresses to be allocated using DHCP."; list address-pool { key "pool-id"; description "Describes IPv6 addresses to be dynamically allocated. When only 'start-address' is present, it represents a single address. When both 'start-address' and 'end-address' are specified, it implies a range inclusive of both addresses."; leaf pool-id { type string; description "A pool identifier for the address range from 'start-address' to 'end-address'."; } leaf start-address { type inet:ipv6-address; mandatory true; description "Indicates the first address in the pool."; } leaf end-address { type inet:ipv6-address; description "Indicates the last address in the pool."; } } } } } choice provider-dhcp { description "Parameters related to DHCP-allocated addresses. IP addresses are allocated by DHCP, which is provided by the operator."; leaf dhcp-service-type { type enumeration { enum server { description "Local DHCP server."; } enum relay { description "Local DHCP relay. DHCP requests are relayed to a provider's server."; } } description "Indicates the type of DHCP service to be enabled on this access."; } choice service-type { description "Choice based on the DHCP service type."; case relay { description "Container for a list of the provider's DHCP servers (i.e., 'dhcp-service-type' is set to 'relay')."; leaf-list server-ip-address { type inet:ipv6-address; description "IPv6 addresses of the provider's DHCP server, for use by the local DHCP relay."; } } } } choice dhcp-relay { description "The DHCP relay is provided by the operator."; container customer-dhcp-servers { description "Container for a list of the customer's DHCP servers."; leaf-list server-ip-address { type inet:ipv6-address; description "IPv6 addresses of the customer's DHCP servers."; } } } } case static-addresses { description "Lists the static IPv6 addresses that are used."; list address { key "address-id"; ordered-by user; description "Lists the IPv6 addresses that are used. The first address of the list is the primary address of the connection."; leaf address-id { type string; description "An identifier of the static IPv6 address."; } leaf customer-address { type inet:ipv6-address; description "An IPv6 address of the customer side."; } uses failure-detection-profile-reference; } } } } grouping ip-connection { description "Defines IP connection parameters."; leaf l3-termination-point { type string; description "Specifies a reference to a local Layer 3 termination point, such as a bridge domain interface."; } container ipv4 { if-feature "vpn-common:ipv4"; description "IPv4-specific connection parameters."; uses ipv4-connection; } container ipv6 { if-feature "vpn-common:ipv6"; description "IPv6-specific connection parameters."; uses ipv6-connection; } } /* Routing */ //BGP base parameters grouping bgp-base { description "Configuration specific to BGP."; leaf description { type string; description "Includes a description of the BGP session. This description is meant to be used for diagnostic purposes. Thesemanticsemantics of the descriptionisare local to an implementation."; } uses rt-pol:apply-policy-group; leaf local-as { type inet:as-number; description "Indicates a local AS Number (ASN), if an ASN distinct from the ASN configured at the AC level is needed."; } leaf peer-as { type inet:as-number; mandatory true; description "Indicates the customer's ASN when the customer requests BGP routing."; } leaf address-family { type identityref { base vpn-common:address-family; } description "This node contains the address families to be activated. 'dual-stack' means that both IPv4 and IPv6 will be activated."; } leaf role { type identityref { base ac-common:bgp-role; } description "Specifies the BGP role (provider, customer, peer, etc.)."; } leaf multihop { type uint8; description "Describes the number of IP hops allowed between a given BGP neighbor and the PE."; } leaf as-override { type boolean; description "Defines whether ASN override is enabled, i.e., replacing the ASN of the customer specified in the AS_PATH attribute with the local ASN."; } leaf allow-own-as { type uint8; description "If set, specifies the maximum number of occurrences of the provider's ASN that are permitted within the AS_PATH before it is rejected."; } leaf prepend-global-as { type boolean; description "In some situations, the ASN that is provided at the node level may be distinct from the ASN configured at the AC. When such ASNs are provided, they are both prepended to the BGP route updates for this AC. To disable that behavior, 'prepend-global-as' must be set to 'false'. In such a case, the ASN that is provided at the node level is not prepended to the BGP route updates for this access."; } leaf send-default-route { type boolean; description "Defines whether default routes can be advertised to a peer. If set to 'true', the default routes are advertised to a peer."; } leaf site-of-origin { when "derived-from-or-self(../address-family, " + "'vpn-common:ipv4' or 'vpn-common:dual-stack')" { description "Only applies if IPv4 is activated."; } type rt-types:route-origin; description "The Site of Origin attribute is encoded as a Route Origin Extended Community. It is meant to uniquely identify the set of routes learned from a site via a particular AC and is used to prevent routing loops."; reference "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs), Section 7"; } leaf ipv6-site-of-origin { when "derived-from-or-self(../address-family, " + "'vpn-common:ipv6' or 'vpn-common:dual-stack')" { description "Only applies if IPv6 is activated."; } type rt-types:ipv6-route-origin; description "The IPv6 Site of Origin attribute is encoded as an IPv6 Route Origin Extended Community. It is meant to uniquely identify the set of routes learned from a site."; reference "RFC 5701: IPv6 Address Specific BGP Extended Community Attribute"; } list redistribute-connected { key "address-family"; description "Indicates, per address family, the policy to follow for connected routes."; leaf address-family { type identityref { base vpn-common:address-family; } description "Indicates the address family."; } leaf enabled { type boolean; description "Enables, when set to 'true', the redistribution ofConnectedconnected routes."; } } container bgp-max-prefix { description "Controls the behavior when a prefix maximum is reached."; leaf max-prefix { type uint32; description "Indicates the maximum number of BGP prefixes allowed in the BGP session. It allows control of how many prefixes can be received from a neighbor. If the limit is exceeded, the action indicated in 'violate-action' will be followed."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 8.2.2"; } leaf warning-threshold { type decimal64 { fraction-digits 5; range "0..100"; } units "percent"; description "When this value is reached, a warning notification will be triggered."; } leaf violate-action { type enumeration { enum warning { description "Only a warning message is sent to the peer when the limit is exceeded."; } enum discard-extra-paths { description "Discards extra paths when the limit is exceeded."; } enum restart { description "The BGP session restarts after the indicated time interval."; } } description "If the BGP neighbor 'max-prefix' limit is reached, the action indicated in 'violate-action' will be followed."; } leaf restart-timer { type uint32; units "seconds"; description "Time interval after which the BGP session will be reestablished."; } } container bgp-timers { description "Includes two BGP timers."; leaf keepalive { type uint16 { range "0..21845"; } units "seconds"; description "This timer indicates the KEEPALIVE messages' frequency between a PE and a BGP peer. If set to '0', it indicates that KEEPALIVE messages are disabled. It is suggested that the maximum time between KEEPALIVE messages be one-third of the Hold Time interval."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 4.4"; } leaf hold-time { type uint16 { range "0 | 3..65535"; } units "seconds"; description "Indicates the maximum number of seconds that may elapse between the receipt of successive KEEPALIVE and/or UPDATE messages from the peer. The Hold Time must be either zero or at least three seconds."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 4.2"; } } } grouping bgp-base-peer-group { description "Grouping for a basic BGP peer group."; leaf name { type string; description "Name of the BGP peer group."; } uses bgp-base; } grouping bgp-base-peer-group-list { description "Grouping for a list of basic BGP peer groups."; list peer-group { key "name"; description "List of BGP peer groups uniquely identified by a name."; uses bgp-base-peer-group; } } grouping bgp-peer-group { description "Grouping for BGP peer group."; leaf name { type string; description "Name of the BGP peer group"; } leaf local-address { type union { type inet:ip-address; type if:interface-ref; } description "Sets the local IP address to use for the BGP transport session. This may be expressed as either an IP address or a reference to an interface."; } uses bgp-base; uses ac-common:bgp-authentication; } grouping bgp-peer-group-list { description "Grouping for a list of BGP peer groups."; list peer-group { key "name"; description "List of BGP peer groups uniquely identified by a name."; uses bgp-peer-group; } } // RIP base parameters grouping rip-base { description "Configuration specific to RIP routing."; leaf address-family { type identityref { base vpn-common:address-family; } description "Indicates whether IPv4, IPv6, or both address families are to be activated."; } container timers { description "Indicates the RIP timers."; reference "RFC 2080: RIPng for IPv6 RFC 2453: RIP Version 2"; leaf update-interval { type uint16 { range "1..32767"; } units "seconds"; description "Indicates the RIP update time, i.e., the amount of time for which RIP updates are sent."; } leaf invalid-interval { type uint16 { range "1..32767"; } units "seconds"; description "The interval before a route is declared invalid after no updates are received. This value is at least three times the value for the 'update-interval' argument."; } leaf holddown-interval { type uint16 { range "1..32767"; } units "seconds"; description "Specifies the interval before better routes are released."; } leaf flush-interval { type uint16 { range "1..32767"; } units "seconds"; description "Indicates the RIP flush timer, i.e., the amount of time that must elapse before a route is removed from the routing table."; } } leaf default-metric { type uint8 { range "0..16"; } description "Sets the default metric."; } } // Routing profile grouping routing-profile { description "Defines profiles for routing protocols."; list routing-protocol { key "id"; description "List of routing protocols used on the AC."; leaf id { type string; description "Unique identifier for the routing protocol."; } leaf type { type identityref { base vpn-common:routing-protocol-type; } description "Type of routing protocol."; } container bgp { when "derived-from-or-self(../type, " + "'vpn-common:bgp-routing')" { description "Only applies when the protocol is BGP."; } if-feature "vpn-common:rtg-bgp"; description "Configuration specific to BGP."; container peer-groups { description "Lists a set of BGP peer groups."; uses bgp-base-peer-group-list; } } container ospf { when "derived-from-or-self(../type, " + "'vpn-common:ospf-routing')" { description "Only applies when the protocol is OSPF."; } if-feature "vpn-common:rtg-ospf"; description "Configuration specific to OSPF."; uses ac-common:ospf-basic; leaf max-lsa { type uint32 { range "1..4294967294"; } description "Maximum number of allowed Link State Advertisements (LSAs) that the OSPF instance will accept."; } leaf passive { type boolean; description"Enables when"When set to'true''true', enables a passive interface. It is active when set to 'false'. A passive interface's prefix will be advertised, but no neighbor adjacencies will be formed on the interface."; } } container isis { when "derived-from-or-self(../type, " + "'vpn-common:isis-routing')" { description "Only applies when the protocol is IS-IS."; } if-feature "vpn-common:rtg-isis"; description "Configuration specific to IS-IS."; uses ac-common:isis-basic; leaf level { type identityref { base vpn-common:isis-level; } description "Can be 'level-1', 'level-2', or 'level-1-2'."; reference "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 VPNs"; } leaf metric { type uint32 { range "0 .. 16777215"; } description "Metric of the AC. It is used in the routing state calculation and path selection."; } leaf passive { type boolean; description "When set to 'false', the interface is active. In such mode, the interface sends or receives IS-IS protocol control packets. When set to 'true', the interface is passive. That is, it suppresses the sending of IS-IS updates through the specified interface."; } } container rip { when "derived-from-or-self(../type, " + "'vpn-common:rip-routing')" { description "Only applies when the protocol is RIP."; } if-feature "vpn-common:rtg-rip"; description "Configuration specific to RIP routing."; uses rip-base; } container vrrp { when "derived-from-or-self(../type, " + "'vpn-common:vrrp-routing')" { description "Only applies when the protocol is the Virtual Router Redundancy Protocol (VRRP)."; } if-feature "vpn-common:rtg-vrrp"; description "Configuration specific to VRRP."; reference "RFC 9568: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6"; leaf address-family { type identityref { base vpn-common:address-family; } description "Indicates whether IPv4, IPv6, or both address families are to be enabled."; } leaf ping-reply { type boolean; description "Controls whether the VRRP speaker should reply to ping requests. Such behavior is enabled, if set to 'true'."; } } } } grouping routing { description "Defines routing protocols."; list routing-protocol { key "id"; description "List of routing protocols used on the AC."; leaf id { type string; description "Unique identifier for the routing protocol."; } leaf type { type identityref { base vpn-common:routing-protocol-type; } description "Type of routing protocol."; } list routing-profile { key "routing-profile-ref"; description "Routing profiles."; uses routing-profile-reference; leaf type { type identityref { base vpn-common:ie-type; } description "Import, export, or both."; } } container static { when "derived-from-or-self(../type, " + "'vpn-common:static-routing')" { description "Only applies when the protocol is static routing."; } description "Configuration specific to static routing."; container cascaded-lan-prefixes { description "LAN prefixes from the customer."; list ipv4-lan-prefix { if-feature "vpn-common:ipv4"; key "lan next-hop"; description "List of LAN prefixes for the site."; uses ac-common:ipv4-static-rtg-entry; uses bfd-routing; leaf preference { type uint32; description "Indicates the preference associated with the static route."; } uses ac-common:service-status; } list ipv6-lan-prefix { if-feature "vpn-common:ipv6"; key "lan next-hop"; description "List of LAN prefixes for the site."; uses ac-common:ipv6-static-rtg-entry; uses bfd-routing; leaf preference { type uint32; description "Indicates the preference associated with the static route."; } uses ac-common:service-status; } } } container bgp { when "derived-from-or-self(../type, " + "'vpn-common:bgp-routing')" { description "Only applies when the protocol is BGP."; } if-feature "vpn-common:rtg-bgp"; description "Configuration specific to BGP."; container peer-groups { description "Configuration for BGP peer groups"; uses bgp-peer-group-list; } list neighbor { key "remote-address"; description "List of BGP neighbors."; leaf remote-address { type inet:ip-address; description "The remote IP address of this entry's BGP peer."; } leaf local-address { type union { type inet:ip-address; type if:interface-ref; } description "Sets the local IP address to use for the BGP transport session. This may be expressed as either an IP address or a reference to an interface."; } leaf peer-group { type leafref { path "../../peer-groups/peer-group/name"; } description "The peer group with which this neighbor is associated."; } uses bgp-base; uses bfd-routing; uses ac-common:bgp-authentication; uses ac-common:service-status; } } container ospf { when "derived-from-or-self(../type, " + "'vpn-common:ospf-routing')" { description "Only applies when the protocol is OSPF."; } if-feature "vpn-common:rtg-ospf"; description "Configuration specific to OSPF."; uses ac-common:ospf-basic; container sham-links { if-feature "vpn-common:rtg-ospf-sham-link"; description "List of sham links."; reference "RFC 4577: OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs), Section 4.2.7 RFC 6565: OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol, Section 5"; list sham-link { key "target-site"; description "Creates a sham link with another site."; leaf target-site { type string; description "Target site for the sham link connection. The site is referred to by its identifier."; } leaf metric { type uint16; description "Metric of the sham link. It is used in the routing state calculation and path selection."; reference "RFC 4577: OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs), Section 4.2.7.3 RFC 6565: OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol, Section 5.2"; } } } leaf max-lsa { type uint32 { range "1..4294967294"; } description "Maximum number of allowed Link State Advertisements (LSAs) that the OSPF instance will accept."; } leaf passive { type boolean; description"Enables when"When set to'true''true', enables a passive interface. It is active when set to 'false'. A passive interface's prefix will be advertised, but no neighbor adjacencies will be formed on the interface."; } uses ac-common:ospf-authentication; uses ac-common:service-status; } container isis { when "derived-from-or-self(../type, " + "'vpn-common:isis-routing')" { description "Only applies when the protocol is IS-IS."; } if-feature "vpn-common:rtg-isis"; description "Configuration specific to IS-IS."; uses ac-common:isis-basic; leaf level { type identityref { base vpn-common:isis-level; } description "Can be 'level-1', 'level-2', or 'level-1-2'."; reference "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 VPNs"; } leaf metric { type uint32 { range "0 .. 16777215"; } description "Metric of the AC. It is used in the routing state calculation and path selection."; } leaf passive { type boolean; description "When set to 'false', the interface is active. In such mode, the interface sends or receives IS-IS protocol control packets. When set to 'true', the interface is passive. That is, it suppresses the sending of IS-IS updates through the specified interface."; } uses ac-common:isis-authentication; uses ac-common:service-status; } container rip { when "derived-from-or-self(../type, " + "'vpn-common:rip-routing')" { description "Only applies when the protocol is RIP. For IPv4, the model assumes that RIP version 2 is used."; } if-feature "vpn-common:rtg-rip"; description "Configuration specific to RIP routing."; uses rip-base; uses ac-common:rip-authentication; uses ac-common:service-status; } container vrrp { when "derived-from-or-self(../type, " + "'vpn-common:vrrp-routing')" { description "Only applies when the protocol istheVRRP."; } if-feature "vpn-common:rtg-vrrp"; description "Configuration specific to VRRP."; reference "RFC 9568: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6"; leaf address-family { type identityref { base vpn-common:address-family; } description "Indicates whether IPv4, IPv6, or both address families are to be enabled."; } leaf vrrp-group { type uint8 { range "1..255"; } description "Includes the VRRP group identifier."; } leaf backup-peer { type inet:ip-address; description "Indicates the IP address of the peer."; } leaf-list virtual-ip-address { type inet:ip-address; description "Virtual IP addresses for a single VRRP group."; reference "RFC 9568: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6, Sections 1.2 and 1.3"; } leaf priority { type uint8 { range "1..254"; } description "Sets the local priority of the VRRP speaker."; } leaf ping-reply { type boolean; description "Controls whether the VRRP speaker should reply to ping requests."; } uses ac-common:service-status; } } } // OAM grouping bfd { description "Grouping for BFD."; leaf session-type { type identityref { base vpn-common:bfd-session-type; } description "Specifies the BFD session type."; } leaf desired-min-tx-interval { type uint32; units "microseconds"; description "The minimum interval between transmissions of BFD Control packets, as desired by the operator."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.8.7"; } leaf required-min-rx-interval { type uint32; units "microseconds"; description "The minimum interval between received BFD Control packets that the PE should support."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.8.7"; } leaf local-multiplier { type uint8 { range "1..255"; } description "Specifies the detection multiplier that is transmitted to a BFD peer. The detection interval for the receiving BFD peer is calculated by multiplying the value of the negotiated transmission interval by the received detection multiplier value."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.8.7"; } leaf holdtime { type uint32; units "milliseconds"; description "Expected BFD holdtime. The customer may impose some fixed values for the holdtime period if the provider allows the customer to use this function."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.8.18"; } } grouping bfd-routing { description "Defines a basic BFD grouping for routing configuration."; container bfd { if-feature "vpn-common:bfd"; description "BFD control for this neighbor."; leaf enabled { type boolean; description "Enables BFD if set to 'true'. BFD is disabledofif set to 'false'."; } uses failure-detection-profile-reference; } } grouping oam { description "Defines the Operations, Administration, and Maintenance (OAM) mechanisms used."; container bfd { if-feature "vpn-common:bfd"; description "Container for BFD."; list session { key "dest-addr"; description "List of IP sessions."; leaf dest-addr { type inet:ip-address; description "IP address of the peer."; } leaf source-address { type union { type inet:ip-address; type if:interface-ref; } description "Sets the local IP address to use for the BFD session. This may be expressed as either an IP address or a reference to an interface."; } uses failure-detection-profile-reference; uses bfd; container authentication { presence "Enables BFD authentication"; description "Parameters for BFD authentication."; leaf key-chain { type key-chain:key-chain-ref; description "Name of the key chain."; } leaf meticulous { type boolean; description "Enables meticulous mode, if set to 'true'."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.7"; } } uses ac-common:service-status; } } } // Security grouping security { description "Security parameters for an AC."; container encryption { if-feature "vpn-common:encryption"; description "Container for AC encryption."; leaf enabled { type boolean; description "If set to 'true', traffic encryption on the connection is required. Otherwise, it is disabled."; } leaf layer { when "../enabled = 'true'" { description "Included only when encryption is enabled."; } type enumeration { enum layer2 { description "Encryption occurs at Layer 2."; } enum layer3 { description "Encryption occurs at Layer 3. For example, IPsec may be used when a customer requests Layer 3 encryption."; } } description "Indicates the layer on which encryption is applied."; } } container encryption-profile { when "../encryption/enabled = 'true'" { description "Indicates the layer on which encryption is enabled."; } description "Container for the encryption profile."; choice profile { description "Choice for the encryption profile."; case provider-profile { uses encryption-profile-reference; } case customer-profile { leaf customer-key-chain { type key-chain:key-chain-ref; description "Customer-supplied key chain."; } } } } } // AC profile grouping ac-profile { description "Grouping for attachment circuit profiles."; container routing-protocols { description "Defines routing protocols."; uses routing-profile; } container oam { description "Defines the OAM mechanisms used for the AC profile."; container bfd { if-feature "vpn-common:bfd"; description "Container for BFD."; uses bfd; } } } // Parent and Child ACs grouping ac-hierarchy { description "Container for parent and child AC references."; container parent-ref { description "Specifies the parent AC that is inherited by an AC. Parent ACs are used, e.g., in contexts where multiple CEs are terminating the same AC, but some specific information is required for each peer SAP."; uses ac-ntw:attachment-circuit-reference; } container child-ref { config false; description "Specifies a child AC that relies upon a parent AC."; uses ac-ntw:attachment-circuit-references; } } // AC network provisioning grouping ac { description "Grouping for attachment circuits."; leaf description { type string; description "Associates a description with an AC."; } container l2-connection { if-feature "ac-common:layer2-ac"; description "Defines Layer 2 protocols and parameters that are required to enable AC connectivity."; uses l2-connection-if-ref; } container ip-connection { if-feature "ac-common:layer3-ac"; description "Defines IP connection parameters."; uses ip-connection; } container routing-protocols { description "Defines routing protocols."; uses routing; } container oam { description "Defines the OAM mechanisms used for the AC."; uses oam; } container security { description "AC-specific security parameters."; uses security; } container service { description "AC-specific bandwidth parameters."; leaf mtu { type uint32; units "bytes"; description "Layer 2 MTU."; } uses ac-svc:bandwidth; container qos { if-feature "vpn-common:qos"; description "QoS configuration."; container qos-profiles { description "QoS profile configuration."; list qos-profile { key "qos-profile-ref"; description "Points to a QoS profile."; uses qos-profile-reference; leaf direction { type identityref { base vpn-common:qos-profile-direction; } description "The direction to which the QoS profile is applied."; } } } } container access-control-list { description "Container for the Access Control List (ACL)."; container acl-profiles { description "ACL profile configuration."; list acl-profile { key "forwarding-profile-ref"; description "Points to an ACL profile."; uses forwarding-profile-reference; } } } } } augment "/nw:networks/nw:network" { description "Add a list of profiles."; container specific-provisioning-profiles { description "Contains a set of valid profiles to reference in the AC activation."; uses ac-common:ac-profile-cfg; } list ac-profile { key "name"; description "Specifies a list of AC profiles."; leaf name { type string; description "Name of the AC."; } uses ac-ntw:ac-profile; } } augment "/nw:networks/nw:network/nw:node" { when '../nw:network-types/sap:sap-network' { description "Augmentation parameters apply only for SAP networks."; } description "Augments nodes with AC provisioning details."; list ac { key "name"; description "List of ACs."; leaf name { type string; description "A name that identifies the AC locally."; } leaf svc-ref { type ac-svc:attachment-circuit-reference; description "A reference to the AC as exposed at the service level."; } list profile { key "ac-profile-ref"; description "List of AC profiles."; uses ac-profile-reference; } uses ac-hierarchy; leaf-list peer-sap-id { type string; description "One or more peer SAPs can be indicated."; } uses ac-common:redundancy-group; uses ac-common:service-status; uses ac-ntw:ac; } } augment "/nw:networks/nw:network/nw:node" + "/sap:service/sap:sap" { when '../../../nw:network-types/sap:sap-network' { description "Augmentation parameters apply only for SAP networks."; } description "Augments SAPs with AC provisioning details."; list ac { key "ac-ref"; description "Specifies the ACs that are terminated by the SAP."; uses ac-ntw:attachment-circuit-reference; } } }<CODE ENDS>]]></sourcecode> </section> <section anchor="security-considerations"> <!--[rfced] *AD - We note that there is some text in the Security Considerations section that differs from the template on <https://wiki.ietf.org/group/ops/yang-security-guidelines>. Please review and let us know if the text is acceptable. For example: - This sentence is not present; should it be added? "There are no particularly sensitive RPC or action operations." If so, should it be at the end of the section? (Your reply to this question will also be applied to RFC 9836.) From the guidelines page: "If the data model contains any particularly sensitive RPC or action operations, then those operations must be listed here, along with an explanation of the associated specific sensitivity or vulnerability concerns. Otherwise, state: 'There are no particularly sensitive RPC or action operations.'" - The last two paragraphs (after the readable nodes section) do not seem to be within a section of the template. --> <name>Security Considerations</name> <!-- DNE begins --> <t>This section is modeled after the template described inin<xref section="3.7" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t> <t>The "ietf-ac-ntw" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These protocols have to use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref target="RFC8446"/>, and QUIC <xref target="RFC9000"/>) and have to use mutual authentication.</t> <t>The Network Configuration Access Control Model (NACM) <xref target="RFC8341"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.</t> <t>There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e.,config true,"config true", which is the default).TheseAll writable data nodesmayare likely to beconsideredreasonably sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations.Specifically, theThe following subtrees and data nodes have particularsensitivities/vulnerabilities:</t> <dl>sensitivities/vulnerabilities:</t><!-- DNE ends --> <dl spacing="normal" newline="false"> <dt>'specific-provisioning-profiles':</dt> <dd> <t>This container includes a set of sensitive data thatinfluenceinfluences how an AC is delivered. For example, an attacker who has access to these data nodes may be able to manipulate routing policies, QoS policies, or encryption properties. These data nodes are defined with "nacm:default-deny- write" tagging <xreftarget="I-D.ietf-opsawg-teas-common-ac"/>.</t>target="RFC9833"/>.</t> </dd> <dt>'ac':</dt> <dd> <t>An attacker who is able to access network nodes can undertake various attacks, such as modify the attributes of an AC (e.g., QoS, bandwidth, routing protocols, keying material), leading to malfunctioning of services that are delivered over that AC and therefore to Service Level Agreement (SLA) violations. In addition, an attacker could attempt to add a new AC.: In addition toBy also using NACM to prevent unauthorized access, such activity can be detected by adequately monitoring and tracking network configuration changes.</t> </dd> </dl> <!-- DNE begins --> <t>Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particularsensitivities/vulnerabilities:</t> <dl>sensitivities/vulnerabilities:</t><!-- DNE ends --> <dl spacing="normal" newline="false"> <dt>'ac':</dt> <dd> <t>Unauthorized access to this subtree can disclose the identity of a customer 'peer-sap-id'.</t> </dd> <dt>'l2-connection' and 'ip-connection':</dt> <dd> <t>An attacker can retrieve privacy-related information, which can be used to track a customer. Disclosing such information may be considered a violation of the customer-provider trust relationship.</t> </dd> <dt>'keying-material' and 'customer-key-chain':</dt> <dd> <t>An attacker can retrieve the cryptographic keys protecting an AC (routing, in particular). These keys could be used to inject spoofed routing advertisements.</t> </dd> </dl> <t>Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-chain') rely upon <xref target="RFC8177"/> for authentication purposes. As such, the AC network module inherits the security considerations discussed in <xref section="5" sectionFormat="of" target="RFC8177"/>. Also, these data nodes support supplying explicit keys as strings in ASCII format. The use of keys in hexadecimal string format would afford greater key entropy with the same number of key-string octets. However, such a format is not included in this version of the AC network model, because it is not supported by the underlying device modules (e.g., <xref target="RFC8695"/>).</t> <t><xref target="sec-sec"/> specifies thetheencryption to be applied to traffic for a given AC.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>IANAis requested to registerhas registered the following URI in the "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688"/>:</t><artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-ac-ntw Registrant Contact: The IESG. XML: N/A;<dl spacing="compact" newline="false"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-ntw</dd> <dt>Registrant Contact:</dt><dd>The IESG.</dd> <dt>XML:</dt><dd>N/A; the requested URI is an XMLnamespace. ]]></artwork>namespace.</dd> </dl> <t>IANAis requested to registerhas registered the following YANG module in the "YANG Module Names"subregistryregistry <xref target="RFC6020"/> within the "YANG Parameters"registry:</t> <artwork><![CDATA[ Name: ietf-ac-ntw Namespace: urn:ietf:params:xml:ns:yang:ietf-ac-ntw Prefix: ac-ntw Maintainedregistry group:</t> <dl spacing="compact" newline="false"> <dt>Name:</dt><dd>ietf-ac-ntw</dd> <dt>Maintained byIANA? N Reference: RFC XXXX ]]></artwork>IANA?</dt><dd>N</dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-ntw</dd> <dt>Prefix:</dt><dd>ac-ntw</dd> <dt>Reference:</dt><dd>RFC 9835</dd> </dl> </section> </middle> <back> <displayreference target="I-D.ietf-netmod-rfc8407bis" to ="YANG-GUIDELINES"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> <referenceanchor="IEEE802.1Qcp" target="https://doi.org/10.1109/IEEESTD.2018.8467507">anchor="IEEE802.1Qcp"> <front> <title>IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks--Amendment 30: YANG Data Model</title> <author> <organization>IEEE</organization> </author> <date year="2018" month="September"/> </front> <seriesInfo name="IEEE Std" value="802.1Qcp-2018"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8467507"/> </reference> <!-- [RFC9834] companion doc RFC9834 - draft-ietf-opsawg-teas-attachment-circuit-20 RFC Ed Queue as of 03/03/25. --> <referenceanchor="I-D.ietf-opsawg-teas-attachment-circuit">anchor="RFC9834" target="https://www.rfc-editor.org/info/rfc9834"> <front> <title>YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)</title> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair"initials="M." surname="Boucadair">role="editor"> <organization>Orange</organization> </author> <author initials="R." surname="Roberts" fullname="Richard Roberts"initials="R." surname="Roberts">role="editor"> <organization>Juniper</organization> </author> <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez deDios" initials="O. G." surname="deDios"> <organization>Telefonica</organization> </author> <authorfullname="Samier Barguil"initials="S."surname="Barguil">surname="Barguil" fullname="Samier Barguil"> <organization>Nokia</organization> </author> <authorfullname="Bo Wu"initials="B."surname="Wu">surname="Wu" fullname="Bo Wu"> <organization>Huawei Technologies</organization> </author> <dateday="23" month="January" year="2025"/> <abstract> <t> Delivery of network services assumes that appropriate setup is provisioned over the links that connect customer termination points and a provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC), while the underlying link is referred to as "bearer". This document specifies a YANG service data model for ACs. This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a YANG service model for managing bearers over which ACs are established. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-attachment-circuit-20"/> </reference> <reference anchor="RFC9291"> <front> <title>A YANG Network Data Model for Layer 2 VPNs</title> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="O. Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"/> <author fullname="S. Barguil" initials="S." surname="Barguil"/> <author fullname="L. Munoz" initials="L." surname="Munoz"/> <date month="September" year="2022"/> <abstract> <t>This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices.</t> <t>Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types.</t> </abstract> </front> <seriesInfo name="RFC" value="9291"/> <seriesInfo name="DOI" value="10.17487/RFC9291"/> </reference> <reference anchor="RFC9182"> <front> <title>A YANG Network Data Model for Layer 3 VPNs</title> <author fullname="S. Barguil" initials="S." surname="Barguil"/> <author fullname="O. Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"/> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="L. Munoz" initials="L." surname="Munoz"/> <author fullname="A. Aguado" initials="A." surname="Aguado"/> <date month="February" year="2022"/> <abstract> <t>As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services.</t> <t>The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator.</t> </abstract> </front> <seriesInfo name="RFC" value="9182"/> <seriesInfo name="DOI" value="10.17487/RFC9182"/> </reference> <reference anchor="RFC8345"> <front> <title>A YANG Data Model for Network Topologies</title> <author fullname="A. Clemm" initials="A." surname="Clemm"/> <author fullname="J. Medved" initials="J." surname="Medved"/> <author fullname="R. Varga" initials="R." surname="Varga"/> <author fullname="N. Bahadur" initials="N." surname="Bahadur"/> <author fullname="H. Ananthakrishnan" initials="H." surname="Ananthakrishnan"/> <author fullname="X. Liu" initials="X." surname="Liu"/> <date month="March" year="2018"/> <abstract> <t>This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.</t> </abstract>month='August' year='2025'/> </front> <seriesInfo name="RFC"value="8345"/>value="9834"/> <seriesInfo name="DOI"value="10.17487/RFC8345"/>value="10.17487/RFC9834"/> </reference><reference anchor="RFC9408"> <front> <title>A YANG Network Data Model for Service Attachment Points (SAPs)</title> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/> <author fullname="S. Barguil" initials="S." surname="Barguil"/> <author fullname="Q. Wu" initials="Q." surname="Wu"/> <author fullname="V. Lopez" initials="V." surname="Lopez"/> <date month="June" year="2023"/> <abstract> <t>This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks).</t> <t>This document augments the 'ietf-network' data model defined in<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9291.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9182.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8345.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9408.xml"/> <!-- [RFC9833] companion doc RFC9833 draft-ietf-opsawg-teas-common-ac-15 RFC8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, suchEd Queue asLayer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are supported in the SAP data model.</t> </abstract> </front> <seriesInfo name="RFC" value="9408"/> <seriesInfo name="DOI" value="10.17487/RFC9408"/> </reference>of 03/03/25. --> <referenceanchor="I-D.ietf-opsawg-teas-common-ac">anchor="RFC9833" target="https://www.rfc-editor.org/info/rfc9833"> <front> <title>A Common YANG Data Model for Attachment Circuits</title> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair"initials="M." surname="Boucadair">role="editor"> <organization>Orange</organization> </author> <author initials="R." surname="Roberts" fullname="Richard Roberts"initials="R." surname="Roberts">role="editor"> <organization>Juniper</organization> </author> <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez deDios" initials="O. G." surname="deDios"> <organization>Telefonica</organization> </author> <authorfullname="Samier Barguil"initials="S."surname="Barguil">surname="Barguil Giraldo" fullname="Samier Barguil Giraldo"> <organization>Nokia</organization> </author> <authorfullname="Bo Wu"initials="B."surname="Wu">surname="Wu" fullname="Bo Wu"> <organization>Huawei Technologies</organization> </author> <dateday="23" month="January" year="2025"/> <abstract> <t> The document specifies a common attachment circuits (ACs) YANG model, which is designed to be reusable by other models. This design is meant to ensure consistent AC structures among models that manipulate ACs. For example, this common model can be reused by service models to expose ACs as a service, service models that require binding a service to a set of ACs, network and device models to provision ACs, etc. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-common-ac-15"/> </reference> <reference anchor="RFC7950"> <front> <title>The YANG 1.1 Data Modeling Language</title> <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/> <date month="August" year="2016"/> <abstract> <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t> </abstract> </front> <seriesInfo name="RFC" value="7950"/> <seriesInfo name="DOI" value="10.17487/RFC7950"/> </reference> <reference anchor="RFC8342"> <front> <title>Network Management Datastore Architecture (NMDA)</title> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/> <author fullname="P. Shafer" initials="P." surname="Shafer"/> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <author fullname="R. Wilton" initials="R." surname="Wilton"/> <date month="March" year="2018"/> <abstract> <t>Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.</t> </abstract> </front> <seriesInfo name="RFC" value="8342"/> <seriesInfo name="DOI" value="10.17487/RFC8342"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC8343"> <front> <title>A YANG Data Model for Interface Management</title> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <date month="March" year="2018"/> <abstract> <t>This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).</t> <t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</t> <t>This document obsoletes RFC 7223.</t> </abstract> </front> <seriesInfo name="RFC" value="8343"/> <seriesInfo name="DOI" value="10.17487/RFC8343"/> </reference> <reference anchor="RFC6991"> <front> <title>Common YANG Data Types</title> <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/> <date month="July" year="2013"/> <abstract> <t>This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.</t> </abstract>month='August' year='2025'/> </front> <seriesInfo name="RFC"value="6991"/>value="9833"/> <seriesInfo name="DOI"value="10.17487/RFC6991"/> </reference> <reference anchor="RFC8177"> <front> <title>YANG Data Model for Key Chains</title> <author fullname="A. Lindem" initials="A." role="editor" surname="Lindem"/> <author fullname="Y. Qu" initials="Y." surname="Qu"/> <author fullname="D. Yeung" initials="D." surname="Yeung"/> <author fullname="I. Chen" initials="I." surname="Chen"/> <author fullname="J. Zhang" initials="J." surname="Zhang"/> <date month="June" year="2017"/> <abstract> <t>This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated.</t> </abstract> </front> <seriesInfo name="RFC" value="8177"/> <seriesInfo name="DOI" value="10.17487/RFC8177"/> </reference> <reference anchor="RFC8341"> <front> <title>Network Configuration Access Control Model</title> <author fullname="A. Bierman" initials="A." surname="Bierman"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <date month="March" year="2018"/> <abstract> <t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t> <t>This document obsoletes RFC 6536.</t> </abstract> </front> <seriesInfo name="STD" value="91"/> <seriesInfo name="RFC" value="8341"/> <seriesInfo name="DOI" value="10.17487/RFC8341"/> </reference> <reference anchor="RFC8294"> <front> <title>Common YANG Data Types for the Routing Area</title> <author fullname="X. Liu" initials="X." surname="Liu"/> <author fullname="Y. Qu" initials="Y." surname="Qu"/> <author fullname="A. Lindem" initials="A." surname="Lindem"/> <author fullname="C. Hopps" initials="C." surname="Hopps"/> <author fullname="L. Berger" initials="L." surname="Berger"/> <date month="December" year="2017"/> <abstract> <t>This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area.</t> </abstract> </front> <seriesInfo name="RFC" value="8294"/> <seriesInfo name="DOI" value="10.17487/RFC8294"/> </reference> <reference anchor="RFC9067"> <front> <title>A YANG Data Model for Routing Policy</title> <author fullname="Y. Qu" initials="Y." surname="Qu"/> <author fullname="J. Tantsura" initials="J." surname="Tantsura"/> <author fullname="A. Lindem" initials="A." surname="Lindem"/> <author fullname="X. Liu" initials="X." surname="Liu"/> <date month="October" year="2021"/> <abstract> <t>This document defines a YANG data model for configuring and managing routing policies in a vendor-neutral way. The model provides a generic routing policy framework that can be extended for specific routing protocols using the YANG 'augment' mechanism.</t> </abstract> </front> <seriesInfo name="RFC" value="9067"/> <seriesInfo name="DOI" value="10.17487/RFC9067"/> </reference> <reference anchor="RFC9181"> <front> <title>A Common YANG Data Model for Layer 2 and Layer 3 VPNs</title> <author fullname="S. Barguil" initials="S." surname="Barguil"/> <author fullname="O. Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"/> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="Q. Wu" initials="Q." surname="Wu"/> <date month="February" year="2022"/> <abstract> <t>This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN network models.</t> </abstract> </front> <seriesInfo name="RFC" value="9181"/> <seriesInfo name="DOI" value="10.17487/RFC9181"/> </reference> <reference anchor="RFC4364"> <front> <title>BGP/MPLS IP Virtual Private Networks (VPNs)</title> <author fullname="E. Rosen" initials="E." surname="Rosen"/> <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/> <date month="February" year="2006"/> <abstract> <t>This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4364"/> <seriesInfo name="DOI" value="10.17487/RFC4364"/> </reference> <reference anchor="RFC5880"> <front> <title>Bidirectional Forwarding Detection (BFD)</title> <author fullname="D. Katz" initials="D." surname="Katz"/> <author fullname="D. Ward" initials="D." surname="Ward"/> <date month="June" year="2010"/> <abstract> <t>This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5880"/> <seriesInfo name="DOI" value="10.17487/RFC5880"/> </reference> <reference anchor="RFC8077"> <front> <title>Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)</title> <author fullname="L. Martini" initials="L." role="editor" surname="Martini"/> <author fullname="G. Heron" initials="G." role="editor" surname="Heron"/> <date month="February" year="2017"/> <abstract> <t>Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents.</t> <t>This document is a rewrite of RFC 4447 for publication as an Internet Standard.</t> </abstract> </front> <seriesInfo name="STD" value="84"/> <seriesInfo name="RFC" value="8077"/> <seriesInfo name="DOI" value="10.17487/RFC8077"/> </reference> <reference anchor="RFC5701"> <front> <title>IPv6 Address Specific BGP Extended Community Attribute</title> <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/> <date month="November" year="2009"/> <abstract> <t>Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support an IPv6 Address Specific Extended Community. The lack of an IPv6 Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, the IPv6 Address Specific Extended Community, that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. [STANDARDS TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5701"/> <seriesInfo name="DOI" value="10.17487/RFC5701"/> </reference> <reference anchor="RFC4271"> <front> <title>A Border Gateway Protocol 4 (BGP-4)</title> <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/> <author fullname="T. Li" initials="T." role="editor" surname="Li"/> <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/> <date month="January" year="2006"/> <abstract> <t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t> <t>The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t> <t>BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t> <t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4271"/> <seriesInfo name="DOI" value="10.17487/RFC4271"/> </reference> <reference anchor="RFC5925"> <front> <title>The TCP Authentication Option</title> <author fullname="J. Touch" initials="J." surname="Touch"/> <author fullname="A. Mankin" initials="A." surname="Mankin"/> <author fullname="R. Bonica" initials="R." surname="Bonica"/> <date month="June" year="2010"/> <abstract> <t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5925"/> <seriesInfo name="DOI" value="10.17487/RFC5925"/> </reference> <reference anchor="RFC4577"> <front> <title>OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)</title> <author fullname="E. Rosen" initials="E." surname="Rosen"/> <author fullname="P. Psenak" initials="P." surname="Psenak"/> <author fullname="P. Pillay-Esnault" initials="P." surname="Pillay-Esnault"/> <date month="June" year="2006"/> <abstract> <t>Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol.</t> <t>This document updates RFC 4364. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4577"/> <seriesInfo name="DOI" value="10.17487/RFC4577"/> </reference> <reference anchor="RFC6565"> <front> <title>OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol</title> <author fullname="P. Pillay-Esnault" initials="P." surname="Pillay-Esnault"/> <author fullname="P. Moyer" initials="P." surname="Moyer"/> <author fullname="J. Doyle" initials="J." surname="Doyle"/> <author fullname="E. Ertekin" initials="E." surname="Ertekin"/> <author fullname="M. Lundberg" initials="M." surname="Lundberg"/> <date month="June" year="2012"/> <abstract> <t>Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6 VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as PE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6565"/> <seriesInfo name="DOI" value="10.17487/RFC6565"/> </reference> <reference anchor="RFC5709"> <front> <title>OSPFv2 HMAC-SHA Cryptographic Authentication</title> <author fullname="M. Bhatia" initials="M." surname="Bhatia"/> <author fullname="V. Manral" initials="V." surname="Manral"/> <author fullname="M. Fanto" initials="M." surname="Fanto"/> <author fullname="R. White" initials="R." surname="White"/> <author fullname="M. Barnes" initials="M." surname="Barnes"/> <author fullname="T. Li" initials="T." surname="Li"/> <author fullname="R. Atkinson" initials="R." surname="Atkinson"/> <date month="October" year="2009"/> <abstract> <t>This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5709"/> <seriesInfo name="DOI" value="10.17487/RFC5709"/> </reference> <reference anchor="RFC7474"> <front> <title>Security Extension for OSPFv2 When Using Manual Key Management</title> <author fullname="M. Bhatia" initials="M." surname="Bhatia"/> <author fullname="S. Hartman" initials="S." surname="Hartman"/> <author fullname="D. Zhang" initials="D." surname="Zhang"/> <author fullname="A. Lindem" initials="A." role="editor" surname="Lindem"/> <date month="April" year="2015"/> <abstract> <t>The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.</t> <t>This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.</t> </abstract> </front> <seriesInfo name="RFC" value="7474"/> <seriesInfo name="DOI" value="10.17487/RFC7474"/> </reference> <reference anchor="RFC7166"> <front> <title>Supporting Authentication Trailer for OSPFv3</title> <author fullname="M. Bhatia" initials="M." surname="Bhatia"/> <author fullname="V. Manral" initials="V." surname="Manral"/> <author fullname="A. Lindem" initials="A." surname="Lindem"/> <date month="March" year="2014"/> <abstract> <t>Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.</t> <t>The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.</t> </abstract> </front> <seriesInfo name="RFC" value="7166"/> <seriesInfo name="DOI" value="10.17487/RFC7166"/> </reference> <reference anchor="RFC2453"> <front> <title>RIP Version 2</title> <author fullname="G. Malkin" initials="G." surname="Malkin"/> <date month="November" year="1998"/> <abstract> <t>This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="56"/> <seriesInfo name="RFC" value="2453"/> <seriesInfo name="DOI" value="10.17487/RFC2453"/> </reference> <reference anchor="RFC2080"> <front> <title>RIPng for IPv6</title> <author fullname="G. Malkin" initials="G." surname="Malkin"/> <author fullname="R. Minnear" initials="R." surname="Minnear"/> <date month="January" year="1997"/> <abstract> <t>This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in the IPv4 Internet [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2080"/> <seriesInfo name="DOI" value="10.17487/RFC2080"/> </reference> <reference anchor="RFC9568"> <front> <title>Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6</title> <author fullname="A. Lindem" initials="A." surname="Lindem"/> <author fullname="A. Dogra" initials="A." surname="Dogra"/> <date month="April" year="2024"/> <abstract> <t>This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It obsoletes RFC 5798, which previously specified VRRP (version 3). RFC 5798 obsoleted RFC 3768, which specified VRRP (version 2) for IPv4. VRRP specifies an election protocol that dynamically assigns responsibility for a Virtual Router to one of the VRRP Routers on a LAN. The VRRP Router controlling the IPv4 or IPv6 address(es) associated with a Virtual Router is called the Active Router, and it forwards packets routed to these IPv4 or IPv6 addresses. Active Routers are configured with virtual IPv4 or IPv6 addresses, and Backup Routers infer the address family of the virtual addresses being advertised based on the IP protocol version. Within a VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address families are independent of one another and always treated as separate Virtual Router instances. The election process provides dynamic failover in the forwarding responsibility should the Active Router become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup Routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms.</t> </abstract> </front> <seriesInfo name="RFC" value="9568"/> <seriesInfo name="DOI" value="10.17487/RFC9568"/> </reference> <reference anchor="RFC3688"> <front> <title>The IETF XML Registry</title> <author fullname="M. Mealling" initials="M." surname="Mealling"/> <date month="January" year="2004"/> <abstract> <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t> </abstract> </front> <seriesInfo name="BCP" value="81"/> <seriesInfo name="RFC" value="3688"/> <seriesInfo name="DOI" value="10.17487/RFC3688"/> </reference> <reference anchor="RFC6020"> <front> <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title> <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/> <date month="October" year="2010"/> <abstract> <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6020"/> <seriesInfo name="DOI" value="10.17487/RFC6020"/>value="10.17487/RFC9833"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8177.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8294.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9067.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9181.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8077.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5701.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4577.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6565.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5709.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7474.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7166.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2453.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2080.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9568.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4252.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC7665"> <front> <title>Service Function Chaining (SFC) Architecture</title> <author fullname="J. Halpern" initials="J." role="editor" surname="Halpern"/> <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro"/> <date month="October" year="2015"/> <abstract> <t>This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols.</t> </abstract> </front> <seriesInfo name="RFC" value="7665"/> <seriesInfo name="DOI" value="10.17487/RFC7665"/> </reference> <reference anchor="RFC9543"> <front> <title>A Framework for Network Slices in Networks Built from IETF Technologies</title> <author fullname="A. Farrel" initials="A." role="editor" surname="Farrel"/> <author fullname="J. Drake" initials="J." role="editor" surname="Drake"/> <author fullname="R. Rokui" initials="R." surname="Rokui"/> <author fullname="S. Homma" initials="S." surname="Homma"/> <author fullname="K. Makhijani" initials="K." surname="Makhijani"/> <author fullname="L. Contreras" initials="L." surname="Contreras"/> <author fullname="J. Tantsura" initials="J." surname="Tantsura"/> <date month="March" year="2024"/> <abstract> <t>This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context.</t> <t>The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security.</t> <t>This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9543.xml"/> <!-- [RFC9836] draft-ietf-opsawg-ac-lxsm-lxnm-glue-14 IESG State: RFC Ed Queue as ofIETF Network Slices.</t> </abstract> </front> <seriesInfo name="RFC" value="9543"/> <seriesInfo name="DOI" value="10.17487/RFC9543"/> </reference>03/03/25. --> <referenceanchor="I-D.ietf-opsawg-ac-lxsm-lxnm-glue">anchor="RFC9836" target="https://www.rfc-editor.org/info/rfc9836"> <front> <title>A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits</title> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair"initials="M." surname="Boucadair">role="editor"> <organization>Orange</organization> </author> <authorfullname="Richard Roberts"initials="R."surname="Roberts">surname="Roberts" fullname="Richard Roberts"> <organization>Juniper</organization> </author> <authorfullname="Samier Barguil"initials="S."surname="Barguil">surname="Barguil" fullname="Samier Barguil"> <organization>Nokia</organization> </author> <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez deDios" initials="O. G." surname="deDios"> <organization>Telefonica</organization> </author> <dateday="9" month="January" year="2025"/> <abstract> <t> The document specifies a module that updates existing service (i.e., the Layer 2 Service Model (L2SM) and the Layer 3 Service Model (L3SM)) and network (i.e., the Layer 2 Network Model (L2NM) and the Layer 3 Network Model (L3NM)) Virtual Private Network (VPN) modules with the required information to bind specific VPN services to attachment circuits (ACs) that are created using the AC service ("ietf-ac-svc") and network ("ietf-ac-ntw") models. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ac-lxsm-lxnm-glue-13"/> </reference> <reference anchor="RFC8969"> <front> <title>A Framework for Automating Service and Network Management with YANG</title> <author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="D. Lopez" initials="D." surname="Lopez"/> <author fullname="C. Xie" initials="C." surname="Xie"/> <author fullname="L. Geng" initials="L." surname="Geng"/> <date month="January" year="2021"/> <abstract> <t>Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance.</t> <t>This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF.</t> </abstract> </front> <seriesInfo name="RFC" value="8969"/> <seriesInfo name="DOI" value="10.17487/RFC8969"/> </reference> <reference anchor="RFC8340"> <front> <title>YANG Tree Diagrams</title> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/> <date month="March" year="2018"/> <abstract> <t>This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t> </abstract> </front> <seriesInfo name="BCP" value="215"/> <seriesInfo name="RFC" value="8340"/> <seriesInfo name="DOI" value="10.17487/RFC8340"/> </reference> <reference anchor="RFC8466"> <front> <title>A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery</title> <author fullname="B. Wen" initials="B." surname="Wen"/> <author fullname="G. Fioccola" initials="G." role="editor" surname="Fioccola"/> <author fullname="C. Xie" initials="C." surname="Xie"/> <author fullname="L. Jalil" initials="L." surname="Jalil"/> <date month="October" year="2018"/> <abstract> <t>This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.</t> <t>The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624.</t> <t>The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.</t> </abstract> </front> <seriesInfo name="RFC" value="8466"/> <seriesInfo name="DOI" value="10.17487/RFC8466"/> </reference> <reference anchor="RFC8299"> <front> <title>YANG Data Model for L3VPN Service Delivery</title> <author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/> <author fullname="S. Litkowski" initials="S." surname="Litkowski"/> <author fullname="L. Tomotaki" initials="L." surname="Tomotaki"/> <author fullname="K. Ogaki" initials="K." surname="Ogaki"/> <date month="January" year="2018"/> <abstract> <t>This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.</t> <t>This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text.</t> </abstract> </front> <seriesInfo name="RFC" value="8299"/> <seriesInfo name="DOI" value="10.17487/RFC8299"/> </reference> <reference anchor="RFC3644"> <front> <title>Policy Quality of Service (QoS) Information Model</title> <author fullname="Y. Snir" initials="Y." surname="Snir"/> <author fullname="Y. Ramberg" initials="Y." surname="Ramberg"/> <author fullname="J. Strassner" initials="J." surname="Strassner"/> <author fullname="R. Cohen" initials="R." surname="Cohen"/> <author fullname="B. Moore" initials="B." surname="Moore"/> <date month="November" year="2003"/> <abstract> <t>This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies. This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.</t> </abstract> </front> <seriesInfo name="RFC" value="3644"/> <seriesInfo name="DOI" value="10.17487/RFC3644"/> </reference> <reference anchor="RFC4862"> <front> <title>IPv6 Stateless Address Autoconfiguration</title> <author fullname="S. Thomson" initials="S." surname="Thomson"/> <author fullname="T. Narten" initials="T." surname="Narten"/> <author fullname="T. Jinmei" initials="T." surname="Jinmei"/> <date month="September" year="2007"/> <abstract> <t>This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4862"/> <seriesInfo name="DOI" value="10.17487/RFC4862"/> </reference> <reference anchor="RFC9234"> <front> <title>Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages</title> <author fullname="A. Azimov" initials="A." surname="Azimov"/> <author fullname="E. Bogomazov" initials="E." surname="Bogomazov"/> <author fullname="R. Bush" initials="R." surname="Bush"/> <author fullname="K. Patel" initials="K." surname="Patel"/> <author fullname="K. Sriram" initials="K." surname="Sriram"/> <date month="May" year="2022"/> <abstract> <t>Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.</t> </abstract> </front> <seriesInfo name="RFC" value="9234"/> <seriesInfo name="DOI" value="10.17487/RFC9234"/> </reference> <reference anchor="RFC4552"> <front> <title>Authentication/Confidentiality for OSPFv3</title> <author fullname="M. Gupta" initials="M." surname="Gupta"/> <author fullname="N. Melam" initials="N." surname="Melam"/> <date month="June" year="2006"/> <abstract> <t>This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4552"/> <seriesInfo name="DOI" value="10.17487/RFC4552"/> </reference> <reference anchor="RFC9127"> <front> <title>YANG Data Model for Bidirectional Forwarding Detection (BFD)</title> <author fullname="R. Rahman" initials="R." role="editor" surname="Rahman"/> <author fullname="L. Zheng" initials="L." role="editor" surname="Zheng"/> <author fullname="M. Jethanandani" initials="M." role="editor" surname="Jethanandani"/> <author fullname="S. Pallagatti" initials="S." surname="Pallagatti"/> <author fullname="G. Mirsky" initials="G." surname="Mirsky"/> <date month="October" year="2021"/> <abstract> <t>This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).</t> <t>The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) (RFC 8342).</t> </abstract> </front> <seriesInfo name="RFC" value="9127"/> <seriesInfo name="DOI" value="10.17487/RFC9127"/> </reference> <reference anchor="RFC7880"> <front> <title>Seamless Bidirectional Forwarding Detection (S-BFD)</title> <author fullname="C. Pignataro" initials="C." surname="Pignataro"/> <author fullname="D. Ward" initials="D." surname="Ward"/> <author fullname="N. Akiya" initials="N." surname="Akiya"/> <author fullname="M. Bhatia" initials="M." surname="Bhatia"/> <author fullname="S. Pallagatti" initials="S." surname="Pallagatti"/> <date month="July" year="2016"/> <abstract> <t>This document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.</t> <t>This document updates RFC 5880.</t> </abstract> </front> <seriesInfo name="RFC" value="7880"/> <seriesInfo name="DOI" value="10.17487/RFC7880"/> </reference> <reference anchor="I-D.ietf-netmod-rfc8407bis"> <front> <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title> <author fullname="Andy Bierman" initials="A." surname="Bierman"> <organization>YumaWorks</organization> </author> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <organization>Orange</organization> </author> <author fullname="Qin Wu" initials="Q." surname="Wu"> <organization>Huawei</organization> </author> <date day="14" month="January" year="2025"/> <abstract> <t> This memo provides guidelines for authors and reviewers of specifications containing YANG modules, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. The document also updates RFC 6020 by clarifying how modules and their revisions are handled by IANA. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis-22"/> </reference> <reference anchor="RFC6241"> <front> <title>Network Configuration Protocol (NETCONF)</title> <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/> <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/> <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/> <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/> <date month="June" year="2011"/> <abstract> <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6241"/> <seriesInfo name="DOI" value="10.17487/RFC6241"/> </reference> <reference anchor="RFC8040"> <front> <title>RESTCONF Protocol</title> <author fullname="A. Bierman" initials="A." surname="Bierman"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <date month="January" year="2017"/> <abstract> <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t> </abstract> </front> <seriesInfo name="RFC" value="8040"/> <seriesInfo name="DOI" value="10.17487/RFC8040"/> </reference> <reference anchor="RFC4252"> <front> <title>The Secure Shell (SSH) Authentication Protocol</title> <author fullname="T. Ylonen" initials="T." surname="Ylonen"/> <author fullname="C. Lonvick" initials="C." role="editor" surname="Lonvick"/> <date month="January" year="2006"/> <abstract> <t>The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4252"/> <seriesInfo name="DOI" value="10.17487/RFC4252"/> </reference> <reference anchor="RFC8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <datemonth="August"year="2018"/> <abstract> <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="RFC9000"> <front> <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/> <date month="May" year="2021"/> <abstract> <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t> </abstract>year="2025" /> </front> <seriesInfo name="RFC"value="9000"/>value="9836" /> <seriesInfo name="DOI"value="10.17487/RFC9000"/>value="10.17487/RFC9836"/> </reference><reference anchor="RFC8695"> <front> <title>A YANG Data Model for the Routing Information Protocol (RIP)</title> <author fullname="X. Liu" initials="X." surname="Liu"/> <author fullname="P. Sarda" initials="P." surname="Sarda"/> <author fullname="V. Choudhary" initials="V." surname="Choudhary"/> <date month="February" year="2020"/> <abstract> <t>This document describes a data model for the management<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8969.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8466.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8299.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3644.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9234.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4552.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9127.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7880.xml"/> <!-- [I-D.ietf-netmod-rfc8407bis] draft-ietf-netmod-rfc8407bis-22 IESG State: Publication Requested as ofthe Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. The data model includes definitions for configuration, operational state, and Remote Procedure Calls (RPCs).</t> <t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA).</t> </abstract> </front> <seriesInfo name="RFC" value="8695"/> <seriesInfo name="DOI" value="10.17487/RFC8695"/> </reference>03/03/25. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-rfc8407bis.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8695.xml"/> </references> </references><?line 4195?><section anchor="sec-examples"> <name>Examples</name> <section anchor="vpls"> <name>VPLS</name> <t>Let us consider the example depicted in <xref target="ex-topo"/> with two customer terminating points (CE1 and CE2). Let us also assume that the bearers to attach these CEs to the provider network are already in place. References totheidentify these bearers are shown in the figure.</t> <figure anchor="ex-topo"> <name>Topology Example</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="128" width="488" viewBox="0 0 488 128" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,64 L 8,80" fill="none" stroke="black"/> <path d="M 48,48 L 48,64" fill="none" stroke="black"/> <path d="M 80,72 L 80,96" fill="none" stroke="black"/> <path d="M 104,32 L 104,80" fill="none" stroke="black"/> <path d="M 152,32 L 152,80" fill="none" stroke="black"/> <path d="M 184,32 L 184,112" fill="none" stroke="black"/> <path d="M 304,32 L 304,112" fill="none" stroke="black"/> <path d="M 336,32 L 336,80" fill="none" stroke="black"/> <path d="M 384,32 L 384,80" fill="none" stroke="black"/> <path d="M 416,72 L 416,96" fill="none" stroke="black"/> <path d="M 440,64 L 440,80" fill="none" stroke="black"/> <path d="M 480,48 L 480,64" fill="none" stroke="black"/> <path d="M 104,32 L 152,32" fill="none" stroke="black"/> <path d="M 184,32 L 304,32" fill="none" stroke="black"/> <path d="M 336,32 L 384,32" fill="none" stroke="black"/> <path d="M 24,48 L 48,48" fill="none" stroke="black"/> <path d="M 152,46 L 184,46" fill="none" stroke="black"/> <path d="M 152,50 L 184,50" fill="none" stroke="black"/> <path d="M 304,46 L 336,46" fill="none" stroke="black"/> <path d="M 304,50 L 336,50" fill="none" stroke="black"/> <path d="M 456,48 L 480,48" fill="none" stroke="black"/> <path d="M 48,64 L 104,64" fill="none" stroke="black"/> <path d="M 384,64 L 440,64" fill="none" stroke="black"/> <path d="M 8,80 L 32,80" fill="none" stroke="black"/> <path d="M 104,80 L 152,80" fill="none" stroke="black"/> <path d="M 336,80 L 384,80" fill="none" stroke="black"/> <path d="M 440,80 L 464,80" fill="none" stroke="black"/> <path d="M 184,112 L 304,112" fill="none" stroke="black"/> <path d="M 24,48 C 15.16936,48 8,55.16936 8,64" fill="none" stroke="black"/> <path d="M 456,48 C 447.16936,48 440,55.16936 440,64" fill="none" stroke="black"/> <path d="M 32,80 C 40.83064,80 48,72.83064 48,64" fill="none" stroke="black"/> <path d="M 464,80 C 472.83064,80 480,72.83064 480,64" fill="none" stroke="black"/> <polygon class="arrowhead" points="424,72 412,66.4 412,77.6" fill="black" transform="rotate(270,416,72)"/> <polygon class="arrowhead" points="88,72 76,66.4 76,77.6" fill="black" transform="rotate(270,80,72)"/> <g class="text"> <text x="128" y="52">PE1</text> <text x="360" y="52">PE2</text> <text x="32" y="68">CE1</text> <text x="128" y="68">"450"</text> <text x="244" y="68">MPLS</text> <text x="360" y="68">"451"</text> <text x="464" y="68">CE2</text> <text x="244" y="100">Core</text> <text x="80" y="116">Bearer:1234</text> <text x="424" y="116">Bearer:5678</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .-----. .--------------. .-----. .---. | PE1 +===+ +===+ PE2 | .---. | CE1+------+"450"| | MPLS | |"451"+------+ CE2| '---' ^ '-----' | | '-----' ^ '---' | | Core | | Bearer:1234 '--------------' Bearer:5678 ]]></artwork> </artset> </figure> <t>The AC service model <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>target="RFC9834"/> can be used by the provider to manage and expose the ACs over existing bearers as shown in <xref target="ex-ac"/>.</t> <figure anchor="ex-ac"> <name>ACs Created Using ACaaS</name><artwork><![CDATA[<sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac-group-profile": [ { "name": "an-ac-profile", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "tag-type": "ietf-vpn-common:c-vlan", "cvlan-id": 550 } } }, "service": { "mtu": 1550, "svc-pe-to-ce-bandwidth": { "bandwidth": [ { "bw-type": "ietf-vpn-common:bw-per-port", "cir": "20480000" } ] }, "svc-ce-to-pe-bandwidth": { "bandwidth": [ { "bw-type": "ietf-vpn-common:bw-per-port", "cir": "20480000" } ] }, "qos": { "qos-profiles": { "qos-profile": [ { "profile": "QoS_Profile_A", "direction": "ietf-vpn-common:both" } ] } } } } ], "ac": [ { "name": "ac-1", "description": "First attachment", "ac-group-profile": [ "an-ac-profile" ], "l2-connection": { "bearer-reference": "1234" } }, { "name": "ac-2", "description": "Second attachment", "ac-group-profile": [ "an-ac-profile" ], "l2-connection": { "bearer-reference": "5678" } } ] } }]]></artwork>]]></sourcecode> </figure> <t>The provisioned AC at PE1 can be retrieved using the AC network model as depicted in <xref target="ex-acntw-query"/>. A similar query can be used for the AC at PE2.</t> <figure anchor="ex-acntw-query"> <name>Example of AC Network Response (Message Body)</name><artwork><![CDATA[<sourcecode type="json"><![CDATA[ { "ietf-ac-ntw:ac":[ { "name":"ac-11", "svc-ref":"ac-1", "peer-sap-id":[ "ce-1" ], "status":{ "admin-status":{ "status":"ietf-vpn-common:admin-up" }, "oper-status":{ "status":"ietf-vpn-common:op-up" } }, "l2-connection":{ "encapsulation":{ "encap-type":"ietf-vpn-common:dot1q", "dot1q":{ "tag-type":"ietf-vpn-common:c-vlan", "cvlan-id":550 } }, "bearer-reference":"1234" }, "service":{ "mtu":1550, "svc-pe-to-ce-bandwidth":{ "bandwidth":[ { "bw-type": "ietf-vpn-common:bw-per-port", "cir":"20480000" } ] }, "svc-ce-to-pe-bandwidth":{ "bandwidth":[ { "bw-type": "ietf-vpn-common:bw-per-port", "cir":"20480000" } ] }, "qos":{ "qos-profiles":{ "qos-profile":[ { "qos-profile-ref":"QoS_Profile_A", "network-ref":"example:an-id", "direction":"ietf-vpn-common:both" } ] } } } } ] }]]></artwork>]]></sourcecode> </figure> <t>Also, the AC network model can be used to retrieve the list of SAPs to which the ACs are bound as shown in <xref target="ex-acntw-query"/>.</t> <figure anchor="ex-acntw-query-2"> <name>Example of AC Network Response to Retrieve the SAP (Message Body)</name><artwork><![CDATA[<sourcecode type="json"><![CDATA[ { "ietf-sap-ntw:service":[ { "service-type":"ietf-vpn-common:vpls", "sap":[ { "sap-id":"sap#1", "peer-sap-id":[ "ce-1" ], "description":"A parent SAP", "attachment-interface":"GE0/6/1", "interface-type":"ietf-sap-ntw:phy", "role":"ietf-sap-ntw:uni", "allows-child-saps":true, "sap-status":{ "status":"ietf-vpn-common:op-up" } }, { "sap-id":"sap#11", "description":"A child SAP", "parent-termination-point":"GE0/6/4", "attachment-interface":"GE0/6/4.2", "interface-type":"ietf-sap-ntw:logical", "encapsulation-type":"ietf-vpn-common:vlan-type", "sap-status":{ "status":"ietf-vpn-common:op-up" }, "ietf-ac-ntw:ac":[ { "ac-ref":"ac-1", "node-ref":"example:pe2", "network-ref":"example:an-id" } ] } ] } ] }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="parent-ac"> <name>Parent AC</name> <t>In reference to the topology depicted in <xref target="sap-ac-ntw"/>, PE2 has a SAPwhichthat terminates an AC with two peer SAPs (CE2 and CE5). In order to control data that is specific to each of these peer SAPs over the same AC, child ACs can be instantiated as depicted in <xref target="ex-parent-ac"/>.</t> <figure anchor="ex-parent-ac"> <name>Example of Child ACs</name><artwork><![CDATA[<sourcecode type="json"><![CDATA[ { "ietf-ac-ntw:ac":[ { "name":"ac-1", "peer-sap-id":[ "CE2", "CE5" ], "status":{ "admin-status":{ "status":"ietf-vpn-common:admin-up" }, "oper-status":{ "status":"ietf-vpn-common:op-up" } }, "l2-connection":{ "encapsulation":{ "encap-type":"ietf-vpn-common:dot1q", "dot1q":{ "tag-type":"ietf-vpn-common:c-vlan", "cvlan-id":550 } }, "bearer-reference":"1234" } }, { "name":"ac-1-to-ce2", "parent-ref":{ "ac-ref":"ac-1", "node-ref":"example:pe2", "network-ref":"example:an-id" }, "peer-sap-id":[ "CE2" ] }, { "name":"ac-1-to-ce5", "parent-ref":{ "ac-ref":"ac-1", "node-ref":"example:pe2", "network-ref":"example:an-id" }, "peer-sap-id":[ "CE5" ] } ] }]]></artwork>]]></sourcecode> </figure> <t><xref target="ex-parent-ac-sap"/> shows how to bind the parent AC to a SAP.</t> <figure anchor="ex-parent-ac-sap"> <name>Example of Binding ParentACACs to SAPs</name><artwork><![CDATA[<sourcecode type="json"><![CDATA[ { "ietf-sap-ntw:service":[ { "service-type":"ietf-vpn-common:l3vpn", "sap":[ { "sap-id":"sap#14587", "description":"A SAP", "parent-termination-point":"GE0/6/4", "attachment-interface":"GE0/6/4.2", "interface-type":"ietf-sap-ntw:logical", "encapsulation-type":"ietf-vpn-common:vlan-type", "sap-status":{ "status":"ietf-vpn-common:op-up" }, "ietf-ac-ntw:ac":[ { "ac-ref":"ac-1", "node-ref":"example:pe2", "network-ref":"example:an-id" } ] } ] } ] }]]></artwork>]]></sourcecode> </figure> </section> </section> <section anchor="AC-Ntw-Tree"> <name>Full Tree</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-ac-ntw augment /nw:networks/nw:network: +--rw specific-provisioning-profiles | +--rw valid-provider-identifiers | +--rw encryption-profile-identifier* [id] | | +--rw id string | +--rw qos-profile-identifier* [id] | | +--rw id string | +--rw failure-detection-profile-identifier* [id] | | +--rw id string | +--rw forwarding-profile-identifier* [id] | | +--rw id string | +--rw routing-profile-identifier* [id] | +--rw id string +--rw ac-profile* [name] +--rw name string +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw bgp {vpn-common:rtg-bgp}? | | +--rw peer-groups | | +--rw peer-group* [name] | | +--rw name string | | +--rw description? string | | +--rw apply-policy | | | +--rw import-policy* leafref | | | +--rw default-import-policy? | | | | default-policy-type | | | +--rw export-policy* leafref | | | +--rw default-export-policy? | | | default-policy-type | | +--rw local-as? inet:as-number | | +--rw peer-as inet:as-number | | +--rw address-family? identityref | | +--rw role? identityref | | +--rw multihop? uint8 | | +--rw as-override? boolean | | +--rw allow-own-as? uint8 | | +--rw prepend-global-as? boolean | | +--rw send-default-route? boolean | | +--rw site-of-origin? | | | rt-types:route-origin | | +--rw ipv6-site-of-origin? | | | rt-types:ipv6-route-origin | | +--rw redistribute-connected* [address-family] | | | +--rw address-family identityref | | | +--rw enabled? boolean | | +--rw bgp-max-prefix | | | +--rw max-prefix? uint32 | | | +--rw warning-threshold? decimal64 | | | +--rw violate-action? enumeration | | | +--rw restart-timer? uint32 | | +--rw bgp-timers | | +--rw keepalive? uint16 | | +--rw hold-time? uint16 | +--rw ospf {vpn-common:rtg-ospf}? | | +--rw address-family? identityref | | +--rw area-id yang:dotted-quad | | +--rw metric? uint16 | | +--rw max-lsa? uint32 | | +--rw passive? boolean | +--rw isis {vpn-common:rtg-isis}? | | +--rw address-family? identityref | | +--rw area-address area-address | | +--rw level? identityref | | +--rw metric? uint32 | | +--rw passive? boolean | +--rw rip {vpn-common:rtg-rip}? | | +--rw address-family? identityref | | +--rw timers | | | +--rw update-interval? uint16 | | | +--rw invalid-interval? uint16 | | | +--rw holddown-interval? uint16 | | | +--rw flush-interval? uint16 | | +--rw default-metric? uint8 | +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw address-family? identityref | +--rw ping-reply? boolean +--rw oam +--rw bfd {vpn-common:bfd}? +--rw session-type? identityref +--rw desired-min-tx-interval? uint32 +--rw required-min-rx-interval? uint32 +--rw local-multiplier? uint8 +--rw holdtime? uint32 augment /nw:networks/nw:network/nw:node: +--rw ac* [name] +--rw name string +--rw svc-ref? ac-svc:attachment-circuit-reference +--rw profile* [ac-profile-ref] | +--rw ac-profile-ref leafref | +--rw network-ref? -> /nw:networks/network/network-id +--rw parent-ref | +--rw ac-ref? leafref | +--rw node-ref? leafref | +--rw network-ref? -> /nw:networks/network/network-id +--ro child-ref | +--ro ac-ref* leafref | +--ro node-ref? leafref | +--ro network-ref? -> /nw:networks/network/network-id +--rw peer-sap-id* string +--rw group* [group-id] | +--rw group-id string | +--rw precedence? identityref +--rw status | +--rw admin-status | | +--rw status? identityref | | +--ro last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref | +--ro last-change? yang:date-and-time +--rw description? string +--rw l2-connection {ac-common:layer2-ac}? | +--rw encapsulation | | +--rw encap-type? identityref | | +--rw dot1q | | | +--rw tag-type? identityref | | | +--rw cvlan-id? uint16 | | | +--rw tag-operations | | | +--rw (op-choice)? | | | | +--:(pop) | | | | | +--rw pop? empty | | | | +--:(push) | | | | | +--rw push? empty | | | | +--:(translate) | | | | +--rw translate? empty | | | +--rw tag-1? dot1q-types:vlanid | | | +--rw tag-1-type? dot1q-types:dot1q-tag-type | | | +--rw tag-2? dot1q-types:vlanid | | | +--rw tag-2-type? dot1q-types:dot1q-tag-type | | +--rw priority-tagged | | | +--rw tag-type? identityref | | +--rw qinq | | +--rw tag-type? identityref | | +--rw svlan-id? uint16 | | +--rw cvlan-id? uint16 | | +--rw tag-operations | | +--rw (op-choice)? | | | +--:(pop) | | | | +--rw pop? uint8 | | | +--:(push) | | | | +--rw push? empty | | | +--:(translate) | | | +--rw translate? uint8 | | +--rw tag-1? dot1q-types:vlanid | | +--rw tag-1-type? dot1q-types:dot1q-tag-type | | +--rw tag-2? dot1q-types:vlanid | | +--rw tag-2-type? dot1q-types:dot1q-tag-type | +--rw (l2-service)? | | +--:(l2-tunnel-service) | | | +--rw l2-tunnel-service | | | +--rw type? identityref | | | +--rw pseudowire | | | | +--rw vcid? uint32 | | | | +--rw far-end? union | | | +--rw vpls | | | | +--rw vcid? uint32 | | | | +--rw far-end* union | | | +--rw vxlan | | | +--rw vni-id? uint32 | | | +--rw peer-mode? identityref | | | +--rw peer-ip-address* inet:ip-address | | +--:(l2vpn) | | +--rw l2vpn-id? vpn-common:vpn-id | +--rw l2-termination-point? string | +--rw local-bridge-reference? string | +--rw bearer-reference? string | | {ac-common:server-assigned-reference}? | +--rw lag-interface {vpn-common:lag-interface}? | +--rw lag-interface-id? string | +--rw member-link-list | +--rw member-link* [name] | +--rw name string +--rw ip-connection {ac-common:layer3-ac}? | +--rw l3-termination-point? string | +--rw ipv4 {vpn-common:ipv4}? | | +--rw local-address? | | | inet:ipv4-address | | +--rw prefix-length? uint8 | | +--rw address-allocation-type? | | | identityref | | +--rw (allocation-type)? | | +--:(dynamic) | | | +--rw (address-assign)? | | | | +--:(number) | | | | | +--rw number-of-dynamic-address? uint16 | | | | +--:(explicit) | | | | +--rw customer-addresses | | | | +--rw address-pool* [pool-id] | | | | +--rw pool-id string | | | | +--rw start-address | | | | | inet:ipv4-address | | | | +--rw end-address? | | | | inet:ipv4-address | | | +--rw (provider-dhcp)? | | | | +--:(dhcp-service-type) | | | | | +--rw dhcp-service-type? | | | | | enumeration | | | | +--:(service-type) | | | | +--rw (service-type)? | | | | +--:(relay) | | | | +--rw server-ip-address* | | | | inet:ipv4-address | | | +--rw (dhcp-relay)? | | | +--:(customer-dhcp-servers) | | | +--rw customer-dhcp-servers | | | +--rw server-ip-address* | | | inet:ipv4-address | | +--:(static-addresses) | | +--rw address* [address-id] | | +--rw address-id string | | +--rw customer-address? | | | inet:ipv4-address | | +--rw failure-detection-profile-ref? leafref | | +--rw network-ref? | | -> /nw:networks/network/network-id | +--rw ipv6 {vpn-common:ipv6}? | +--rw local-address? | | inet:ipv6-address | +--rw prefix-length? uint8 | +--rw address-allocation-type? | | identityref | +--rw (allocation-type)? | +--:(dynamic) | | +--rw (address-assign)? | | | +--:(number) | | | | +--rw number-of-dynamic-address? uint16 | | | +--:(explicit) | | | +--rw customer-addresses | | | +--rw address-pool* [pool-id] | | | +--rw pool-id string | | | +--rw start-address | | | | inet:ipv6-address | | | +--rw end-address? | | | inet:ipv6-address | | +--rw (provider-dhcp)? | | | +--:(dhcp-service-type) | | | | +--rw dhcp-service-type? | | | | enumeration | | | +--:(service-type) | | | +--rw (service-type)? | | | +--:(relay) | | | +--rw server-ip-address* | | | inet:ipv6-address | | +--rw (dhcp-relay)? | | +--:(customer-dhcp-servers) | | +--rw customer-dhcp-servers | | +--rw server-ip-address* | | inet:ipv6-address | +--:(static-addresses) | +--rw address* [address-id] | +--rw address-id string | +--rw customer-address? | | inet:ipv6-address | +--rw failure-detection-profile-ref? leafref | +--rw network-ref? | -> /nw:networks/network/network-id +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profile* [routing-profile-ref] | | +--rw routing-profile-ref leafref | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw type? identityref | +--rw static | | +--rw cascaded-lan-prefixes | | +--rw ipv4-lan-prefix* [lan next-hop] | | | {vpn-common:ipv4}? | | | +--rw lan inet:ipv4-prefix | | | +--rw lan-tag? string | | | +--rw next-hop union | | | +--rw metric? uint32 | | | +--rw bfd {vpn-common:bfd}? | | | | +--rw enabled? | | | | | boolean | | | | +--rw failure-detection-profile-ref? | | | | | leafref | | | | +--rw network-ref? | | | | -> /nw:networks/network/network-id | | | +--rw preference? uint32 | | | +--rw status | | | +--rw admin-status | | | | +--rw status? identityref | | | | +--ro last-change? yang:date-and-time | | | +--ro oper-status | | | +--ro status? identityref | | | +--ro last-change? yang:date-and-time | | +--rw ipv6-lan-prefix* [lan next-hop] | | {vpn-common:ipv6}? | | +--rw lan inet:ipv6-prefix | | +--rw lan-tag? string | | +--rw next-hop union | | +--rw metric? uint32 | | +--rw bfd {vpn-common:bfd}? | | | +--rw enabled? | | | | boolean | | | +--rw failure-detection-profile-ref? | | | | leafref | | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw preference? uint32 | | +--rw status | | +--rw admin-status | | | +--rw status? identityref | | | +--ro last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref | | +--ro last-change? yang:date-and-time | +--rw bgp {vpn-common:rtg-bgp}? | | +--rw peer-groups | | | +--rw peer-group* [name] | | | +--rw name string | | | +--rw local-address? union | | | +--rw description? string | | | +--rw apply-policy | | | | +--rw import-policy* leafref | | | | +--rw default-import-policy? | | | | | default-policy-type | | | | +--rw export-policy* leafref | | | | +--rw default-export-policy? | | | | default-policy-type | | | +--rw local-as? inet:as-number | | | +--rw peer-as inet:as-number | | | +--rw address-family? identityref | | | +--rw role? identityref | | | +--rw multihop? uint8 | | | +--rw as-override? boolean | | | +--rw allow-own-as? uint8 | | | +--rw prepend-global-as? boolean | | | +--rw send-default-route? boolean | | | +--rw site-of-origin? | | | | rt-types:route-origin | | | +--rw ipv6-site-of-origin? | | | | rt-types:ipv6-route-origin | | | +--rw redistribute-connected* [address-family] | | | | +--rw address-family identityref | | | | +--rw enabled? boolean | | | +--rw bgp-max-prefix | | | | +--rw max-prefix? uint32 | | | | +--rw warning-threshold? decimal64 | | | | +--rw violate-action? enumeration | | | | +--rw restart-timer? uint32 | | | +--rw bgp-timers | | | | +--rw keepalive? uint16 | | | | +--rw hold-time? uint16 | | | +--rw authentication | | | +--rw enabled? boolean | | | +--rw keying-material | | | +--rw (option)? | | | +--:(ao) | | | | +--rw enable-ao? boolean | | | | +--rw ao-keychain? | | | | key-chain:key-chain-ref | | | +--:(md5) | | | | +--rw md5-keychain? | | | | key-chain:key-chain-ref | | | +--:(explicit) | | | +--rw key-id? uint32 | | | +--rw key? string | | | +--rw crypto-algorithm? | | | identityref | | +--rw neighbor* [remote-address] | | +--rw remote-address inet:ip-address | | +--rw local-address? union | | +--rw peer-group? | | | -> ../../peer-groups/peer-group/name | | +--rw description? string | | +--rw apply-policy | | | +--rw import-policy* leafref | | | +--rw default-import-policy? | | | | default-policy-type | | | +--rw export-policy* leafref | | | +--rw default-export-policy? | | | default-policy-type | | +--rw local-as? inet:as-number | | +--rw peer-as inet:as-number | | +--rw address-family? identityref | | +--rw role? identityref | | +--rw multihop? uint8 | | +--rw as-override? boolean | | +--rw allow-own-as? uint8 | | +--rw prepend-global-as? boolean | | +--rw send-default-route? boolean | | +--rw site-of-origin? | | | rt-types:route-origin | | +--rw ipv6-site-of-origin? | | | rt-types:ipv6-route-origin | | +--rw redistribute-connected* [address-family] | | | +--rw address-family identityref | | | +--rw enabled? boolean | | +--rw bgp-max-prefix | | | +--rw max-prefix? uint32 | | | +--rw warning-threshold? decimal64 | | | +--rw violate-action? enumeration | | | +--rw restart-timer? uint32 | | +--rw bgp-timers | | | +--rw keepalive? uint16 | | | +--rw hold-time? uint16 | | +--rw bfd {vpn-common:bfd}? | | | +--rw enabled? boolean | | | +--rw failure-detection-profile-ref? leafref | | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw authentication | | | +--rw enabled? boolean | | | +--rw keying-material | | | +--rw (option)? | | | +--:(ao) | | | | +--rw enable-ao? boolean | | | | +--rw ao-keychain? | | | | key-chain:key-chain-ref | | | +--:(md5) | | | | +--rw md5-keychain? | | | | key-chain:key-chain-ref | | | +--:(explicit) | | | +--rw key-id? uint32 | | | +--rw key? string | | | +--rw crypto-algorithm? identityref | | +--rw status | | +--rw admin-status | | | +--rw status? identityref | | | +--ro last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref | | +--ro last-change? yang:date-and-time | +--rw ospf {vpn-common:rtg-ospf}? | | +--rw address-family? identityref | | +--rw area-id yang:dotted-quad | | +--rw metric? uint16 | | +--rw sham-links {vpn-common:rtg-ospf-sham-link}? | | | +--rw sham-link* [target-site] | | | +--rw target-site string | | | +--rw metric? uint16 | | +--rw max-lsa? uint32 | | +--rw passive? boolean | | +--rw authentication | | | +--rw enabled? boolean | | | +--rw keying-material | | | +--rw (option)? | | | +--:(auth-key-chain) | | | | +--rw key-chain? | | | | key-chain:key-chain-ref | | | +--:(auth-key-explicit) | | | +--rw key-id? uint32 | | | +--rw key? string | | | +--rw crypto-algorithm? identityref | | +--rw status | | +--rw admin-status | | | +--rw status? identityref | | | +--ro last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref | | +--ro last-change? yang:date-and-time | +--rw isis {vpn-common:rtg-isis}? | | +--rw address-family? identityref | | +--rw area-address area-address | | +--rw level? identityref | | +--rw metric? uint32 | | +--rw passive? boolean | | +--rw authentication | | | +--rw enabled? boolean | | | +--rw keying-material | | | +--rw (option)? | | | +--:(auth-key-chain) | | | | +--rw key-chain? | | | | key-chain:key-chain-ref | | | +--:(auth-key-explicit) | | | +--rw key-id? uint32 | | | +--rw key? string | | | +--rw crypto-algorithm? identityref | | +--rw status | | +--rw admin-status | | | +--rw status? identityref | | | +--ro last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref | | +--ro last-change? yang:date-and-time | +--rw rip {vpn-common:rtg-rip}? | | +--rw address-family? identityref | | +--rw timers | | | +--rw update-interval? uint16 | | | +--rw invalid-interval? uint16 | | | +--rw holddown-interval? uint16 | | | +--rw flush-interval? uint16 | | +--rw default-metric? uint8 | | +--rw authentication | | | +--rw enabled? boolean | | | +--rw keying-material | | | +--rw (option)? | | | +--:(auth-key-chain) | | | | +--rw key-chain? | | | | key-chain:key-chain-ref | | | +--:(auth-key-explicit) | | | +--rw key? string | | | +--rw crypto-algorithm? identityref | | +--rw status | | +--rw admin-status | | | +--rw status? identityref | | | +--ro last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref | | +--ro last-change? yang:date-and-time | +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw address-family? identityref | +--rw vrrp-group? uint8 | +--rw backup-peer? inet:ip-address | +--rw virtual-ip-address* inet:ip-address | +--rw priority? uint8 | +--rw ping-reply? boolean | +--rw status | +--rw admin-status | | +--rw status? identityref | | +--ro last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref | +--ro last-change? yang:date-and-time +--rw oam | +--rw bfd {vpn-common:bfd}? | +--rw session* [dest-addr] | +--rw dest-addr inet:ip-address | +--rw source-address? union | +--rw failure-detection-profile-ref? leafref | +--rw network-ref? | | -> /nw:networks/network/network-id | +--rw session-type? identityref | +--rw desired-min-tx-interval? uint32 | +--rw required-min-rx-interval? uint32 | +--rw local-multiplier? uint8 | +--rw holdtime? uint32 | +--rw authentication! | | +--rw key-chain? key-chain:key-chain-ref | | +--rw meticulous? boolean | +--rw status | +--rw admin-status | | +--rw status? identityref | | +--ro last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref | +--ro last-change? yang:date-and-time +--rw security | +--rw encryption {vpn-common:encryption}? | | +--rw enabled? boolean | | +--rw layer? enumeration | +--rw encryption-profile | +--rw (profile)? | +--:(provider-profile) | | +--rw encryption-profile-ref? leafref | | +--rw network-ref? | | -> /nw:networks/network/network-id | +--:(customer-profile) | +--rw customer-key-chain? | key-chain:key-chain-ref +--rw service +--rw mtu? uint32 +--rw svc-pe-to-ce-bandwidth {vpn-common:inbound-bw}? | +--rw bandwidth* [bw-type] | +--rw bw-type identityref | +--rw (type)? | +--:(per-cos) | | +--rw cos* [cos-id] | | +--rw cos-id uint8 | | +--rw cir? uint64 | | +--rw cbs? uint64 | | +--rw eir? uint64 | | +--rw ebs? uint64 | | +--rw pir? uint64 | | +--rw pbs? uint64 | +--:(other) | +--rw cir? uint64 | +--rw cbs? uint64 | +--rw eir? uint64 | +--rw ebs? uint64 | +--rw pir? uint64 | +--rw pbs? uint64 +--rw svc-ce-to-pe-bandwidth {vpn-common:outbound-bw}? | +--rw bandwidth* [bw-type] | +--rw bw-type identityref | +--rw (type)? | +--:(per-cos) | | +--rw cos* [cos-id] | | +--rw cos-id uint8 | | +--rw cir? uint64 | | +--rw cbs? uint64 | | +--rw eir? uint64 | | +--rw ebs? uint64 | | +--rw pir? uint64 | | +--rw pbs? uint64 | +--:(other) | +--rw cir? uint64 | +--rw cbs? uint64 | +--rw eir? uint64 | +--rw ebs? uint64 | +--rw pir? uint64 | +--rw pbs? uint64 +--rw qos {vpn-common:qos}? | +--rw qos-profiles | +--rw qos-profile* [qos-profile-ref] | +--rw qos-profile-ref leafref | +--rw network-ref? | | -> /nw:networks/network/network-id | +--rw direction? identityref +--rw access-control-list +--rw acl-profiles +--rw acl-profile* [forwarding-profile-ref] +--rw forwarding-profile-ref leafref +--rw network-ref? -> /nw:networks/network/network-id augment /nw:networks/nw:network/nw:node/sap:service/sap:sap: +--rw ac* [ac-ref] +--rw ac-ref leafref +--rw node-ref? leafref +--rw network-ref? -> /nw:networks/network/network-id]]></artwork>]]></sourcecode> </section> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>This document builds on <xref target="RFC9182"/> and <xref target="RFC9291"/>.</t> <t>Thanks toMoti Morgenstern<contact fullname="Moti Morgenstern"/> for the review and comments.</t> <t>Thanks toMartin Björklund<contact fullname="Martin Björklund"/> for theyangdoctorsYANG Doctors review,Gyan Mishra<contact fullname="Gyan Mishra"/> for an earlyrtg-dirRTGDIR review,Joel Halpern<contact fullname="Joel Halpern"/> for thertg-dirRTGDIR review,Giuseppe Fioccola<contact fullname="Giuseppe Fioccola"/> for theops-dirOPSDIR review, andRuss Housley<contact fullname="Russ Housley"/> for thesec-dirSECDIR review.</t> <t>Thanks toKrzysztof Szarkowicz<contact fullname="Krzysztof Szarkowicz"/> for theShepherdshepherd review.</t> <t>Thanks forMahesh Jethanandani<contact fullname="Mahesh Jethanandani"/> for the AD review.</t> </section> <section anchor="contributors" numbered="false"toc="include" removeInRFC="false">toc="include"> <name>Contributors</name> <contact initials="V." surname="Lopez" fullname="Victor Lopez"> <organization>Nokia</organization> <address> <email>victor.lopez@nokia.com</email> </address> </contact> <contact fullname="Ivan Bykov"> <organization>Ribbon Communications</organization> <address> <email>Ivan.Bykov@rbbn.com</email> </address> </contact> <contact fullname="Qin Wu"> <organization>Huawei</organization> <address> <email>bill.wu@huawei.com</email> </address> </contact> <contact fullname="Ogaki Kenichi"> <organization>KDDI</organization> <address> <email>ke-oogaki@kddi.com</email> </address> </contact> <contact fullname="Luis Angel Munoz"> <organization>Vodafone</organization> <address> <email>luis-angel.munoz@vodafone.com</email> </address> </contact> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA+y963IbR5Iw+p8R+w699A+QNgHxJkqiZ8eGKNrDs7pwRNne iY39NhpAk+xRAw13N0jRlr5nOc9ynuzkpbJuXd1okJTtmSFi10MBVVlZWVlZ mVlZmf1+f61Kqyw5jNaH0eukus6L99Hfhq+/j17EVRy9yidJFp3nRTSsqnh8 OU1mVXSUFuNFWpXra/FoVCRX1Jf6CACr2xE0G8dVcpEXN4dRWU3W1ib5eBZP YchJEZ9X/TSpzvv5vIyvL/qz6rof65H6Yx6pv3OwVi5G07Qs03xW3cyh78nx u+/WZovpKCkO1yYwwOHaOJ+VyaxclIdRVSySNUBsby0ukhgQfDNPiriC3mUU zybRq3gWXyQ4xvoaYnxR5It5W7NoCHCin6BpOruIvsfm62vvkxvoPDlci/rR WZaOk+gsKa7gf/GLl3s/nr6mP3bVH8NFlU8JOv5LaOV++6YYXyZlVegvSoYY AUHTq6S4obHUd/Miv0qRJICT3bZMLhDnGozzLPmQjtIsrW6c5ul0nqXn6biG mzWdve9PT52fYL447Fq8qC5zWIP+WgSf80WW8eK+yi/hfyfR83wxjidxWtDv RY68lkzSKucv8uIinqW/0NCHMP14dpHQD8k0TrPDaMpgBiMB821ObQbjfLpW G/RtOr6Mi0n0Nge+qMrACP/PYpbCIttDFAW3/vbv/NtgllR10G/KcVxE3+ez X+Is+QXWI3qR5qER3iVZcg5rMo7tQXLsPrhQ3SdAgbz8ttJNw9M5i6dpUkTP 4+JikWbR92kRZ5M8MObr/H3qDFdSz8GIe/7vBff8dobtwmM9z6OfFgHQf1nE 10kKsxpfzvIsv0iT0h4ogy0yuF6M8m8vqSEDh61YFekIWBs4I4p4LB7nx3QM 30Yv83nyiwwXmMAVNRtk2MxGW4AZxE+u4ln0/OZ9fhXA/m06GuWz6CifThcz xeEO/th7QL2/LUajWdMgf01nbeSxIcIGy4AiDj3qAN9cxO/T6D8TQOoyDcD9 zxcvTmyo75N+nmOfb99PJo1QXy7SMhrC9siiV4tZ/ksA8I/5JAaeczZZBt36 uKuywRS7fXulGvE4s7xACXWV4FqeHB8fP93eHez8dTw/JCBygOAv0VkFghO3 4Dkt8jjOSJJOk6rI5zmIHlgslMnRjAVJ2e8/L9LJRcISl/+eiJiBX4cgyiYk gve2D/2jaZ0QEBGEfyuSKLZClOjfdEKAPJtXCR4Z0e72zlNGHnZIUh1Gl1U1 Lw8fPZrk6QC6PtrZHuzsbD97hBDO3r0YYIfB0/2DJ4+3n6ytpbNzQxPYS/1+ FI9QbI9Bcry7hEWAQ25BWJfzZAzCFecncwahJuejOewiddiVg+jdZaKajIFa oyRalAkTtLp0pX6Un4dAQJsUWsP/TRYFNisDJ0a0kQwuBlsRnE5bjljXx9jm IBpGwAFzYB/YRAKEUYM5ytQmEewORM1bnZJwfp7Aehe8vL2AGtHrx8B8fTnU NoZHcXy2GW2c9F8MbN2gSrBdTTnYHCDFCatFlgAv0NlXEj6juEw00Td6BE39 s7dJCGErGdnC7TRP4b8bZ8PTTZ5uGV2n1SU1nyQVbBqatGICoM0qiwPEOsVm E+DDY+L8jdPjEueBfDRNJ5MsWVv7IjoBGQqTGtOpvHaUz2YJ/H0Fp7csRYlb iceEEyUa3ehdFVV5NF6UoFog6a9YtuKpg7oYTDsppukMUAcs5zjXcisqF+PL KC41Ob5bzMasCv366zdvvzt6cnDw+NOnLQQkkOEgJ/SPAP2taJ7AN6jOzPJp vgBANyXsNjhYCpzp23xRIS4bw7Pnb6H5Gu/KOBoDcfCHC8DsOr4BTICWJ/gd TCY6/gAnOkgmXpJSLTZMeZwAbyc4T01z2GHCo6n9j7lQW++/+AaIMQfBEuUz tW6wdZmik3xeMTHrELYA8DhbTJBu2O08y6+j+aLC8eZZjDpWEyNM4KABnDUO ZgkBi0sAA71uaD1B1UHOzCMUlTX+wQ0CG/M7GCf5EIPmlmzRgHDiJ6HmONfL vIQ/FlmVQnMzshIAL+MblIhwMhfVAuT1aZFewVpombABEmKTVoVb7rHIgH8H pYZil2eP9/c+fQJMT2YRcwDO6CpPJ9YiwSKfJ0UChCEyFLCmcHrMKmdvAW2v YhBowFJZro7wrdDy4lSTD/O8RGgKOq4JDDwlTR7NEVmA/jX0GURHepOgrAVC zgCLnxegg+MIdJhlcBCGKAtgQTbbq78lMgWBnPOUq8u4CvW+toayRHSpwGom oP7DowGQ9d87isRPn5xTh3aZOXKIFDhiSDbFpSEs7LVffy2TcZ9Fqwe101kW bawTvvEYTbv1zVXPNlwv2sq1LdzlhPN2CfClT0DAK/tQTuE/s2n/Ilt4k1wY O6rktUjYnPMs3Y2Xu69fbeIKIePvPtsBMHK6kB1Ya79ntd95ugvtcdlT6PPy A7Sn0XDyzD2FNS+g1qIU+WPk4CQ5T2dyElv6hxKYWh3JErAiY5TazuiIrYM+ ij+UhMQoM8DFXRvQdeBgIgGMGMIilsxnM5ighbaDFm5MGAE0nDPYcrhF4Dc+ ra9BCuCOpQMvIcYf51e43nkFMjq7gX/OrqApjA8iqkmyg1wAoyOKszKXdRyX yEg5UKtQyh6K/iy/4YGVDBxn+ULLZlEpYNIulyNdkzK9wBnFPn/AKKNc6Qiu qqF6M32f7u0/ttiji/IhK7O//fTTJ9DJgseC2k7m8IiQS0Dc45YX0Q8wgfov 0/fJdVqqg6M+New9Br0PfsFzwCYXSC1YqBgB1UZEMWkPhvyryAsbGLgB3ShH NHMUDWD3ZBNshOT+v/CJ4ri8ulDqu/0Z9PuDf6t///Ho+OBj4Pte/6te/et4 HH10QXYaJLJ6wYCPv+rTR/7n6HjXR2FgNRgQOv2eCwq/8Tp9bPgb/xmPV2js Nh18NQj+zf+02g76X5XxXM1K/T0I/cQfu+tHnFBP/5P+/hj8qYahRv70eMf7 zvpp1+6qFs6bTLirOyqs3s5XPLd6i/autITAQL2veoHfW7vqv3v9+qfX8tO/ rTnLU/8MWn4K0bgTykhXmOigCcbp8V4DjNPjffUNcwtsjcfBte6EB7ONt1FW AxHmNP4MkHqm64B5yvy3eeF4L+iF43/a/w2IHg3JZR/+p/5vcz8UAfU585d1 6WBP8ytXyn20vgxJTtXq6HiPtzuoR8Km8OX+V/264LKm0/e3uvqShPvar4fR F0AgpQqy0+g/1gP+ADD5SGEr10GDYFU9zuBg+o91thTXPzWczqSEVPwLnV4z 9YOlhDQp0dwekIMDlsGTL2NnsKMO3yfPHm/DsW3p0r6mhRoKGi1aU9Q6n7lF QN8I2BtwhA4LOP+qhHWojdevXgw3PTxZV9glhM6IIqLKemY/NUc9XX6mLl98 ER2Tmz0Ffel1Duf4xjuyLIpkCpoVGbgwhGq0ubZGbRTq5ofDiNxZZTJmW0zs E4HCejha4YtRphysA98Hhu7gOAUdiaykyzxDle0qBn1bqYqzhNUOAkyNJuxw AYLA4v8C/1TNoTEiWKWgQILGZY/KmM5wGuViOgWT8RfskGXYkEzkxQhsrWqh 9HnRUXHwZAJIn2YJOozi+Rz0TTLv8wwMfNR3FVakBB2urX0ZHcEn6vf/TO3i UmlOSDe+lCKTpgO3Aagz+NwaVMj6A5j/BZ+lMIl9ASq0393efdzf3ulvPzG9 xuQNIBVQEdCiNn9lLTJ6rI60js5ujRfI0Cn73GlTvU9uIrwyK6P1Vz+cvVvf 4v+NXr+hv98e//WHk7fHL/Dvs78MX77Uf6ypFmd/efPDyxfmL9Pz6M2rV8ev X3Bn+DZyvlpbfzX82zrb5+tvTt+dvHk9fLle38Mxu5RGyjkxL5KKdP01UI7H RTri7fb86PT/+3939tUu3d3ZeQaiQW3ZnSf78A+07nk0Ml74n+jhWQPuSuKC rNoMjeB5WoG5soX2RHmZX88i1LCBGb/8b6TM/xxGfxqN5zv7f1Zf4ISdL4Vm zpdEs/o3tc5MxMBXgWE0NZ3vPUq7+A7/5vxb6G59+advMhB5UX/n6Td/XmMe KZIYxQMQYwH2AazEeTxNsxRopl2w6L4sXXF5pgTULjKmZS35okgfEggjWndO kHVchDBUOAcALvq1nj47eKYPiWkSozlcaglzMx3lWen4w6siARsqjS+KeFr6 RjH7ykDObxPMlx/OXrHriOWs2JPiohNrUbsdzsiNQDD2Dw5st4Ny1fk99qwe u8+eqVFfh0f9PK4OGhFbekPycAiMACkSGxmMpCNvkaKu8vjP0Y/wIUGxHI8P 1w5tU1qJxLU1UDnwJ4Xb2hpoIvhvy/q2jW/4/Wps/b62dgLbdTIhUbbliQzN UQZT4k/Ah68+CKdofnlTpngdBoIXr1HxT+D993wOjdm7j4417VxHV0q0Ac1L UBQ22ab3HR4Dgj2iccQgj2GjFAnoASWOhX9PaKRB9Maz0CvrUtfxx+GSLNA8 jxVsdtypcTACQ5qbOyBymAvyiBf2yCmgAp2DGfluyXW4mKU/LzQ04gJyAcOo MDc4P85v9MC06WHBUTHUNznKZyOEIhGieqZJsTmIzuguwwKtsAVxXqTJlY+t cdsKf6GqgL5ZvMATX5MoAOK1Jc5dzOLpKL1Y5IsS5LxGX/wk2tXt+HWFOrDq 42RekevIWcKLZAZ0Y8UH+lnO5IRGpzUFQEmR3SDDKfZpvYkKeY0QEZ8pQm5c 9KwDWniPAAOTY07fOSjM1aJoMHKbwHfAFD4jl7rRxo8vh6/LTbl8scHQbkhL 51IrNpsH+Rj9RSJkKNAA9h3vshcJan/IYufq8gq64IpUN0C2cg56SDrKzCXN 1GjmIsAbHIv1vTOrYaC3EDvMmJGab6FQrVc/5TrqJ6d5vNWCMTQTJhGqJzFK DH0qam7G1fbvmVhQlIEBiTdv5kjeLEymAEew69C5xsRbzE0YIWNG3FI3OvqC Q+mUeLek9cdEGiQT5wIkDpC3ZQbInkIQpof4IvMiuFIW7f1lYWktfYQdY6SH 3DVOkvotntyl0cHWdDVGrk5/YBpw5ixufk7rf4dBULpgSAhpJpZjng1HOjDd ewT8Cg2FfJzSDbHhqrxgnqBLz3Q6zwv8nVQbuXMX1ZUUGoT16ROcfh9PCap2 vbyi1h+Zu0kqf1z7CCyhzKGPclOk/knWCppZqhUcyboJ/i262eMB6XzYGi0p bD3Jq52f+3hMldAlSZ5u7/bt73791Y5i+fQJ+6TnDF1fG5YfjRW+p9rAikir pFLALDVxX5TPg2eoGGEXsHj640swfrmf+aexF55wy1k8nn6UewP0JfTxC42C gje7/mjfLXx0bhWwQVHpiUOzIl/g5jOo/jsrfvu68TzP3KYYpTO+kbbPtg8U fug3pYboxQF96qNzLYEtruYzZy2tf2v9j6aBviBkE/ECMWewzQicmxbR0HDi qdLv0O/zBTBPxvctl+kcN+QbutgZHtlhJ3hvCUyCx9RVmlyj2yYB+aaCQgob wgjImCR8DMklMwAzbh629tdd3lyPNgKXib5pv6k78tmGXEs9DeeyVdHZsN+0 UalD270DNLyeRWj2fa/TAG9Hw/MOXKJutt7ouMSs+xP/j/3fwL2P/V/1s+UF 71k/W77bwZrduwbO/mKFltZiRH+CUSJvvR2Y/8dMq/lDLT8Gh2tsGbpAoE9k La9uvezzfzq3/Lhay14QNeSYyFq+tTX2XP3tMPovdd6U0d+ME9na2dqL7Gz/ JX7j2l5Wpxic8vp0G7H/r7Z7t9ztp/xJzh5iaOVAx72xkmmftnWhoFBQarY2 WwgR0XjwOrUJlogDhgP2TzpNsxiMgy1jSK2IR5aWlVKJKwnFkLt+/kNbhnkE 5yWGlaOrkPQFlrBaunIAgUxEx9cot4FyNNohBsbIV+fclkdlE8agHP6aZqUK AfIW0afQd4sCTw5UELdM7IVEQrF6ZYU7GR2MFCMgxpYLnMVjKAiRfDrk1UA3 i+puEWMVvAmOdfHRobfFlHgrEKmrhB/KRHut6pcw7mn6xRe0+u9U0CAPouyh V2IPSSCVhDRiTCAexIuxdf7GaOuR54EjMSqMCc4vtE1zlWdXxOl06uKg5JB1 BubgA3UPoFVkCuY6SzD6zNwywcgUmDSTmxOcMcZAiFchjk6PBzRUdHQs5luS kk5hWZ2TRNkc8KX4blhfV64G90vXooI55+fVNU4EY2mBuTG6Q+IirpSZrN9o KHNPWx7K5lYIa8seDIeesRAIM2hQTPpzEH5oDZ0XsQ7SoUBemCBd5MB+VDwi vSnoi6I3kbIqfE/cp19CR+0AUKSxAkk57EOFmowDMaqImxt/GGqlbRscjPYI vhQhDvUp48ajbqrlM3FhVjAgbWodCAP7JhClIvO2MNihbXZ0vMvcF19ccLyP aSqWMXku6vGY2B1dyWkJNnlpe3r39w5A9bbcJDhf8dvRNlTxN8CYnp8l4L1R d3NwvqHq6rIdPuoh1wYyz6VScUXAuezhaMHAJiKYhaZo/yqMKTTJxAci5RV1 oR+SXO9VJw5oC1BIYZ/ITAN2pu0EwrC+FL0GYzllrNXZ5yU3gZs4rJwpsPyV 0odLoCUawEB7HpxPijI0OlgcyWzCkdABkaPxg0XReOxtbhksT48dDLciMOHY Z1pjTOUvBqIK0rDek2SMbgV2G6KjT5NRnW9q7zeGNBPLYdgbgOBYtxymRG4L CYTDy6aYnn+lZr+Jm47Ds8G84gjc8Q06d6p8nGfRxo9v355uilfBPVjSeiio CC5xJKvQW/IXHZOgFnUC719DbrHWYDD6hIJeGsK3oiYVVUUTWaE0bc057mhj tLOph4fxpOVXLpSGQBVsNTzCIBKNAXyL8sZX+IMATo9tAMCAKjTJN3pC0W34 4QCNjdHupqjifjCHwP/q9JhBiYNJ4+tQ7KMDuIlie0GKdZlwM8V2Fcl77QB8 iu3XKBa1AhCK7SmKtUX3BIML26Pz3JHk8xVjXUexuXcN5RB+XXo3GnPdetsG HlFdbLp/W9sYfdiM/kME/Mkk+mAsusVYGXI9Cf1REqLXbMmBTnqal3QhJ+YM SEn37lHJzDdoKmSZvux7oZ7SooQDzYPcRYt+8gFjvy/za9ba5xZwUZNr4cAM P1fw/ae6HJ1dqgddIYU8JD75rHIsCNTK6KSKSYMsEjjOSxhCTDNQ+eBwqtSV AdgE6IJv8tybuBf9ZoUUYX3RYSL06TyZxqkK3uEbk/kcSWKO7bodoweQE0C9 yeAAcLIjzeMkyxztWQZPTyjUIXYr5NsaRD/JOShn9yyeqqsyHaMiV2vqAQpF J3uXzDI/PF9loTLUokoOmZbQ6L6csp3OL/y4Z1jz4aV2pbavlu5GtQu/0nvP /KSBOGEBJQMkwma76LWFFdhS/97T//4Y2Z7nfomXDn1Fny09irWIW46PBwFQ 7LfrdGidysCZylIa6Wkto9FH96H97QnqSpzSDOARFDa9Q1D6tyKo8qd71HJG 0XRT0ZP2KI2fFYlnn/Wfm3gy1lE+O08vFgoQS+2W0e0tYwekN86t83E2cKAO mr4PBeK/yFFEOsPx/5of/OFqFGz63kezZ837Kyfo3kaTiPwikZ3gUqIxUtpd iw4dfJZf2sH6DBSyg44dPir0uHGnDhx2W3TtoBQ8pT516eC069Th9fG7ozev v3t09PJkEP7ceYiwaVQ7aQZEe3ZRL/fgf5SW3A8AfDw6/mLHsKIzScdm4I9p Cf3oxUyvv0x7DxOhV5PA8m3rh7qcpWBPD5cNVf9Qv+eWvgrKor56mEm8uqiJ OrHLkRJoP5TAhy2XEspZj9qIfaPqOZhttdF/Oknhcz/AUdyv8r6Mf6Lfv278 8PqEnrtL2ExDs9fQzPdkZZn2m1h3/LAT+aK8P5+B2nwZX2GwUw99dj3UStdg Lj37cDuczdIe6JbintqK6Bk40iwB5c24MTA8Mi1Af81u1pSjkJVI3R5V1fTi cpTTu0/peJXGNdceBguVYL6xBwmdoAJjXc3+i511ICSjX7LTjZxfRaL8y/xu MJ78PR7T8zUCAE3T8wjf8HKQ19Gxq/SFvROanTzFby3I/NpwdTcXhUy07Q9v KzU0d6ALLXZvDV1T02/k7steA/Rlg3Yi2IoUuA+C7d0CelBS1Q9yIZiWOfaO W1X2gPRm/66O15JIvBap9AVoEBjyPrejtQI3RRQIxAEcKmB3gTLDCnqWzk0W sPuQBaj8urruvwMAaMadLUYIq/7kxY24pXhNvh5YE+c8B5L3SmXypWjl8cMY 7RHQHnCFoj0PMetpKqXfsmkylpDMKZ1ZxRNhAbGm7Pro0QxEoloE62/MYQOs Vlxrp23fjuPEf5ynGWVgwmdrg4FuH4/lxy+j/8bIr//hMxLbLBmU/gRuObSA uUD4W/yixulAGMo+ZpqBTdcHq/obpxkbhIeB3G7aALdhmKmYeWFLhc/H+qzx V/wpS+Jz+NNrJzarwav/Z48cQgvVMp04+NDr5X4dcOzOtWF0IK7VrBOKq+CX 81vqGnq5Qu/LNvTyLujld0Hvmi7OSBNIJxqXAOdQFj5Yc/pfaOuvtnxf7//R ME4yTibIToglh2NXN3o6ikOruFqU/kpOpums7/300e2i17kG+KNFqiwuqz5n rcEON/DHIb6i6oNq0ceHax5pMUbeH1ivbIeBoxUH5hlNjHQ3W7W+Jtlu3wou j37VcTOH5AXbxUi3bzQqLJF053Te2nmvtbOOR1T3UGVTwzyeNv0EZ8KioHSH Tb+rBIfqwz93lJeP8BGJgsB/xyojmiVFeQf+j4xgSw1NdWfHdREat5cZWp8w h5NoE3Io4slrTkZUBYb8FAWtDrrJt4OrOaPEaVJ4tgtHaaB/e6ZTo1mKhEJp zbhf+Wp5w7smJKfslpz3GMGdfKhqbw831cVpLWBaB+STRx5v8WeTRxgsUdhf 2rmyBtEx2iOIvL6DLUOpLVRDdTW7KGYSI+FeHdu0skINeiISe16GJOUrp2Rc w6NHiAdGMVDstcmJtKXvBeoJQojozMFyw62fjIByRcFZbvYyUE5+mGXpe33Z 7GZ6W8XvvqXc6Hj/S698zKMY/UaI9AgrnqUcgwRUlh0MuEU5X6wLiWGEi05v UQMa6ZHQXSuHGz2rXQ/vrYdZmRMTGTLHZWLC271wNQVXIqriyrkJINGlYyQw qETeCFAcW3bTEsam3kPx8wj35ZM3qPpGX5Ns9JRe1dskNRMfkWvoDcFeTgKh YBBVkVCcn4HUi8c9ea6NlzP4xCjq3UIQ9jh3oLy4UE80OGwIX7WkGYYbYII+ nYNNCEzPy1R4gvvCAWPy8GngJt/c8Fsu6kvRishCV3GaUdQD7jPJx0VB3fAv tgxiO4LF3nvnMeYcTX9JJH0AhYE7L5LUqlJUGesj6qqSE5LxdZxS0iWcWv79 6dOmEUh8q+VFsWFUY2YlEUNXiTz04oYoh6kV39PZadJk1SY6YxaOSkFBSIB0 BiIyhaXeAnj0OLD+ukM/FIkoOsXBEXhTDXwyU7kCAT9JIkSv880W9PpEVfw+ KS3lzIQ2XWT5CB9FztRiKBEvmYasICuaicPEzTFcLIRI9tmRVpucHYqtRXnz NWX3lY6SqYlZCb1EW7PULxrx9pCiFOmRe+KkOCKW0UG0yodWcrCXHUc2wDgm 9DUltDeAdhwIa21bKw9cYo3At6Y9Y5f0ENaJbDDkT/KrOWDlMPIIUEcrGmqU Pbyu0ywTVpJgRCAIRRRJkgBBEhb0J+BijNR1qEP3pllCrEhsTg/hJRsUg6Gc dxE9eOfzG5sPoiPdCmljxUkremg7qIfib2ZOhyzHS+Z69B9tYSsX2g76HGq5 FXtiefTswCYdR6bzFo5vELgVg4YpyUH1obAyCRxWcVSs2GsdRyQDKkrvzYS4 FQjT5+ji1acHBoxyf4r7QtMl5VujKw0ZKSSX90i7YTRNS+Br4Ar7oAt3vgIm qPT7XWdE2/lMTlMQwxcXLEEnCc4ckMqncQY8oVdBdcLs3CBkk4JetvIcJSbR CQtVojPbBaG5pQOxg032qImyFiJtLcjvRXVBDUxq961oaM1ZXiq+QlIlM0zS GW28Gb7aFABgXhAAsSXke/h/+h47y9ElP12NSdjjQ8qJDAt8BTsdVOrSCY6o YopJ4LflQGWcgAQnUBY2TsImj5Oc3HXlYo4PFpCJMkVFOoqEXvSPk9Orffrv QYBKW9Hz715wtOIm+8b067wylGbHhGSU5sCj3UFpEDjOW1x5JiZEecFILsm3 hMeiQHWHQ2RKJ4pE00hpipjtcVGRXVAPxqGQfsQWHydgzDCeTwattOS1AE1n VtmZfDEvipNu57Fx1UUaQNTmttIWX5svCH9uMejo51s4WDohWPoYBt1Bnx1D x1MXIJ316zfLB195fBivuCGLoA2PcKtu+MhnNbx+zss2hLyfO2KyGgrnoDKD WOqz8F5CodbGnwe9vLiOi4nl/g7iFWz1OVfO8k81IRVosgJGq7hzPFErPh0j zLlmCUpDeQdnxKN1Z1EX2cqsIIFpmxtwEIMRERc3ThQdacThvNViR/mGqFa8 2fBA2+UCNJGZfvrVCFFMHHIdGDCSJaRmfdFZDdB0UydHhjbb6rp3J+h8fJ7a IE8F5K9fOI31yUq6wxJs3Oun1Htrz628W6alLkzbTbn0pslyg4OZl076ErLf NzlXdDsNNiBKTfMvo/8W975+zatcxuTdt/zQNkxbGt4ZWLMkuzvoujC6M0xf lrQAjBoBtt8Vdr7oW+Kit6bkt7Bw9eYXutZxW6BfKHir4zYbXcyjX03qgUMw APrwnVw01KhOnli2A2stonojn2R223YKNk7P6xy8menamZIXqhwODQ0Nv9Fz Z9XYXMzVLhua+oMhEIMh3Xfg1Mms/yl/Sz/uQLkplg2FbtH7QNWB04KqfLqj qq7LMNtRPy69hYMPZgw5jMs+519sBULMFpc1ECsBiScTMDXLPmXPu7Hxadw/ HgSM5qrPYxUI5Ga5zOd1KAswtp+241/SM/8CxvK6j3JALJ6190ZnXR/Oydpa LB95XlBpkD67Jm0AXUYusauwDYo/jX6n3mmV9PPzfl6kF+lsGYNKrpdDGkd1 aoWfzq8O+rcchPp2HqlI8HEkFQFL+jqSD29EHcZskqMfw3yMPy3nPiM26AXk xOKALosAp0V/Gn/oc1akZWOYltYwyGV7u8u6gpJAylZ1CVPEtLgIAZ+CTuPs YH9Z76s0z+h2f2wdFQmIhkTKB7b3hzGrGFc3hR6CeyvihjzUJ3he2i3fJ8k8 xlvWbxTknYNlXZAKBL2pi7rzL+fntVMev2w85uvysI2PVJ8iiXW8CX04piKv gJX7Py/iSUNHLHeWjm3B0zB7w0JZGS/nH4lGKktFVPUJcrXa8SWYDD6l8Mv7 p5TqyA3sbxo60d2QI52XDxSm7P2QCpSuGqXgu3slVMPG0b8v5hSxQ6GeYG19 o6cYYB6jyM3YMHN6LeuEO22CJ6Tda1mn82xRXnrYtfO2HIVm4QInsBJoRVFf APzSX4HoFiug+6DPo4/5vG8aDmYvqsj6bnQ+cfCDfxvU7IZlQqVq+2Ky2J8A hnZXdErD2dnHaLTqQ31JDavbvSTCg7oVH2prGu7F2qq6DEvNISBjPQ11Qr4R Ae1/1FDaLeX4J8Qppb0i9Uij+lOIcHkivpZLPmC+x4lOMq6TeLZ7VFKuI5Zx HMj4spZUwX4DS+m7uegbJaiz8sxKFpAysWD7MSaSEZbrKE10MA9jQGYF3p1S hg5KuasLLg2iYZuvZ8uLgLZ8MXLbptCeHK6t9VrdMT2dg1Iaad9aYaUilfgG QVpCidTttNVbcm/w3Vi1mLNTTdJ/zJHbdNwHThUz99BzY+tubQBohz0+jG/0 10WMtYwpqY9cwP01P9vshLyUOxxneERI9eMtOIupxrNK4qIyzqiwAs7hsnew v0+V7XykrxTSXTxLagqqaaSbtuEeaOzP5nnKr2f4LvE77YeKXug+G8+/e7Fp evK2evz0KZa3sFcJszG9l+QxPmuqBMuCLHfhABt9c25dz2NGZayTNSaHkAmN 4S/VHS1e8ZlQlzfDVyp4xLmHda75KAjQCnQpjfjg+z1VqVPXzbDvJ4dztPIo THA42NkZ7HFyrcEOpVFsyu8YfGyOa97m8pPFNstRX2VOOqAWhV3QXIciVxtd 96UX/+P3SaVeNtxISmZ7bTQojH9Ql5/Q01siGgJhDsfozcdHlhiwFb1MMb31 xvDoZblJz51mPo83uyPVZK2r5iZ+1k2caVOIicV/au89//5UN9yUtF443beS HNu671cxFj3j6ezpa2s7W4LF7jr4C3b9FKNFNJom2NNiNTeosYcOv55JfcMJ zt28ClTzTp1QVkZekYmTvy8oEE9CwtxIr9JqIYVT4vdJMKRK/W6yhSHOfDvx cjc6MgHZfCuR7ar7iJ4T622HAYaz+UjghhsCxNEsGxh5gs/8QvG8ahP7gR94 HLRddgB6K15z2C9bnKjsWzq9Tfj4LcLjHbfEOJ6Xi8w3090GrvYYVmyNmo3p jd0fjM0RX3iaaCMw3Wd8lcVgGliuk5qW7w+hY4XKWiNNr4183h9f5lhc+ptQ KwZ4uDHP55sNvxvbznYsJtN5ddMKEQyX5SCh0TedQVZFPCtRBWqCq6etW37T BteQcsdVrq3c1Ye4LulkSXde7masXJDqb8Ul7aB374bZbjNmIZBtmImzNs0x KqvPafo67IAlG+nndObto+gW+0j3KTvto2i1bRd12XaR1a552+m/G7ZdgOL2 tvNt+TrE+rYLgFyy7VyQTdtO/x0Ft10jqrfedrXuIea2serO3D7oFbddrXsz ZiGQjZgpboJTT9nMPjvRAuFBvYBDMdOtGrZlrWGL8Oh8fuku8zJZTHKsf9Ms xNHrNNbbreZKrLc+j4s+mA3EULPa6W0PfzXPggfh3Qb+ssPAH7I4+LNpMUsd GdOKgaEnXkuiV6TzOrhd07n4g3ESdJVpvgqy0dV8Vt/jwjroh/MmYbnm+Nca 6yLHqfgjssvx0ZkCUbtct31koyKdXFgxXt+09FC5rdy2DWMInSzFEbcC3f9y 0T4DJ6BIZvGFKVjhuCadX3z/aaCzImVz9MU0wSvnPubU6OOzhgbvqtUsHClh NxadOxRbssLbUQJdU83bglNqjS1vb+hn9x1pUxv3LSk30a5QZb2IE1SMH8sc q7tDySpzjAXbKjOF6m1rzGlOFarAdtxI0fS62VRpYjPJcjh2cj7pkjxgd8Zg VcEBQG9B8PFcpT2iKui8pMh1MAfTuQxmNBEx2rFJkVzjuyPJH9urCf0GS5On d6NQUg8Y3VSHaKDHeuYMlbJBiDdQsmxLltvTAssPAbGGr43L8MfTl2ebdqvk v6pElUCqV6+C9v8F3aEDvaQxh4xdi+OAK3tQUPk2FnjZBJu3JzLLeUViVTzj Anj6GZw8K/TSFYMJjTl7Lgr66q3yoeDCPkchhf/YOHn7fDPSexuLDolLXIhV LkZWqRtTeUDRmYuVCXsoDx46MHRaaV7oR9Z7BO0VpDFA57CeVImI8jzTCLYX ksn4fuedW4beG5npoxDmEdDlOVI02KJU7WP5xnpaUK9cR0gExXwvUEpOkcoD P6Fkb/jepf6sUyU9Xej0/Gmp3kGZ9zny4Mc/PHrsuDk5DThu9j6p6pY9R1g2 7Cd+rRh8SuM8ecME8ul4QeUjCH0YWx3StVfI4tFRe7sGfalLZ+8f36VTA7Dq yaWG3QtrJg1KRjq/2ncOfPziU10bNzFpvIQNprfSxq72G/UxDow6Tz/0s2R2 UV2Grv/kEzC13PtaVQ1SX5E2INVuqW94UAKmLemRkxtM/Tqua5IWJMGLlK4A IEst5di7IDQbO26GYVZqfL0CUaNRb42SfJijr7tqGkdzm7wQF/BJ3Q1Q18dl vvOcQnLxf/puXG69p+6sWpuvG7TaYGcOOQoyWb1LR+5sGgsj8cJsX+8hn05D Ka7RcfCTy/G8nWmwheg7zKzL+KfWowm+NYtw8FcNmS54aCK6rdvpSNDxVvim Bay9QsrWsSzDz7FOREpGK4i/YK63kqY9pg1s6BHVNqDdq7nTinO/xcR5jflm VQuFoK/MEQZWaGZIFAR6uKFx9qfRzg2QrXGH6n92nLcNfaVnak1A7HdZba6z qHs+LIstMZzWP8EPGiz1phM8QJ+DcNDdHU/waIUT3Eaq/alG6wmuVyJ4gnvE bDvB9R/NJ7jd5JYneG2U0AluN4o6neBej9o6NJ/g9Z5R9xO8pXPTCR7s0pE7 m8ZqOMGDPeTTaailJ7g9xPIT3G7d7QT3esinMXzbRaYLHtHyE7xOx/AJHqR3 h1Ms2E8+q6xTwwlu/9HtBPf+6HaCe3+sOPdbTHzpCe4hsuwEj5p6rHCC12G0 neD2p7sMsKHf4gSvA2k4wUOf7if4H9O9vOe4l11/USilny5dJj4b46TLVeGU WF59yw+SwMtOSdUcNaQcZbMkmaggUaeoWcgTpbJamRBbyeWBgbcGjdJzIAZc J71aGh9MO6TzW9lJbDD9X1wU7Oxyx45d957jUiXPm5ntmFAkrJyUK5KePT2P MIsShjyOqaSeepvEeFIT7EaOXO6pfG+WL8m43i9xRY1jLmK1hxxnUworwwA5 nTxOy5BDU27txV+OTrfovxTHe6MS2XCUpvH3DaLXeaWc0ZJYGdFTub/OsOYr ZRMbKkyGC9wO9rXCxtnL4fBoUyogPj3AiG5rAYCWTSToNaibrgddsl65zsrI 9CGacEKdii8ArPhB5DjVFMPvVOciAV251CWYTo8t/pM2zjSp4tCsHeOSSp5G PUft6KlVMEuogwKnMQYB5lzQEUl0w7VMla+buvEhpPzUlMs+zQuV8YaT76kq whXdE/RqWklP0Z8pDmzaaQplFsfjnorvI6siOrGyQ+Q6SaMqLDicXGGMYJlI WSs70rMsFyqpHrGKTgvELczmJMZjG0Zfj+D5gHtfBWI6plKPWKnnWD2+YMAJ e52sae5ub+8cTkZPD7cPdw4Pd4IA7fYH+72tMKoyWS4uVfqgH0FPzoBH1yzm WsVkxFO3WTrtUVLgRcemVUwUmL9cjGYYGayEr5SyijkWhp9JzJMizZXgIelq XeJsOUlOo43KVGyAYTf5CgpDTTNVCczOCaIGtW41Jguq0hAc/l1z+s1Syl1j ZU/g/cVcckSiS1+nwlQZq9QVGN+KYPyvm8BdwoxLTiXfeBmBr43c2wjOLHXo VVFfIbfGP3+mhY6pFix1xoZAzzi7vuNsgEEPHLu+cGyAgS//Oj79a4BAb9e6 Pl5r0w+jFbNQ39NF2O9/DbZSAMdteb6ZACH+tz9L9oL3HgIwCSR/qj92D3YO 1jKodWq2bSyDeyW/pA09RILlVGD1seueeZAfBsK9yY/PZF/K4agzi6lDtW5a vhL9Qc7ddAZsQTnINnr+ju35KZG3+ElmIHn4Gmu/vXSCURkqtIQ1E5Xqlodp yj1eueEkUjW9XONMw1rtMejKc1KUnn7mTE4aXAuTsdUUHRZBCa3JmvRJwqas GNVoyyqN/J15xyPv3OJKZdPgdN5UTNWtjqpT2FIa/bUasUWLV3t405DRfpDE 0JOZzua8RllezxczJ4O/wpQeQVJ2e35tp98dBWvzAEHeeBl4vXdiHpPQ0y3N Izq/NKica5ImzqcpKYVfkGUKE3OVQ+u9ocnCq14ldlERVf8uWqK7Vx8O8897 mK90lj8c5R2o0HCUK9dvXI5j2Ih9fK3CVq5/a+UsGF7bmqZAUfgHzPpD1b/M 58EUQDLr1hCnOmII15qivjNuTuVjd8UnD03R4KFVY/y5iR+UX2/vpi5pTrSj O7Smm/B66E6S8qi5nZC2JRWSDbDdEb98mJYMbR8darbsgciBGN1qM9iUnTvB +R2Wwi7PFGJUuVXxa0iF2npAl7zwDHfuXOypCdlA2anwBlStb4NrdCdcTZTE iqJDPstiKxwkm0THQXsWsNVER7Si6IhWFR3RyqIj6ig6oq6iwwa4uuhwh+mY 3HGZ6Igczrid6IhWFR3RctFht1omOrwpr7Ydnc633I4G2aWiw2t9G1yjW+L6 4FjwIfzRHQuWSSW+Bc90C7+LMvZlPZmGmMWqTBOZiSen6joGsyEpgU2pSqRo TqmfdOCrJXXZsj69OY+v8IV5gqfQ+qbJ8aFuHxO8/xgnXkInTJEiQt4bhQs+ fagilP/sQNCFvCvXJAVbFnqajDxuIbWZddm5Rcl4Epm4Pl/sWlq9SQpaezHp of2t7rzwnV5vkwuAAMpwTHjYXl8mFA3w/LsX1qU1QgBo/DcjTkXJDObQsipu sOoM9pTEKXihQxmTLGMex+XzLUAo/qH2Bsqnk4xGd/Kqj6wR5S+iR2TUEidB SYDJbYJOIaDj96eIhRHtAUzMj12xARDvOEGR7mk/b0syKpWjfkbnEXfm7DMq T5J6QUT+JGDwSsU4KFZGpFWFIET4B4lmoKxAGi1VZaiZYG5YhKzPwkCjnEAI bmOSbKo7dOUKsupD1eDzPkBnDCbvYQ8MJg817hf8vqvvhdKOPlzPfZbrOaXa PGRCf8iE7veSz0Mm9NDnIRN6c++HTOiKex4yoT9kQv+8mdAfLNWHEJoQgIcQ mn+We7eWEJr7UvEDjRpVfBuHlVV8u7P7tNHuHPaK231XNg/szq3mgUe1lc0D r39H86DGel10bm+olc2DBlSXmAe1Q6s7qnc0D2wgtzYPHEa4lXngCq7bmAc2 hFXNAwf/lc0Dp/eK5oFD/pXNA0fQrWweOL2XaO4ug3YzD5zTrot50DDIcvPA 4Z7bmgfezl3NPPDFRmfzwDt92swDb4xVzAOv64rmgdd7ZfPA1y1WMA988jTX e7FH6GIeeF2Wmgf+Rl9gUF+l6hw0ajuN/LCEISIzFUwoD2yBVd7jrLm57rHB j4X8l71eW25+uBHnm8vaeVzdj/POfF2HEed9mNL4Mm4WAHYn+UCfPnU61H/1 m/ehO8Xp5HH3OULj3xzBhtQG9daRxRV+ss72HRQEUTseW/W8OgiqT5L34+wC b/Qup0vpZX2Wl3aaJenF5SjHeqxFMs1R4LBIDnp2RLTYDZ3xGvOjeiBW1aB1 R6PmNwVc0Qfsn8HgEfyfZTtYfz9C9b95kNu48Lv57zXdb+O8/2jw6+q5t7ij oy/cyKFb+OxrGC532FvM2xHDu7vq7+6nv6OT/o4e+lu75+/gm7+1Y/4OXvk7 uOQ7++OF/zo741fzxNfAd3LD390H/zHMo/jT8jDIW3jfu7rejQqwmt9d91vd 6a673sbj/tEsxkru9i6+9o9GS+jkaNftu6jRBocVArIb9Wj30x6EzUBulwql pp0sja+Wz+0iJDuZGUto04UaywwMD6Fm68KedKNpYTfyMO9mVwQBtBoVXg/5 dFXYa9MKmhNBtNptifvGq9mKcAdY3YRo6t/Vfgj2rxkPUUflojVQVk6WpdG/ H11wK4TTqp63j/vl3p2CfrnpbSJ+b4XiwxVoZPX+/MG6EoMnkboYv3eLMF18 YqpyGan4UXrB2zNWZQ+jdKmoHgY2vlCl+2K+a5JIWWzOac0xENJN4oLdznSB BAxrVCY2hQQ7Kdqd3FKqYAIFjaKaMsrS8hLRr1S4IiUyQcylyC+ObVm5NHJ0 oivG2hawvJ11EbcNXerN1Rd1/UE2TR+x/ecX7ny2ffAEC3fmqlykDsb16VI2 BDsPz6LXZJtFG8Oz15sUB8vWnMzEiYKFn3oldHpNmDsKcai9UF2pzNb8B5GK bFa8hhn5VRIdfLHX26L/PehRBq2eSZ3V03G1HuxpenFZWYGrFxy4bCJ0pa4C hkRTFPeiZNbAeoUqRBp3Hr+S5mxVXH94E9GagLpxxUmmgNRFPi8wBFjnvfqO sTixyvBuDL87KTejR9EZvoD+eYGhCG3Nz7i9ky4Is/HrqpGEwQT+lybipJ/S 6YEWMyB/WXEmrVenL8+il3tYVgKR2cIRov+IdrZ2dp9SYU/nAblUr9gf7A32 pX7F/t4BVbulmp9Z4m2sSgfxZqrepewKkAuZfsNOb8rj9wm9sDov8il1xDIy DRjg6ET/3b19LjgqJnqIy9i5QFHOKG0STB+G4fUUP12QbIm5gCgyHjKuMdsV vHPkPpUmThcZ0W/zTRw8cH4kXRXnmrD4rSgdJAOsfDvP4rFIDerCK6gzstnF JxQYbvq/p8N3fyFczXt/zcIIyXoEoF7aqx2uwMSY9Uq60lwtPwNP9ofSKuhR 5SBR8gtcTMVBl4sRHbcg5d4nyPoCGQFJTVHKX8aSQD1isFPyeXMRAHpGWLWU WJl4IRaB8DLHNUNmAXP2Cubp5C5TUNwJcUFZsIDT6WJqMUIdTdU9H8MpSLK/ hBGf34irrL72JqvXdg8zKtC7jy0Fpkj+TuH7sxs9UTM9bitHQB2VTfXawHXj 8OJQFjmdnBEaM0GsHBNcIVbhQWH7VLj4iMvFlrWJqAB+zcMOv702SRVqlWcj fryAWJoq32q2/pLSU4Sad4mndOQhICSXRw66BK5KEafHku3qOocY6KuEShTl tVwf6uGDKTGsX6aDfVbMDNMh1OgqjZH/dM0TSgmIJ5N6qiHEyoUl9XuFjJjV KvrzxBeZEaU4O8NhctF839AULF4h6THOaQHwVKZ8edLs+EPFxD8CbRAmWt0g OQIOM6LJUVwUStuh9HNy1ugsHyhWBKTCRwOuPWxy0iqqSQheqmj4k+0dEM42 uRoJRedH0AnXwCNcGZ4KIDl8wclJT48Jousk69lwuPCOSodI6lws+fhEWqSl 3sxwRNBLJJQvNkD8ovYmqSZs6GjxsiBE+iyyj0VfP6OTh8/CaUpUVLhsWXsc YTGLubliXCdcT+sMrHPr+dTcfDKtoXgAYc9XlE2HB4FpwjJfJIV5PQXf+Rgq 6B4SNYpdX6Z4/I6lHFnyAcyQKtHPsswc2+lqjxwBF6uK7ipBrE8pnSGWXN6c glAmO4WliC+SrUi9h8Pvkg+g1xsg87i6LI2ignKI9FDluZST3VgASAnHrVkj xBaduAmw/aTkFJHYji0P0JKi+LzSoplpJrqVsI4sL9hZYpjw6znjGuW99O46 j/jfIlrH8bySMl6Vk7f2MNrYEQdMTztDQetmHNIygGo9n6WyyBScvwCY6B0i YIvH/cGuFpC7T3ZQq65bWbGlLsi88XTb2N2Metq3246ei8x/SidGSJJMxpjS larhacXQRXbfQxbNjug55qhVpMVTGWwySqw7sRb37u8oZ3yP7D+e1DZe0ytK 1/eqeIHr9i0yPF8x0ZV+Uwg6GMh+2B2xbBhFMUOFnT1rzehQ28JDCsSAqiFI 05Dd8O5IVm7oIBK9YeN3Axr0h2825fR4tvsYLFdaA5OXq7SWjjI6cQLbuFRa 1RSsCDpqEK9XLx5raxBztlsmNtcqjMtyMU1UulmrdqCuTMe0UOMxfqJ/2hpX 6dhh75ObiPyccmbqY0R5FbQOTFiAuHqdMypzEbCU2TcewQkJdsq1ynGtwBjw rH8ZRAa4t67hdC221OtOeSppMFNAGACI+wXsxTFaLLYDZpTcAKuqJGL6PH+6 g6UKtyh/ayaAzoBDTl7QMr1Nxlfwp7VN9kydQ17OTZVMmGwuCYjY8hKCNXqC UnLTpHJUlHDioEpmF31EgvMCmVRgyoDgI/WQFA07qiJgsnIDO1k0vZBFSSBI a0eI+KPwvCT3EzW1XTiH0Wkbhkqv7gnkntKuK2JlXOBkQr4oWiVsms/oB9Vf 8ZLrNLKe/braiXnx650f6inum7PT79RbXPSQWo9x6Zeur3Gp78NzXDvO/4+V LbcprGJ5HBMwb+wWhmA3fF7BHu3/vIibHjy4WWrw03Chaq6tszJecmf9T+me jx5eKH3GrdpMgNC2tT8PL5Q6UOF3SfL7TyP1yst4SmlXyuCc+vr3wOzqQIAF wea8SCryB7W/07Ia4pcd3kh5U7sHaa6bz7HcxVXSIYCia/j6bQLXVwlZ7xys zrEkgG9fB0S0BErbWPSXRXFbF+Yrx2+7aHUL4b5T8PadwrZvF3OxLOCiW7SF B2iFpId3iLPoGmRxywiLO4RX/JPpXp8pNEIbRBIbQeZU1+AIatxkFx8uvWoX 71Ko8JT7gID6p3IlSy4kKYo0QUv2J8mWRffH6J4yRau8C3dyyP68SMqKbj75 DmBuLkyonBZ6aVHDVaWg3BI2eTG+hO5FXOWFumMfm3tVmRTS5mpX+Sj2H6OP AhGjr/fU1wePD9CZZN1CxLNZvpjp9aLp8G0Qucr4tA9dJtNSDOH36OSFl5ss GkrmL7ypUXnG6HZW284M3hzy1o0r5tICsJUaAttErAjoyjfXOdW9gZ8K7WNG tR7RJRcM3meQm3QECzLJgQwIQc3RdbYOzH0U0wz7mxaP5VcmHV1JqjOccT5L qqb7jpcwJpf+8uo6CSIvz4YSyKBJqnPek+c4Ho+TeUVOFtYEGq6B4pn0tqq/ qS4Uy4PMmzR5P53bILdBVALvTdkdOkpEb5BdoiKMHMQHtjNVl2LzoLJ6YLmB WFjRKLkwivJVlod8yxVSbd4VMRgJBWHibIDHT7afwWLyP57sP9lXK+tshyc7 BwefPn2Njkt0LW5ZLtFJDnOe5ZXMQMqyPX68y4EWlmep1bXkuIu85PsnZ/2T M+VlwoPC8jLxT13dTNT5wc30x3Uz3Uc45R2NNufxnP1NQyfyvjo66fKBwkbe Xa2bP5xuFP0R/VKd/U8PfqYHP9MfQe49iD39eXDqPDh1/M4PTp0/gFPnD6R0 fCaHjDYddE10sjy6emS49Wd1ySxxxigvhR3F4NpjjCL7BrgRvfdAOR8y37g5 /XwYvaQQhJ0t9ceuRq6zy8MYcuzzWGrHc4ff0JDX9crVwGLGqzAutGiljKC8 zolN9A1CsONiyMqmZxhpgaHftb7Yk6KZaqeaFnUeF61ibrt2s2dvvz2R/Oqw hS1jG7/vXP44fciv/s9uad/dO397pbU5Exb/vpjToSVhnHwMNie2UrOfQdN0 4vZa1gnDXCf4fsTutazTebYoLz3s2m9E5SWEUaIDiT3+FQz4h8CSB4O/CxX+ YQ3+B/H7jyp+DUlv74p48EWE0FrRF/HgTviHdiegqvJHMPrFiNFl6k+6J6jA tr97CEakaobZz5AlpAHzPxXAln6ABCCur4d39x/v4RsOnMxrrDL3fTJTObmi DfhydiHvb3a3n25jS41kIXAdQxptVPtxmWujGuqpV1EboSdRm4drCvSXUc87 aPihXIRv5eh+3TyIq9QjL5wKd1KLAnw8sAD6h1AjxFFyjoXqY20Wkwk8ScZZ zG/jCI4NunZUWbBDoEdJVfGCyNtmRLhI4HgoEweye54tR1mji09X9Mt5KWtH C4DLxclI7IPPC+aQp9eIIje4N5eL9rcgbMtB0dnFYXsrPAfHj2/fiocD/7Rc HPTLMt8GiqcH58aDc+M38HSvrKHrPnNcYkwdopUhT7F8sPYbATxY+w/W/hII D/Koll55uUyig5NzhFsrGzCkzULF4/eLeR9fq1pdWrOZm9HSosJwY9Pwy859 50WK9p9nSLZhWpe3+Aka85HNtL7Z5dK5yWzUf69mNjrdVjbODGotZqPXbjXM opUx+61MQa3ziS1ImuIyI5Aa/QGswNe55JEijCS7gQT4Pnt88PTTJwVKxyLT MBTpjveQODqq32YPu8HoTr4kGkW/Lrc2sTIGVGohfhlgv5q38zTV96+XDVE1 sEDAl/yCvwTqZz4esqn1VXR6MSsNvlRCm8thczttgvAE9HhkPfGTfr3pW/IO sU0xT+L3mKqNcyhQH0pvhGyiHj6Uq5g3BNWya8wSz3LfwDIluVOdyoYNLIRC WTgQ22QtLWc9TkNGeQ1hKBrGA0dx+JgsBROlbJSwBcxDgGfyEIB5apMsrujN 8JVkCYinkiAAvluaFyCeeobWH8+oWnKBps6xtlzfrhii9Ar9joqg3RW2RFok kz6eGdWHuhfdxGI5UwPe092KDzU3ergXJwmkLIpzkDtF43lud0L/hyRH9z96 qN/W+PjqH838WOIF7cBtjtbM3AbkA+apSMx6lkJkcRc3CCxeN52qzBfFOAnW lgkVl9H9bpewXndvtlasP1a1VnwKdt2vdaJ23LJex+671uvYeeN6/Trt3VBH 9+z499AK+BdK+HWn+yK7+zShnIs5K5sPevdvonffx0tXdcTrh66gFix93wpt LK1apaUzWXB1DnBMeKZ26CEn1mYZFso7jLnRMCmSBD/y1YmjOk3j+Zy1XT8p FOUXBAg6Ex7rLyf9FwNyCefzMr6+6FdJXPbjqgLc8JDrj9NivEgrTHtpkCN4 clGDahklOuScZQnhgDTQaXwXs0lSZDeUCotTOauneZgKWWVC5uTTu0/UmzxH EAdowbm8bc28qCc1F+VYp2hupZebT/0eyOVN4rMSrPUEIvq9xWRtJacPtrPs ETDUe9UXJQO0ziQViasTvMtrZiepfD0rrTMMp8s1B1EtW2Cq9sJ5Fl/lzi0g ZrYF08ZaSHlWPc4wnHZM/dRj0ad8x3eWxNMM2YJ/Qlo9oZ82B04KZH7EzVnz Jub9rrUp+fUub2w3x6qd0toZXiXIDx2bNG16VZvOOCWr+oGyZU7TcZGblJlW Zn5Kwj9NKS00YafMuGgOdl9SQWuaLZpFf0/pSg4zJ6Z8m9l0Eq+CjLzY1oms A0g04YAprXn1kK1Nin5zxGtMZslFXqWU8FWmbGGlOyiQmAUR861vSe44ufJT e4DNP7t6Ag4uegIN+kMo+W/yYU6ZemmSciVKwBRlsiy1kl8GLhNP7FzYQn/o C7hMY50Zlq4RNcN5JuyUDg5M2bqQ22Vjwx6Yx+6K52BIK6vzVtQz2kbPZMSm q032uqggbtOMRqQc+faYasQShxzskZ8F/6JsoT7Td8jRBxOFlmhwn6mDWVnd 8P/qEJUTe6npjd2U6U3M05OePUtql86xQas7owgatQijRLMppnAo4nNMk8ku mgvg9BklyH6nn5Ork1yHKFBsPIg9ReL2EZTceolGVrSLZxb/uWd12eSj7Cp/ n+iaFRZAI0+7ORserNE7x+RIIJxeA9twNV87OFrddPxcXePXrWiirAqHi8r5 OMhpHTKZN9RvfkhdpELWJDe/wNhsNlnqAy6zaDtcwUWOZn87u/ZwQ0pLNM9C E0Q3dQy4JfZbJ9NARJCYBlqo1e0DEnlckUVJvCsj8fj7pQLvaryqr/Fh+/8W IXnKvq8WDXUPa15KBQjWc570q7wPZsIIjtbrdAIWgC1e0tkoB2ugP7p2nLHG jya9YElH16Ra/4/bTo+mfuYfwo5aR4pg481var9GIkVgP43zcjPUQKMHDQAx +G/fij2IaoJAN1YJCX3/bLh5Kq4hbG7qdza2H5UrtU9WhJ+sCH++Ivx5B/i0 MlQxIrgukUe7ZkCRR7UOLZPOMJPOMOedYc4bYJqdNqadNm/aaSBEHrbaw1Z7 2Gp33Go/525CEPh3eD/BD9rn1LAxrCbA29a/nICxyF0Vt19DvFi9T0hfjWr8 sYq+Wh+DrUVTQDpqkg6iqI0x8kKZln0sHxe6tIzHWYiQDU2AkGDdXnMdmCZ6 et3DHcJk9bo2kLX26UBWo3Vf+Vo3689hp3ygHqUo3JaHntyAys9XoicetLmA 31lM91fvfiBf0OiGSt2Ij2l4RH6QoF7XI+dJL3wUWUPdOCiaw8oZ4zBqHCV1 XC9KgbTgSGk+o3NvcBU/9HJleWy31UH3go7YjpLvEpMrbxp8AhPz8JFjtgtC i3kjOpjTWVDwUNtsJ0/bIoh3p0jwTQfX41uUkpkSS4ehY3MSnViOvLfoNdw4 Onm7ueW1er4oyio6S3/B35+fqd+PP+CmDoA41iBUE7v/se5/msTvA71Pqbek bKBGdv9T6D+IAMut6Bj/gw2hS72oz2heUrGhDGby/Axa43+o9fOzQOsbTobB 3lvrcQwoNADHqXX571xedAf9854XzfG+muVGKPSSpgcKlVKC6OUID2ca4gMi 4Mmj/GxgN8cgsbb2+LuqZaV6IF9JJataF7w6yTK+gjsbnqqcl6Mky3HGucle ilA8uMyjjaARG+FjnTdUCtTxfuHCvSxgfs5rBX+5uChspb/mZ+IkLANlchlA 4GRpBDg8erkU4BdR9Lfh6++jV5wslB0c/OKEpHBaSh5RqkFL7FHnjoNnz4g7 3Oo86l+7z/atf+3t75l/cU3gLY/H4F/B2zrWS9Cr8GlL5Yg9OT4+frq9O9j5 63iunSt0tbz2p6M3L46j58ffn7w++3NEN2br1hOab3e3dx/3t3f6208G2H5d vbOxn9lEv67xPXVfohp3Bjtfw3focCnneGG5vijA1ocuh/QQrjz8MM0OZ+Uh 3W5boNaxm6rqx998jXzGFZN5TKN60bi6ufn+a/pa396pU3kdSBch7bDuzxED oDV9gYfkK3J+n2uP9S5RTnmv6+f6j6evS8L1k4cdxuH0efkd7PD7FryQMw7r WL1jMaOTAAeH1N49d0T9dcuwyIKHQSr8Z3ITHWHv8DTFJRWYaaHm3zYs8HrT bM2jM/VwDDM3t+LAhbZrSMDXbYwAWwoZITR3GfmUADcss7qK95f5vG3asKmb xjzRd/uv4ll8QdmX6yMnCezi/iSvdn4Okd76oQENFASgQU4ikQaH0fMinVxQ kdGJ+nsSvVZaar9fZ339GWKtOfLN7m3XmChINblYd5CeXbeT7HETyRSS0Ttd 8HgrqqNrbhR3gjiV8VzLMI0TfNnGO/vbTzVSgoXBS7T1oY6aqGN1mgMHUYXw 03IziJf2EruY6a9b8DuCzxIhZ3CLjjiiI7zPY3Lj11CA71rGP4NPjSF4Yz9P QMUqmNl6bQTSaPX6GIDSF6JuDI/i+ExIBv/Ji4t4lv5i7pOAx999F705PRv+ 9H208WaeSD11HNNsLs4I/xMsHW717zFAnaHS1eqYUVoHED8lo0P480+XVTUv Dx89QpuqKjAioKCzdwAYPLq+eMRH8KM/81yg40vQL6Dnn6ZxmlX5If/+rXT5 s3o7fDxJq7zAEV7llzFGaTzPF+N4EqeFTxWBNOWGg5E0/DYvMFxsAJyhhscU 5Az1bQqHQDEBoTZKiqpmPwvMouDfv/37YpYCzQawV2uw3mB51ej7fPZLnCW/ gH4TvUjzRpA5th5cqNaTZAJtv62SLDnPsaR9ENuzeJpiUc24uFikWRPksqRm gxE3+9+LtIizSf7tLH+fhuE+z6OfFk3gMmCKwfVilH97uYivk5QgEC9YpjXz A2l6xNlKDWIdD9VJ+lYk3FTvNI5/Eq5jFDAvndmAKqSqRN4uN+VN+VE+vynS i8sq2hhvRqiFRcTY74pFWWk7CFaqpFqfpoh8rBYkpsmXxvqcYKa8ISj4BBYf nqNGbl6xvzXVnKVK64KrSXKgF30zSmdxQdrxFO0oDOjKFaPiP7D+Jcxdp9Hb Usq/shjnYLEtuMw3q6blYoRl1xmAMjHg0E1mGDkG3UxhW1Sj2UB8m1xR7ejn Zy9gj1Fb7o+BVIAYWhwzozMNxjrjnqZfr4xeJhdxFp2iTU2p+4UGWcyP73Nu /iIfL6xKCBsiBSoEkyRGAiis+xgDoxexXsjUY5/UFCJFyflf8Pk6wucclRQx xa+BOZLsnNjpfAELmBHuWOMZi96vk4pcJDyRyCjsSmz7TIwicpZWKT6jUZ0G 6y3iHJGqHXedzxP4z6NHHJyHgEv64ksApwq609MgoHipIwYFCVwGDNEqlaFV Rl8+wt7SI6qHJfZNyF7j3N/pYt00gGuom/7xLLBHRYJwBXCpOYsONqEg+gvx hET34a+qOV2VKEei/pJrUkfrDffa/23+7KeT/xgvCkCr2th8NBg8WrcdqdG6 5YH8H7kO/2/1v0v7YhvqyNbWYTyWv9B4U5Ni1qAgr7623s/jrEzkd3m5Vqc3 UHwI1BqVeYYJL5yYyiCNhZIMksxpmQx01kzViQvKu7OBdhPENW1FC+52diDv wwNP/KY8Mbb9+L+FRJCwNU8M2LcJv8fS6xUUTP6gK2lwri9mOEbrnhbVAG9b yTAKv8GKeuvp/CBLKYKnPxdlxrrHKtejUB9OsKQD5bT6WJTBIQLzN12kUTr5 /AwVCBRdnaG829P7Eg+2Z9rhHv+29l+GbeyJ/x78ElqRFfik9c3JvXGNGsVE 9bcJolaU/nUYq5kMvwub1ZbwLkwXDEW4P27T4MP8FQ6E+NdhrPr8fx+Oalym FVgpkFnq3vhI0vqFmCiU0epfhoP8yf8u7NOwOst559Ejff9plWGzmcoNh29k pBfKLyrQdOw6uf10NlSrrqZ+RVblMkf1gGx4pJG5wrcHORe0FV9rmRp727yL AmLE83KRxRaeDYQ80p3s+18HwEAvmdgD8ZxDYA0P0z+tcDfrpygaoWfLfVZj oBMkwxOf9F8hdHGXxhcX5BDV74Ghv0FR+hti0MWghQ+9uVwHdsanjn2MOurn GMSRnW/AnjKz24ps4xLZvGfNgaD2NtediYZRBqTfzLIb9VCsVI8+LxOd5Ib+ 9qeVencLPR5xsH4HWtmdaSeY5xgE3fxqyAeI9XNzkdRpujpBK3TGC4B0Lryo 7qvtAJPopJKbBHfGsbhJfSiycejZrtwzgBDB2r35bMuFQilm8YEptCuS6yIl 4QBQ+RY4+vHl8DWOQC/ukzJxe1szx30qsUwmPezRcf/02MR+Dtzu9nNknIUH rryZqrS10dAqbutPAJ3oidvfftmsRMLpcf/o2LsENnhZKw+re5njfWI+76u/ fnW6Na0rrSxmqTKLayhqrSyHMjkjKtkxz+feWEp0JNN5dfO190szHoDJaT6X mEPmUn/AT4HhF+XlvY0PsGAH5TMq+ITFrpGJdNyTehaNu2cHxX4NAP20i3hd JcB7uAu81+pbeMSh+yie3dS7M723nDzI9GAaeXubX7aL/nKe1+5TI+YZSTV2 hM+D6WI+2jg9Ot3ErYfL2oGo9JY7wwC/e6LsOwFYuguMx7tH7kEEyAYCH0bo mcYdNtcXfS0Tsf/mKdGqudMhqd2b5RWeEsDHmz0XIE3WCkI5vMpAZE2+7rqz htF5iiGdaqLW0jHb4qw1pf0ZG7mi8mAgFIcFYouY05zH8aHEeJULBENWMseS Ae7SMEw1XzEIkkb9HV94hz+TiHl53e5Q9pGa652JaYc66rsJJfCJwHLyIsod prUbZAbkBL0m988PnIUgxBAyaLc12f08azL+jGuy2zQt+auu5knWxL7SpO5b 4fPg/6aqnz/2SkqglvFqHE2yFm3QG7BZuf45nd2/bo1Af1P6/jWd/XU1ouoc INjVMulaaIqzelCwHxTslnXtrGCvrF/TS9DaTzB3jJ2L1nc+7nrgfFVvuTZe 14VJnzhfzMb28yy9wiGVds4q7B9blQ/om64u367KB7qvqMsHIKAafG8q++dm FkvBt2iu9Xyl1WsdPkAvrdV7T5P87W/luq4B6Vtk2FHp2WiJiUQYnMZuz8kh YJkxD9ShRK5KTU+JBOxEovp4LdOZ0jeXILPLyFD+a8N0Nos1kCWyUKbeTNKY ssqpo0al6NYohqDYWJcabYPFFhoJc3JJJtlNx+k00baVrEJSkAyYyY+frrEU mZlfg3NYtggP9uCDPXjP9uDnZIZmY3AlbvhXthb5v0ohy3bl3Wb7/cg76124 cxEjvdU9oQg01BYMLkrZobA8EGJkgqhonpe7P56+pnIKN2qCN9xMjWaAVAsY NpMBzVyNCQGT4Ua1OTUaMC907L7MTg3DVflq+9szZmoj1kxEvPPJdsGqs3Ah JqMvMUGJzWK0nJYJyE3sVW20hdxshExWIQPoYPmYU07SIQR0dxkNn55dFNRA Xr7pt2D4j42Tt883wxcodeb61HxZ2E/PravgwJ2h4ff6HaR9ZUjTMKasYGOi fgVFWjAHB+uWGpfPrHOfONO9pubUYF+3bQ17i3p3sJzZUHOWGYo3gWVBok3G B420Lhejfo3gnyzcKb/oiF7r1a71b4c9o8sgvamMiSExB/VWRAkerc09nWf0 sMW2mdVNLi/RTKCiWm46Dq0xpvENJZF0cZjkU9jZgcmP6A1ZYNrAX+dJTHnl 1s02JS256MdUaySZmH6aj7uSi7QItGpmZmoGC5OMuZZJwqKXXaKFJ1LboOKz cGZuCTqQ9ob5Q3O3ZIjTeL11du4tOIx3nl4sCp1H9WU6ex8NLy6K5IK/oydz 0cbL4fdWfiCDWFzxU6LEOnCZd22UXBkYWIhG4Q3j2u4sHWXRdg0+TaYjYIUM psJB+UuPCJco9JaLYEQIg54G2OKQYFqDOOL9fXITrXth1y0i/ZUZxz3aiYiU yjCgn/jEaxvCHYRAdlciJFqEihM1hIqk86v9TsEiCKSvNZyg0HcCjJxM5q7U U3UwAJ76ecmOTlR5JQWL7QJOki0buFfWDz8rksZIGh42Q+y8qA6lcHm/LYlK Uf4z9XbNxtLAsTQhVDYmN7CK6Xg5X/8kTmJTtQltYgWYVbgXfzk6ReWMcoDZ nCOjTBPQtpXQVgZmOjsvYp3e02YnIYGqtsXiuJundyidcQ9e5tcOMQRzJd49 HyQSZbYgJnd3C+8i+qWfn/fVlGo8JR/tE9o5WMmt5iZXUpjAkjr1stiYCZjw MimhruR5ZW8snkSU5qSrHU/UkDLu3hSNkNTJZA2CPjVap+ydI4KyP13NavVp c0YiZD9/ZkrEChPN8zwL+OhI0uJvfSfUrgv2ZBXgzyNANLBIik8A+ZAPMzKz CnmEooi2HXnSMJd44RabUCmZKGl/qLNO2lSa6mpSKaN5NHKC+aPR8/tkNrG+ KZIQCF0DgEsJTPmKKVZuUKpjVqZXJKVwoCBJhIT1xdQee1qqwEq2nGr8aV9L kh3EJEY/0Ae5bHWeCt7TBSHUaIelNGzShablu4LVRB1IzdNtPMPszxTWMK7y AlTJYpHcijZe5XdytQlyKR8PSLwVJmjR5Y7TWxF5LJpzW9zdf4eFp/lLHUU6 HnhyOZ53O8ZOjQVbJNoti2Kub85ds1s8I/102VG9pYqMWJ5lF4S6w2FPWF4E tEqcizgzGl1gVv722hrjbxEbXIH1XyJ4X5IiQVoHg6gvnr90NB4S8+ZOwxGE gfzNhSBVTDKm6ObcZCE2tFTEbii7/2rRzF32Fk+fJk46lhqjKv9+VJ9ko4bg 6ATMzi2L3oKkUlExtlnfELsoOnHJakR+4x9asxX0CvMu21PVLf6pJwuVxIu9 GqfTCYyhAFxZCrDrbQa0D/2cW3kVTMW9AAN2lXZLGNXTdlunvBWOcyRTRQRA 5jP+CjzbIhGJpPV1bRSH74RZuI8lttolVUBT1auJsrU797YwlID2GCoUcNCV H7pxQ+sWCHNCGNduRkEtlgw3JxdyD+r/Tc6YtKxMJRwwDT1M9SMPtK9rHpMQ xUiHFz3fU+PzAvg+mfSBTQBe0cmdYjBsRY3v0kkTcsnvFUgmvNNS7cR0ijlx vCZuf+PUCJy7Zp734NMZzmxtVxIC15dlyT2YbwaGMFvCze1IOh4Nj5WdNz11 BMnv0uF1bveLCpjEQVdX1cE9u6oOOrmqcOBamW5xMdvkanJNHXxG19TBg2vK uKYO/ulcU3WF4sEz9Tt7phwue/BNPfimfmPfVO3Qsj//+L6p1uk9+KZcLB98 U+4yWOP9Jr6poGR78E09+Ka6+qZapN1y39TBg29Kf/4pfFON3LDMNxXghI64 /ubOqYM/rnOqGbV7ck65fd3KRL+zc+rgMzinGth5qXOq5m35HZ1TK6XcAXWs g19q77eLft3rGP3qBH42xVwZEYuOx2Xxj9imPexxhdgztbZeWFsjcgcdkDtY ilxXb6NB7iCI3CeVeFtCvL98hP9+9Pz7U85NZCA6vDe6mPfp90a2O3IiRTWy wAUA2+E5u1DdqqymHxvHDhi1NXEWMHtKZc6PfexGhtewTFPC+eed9yOTNL6Y 5SVKofmimOdo45C0LROwZfFrA0MNaQ+QWq5GDA52gqIDflmuTnNIhaZU+Zo+ UbzuOA75jOOyz+66JRQTLV124/Ases1uvo3h2evNLeBLylNz9jrCzP/pbFx5 vgacKP4s0cAmOHJ4BGheJRnOfZYkE3NyWpHaWEms4xTCLoMlE/M0DMRUv37X 0lobTcAkZmYqQ1oAaTnvzuNpmt14uAeze/m5vVwIMpfWXG7Es5jPWkRI6fiB CFJqPJT4AIc9eXpCvckC+AWO0vH7nnJ/c/k29LHxXctswueaegRn+hp4dXIU eZZ0JoK5cEC5gV07zd51ReNmplE3xI7Y0qu5RTy1FSXVeLAZwHa6yKr00noB bh7ztvKUca3WnOGX+Kyb0gCg9p9U10mC6d4v0iv4X4enZkl6cTnKC1Ol8DjE X2U/Bx0YzjqPrqMcJh3PluDJZzywOV59EMtraMBCyuKGrU22ZJHMs3is6jsa RKmXr9SIN1VcVMOz/z0dvvuLCeSn1wmubBC58jo0TyRZP7+e1STA8uU4OUd7 d0sjxcsyjT+k08XUWp58zMkgx9riMPhZRijOV6vSphoJzsedrOk9SuBcSMix jC4xLFISFnFAYvQsXmT5KCCvu6zpCRZY4aqKC35Gs6UFr5RI1OanEr8oKgyy LInVMxpHlLdKcEt6kDueNDFoLGmjeEhC5oa+IlmiZqzvfgwQ3rjIKYv5hAS0 k4LjXY64UUZHVVjyMr5K88LSBXs1coIsw3o3o0Q7QChBZg+zhSmMrcgstBC7 Ec86vfLKZhp3cm1zct1XFk+UOAP1ArTPne+80eVBKYEr5cVlPLnCfCQqP2tM wtFaVd5GRDU8VXtudgUFihy2NhzrXGCAgRmmVYJ3k3mRXqRGmWtPfeMei076 Gy/5DWrYPbzfdbJNmvPNyYvTYPU7OXHScz4CadW8s86cTbQ4Ur6QErkmaoat S4V64hnW6wUJ9IYJYmQmyWSsvTRhG+ctsQM3M+gef6iY67Bk22IGh6tk0NDq KnwLegzMyX5CZllRnMVGrSksUoG3syQCYq4mfJXGuKAxrPN4kcUFqnBOUr60 1Jl+55gPZlbpPLJZDoegIZhfJkgVCtrfO9g/xB3z6NXpyzM8O39MC5BpWGaJ aK7rCkYbWEBz08uiwx8p3PSkznZk3Hx+3jv4DLx3sBLv0URXYkAaoisXKv+G QdnmyiAzNnKjxT7208al7LiUmR4/2d45ZDyHSgs+E9sShXIdyxAzDYUELjOh g6ww5c4SsZitnGmOj4/ZZomtLmbJFlU7dlR3lddGpS8C+nG6FtchbnBgsnnv JhvskhXzDodtk07Zvmyry51dnZ3VjStf/3ioesdf44jH1J2qdaNyUj/ICrdg HfCb49s8aqSnkwtBu2zQZAEVs6/KXP7atthHXFi6VO94WZFhRGOpkynqKimQ 8fjS3vZsrNQHszTkvd2lFHLXpK4e4z7hARJjwqTu+3/ffeJEa5yoBGhchg8m jFAxzGmKSZw0aF1Vfpyg9HXgqz0vtpEHXxzWU1a0kw9j8iXw+sZ8EJh8aKnj qu0BzfGqus/tejq5C28u15dflzJyaO0+oYrQz8lxH30PAK9BkT5V+cqj/WgD yNPfDx9W5rh6Otgd7Ib3wTVIPyqWfAl75jLPajtiAnJtGmcH+87WPS94Yv0J iOWqjB7bHmeVh2p7MNjZ3l4P7WOUiWW0DrJoLLWE+dMed4cFCzlLkGbbLVg/ NQcqOijFHeuOBMw5lF5c4AVIg0xw18wnRNP9Pd2lCwqdL9H4GNb9psDh8UXC l6l8jJFQxnL34jby17jGmc1+f8IRBNI4Lib95ENVxH2sarDCpd8L7oyDQe+I e2uH1qqoAK9hSE/34d+5kkAAgOQ4p5QtduK6qEqnNWKRxx6YZ9kr8mZ5Zry5 2pfSM1KyZ2igOdOPtA7IjFUEhcOrigB9nGuxTESr7cY5isrl2+0dANUUUyTm IBlPIod2WZEgaiPQYy7r2IfONZpC2X6maRc7ZqJDBLiTd2i9T5J5nGFcXYAg OwcOuxkhtbvzdP9xm5jqTjdK5UUrkjrH338eH58OX578eCwbveyBCEXn72zs 6IbGh3d6TK66mA9Ksp2900m0ju0eBxlaI8ZVYEg/VlE5PCa1YxWF0AIkZVmp 9IjOEY7z03jqUWwQekBg43yWwNmSFhNx6v0FzxiHwX7To3B/sB/eUHj2ESuu wDvRx2hvMDh4/Hjvfvhnmc6kAPGaoEstyeK5m7FVFoZ1UNB55mTslAtyCOHW MIwB/PUIpNgPpy+G78ILqN10dQZ856ylOMKSlDxCvyRFjnYqoAnExex1oF44 eKqp/MZr7ytB9ftsuVPs0/0Qfd18vfi9VRgL74jjUhmAdG5TZ+eS0cmM0vV2 8TV2su4S67Ct2ztB/+suE7PzzCyfnYT5hGZp7u+xUY10oQQzwbm+VGN40GsO ppSDnWI3MYxDAWueX7es9crL/Nstb93H1PJgByhUV1lVmEk9yIR/PT80uY5U oSUzYCgHmmS15qsVE1pLXpfSpJmiAxrTHWJ2V60CuZfg6kYg+TCneCJy/ijp QT4gDVu6ExP6NTfbkt/Ye6H26Ah/xCr0yE5sMYS3zF13yx96nzRuEayKftIe fAE43Tr4AmF7l9y/3/W2OXTlPgPd8Vvk3qOk6XSzVLvtdpQp/+q7ISqom6Zr 6wBIKV/VbXBK7m4/3T7EDooHEX+DIbXYf7xHLaIfASAuijkPif58jdTXmn9n TWhnMNjbfXLwZN2ImPvSghBdxosIIbfH5IOZ5osZh556Ft95LgaL6a5STgMX NZhU6YzL6f3O0393adle6qo3Vvd8FDw0zuKCjEdCV5lnMyfS3p6xeL6U3NUO FFc3IxI6gd+VzsksYr3n8Qe+frpYTJspijr1BG/Zf2eSujEcPnFBZUYKqvuA IkGqNNrd59mivPy951PfIYQWS4puO4RNCNTa2YYIcBoVjpCbEc//JJdvaOjX qvtZGovcNHOVh0CohUUry214UCN+ODZHFBK5NlbFJCzxq48zt+pkWy3S5hNN Lr6lKCftDKueJVeRdM54CzYbK85Jb8Vnt57ztTH4NlQ9HbGLTbAku23iyh9I fwi9+vMxaNgedyk76ZNq5cqT6rHPclQd/5OFU/s97fLCOBxYRqPfsT6OZpe0 tENVXTo0hO4W1UUfMFkuRjpFx7r0Mhpjx0o4/HxAV7JpUIf502S/keZdJ0B9 NfNyfn6Py4ngPsN6vjk7/W7lBUVc7rKi/qCeOURTJcveNNH3gFkZO3O3fMye B98cdvu7z/afHTyB/zbeBDSnl605vuR+kBL9nlWoDA4lLAj1D+/F2sbLs2G5 aVyXOPlIVzEmnzUGSM2r8DJw8FzM7rLaxGtXxC0zUdfEgVtiCnfhEYwNy85X dy5kVCQuBAkzG9Zh9Ep19elCkVsFE0y1FY0WFaiNVmTo5O8AYDYmxq379Umr tsotdUi67jw6KNPyHvcmgvsMe/PkrH9ytvLmRGTusjlro/oZUnCyod3JgYI1 Fm06cetnLkEmKCvv0iO+WO9R7/5Ob0v+3O2R2Sw/wL9dMR/y8yob9tnOU/L0 HhF20d+Gr7+PXsRVHL3KJzBRuwS2y5rmg5cm8rQHA7mad7ink2rqtUm27Wgw iHYOnjx5srvz+BaSjYdU7j5V+01i21S4r6gv+PLM24DjOBtLITkuVV5dglDI 6u/jPocw+6kugrZcSaDjyFCUcQSsO4EpLKPfByNSSy5OR4aq2oR6W3okULEe 83j8HrR/P4HHTw3hOA6KihpoEFMQrndtkFZUmEo/c2QUVdE8xk3sazCd88XF Zf123o5YX0lMAuXvUUqik+7+hSQYnCuLSBjqLhIy4DHED79YSm0/b4ioV0Vx n1RFcJ+BrPhvCUqloEfvQfrbZLKYTUCFsa6+Nn58+/Z0c+XVwBncZTlw1E5X d88eHzw99GbVMpGwUBdv5Z74Nc17oXXvQGwMRFz5ZGwKRuwo6W/nVfZUv8JL VtEm4dFyxic1gUmvIuR18KCgTVwJa4PrH7/HxziX+SKbRDwWxmPDyC7e8qpt EJ3hGwgdgui8AfLC/5ulY/3eTk7IpX6aB9eMNfI/hmvGXxnLIaeXxvsZ7y6X CzPPAVivBByA6j+GD9FxdZU7qdVk6yZRpnibuoU3pvS/SoZ0UytUGoP7OwNV qov7PwUVpoHDfimXNZ9XzUCtrChxOY4nQIwsnvV1+HA3J9fwtQk41jEz8nzR y1tBCTDwmb4Zx+OYLvkC+EPbAeCAEf+h6l/mc+/3lohKkV8u7lInynkFwZ9Q QRnhAlApgP2Lm0CP0flEuMT9VZ4o+pWy5BOMZFw2rdrliDVAvZaVpPeoqx10 CdKWCaZGD0mKhBAXZdPultU/uM3qH/yhVv/gYfVXW/1m6fxwC/GZbyHcMeph XKWz1oH4mIYrCLWhtQvVRoZVlWSaY3A36/nOKK1XJnJXIpC9mxIVAm7D9nZQ e/xX2/gqBIGh24FY5LUiHR72eq80gcmNfrCWoDULSz90resEloSx1dFpnfPt gtt82XG7GDcfSrdQtwZ6B6LKLGphk7qOGrErcR3kCxZINtvL+vtRrT7gCtR9 J49ZGDGSwPKigLK0qA3k335EltxektbKDfezfwifQZ0CAhsaN4n7h6vJ3+Zq 0jJsLuMp1bN0RcsSdPu622oiGbtRRcqy85XG/uMnTw75BlLVdD9VyT8eHUl+ k2NMLXYa9Hebjzq1lr5fb+qvnrXb0fCDJ25jxPfg8cFjxvdqj9MCCL6MJiyY g3fjcKfH/aPjTR14I9MzCLj3J5wNUpbFk090llZxcZFU9Ma+u6J7VCQqz5Re Oyk1TQn6g8quKrauhwsfTuHs2q3a6TuCyTkPtLat8bJSHXKCr9S/AMIPRWYB uxWcDmF0E2HwWKjILH8+1acWuPnSs7pFtn73VkvPp+Vyqz4ruu1a4YKLP+F9 R0ittPeamBg/2kW9ZAO2wfBzS7ibcLBX73ufWxE/Hbaj9TqGP8sS2D4EiDwE iDhAVggQCR/zTQpYJ/XrIebkIebk88acOCmJ3M9DyMkdxGOrBncPYSf3EXiy NPTkfoJP7if8pHMASnjb37MY/keJaXFp+F0ud/b0GJuEAazdYiov7DEm5Uoe Url91f76I0fJ1FYTG9zzwv8Dxd14AS0PUTT/klE0xGF132nwuRKtmDZndh/f 4mw2WU0kyIbHDhvzHq4jOIYWfEcRWKFmx3kHYleXdcd/UvP1u/jw8+gr5tGm eh63xk143ynnxC+tVUU3Q77umt99bKvWjaWt6zLaGew2AcDWO4O9Fl2qSPMC 9tvqTHkL49q7CNFjKy6wY8H+0eLRuihAbWeb/aDwzfCVmyzgXCK7lmaQ+O6F 8+pd3Rm5NaRWePOO9xs2DP887pLW/LsXOqWTXXvKeclZplg7ZprCKB/qL2AD F/bqWes0HRe5/7a1MVkowOfMhOaVrspog3du05SQJJmESCv2MOutlPMt9Jcp lJvLIjWl93yKL+mfpxPoTbsXsABt8DouSA1/IXVTog1AoT1R7MHg6SCQLBY5 UlOz+D2oqfMhWlQU4lnuUO0hOz2WjYbGSV5UfwAq8s0ypdVH9a6oUy/wvNg7 q1fYJLpeTmQNKXm8FXdWqjqhlfcbCeynT3rngNOLoyM6aXGQStLZ8fqJTc6s rZC5UZn01Zt9Ja1nyUVepW7BWHsjWYxxYw0NkEOzNTBokD8AC2CGASdpV9vG yUBF6bJxjj/MOTcrUl9G8JdPFyfAS/50inVZOFU+xlJNmEAmpEqgWIIKzKB8 gnHQyh5hx75KaWrHD0oAAt6Um/7ni5nngvltFmHnqbUKn/wjUMyz5qNQYrN1 uiyg8YV9PAqEsW03ySytmKlzE0ndYKNBk/aFxrHFq6NT5+tssLrvPSYMpunW Yt/521Jn5ONcb5VXPlO8+jXZtVpVr/q65fF0+XrRNclcJUCF83U4wbOlrPiL LVJiX8UoTmaxxYMboCdtRtNkfBlD66nrF7nf1XTrElpallwuKwXHrCBdKwMs ri283JSXMIATnQDTjQMQRYnhuWr50nimRhfo+qqmGMihRTEOR4Y1Rlwtj7da Hm31qdt8uodaGbXUc86tmEOsVtuzY3iVZyWsVDlPYo/MN4bdXT+bsxJcqxzQ ckSG26Fb0IpVN1ltCA9MIKYQdkQftmoa5A7946H+qx5w1+LJt1Pd4dYjCEui 2WACWBIiXwRDB1e9SxCSWlD5ZqDtORJ+mgIN7uuE5Y85Z580UOXOZisMsUBz 3jkASvVl8ykg3axscOx+mVlPnAx/A6WKm7nD2w1S3bRcRbgPj6wh7vegDtSl KeJz9Nhak1I33FbRQ/dWXuy7QfQGpdF1iqV/ODu0zrpbO8bZpqF7RN9nPhg8 kmn9h8Kro/tbuRjxUj67YWjWPMyLvLDUW574nPD1by5bd6AhIhbIojxk6n51 SdJwGmrvXobaG9D1TvIhxnKI6E+GLeDvS3W60EWpqp5QL9yn4Pl9Q9zpTmp5 wnHHHct8gRm3KWrWXUO+3liabNt0qr2ss9hM2rRy3N1xrvFdqyXubn8EbkFT kzGgVGXt+vPBpisabt8FtKr0LPZa4ImiEs11YreV11Vgde3gEFi3uvBnPakl rKyPzh5kreXndcOjXThyQFiHsq7B2bU04ZqbVLWq4vElRnNF47QYL0Ce+o85 rTtn78XqkqybS18Mhx+Jfh3cZ8aeWjIa2VTDV755pBnRUM7i7aDN1Mlqarui bLKc6npsfYFB0cRFQQvw6DLNJoB36S/1ZQpHSDG+bNExXCzmBuhYATVaWGDB uX3fdpV38OmpUQC2OPLSGRzYqfKtsXpjSHUqzUtd+XwrSgYXgy0MpUFkkg8V 3VUUifjNLJXx6Jj76ZLTymVXomI8POKIO663qK6JTd90htF1sYhP0TCIVlhw gt2EZ8NTj2OB9rPq+tBsnr7aPCG/gPMeFqnu0JM9MhG5IVqVNbv2tl48InCR 0D38Yp7PuOAbk3N1nMuva2wIY8w4zpbFM5qNSGGPFW8tbdwi5VZ/1/nYIef3 UN60+CWjVWS6RRF/VbLder11d/Mbm4B1s348bletRRpJlJsRmRzwpRV+XaZU mM9wJ6jLfKDjKgiCV1iezV1ZB/0+oK1PJX+iocLyrRPd6zzRZUXodbnypZXU P+8p89lPF29YgBwe0rMPm7j6yJSDL+v2ojeYtGgakczZ7gOOgFev0wnWgA2M yK6EauEbhQ2FckY3sDU7uAPVhnn17ocGpyywaHk1PtTI1Q/xn/Ny+SEOjZZj 89f8LOwzrw0o2kvHx7MIWDS1xgGUj9WC7uml5Gu1fvaydrRhgL6sHFaq5EKy Fj7BV+reIL7KTbiSBBd3jYfp0iAn/PiX8PagGvDXXrdP3r/b3wrhHaFGEWZu KjDZKxIy/+qjdXmFzjWD++pCxC530IxrwDAbEhh9p0w+843h0cvNMD/G42xF fgRYnfnRgh7ix3PtpbszW+Kh/bKVL8OD1dlzqU0VLy5IL1l/NLs+VCpPaf0t hnpAxRlOJlZximbzSeRq39ak6uvUZqtbWX85Ub3uDeQy3ncpcn5kKKDqKDgr 6rk7jfHYH587B6Va9tqqd6ysYauuQiZjhvlHilPxZbV8TrYz3D6J/fODFOFx 3eDsxAn0Zz5JhCPIzdMbDKwmXNX3URnPD+H/++rb3pKTl8eNPQWKJNENuxpR HIA1Iiq5V4s8xJoMs6QS6CWrwkx5o8pPEuAsL41XPF51jV/qdb3H9RxyZzYj JX6zFDOebroai9GCjtB3jxkaWWkPy023VrSciy6FDt6TfcCQBV13XhQuekDT kJarIR2XtRc7ZeJ62batDOM3ykh/h2jXgr2UfVNhB9n61mnX3swSjDOeYm0E sbB1UVldybF5+0q4uI4qtevtdLzFcUXBbUWAntVX0Ja2Ow8mW78mI/j//siS gtbi1oIiHjv82sFbhH4fbQSLE8cEGN7R+fJp7dPan47evDiOjl+/OPvz2v+F z9ra2hf6zg51qhK9zhyDsbZGl+ClvoHiRyrJxCqKWiXTOUaKqdmN+M0XOo1/ lcvGvcET3I3fnPRfDNKkOseFBUD94nz8dH/7ySgtP30a4Fhgk9DvPKl1fikH LRcZFeBQUT0TfDrHr2WUS20N4zAvZuq5eqL0TIyRSmMCQu9SJli3Ob6g17rG MN6i11wgr5BKr4/fHb15/R3g/s3b744Odvd3Pn0iH8Xb4zP7l6fb+9uAM4Zp lYnlzriMrxIVU4NRBjHboIlVqoxvLDbYo3d29hcFcH/38e6nT1vRu5dnMsT+ /gF+o14E/vWHkyP1y7PtbRh8k/BSA9Jo0wVFmXs38BRUhqRVL8Qj97WIp0vz i8SN18OjV5sw3L8jIntIBYSiriRU7cgEpsSKFgq6caWoLq5Vuv6OC01SDpDQ dASEC2VtzYtElOwEgz9HSqeL8Y30FWwy8vo0wNHPbHIdOcQeXfSUzio9fSw8 Q8VnzItu4iNWBZi51GtFYHOb8WQ7IqBr2CSIzaMxJn2gv3A/0F/RBlfFUT5M vNDaUhYVPwFaIxFAZWQ2B5HiHQsJdRs4VlsQaZHAn/T2Gmh6tchAb8aREBBg Sm5c8Ucms6u0yGcktQD4T+hgtmmiOC6ZgGRgDOm1AZKKZuA05mPcxQ6FYL6g jTNHZzjQnbc3gslrASd4fhFzYvHzi5gmkZyfQxe8rhOszZjkAleykBQZfhTH NYox3h74osLCv4yywYsGsfhNaAb/D0eJEC3N6N+HxA69dtujd4iNDjkAyHIX ylMabXSY5SF8kFGUaE5n59mCNCIsF0+WG1fWwtLBdGvv3g7HciCQHH9PxZD/ //aedjluG8n/egrs+IfsRHQsxVKcufKpFK+TeC9OuaLs1lalvFvUDDXiejRk yBnJiqXXuhe4F7tufDa+SJDjZLMpsSqxhkQ3gEajP4BGo4KutWpShUZE8gvn PR3HByKurHnorlkDrJYlnqjfE169/lXR/VoJLkYXSfXYZ1CcQGqmcJ0IlvDs cqpuYAKT9CaTeHCigE+wzhcLHqv5Qcv+qm7z60W2LvJW2iQg7rn8x5HJZ4r6 JyubGLgKIXqqaKKYSDRupmkIZhB0IX+HgcpNiRE4ApER9Ti1y3OhUuEbaC1+ MRfKHD5UYrJIdEC0PbP4t+cvre6hsudXrAPVmzJfPtpDA5FH5pBxWap4WnnQ VhpHRN9r9mDVlQr8RlN6hXckw3t+fRb0/1Ra0t+hJS3xnyxgcnDN9vD0u5NH 8qZ5PrMYHlnO5zDzZRilIewM4+0N64Eq53EpOffhV8W13puaUhxC4WA3UE/w EzENNAXq3qxQDFRN+QvaCHyY9uhp6Vyu2SvzVoS5yZ2wefHzBigI9howRbmu Gr6bgp1voLXmzI0ad2tlBreOV4tCnpk+rYzrC5J6zjmHcHJIznviFxFFJHCf +BUH4NcXG25VlDyvbr7itFXRwNgsxclSOKO1sijWe/g/KaT3pL5bVWsuGLGr j0LS4PFvJjzNFP2rP9qiafx6b14jH+h52c6WFY8vN4uecjBxzpmgl13iTu1K kWBt6OzyHuxaGyeqOZbIwHobTEwAjKllW3mVg3vUFOJkA9nvVIpasiXfxMCe IOPpkxY62y5jfxY94pFtKFLo1qmvxhUCPScVa9JgDBGcD1ZDy/cwxdy9KGtJ BSFiMiViJB38WI1eYoiKUepXiyavodsovloj/7la5zOPi0Ip7vj2s+GUR0o9 IKwlRgj5ytW/UN+D4VudwxslOE0GGDFddnZOoV0NmK6EMx/uni1qzL6BWVvw X0wbgP+CA7W7F+39I6Tdjdj9lebr/hdfgBF/7pso9abBBQqYOictH8Y9tXih ZrWUDHLDXqVKkK7SzHKVOJNvWpnywvg+hzjWph1Q17Kt9nxlLs888X/FSZvi fY2aei1InLdyPYELr5PTF69eMcFzIpMXOgDVuSgLBS7AtJiDPAC1I+FkaXbN j1jl5/BzzhY8d1nDvVVMulnVNyR3La42GXMZiSxRVSCzUc59W13jyCm9qqrA Iw7VWhlMxqpWqQz0miQldLEELVvMcuxIqXFIshgPmCt3QaB5wbWgGCQtRKX3 dPTlIfhIwFsfPsCIZfAfMEFr+dpOIJZ0HWU0kpj9PCpTHAJegBIQsRrgL786 +f7E85WB+fl7GTsBbpHA0xSLslXuspbJ7K8/vFJL05NVO0GJKUo2YgxKbs/w z69e/vg1+/vr79gPssBEMvfnR8+e3d2BYOaePBQHpDD3Nw0mgV+fT/lySDt9 f7mcrtrpDWjIKXGwuSMlMKJy4qvqs/VUuIuvXp5+w3U/1Auvvv/s5L+kOlVd 4x1AlcKbhmuTbY3R7XJZYSA5qCpWZOHvXvN33DvHKmxCCTIcPTkAj1hSjYCa +PQJUyCEWIgPuuZQ5HvVkWGEfMNTXk0ZM6/4YZWcm8vAvUiMY0AvqC7XZqYi D9vf4ZFky7KMH7xHNnsp/IOWfXiATCzdhfYOvj1gf3vz3enOznfgimxaLYwE U4tyMEHqcrZWEql4n62rupJ0YjDxyPkvEi5Uix2nhy9e7ouAq5cHIO1lPTlI L5mjxJzcPCvAepXePF+HkuINg5HkirBWcGrGc2d8iUbQDdcsS558TNNFA8qF 7huJUlXFL1oG32qleEUsHzwWgyseluftlX1Q+3GGz2P9l37MK+D5x/IFPLfs DZDh0+fPn3/KrEe8evPyAIoY3I93bqHX+58KpJ9Onh4+mdxyNPjwtH5M/ryF j/sTVRKpfLuzC3/uYoF/gMbnH3Y1sH7wp/koS+7uWN+dHy/QcfC+4S8O9hUn 6nT/4POn8suuTZ1dDSKLHh598YxQeufDlD2Q/MXAuFsWzyc/wt/LanGjmHgC YyYWefNluVg9n8wKPA8zuRMLf6AM1AaBWNqDmR30Gf2VTuBoardJRWFMqkqu +3FuFpsSeq2VO1rFe5AM/Hih4q7WMBefONJDpT0GyunFyvAeSjuZyuVgXAgW Sb7lGgN8+UmOmNk0EPtKUyiNLrEuak5zTCxTWGOXH2Ha5HUrM2k5H+EzLq0j ct5mElYwr9b7P0/sIyMT8dLFgVjyRRbDNMuulvlq4p4+mczwNRj0AHN4+MT6 GgkgIF2WTOF29nK9gVf7gI9WN8FtrroAPsxmRaZ9dp8Y9NNPTnv9SIzJ2XW0 0/CpRgMejBSv59j3skGogydPnz2BZ+KUsMM13lJqeP2a8X7Vf6h+YdiR1wka PxTiQfI90M1QRwHIAGC00T/fiJ//PAl0DvlfRcUESVMBfT0oN/LmbQqjW1t6 b/eUsOgRD7Nsn0oFsq2En78uG9yK0uKIFu2QQ+K7JXn0l7epMkgIULP1hO1B tTLxu7zX2cGDjg6e8hP2v6MeojYM9FAM6o7YdvOVZT5TqhIVkcgiDUY1X1Q4 eZHnp0o16kXqgkc5g9GFNolUecqtn8sVuZBjJTKVOLZgPgMrNQO7vLnhbilr y8sS14D4K0ujksMCvPIDXxVaG3dT5GCfgdUAcwamHCzkG+6UTl3mholrVoQM UvkNROI+mYlvLZR8g3sydYRLjofKs/BHCubNegG4qe2Zf+coTlw9H4O9qn3U 5hetxWVPp3+OFeA3gReQYj/JGGDGHghKVmMSpFoEHMxYBa5RwFxh6hLZn4OO kLEJpk0Ih1TchnBNiA4jwqcl+eirobAiYtuoXQHOdW9U9fLuu+/edtIzZl38 YTvMzQ6/d7bhEWR2y/YIkYBFqeCAS3nXb4xIUBUiI8Ckiz8VU6gDjFgyiYYM fzyCMpemXiEqr6gKfBvRflr9KDUoHUUZuKXCFX4o2rpagcv28HXRtujGfVXN bx6hctRLqb7GcxbyrcVvFXTJY3usqGd16uqs2qzmIS+QqsyYDuSRS6AEtdgJ aUIVhhURnFf1srUVZF67/BbQLlJL4h8P9gNivEOXyhKORpUDH1AI1CSbnKhz VkDSQLXENdY5MADqm5dPPjv6LNROk/+D0kcRtr64CcA01dIruVmVoebwBEiZ OH0GRWGu82CNID2jupwNVOesR6v1DWeITu4oiJNw4UGQpxf1Sh+eGsaVPj0Q T4eO3NPHB4PHblktcIcyAGcZLtF5gTYD//YbjFagbxEblz4xHZjHLFyrFG4G OSK+LgJkVsU7lMIINbnjfUiT4NlBogzHDNJUFGNQpi/XHzwwx2B3dl6t/ADj tVpctN0aZAExPBg5h4uzPISGVyOlvAqpbOX+pl4LN6G3D1+8PJAr34ePeL73 qpELiWrzXsf78PtkScJlfk5W7G+1NJxXBnSQg7jq1CoJ9cXLQUQqvaDHJmdw eC1ysAOW7GQBNdzlQSDMvdtl1XDvdlH4wOKOxXvCtzqwWVCfrveZp0N0pknM REF5N2ROBIRlUrcP/5O7fRjqdlxHaJEV0A86kQOKfFvAYf24XX+BiSoxghL3 5ksRBkcTKlRCtv+qpvjyc/ixrS3+9PDZFwn2273ldm+5/QaWmzXPAjPzq1Lc BvOGzjQ0Y7hxxr7eLJfsRwzu+/Dg5EX2PViB+OvOmoUikmNqBVfsmLNEkaNE PHiNfZplzXXPAVFe8FaV5cc/dRRdZm430OU02kDWJFP8E/ZTOX9LYHQN5Rx/ ivgnDydd1tkaWTwF5Pao/fPBW+N08hV1IWRRhOK12ZgBUNSbmsnFd3780X0I llCbRIi2+nwbK0Ha6vRPtNWth5ZAqXYMv8hx/lAxfgW7f3353bFdWDeR3JHs lWB+IZdktGw3BaPdc4CJtjoeDMxP42X88MFNpKDhNx4vLQt/QuqRV0v3wasD CRYen8z6p/pbwQkArq36qsJwko/RVAtPR1PVk95UUY+8Ir11Bo4xkZA3bzMR 6NmJhDMbeKb+MwCJfV8PbU90/jgYcKXP78cQDDxv1kVV+1h4Sv/u9rcZOvMN 1OWAy/yf3dC49phV1ytvLPprrpuiLlbzbLGszuzBTKkZr3jLFNug+NPNT4Iu 10VWnWdVUy7KVR+DAifzk7xTXo8E6sRf1ldH2chKOGxyTU0xxzhQfuRHefTF HKSnzZgxOXob5mP81M99RmyI1JSEA1IGAS+Qx8tw7dtVY3WYkqQakY6oDxSM BG5srS+gi3ixAGKQ4eRHT/ugxTGHIstnRFWQFK998HigNMfRLQFCtb2z4YY8 HCaoL2nJd0VR53jW6lhi3j/qA0EqcOwxEFEMTyt4Wh5fRtW8Lw+7+EjCNEWe KcOEPzwieV7h5SDZz5t8HgEUt4NSwRPpvWGhZZv3848UUOLiyT6uljOe35wb uHL241NK5WjnD30TAeIZKizp3F9RmLIfh1T8dkv/HsePSqjIxNHfxYWg+hqh Y93FAPMYQ24lHDMLqg8IZ9ocNSSF6gM6X27aC6d13bytVKEZuIAGlgKNXzIZ uJrRHQE2YgQ0jLnPLKKYpYTJL4nrLyUf5mm1U7KaptGC9BIv1/gJtJCCRm7n 0kP6+UEIKnYN1XEnlHvtkjutnoWA1AU4IdNQV9Wz/qBSmdB1iHy2pTcqg9vs diVk3rGxGM/YzlxDDRXXjeYpf1jIGZFdMItQsnXZfzukUXSRJcu50yq9fB1q Bu11tA1y3ey4p5jd1GHtrEyqWQdxJZv5SXczq7RmVts185pmEzLOZIinlMsv Yl3tpQtSIouuXmiXYlbMkdkiMkpyMF9/9UeYbOqRj7c2mOaAsAjUpFvm7ToT p7gRRFg03I5cCcvLIzbZ9fPFdpVWPRtcfcdiSGiknHS6gdy5lhbRi5RmST1E WrOdmEZeaDDuJdofjPKXe4mmJ1FkGkZtJBoYT926VZhsH14hTa6HVZ2J5PqP jkOlBMLpw7qqH0W+G+6mHj7mNrjpxAgWRD9KKHScjJKn/UFfKIZXd1uXPO7C a0i5T7QJH1npC+OglPMeWDLWFFb+LXmhG8fBFvUfjKhfiStxUywWWhR+NT43 90yKn8uVMyfYiDmhYdqkOcGGTSGWMoUYKRefQvrvyBQKUJxOIddA9jH6UyiA smcK2ShjU0j/zYJTKNrUcVPIgx3Bwi6OIVPIgx1av+QMUEZyu9tlDU5s+Lze gK5a6lKRKeYV7JjxyXpFg9RtsQEPsGyCaHUjrmZ66ni+tl/6PG+yYsUB+OV0 8eox+PbjV/xJQsXvl3nwsymxKi150dkCQ0+0KjEuOnkcbFBzXR92wrnBL8hG 4Iv681WxDjqqTies0OdVZrG/4Tg3AEKiiNi2wok8a8r5gqT4PO6AcAOcSBM9 CEUnYtDhVOAbJCIXocETMPCWMEV1vIXlu1tf3AWGALAkZXx78rLAPZlsWa7e 8ZSlkeUHUiy8lUgLK983ZPA61yoE7lAI0ePz8PBGRqqsr55aVMMXd75IMztf glmDJqVm6aunUaYWvtJ5+T5bFqvF+sLiXucJ6B57VQg3gWYmWibWqG7T5aGD JaDr+WSc38BglTN/OhJMql2ccwOIyNwWO3xBbLR1ohhu5sj69QiwqJVDalG5 b2L1aGbTKYAk+sK3i3yhpvpbV3zjH/9xXGgfUgPL0uZ1RDQEgcXGRpDJfJBE 7ozVhft9Ybb3IdSTVJXkGh1tM7+Y1d1MgyUyGmfXyz8eRAw/6UV4i8lrTEo7 NBHt0t105NgxdddNB1o6QlJhEPX6a4wTJ6VoVrD9quV6KmnaF00b7AntQxAq DjSw7yM6LsYY00HPjFAIOg+WMCAbwCFREICwN+DoEzUWAmSLzlD9M7HfFHvn LcIogf3lSx8JXcqMFFRP+jLnLdHgR64GP4qYOzENHqDPUXhrb0sNzgZocNqo 7oCwTg2uRyKowR1idmlw/Udcg9MiIzW4V0tIg9NCLEmDOxDeOMQ1uA/J0jV4 B3BMgwdBErkzVldEgwch1JNUVa8Gp1X0a3BaOk2DOxDqiQaJ2I1JaQfr1+A+ HcMaPEjvBC0WhFPPkHGKaHD6R5oGd/5I0+DOHwP7PqLjvRrcaUifBmcxiAEa 3MfRpcHpky4DKPYRGtxHEtHgoWfoRuWvEWFNnv5ga/L0qFknQB3a4YasO7vo kV50b6hToDjdiTAYZDNR7KHYjX4qiPkUQTnL21k+L+YZ7kcIK8lVw9aAoR1q igJF4Qf0+v06u6jqYOSk6nXnmo3fMMRLuqiN4HgEJAXFhfDYGmFo1ET7RRF3 qdYvb0d8xeMTNUBnlI4DoYFUpGi8nCJtRwQpRdgtWfqr6Qhsv7Wo2TEHmIWR jZoMlLK1tWSbMBShoAGfzyPxDd1I++MNAsDDoh8Cje0IhrAnoCw9pq1sq7Ya t2+g6FBPn7PomDVh0XHUHTw9THSwgaKDDRUdbLDoYImig6WKDopwuOiwq0k8 E9MnOpjFGeNEBxsqOli/6KCl+kSH0+Vh09ECHjkdTWN7RYdTekxb2ci2Su7/ iCfnAoWiJ+doGwafnKPA9goWBQ7LCgo7+NSdpcG6Tt05VBt86s6BTzx156n/ lKNsTlWDT91Fmtpz6s7j4/SmWuM+/NQdRTL61J1tyow5dUcxjDt1RzEMPXVn tX/wqTsLeuCpO4v8g0/dUejhp+4s6J4DcTaDpp26o/iTTt1FKuk/dWdxz9hT d87MHXbqzhUbyafuHO3TderOqWPIqTsHdOCpOwd68Kk7B37IqTuXPPHDQ7SG lFN3DkjvqTt3ols3/ETXXqL80MMQzHTFuo0pXlxDPKy4CncXcJ2yTK5+5tWj vnIOV2d5lczXPo68wjuU+BVKvQ0kP/W9S1P9Vxafh3YXL+eH6X2Ewr95AyM7 WH5pRrjCDWzrnkFBFJ567LTzfBTibq8sXy4wVvrispde5Ok/J7gqysXFWYXJ PZriskKBI0Ry0HdXooUWtOqLxhI6KIZa0BrQmPmxZSj+gBcpLqMmvgP5+zM0 /+OVjMmMkWCgU7qPyYlxa9qXmhCDcEdiigkjh0akwvBa2J8HgzBvYgu3tMWZ xUoj019sY4Vr8NGJL8bZ36bZY1JejLO8NeCoZBdjbW4D2p+BQvFfco6LAaZ2 CH1SdostjWxGTYGheS0cQyQxqUWSbU2xD0xnoeGG57LQoGMSWdyawRiUxaLX mKa4E/NX6PIpZrRpw4BtqqgdbT/dW1Pb7Hh71knvrpN6xq0bJ7kZPbRJoUaf g+E0KO5d0E5HXQtayGl5ml8RRNDpVDgQ6kk12L1uBd2JYLO6fYmP3a64F2FX MNyFiMGn+g9BeM95YInGRef2QfKeyK2NbsAmw+22uyEDtkLG74NssQnyx8os 1F7kl/yskZ8DCPuU6e+B3vlIwMQBXYu3pqOF1b2RQwriy4RNFKdr/4aMSbeJ imeM1klWOWn6xlE20F5zO3fHSgptRda3zDNCLkealbbGs9XqzlbrOuOEcp9E ThPHI2XxdoI4VQqPFMFbyN/7fGX3gorZrbgXVA7wvaD6HQiq+2yB/65sgffS 7/ch/e4F2H+0APsY6TY7G2nVJDcHmXkCM1tDnOWzd3i5dGElpezcxjS1lc16 ky+T06lQWJX5qncPxUB46UTxCYoX1sXINp1jjKz/HsbIFthgdjFN62Bkp9yw lrHBLZOLNSZJq6ZJwrq62r/iSVo/YT/Ni1acNfWPsym1JAvYbU7jqbbaNLMi uKkunsDWugYefUCtb6Ge/DF0id6lYDDNrSBQr2joSncriBOwqDV0V9rbfuiu 9LcaOjbvu9Lg9ldtWy5/Cg2NawDg6yT9TsHBjipnm2UlpuK9VPpNpFJbzDao RDzRZO5EsiSUeR1OrUTMV38EdSme9kl0Lbx36rZBSZKQbHwov8VyJegj7apc nAUDF0H1iK7bQdKLjRVg5CB3tBeaILpozCK3n56JqvjEyumn31+uNxGp4qXy loiuZnilPL/20Fwsb5/kWvHLtrOzaytjudGaCgrUobxG/q1dTtcmP4sP4Wzm FivZCQG8QcCpO6vMwXMW4gQoAA2D/9Mz58zjBl1Y7q24SczDxUsl+bG4iVWI lj9rB5UvBuIvBuKvB+KvE/DzkalARzXBcWEO7eKImEO1hJJFMs4iGWedjLOO 4DQzbcZnWh2badVmfT/V7qfa/VTbcqr9XNn7QPA7PJ/IrZBtZGKQIsDb9BpJ mpOC2aNiw0VSUvgwIaOFefwxxGjx65iD0zOzw6DD0kFa7rMZLtvIW9Wt7KR2 sWWIkJEiQMjAPZcOPR3wMECYrA5ohKzek0TWxOtJPmvzWl1qLP6G/3YoNcQ1 IbTT6ovqGAv0Tvao86oLv9dpnSN3w+Ilsiezd6vqGrwH3uF258NUBE8X8+eT 83zZFnjX7I8XZcvm1WzDiXK2KZfzlqGT8uFPP3z94sv9Zwd3dwy0lnpx8OX+ 3d1jhMsxsmRdsdfVuoT/NYti1YILvsKR5rdIN8VVWVxzYJzH2AYbMG/W5Yp9 9a//+9/m3RLUpoZELwvatK6aVmLZY9/AS/a6bC+anJeDX0XeLG8YLl3CpNAF /1IVS/ZtvqytttiFdr4pN21Rg3r9uqxms2qZ65JV3VrosPk/bNqWfQue9LK4 0QXB1SMFrZ79T/PLTfvLujpnp7/kzbvqupz9ouFOL4oaJP7cA8QCr/OLor1g fynW8A6qzlelBjz5swb5f8i00fOGBQMA[rfced] Please review the "type" attribute of each sourcecode element in the XML file to ensure correctness. If the current list of preferred values for "type" (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free to let us know. Also, it is acceptable to leave the "type" attribute not set. --> <!-- [rfced] Throughout the text, the following terminology appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. Hold Time vs. holdtime Network Slice Service vs. Network Slice --> <!--[rfced] Abbreviations a) Both the expansion and the acronym for the following terms are used throughout the document. Would you like to update to using the expansion upon first usage and the acronym for the rest of the document for consistency? attachment circuit (AC) Customer Edge (CE) Layer 2 VPN (L2VPN) Layer 3 VPN (L3VPN) Provider Edge (PE) Service Attachment Point (SAP) b) FYI - We have added expansions for the following abbreviation per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Class of Service (CoS) --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>