<?xml version='1.0'encoding='utf-8'?>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-teas-attachment-circuit-20" number="9834" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.25.0 -->version="3" xml:lang="en" updates="" obsoletes=""> <front> <!--[rfced] In the RFC's title, we suggest removing the single quotes and hyphens. Other expansions of "ACaaS" in the document and the related documents would be updated accordingly. Is the suggested title acceptable? (This is similar to how "Software as a Service (SaaS)" typically does not appear with hyphens when used as a noun.) Original: YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) Suggested: YANG Data Models for Bearers and Attachment Circuits as a Service (ACaaS) --> <title abbrev="ACaaS">YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)</title> <seriesInfoname="Internet-Draft" value="draft-ietf-opsawg-teas-attachment-circuit-20"/>name="RFC" value="9834"/> <author fullname="Mohamed Boucadair"role="editor">role="editor" initials="M." surname="Boucadair"> <organization>Orange</organization> <address> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="Richard Roberts"role="editor">role="editor" 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>OPSAWG</workgroup>month="August"/> <area>OPS</area> <workgroup>opsawg</workgroup> <keyword>Slice Service</keyword> <keyword>L3VPN</keyword> <keyword>L2VPN</keyword> <keyword>Automation</keyword> <keyword>Network Automation</keyword> <keyword>Orchestration</keyword> <keyword>service delivery</keyword> <keyword>Service provisioning</keyword> <keyword>service segmentation</keyword> <keyword>service flexibility</keyword> <keyword>service simplification</keyword> <keyword>Network Service</keyword> <keyword>3GPP</keyword> <keyword>Network Slicing</keyword> <abstract><?line 117?><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 a "bearer".</t> <t>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).</t> <t>The document also specifies a YANG service data model for managing bearers over which ACs are established.</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 125?> <section anchor="introduction"> <name>Introduction</name> <section anchor="scope-and-intended-use"> <name>Scope and Intended Use</name> <t>Connectivity services are provided by networks to customers via dedicated termination points, such as Service Functions (SFs) <xref target="RFC7665"/>, Customer Edges (CEs), peer Autonomous System Border Routers (ASBRs), data centers gateways, or Internet ExchangePoints.Points (IXPs). A connectivity service is basically about ensuring data transfer received from or destined to a given termination point to or from other termination points. The objectives for the connectivity service can be negotiated and agreed upon between the customer and the network provider. To facilitate data transfer within the provider network, it is assumed that the appropriate setup is provisioned over the links that connect customer termination points and a provider network (usually via a Provider Edge (PE)), allowingsuccessfullydata to be successfully exchanged over these links. The required setup is referred to in this document as an attachment circuit (AC), while the underlying link is referred to as a "bearer".</t> <t>When a customer requests a new service, the service can be bound to existing attachment circuits or trigger the instantiation of new attachment circuits. The provisioning of a service should, thus, accommodate both deployments.</t> <t>Also, because the instantiation of an attachment circuit requires coordinating the provisioning of endpoints that might not belong to the same administrative entity (customer vs. provider or distinct operational teams within the same provider, etc.), providing programmatic means to expose 'Attachment Circuits'-as-a-Service (ACaaS) greatly simplifies the provisioning of services delivered over an attachment circuit. For example, management systems of adjacent domains that need to connect via an AC will use such means to agree upon the resources that are required for the activation of both sides of an AC (e.g., Layer 2 tags, IP address family, or IP subnets).</t> <t>This document specifies a YANG service data model ("ietf-ac-svc") for managing attachment circuits that are exposed by a network to its customers, such as an enterprise site, an SF, a hosting infrastructure, or a peer network provider. The model can be used for the provisioning of ACs prior to or during advanced service provisioning (e.g., IETF Network Slice Service defined in "A Framework for Network Slices in Networks Built from IETF Technologies" <xref target="RFC9543"/>).</t> <t>The "ietf-ac-svc" module (<xref target="sec-ac-module"/>) includes a set of reusable groupings. Whether a service model that wants to describe the attachment circuits associated with the service reuses structures defined in the "ietf-ac-svc" or simply includes an AC reference (that was communicated during AC service instantiation) is a design choice of these service models. Relying upon the AC service model to manage ACs over which services are delivered has the merit of decorrelating the management of the (core) service from the ACs. This allows upgrades (to reflect recent AC technologies or new features such as new encryptionschemes,schemes or additional routing protocols) to be done in just one place rather than in each (core) service model. This document favors the approach of completely relying upon the AC service model instead of duplicating data nodes into specific modules of advanced services that are delivered over an attachment circuit.</t> <t>Since the provisioning of an AC requires a bearer to be in place, this document introduces a new module called"ietf-bearer-svc" that"ietf-bearer-svc", which enables customers to manage their bearers (<xref target="sec-bearer-module"/>). <!--[rfced] In the second sentence below, does the customer retrieve "a reference" or "an indication" or something else? Original: The customers can then retrieve a provider-assigned bearer reference that they will include in their AC service requests. Likewise, a customer may retrieve whether their bearers support a synchronization mechanism such as Sync Ethernet (SyncE) [ITU-T-G.781]. Perhaps: The customers can then retrieve a provider-assigned bearer reference that they will include in their AC service requests. Likewise, a customer may retrieve a reference if their bearers support a synchronization mechanism such as Sync Ethernet (SyncE) [ITU-T-G.781]. --> The customers can then retrieve a provider-assigned bearer reference that they will include in their AC service requests. Likewise, a customer may retrieve whether their bearers support a synchronization mechanism such as Sync Ethernet (SyncE) <xref target="ITU-T-G.781"/>. An example of retrieving a bearer reference is provided in <xref target="ex-create-bearer"/>.</t> <t>An AC service request can provide a reference to a bearer or a set of peer Service Attachment Points (SAPs) specified in "A YANG Network Data Model for Service Attachment Points (SAPs)" <xref target="RFC9408"/>. Both schemes are supported in the AC service model. When several bearers are available, the AC service request may filter them based on the bearer type, synchronization support, etc.</t> <t>Each AC is identified with a unique identifier within a provider domain. From a network provider standpoint, an AC can be bound to a single or multiple SAPs <xref target="RFC9408"/>. Likewise, the same SAP can be bound to one or multiple ACs. However, the mapping between an AC and a PE in the provider network that terminates that AC is hidden to the application that makes use of the AC service model. Such mapping information is internal to the network controllers. As such, the details about the (node-specific) attachment interfaces are not exposed in the AC service model. However, these details are exposed at the network model per "A Network YANG Data Model for Attachment Circuits"specification<xreftarget="I-D.ietf-opsawg-ntw-attachment-circuit"/>.target="RFC9835"/>. "A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits" <xreftarget="I-D.ietf-opsawg-ac-lxsm-lxnm-glue"/>target="RFC9836"/> specifies augmentations to the L2VPN Service Model (L2SM) <xref target="RFC8466"/> and the L3VPN Service Model (L3SM) <xref target="RFC8299"/> to bind LxVPN services to ACs.</t> <t>The AC service model does not make any assumptions about the internal structure or even the nature of the services that will be delivered over an attachment circuit or a set of attachment circuits. Customers do not have access to that network view other than the ACs that they ordered. For example, the AC service model can be used to provision a set of ACs to connect multiple sites (Site1, Site2, ..., SiteX) for a customer who also requested VPN services. If the provisioning of these services requires specific configuration on ASBR nodes, such configuration is handled at the network level and is not exposed to the customer at the service level. However, the network controller will have access to such aviewview, as the service points in these ASBRs will be exposed as SAPs with 'role' set to 'ietf-sap-ntw:nni' <xref target="RFC9408"/>.</t> <t>The AC service model can be used in a variety of contexts, such as (but not limited to) those provided in <xref target="examples"/>:</t> <ul spacing="normal"> <li> <t>Create an AC over an existing bearer<xref target="ac-bearer-exist"/>.</t>(<xref target="ac-bearer-exist"/>).</t> </li> <li> <t>Request an attachment circuit for a known peer SAP (<xref target="ac-no-bearer-peer-sap"/>).</t> </li> <li> <t>Instantiate multiple attachment circuits over the same bearer (<xref target="sec-ex-one-ce-multi-acs"/>).</t> </li> <li> <t>Control the precedence over multiple attachment circuits (<xref target="sec-ex-prec"/>).</t> </li> <li> <t>CreateMultiplemultiple ACs bound toMultiplemultiple CEs (<xref target="sec-multiple-ces"/>).</t> </li> <li> <t>Bind aslice serviceSlice Service to a set of pre-provisioned attachment circuits (<xref target="sec-ex-slice"/>).</t> </li> <li> <t>Connect an enterprise network to a provider network using BGP (<xref target="sec-cus-bgp"/>).</t> </li> <li> <t>Connect a Cloud Infrastructure to a service provider network (<xref target="sec-ex-cloud"/>).</t> </li> <li> <t>Interconnect provider networks (e.g., <xref target="RFC8921"/> or <xref target="I-D.ietf-grow-peering-api"/>). Such ACs are identified with a 'role' set to 'ac-common:nni' or 'ac-common:public-nni'. See <xref target="sec-peering"/> to illustrate the use of the AC model for interconnection/peering.</t> </li> <li> <t>Manage connectivity for complex containerized or virtualized functions in the cloud (<xref target="sec-cloudified-nfs"/>).</t> </li> <li> <t>Manage AC redundancy with static addressing (<xref target="sec-bfd-static"/>).</t> </li> </ul> <t>The document adheres to the principles discussed in "Service Models Explained" (<xref section="3" sectionFormat="of" target="RFC8309"/>) for the encoding and communication protocols used for the interaction between a customer and a provider. Also, consistent with "A Framework for Automating Service and Network Management with YANG" <xref target="RFC8969"/>, the service models defined in the document can be used independently ofNETCONF/RESTCONF.</t>the Network Configuration Protocol (NETCONF) / RESTCONF.</t> <t>The YANG data models in this document conform to the Network Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t> </section> <section anchor="positioning-acaas-vs-other-data-models"> <name>Positioning ACaaS vs. Other Data Models</name> <t>The AC model specified in this document is not a network model <xref target="RFC8969"/>. As such, the model does not expose details related to specific nodes in the provider's network that terminate an AC (e.g., network node identifiers). The mapping between an AC as seen by a customer and the network implementation of an AC is maintained by the network controllers and is not exposed to the customer. This mapping can be maintained using a variety of network models, such as an augmented SAP AC network model <xreftarget="I-D.ietf-opsawg-ntw-attachment-circuit"/>.</t>target="RFC9835"/>.</t> <t>The AC service model is not a device model. A network provider may use a variety of device models (e.g., "A YANG Data Model for Routing Management (NMDA Version)" <xref target="RFC8349"/> or "YANG Model for Border Gateway Protocol (BGP-4)" <xref target="I-D.ietf-idr-bgp-model"/>) to provision an AC service in relevant network nodes.</t> <t>The AC service model reuses common types and structures defined in "A Common YANG Data Model for Layer 2 and Layer 3 VPNs" <xref target="RFC9181"/>.</t> <section anchor="why-not-use-the-l2sm-as-reference-data-model-for-acaas"> <name>Why Not Use the L2SM as a Reference Data Model for ACaaS?</name> <t>The L2VPN Service Model (L2SM) <xref target="RFC8466"/> covers some AC-related considerations. Nevertheless, the L2SM structure is primarily focused on Layer 2 aspects. For example, the L2SM does not cover Layer 3 provisioning, which is required for the typical AC instantiation.</t> </section> <section anchor="why-not-use-the-l3sm-as-reference-data-model-for-acaas"> <name>Why Not Use the L3SM as a Reference Data Model for ACaaS?</name> <t>Like the L2SM, the L3VPN Service Model (L3SM) <xref target="RFC8299"/> addresses certain AC-related aspects. However, the L3SM structure does not sufficiently address Layer 2 provisioning requirements. Additionally, the L3SM is primarily designed for conventional L3VPN deployments and, as such, has some limitations for instantiating ACs in other deployment contexts (e.g., cloud environments). For example, the L3SM does not provide the capability to provision multiple BGP peer groups over the same AC.</t> </section> </section><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>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 meanings of the symbols in the YANG tree diagrams are defined in "YANG Tree Diagrams" <xref target="RFC8340"/>.</t> <t>LxSM refers to both the L2SM and the L3SM.</t> <t>LxNM refers to both theL2NML2VPN Network Model (L2NM) and theL3NM.</t>L3VPN Network Model (L3NM).</t> <t>LxVPN refers to bothL2VPNLayer 2 VPN (L2VPN) andL3VPN.</t>Layer 3 VPN (L3VPN).</t> <t>This document uses the following terms:</t><dl><!--[rfced] FYI, we have reformatted some of the definitions in the "Conventions and Definitions" section to reflect what appears in RFCs-to-be 9833 and 9835. Please review and let us know any changes. --> <dl spacing="normal" newline="false"> <dt>Bearer:</dt> <dd> <t>A physical or logical link that connects a customer node (or site) to a providernetwork. Anetwork.</t> <t>A bearer can be a wireless or wired link. One or multiple technologies can be used to build a bearer (e.g., Link Aggregation Group (LAG) <xref target="IEEE802.1AX"/>). 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 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 attachmentcircuit. Onecircuit.</t> <t>One or multiple attachment circuits may be hosted over the same bearer (e.g., multiple VLANs on the same bearer that is provided by a physical link).</t> </dd> <dt>Customer Edge (CE):</dt> <dd> <t>Equipment that is dedicated to a customer and is connected to one or more PEs via ACs.</t></dd> <dt/> <dd><t>A CE can be a router, a bridge, a switch, etc.</t> </dd> <dt>Provider Edge (PE):</dt> <dd> <t>Equipment owned and managed by the service provider that can support multiple services for different customers.</t></dd> <dt/> <dd><t>Per "Provider Provisioned Virtual Private Network (VPN) Terminology" (<xref section="5.2" sectionFormat="of" target="RFC4026"/>), a PE is a device located at the edge of the service network with the functionality that is needed to interface with the customer.</t></dd> <dt/> <dd><t>A PE is connected to one or more CEs via ACs.</t> </dd> <!--[rfced] We note that the definitions for "Network controller" and "Service orchestrator" in RFC-to-be 9835 each have an additional sentence that does not appear in the definition in this document. Should this sentence be added? (Specifically, "One or multiple..." and "A service orchestrator may interact..." are the additional sentences.) This document (current): Network controller: Denotes a functional entity responsible for the management of the service provider network. ... Service orchestrator: Refers to a functional entity that interacts with the customer of a network service. A service orchestrator is typically responsible for the attachment circuits, the PE selection, and requesting the activation of the requested service to a network controller. RFC-to-be 9835: Network controller: 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. ... Service orchestrator: Refers to a functional entity that interacts with the customer of a network service. 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. A service orchestrator may interact with one or more network controllers. --> <dt>Network controller:</dt> <dd> <t>Denotes a functional entity responsible for the management of the service provider network.</t> </dd> <dt>Network Function (NF):</dt> <dd> <t>Used to refer to the same concept as Service Function (SF) (<xref section="1.4" sectionFormat="of" target="RFC7665"/>).</t></dd> <dt/> <dd><t>NF is also used in thisdocumentdocument, as this term is widely used outside the IETF.</t></dd> <dt/> <dd><t>NF and SF are used interchangeably.</t> </dd> <dt>Parent Bearer:</dt> <dd> <t>Refers to a bearer (e.g., LAG) that is used to build other bearers. These bearers(called,(called child bearers) inherit the parent bearer properties.</t> </dd> <dt>Parent AC:</dt> <dd> <t>Refers to an AC that is used to build other ACs. These ACs(called,(called child ACs) inheritththe parent AC properties.</t> </dd> <dt>Service orchestrator:</dt> <dd> <t>Refers to a functional entity that interacts with the customer of a networkservice. Theservice.</t> <t>A service orchestrator is typically responsible for the attachment circuits, the PE selection, and requesting the activation of the requested service to a network controller.</t> </dd> <!--[rfced] Since "L2VPN" and "L3VPN" are defined prior to these terms listed and to make the definitions more concise, may we update to "LxVPN"? Note that this would also match the text in RFC-to-be 9835. Original: Service provider network: A network that is able to provide network services (e.g., Layer 2 VPN, Layer 3 VPN, or Network Slice Services). Service provider: An entity that offers network services (e.g., Layer 2 VPN, Layer 3 VPN, or Network Slice Services). Perhaps: Service provider network: A network that is able to provide network services (e.g., LxVPN or Network Slice Services). Service provider: An entity that offers network services (e.g., LxVPN or Network Slice Services). --> <dt>Service provider network:</dt> <dd> <t>A network that is able to provide network services (e.g., Layer 2VPN,VPN (L2VPN), Layer 3VPN,VPN (L3VPN), or Network Slice Services).</t> </dd> <dt>Service provider:</dt> <dd> <t>An entity that offers network services (e.g., Layer 2 VPN, Layer 3 VPN, 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">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">vpn-common</td> <td align="left">ietf-vpn-common</td> <td align="left"> <xref target="RFC9181"/></td> </tr> </tbody> </table> </section> <section anchor="relationship-to-other-ac-data-models"> <name>Relationship to Other AC Data Models</name> <t><xref target="ac-overview"/> depicts the relationship between the various AC data models:</t> <ul spacing="normal"> <li> <t>"ietf-ac-common"(<xref target="I-D.ietf-opsawg-teas-common-ac"/>)</t><xref target="RFC9833"/></t> </li> <li> <t>"ietf-bearer-svc" (<xref target="sec-bearer-module"/>)</t> </li> <li> <t>"ietf-ac-svc" (<xref target="sec-ac-module"/>)</t> </li> <li> <t>"ietf-ac-ntw"(<xref target="I-D.ietf-opsawg-ntw-attachment-circuit"/>)</t><xref target="RFC9835"/></t> </li> <li> <t>"ietf-ac-glue"(<xref target="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-data-models"> <name>Sample Uses of the Data Models</name> <section anchor="acs-terminated-by-one-or-multiple-customer-edges-ces"> <name>ACs Terminated by One or Multiple Customer Edges (CEs)</name> <t><xref target="uc"/> depicts two target topology flavors that involve ACs. These topologies have the following characteristics:</t> <ul spacing="normal"> <li> <t>A CE can be either a physical device or a logical entity. Such 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.</t> </li> <li> <t>An AC service request may include one or multiple ACs, which may be associated to a single CE or multiple CEs.</t> </li> <li> <t>CEs may be either dedicated to one single connectivity service or host multiple connectivity services (e.g., CEs with roles of SFs <xref target="RFC7665"/>).</t> </li> <li> <t>A network provider may bind a single AC to one or multiple peer SAPs (e.g.,CE#1CE1 andCE#2CE2 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.</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.,CE#3),CE3), distinct PEs (e.g.,CE#4),CE4), etc. The network provider uses this request to decide where to terminate the AC in the provider network (i.e., select which PE(s) to use) and also whether to enable specific capabilities (e.g., Virtual Router Redundancy Protocol (VRRP) <xref target="RFC9568"/>). Note that placement constraints may also be requested during the instantiation of the underlying bearers (<xref target="sec-bearer"/>).</t> </li> </ul> <figure anchor="uc"> <name>Examples of ACs</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="304" width="512" viewBox="0 0 512 304" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,80 L 8,112" fill="none" stroke="black"/> <path d="M 8,160 L 8,192" fill="none" stroke="black"/> <path d="M 72,64 L 72,96" fill="none" stroke="black"/> <path d="M 72,144 L 72,176" fill="none" stroke="black"/> <path d="M 112,80 L 112,176" fill="none" stroke="black"/> <path d="M 176,112 L 176,144" fill="none" stroke="black"/> <path d="M 192,32 L 192,104" fill="none" stroke="black"/> <path d="M 192,152 L 192,224" fill="none" stroke="black"/> <path d="M 200,112 L 200,144" fill="none" stroke="black"/> <path d="M 280,208 L 280,240" fill="none" stroke="black"/> <path d="M 288,248 L 288,272" fill="none" stroke="black"/> <path d="M 304,208 L 304,240" fill="none" stroke="black"/> <path d="M 352,64 L 352,112" fill="none" stroke="black"/> <path d="M 352,144 L 352,192" fill="none" stroke="black"/> <path d="M 360,32 L 360,56" fill="none" stroke="black"/> <path d="M 360,200 L 360,224" fill="none" stroke="black"/> <path d="M 376,64 L 376,112" fill="none" stroke="black"/> <path d="M 376,144 L 376,192" fill="none" stroke="black"/> <path d="M 448,80 L 448,112" fill="none" stroke="black"/> <path d="M 448,160 L 448,192" fill="none" stroke="black"/> <path d="M 480,192 L 480,272" fill="none" stroke="black"/> <path d="M 504,64 L 504,96" fill="none" stroke="black"/> <path d="M 504,144 L 504,176" fill="none" stroke="black"/> <path d="M 192,32 L 360,32" fill="none" stroke="black"/> <path d="M 24,64 L 72,64" fill="none" stroke="black"/> <path d="M 352,64 L 376,64" fill="none" stroke="black"/> <path d="M 464,64 L 504,64" fill="none" stroke="black"/> <path d="M 72,80 L 112,80" fill="none" stroke="black"/> <path d="M 376,80 L 400,80" fill="none" stroke="black"/> <path d="M 424,80 L 448,80" fill="none" stroke="black"/> <path d="M 376,96 L 400,96" fill="none" stroke="black"/> <path d="M 424,96 L 448,96" fill="none" stroke="black"/> <path d="M 8,112 L 56,112" fill="none" stroke="black"/> <path d="M 176,112 L 200,112" fill="none" stroke="black"/> <path d="M 352,112 L 376,112" fill="none" stroke="black"/> <path d="M 448,112 L 488,112" fill="none" stroke="black"/> <path d="M 112,128 L 136,128" fill="none" stroke="black"/> <path d="M 160,128 L 176,128" fill="none" stroke="black"/> <path d="M 24,144 L 72,144" fill="none" stroke="black"/> <path d="M 176,144 L 200,144" fill="none" stroke="black"/> <path d="M 352,144 L 376,144" fill="none" stroke="black"/> <path d="M 464,144 L 504,144" fill="none" stroke="black"/> <path d="M 376,160 L 400,160" fill="none" stroke="black"/> <path d="M 424,160 L 448,160" fill="none" stroke="black"/> <path d="M 72,176 L 112,176" fill="none" stroke="black"/> <path d="M 376,176 L 400,176" fill="none" stroke="black"/> <path d="M 424,176 L 448,176" fill="none" stroke="black"/> <path d="M 8,192 L 56,192" fill="none" stroke="black"/> <path d="M 352,192 L 376,192" fill="none" stroke="black"/> <path d="M 448,192 L 488,192" fill="none" stroke="black"/> <path d="M 280,208 L 304,208" fill="none" stroke="black"/> <path d="M 192,224 L 280,224" fill="none" stroke="black"/> <path d="M 304,224 L 360,224" fill="none" stroke="black"/> <path d="M 280,240 L 304,240" fill="none" stroke="black"/> <path d="M 288,272 L 376,272" fill="none" stroke="black"/> <path d="M 400,272 L 480,272" fill="none" stroke="black"/> <path d="M 24,64 C 15.16936,64 8,71.16936 8,80" fill="none" stroke="black"/> <path d="M 464,64 C 455.16936,64 448,71.16936 448,80" fill="none" stroke="black"/> <path d="M 56,112 C 64.83064,112 72,104.83064 72,96" fill="none" stroke="black"/> <path d="M 488,112 C 496.83064,112 504,104.83064 504,96" fill="none" stroke="black"/> <path d="M 24,144 C 15.16936,144 8,151.16936 8,160" fill="none" stroke="black"/> <path d="M 464,144 C 455.16936,144 448,151.16936 448,160" fill="none" stroke="black"/> <path d="M 56,192 C 64.83064,192 72,184.83064 72,176" fill="none" stroke="black"/> <path d="M 488,192 C 496.83064,192 504,184.83064 504,176" fill="none" stroke="black"/> <g class="text"> <text x="412" y="68">(b1)</text> <text x="412" y="84">AC</text> <text x="40" y="100">CE1</text> <text x="364" y="100">PE</text> <text x="412" y="100">AC</text> <text x="480" y="100">CE3</text> <text x="412" y="116">(b2)</text> <text x="148" y="132">AC</text> <text x="188" y="132">PE</text> <text x="272" y="132">Network</text> <text x="360" y="132">|</text> <text x="412" y="148">(b3)</text> <text x="412" y="164">AC</text> <text x="40" y="180">CE2</text> <text x="364" y="180">PE</text> <text x="412" y="180">AC</text> <text x="480" y="180">CE4</text> <text x="412" y="196">(b3)</text> <text x="292" y="228">PE</text> <text x="388" y="276">AC</text> <text x="20" y="292">(bx)</text> <text x="48" y="292">=</text> <text x="84" y="292">bearer</text> <text x="124" y="292">Id</text> <text x="144" y="292">x</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .--------------------. | | .------. | .--. (b1) .-----. | +----. | | +---AC---+ | | CE1 | | | |PE+---AC---+ CE3 | '------' | .--. '--' (b2) '-----' +---AC--+PE| Network | .------. | '--' .--. (b3) .-----. | | | | | +---AC---+ | | CE2 +----' | |PE+---AC---+ CE4 | '------' | '--' (b3) '---+-' | .--. | | '----------+PE+------' | '--' | | | '-----------AC----------' (bx) = bearer Id x ]]></artwork> </artset> </figure> </section> <section anchor="separate-ac-provisioning-vs-actual-service-provisioning"> <name>Separate AC Provisioning vs. Actual Service Provisioning</name> <t>The procedure to provision a service in a service provider network may depend on the practices adopted by a service provider. This includes the workflow put in place for the provisioning of network services and how they are bound to an attachment circuit. For example, a single attachment circuit may be used to host multiple connectivity services. 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 bearer or an attachment circuit to be put inplace,place and then refer to that bearer or AC when requesting services that are bound to the bearer or AC. <xreftarget="I-D.ietf-opsawg-ac-lxsm-lxnm-glue"/>target="RFC9836"/> specifies augmentations to the L2SM and the L3SM to bind LxVPN services to ACs.</t> </section> <section anchor="sample-deployment-models"> <name>Sample Deployment Models</name> <t><xref target="_u-ex-c"/>showsillustrates an exampleto illustrateof how the bearer/AC service models can be used between a customer and a provider. Internals to the provider orchestration domain (or customer orchestration domain) are hidden to the customer (or provider).</t> <t>Resources that are needed to activate an AC (e.g., Layer 2 or Layer 3 identifiers) are typically imposed by the provider. However, the deployment model assumes that the customer may supply a specific identifier (e.g., selected from a pool that was pre-provisioned by the provider) in a service request. The provider may accept or reject such request.</t> <figure anchor="_u-ex-c"> <name>Example of Interaction Between Customer and Provider Orchestrations</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="240" width="544" viewBox="0 0 544 240" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,48 L 8,80" fill="none" stroke="black"/> <path d="M 8,160 L 8,224" fill="none" stroke="black"/> <path d="M 96,96 L 96,112" fill="none" stroke="black"/> <path d="M 96,144 L 96,160" fill="none" stroke="black"/> <path d="M 192,48 L 192,80" fill="none" stroke="black"/> <path d="M 192,160 L 192,224" fill="none" stroke="black"/> <path d="M 368,48 L 368,80" fill="none" stroke="black"/> <path d="M 368,160 L 368,224" fill="none" stroke="black"/> <path d="M 448,96 L 448,112" fill="none" stroke="black"/> <path d="M 448,144 L 448,160" fill="none" stroke="black"/> <path d="M 536,48 L 536,80" fill="none" stroke="black"/> <path d="M 536,160 L 536,224" fill="none" stroke="black"/> <path d="M 24,32 L 176,32" fill="none" stroke="black"/> <path d="M 384,32 L 520,32" fill="none" stroke="black"/> <path d="M 208,64 L 352,64" fill="none" stroke="black"/> <path d="M 24,96 L 88,96" fill="none" stroke="black"/> <path d="M 104,96 L 176,96" fill="none" stroke="black"/> <path d="M 384,96 L 440,96" fill="none" stroke="black"/> <path d="M 456,96 L 520,96" fill="none" stroke="black"/> <path d="M 8,160 L 88,160" fill="none" stroke="black"/> <path d="M 104,160 L 192,160" fill="none" stroke="black"/> <path d="M 368,160 L 440,160" fill="none" stroke="black"/> <path d="M 456,160 L 536,160" fill="none" stroke="black"/> <path d="M 200,174 L 256,174" fill="none" stroke="black"/> <path d="M 200,178 L 256,178" fill="none" stroke="black"/> <path d="M 312,174 L 360,174" fill="none" stroke="black"/> <path d="M 312,178 L 360,178" fill="none" stroke="black"/> <path d="M 192,192 L 272,192" fill="none" stroke="black"/> <path d="M 296,192 L 360,192" fill="none" stroke="black"/> <path d="M 200,206 L 360,206" fill="none" stroke="black"/> <path d="M 200,210 L 360,210" fill="none" stroke="black"/> <path d="M 8,224 L 192,224" fill="none" stroke="black"/> <path d="M 368,224 L 536,224" fill="none" stroke="black"/> <path d="M 24,32 C 15.16936,32 8,39.16936 8,48" fill="none" stroke="black"/> <path d="M 176,32 C 184.83064,32 192,39.16936 192,48" fill="none" stroke="black"/> <path d="M 384,32 C 375.16936,32 368,39.16936 368,48" fill="none" stroke="black"/> <path d="M 520,32 C 528.83064,32 536,39.16936 536,48" fill="none" stroke="black"/> <path d="M 24,96 C 15.16936,96 8,88.83064 8,80" fill="none" stroke="black"/> <path d="M 176,96 C 184.83064,96 192,88.83064 192,80" fill="none" stroke="black"/> <path d="M 384,96 C 375.16936,96 368,88.83064 368,80" fill="none" stroke="black"/> <path d="M 520,96 C 528.83064,96 536,88.83064 536,80" fill="none" stroke="black"/> <polygon class="arrowhead" points="456,160 444,154.4 444,165.6" fill="black" transform="rotate(90,448,160)"/> <polygon class="arrowhead" points="456,96 444,90.4 444,101.6" fill="black" transform="rotate(270,448,96)"/> <polygon class="arrowhead" points="360,64 348,58.4 348,69.6" fill="black" transform="rotate(0,352,64)"/> <polygon class="arrowhead" points="216,64 204,58.4 204,69.6" fill="black" transform="rotate(180,208,64)"/> <polygon class="arrowhead" points="104,160 92,154.4 92,165.6" fill="black" transform="rotate(90,96,160)"/> <polygon class="arrowhead" points="104,96 92,90.4 92,101.6" fill="black" transform="rotate(270,96,96)"/> <g class="text"> <text x="264" y="36">Bearer/AC</text> <text x="92" y="52">Customer</text> <text x="256" y="52">Service</text> <text x="316" y="52">Models</text> <text x="444" y="52">Provider</text> <text x="64" y="68">Service</text> <text x="132" y="68">Ordering</text> <text x="424" y="68">Service</text> <text x="480" y="68">Order</text> <text x="444" y="84">Handling</text> <text x="100" y="132">Provisioning</text> <text x="452" y="132">Provisioning</text> <text x="284" y="180">Bearer</text> <text x="76" y="196">Customer</text> <text x="132" y="196">Site</text> <text x="284" y="196">AC</text> <text x="420" y="196">Provider</text> <text x="488" y="196">Network</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .--------------------. Bearer/AC .------------------. | Customer | Service Models | Provider | | Service Ordering | <-----------------> | Service Order | | | | Handling | '---------^----------' '--------^---------' | | Provisioning Provisioning | | .----------v-----------. .---------v----------. | |========Bearer=======| | | Customer Site +----------AC---------| Provider Network | | |=====================| | '----------------------' '--------------------' ]]></artwork> </artset> </figure> <t><xref target="_u-ex-r"/>showsillustrates an exampleto illustrateof how the bearer/AC service modelsthatinvolve a third party. This deployment model follows a recursiveapproachapproach, but otherClient/Serverclient/server alternative modes with a third party can be considered. In a recursive deployment, the Service Broker exposes a server to a customer for the ordering of AC services, but it also acts as a client when communicating with a provider. How the Service Broker decides to terminate a recursion for a given service request or create child service requests isdeployment specific.</t>specific to each deployment.</t> <figure anchor="_u-ex-r"> <name>Example of Recursive Deployment</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="144" width="584" viewBox="0 0 584 144" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,48 L 8,80" fill="none" stroke="black"/> <path d="M 96,48 L 96,80" fill="none" stroke="black"/> <path d="M 232,48 L 232,80" fill="none" stroke="black"/> <path d="M 320,48 L 320,80" fill="none" stroke="black"/> <path d="M 448,48 L 448,80" fill="none" stroke="black"/> <path d="M 576,48 L 576,80" fill="none" stroke="black"/> <path d="M 24,32 L 80,32" fill="none" stroke="black"/> <path d="M 248,32 L 304,32" fill="none" stroke="black"/> <path d="M 464,32 L 560,32" fill="none" stroke="black"/> <path d="M 104,64 L 224,64" fill="none" stroke="black"/> <path d="M 328,64 L 440,64" fill="none" stroke="black"/> <path d="M 24,96 L 80,96" fill="none" stroke="black"/> <path d="M 248,96 L 304,96" fill="none" stroke="black"/> <path d="M 464,96 L 560,96" fill="none" stroke="black"/> <path d="M 24,32 C 15.16936,32 8,39.16936 8,48" fill="none" stroke="black"/> <path d="M 80,32 C 88.83064,32 96,39.16936 96,48" fill="none" stroke="black"/> <path d="M 248,32 C 239.16936,32 232,39.16936 232,48" fill="none" stroke="black"/> <path d="M 304,32 C 312.83064,32 320,39.16936 320,48" fill="none" stroke="black"/> <path d="M 464,32 C 455.16936,32 448,39.16936 448,48" fill="none" stroke="black"/> <path d="M 560,32 C 568.83064,32 576,39.16936 576,48" fill="none" stroke="black"/> <path d="M 24,96 C 15.16936,96 8,88.83064 8,80" fill="none" stroke="black"/> <path d="M 80,96 C 88.83064,96 96,88.83064 96,80" fill="none" stroke="black"/> <path d="M 248,96 C 239.16936,96 232,88.83064 232,80" fill="none" stroke="black"/> <path d="M 304,96 C 312.83064,96 320,88.83064 320,80" fill="none" stroke="black"/> <path d="M 464,96 C 455.16936,96 448,88.83064 448,80" fill="none" stroke="black"/> <path d="M 560,96 C 568.83064,96 576,88.83064 576,80" fill="none" stroke="black"/> <polygon class="arrowhead" points="448,64 436,58.4 436,69.6" fill="black" transform="rotate(0,440,64)"/> <polygon class="arrowhead" points="336,64 324,58.4 324,69.6" fill="black" transform="rotate(180,328,64)"/> <polygon class="arrowhead" points="232,64 220,58.4 220,69.6" fill="black" transform="rotate(0,224,64)"/> <polygon class="arrowhead" points="112,64 100,58.4 100,69.6" fill="black" transform="rotate(180,104,64)"/> <g class="text"> <text x="152" y="36">Bearer/AC</text> <text x="376" y="36">Bearer/AC</text> <text x="52" y="52">Customer</text> <text x="136" y="52">Service</text> <text x="196" y="52">Models</text> <text x="272" y="52">Service</text> <text x="360" y="52">Service</text> <text x="416" y="52">Model</text> <text x="508" y="52">Provider</text> <text x="48" y="68">Service</text> <text x="276" y="68">Broker</text> <text x="488" y="68">Service</text> <text x="544" y="68">Order</text> <text x="52" y="84">Ordering</text> <text x="264" y="84">B2B</text> <text x="296" y="84">C/S</text> <text x="516" y="84">Handling</text> <text x="16" y="132">B2B</text> <text x="52" y="132">C/S:</text> <text x="124"y="132">Back-to-back</text>y="132">Back-to-Back</text> <text x="232" y="132">Client/Server</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .--------. Bearer/AC .--------. Bearer/AC .-------------. | Customer | Service Models | Service | Service Model | Provider | | Service |<-------------->| Broker |<------------->| Service Order | | Ordering | | B2B C/S | | Handling | '--------' '--------' '-------------' B2B C/S:Back-to-backBack-to-Back Client/Server ]]></artwork> </artset> </figure> <t><xref target="_u-ex"/> shows the positioning of the AC service model in the overall service delivery process, with a focus on the provider.</t> <!--[rfced] Figure 5 uses "CE#1" and "CE#2", while other figures in the document use "CE1" and "CE2". May we update the CEs in Figure 5 to match the other figures in the document? If so, both artworks (svg and ascii-art) will be updated accordingly. --> <figure anchor="_u-ex"> <name>An Example of AC Model Usage (Focus on the Provider's Internals)</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="688" width="512" viewBox="0 0 512 688" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,608 L 8,624" fill="none" stroke="black"/> <path d="M 48,592 L 48,608" fill="none" stroke="black"/> <path d="M 96,480 L 96,496" fill="none" stroke="black"/> <path d="M 104,368 L 104,384" fill="none" stroke="black"/> <path d="M 120,576 L 120,640" fill="none" stroke="black"/> <path d="M 136,400 L 136,464" fill="none" stroke="black"/> <path d="M 136,512 L 136,528" fill="none" stroke="black"/> <path d="M 176,320 L 176,352" fill="none" stroke="black"/> <path d="M 176,480 L 176,496" fill="none" stroke="black"/> <path d="M 208,144 L 208,160" fill="none" stroke="black"/> <path d="M 208,256 L 208,272" fill="none" stroke="black"/> <path d="M 208,400 L 208,568" fill="none" stroke="black"/> <path d="M 232,368 L 232,384" fill="none" stroke="black"/> <path d="M 272,64 L 272,128" fill="none" stroke="black"/> <path d="M 272,176 L 272,240" fill="none" stroke="black"/> <path d="M 272,288 L 272,320" fill="none" stroke="black"/> <path d="M 296,368 L 296,384" fill="none" stroke="black"/> <path d="M 336,144 L 336,160" fill="none" stroke="black"/> <path d="M 336,256 L 336,272" fill="none" stroke="black"/> <path d="M 368,320 L 368,352" fill="none" stroke="black"/> <path d="M 368,400 L 368,568" fill="none" stroke="black"/> <path d="M 384,576 L 384,640" fill="none" stroke="black"/> <path d="M 424,368 L 424,384" fill="none" stroke="black"/> <path d="M 456,608 L 456,624" fill="none" stroke="black"/> <path d="M 496,592 L 496,608" fill="none" stroke="black"/> <path d="M 224,32 L 320,32" fill="none" stroke="black"/> <path d="M 224,64 L 320,64" fill="none" stroke="black"/> <path d="M 224,128 L 320,128" fill="none" stroke="black"/> <path d="M 224,176 L 320,176" fill="none" stroke="black"/> <path d="M 224,240 L 320,240" fill="none" stroke="black"/> <path d="M 224,288 L 320,288" fill="none" stroke="black"/> <path d="M 176,320 L 368,320" fill="none" stroke="black"/> <path d="M 120,352 L 216,352" fill="none" stroke="black"/> <path d="M 312,352 L 408,352" fill="none" stroke="black"/> <path d="M 120,400 L 216,400" fill="none" stroke="black"/> <path d="M 312,400 L 408,400" fill="none" stroke="black"/> <path d="M 112,464 L 160,464" fill="none" stroke="black"/> <path d="M 112,512 L 160,512" fill="none" stroke="black"/> <path d="M 120,576 L 384,576" fill="none" stroke="black"/> <path d="M 24,592 L 48,592" fill="none" stroke="black"/> <path d="M 472,592 L 496,592" fill="none" stroke="black"/> <path d="M 48,608 L 120,608" fill="none" stroke="black"/> <path d="M 384,608 L 456,608" fill="none" stroke="black"/> <path d="M 8,624 L 32,624" fill="none" stroke="black"/> <path d="M 456,624 L 480,624" fill="none" stroke="black"/> <path d="M 120,640 L 384,640" fill="none" stroke="black"/> <path d="M 224,32 C 215.16936,32 208,39.16936 208,48" fill="none" stroke="black"/> <path d="M 320,32 C 328.83064,32 336,39.16936 336,48" fill="none" stroke="black"/> <path d="M 224,64 C 215.16936,64 208,56.83064 208,48" fill="none" stroke="black"/> <path d="M 320,64 C 328.83064,64 336,56.83064 336,48" fill="none" stroke="black"/> <path d="M 224,128 C 215.16936,128 208,135.16936 208,144" fill="none" stroke="black"/> <path d="M 320,128 C 328.83064,128 336,135.16936 336,144" fill="none" stroke="black"/> <path d="M 224,176 C 215.16936,176 208,168.83064 208,160" fill="none" stroke="black"/> <path d="M 320,176 C 328.83064,176 336,168.83064 336,160" fill="none" stroke="black"/> <path d="M 224,240 C 215.16936,240 208,247.16936 208,256" fill="none" stroke="black"/> <path d="M 320,240 C 328.83064,240 336,247.16936 336,256" fill="none" stroke="black"/> <path d="M 224,288 C 215.16936,288 208,280.83064 208,272" fill="none" stroke="black"/> <path d="M 320,288 C 328.83064,288 336,280.83064 336,272" fill="none" stroke="black"/> <path d="M 120,352 C 111.16936,352 104,359.16936 104,368" fill="none" stroke="black"/> <path d="M 216,352 C 224.83064,352 232,359.16936 232,368" fill="none" stroke="black"/> <path d="M 312,352 C 303.16936,352 296,359.16936 296,368" fill="none" stroke="black"/> <path d="M 408,352 C 416.83064,352 424,359.16936 424,368" fill="none" stroke="black"/> <path d="M 120,400 C 111.16936,400 104,392.83064 104,384" fill="none" stroke="black"/> <path d="M 216,400 C 224.83064,400 232,392.83064 232,384" fill="none" stroke="black"/> <path d="M 312,400 C 303.16936,400 296,392.83064 296,384" fill="none" stroke="black"/> <path d="M 408,400 C 416.83064,400 424,392.83064 424,384" fill="none" stroke="black"/> <path d="M 112,464 C 103.16936,464 96,471.16936 96,480" fill="none" stroke="black"/> <path d="M 160,464 C 168.83064,464 176,471.16936 176,480" fill="none" stroke="black"/> <path d="M 112,512 C 103.16936,512 96,504.83064 96,496" fill="none" stroke="black"/> <path d="M 160,512 C 168.83064,512 176,504.83064 176,496" fill="none" stroke="black"/> <path d="M 24,592 C 15.16936,592 8,599.16936 8,608" fill="none" stroke="black"/> <path d="M 472,592 C 463.16936,592 456,599.16936 456,608" fill="none" stroke="black"/> <path d="M 32,624 C 40.83064,624 48,616.83064 48,608" fill="none" stroke="black"/> <path d="M 480,624 C 488.83064,624 496,616.83064 496,608" fill="none" stroke="black"/> <g class="text"> <text x="268" y="52">Customer</text> <text x="108" y="84">Customer</text> <text x="176" y="84">Service</text> <text x="236" y="84">Models</text> <text x="72" y="100">ietf-l2vpn-svc,</text> <text x="200" y="100">ietf-l3vpn-svc,</text> <text x="392" y="100">ietf-network-slice-service,</text> <text x="100" y="116">ietf-ac-svc,</text> <text x="208" y="116">ietf-ac-glue,</text> <text x="296" y="116">and</text> <text x="376" y="116">ietf-bearer-svc</text> <text x="272" y="148">Service</text> <text x="272" y="164">Orchestration</text> <text x="112" y="196">Network</text> <text x="172" y="196">Models</text> <text x="72" y="212">ietf-l2vpn-ntw,</text> <text x="200" y="212">ietf-l3vpn-ntw,</text> <text x="336" y="212">ietf-sap-ntw,</text> <text x="448" y="212">ietf-ac-glue,</text> <text x="96" y="228">and</text> <text x="160" y="228">ietf-ac-ntw</text> <text x="264" y="260">Network</text> <text x="272" y="276">Orchestration</text> <text x="56" y="308">Network</text> <text x="144" y="308">Configuration</text> <text x="224" y="308">Model</text> <text x="164" y="372">Domain</text> <text x="364" y="372">Domain</text> <text x="168" y="388">Orchestration</text> <text x="360" y="388">Orchestration</text> <text x="36" y="420">Device</text> <text x="64" y="436">Configuration</text> <text x="36" y="452">Models</text> <text x="132" y="484">Config</text> <text x="136" y="500">Manager</text> <text x="156" y="548">NETCONF/CLI.</text> <text x="288" y="548">...................</text> <text x="376" y="548">.</text> <text x="136" y="564">|</text> <text x="84" y="596">Bearer</text> <text x="420" y="596">Bearer</text> <text x="28" y="612">CE#1</text> <text x="248" y="612">Network</text> <text x="476" y="612">CE#2</text> <text x="28" y="660">Site</text> <text x="56" y="660">A</text> <text x="476" y="660">Site</text> <text x="504" y="660">B</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .-------------. | Customer | '------+------' Customer Service Models | ietf-l2vpn-svc, ietf-l3vpn-svc, | ietf-network-slice-service, ietf-ac-svc, ietf-ac-glue, | and ietf-bearer-svc .------+------. | Service | | Orchestration | '------+------' Network Models | ietf-l2vpn-ntw, ietf-l3vpn-ntw, | ietf-sap-ntw, ietf-ac-glue, and ietf-ac-ntw | .------+------. | Network | | Orchestration | '------+------' Network Configuration Model | .-----------+-----------. | | .-------+-----. .-------+-----. | Domain | | Domain | | Orchestration | | Orchestration | '--+--------+-' '-------+-----' Device | | | Configuration | | | Models | | | .---+---. | | | Config | | | | Manager | | | '---+---' | | | | | NETCONF/CLI....................... | | | .--------------------------------. .---. Bearer | | Bearer .---. |CE#1+--------+ Network +--------+CE#2| '---' | | '---' '--------------------------------' Site A Site B ]]></artwork> </artset> </figure> <t>In order to ease the mapping between the service model and underlying network models (e.g., the L3VPN Network Model(L3NM),(L3NM) and SAP), the name conventions used in existing network data models are reused as much as possible. For example, 'local-address' is used rather than 'provider-address' (or similar) to refer to an IP address used in the provider network. This approach is consistent with the automation framework defined in <xref target="RFC8969"/>.</t> </section> </section> <section anchor="description-of-the-data-models"> <name>Description of the Data Models</name> <section anchor="sec-bearer"> <name>The Bearer Service ("ietf-bearer-svc") YANG Module</name> <t><xref target="bearer-st"/> shows the tree for managing the bearers (that is, the properties of an attachment that are below Layer 3). A bearer can be a physical or logical link (e.g., LAG <xref target="IEEE802.1AX"/>). Also, a bearer can be a wireless or wired link. A reference to a bearer is generated by the operator. Such a reference can be used, e.g., in a subsequent service request to create an AC. The anchoring of the AC can also be achieved by indicating (with or without a bearerreference),reference) a peer SAP identifier (e.g., an identifier of an SF).</t> <figure anchor="bearer-st"> <name>Bearer Service Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-bearer-svc +--rw locations | +--rw customer* [name peer-as] | +--rw name string | +--rw peer-as inet:as-number | +--ro location* [name] | +--ro name string | +--ro address? string | +--ro city? string | +--ro postal-code? string | +--ro state? string | +--ro country-code? string +--rw bearers +--rw requested-start? yang:date-and-time +--rw requested-stop? yang:date-and-time +--ro actual-start? yang:date-and-time +--ro actual-stop? yang:date-and-time +--rw placement-constraints | +--rw constraint* [constraint-type] | {vpn-common:placement-diversity}? | +--rw constraint-type identityref | +--rw target | +--rw (target-flavor)? | +--:(id) | | +--rw group* [group-id] | | +--rw group-id string | +--:(all-bearers) | | +--rw all-other-bearers? empty | +--:(all-groups) | +--rw all-other-groups? empty +--rw bearer* [name] +--rw name string +--rw description? string +--rw customer-name? string +--rw groups | +--rw group* [group-id] | +--rw group-id string +--rw op-comment? string +--rw bearer-parent-ref? bearer-svc:bearer-ref +--ro bearer-lag-member* bearer-svc:bearer-ref +--ro sync-phy-capable? boolean +--rw sync-phy-enabled? boolean +--rw sync-phy-type? identityref +--rw provider-location-reference? string +--rw customer-point | +--rw identified-by? identityref | +--rw device | | +--rw device-id? string | | +--rw location | | +--rw name? string | | +--rw address? string | | +--rw city? string | | +--rw postal-code? string | | +--rw state? string | | +--rw country-code? string | +--rw site | | +--rw site-id? string | | +--rw location | | +--rw name? string | | +--rw address? string | | +--rw city? string | | +--rw postal-code? string | | +--rw state? string | | +--rw country-code? string | +--rw custom-id? string +--rw type? identityref +--rw test-only? empty +--ro bearer-reference? string | {ac-common:server-assigned-reference}? +--ro ac-svc-ref* | ac-svc:attachment-circuit-reference +--rw requested-start? yang:date-and-time +--rw requested-stop? yang:date-and-time +--ro actual-start? yang:date-and-time +--ro actual-stop? yang:date-and-time +--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]]></artwork>]]></sourcecode> </figure> <t>In some deployments, a customer may first retrieve a list of available presence locations before placing an order for a bearer creation. The request is filtered based upon a customer name and an Autonomous System Number (ASN). The reserved value "AS 0" <xref target="RFC7607"/> is used for customers with no ASN. The retrieved location names maybethen be referenced in a bearer creation request ('provider-location-reference'). See the example provided in <xref target="sec-ret-loc"/>.</t> <t>The same customer site (CE, SF, etc.) can terminate one or multiple bearers; each of them is uniquely identified by a reference that is assigned by the network provider. These bearers can terminate on the same or distinct network nodes. CEs that terminate multiple bearers are called multi-homed CEs.</t> <t>A bearer can be created, modified, or discovered from the network. For example, the following deployment options can be considered:</t><dl><dl spacing="normal" newline="false"> <dt>Greenfield creation:</dt> <dd> <t>In this scenario, bearers are created from scratch using specific requests made to a network controller. This method allows providers to tailor bearer creation to meet customer-specific needs. For example, a bearer request may indicate some hints about the placement constraints ('placement-constraints'). These constraints are used by a provider to determine how/where to terminate a bearer in the network side (e.g., Point of Presence (PoP) or PE selection).</t> </dd> <dt>Auto-discovery using network protocols:</dt> <dd> <t>Devices can use specific protocols (e.g., Link Layer Discovery Protocol (LLDP) <xref target="IEEE802.1AB"/>) to automatically discover and connect to available network resources. A network controller can use such reported information to expose discovered bearers from the network using the same bearer data model structure.</t> </dd> </dl> <t>A request to create a bearer may include a set of constraints ('placement-constraints') that are used by a controller to decide the network terminating side of a bearer (e.g., PE selection, PE redundancy, or PoP selection). <!--[rfced] To avoid repetition of "future", may we remove "in the future" from this sentence? Original: Future placement criteria ('constraint-type') may be defined in the future to accommodate specific deployment contexts. Perhaps: Future placement criteria ('constraint-type') may be defined to accommodate specific deployment contexts. --> Future placement criteria ('constraint-type') may be defined in the future to accommodate specific deployment contexts. A request may also include some timing constraints ('requested-start', 'requested-stop') that are applicable for a set of bearers. The timing constraints can be adjusted at the 'bearer' level. These adjusted values take precedence over the global values.</t> <t>The descriptions of the bearer data nodes are as follows:</t><dl><dl spacing="normal" newline="false"> <dt>'name':</dt> <dd> <t>Used to uniquely identify a bearer. This name is typically selected by the client when requesting a bearer.</t> </dd> <dt>'customer-name':</dt> <dd> <t>Indicates the name of the customer who ordered the bearer.</t> </dd> <dt>'description':</dt> <dd> <t>Includes a textual description of the bearer.</t> </dd> <dt>'group':</dt> <dd> <t>Tags a bearer with one or more identifiers that are used to group a set of bearers.</t> </dd> <dt>'op-comment':</dt> <dd> <t>Includes operational comments that may be useful for managing the bearer (building, level, etc.). No structure is associated with this data node to accommodate all deployments.</t> </dd> <dt>'bearer-parent-ref':</dt> <dd> <t>Specifies the parent bearer. This data node can be used, e.g., if a bearer is a member of a LAG.</t> </dd> <dt>'bearer-lag-member':</dt> <dd> <t>Lists the bearers that are members of a LAG. Members can be declared as part of a LAG using 'bearer-parent-ref'.</t> </dd> <dt>'sync-phy-capable':</dt> <dd> <t>Reports whether a synchronization physical (Sync PHY) mechanism is supported for this bearer.</t> </dd> <dt>'sync-phy-enabled':</dt> <dd> <t>Indicates whether a Sync PHY mechanism is enabled for a bearer.OnlyIt only applies when 'sync-phy-capable' is set to 'true'.</t> </dd> <dt>'sync-phy-type':</dt> <dd> <t>Specifies the Sync PHY mechanism (e.g.,SynchESyncE <xref target="ITU-T-G.781"/>) enabled for the bearer.</t> </dd> <dt>'provider-location-reference':</dt> <dd> <t>Indicates a location identified by a provider-assigned reference.</t> </dd> <dt>'customer-point':</dt> <!--[rfced] To avoid redundancy, may we remove "when requesting a bearer"? Original: A bearer request can indicate a device, a site, a combination thereof, or a custom information when requesting a bearer. Perhaps: A bearer request can indicate a device, a site, a combination thereof, or custom information. --> <dd> <t>Specifies the customer termination point for the bearer. A bearer request can indicate a device, a site, a combination thereof, oracustom information when requesting a bearer. All these schemes are supported in the model.</t> </dd> <dt>'type':</dt> <dd> <t>Specifies the bearer type (Ethernet, wireless, LAG, etc.).</t> </dd> <dt>'test-only':</dt> <dd> <t>Indicates that a request is only for test validation and not for enforcement, even if there are no errors. This is used for feasibility checks. This data node is applicable only when the data model is used with protocolswhichthat do not natively support such option. For example, this data node is redundant with the "test-only" value of the <tt><test-option></tt> parameter in the NETCONF <tt><edit-config></tt> operation (<xref section="7.2" sectionFormat="of" target="RFC6241"/>).</t> </dd> <dt>'bearer-reference':</dt> <dd> <t>Returns an internal reference for the service provider to uniquely identify the bearer. This reference can be used when requesting services. <xref target="ex-create-bearer"/> provides an example about how this reference can be retrieved by a customer.</t></dd> <dt/> <dd><t>Whether the 'bearer-reference' mirrors the content of the 'name' is deployment-specific. The module does not assume nor preclude such schemes.</t> </dd> <dt>'ac-svc-ref':</dt> <dd> <t>Specifies the set of attachment circuits that are bound to the bearer.</t> </dd> <dt>'requested-start':</dt> <dd> <t>Specifies the requested date and time when the bearer is expected to be active.</t> </dd> <dt>'requested-stop':</dt> <dd> <t>Specifies the requested date and time when the bearer is expected to be disabled.</t> </dd> <!--[rfced] To avoid redundancy, may we remove "actually"? Note that there are a number of other places throughout the document with similar phrasing, which would also be updated. Original: 'actual-start': Reports the actual date and time when the bearer actually was enabled. Perhaps: 'actual-start': Reports the actual date and time when the bearer was enabled. --> <dt>'actual-start':</dt> <dd> <t>Reports the actual date and time when the bearer actually was enabled.</t> </dd> <dt>'actual-stop':</dt> <dd> <t>Reports the actual date and time when the bearer actually was disabled.</t> </dd> <dt>'status':</dt> <dd> <t>Used to track the overall status of a given bearer. Both the operational and administrative status are maintained together with a timestamp.</t></dd> <dt/> <dd><t>The 'admin-status' attribute is typically configured by a network operator to indicate whether the service is enabled, disabled, or subjected to additional testing or pre-deployment checks. These additional options, such as 'admin-testing' and 'admin-pre-deployment', provide the operators the flexibility to conduct additional validations on the bearer before deploying services over that connection.</t> </dd> <dt>'oper-status':</dt> <dd><t>The 'oper-status'<t>Reflects the operational state of a bearerreflects its operational stateas observed. As a bearer can contain multiple services, the operational status should only reflect the status of the bearer connection. To obtain network-level service status, specific networkmodelsmodels, such as those in <xref section="7.3" sectionFormat="of" target="RFC9182"/> or <xref section="7.3" sectionFormat="of"target="RFC9291"/>target="RFC9291"/>, should be consulted.</t></dd> <dt/> <dd><t>It is important to note that the 'admin-status' attribute should remain independent of the 'oper-status'. In other words, the setting of the intended administrative state (e.g.,whether'admin-up' or 'admin-testing') <bcp14>MUST NOT</bcp14> be influenced by the current operational state. If the bearer is administratively set to 'admin-down', it is expected that the bearer will also be operationally 'op-down' as a result of this administrative decision.</t></dd> <dt/> <dd><t>To assess the service delivery status for a given bearer comprehensively, it is recommended to consider both administrative and operational service status values in conjunction. This holistic approach allows a network controller or operator to identify anomalies effectively.</t></dd> <dt/> <dd><t>For instance, when a bearer is administratively enabled but the 'operational-status' of that bearer is reported as 'op-down', it should be expected that the 'oper-status' of services transported over that bearer is also down. These status values differing should trigger the detection of an anomaly condition.</t></dd> <dt/> <dd><t>See"A Common YANG Data Model for Layer 2 and Layer 3 VPNs""<xref target="RFC9181" format="title"/>" <xref target="RFC9181"/> for more details.</t> </dd> </dl> </section> <section anchor="the-attachment-circuit-service-ietf-ac-svc-yang-module"> <name>The Attachment Circuit Service ("ietf-ac-svc") YANG Module</name> <t>The full tree diagram of the "ietf-ac-svc" module is provided in <xref target="AC-svc-Tree"/>. Subtrees are provided in the following subsections for the reader's convenience.</t> <section anchor="overall-structure"> <name>Overall Structure</name> <t>The overall tree structure of the AC service module is shown in <xref target="o-svc-tree"/>.</t> <figure anchor="o-svc-tree"> <name>Overall AC Service Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ +--rw specific-provisioning-profiles | ... +--rw service-provisioning-profiles | ... +--rw attachment-circuits +--rw ac-group-profile* [name] | ... +--rw placement-constraints | ... +--rw ac* [name] ... +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | ... +--rw oam | ... +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>The rationale for deciding whether a reusable grouping is included in this document orbemoved into the AC common module <xreftarget="I-D.ietf-opsawg-teas-common-ac"/>target="RFC9833"/> is as follows:</t> <ul spacing="normal"> <li> <t>Groupings that are reusable among the AC service module, AC network module, and other servicemodels,models and network models are included in the AC common module.</t> </li> <li> <t>Groupings that are reusable only by other service models are maintained in the "ietf-ac-svc" module.</t> </li> </ul> <t>Each AC is identified with a unique name ('../ac/name') within a domain. The mapping between this AC and a local PE that terminates the AC is hidden to the application that makes use of the AC service model. This information is internal to theNetworknetwork controller. As such, the details about the (node-specific) attachment interfaces are not exposed in this service model.</t> <t>The AC service model uses groupings and types defined in the AC common model <xreftarget="I-D.ietf-opsawg-teas-common-ac"/>target="RFC9833"/> ('op-instructions', 'dot1q', 'qinq', 'priority-tagged', 'l2-tunnel-service', etc.). Therefore, the descriptions of these nodes are not reiterated in the following subsections.</t> <t>Features are used to tag conditional portions of the model in order to accommodate various deployments (support of layer 2 ACs, Layer 3 ACs, IPv4, IPv6, routing protocols, Bidirectional Forwarding Detection (BFD), etc.).</t> </section> <section anchor="sec-profiles"> <name>Service Profiles</name> <section anchor="sec-profiles-desc"> <name>Description</name> <t>The 'specific-provisioning-profiles' container (<xref target="gp-svc-tree"/>) can be used by a service provider to maintain a set of reusable profiles. The profiles definitions are similar to those defined in <xref target="RFC9181"/>, including: Quality of Service (QoS), BFD, forwarding, and routing profiles. The exact definition of the profiles is local to each service provider. The model only includes an identifier for these profiles in order to facilitate identifying and binding local policies when building an AC.</t> <figure anchor="gp-svc-tree"> <name>Service Profiles</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-ac-svc +--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 service-provisioning-profiles | +--rw service-profile-identifier* [id] | +--rw id string +--rw attachment-circuits +--rw ac-group-profile* [name] | ... +--rw placement-constraints | ... +--rw ac* [name] ... +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | ... +--rw oam | ... +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>As shown in <xref target="gp-svc-tree"/>, two profile types can be defined: 'specific-provisioning-profiles' and 'service-provisioning-profiles'. Whether only specific profiles, service profiles, or a combination thereof are used is local to each service provider.</t> <t>The following specific provisioning profiles can bedefined:</t> <dl>defined as follows:</t> <dl spacing="normal" newline="false"> <dt>'encryption-profile-identifier':</dt> <dd> <t>Refers to a set of policies related to the encryption setup that can be applied when provisioning an AC.</t> </dd> <dt>'qos-profile-identifier':</dt> <dd> <t>Refers to a set of policies, such as classification, marking, and actions (e.g., <xref target="RFC3644"/>).</t> </dd> <dt>'failure-detection-profile-identifier':</dt> <dd> <t>Refers to a set of failure detection policies (e.g., BFD policies <xref target="RFC5880"/>) that can be invoked when building an AC.</t> </dd> <dt>'forwarding-profile-identifier':</dt> <dd> <t>Refers to the policies that apply to the forwarding of packets conveyed within an AC. Such policies may consist, for example, of applying Access Control Lists (ACLs).</t> </dd> <dt>'routing-profile-identifier':</dt> <dd> <t>Refers to a set of routing policies that will be invoked (e.g., BGP policies) when building an AC.</t> </dd> </dl> </section> <section anchor="referencing-servicespecific-profiles"> <name>Referencing Service/Specific Profiles</name> <!--[rfced] For clarity, may we update "by an identifier" to "of an identifier"? Original: All the above mentioned profiles are uniquely identified by the provider server by an identifier. Perhaps: All the above mentioned profiles are uniquely identified by the provider server of an identifier. --> <t>All the above mentioned profiles are uniquely identified by the provider server by an identifier. To ease referencing these profiles by other data models, specific typedefs are defined for each of these profiles. Likewise, an attachment circuit reference typedef is defined when referencing a (global) attachment circuit by its name is required. These typedefs <bcp14>SHOULD</bcp14> be used when other modules need a reference to one of these profiles or attachment circuits.</t> </section> </section> <section anchor="sec-acp"> <name>Attachment Circuits Profiles</name> <t>The 'ac-group-profile' defines reusable parameters for a set of ACs. Each profile is identified by 'name'. Some of the data nodes can be adjusted at the 'ac' level. These adjusted values take precedence over the global values. The structure of 'ac-group-profile' is similar to the one used to model each 'ac' (<xref target="ac-svc-tree"/>).</t> </section> <section anchor="sec-pc"> <name>AC PlacementContraints</name>Constraints</name> <t>The 'placement-constraints' specifies the placement constraints of an AC. For example, this container can be used to request avoidance of connecting two ACs to the same PE. The full set of supported constraints is defined in <xref target="RFC9181"/> (see 'placement-diversity', in particular).</t> <t>The structure of 'placement-constraints' is shown in <xref target="precedence-tree"/>.</t> <figure anchor="precedence-tree"> <name>Placement Constraints Subtree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ +--rw specific-provisioning-profiles | ... +--rw service-provisioning-profiles | ... +--rw attachment-circuits +--rw ac-group-profile* [name] | ... +--rw placement-constraints | +--rw constraint* [constraint-type] | +--rw constraint-type identityref | +--rw target | +--rw (target-flavor)? | +--:(id) | | +--rw group* [group-id] | | +--rw group-id string | +--:(all-accesses) | | +--rw all-other-accesses? empty | +--:(all-groups) | +--rw all-other-groups? empty +--rw ac* [name] ...]]></artwork>]]></sourcecode> </figure> </section> <section anchor="attachment-circuits"> <name>Attachment Circuits</name> <t>The structure of 'attachment-circuits' is shown in <xref target="ac-svc-tree"/>.</t> <figure anchor="ac-svc-tree"> <name>Attachment Circuits Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ +--rw specific-provisioning-profiles | ... +--rw service-provisioning-profiles | ... +--rw attachment-circuits +--rw ac-group-profile* [name] | ... +--rw placement-constraints | ... +--rw customer-name? string +--rw requested-start? yang:date-and-time +--rw requested-stop? yang:date-and-time +--ro actual-start? yang:date-and-time +--ro actual-stop? yang:date-and-time +--rw ac* [name] +--rw customer-name? string +--rw description? string +--rw test-only? empty +--rw requested-start? yang:date-and-time +--rw requested-stop? yang:date-and-time +--ro actual-start? yang:date-and-time +--ro actual-stop? yang:date-and-time +--rw role? identityref +--rw peer-sap-id* string +--rw group-profile-ref* ac-group-reference +--rw parent-ref* ac-svc:attachment-circuit-reference +--ro child-ref* ac-svc:attachment-circuit-reference +--rw group* [group-id] | +--rw group-id string | +--rw precedence? identityref +--ro service-ref* [service-type service-id] | +--ro service-type identityref | +--ro service-id string +--ro server-reference? string | {ac-common:server-assigned-reference}? +--rw name string +--rw service-profile* service-profile-reference +--rw l2-connection {ac-common:layer2-ac}? | ... +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | ... +--rw oam | ... +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>A request may also include some timing constraints ('requested-start', 'requested-stop') that are applicable for a set of ACs. The timing constraints can be adjusted at the 'ac' level. These adjusted values take precedence over the global values.</t> <t>Thedescription of the'ac' data nodesisare described as follows:</t><dl><dl spacing="normal" newline="false"> <dt>'customer-name':</dt> <dd> <t>Indicates the name of the customer who ordered the AC or a set of ACs.</t> </dd> <dt>'description':</dt> <dd> <t>Includes a textual description of the AC.</t> </dd> <dt>'test-only':</dt> <dd> <t>Indicates that a request is only for a validation test and not for enforcement, even if there are no errors. This is used for feasibility checks. This data node is applicable only when the data model is used with protocolswhichthat do not have built-in support of such option.</t> </dd> <dt>'requested-start':</dt> <dd> <t>Specifies the requested date and time when the attachment circuit is expected to be active.</t> </dd> <dt>'requested-stop':</dt> <dd> <t>Specifies the requested date and time when the attachment circuit is expected to be disabled.</t> </dd> <dt>'actual-start':</dt> <dd> <t>Reports the actual date and time when the attachment circuit actually was enabled.</t> </dd> <dt>'actual-stop':</dt> <dd> <t>Reports the actual date and time when the attachment circuit actually was disabled.</t> </dd> <dt>'role':</dt> <dd> <t>Specifies whether an AC is used, e.g., as User-to-Network Interface (UNI) or Network-to-Network Interface (NNI).</t> </dd> <dt>'peer-sap-id':</dt> <dd> <t>Includes references to the remote endpoints of an attachment circuit <xref target="RFC9408"/>. 'peer' is drawn here from the perspective of the provider network. That is, a 'peer-sap' will refer to a customer node.</t> </dd> <dt>'group-profile-ref':</dt> <dd> <t>Indicates references to one or more profiles that are defined in <xref target="sec-acp"/>.</t> </dd> <dt>'parent-ref':</dt> <dd> <t>Specifies an AC that is inherited by an attachment circuit.</t></dd> <dt/> <dd><t>In contexts where dynamic termination points are managed for a given AC, a parent AC can be defined with a set of stable and common information, while "child" ACs are defined to track dynamic information. These "child" ACs are bound to the parent AC, which is exposed to services (as a stable reference).</t></dd> <dt/> <dd><t>Whenever a parent AC is deleted, all its "child" ACs <bcp14>MUST</bcp14> be deleted.</t></dd> <dt/> <dd><t>A "child" AC <bcp14>MAY</bcp14> rely upon more than one parent AC (e.g., parent Layer 2 AC and parent Layer 3 AC). In such cases, these ACs <bcp14>MUST NOT</bcp14> be overlapping. An example to illustrate the use of multiple parent ACs is provided in <xref target="sec-bfd-static"/>.</t> </dd> <dt>'child-ref':</dt> <dd> <t>Lists one or more references of child ACs that rely upon this attachment circuit as a parent AC.</t> </dd> <dt>'group':</dt> <dd> <t>Lists the groups to which an AC belongs <xref target="RFC9181"/>. For example, the 'group-id' is used to associate redundancy or protection constraints of ACs. An example is provided in <xref target="sec-ex-prec"/>.</t> </dd> <dt>'service-ref':</dt> <dd> <t>Reports the set of services that are bound to the attachment circuit. The services are indexed by their type.</t> </dd> <dt>'server-reference':</dt> <dd> <t>Reports the internal reference that is assigned by the provider for this AC. This reference is used to accommodate deployment contexts (e.g., <xref section="9.1.2" sectionFormat="of" target="RFC8921"/>) where an identifier is generated by the provider to identify a service order locally.</t> </dd> <dt>'name':</dt> <dd> <t>Associates a name that uniquely identifies an AC within a service provider network.</t> </dd> <dt>'service-profile':</dt> <dd> <t>References a set of service-specific profiles.</t> </dd> <dt>'l2-connection':</dt> <dd> <t>See <xref target="sec-l2"/>.</t> </dd> <dt>'ip-connection':</dt> <dd> <t>See <xref target="sec-l3"/>.</t> </dd> <dt>'routing':</dt> <dd> <t>See <xref target="sec-rtg"/>.</t> </dd> <dt>'oam':</dt> <dd> <t>See <xref target="sec-oam"/>.</t> </dd> <dt>'security':</dt> <dd> <t>See <xref target="sec-sec"/>.</t> </dd> <dt>'service':</dt> <dd> <t>See <xref target="sec-bw"/>.</t> </dd> </dl> <section anchor="sec-l2"> <name>Layer 2 Connection Structure</name> <t>The 'l2-connection' container (<xref target="l2-svc-tree"/>) is used to configure the relevant Layer 2 properties of anAC including:AC, including encapsulation details and tunnel terminations. For the encapsulation details, the model supports the definition of the type as well as theIdentifiersidentifiers (e.g., VLAN-IDs) of each of the encapsulation-type defined. For the second case, attributes for pseudowire, Virtual Private LAN Service (VPLS), and Virtual eXtensible Local Area Network (VXLAN) tunnel terminations are included.</t> <t>'bearer-reference' is used to link an AC with a bearer over which the AC is instantiated.</t> <t>This structure relies upon the common groupings defined in <xreftarget="I-D.ietf-opsawg-teas-common-ac"/>.</t>target="RFC9833"/>.</t> <figure anchor="l2-svc-tree"> <name>Layer 2 Connection Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ +--rw specific-provisioning-profiles | ... +--rw service-provisioning-profiles | ... +--rw attachment-circuits +--rw ac-group-profile* [name] | ... +--rw placement-constraints | ... +--rw ac* [name] ... +--rw name string +--rw l2-connection {ac-common:layer2-ac}? | +--rw encapsulation | | +--rw type? identityref | | +--rw dot1q | | | +--rw tag-type? identityref | | | +--rw cvlan-id? uint16 | | +--rw priority-tagged | | | +--rw tag-type? identityref | | +--rw qinq | | +--rw tag-type? identityref | | +--rw svlan-id? uint16 | | +--rw cvlan-id? uint16 | +--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 bearer-reference? string | {vpn-common:bearer-reference}? +--rw ip-connection {ac-common:layer3-ac}? | ... +--rw routing-protocols | ... +--rw oam | ... +--rw security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> </section> <section anchor="sec-l3"> <name>IP Connection Structure</name> <t>The 'ip-connection' container is used to configure the relevant IP properties of an AC. The model supports the usage of dynamic and static addressing. This structure relies upon the common groupings defined in <xref section="4.3" sectionFormat="of"target="I-D.ietf-opsawg-teas-common-ac"/>.target="RFC9833"/>. Both IPv4 and IPv6 parameters are supported.</t> <t>For ACs that require Layer 3 tunnel establishment, the ACaaS includes a provision for future augmentations to define tunnel-specific data nodes ('l3-tunnel-service'). Such augmentations <bcp14>MUST</bcp14> be conditional based on the tunnel type ('type').</t> <t><xref target="ipv4-svc-tree"/> shows the structure of the IPv4 connection.</t> <figure anchor="ipv4-svc-tree"> <name>Layer 3 Connection Tree Structure (IPv4)</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ | ... +--rw ip-connection {ac-common:layer3-ac}? | +--rw ipv4 {vpn-common:ipv4}? | | +--rw local-address? | | | inet:ipv4-address | | +--rw virtual-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 | | | +--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? | | failure-detection-profile-reference | | {vpn-common:bfd}? | +--rw ipv6 {vpn-common:ipv6}? | | ... | +--rw (l3-service)? | +--:(l3-tunnel-service) | +--rw l3-tunnel-service | +--rw type? identityref]]></artwork>]]></sourcecode> </figure> <t><xref target="ipv6-svc-tree"/> shows the structure of the IPv6 connection.</t> <figure anchor="ipv6-svc-tree"> <name>Layer 3 Connection Tree Structure (IPv6)</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ | ... +--rw ip-connection {ac-common:layer3-ac}? | +--rw ipv4 {vpn-common:ipv4}? | | ... | +--rw ipv6 {vpn-common:ipv6}? | | +--rw local-address? | | | inet:ipv6-address | | +--rw virtual-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 | | | +--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? | | failure-detection-profile-reference | | {vpn-common:bfd}? | +--rw (l3-service)? | +--:(l3-tunnel-service) | +--rw l3-tunnel-service | +--rw type? identityref | ...]]></artwork>]]></sourcecode> </figure> </section> <section anchor="sec-rtg"> <name>Routing</name> <t>As shown in the tree depicted in <xref target="rtg-svc-tree"/>, the 'routing-protocols' container defines the required parameters to enable the desired routing features for an AC. One or more routing protocols can be associated with an AC. Such routing protocols willbethen be enabled between a PE and the customer termination points. Each routing instance is uniquely identified by the combination of the 'id' and 'type' to accommodate scenarios where multiple instances of the same routing protocol have to be configured on the same link.</t> <t>In addition to static routing (<xref target="sec-static-rtg"/>), the module supports BGP (<xref target="sec-bgp-rtg"/>), OSPF (<xref target="sec-ospf-rtg"/>), IS-IS (<xref target="sec-isis-rtg"/>), and RIP (<xref target="sec-rip-rtg"/>). It also includes a reference to the 'routing-profile-identifier' defined in <xref target="sec-profiles"/>, so that additional constraints can be applied to a specific instance of each routing protocol. Moreover, the module supports VRRP (<xref target="sec-vrrp-rtg"/>).</t> <figure anchor="rtg-svc-tree"> <name>Routing Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ +--rw specific-provisioning-profiles | ... +--rw service-provisioning-profiles | ... +--rw attachment-circuits +--rw ac-group-profile* [name] | ... +--rw placement-constraints | ... +--rw ac* [name] ... +--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-profiles* [id] | | +--rw id routing-profile-reference | | +--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> <section anchor="sec-static-rtg"> <name>Static Routing</name> <t>The static tree structure is shown in <xref target="static-rtg-svc-tree"/>.</t> <figure anchor="static-rtg-svc-tree"> <name>Static Routing Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ | ... +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profiles* [id] | | +--rw id routing-profile-reference | | +--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 failure-detection-profile? | | | | failure-detection-profile-reference | | | | {vpn-common:bfd}? | | | +--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 failure-detection-profile? | | | failure-detection-profile-reference | | | {vpn-common:bfd}? | | +--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}? | ...]]></artwork>]]></sourcecode> </figure> <t>As depicted in <xref target="static-rtg-svc-tree"/>, 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") 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>'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>'failure-detection-profile':</dt> <dd> <t>Indicates a failure detection profile (e.g., BFD) that applies for this entry.</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>An AC service activation with BGP routing <bcp14>SHOULD</bcp14> include at least the customer's AS Number (ASN) and the provider's ASN. Additional information can be supplied by a customer in a request or exposed by a provider in a response to a query request in order to ease the process of automating the provisioning of BGP sessions (the customer does not use the primary IP address to establish the underlying BGP session, communicate the provider's IP address used to establish the BGP session, share authentication parameters, bind the session to a forwarding protection profile, etc.).</t> <t>The BGP tree structure is shown in <xref target="bgp-rtg-svc-tree"/>.</t> <figure anchor="bgp-rtg-svc-tree"> <name>BGP Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ | ... +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profiles* [id] | | +--rw id routing-profile-reference | | +--rw type? identityref | +--rw static | | ... | +--rw bgp {vpn-common:rtg-bgp}? | | +--rw peer-groups | | | +--rw peer-group* [name] | | | +--rw name string | | | +--rw local-as? inet:as-number | | | +--rw peer-as? inet:as-number | | | +--rw address-family? identityref | | | +--rw role? identityref | | | +--rw local-address? inet:ip-address | | | +--rw bgp-max-prefix | | | | +--rw max-prefix? uint32 | | | +--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* [id] | | +--rw id string | | +--ro server-reference? string | | | {ac-common:server-assigned-reference}? | | +--rw remote-address? inet:ip-address | | +--rw local-address? inet:ip-address | | +--rw local-as? inet:as-number | | +--rw peer-as? inet:as-number | | +--rw address-family? identityref | | +--rw role? identityref | | +--rw bgp-max-prefix | | | +--rw max-prefix? uint32 | | +--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 requested-start? yang:date-and-time | | +--rw requested-stop? yang:date-and-time | | +--ro actual-start? yang:date-and-time | | +--ro actual-stop? yang:date-and-time | | +--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 peer-group? | | | -> ../../peer-groups/peer-group/name | | +--rw failure-detection-profile? | | failure-detection-profile-reference | | {vpn-common:bfd}? | +--rw ospf {vpn-common:rtg-ospf}? | | ... | +--rw isis {vpn-common:rtg-isis}? | | ... | +--rw rip {vpn-common:rtg-rip}? | | ... | +--rw vrrp {vpn-common:rtg-vrrp}? | ...]]></artwork>]]></sourcecode> </figure> <t>For deployment cases where an AC service request includes a list of neighbors with redundant information, the ACaaS allowsto factorizefactorizing shared data by means of 'peer-group'.TheThus, the presence of 'peer-groups' in a service request isthusoptional.</t> <t>The following data nodes are supported for each BGP 'peer-group':</t><dl><dl spacing="normal" newline="false"> <dt>'name':</dt> <dd> <t>Defines a name for the peer group.</t> </dd> <dt>'local-as':</dt> <dd> <t>Reports the provider's ASN. This information is used at the customer side to configure the BGP session with the provider network.</t> </dd> <dt>'peer-as':</dt> <dd> <t>Indicates the customer's ASN. This information is used at the provider side to configure the BGP session with the customer equipment.</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"/>. This parameter is useful for interconnection scenarios.</t></dd> <dt/> <dd><t>This is an optional parameter.</t> </dd> <dt>'local-address':</dt> <dd> <t>Reports a provider's IP address to use to establish the BGP transport session.</t> </dd> <dt>'bgp-max-prefix':</dt> <dd> <t>Indicates the maximum number of BGP prefixes allowed in a session for this group.</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>Similar to <xref target="RFC9182"/>, this version of the ACaaS assumes that parameters specific to the TCP-AO are preconfigured as part of the key chain that is referenced in the ACaaS. 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 "YANG Data Model for Key Chains" <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> <dt>'server-reference':</dt> <dd> <t>Reports the internal reference that is assigned by the provider for this BGP session. This is an optional parameter.</t> </dd> <dt>'remote-address':</dt> <dd> <t>Specifies the customer's IP address used toestablishingestablish this BGP session. If not present, this means that the primary customer IP address is used as the remote IP address.</t> </dd> <dt>'requested-start':</dt> <dd> <t>Specifies the requested date and time when the BGP session is expected to be active.</t> </dd> <dt>'requested-stop':</dt> <dd> <t>Specifies the requested date and time when the BGP session is expected to be disabled.</t> </dd> <dt>'actual-start':</dt> <dd> <t>Reports the actual date and time when the BGP session actually was enabled.</t> </dd> <dt>'actual-stop':</dt> <dd> <t>Reports the actual date and time when the BGP session actually was disabled.</t> </dd> <dt>'status':</dt> <dd> <t>Indicates the status of the BGP routing instance.</t> </dd> <dt>'peer-group':</dt> <dd> <t>Specifies 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/> <dd><t>This is an optional parameter.</t> </dd> <dt>'failure-detection-profile':</dt> <dd> <t>Indicates a failure detection profile (BFD) that applies for a BGP neighbor. This is an optional parameter.</t> </dd> </dl> </section> <section anchor="sec-ospf-rtg"> <name>OSPF</name> <t>The OSPF tree structure is shown in <xref target="ospf-rtg-svc-tree"/>.</t> <figure anchor="ospf-rtg-svc-tree"> <name>OSPF Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ | ... +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profiles* [id] | | +--rw id routing-profile-reference | | +--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 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}? | ...]]></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>'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>'authentication':</dt> <dd> <t>Controls the authentication schemes to be enabled for the OSPF instance. The model 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"/>.</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 tree structure is shown in <xref target="isis-rtg-svc-tree"/>.</t> <figure anchor="isis-rtg-svc-tree"> <name>IS-IS Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ | ... +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profiles* [id] | | +--rw id routing-profile-reference | | +--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 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}? | ...]]></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>'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 tree structure is shown in <xref target="rip-rtg-svc-tree"/>.</t> <figure anchor="rip-rtg-svc-tree"> <name>RIP Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ | ... +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profiles* [id] | | +--rw id routing-profile-reference | | +--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 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}? | ...]]></artwork>]]></sourcecode> </figure> <t>'address-family' indicates whether IPv4, IPv6, or both address families are to be activated. For example, 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> </section> <section anchor="sec-vrrp-rtg"> <name>VRRP</name> <t>The model supports the Virtual Router Redundancy Protocol (VRRP) <xref target="RFC9568"/> on an AC (<xref target="vrrp-rtg-svc-tree"/>).</t> <figure anchor="vrrp-rtg-svc-tree"> <name>VRRP Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ | ... +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profiles* [id] | | +--rw id routing-profile-reference | | +--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 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]]></artwork>]]></sourcecode> </figure> <t>The following 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>'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>Operations, Administration, and Maintenance (OAM)</name> <t>As shown in the tree depicted in <xref target="oam-svc-tree"/>, the 'oam' container defines OAM-related parameters of an AC.</t> <figure anchor="oam-svc-tree"> <name>OAM Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ +--rw specific-provisioning-profiles | ... +--rw service-provisioning-profiles | ... +--rw attachment-circuits +--rw ac-group-profile* [name] | ... +--rw placement-constraints | ... +--rw ac* [name] ... +--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* [id] | +--rw id string | +--rw local-address? inet:ip-address | +--rw remote-address? inet:ip-address | +--rw profile? | | failure-detection-profile-reference | +--rw holdtime? 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 security | ... +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>This version of the module supports BFD. The following BFD data nodes can be specified:</t><dl><dl spacing="normal" newline="false"> <dt>'id':</dt> <dd> <t>An identifier that uniquely identifies a BFD session.</t> </dd> <dt>'local-address':</dt> <dd> <t>Indicates the provider's IP address used for a BFD session.</t> </dd> <dt>'remote-address':</dt> <dd> <t>Indicates the customer's IP address used for a BFD session.</t> </dd> <dt>'profile':</dt> <dd> <t>Refers to a BFD profile.</t> </dd> <dt>'holdtime':</dt> <dd> <t>Used to indicate the expected BFD holddown time, in milliseconds.</t> </dd> <dt>'status':</dt> <dd> <t>Indicates the status of the BFD session.</t> </dd> </dl> </section> <section anchor="sec-sec"> <name>Security</name> <t>As shown in the tree depicted in <xref target="sec-svc-tree"/>, the 'security' container defines a set of AC security parameters.</t> <figure anchor="sec-svc-tree"> <name>Security Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ +--rw specific-provisioning-profiles | ... +--rw service-provisioning-profiles | ... +--rw attachment-circuits +--rw ac-group-profile* [name] | ... +--rw placement-constraints | ... +--rw ac* [name] ... +--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 provider-profile? | | encryption-profile-reference | +--:(customer-profile) | +--rw customer-key-chain? | key-chain:key-chain-ref +--rw service ...]]></artwork>]]></sourcecode> </figure> <t>The 'security' container specifies a minimum set of encryption-related parameters that can be requested to be applied to traffic for a given AC. Typically, 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 (see <xref target="sec-profiles-desc"/>). For example, a service provider may use IPsec when a customer requests Layer 3 encryption for an AC.</t> </section> <section anchor="sec-bw"> <name>Service</name> <t>The structure of the 'service' container is depicted in <xref target="bw-tree"/>.</t> <figure anchor="bw-tree"> <name>Bandwidth Tree Structure</name><artwork align="center"><![CDATA[<sourcecode type="yangtree"><![CDATA[ +--rw specific-provisioning-profiles | ... +--rw service-provisioning-profiles | ... +--rw attachment-circuits +--rw ac-group-profile* [name] | ... +--rw placement-constraints | ... +--rw ac* [name] ... +--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* [profile] | +--rw profile qos-profile-reference | +--rw direction? identityref +--rw access-control-list +--rw acl-profiles +--rw acl-profile* [profile] +--rw profile forwarding-profile-reference]]></artwork>]]></sourcecode> </figure> <t>The 'service' container defines the following data nodes:</t><dl><dl spacing="normal" newline="false"> <dt>'mtu':</dt> <dd> <t>Specifies the Layer 2 MTU, in bytes, for the AC.</t> </dd> </dl> <dl newline="true" spacing="normal"> <dt>'svc-pe-to-ce-bandwidth' and'svc-ce-to-pe-bandwidth':</dt> <dd><t/> </dd> <dt> 'svc-pe-to-ce-bandwidth':</dt> <dd> <t>Indicates<dl newline="false" spacing="normal"> <dt>'svc-pe-to-ce-bandwidth':</dt> <dd>Indicates the inbound bandwidth of the AC (i.e., download bandwidth from the service provider to the customersite).</t> </dd>site).</dd> <dt>'svc-ce-to-pe-bandwidth':</dt><dd> <t>Indicates<dd><t>Indicates the outbound bandwidth of the AC (i.e., upload bandwidth from the customer site to the service provider).</t> </dd><dt/> <dd></dl> <t>Both 'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth' can be represented using the Committed Information Rate (CIR), the Excess Information Rate (EIR), or the Peak Information Rate (PIR). Both reuse the 'bandwidth-per-type' grouping defined in <xreftarget="I-D.ietf-opsawg-teas-common-ac"/>.</t>target="RFC9833"/>.</t> </dd> </dl> <dl newline="false" spacing="normal"> <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> </section> <section anchor="yang-modules"> <name>YANG Modules</name> <section anchor="sec-bearer-module"> <name>The Bearer Service ("ietf-bearer-svc") YANG Module</name> <t>This module uses types defined in <xref target="RFC6991"/>, <xref target="RFC9181"/>, and <xreftarget="I-D.ietf-opsawg-teas-common-ac"/>.</t>target="RFC9833"/>.</t> <sourcecodetype="yang"><![CDATA[ <CODE BEGINS> file "ietf-bearer-svc@2025-01-07.yang"name="ietf-bearer-svc@2025-08-11.yang" type="yang" markers="true"><![CDATA[ module ietf-bearer-svc { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bearer-svc"; prefix bearer-svc; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types, Section 4"; } import ietf-vpn-common { prefix vpn-common; reference "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 VPNs"; } 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 "RFCXXXX: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 generic YANGmodelmodule for exposing network bearers as a service. Copyright (c) 2025 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC xxx; see the RFC itself for full legal notices."; revision2025-01-072025-08-11 { description "Initial revision."; reference "RFCXXXX:9834: YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)"; } // Identities identity identification-type { description "Base identity for identification of bearers."; } identity device-id { base identification-type; description "Identification of bearers based on device."; } identity site-id { base identification-type; description "Identification of bearers based on site."; } identity site-and-device-id { base identification-type; description "Identification of bearers based on site and device."; } identity custom { base identification-type; description "Identification of bearers based on other custom criteria."; } identity bearer-type { description "Base identity for bearers type."; } identity ethernet { base bearer-type; description "Ethernet."; } identity wireless { base bearer-type; description "Wireless."; } identity lag { base bearer-type; description "Link Aggregation Group (LAG)."; } identity network-termination-hint { base vpn-common:placement-diversity; description "A hint about the termination at the network side is provided (e.g., geoproximity)."; } identity sync-phy-type { description "Base identity for physical layer synchronization."; } identity sync-e { base sync-phy-type; description "Sync Ethernet (SyncE)."; reference "ITU-T G.781: Synchronization layer functions for frequency synchronization based on the physical layer"; } // Typedef to ease referencing cross-modules typedef bearer-ref { type leafref { path "/bearer-svc:bearers/bearer-svc:bearer/bearer-svc:name"; } description "Defines a type to reference a bearer."; } // Reusable groupings grouping location-information { description "Basic location information."; leaf name { type string; description "Provides a location name. This data node can be mapped, e.g., to the 3GPP NRM IOC ManagedElement."; } leaf address { type string; description "Address (number and street) of the device/site."; } leaf city { type string; description "City of the device/site."; } leaf postal-code { type string; description "Postal code of the device/site."; } leaf state { type string; description "State of the device/site. This leaf can also be used to describe a region for a country that does not have states."; } leaf country-code { type string { pattern '[A-Z]{2}'; } description "Country of the device/site. Expressed as ISO ALPHA-2 code."; } } grouping placement-constraints { description "Constraints related to placement of a bearer."; list constraint { if-feature "vpn-common:placement-diversity"; key "constraint-type"; description "List of constraints."; leaf constraint-type { type identityref { base vpn-common:placement-diversity; } must "not(derived-from-or-self(current(), " + "'vpn-common:bearer-diverse') or " + "derived-from-or-self(current(), " + "'vpn-common:same-bearer'))" { error-message "Only bearer-specific diversity" + "constraints must be provided."; } description "Diversity constraint type for bearers."; } container target { description "The constraint will apply against this list of groups."; choice target-flavor { description "Choice for the group definition."; case id { list group { key "group-id"; description "List of groups."; leaf group-id { type string; description "The constraint will apply against this particular group ID."; } } } case all-bearers { leaf all-other-bearers { type empty; description "The constraint will apply against all other bearers of a site."; } } case all-groups { leaf all-other-groups { type empty; description "The constraint will apply against all other groups managed by the customer."; } } } } } } container locations { description "Retrieves the available provider locations for terminating bearers for a given customer."; list customer { key "name peer-as"; description "List of locations per customer."; leaf name { type string; description "Indicates the name of the customer."; } leaf peer-as { type inet:as-number; description "Indicates the customer's ASN. 0 is used when the customer does not have an ASN."; reference "RFC 7607: Codification of AS 0 Processing"; } list location { key "name"; config false; description "Reports the list of available locations."; uses location-information; } } } container bearers { description "Main container for the bearers. The timing constraints indicated at the bearer level take precedence over the global values indicated at the bearers level."; uses ac-common:op-instructions; container placement-constraints { description "Diversity constraint type."; uses placement-constraints; } list bearer { key "name"; description "Maintains a list of bearers."; leaf name { type string; description "A name that uniquely identifies a bearer for a given customer."; } leaf description { type string; description "A description of this bearer."; } leaf customer-name { type string; description "Indicates the name of the customer that requested this bearer."; } uses vpn-common:vpn-components-group; leaf op-comment { type string; description "Includes comments that can be shared with operational teams andwhichthat may be useful for the activation of a bearer. This may include, for example, information about the building, level, etc."; } leaf bearer-parent-ref { type bearer-svc:bearer-ref; description "Specifies the parent bearer. This can be used, e.g., for a Link Aggregation Group (LAG)."; } leaf-list bearer-lag-member { type bearer-svc:bearer-ref; config false; description "Reports LAG members."; } leaf sync-phy-capable { type boolean; config false; description "Indicates, when set to true, that a mechanism for physical layer synchronization is supported for this bearer. No such mechanism is supported if set to false."; } leaf sync-phy-enabled { type boolean; description "Indicates, when set to true, that a mechanism for physical layer synchronization is enabled for this bearer. No such mechanism is enabled if set to false."; } leaf sync-phy-type { when "../sync-phy-enabled='true'"; type identityref { base sync-phy-type; } description "Type of the physical layer synchronization that is enabled for this bearer."; } leaf provider-location-reference { type string; description "Specifies the provider's location reference."; } container customer-point { description "Base container to link theBearerbearer existence."; leaf identified-by { type identityref { base identification-type; } description "Specifies how the customer point is identified."; } container device { when "derived-from-or-self(../identified-by, " + "'bearer-svc:device-id') or " + "derived-from-or-self(../identified-by, " + "'bearer-svc:site-and-device-id')" { description "Only applicable if identified-by is device."; } description "Bearer is linked to device."; leaf device-id { type string; description "Identifier for the device where that bearer belongs."; } container location { description "Location of the node."; uses location-information; } } container site { when "derived-from-or-self(../identified-by, " + "'bearer-svc:site-id') or " + "derived-from-or-self(../identified-by, " + "'bearer-svc:site-and-device-id')" { description "Only applicable if identified-by is site."; } description "Bearer is linked to a site."; leaf site-id { type string; description "Identifier for the site or sites where that bearer belongs."; } container location { description "Location of the node."; uses location-information; } } leaf custom-id { when "derived-from-or-self(../identified-by, " + "'bearer-svc:custom')" { description "Only enabledidif identified-by is custom."; } type string; description "Thesemanticsemantics of this identifier is shared between the customer/provider using out-of-band means."; } } leaf type { type identityref { base bearer-type; } description "Type of the bearer (e.g., Ethernet or wireless)."; } leaf test-only { type empty; description "When present, this indicates that this is a feasibility check request. No resources are committed for such bearer requests."; } leaf bearer-reference { if-feature "ac-common:server-assigned-reference"; type string; config false; description "This is an internal reference for the service provider to identify the bearers."; } leaf-list ac-svc-ref { type ac-svc:attachment-circuit-reference; config false; description "Specifies the set ofACesACs that are bound to the bearer."; } uses ac-common:op-instructions; uses ac-common:service-status; } } }<CODE ENDS>]]></sourcecode> </section> <section anchor="sec-ac-module"> <name>The AC Service ("ietf-ac-svc") YANG Module</name> <t>This module uses types defined in <xref target="RFC6991"/>, <xref target="RFC9181"/>, <xref target="RFC8177"/>, and <xreftarget="I-D.ietf-opsawg-teas-common-ac"/>.target="RFC9833"/>. Also, the module uses the extensions defined in <xref target="RFC8341"/>.</t> <!--[rfced] We note that RFC 4271 is only cited in the "ietf-ac-svc" YANG module. In order to have a 1:1 matchup between the references section and the text, may we add it to the RFCs listed prior to the YANG module and add a normative reference for it? Original: This module uses types defined in [RFC6991], [RFC9181], [RFC8177], and [I-D.ietf-opsawg-teas-common-ac]. Perhaps:: This module uses types defined in [RFC4271], [RFC6991], [RFC9181], [RFC8177], and [RFC9833]. ... [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>. --> <!--[rfced] FYI, the YANG module "ietf-ac-svc" has been updated per the formatting option of pyang. Please let us know any concerns. (No changes were needed for "ietf-bearer-svc".) --> <sourcecodetype="yang"><![CDATA[ <CODE BEGINS> file "ietf-ac-svc@2025-01-07.yang"name="ietf-ac-svc@2025-08-11.yang" type="yang" markers="true"><![CDATA[ module ietf-ac-svc { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ac-svc"; prefix ac-svc; import ietf-ac-common { prefix ac-common; reference "RFCCCCC:9833: A Common YANG Data Model for Attachment Circuits"; } import ietf-vpn-common { prefix vpn-common; reference "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 VPNs"; } import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control Model"; } 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"; } 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 YANGmodelmodule for exposingattachment circuits as a service'Attachment Circuits'-as-a-Service (ACaaS). 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;9834; see the RFC itself for full legal notices."; revision2025-01-072025-08-11 { description "Initial revision."; reference "RFCXXXX:9834: YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)"; } /* A set of typedefs to ease referencing cross-modules */ typedef attachment-circuit-reference { type leafref { path "/ac-svc:attachment-circuits/ac-svc:ac/ac-svc:name"; } description "Defines a reference to an attachment circuit that can be used by other modules."; } typedef ac-group-reference { type leafref { path "/ac-svc:attachment-circuits/ac-svc:ac-group-profile" + "/ac-svc:name"; } description "Defines a reference to an attachment circuit profile."; } typedef encryption-profile-reference { type leafref { path "/ac-svc:specific-provisioning-profiles" + "/ac-svc:valid-provider-identifiers" + "/ac-svc:encryption-profile-identifier/ac-svc:id"; } description "Defines a reference to an encryption profile."; } typedef qos-profile-reference { type leafref { path "/ac-svc:specific-provisioning-profiles" + "/ac-svc:valid-provider-identifiers" + "/ac-svc:qos-profile-identifier/ac-svc:id"; } description "Defines a reference to a QoS profile."; } typedef failure-detection-profile-reference { type leafref { path "/ac-svc:specific-provisioning-profiles" + "/ac-svc:valid-provider-identifiers" + "/ac-svc:failure-detection-profile-identifier" + "/ac-svc:id"; } description "Defines a reference to a BFD profile."; } typedef forwarding-profile-reference { type leafref { path "/ac-svc:specific-provisioning-profiles" + "/ac-svc:valid-provider-identifiers" + "/ac-svc:forwarding-profile-identifier/ac-svc:id"; } description "Defines a reference to a forwarding profile."; } typedef routing-profile-reference { type leafref { path "/ac-svc:specific-provisioning-profiles" + "/ac-svc:valid-provider-identifiers" + "/ac-svc:routing-profile-identifier/ac-svc:id"; } description "Defines a reference to a routing profile."; } typedef service-profile-reference { type leafref { path "/ac-svc:service-provisioning-profiles" + "/ac-svc:service-profile-identifier" + "/ac-svc:id"; } description "Defines a reference to a service profile."; } /******************** Reusable groupings ********************/ // Basic Layer 2 connection grouping l2-connection-basic { description "Defines Layer 2 protocols and parameters that can be factorized when provisioning Layer 2 connectivity among multiple ACs."; container encapsulation { description "Container for Layer 2 encapsulation."; leaf type { type identityref { base vpn-common:encapsulation-type; } description "Encapsulation type."; } container dot1q { when "derived-from-or-self(../type, 'vpn-common:dot1q')" { description "Only applies when the type of the tagged interface is 'dot1q'."; } description "Tagged interface."; uses ac-common:dot1q; } container qinq { when "derived-from-or-self(../type, 'vpn-common:qinq')" { description "Only applies when the type of the tagged interface is 'qinq'."; } description "Includes QinQ parameters."; uses ac-common:qinq; } } } // Full Layer 2 connection grouping l2-connection { description "Defines Layer 2 protocols and parameters that are used to enable AC connectivity."; container encapsulation { description "Container for Layer 2 encapsulation."; leaf type { type identityref { base vpn-common:encapsulation-type; } description "Indicates the encapsulation type."; } container dot1q { when "derived-from-or-self(../type, 'vpn-common:dot1q')" { description "Only applies when the type of the tagged interface is 'dot1q'."; } description "Tagged interface."; uses ac-common:dot1q; } container priority-tagged { when "derived-from-or-self(../type, " + "'vpn-common:priority-tagged')" { description "Only applies when the type of the tagged interface is 'priority-tagged'."; } description "Priority-tagged interface."; uses ac-common:priority-tagged; } container qinq { when "derived-from-or-self(../type, 'vpn-common:qinq')" { description "Only applies when the type of the tagged interface is 'qinq'."; } description "Includes QinQ parameters."; uses ac-common:qinq; } } 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. It is only applicable when a tunnel is required."; 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."; } } } 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."; } } // Basic IP connection grouping ip-connection-basic { description "Defines basic IP connection parameters."; container ipv4 { if-feature "vpn-common:ipv4"; description "IPv4-specific parameters."; uses ac-common:ipv4-connection-basic; } container ipv6 { if-feature "vpn-common:ipv6"; description "IPv6-specific parameters."; uses ac-common:ipv6-connection-basic; } } // Full IP connection grouping ip-connection { description "Defines IP connection parameters."; container ipv4 { if-feature "vpn-common:ipv4"; description "IPv4-specific parameters."; uses ac-common:ipv4-connection { augmentac-svc:allocation-type/static-addresses/address"ac-svc:allocation-type/static-addresses/address" { leaf failure-detection-profile { if-feature "vpn-common:bfd"; type failure-detection-profile-reference; description "Points to a failure detection profile."; } description "Adds a failure detection profile."; } } } container ipv6 { if-feature "vpn-common:ipv6"; description "IPv6-specific parameters."; uses ac-common:ipv6-connection { augmentac-svc:allocation-type/static-addresses/address"ac-svc:allocation-type/static-addresses/address" { leaf failure-detection-profile { if-feature "vpn-common:bfd"; type failure-detection-profile-reference; description "Points to a failure detection profile."; } description "Adds a failure detection profile."; } } } choice l3-service { description "The Layer 3 connectivity service can be provided by specifying a Layer 3 tunnel service."; container l3-tunnel-service { description "Defines a Layer 3 tunnel termination. It is only applicable when a tunnel is required."; leaf type { type identityref { base ac-common:l3-tunnel-type; } description "Selects the tunnel termination type for an AC."; } } } } // Routing protocol list grouping routing-protocol-list { description "List of routing protocols used on the AC."; leaf type { type identityref { base vpn-common:routing-protocol-type; } description "Type of routing protocol."; } list routing-profiles { key "id"; description "Routing profiles."; leaf id { type routing-profile-reference; description "Reference to the routing profile to be used."; } leaf type { type identityref { base vpn-common:ie-type; } description "Import, export, or both."; } } } // Static routing with BFD grouping ipv4-static-rtg-with-bfd { description "Configuration specific to IPv4 static routing with failure protection (e.g., BFD)."; 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; leaf failure-detection-profile { if-feature "vpn-common:bfd"; type failure-detection-profile-reference; description "Points to a failure detection profile."; } uses ac-common:service-status; } } grouping ipv6-static-rtg-with-bfd { description "Configuration specific to IPv6 static routing with failure protection (e.g., BFD)."; 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; leaf failure-detection-profile { if-feature "vpn-common:bfd"; type failure-detection-profile-reference; description "Points to a failure detection profile."; } uses ac-common:service-status; } } // BGP Service grouping bgp-neighbor-without-name { description "A grouping with generic parameters for configuring a BGP neighbor."; leaf remote-address { type inet:ip-address; description "The remote IP address of this entry's BGP peer. This is a customer IP address. If this leaf is not present, this means that the primary customer IP address is used as the remote IP address."; } leaf local-address { type inet:ip-address; description "The provider's IP address that will be used to establish the BGP session."; } uses ac-common:bgp-peer-group-without-name; container bgp-max-prefix { description "A container for the maximum number of BGP prefixes allowed in the BGP session."; 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."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 8.2.2"; } } uses ac-common:bgp-authentication; uses ac-common:op-instructions; uses ac-common:service-status; } grouping bgp-neighbor-with-name { description "A grouping with generic parameters for configuring a BGP neighbor with an identifier."; leaf id { type string; description "An identifier that uniquely identifies a neighbor."; } uses ac-svc:bgp-neighbor-without-name; } grouping bgp-neighbor-with-server-reference { description "A grouping with generic parameters for configuring a BGP neighbor with a reference generated by the provider."; leaf server-reference { if-feature "ac-common:server-assigned-reference"; type string; config false; description "This is an internal reference for the service provider to identify the BGP session."; } uses ac-svc:bgp-neighbor-without-name; } grouping bgp-neighbor-with-name-server-reference { description "A grouping with generic parameters for configuring a BGP neighbor with an identifier and a reference generated by the provider."; leaf id { type string; description "An identifier that uniquely identifiers a neighbor."; } uses ac-svc:bgp-neighbor-with-server-reference; } grouping bgp-svc { description "Configuration specific to BGP."; container peer-groups { description "Configuration for BGP peer-groups"; list peer-group { key "name"; description "List of BGP peer-groups configured on the local system--- uniquely identified by peer-group name."; uses ac-common:bgp-peer-group-with-name; leaf local-address { type inet:ip-address; description "The provider's local IP address that will be used to establish the BGP session."; } container bgp-max-prefix { description "A container for the maximum number of BGP prefixes allowed in the BGP session."; 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."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 8.2.2"; } } uses ac-common:bgp-authentication; } } list neighbor { key "id"; description "List of BGP neighbors."; uses ac-svc:bgp-neighbor-with-name-server-reference; leaf peer-group { type leafref { path "../../peer-groups/peer-group/name"; } description "The peer-group with which this neighbor is associated."; } leaf failure-detection-profile { if-feature "vpn-common:bfd"; type failure-detection-profile-reference; description "Points to a failure detection profile."; } } } // OSPF Service grouping ospf-svc { description "Service configuration specific to OSPF."; uses ac-common:ospf-basic; uses ac-common:ospf-authentication; uses ac-common:service-status; } // IS-IS Service grouping isis-svc { description "Service configuration specific to IS-IS."; uses ac-common:isis-basic; uses ac-common:isis-authentication; uses ac-common:service-status; } // RIP Service grouping rip-svc { description "Service 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."; } uses ac-common:rip-authentication; uses ac-common:service-status; } // VRRP Service grouping vrrp-svc { description "Service 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."; } uses ac-common:service-status; } // Basic routing parameters grouping routing-basic { description "Defines basic parameters 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."; } uses routing-protocol-list; 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"; list peer-group { key "name"; description "List of BGP peer-groups configured on the local system--- uniquely identified by peer-group name."; uses ac-common:bgp-peer-group-with-name; } } } 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 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; } 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."; leaf address-family { type identityref { base vpn-common:address-family; } description "Indicates whether IPv4, IPv6, or both address families are to be activated."; } } 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."; leaf address-family { type identityref { base vpn-common:address-family; } description "Indicates whether IPv4, IPv6, or both address families are to be enabled."; } } } } // Full routing parameters 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."; } uses routing-protocol-list; container static { when "derived-from-or-self(../type, " + "'vpn-common:static-routing')" { description "Only applies when the protocol is the static routing protocol."; } description "Configuration specific to static routing."; container cascaded-lan-prefixes { description "LAN prefixes from the customer."; uses ipv4-static-rtg-with-bfd; uses ipv6-static-rtg-with-bfd; } } 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."; uses bgp-svc; } 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 ospf-svc; } 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 isis-svc; } 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-svc; } 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."; uses vrrp-svc; } } } // Encryption choice grouping encryption-choice { description "Container for the encryption profile."; choice profile { description "Choice for the encryption profile."; case provider-profile { leaf provider-profile { type encryption-profile-reference; description "Reference to a provider encryption profile."; } } case customer-profile { leaf customer-key-chain { type key-chain:key-chain-ref; description "Customer-supplied key chain."; } } } } // Basic security parameters grouping ac-security-basic { description "AC-specific security parameters."; container encryption { if-feature "vpn-common:encryption"; description "Container for AC security 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."; uses encryption-choice; } } // Bandwidth parameters grouping bandwidth { description "Container for bandwidth."; container svc-pe-to-ce-bandwidth { if-feature "vpn-common:inbound-bw"; description "From the customer site's perspective, the inbound bandwidth of the AC or download bandwidth from the service provider to the site."; uses ac-common:bandwidth-per-type; } container svc-ce-to-pe-bandwidth { if-feature "vpn-common:outbound-bw"; description "From the customer site's perspective, the outbound bandwidth of the AC or upload bandwidth from the CE to the PE."; uses ac-common:bandwidth-per-type; } } // Basic AC parameters grouping ac-basic { description "Grouping for basic parameters for an attachment circuit."; leaf name { type string; description "A name that uniquely identifies the 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-basic; } container ip-connection { if-feature "ac-common:layer3-ac"; description "Defines IP connection parameters."; uses ip-connection-basic; } container routing-protocols { description "Defines routing protocols."; uses routing-basic; } container oam { description "Defines the Operations, Administration, and Maintenance (OAM) mechanisms used."; container bfd { if-feature "vpn-common:bfd"; description "Container for BFD."; uses ac-common:bfd; } } container security { description "AC-specific security parameters."; uses ac-security-basic; } container service { description "AC-specific bandwidth parameters."; leaf mtu { type uint32; units "bytes"; description "Layer 2 MTU."; } uses bandwidth; } } // Full AC parameters grouping ac { description "Grouping for an attachment circuit."; leaf name { type string; description "A name of the AC. Data models that need to reference an AC should use 'attachment-circuit-reference'."; } leaf-list service-profile { type service-profile-reference; description "A reference to a service profile."; } 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; } 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."; container bfd { if-feature "vpn-common:bfd"; description "Container for BFD."; list session { key "id"; description "List of BFD sessions."; leaf id { type string; description "A unique identifier for the BFD session."; } leaf local-address { type inet:ip-address; description "Provider's IP address of the BFD session."; } leaf remote-address { type inet:ip-address; description "Customer's IP address of the BFD session."; } leaf profile { type failure-detection-profile-reference; description "Points to a BFD profile."; } uses ac-common:bfd; uses ac-common:service-status; } } } container security { description "AC-specific security parameters."; uses ac-security-basic; } container service { description "AC-specific bandwidth parameters."; leaf mtu { type uint32; units "bytes"; description "Layer 2 MTU."; } uses bandwidth; container qos { if-feature "vpn-common:qos"; description "QoS configuration."; container qos-profiles { description "QoS profile configuration."; list qos-profile { key "profile"; description "Points to a QoS profile."; leaf profile { type qos-profile-reference; description "QoS profile to be used."; } 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 "profile"; description "Points to an ACL profile."; leaf profile { type forwarding-profile-reference; description "Forwarding profile to be used."; } } } } } } // Parent and Child ACs grouping ac-hierarchy { description "Container for parent and child AC references."; leaf-list parent-ref { type ac-svc:attachment-circuit-reference; description "Specifies a parent AC that is inherited by an AC. In contexts where dynamic termination points are bound to the same AC, a parent AC with stable information is created with a set of child ACs to track dynamic AC information."; } leaf-list child-ref { type ac-svc:attachment-circuit-reference; config false; description "Specifies a child AC that relies upon a parent AC."; } } /******************** Main AC containers ********************/ container specific-provisioning-profiles { description "Contains a set of valid profiles to reference for an AC."; uses ac-common:ac-profile-cfg; } container service-provisioning-profiles { description "Contains a set of valid profiles to reference for an AC."; list service-profile-identifier { key "id"; description "List of generic service profile identifiers."; leaf id { type string; description "Identification of the service profile to be used. The profile only has significance within the service provider's administrative domain."; } } nacm:default-deny-write; } container attachment-circuits { description "Main container for the attachment circuits. The timing constraints indicated at the 'ac' level take precedence over the values indicated at the 'attachment-circuits' level."; list ac-group-profile { key "name"; description "Maintains a list of profiles that are shared among a set of ACs."; uses ac; } container placement-constraints { description "Diversity constraint type."; uses vpn-common:placement-constraints; } leaf customer-name { type string; description "Indicates the name of the customer that requested these ACs."; } uses ac-common:op-instructions; list ac { key "name"; description "Provisioning of an attachment circuit."; leaf customer-name { type string; description "Indicates the name of the customer that requested this AC."; } leaf description { type string; description "Associates a description with an AC."; } leaf test-only { type empty; description "When present, this indicates that this is a feasibility check request. No resources are committed for such AC requests."; } uses ac-common:op-instructions; leaf role { type identityref { base ac-common:role; } description "Indicates whether this AC is used as UNI, NNI, etc."; } leaf-list peer-sap-id { type string; description "One or more peer SAPs can be indicated."; } leaf-list group-profile-ref { type ac-group-reference; description "A reference to an AC profile."; } uses ac-hierarchy; uses ac-common:redundancy-group; list service-ref { key "service-type service-id"; config false; description "Reports the set of services that are bound to the AC."; leaf service-type { type identityref { base vpn-common:service-type; } description "Indicates the service type (e.g., L3VPN or Network Slice Service)."; reference "RFC 9408: A YANG Network Data Model for Service Attachment Points (SAPs), Section 5"; } leaf service-id { type string; description "Indicates an identifier of a service instance of a given type that uses the AC."; } } leaf server-reference { if-feature "ac-common:server-assigned-reference"; type string; config false; description "Reports an internal reference for the service provider to identify the AC."; } uses ac; } } }<CODE ENDS>]]></sourcecode> </section> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <!--[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: - Paragraph 3, the first 2 sentences are not from the template: "Servers MUST verify that requesting clients are entitled to access and manipulate a given bearer or AC. For example, a given customer must not have access to bearers/ACs of other customers." - This sentence is not present: "There are no particularly sensitive RPC or action operations." If it should be added, should it be at the end of the section? 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. --> <!-- 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-bearer-svc" and "ietf-ac-svc" YANG modules define data models that are 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> <!-- DNE ends --> <t>Servers <bcp14>MUST</bcp14> verify that requesting clients are entitled to access and manipulate a given bearer or AC. For example, a given customer must not have access to bearers/ACs of other customers.The<!-- DNE begins -->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 these YANG modules 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 particular sensitivities/vulnerabilities in the "ietf-bearer-svc"module:</t> <dl>module:</t><!-- DNE ends --> <dl spacing="normal" newline="false"> <dt>'placement-constraints':</dt> <dd> <t>An attacker who is able to access this data node can modify the attributes to influence how a service is delivered to a customer, and this leads to Service Level Agreement (SLA) violations.</t> </dd> <dt>'bearer':</dt> <dd> <t>An attacker who is able to access this data node can modify the attributes of bearerand, thus,and thus hinder how ACs are built.</t></dd> <dt/> <dd><t>In addition, an attacker could attempt to add a new bearer or delete existing ones. An attacker may also change the requested type, whether it is for test-only, or the activation scheduling.</t> </dd> </dl> <t>The following subtrees and data nodes have particular sensitivities/vulnerabilities in the "ietf-ac-svc" module:</t><dl><dl spacing="normal" newline="false"> <dt>'specific-provisioning-profiles':</dt> <dd> <t>This container includes a set of sensitive data thatinfluenceinfluences how an AC will be delivered. For example, an attacker who has access to these data nodes may be able to manipulate routing policies, QoS policies, or encryption properties.</t></dd> <dt/> <dd><t>These profiles are defined with "nacm:default-deny-write" tagging <xreftarget="I-D.ietf-opsawg-teas-common-ac"/>.</t>target="RFC9833"/>.</t> </dd> <dt>'service-provisioning-profiles':</dt> <dd> <t>An attacker who has access to these data nodes may be able to manipulate service-specific policies to be applied for an AC.</t></dd> <dt/> <dd><t>This container is defined with "nacm:default-deny-write" tagging.</t> </dd> <dt>'ac':</dt> <dd> <t>An attacker who is able to access this data node can modify the attributes of an AC (e.g., QoS, bandwidth, routing protocols, keying material), leading to malfunctioning of services that will be delivered over that AC and therefore to SLA violations. In addition, an attacker could attempt to add a new AC.</t> </dd> </dl><t>Some<!-- DNE begins --><t>Some of the readable data nodes in these YANG modules may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/vulnerabilities in the "ietf-bearer-svc"module:</t> <dl>module:</t><!-- DNE ends --> <dl spacing="normal" newline="false"> <dt>'customer-name', 'customer-point' and 'locations':</dt> <dd> <t>An attacker can retrieve privacy-related information about locations from where the customer is connected or can be serviced. Disclosing such information may be used to infer the identity of the customer.</t> </dd> </dl> <t>The following subtrees and data nodes have particular sensitivities/vulnerabilities in the "ietf-ac-svc" module:</t><dl><dl spacing="normal" newline="false"> <dt>'customer-name', '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':</dt> <dd> <t>An attacker can retrieve the cryptographic keys protecting the underlying connectivity services (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 service 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 service model because it is not supported by the underlying device modules (e.g., <xref target="RFC8695"/>).</t> <t><xref target="sec-sec"/> specifies a set of encryption-related parameters that can 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 URIs in the "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688"/>:</t><artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-bearer-svc Registrant Contact: The IESG. XML: N/A;<dl spacing="compact" newline="false"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bearer-svc</dd> <dt>Registrant Contact:</dt><dd>The IESG.</dd> <dt>XML:</dt><dd>N/A; the requested URI is an XMLnamespace. URI: urn:ietf:params:xml:ns:yang:ietf-ac-svc Registrant Contact: The IESG. XML: N/A;namespace.</dd> </dl> <dl spacing="compact" newline="false"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-svc</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 modules in the "YANG Module Names"subregistryregistry <xref target="RFC6020"/> within the "YANG Parameters"registry.</t> <artwork><![CDATA[ Name: ietf-bearer-svc Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-bearer-svc Prefix: bearer-svc Reference: RFC XXXX Name: ietf-ac-svc Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-ac-svc Prefix: ac-svc Reference: RFC XXXX ]]></artwork>registry group.</t> <dl spacing="compact" newline="false"> <dt>Name:</dt><dd>ietf-bearer-svc</dd> <dt>Maintained by IANA?</dt><dd>N</dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bearer-svc</dd> <dt>Prefix:</dt><dd>bearer-svc</dd> <dt>Reference:</dt><dd>RFC 9834</dd> </dl> <dl spacing="compact" newline="false"> <dt>Name:</dt><dd>ietf-ac-svc</dd> <dt>Maintained by IANA?</dt><dd>N</dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-svc</dd> <dt>Prefix:</dt><dd>ac-svc</dd> <dt>Reference:</dt><dd>RFC 9834</dd> </dl> </section> </middle> <back> <displayreference target="I-D.ietf-grow-peering-api" to ="PEERING-API"/> <displayreference target="I-D.ietf-idr-bgp-model" to="BGP4-YANG"/> <displayreference target="I-D.ietf-netmod-rfc8407bis" to="YANG-GUIDELINES"/> <displayreference target="I-D.ietf-teas-ietf-network-slice-nbi-yang" to="NSSM"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><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.9408.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.9181.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"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> <!-- [RFC9833] draft-ietf-opsawg-teas-common-ac-15 companion doc RFC8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are supported9833, inthe SAP data model.</t> </abstract> </front> <seriesInfo name="RFC" value="9408"/> <seriesInfo name="DOI" value="10.17487/RFC9408"/> </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 suchEDIT asthe 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="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>of 03/05/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="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="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> </front> <seriesInfo name="RFC" value="6991"/> <seriesInfo name="DOI" value="10.17487/RFC6991"/> </reference> <reference anchor="RFC8177"> <front> <title>YANG Data Model for Key Chains</title> <author fullname="A. Lindem" initials="A." role="editor" surname="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="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="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="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="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="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="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="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"/> </reference> <reference anchor="RFC8792"> <front> <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <author fullname="E. Auerswald" initials="E." surname="Auerswald"/> <author fullname="A. Farrel" initials="A." surname="Farrel"/> <author fullname="Q. Wu" initials="Q." surname="Wu"/> <date month="June" year="2020"/> <abstract> <t>This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.</t> </abstract>month='August' year='2025'/> </front> <seriesInfo name="RFC"value="8792"/>value="9833"/> <seriesInfo name="DOI"value="10.17487/RFC8792"/>value="10.17487/RFC9833"/> </reference> <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.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.4364.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.9182.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9291.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.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.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.8792.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="Instance-Data" target="https://github.com/boucadair/attachment-circuit-model/blob/main/xml-examples/svc-full-instance.xml"> <front> <title>Example of AC SVC Instance Data</title> <author> <organization/> </author> <date month="August" year="2024"/> </front> <refcontent>Commit 8081bb7</refcontent> </reference> <reference anchor="IEEE802.1AB"target="https://standards.ieee.org/ieee/802.1AB/6047/">target=""> <front> <title>IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery</title> <author> <organization>IEEE</organization> </author> <date year="2016" month="January"/> </front> <seriesInfo name="IEEE Std" value="802.1AB-2016"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7433915"/> </reference> <reference anchor="IEEE802.1AX" target="https://doi.org/10.1109/IEEESTD.2020.9105034"> <front> <title>IEEE Standard for Local and Metropolitan Area Networks--Link Aggregation</title> <author> <organization>IEEE</organization> </author> <date year="2020" month="May"/> </front> <seriesInfo name="IEEE Std" value="802.1AX-2020"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9105034"/> </reference> <reference anchor="ITU-T-G.781" target="https://www.itu.int/rec/T-REC-G.781"> <front> <title>Synchronization layer functions for frequency synchronization based on the physical layer</title> <author> <organization>ITU-T</organization> </author> <date year="2024" month="January"/> </front></reference> <reference anchor="RFC7665"> <front> <title>Service Function Chaining (SFC) Architecture</title> <author fullname="J. Halpern" initials="J." role="editor" surname="Halpern"/> <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro"/> <date month="October" year="2015"/> <abstract> <t>This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction 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"/><seriesInfoname="DOI" value="10.17487/RFC7665"/>name="ITU-T Recommendation" value="G.781"/> </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"/> <!-- [RFC9835] draft-ietf-opsawg-ntw-attachment-circuit-16 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/05/25. --> <referenceanchor="I-D.ietf-opsawg-ntw-attachment-circuit">anchor="RFC9835" target="https://www.rfc-editor.org/info/rfc9835"> <front> <title>A Network YANG Data Model for Attachment Circuits</title> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair"initials="M." surname="Boucadair">role="editor"> <organization>Orange</organization> </author> <authorfullname="Richard Roberts"initials="R."surname="Roberts">surname="Roberts" fullname="Richard Roberts"> <organization>Juniper</organization> </author> <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez deDios" initials="O. G." surname="deDios"> <organization>Telefonica</organization> </author> <authorfullname="Samier Barguil"initials="S."surname="Barguil">surname="Barguil 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="9" month="January" year="2025"/> <abstract> <t> This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit). The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). </t> </abstract>month="August" year="2025" /> </front> <seriesInfoname="Internet-Draft" value="draft-ietf-opsawg-ntw-attachment-circuit-15"/>name="RFC" value="9835" /> <seriesInfo name="DOI" value="10.17487/RFC9835"/> </reference> <!-- [RFC9836] draft-ietf-opsawg-ac-lxsm-lxnm-glue-14 IESG State: RFC Ed Queue as of 03/05/25. --> <referenceanchor="I-D.ietf-opsawg-ac-lxsm-lxnm-glue">anchor="RFC9836" target="https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ac-lxsm-lxnm-glue-14"> <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 Giraldo" fullname="Samier Barguil Giraldo"> <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="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="RFC8921"> <front> <title>Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP)</title> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="C. Jacquenet" initials="C." surname="Jacquenet"/> <author fullname="D. Zhang" initials="D." surname="Zhang"/> <author fullname="P. Georgatsos" initials="P." surname="Georgatsos"/> <date month="October" year="2020"/> <abstract> <t>This document defines the Connectivity Provisioning Negotiation Protocol (CPNP), which is designed to facilitate the dynamic negotiation of service parameters.</t> <t>CPNP is a generic protocol that can be used for various negotiation purposes that include (but are not necessarily limited to) connectivity provisioning services, storage facilities, Content Delivery Networks, etc.</t> </abstract> </front> <seriesInfo name="RFC" value="8921"/> <seriesInfo name="DOI" value="10.17487/RFC8921"/> </reference> <reference anchor="I-D.ietf-grow-peering-api"> <front> <title>Peering API</title> <author fullname="Carlos Aguado" initials="C." surname="Aguado"> <organization>Amazon</organization> </author> <author fullname="Matt Griswold" initials="M." surname="Griswold"> <organization>FullCtl</organization> </author> <author fullname="Jenny Ramseyer" initials="J." surname="Ramseyer"> <organization>Meta</organization> </author> <author fullname="Arturo L. Servin" initials="A." surname="Servin"> <organization>Google</organization> </author> <author fullname="Tom Strickx" initials="T." surname="Strickx"> <organization>Cloudflare</organization> </author> <date day="7" month="December" year="2024"/> <abstract> <t> We propose an API standard for BGP Peering, also known as interdomain interconnection through global Internet Routing. This API offers a standard way to request public (settlement-free) peering, verify the status of a request or BGP session, and list potential connection locations. The API is backed by PeeringDB OIDC, the industry standard for peering authentication. We also propose future work to cover private peering, and alternative authentication methods. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-grow-peering-api-00"/> </reference> <reference anchor="RFC8309"> <front> <title>Service Models Explained</title> <author fullname="Q. Wu" initials="Q." surname="Wu"/> <author fullname="W. Liu" initials="W." surname="Liu"/> <author fullname="A. Farrel" initials="A." surname="Farrel"/> <date month="January" year="2018"/> <abstract> <t>The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions.</t> <t>A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049).</t> <t>This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider.</t> </abstract> </front> <seriesInfo name="RFC" value="8309"/> <seriesInfo name="DOI" value="10.17487/RFC8309"/> </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="RFC8349"> <front> <title>A YANG Data Model for Routing Management (NMDA Version)</title> <author fullname="L. Lhotka" initials="L." surname="Lhotka"/> <author fullname="A. Lindem" initials="A." surname="Lindem"/> <author fullname="Y. Qu" initials="Y." surname="Qu"/> <date month="March" year="2018"/> <abstract> <t>This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.</t> <t>The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.</t> </abstract> </front> <seriesInfo name="RFC" value="8349"/> <seriesInfo name="DOI" value="10.17487/RFC8349"/> </reference> <reference anchor="I-D.ietf-idr-bgp-model"> <front> <title>YANG Model for Border Gateway Protocol (BGP-4)</title> <author fullname="Mahesh Jethanandani" initials="M." surname="Jethanandani"> <organization>Kloud Services</organization> </author> <author fullname="Keyur Patel" initials="K." surname="Patel"> <organization>Arrcus</organization> </author> <author fullname="Susan Hares" initials="S." surname="Hares"> <organization>Huawei</organization> </author> <author fullname="Jeffrey Haas" initials="J." surname="Haas"> <organization>Juniper Networks</organization> </author> <date day="21" month="October" year="2024"/> <abstract> <t> This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-model-18"/> </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="RFC4026"> <front> <title>Provider Provisioned Virtual Private Network (VPN) Terminology</title> <author fullname="L. Andersson" initials="L." surname="Andersson"/> <author fullname="T. Madsen" initials="T." surname="Madsen"/> <date month="March" year="2005"/> <abstract> <t>The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services.</t> <t>To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="4026"/> <seriesInfo name="DOI" value="10.17487/RFC4026"/> </reference> <reference anchor="RFC7607"> <front> <title>Codification of AS 0 Processing</title> <author fullname="W. Kumari" initials="W." surname="Kumari"/> <author fullname="R. Bush" initials="R." surname="Bush"/> <author fullname="H. Schiller" initials="H." surname="Schiller"/> <author fullname="K. Patel" initials="K." surname="Patel"/> <datemonth="August"year="2015"/> <abstract> <t>This document updates RFC 4271 and proscribes the use of Autonomous System (AS) 0 in the Border Gateway Protocol (BGP) OPEN, AS_PATH, AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR attributes in the BGP UPDATE message.</t> </abstract>year="2025" /> </front> <seriesInfo name="RFC"value="7607"/>value="9836" /> <seriesInfo name="DOI"value="10.17487/RFC7607"/>value="10.17487/RFC9836"/> </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<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.8921.xml"/> <!-- [I-D.ietf-grow-peering-api] draft-ietf-grow-peering-api-00 IESG State: I-D Exists asremote 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="RFC3644"> <front> <title>Policy QualityofService (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="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="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, such03/05/25. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-grow-peering-api.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8309.xml"/> <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.8349.xml"/> <!-- [I-D.ietf-idr-bgp-model] draft-ietf-idr-bgp-model-18 IESG State: I-D Exists asto protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger setofMACs 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="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 use03/05/25. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-model.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.4026.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7607.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.9234.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.2453.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2080.xml"/> <!-- draft-ietf-netmod-rfc8407bis-28 (in queue inthe IPv4 Internet [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2080"/> <seriesInfo name="DOI" value="10.17487/RFC2080"/> </reference>EDIT state) --> <referenceanchor="I-D.ietf-netmod-rfc8407bis">anchor="I-D.ietf-netmod-rfc8407bis" target="https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28"> <front> <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title> <authorfullname="Andy Bierman"initials="A."surname="Bierman">surname="Bierman" fullname="Andy Bierman"> <organization>YumaWorks</organization> </author> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair"initials="M." surname="Boucadair">role="editor"> <organization>Orange</organization> </author> <authorfullname="Qin Wu"initials="Q."surname="Wu">surname="Wu" fullname="Qin Wu"> <organization>Huawei</organization> </author> <dateday="14" month="January" year="2025"/> <abstract> <t> This memo provides guidelines for authors and reviewers of specifications containing YANG modules, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. The document also updates RFC 6020 by clarifying how modules and their revisions are handled by IANA. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis-22"/> </reference> <reference anchor="RFC8040"> <front> <title>RESTCONF Protocol</title> <author fullname="A. Bierman" initials="A." surname="Bierman"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <date month="January" year="2017"/> <abstract> <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t> </abstract> </front> <seriesInfo name="RFC" value="8040"/> <seriesInfo name="DOI" value="10.17487/RFC8040"/> </reference> <reference anchor="RFC4252"> <front> <title>The Secure Shell (SSH) Authentication Protocol</title> <author fullname="T. Ylonen" initials="T." surname="Ylonen"/> <author fullname="C. Lonvick" initials="C." role="editor" surname="Lonvick"/> <date month="January" year="2006"/> <abstract> <t>The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4252"/> <seriesInfo name="DOI" value="10.17487/RFC4252"/> </reference> <reference anchor="RFC8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <date month="August" year="2018"/> <abstract> <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="RFC9000"> <front> <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/> <date month="May" year="2021"/> <abstract> <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t> </abstract> </front> <seriesInfo name="RFC" value="9000"/> <seriesInfo name="DOI" value="10.17487/RFC9000"/> </reference> <reference anchor="RFC8695"> <front> <title>A YANG Data Model for the Routing Information Protocol (RIP)</title> <author fullname="X. Liu" initials="X." surname="Liu"/> <author fullname="P. Sarda" initials="P." surname="Sarda"/> <author fullname="V. Choudhary" initials="V." surname="Choudhary"/> <date month="February" year="2020"/> <abstract> <t>This document describes a data model for the management of the Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. 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> <reference anchor="I-D.ietf-teas-ietf-network-slice-nbi-yang"> <front> <title>A YANG Data Model for the RFC 9543 Network Slice Service</title> <author fullname="Bo Wu" initials="B." surname="Wu"> <organization>Huawei Technologies</organization> </author> <author fullname="Dhruv Dhody" initials="D." surname="Dhody"> <organization>Huawei Technologies</organization> </author> <author fullname="Reza Rokui" initials="R." surname="Rokui"> <organization>Ciena</organization> </author> <author fullname="Tarek Saad" initials="T." surname="Saad"> <organization>Cisco Systems, Inc</organization> </author> <author fullname="John Mullooly" initials="J." surname="Mullooly"> <organization>Cisco Systems, Inc</organization> </author> <date day="21" month="January" year="2025"/> <abstract> <t> This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. </t> </abstract>month="June" day="5" year="2025" /> </front> <seriesInfo name="Internet-Draft"value="draft-ietf-teas-ietf-network-slice-nbi-yang-18"/> </reference> <reference anchor="RFC6151"> <front> <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title> <author fullname="S. Turner" initials="S." surname="Turner"/> <author fullname="L. Chen" initials="L." surname="Chen"/> <date month="March" year="2011"/> <abstract> <t>This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="6151"/> <seriesInfo name="DOI" value="10.17487/RFC6151"/>value="draft-ietf-netmod-rfc8407bis-28"/> </reference><reference anchor="RFC6952"> <front> <title>Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide</title> <author fullname="M. Jethanandani" initials="M." surname="Jethanandani"/> <author fullname="K. Patel" initials="K." surname="Patel"/> <author fullname="L. Zheng" initials="L." surname="Zheng"/> <date month="May" year="2013"/> <abstract> <t>This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.</t> </abstract> </front> <seriesInfo name="RFC" value="6952"/> <seriesInfo name="DOI" value="10.17487/RFC6952"/> </reference> <reference anchor="RFC0826"> <front> <title>An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware</title> <author fullname="D. Plummer" initials="D." surname="Plummer"/> <date month="November" year="1982"/> <abstract> <t>The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8695.xml"/> <!-- [I-D.ietf-teas-ietf-network-slice-nbi-yang] draft-ietf-teas-ietf-network-slice-nbi-yang-22 IESG State: IESG Evaluation as ofan Internet Standard.</t> </abstract> </front> <seriesInfo name="STD" value="37"/> <seriesInfo name="RFC" value="826"/> <seriesInfo name="DOI" value="10.17487/RFC0826"/> </reference> <reference anchor="RFC4861"> <front> <title>Neighbor Discovery for IP version 6 (IPv6)</title> <author fullname="T. Narten" initials="T." surname="Narten"/> <author fullname="E. Nordmark" initials="E." surname="Nordmark"/> <author fullname="W. Simpson" initials="W." surname="Simpson"/> <author fullname="H. Soliman" initials="H." surname="Soliman"/> <date month="September" year="2007"/> <abstract> <t>This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4861"/> <seriesInfo name="DOI" value="10.17487/RFC4861"/> </reference>03/05/25. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-teas-ietf-network-slice-nbi-yang.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6952.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0826.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/> </references> </references> <?line 3692?> <section anchor="examples"> <name>Examples</name> <t>This section includes a non-exhaustive list of examples to illustrate the use of the service models defined in this document. An example of instance data can also be found at <xref target="Instance-Data"/>.</t> <t>Some of the examples below use line wrapping per <xref target="RFC8792"/>.</t> <section anchor="ex-create-bearer"> <name>Create a New Bearer</name> <t>An example of a request message body to create a bearer is shown in <xref target="create-bearer"/>.</t> <figure anchor="create-bearer"> <name>Example of a Message Body to Create a New Bearer</name> <sourcecode type="json"><![CDATA[ { "ietf-bearer-svc:bearers": { "bearer": [ { "name": "a-name-choosen-by-client", "description": "A bearer example", "customer-point": { "identified-by": "ietf-bearer-svc:device-id", "device": { "device-id": "CE_X_SITE_Y" } }, "type": "ietf-bearer-svc:ethernet" } ] } } ]]></sourcecode> </figure> <t>A 'bearer-reference' is then generated by the controller for this bearer. <xref target="get-bearer"/> shows the example of a response message body that is sent by the controller to reply to a GET request:</t> <figure anchor="get-bearer"> <name>Example of a Response Message Body with the Bearer Reference</name> <sourcecode type="json"><![CDATA[ { "ietf-bearer-svc:bearers": { "bearer": [ { "name": "a-name-choosen-by-client", "description": "A bearer example", "sync-phy-capable": true, "customer-point": { "identified-by": "ietf-bearer-svc:device-id", "device": { "device-id": "CE_X_SITE_Y" } }, "type": "ietf-bearer-svc:ethernet", "bearer-reference": "line-156" } ] } } ]]></sourcecode> </figure> <t>Note that the response also indicates that Sync Phy mechanism is supported for this bearer.</t> </section> <section anchor="ac-bearer-exist"> <name>Create an AC over an Existing Bearer</name> <t>An example of a request message body to create a simple AC over an existing bearer is shown in <xref target="ac-b"/>. The bearer reference is assumed to be known to both the customer and the network provider. Such a reference can be retrieved, e.g., following the example described in <xref target="ex-create-bearer"/> or using other means(including,(including exchanged out-of-band or via proprietary APIs).</t> <figure anchor="ac-b"> <name>Example of a Message Body to Request an AC over an Existing Bearer</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "ac4585", "description": "An AC on an existing bearer", "requested-start": "2023-12-12T05:00:00.00Z", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q" }, "bearer-reference": "line-156" } } ] } } ]]></sourcecode> </figure> <t><xref target="ac-br"/> shows the message body of a GET response received from the controller andwhichthat indicates the 'cvlan-id' that was assigned for the requested AC.</t> <figure anchor="ac-br"> <name>Example of a Message Body of a Response to Assign aCVLANCustomer VLAN (CVLAN) ID</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "ac4585", "description": "An AC on an existing bearer", "actual-start": "2023-12-12T05:00:00.00Z", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "tag-type": "ietf-vpn-common:c-vlan", "cvlan-id": 550 } }, "bearer-reference": "line-156" } } ] } } ]]></sourcecode> </figure> </section> <section anchor="ac-no-bearer-peer-sap"> <name>Create an AC for a Known Peer SAP</name> <t>An example of a request to create a simple AC, when the peer SAP is known, is shown in <xref target="ac-known-ps"/>. In this example, the peer SAP identifier points to an identifier of an SF. The (topological) location of that SF is assumed to be known to the network controller. For example, this can be determined as part of an on-demand procedure to instantiate an SF in a cloud. That instantiated SF can be granted a connectivity service via the provider network.</t> <figure anchor="ac-known-ps"> <name>Example of a Message Body to Request an AC with a Peer SAP</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "ac4585", "description": "An AC for a known peer SAP", "requested-start": "2025-12-12T05:00:00.00Z", "peer-sap-id": [ "nf-termination-ip" ] } ] } } ]]></sourcecode> </figure> <t><xref target="ac-known-ps-res"/> shows the received GET response with the requiredinformaitoninformation to connect the SF.</t> <figure anchor="ac-known-ps-res"> <name>Example of a Message Body of a Response to Create an AC with a Peer SAP</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "ac4585", "description": "An AC for a known peer SAP", "actual-start": "2025-12-12T05:00:00.00Z", "peer-sap-id": [ "nf-termination-ip" ], "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "tag-type": "ietf-vpn-common:c-vlan", "cvlan-id": 550 } } } } ] } } ]]></sourcecode> </figure> </section> <section anchor="sec-ex-one-ce-multi-acs"> <name>One CE, Two ACs</name> <t>Let us consider the example of an eNodeB (CE) that is directly connected to the access routers of the mobile backhaul (see <xref target="enodeb"/>). In this example, two ACs are needed to service the eNodeB (e.g., distinct VLANs forControlcontrol andUser Planes).</t>user planes).</t> <figure anchor="enodeb"> <name>Example ofaCE-PE ACs</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="240" width="432" viewBox="0 0 432 240" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,32 L 8,160" fill="none" stroke="black"/> <path d="M 120,32 L 120,160" fill="none" stroke="black"/> <path d="M 272,32 L 272,224" fill="none" stroke="black"/> <path d="M 424,32 L 424,224" fill="none" stroke="black"/> <path d="M 8,32 L 120,32" fill="none" stroke="black"/> <path d="M 272,32 L 424,32" fill="none" stroke="black"/> <path d="M 120,64 L 184,64" fill="none" stroke="black"/> <path d="M 216,64 L 272,64" fill="none" stroke="black"/> <path d="M 120,112 L 184,112" fill="none" stroke="black"/> <path d="M 216,112 L 272,112" fill="none" stroke="black"/> <path d="M 8,160 L 120,160" fill="none" stroke="black"/> <path d="M 272,224 L 424,224" fill="none" stroke="black"/> <g class="text"> <text x="292" y="52">PE</text> <text x="200" y="68">ac1</text> <text x="328" y="68">192.0.2.1</text> <text x="60" y="84">eNodeB</text> <text x="220" y="84">VLAN</text> <text x="248" y="84">1</text> <text x="336" y="84">2001:db8::1</text> <text x="220" y="100">VLAN</text> <text x="248" y="100">2</text> <text x="200" y="116">ac2</text> <text x="156" y="148">Direct</text> <text x="160" y="164">Routing</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ .-------------. .------------------. | | | PE | | +--------ac1-------+ 192.0.2.1 | | eNodeB | VLAN 1 | 2001:db8::1 | | | VLAN 2 | | | +--------ac2-------+ | | | | | | | Direct | | '-------------' Routing | | | | | | | | '------------------' ]]></artwork> </artset> </figure> <t>An example of a request to create the ACs to service the eNodeB is shown in <xref target="two-acs-same-ce"/>. This example assumes that static addressing is used for both ACs.</t> <figure anchor="two-acs-same-ce"> <name>Example of a Message Body to Request Two ACs on the Same Link (Not Recommended)</name> <sourcecode type="json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "ac1", "description": "a first AC with a same peer node", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q" }, "bearer-reference": "line-156" }, "ip-connection": { "ipv4": { "address-allocation-type": "ietf-ac-common:static-\ address" }, "ipv6": { "address-allocation-type": "ietf-ac-common:static-\ address" } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:direct-routing" } ] } }, { "name": "ac2", "description": "a second AC with a same peer node", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q" }, "bearer-reference": "line-156" }, "ip-connection": { "ipv4": { "address-allocation-type": "ietf-ac-common:static-\ address" }, "ipv6": { "address-allocation-type": "ietf-ac-common:static-\ address" } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:direct-routing" } ] } } ] } } ]]></sourcecode> </figure> <t><xref target="two-acs-same-ce-res"/> shows the message body of a GET response received from the controller.</t> <figure anchor="two-acs-same-ce-res"> <name>Example of a Message Body of a Response to Create Two ACs on the Same Link (Not Recommended)</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "ac1", "description": "a first AC with a same peer node", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 1 } }, "bearer-reference": "line-156" }, "ip-connection": { "ipv4": { "local-address": "192.0.2.1", "prefix-length": 30, "address": [ { "address-id": "1", "customer-address": "192.0.2.2" } ] }, "ipv6": { "local-address": "2001:db8::1", "prefix-length": 64, "address": [ { "address-id": "1", "customer-address": "2001:db8::2" } ] } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:direct-routing" } ] } }, { "name": "ac2", "description": "a second AC with a same peer node", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 2 } }, "bearer-reference": "line-156" }, "ip-connection": { "ipv4": { "local-address": "192.0.2.1", "prefix-length": 30, "address": [ { "address-id": "1", "customer-address": "192.0.2.2" } ] }, "ipv6": { "local-address": "2001:db8::1", "prefix-length": 64, "address": [ { "address-id": "1", "customer-address": "2001:db8::2" } ] } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:direct-routing" } ] } } ] } } ]]></sourcecode> </figure> <t>The example shown <xref target="two-acs-same-ce-res"/> is not optimal as it includes many redundant data. <xref target="two-acs-same-ce-node-profile"/> shows a more compact request that factorizes all the redundant data.</t> <figure anchor="two-acs-same-ce-node-profile"> <name>Example of a Message Body to Request Two ACs on the Same Link (Node Profile)</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac-group-profile": [ { "name": "simple-node-profile", "l2-connection": { "bearer-reference": "line-156" }, "ip-connection": { "ipv4": { "local-address": "192.0.2.1", "prefix-length": 30, "address": [ { "address-id": "1", "customer-address": "192.0.2.2" } ] }, "ipv6": { "local-address": "2001:db8::1", "prefix-length": 64, "address": [ { "address-id": "1", "customer-address": "2001:db8::2" } ] } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:direct-routing" } ] } } ], "ac": [ { "name": "ac1", "description": "a first AC with a same peer node", "group-profile-ref": ["simple-node-profile"], "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 1 } } } }, { "name": "ac2", "description": "a second AC with a same peer node", "group-profile-ref": ["simple-node-profile"], "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 2 } } } } ] } } ]]></sourcecode> </figure> <t>A customer may request adding a new AC by simply referring to an existing per-node AC profile as shown in <xref target="add-ac-same-ce-node-profile"/>. This AC inherits all the data that was enclosed in the indicated per-node AC profile (IP addressing, routing, etc.).</t> <figure anchor="add-ac-same-ce-node-profile"> <name>Example of a Message Body to Add anewNew AC over anexisting linkExisting Link (Node Profile)</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac-group-profile": [ { "name": "simple-node-profile" } ], "ac": [ { "name": "ac3", "description": "a third AC with a same peer node", "group-profile-ref": [ "simple-node-profile" ], "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 3 } }, "bearer-reference": "line-156" } } ] } } ]]></sourcecode> </figure> </section> <section anchor="sec-ex-prec"> <name>Control Precedence over Multiple ACs</name> <t>When multiple ACs are requested by the same customer for the same site, the request can tag one of these ACs as 'primary' and the other ones as 'secondary'. An example of such a request is shown in <xref target="ac-precedence"/>. In this example, both ACs are bound to the same 'group-id', and the 'precedence' data node is set as a function of the intended role of each AC (primary or secondary).</t> <figure anchor="multipleac"> <name>An Example Topology for AC Precedence Enforcement</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="208" width="312" viewBox="0 0 312 208" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,96 L 8,144" fill="none" stroke="black"/> <path d="M 40,80 L 40,128" fill="none" stroke="black"/> <path d="M 104,64 L 104,96" fill="none" stroke="black"/> <path d="M 104,128 L 104,160" fill="none" stroke="black"/> <path d="M 272,32 L 272,96" fill="none" stroke="black"/> <path d="M 272,128 L 272,192" fill="none" stroke="black"/> <path d="M 304,32 L 304,96" fill="none" stroke="black"/> <path d="M 304,128 L 304,192" fill="none" stroke="black"/> <path d="M 272,32 L 304,32" fill="none" stroke="black"/> <path d="M 104,64 L 272,64" fill="none" stroke="black"/> <path d="M 24,80 L 40,80" fill="none" stroke="black"/> <path d="M 40,96 L 104,96" fill="none" stroke="black"/> <path d="M 272,96 L 304,96" fill="none" stroke="black"/> <path d="M 40,128 L 104,128" fill="none" stroke="black"/> <path d="M 272,128 L 304,128" fill="none" stroke="black"/> <path d="M 8,144 L 24,144" fill="none" stroke="black"/> <path d="M 104,160 L 272,160" fill="none" stroke="black"/> <path d="M 272,192 L 304,192" fill="none" stroke="black"/> <path d="M 24,80 C 15.16936,80 8,87.16936 8,96" fill="none" stroke="black"/> <path d="M 24,144 C 32.83064,144 40,136.83064 40,128" fill="none" stroke="black"/> <g class="text"> <text x="156" y="52">ac1:</text> <text x="208" y="52">primary</text> <text x="288" y="68">PE1</text> <text x="192" y="84">bearerX@site1</text> <text x="20" y="116">CE</text> <text x="156" y="148">ac2:</text> <text x="216" y="148">secondary</text> <text x="288" y="164">PE2</text> <text x="192" y="180">bearerY@site1</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ .---. ac1: primary | | .--------------------+PE1| .--. | bearerX@site1 | | | +-------' '---' |CE | | +-------. .---. '--' | ac2: secondary | | '--------------------+PE2| bearerY@site1 | | '---' ]]></artwork> </artset> </figure> <figure anchor="ac-precedence"> <name>Example of a Message Body to Associate a Precedence Level with ACs</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "ac1", "description": "A primary AC", "group": [ { "group-id": "1", "precedence": "ietf-ac-common:primary" } ], "l2-connection": { "bearer-reference": "bearerX@site1" } }, { "name": "ac2", "description": "A secondary AC", "group": [ { "group-id": "1", "precedence": "ietf-ac-common:secondary" } ], "l2-connection": { "bearer-reference": "bearerY@site1" } } ] } } ]]></sourcecode> </figure> </section> <section anchor="sec-multiple-ces"> <name>Create Multiple ACs Bound to Multiple CEs</name> <t><xref target="network-example"/> shows an example of CEs that are interconnected by a service provider network.</t> <figure anchor="network-example"> <name>Network Topology Example</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="192" width="504" viewBox="0 0 504 192" 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 8,128 L 8,144" fill="none" stroke="black"/> <path d="M 48,48 L 48,64" fill="none" stroke="black"/> <path d="M 48,112 L 48,128" fill="none" stroke="black"/> <path d="M 112,32 L 112,160" fill="none" stroke="black"/> <path d="M 392,32 L 392,160" fill="none" stroke="black"/> <path d="M 456,64 L 456,80" fill="none" stroke="black"/> <path d="M 456,128 L 456,144" fill="none" stroke="black"/> <path d="M 496,48 L 496,64" fill="none" stroke="black"/> <path d="M 496,112 L 496,128" fill="none" stroke="black"/> <path d="M 112,32 L 392,32" fill="none" stroke="black"/> <path d="M 24,48 L 48,48" fill="none" stroke="black"/> <path d="M 472,48 L 496,48" fill="none" stroke="black"/> <path d="M 48,64 L 112,64" fill="none" stroke="black"/> <path d="M 392,64 L 456,64" fill="none" stroke="black"/> <path d="M 8,80 L 32,80" fill="none" stroke="black"/> <path d="M 456,80 L 480,80" fill="none" stroke="black"/> <path d="M 24,112 L 48,112" fill="none" stroke="black"/> <path d="M 472,112 L 496,112" fill="none" stroke="black"/> <path d="M 48,128 L 112,128" fill="none" stroke="black"/> <path d="M 392,128 L 456,128" fill="none" stroke="black"/> <path d="M 8,144 L 32,144" fill="none" stroke="black"/> <path d="M 456,144 L 480,144" fill="none" stroke="black"/> <path d="M 112,160 L 392,160" 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 472,48 C 463.16936,48 456,55.16936 456,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 480,80 C 488.83064,80 496,72.83064 496,64" fill="none" stroke="black"/> <path d="M 24,112 C 15.16936,112 8,119.16936 8,128" fill="none" stroke="black"/> <path d="M 472,112 C 463.16936,112 456,119.16936 456,128" fill="none" stroke="black"/> <path d="M 32,144 C 40.83064,144 48,136.83064 48,128" fill="none" stroke="black"/> <path d="M 480,144 C 488.83064,144 496,136.83064 496,128" fill="none" stroke="black"/> <g class="text"> <text x="80" y="52">ac1</text> <text x="424" y="52">ac3</text> <text x="32" y="68">CE1</text> <text x="480" y="68">CE3</text> <text x="256" y="100">Network</text> <text x="80" y="116">ac2</text> <text x="424" y="116">ac4</text> <text x="24" y="132">CE2</text> <text x="480" y="132">CE4</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .----------------------------------. .---. ac1 | | ac3 .---. | CE1+-------+ +-------+ CE3| '---' | | '---' | Network | .---. ac2 | | ac4 .---. |CE2 +-------+ +-------+ CE4| '---' | | '---' '----------------------------------' ]]></artwork> </artset> </figure> <t>Let's assume that a request to instantiate the various ACs that are shown in <xref target="network-example"/> is sent by the customer. <xref target="multiple-sites"/> depicts the example of the message body of a GET response that is received from the controller.</t> <figure anchor="multiple-sites"> <name>Example of a Message Body of a Request to Create Multiple ACsboundBound to Multiple CEs</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac-group-profile": [ { "name": "simple-profile", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 1 } } } } ], "ac": [ { "name": "ac1", "description": "First site", "group-profile-ref": [ "simple-profile" ], "l2-connection": { "bearer-reference": "ce1-network" } }, { "name": "ac2", "description": "Second Site", "group-profile-ref": [ "simple-profile" ], "l2-connection": { "bearer-reference": "ce2-network" } }, { "name": "ac3", "description": "Third site", "group-profile-ref": [ "simple-profile" ], "l2-connection": { "bearer-reference": "ce3-network" } }, { "name": "ac4", "description": "Another site", "group-profile-ref": [ "simple-profile" ], "l2-connection": { "bearer-reference": "ce4-network" } } ] } } ]]></sourcecode> </figure> </section> <section anchor="sec-ex-slice"> <name>Binding Attachment Circuits to an IETF Network Slice</name> <t>This example shows how the AC service model complements the model defined in "A YANG Data Model for the RFC 9543 Network Slice Service" <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/> to connect a site to a Slice Service.</t> <t>First, <xref target="slice-vlan-1"/> describes the end-to-end network topology as well as the orchestration scopes:</t> <ul spacing="normal"> <li> <t>The topology is made up of two sites ("site1" and "site2"), interconnected via a Transport Network (e.g., IP/MPLS network). An SF is deployed within each site in a dedicated IP subnet.</t> </li> <li> <t>A 5G Service Management and Orchestration (SMO) is responsible for the deployment of SFs and the indirect management of a localGatewaygateway (i.e., CE).</t> </li> <li> <t>An IETF Network Slice Controller (NSC) <xref target="RFC9543"/> is responsible for the deployment of IETF Network Slices across the Transport Network.</t> </li> </ul> <t>SFs are deployed within each site.</t> <figure anchor="slice-vlan-1"> <name>An Example of a Network Topology Used to Deploy Slices</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="368" width="520" viewBox="0 0 520 368" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 32,112 L 32,144" fill="none" stroke="black"/> <path d="M 48,144 L 48,176" fill="none" stroke="black"/> <path d="M 64,112 L 64,144" fill="none" stroke="black"/> <path d="M 64,184 L 64,240" fill="none" stroke="black"/> <path d="M 80,48 L 80,80" fill="none" stroke="black"/> <path d="M 96,144 L 96,208" fill="none" stroke="black"/> <path d="M 128,144 L 128,208" fill="none" stroke="black"/> <path d="M 168,184 L 168,304" fill="none" stroke="black"/> <path d="M 200,144 L 200,208" fill="none" stroke="black"/> <path d="M 216,112 L 216,136" fill="none" stroke="black"/> <path d="M 216,208 L 216,240" fill="none" stroke="black"/> <path d="M 232,144 L 232,208" fill="none" stroke="black"/> <path d="M 280,64 L 280,80" fill="none" stroke="black"/> <path d="M 320,144 L 320,208" fill="none" stroke="black"/> <path d="M 336,112 L 336,136" fill="none" stroke="black"/> <path d="M 336,208 L 336,240" fill="none" stroke="black"/> <path d="M 352,144 L 352,208" fill="none" stroke="black"/> <path d="M 384,184 L 384,304" fill="none" stroke="black"/> <path d="M 424,144 L 424,208" fill="none" stroke="black"/> <path d="M 456,144 L 456,208" fill="none" stroke="black"/> <path d="M 464,48 L 464,80" fill="none" stroke="black"/> <path d="M 480,112 L 480,144" fill="none" stroke="black"/> <path d="M 480,184 L 480,240" fill="none" stroke="black"/> <path d="M 496,144 L 496,176" fill="none" stroke="black"/> <path d="M 512,112 L 512,144" fill="none" stroke="black"/> <path d="M 32,80 L 128,80" fill="none" stroke="black"/> <path d="M 200,80 L 352,80" fill="none" stroke="black"/> <path d="M 424,80 L 504,80" fill="none" stroke="black"/> <path d="M 32,112 L 64,112" fill="none" stroke="black"/> <path d="M 216,112 L 336,112" fill="none" stroke="black"/> <path d="M 480,112 L 512,112" fill="none" stroke="black"/> <path d="M 32,144 L 64,144" fill="none" stroke="black"/> <path d="M 96,144 L 128,144" fill="none" stroke="black"/> <path d="M 200,144 L 232,144" fill="none" stroke="black"/> <path d="M 320,144 L 352,144" fill="none" stroke="black"/> <path d="M 424,144 L 456,144" fill="none" stroke="black"/> <path d="M 480,144 L 512,144" fill="none" stroke="black"/> <path d="M 32,176 L 96,176" fill="none" stroke="black"/> <path d="M 128,176 L 200,176" fill="none" stroke="black"/> <path d="M 352,176 L 424,176" fill="none" stroke="black"/> <path d="M 456,176 L 512,176" fill="none" stroke="black"/> <path d="M 96,208 L 128,208" fill="none" stroke="black"/> <path d="M 200,208 L 232,208" fill="none" stroke="black"/> <path d="M 320,208 L 352,208" fill="none" stroke="black"/> <path d="M 424,208 L 456,208" fill="none" stroke="black"/> <path d="M 216,240 L 336,240" fill="none" stroke="black"/> <polygon class="arrowhead" points="512,80 500,74.4 500,85.6" fill="black" transform="rotate(0,504,80)"/> <polygon class="arrowhead" points="488,184 476,178.4 476,189.6" fill="black" transform="rotate(270,480,184)"/> <polygon class="arrowhead" points="432,80 420,74.4 420,85.6" fill="black" transform="rotate(180,424,80)"/> <polygon class="arrowhead" points="392,184 380,178.4 380,189.6" fill="black" transform="rotate(270,384,184)"/> <polygon class="arrowhead" points="360,80 348,74.4 348,85.6" fill="black" transform="rotate(0,352,80)"/> <polygon class="arrowhead" points="208,80 196,74.4 196,85.6" fill="black" transform="rotate(180,200,80)"/> <polygon class="arrowhead" points="176,184 164,178.4 164,189.6" fill="black" transform="rotate(270,168,184)"/> <polygon class="arrowhead" points="136,80 124,74.4 124,85.6" fill="black" transform="rotate(0,128,80)"/> <polygon class="arrowhead" points="72,184 60,178.4 60,189.6" fill="black" transform="rotate(270,64,184)"/> <polygon class="arrowhead" points="40,80 28,74.4 28,85.6" fill="black" transform="rotate(180,32,80)"/> <g class="text"> <text x="60" y="36">5G</text> <text x="88" y="36">SMO</text> <text x="252" y="36">IETF</text> <text x="288" y="36">NSC</text> <text x="444" y="36">5G</text> <text x="472" y="36">SMO</text> <text x="216" y="52">(TN</text> <text x="288" y="52">Orchestrator)</text> <text x="80" y="100">Site1</text> <text x="240" y="100">Transport</text> <text x="312" y="100">Network</text> <text x="472" y="100">Site2</text> <text x="48" y="132">SF1</text> <text x="496" y="132">SF2</text> <text x="112" y="180">GW1</text> <text x="216" y="180">PE1</text> <text x="336" y="180">PE2</text> <text x="440" y="180">GW2</text> <text x="60" y="260">LAN1</text> <text x="484" y="260">LAN2</text> <text x="64" y="276">198.51.100.0/24</text> <text x="460" y="276">203.0.113.0/24</text> <text x="132" y="324">Physical</text> <text x="188" y="324">Link</text> <text x="224" y="324">ID:</text> <text x="356" y="324">Physical</text> <text x="412" y="324">Link</text> <text x="448" y="324">ID:</text> <text x="168" y="340">bearerX@site1</text> <text x="392" y="340">bearerX@site2</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ 5G SMO IETF NSC 5G SMO | (TN Orchestrator) | | | | <-----+-----> <---------+--------> <----+----> Site1 Transport Network Site2 .---. .--------------. .---. |SF1| | | |SF2| '-+-' .---. .---. .---. .---. '-+-' | | | | | | | | | | --+-----+GW1+--------+PE1| |PE2+--------+GW2+----+-- ^ | | ^ | | | | ^ | | ^ | '---' | '-+-' '-+-' | '---' | | | | | | | | | '--------------' | | LAN1 | | LAN2 198.51.100.0/24 | | 203.0.113.0/24 | | | | Physical Link ID: Physical Link ID: bearerX@site1 bearerX@site2 ]]></artwork> </artset> </figure> <t><xref target="slice-vlan-2"/> describes the logical connectivity enforced thanks to both IETF Network Slice and ACaaS models.</t> <figure anchor="slice-vlan-2"> <name>Logical Overview</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="528" width="504" viewBox="0 0 504 528" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 16,48 L 16,80" fill="none" stroke="black"/> <path d="M 32,80 L 32,112" fill="none" stroke="black"/> <path d="M 48,48 L 48,80" fill="none" stroke="black"/> <path d="M 80,80 L 80,144" fill="none" stroke="black"/> <path d="M 112,80 L 112,144" fill="none" stroke="black"/> <path d="M 208,80 L 208,144" fill="none" stroke="black"/> <path d="M 224,48 L 224,80" fill="none" stroke="black"/> <path d="M 224,144 L 224,176" fill="none" stroke="black"/> <path d="M 240,80 L 240,144" fill="none" stroke="black"/> <path d="M 280,80 L 280,144" fill="none" stroke="black"/> <path d="M 296,48 L 296,80" fill="none" stroke="black"/> <path d="M 296,144 L 296,176" fill="none" stroke="black"/> <path d="M 312,80 L 312,144" fill="none" stroke="black"/> <path d="M 400,80 L 400,144" fill="none" stroke="black"/> <path d="M 432,80 L 432,144" fill="none" stroke="black"/> <path d="M 464,48 L 464,80" fill="none" stroke="black"/> <path d="M 480,80 L 480,112" fill="none" stroke="black"/> <path d="M 496,48 L 496,80" fill="none" stroke="black"/> <path d="M 320,32 L 352,32" fill="none" stroke="black"/> <path d="M 384,32 L 400,32" fill="none" stroke="black"/> <path d="M 16,48 L 48,48" fill="none" stroke="black"/> <path d="M 224,48 L 296,48" fill="none" stroke="black"/> <path d="M 464,48 L 496,48" fill="none" stroke="black"/> <path d="M 16,80 L 48,80" fill="none" stroke="black"/> <path d="M 80,80 L 112,80" fill="none" stroke="black"/> <path d="M 208,80 L 240,80" fill="none" stroke="black"/> <path d="M 280,80 L 312,80" fill="none" stroke="black"/> <path d="M 400,80 L 432,80" fill="none" stroke="black"/> <path d="M 464,80 L 496,80" fill="none" stroke="black"/> <path d="M 16,112 L 80,112" fill="none" stroke="black"/> <path d="M 112,112 L 208,112" fill="none" stroke="black"/> <path d="M 312,112 L 400,112" fill="none" stroke="black"/> <path d="M 432,112 L 496,112" fill="none" stroke="black"/> <path d="M 80,144 L 112,144" fill="none" stroke="black"/> <path d="M 208,144 L 240,144" fill="none" stroke="black"/> <path d="M 280,144 L 312,144" fill="none" stroke="black"/> <path d="M 400,144 L 432,144" fill="none" stroke="black"/> <path d="M 224,176 L 296,176" fill="none" stroke="black"/> <path d="M 112,208 L 200,208" fill="none" stroke="black"/> <path d="M 216,208 L 312,208" fill="none" stroke="black"/> <path d="M 328,208 L 392,208" fill="none" stroke="black"/> <polygon class="arrowhead" points="408,32 396,26.4 396,37.6" fill="black" transform="rotate(0,400,32)"/> <polygon class="arrowhead" points="400,208 388,202.4 388,213.6" fill="black" transform="rotate(0,392,208)"/> <polygon class="arrowhead" points="336,208 324,202.4 324,213.6" fill="black" transform="rotate(180,328,208)"/> <polygon class="arrowhead" points="328,32 316,26.4 316,37.6" fill="black" transform="rotate(180,320,32)"/> <polygon class="arrowhead" points="320,208 308,202.4 308,213.6" fill="black" transform="rotate(0,312,208)"/> <polygon class="arrowhead" points="224,208 212,202.4 212,213.6" fill="black" transform="rotate(180,216,208)"/> <polygon class="arrowhead" points="208,208 196,202.4 196,213.6" fill="black" transform="rotate(0,200,208)"/> <polygon class="arrowhead" points="120,208 108,202.4 108,213.6" fill="black" transform="rotate(180,112,208)"/> <circle cx="16" cy="272" r="6" class="closeddot" fill="black"/> <circle cx="16" cy="400" r="6" class="closeddot" fill="black"/> <g class="text"> <text x="244" y="36">AS</text> <text x="280" y="36">65536</text> <text x="368" y="36">BGP</text> <text x="420" y="36">AS</text> <text x="456" y="36">65550</text> <text x="32" y="68">SF1</text> <text x="156" y="68">192.0.2.0/30</text> <text x="372" y="68">192.0.2.4/30</text> <text x="480" y="68">SF2</text> <text x="124" y="100">.1</text> <text x="196" y="100">.2</text> <text x="324" y="100">.6</text> <text x="388" y="100">.5</text> <text x="96" y="116">GW1</text> <text x="224" y="116">PE1</text> <text x="296" y="116">PE2</text> <text x="416" y="116">GW2</text> <text x="152" y="132">vlan-id</text> <text x="352" y="132">vlan-id</text> <text x="152" y="148">100</text> <text x="352" y="148">200</text> <text x="64" y="164">198.51.100.0/24</text> <text x="444" y="164">203.0.113.0/24</text> <text x="212" y="196">sdp1</text> <text x="292" y="196">sdp2</text> <text x="148" y="228">Attachment</text> <text x="240" y="228">Network</text> <text x="296" y="228">Slice</text> <text x="372" y="228">Attachment</text> <text x="136" y="244">Circuit</text> <text x="192" y="244">"ac1"</text> <text x="272" y="244">EMBB_UP</text> <text x="360" y="244">Circuit</text> <text x="416" y="244">"ac2"</text> <text x="48" y="276">"ac1"</text> <text x="120" y="276">properties:</text> <text x="16" y="292">-</text> <text x="96" y="292">bearer-reference:</text> <text x="224" y="292">bearerX@site1</text> <text x="16" y="308">-</text> <text x="60" y="308">vlan-id:</text> <text x="112" y="308">100</text> <text x="16" y="324">-</text> <text x="36" y="324">CE</text> <text x="80" y="324">address</text> <text x="140" y="324">(GW1):</text> <text x="220" y="324">192.0.2.1/30</text> <text x="16" y="340">-</text> <text x="36" y="340">PE</text> <text x="84" y="340">address:</text> <text x="172" y="340">192.0.2.2/30</text> <text x="16" y="356">-</text> <text x="60" y="356">Routing:</text> <text x="124" y="356">static</text> <text x="216" y="356">198.51.100.0/24</text> <text x="296" y="356">via</text> <text x="136" y="372">192.0.2.1</text> <text x="192" y="372">tag</text> <text x="276" y="372">primary_UP_slice</text> <text x="48" y="404">"ac2"</text> <text x="120" y="404">properties:</text> <text x="16" y="420">-</text> <text x="96" y="420">bearer-reference:</text> <text x="224" y="420">bearerY@site2</text> <text x="16" y="436">-</text> <text x="60" y="436">vlan-id:</text> <text x="112" y="436">200</text> <text x="16" y="452">-</text> <text x="36" y="452">CE</text> <text x="80" y="452">address</text> <text x="140" y="452">(GW2):</text> <text x="220" y="452">192.0.2.5/30</text> <text x="16" y="468">-</text> <text x="36" y="468">PE</text> <text x="84" y="468">address:</text> <text x="172" y="468">192.0.2.6/30</text> <text x="16" y="484">-</text> <text x="60" y="484">Routing:</text> <text x="112" y="484">BGP</text> <text x="168" y="484">local-as:</text> <text x="232" y="484">65536</text> <text x="296" y="484">(Provider</text> <text x="356" y="484">ASN)</text> <text x="164" y="500">peer-as:</text> <text x="224" y="500">65550</text> <text x="288" y="500">(customer</text> <text x="348" y="500">ASN)</text> <text x="192" y="516">remote-address:</text> <text x="296" y="516">192.0.2.5</text> <text x="376" y="516">(Customer</text> <text x="452" y="516">address)</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ AS 65536 <----BGP--> AS 65550 .---. .--------. .---. |SF1| 192.0.2.0/30 | | 192.0.2.4/30 |SF2| '-+-' .---. .-+-. .-+-. .---. '-+-' | | |.1 .2| | | |.6 .5| | | --+-----+GW1+-----------+PE1| |PE2+----------+GW2+-----+-- | | vlan-id | | | | vlan-id | | '---' 100 '-+-' '-+-' 200 '---' 198.51.100.0/24 | | 203.0.113.0/24 '--------' sdp1 sdp2 <----------> <-----------> <-------> Attachment Network Slice Attachment Circuit "ac1" EMBB_UP Circuit "ac2" * "ac1" properties: - bearer-reference: bearerX@site1 - vlan-id: 100 - CE address (GW1): 192.0.2.1/30 - PE address: 192.0.2.2/30 - Routing: static 198.51.100.0/24 via 192.0.2.1 tag primary_UP_slice * "ac2" properties: - bearer-reference: bearerY@site2 - vlan-id: 200 - CE address (GW2): 192.0.2.5/30 - PE address: 192.0.2.6/30 - Routing: BGP local-as: 65536 (Provider ASN) peer-as: 65550 (customer ASN) remote-address: 192.0.2.5 (Customer address) ]]></artwork> </artset> </figure> <t><xref target="slice-acs"/> shows the message body of the request to create the required ACs using the ACaaS module.</t> <figure anchor="slice-acs"> <name>Message Body of a Request to Create Required ACs</name> <sourcecode type="json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "ac1", "description": "Connection to site1 on vlan 100", "requested-start": "2023-12-12T05:00:00.00Z", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "tag-type": "ietf-vpn-common:c-vlan" } }, "bearer-reference": "bearerX@site1" }, "ip-connection": { "ipv4": { "address-allocation-type": "ietf-ac-common:static-\ address" } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:static-routing", "static": { "cascaded-lan-prefixes": { "ipv4-lan-prefix": [ { "lan": "198.51.100.0/24", "next-hop": "192.0.2.1", "lan-tag": "primary_UP_slice" } ] } } } ] } }, { "name": "ac2", "description": "Connection to site2 on vlan 200", "requested-start": "2023-12-12T05:00:00.00Z", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "tag-type": "ietf-vpn-common:c-vlan" } }, "bearer-reference": "bearerY@site2" }, "ip-connection": { "ipv4": { "address-allocation-type": "ietf-ac-common:static-\ address" } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:bgp-routing", "bgp": { "neighbor": [ { "id": "1", "peer-as": 65550 } ] } } ] } } ] } } ]]></sourcecode> </figure> <t><xref target="slice-acs-res"/> shows the message body of a response to a GET request received from the controller.</t> <figure anchor="slice-acs-res"> <name>Example of a Message Body of a Response Indicating the Creation of the ACs</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "ac1", "description": "Connection to site1 on vlan 100", "actual-start": "2023-12-12T05:00:00.00Z", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "tag-type": "ietf-vpn-common:c-vlan", "cvlan-id": 100 } }, "bearer-reference": "bearerX@site1" }, "ip-connection": { "ipv4": { "local-address": "192.0.2.2", "prefix-length": 30, "address": [ { "address-id": "1", "customer-address": "192.0.2.1" } ] } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:static-routing", "static": { "cascaded-lan-prefixes": { "ipv4-lan-prefix": [ { "lan": "198.51.100.0/24", "next-hop": "192.0.2.1", "lan-tag": "primary_UP_slice" } ] } } } ] } }, { "name": "ac2", "description": "Connection to site2 on vlan 200", "actual-start": "2023-12-12T05:00:00.00Z", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "tag-type": "ietf-vpn-common:c-vlan", "cvlan-id": 200 } }, "bearer-reference": "bearerY@site2" }, "ip-connection": { "ipv4": { "local-address": "192.0.2.6", "prefix-length": 30, "address": [ { "address-id": "1", "customer-address": "192.0.2.5" } ] } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:bgp-routing", "bgp": { "neighbor": [ { "id": "1", "peer-as": 65550, "local-as": 65536 } ] } } ] } } ] } } ]]></sourcecode> </figure> <t><xref target="slice-prov"/> shows the message body of the request to create a Slice Service bound to the ACs created using <xref target="slice-acs"/>. Only references to these ACs are included in the Slice Service request.</t> <figure anchor="slice-prov"> <name>Message Body of a Request to Create a Slice Service Referring to the ACs</name> <sourcecode type="json"><![CDATA[ { "ietf-network-slice-service:network-slice-services": { "slo-sle-templates": { "slo-sle-template": [ { "id": "low-latency-template", "description": "Lowest latency forwarding behavior" } ] }, "slice-service": [ { "id": "Slice URLLC_UP", "description": "Dedicated TN Slice for URLLC-UP", "slo-sle-template": "low-latency-template", "status": {}, "sdps": { "sdp": [ { "id": "sdp1", "ac-svc-name": [ "ac1" ] }, { "id": "sdp2", "ac-svc-name": [ "ac2" ] } ] } } ] } } ]]></sourcecode> </figure> </section> <section anchor="sec-ex-cloud"> <name>Connecting a Virtualized Environment Running in a Cloud Provider</name> <t>This example (<xref target="cloud-provider-1"/>) shows how the AC service model can be used to connect a Cloud Infrastructure to a service provider network. This example makes the following assumptions:</t> <ol spacing="normal"type="1"><li> <t>Atype="1"> <li>A customer (e.g., Mobile Network Team or partner) has a virtualized infrastructure running in a Cloud Provider. A simplistic deployment is represented here with a set of Virtual Machines (VMs) running in a Virtual Private Environment. The deployment and management of this infrastructure is achieved via private APIs that are supported by the CloudProvider:Provider; this realization is out of the scope of thisdocument.</t> </li> <li> <t>Thedocument.</li> <li>The connectivity to theData Centerdata center is achieved thanks to a service based on direct attachment (physical connection), which is delivered upon ordering via an API exposed by the Cloud Provider. When ordering that connection, a unique "Connection Identifier" is generated and returned via theAPI.</t> </li> <li> <t>TheAPI.</li> <li>The customer provisions the networking logic within the Cloud Provider based on that uniqueconnection identifierConnection Identifier (i.e., logical interfaces, IP addressing, androuting).</t> </li>routing).</li> </ol> <figure anchor="cloud-provider-1"> <name>An Example of Realization for Connecting a Cloud Site</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="560" width="496" viewBox="0 0 496 560" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 32,32 L 32,272" fill="none" stroke="black"/> <path d="M 32,384 L 32,528" fill="none" stroke="black"/> <path d="M 56,80 L 56,112" fill="none" stroke="black"/> <path d="M 72,112 L 72,144" fill="none" stroke="black"/> <path d="M 88,80 L 88,112" fill="none" stroke="black"/> <path d="M 104,80 L 104,112" fill="none" stroke="black"/> <path d="M 120,112 L 120,144" fill="none" stroke="black"/> <path d="M 136,80 L 136,112" fill="none" stroke="black"/> <path d="M 152,80 L 152,112" fill="none" stroke="black"/> <path d="M 168,112 L 168,144" fill="none" stroke="black"/> <path d="M 168,176 L 168,240" fill="none" stroke="black"/> <path d="M 176,400 L 176,464" fill="none" stroke="black"/> <path d="M 184,80 L 184,112" fill="none" stroke="black"/> <path d="M 200,144 L 200,176" fill="none" stroke="black"/> <path d="M 200,240 L 200,400" fill="none" stroke="black"/> <path d="M 216,248 L 216,304" fill="none" stroke="black"/> <path d="M 216,336 L 216,392" fill="none" stroke="black"/> <path d="M 224,400 L 224,464" fill="none" stroke="black"/> <path d="M 240,176 L 240,240" fill="none" stroke="black"/> <path d="M 488,32 L 488,272" fill="none" stroke="black"/> <path d="M 488,384 L 488,528" fill="none" stroke="black"/> <path d="M 32,32 L 488,32" fill="none" stroke="black"/> <path d="M 56,80 L 88,80" fill="none" stroke="black"/> <path d="M 104,80 L 136,80" fill="none" stroke="black"/> <path d="M 152,80 L 184,80" fill="none" stroke="black"/> <path d="M 56,112 L 88,112" fill="none" stroke="black"/> <path d="M 104,112 L 136,112" fill="none" stroke="black"/> <path d="M 152,112 L 184,112" fill="none" stroke="black"/> <path d="M 64,144 L 384,144" fill="none" stroke="black"/> <path d="M 168,176 L 240,176" fill="none" stroke="black"/> <path d="M 168,240 L 240,240" fill="none" stroke="black"/> <path d="M 32,272 L 192,272" fill="none" stroke="black"/> <path d="M 224,272 L 488,272" fill="none" stroke="black"/> <path d="M 32,384 L 192,384" fill="none" stroke="black"/> <path d="M 224,384 L 488,384" fill="none" stroke="black"/> <path d="M 176,400 L 224,400" fill="none" stroke="black"/> <path d="M 176,464 L 224,464" fill="none" stroke="black"/> <path d="M 32,528 L 488,528" fill="none" stroke="black"/> <polygon class="arrowhead" points="224,392 212,386.4 212,397.6" fill="black" transform="rotate(90,216,392)"/> <polygon class="arrowhead" points="224,248 212,242.4 212,253.6" fill="black" transform="rotate(270,216,248)"/> <g class="text"> <text x="360" y="52">Cloud</text> <text x="420" y="52">Provider</text> <text x="468" y="52">DC</text> <text x="72" y="100">VM1</text> <text x="120" y="100">VM2</text> <text x="168" y="100">VM3</text> <text x="232" y="100">Virtual</text> <text x="296" y="100">Private</text> <text x="352" y="100">Cloud</text> <text x="84" y="132">.2</text> <text x="132" y="132">.5</text> <text x="184" y="132">.12</text> <text x="304" y="132">198.51.100.0/24</text> <text x="212" y="164">.1</text> <text x="200" y="196">Cloud</text> <text x="284" y="196">BGP_ASN:</text> <text x="344" y="196">65536</text> <text x="204" y="212">Provider</text> <text x="264" y="212">BGP</text> <text x="300" y="212">md5:</text> <text x="204" y="228">GW</text> <text x="372" y="228">"nyxNER_c5sdn608fFQl3331d"</text> <text x="236" y="260">.2</text> <text x="208" y="276">-</text> <text x="28" y="308">Direct</text> <text x="120" y="308">Interconnection</text> <text x="60" y="324">connection_id:</text> <text x="216" y="324">BGP</text> <text x="324" y="324">vlan-id:50</text> <text x="60" y="340">1234-56789</text> <text x="332" y="340">192.0.2.0/24</text> <text x="236" y="372">.1</text> <text x="208" y="388">-</text> <text x="156" y="404">If-A</text> <text x="312" y="404">Service</text> <text x="380" y="404">Provider</text> <text x="448" y="404">Network</text> <text x="200" y="436">PE1</text> <text x="268" y="436">BGP_ASN:</text> <text x="328" y="436">65550</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ .--------------------------------------------------------. | Cloud Provider DC | | | | .---. .---. .---. | | |VM1| |VM2| |VM3| Virtual Private Cloud | | '-+-' '-+-' '-+-' | | |.2 |.5 |.12 198.51.100.0/24 | | -+-----+-----+---+----------------------- | | |.1 | | .---+----. | | | Cloud | BGP_ASN: 65536 | | |Provider| BGP md5: | | | GW | "nyxNER_c5sdn608fFQl3331d" | | '---+----' | | | ^ .2 | '--------------------|-|---------------------------------' | | Direct Interconnection | | connection_id: |BGP vlan-id:50 1234-56789 | | 192.0.2.0/24 | | | | .1 .--------------------|-v---------------------------------. | If-A.--+--. Service Provider Network | | | | | | | PE1 | BGP_ASN: 65550 | | | | | | '-----' | | | | | | | '--------------------------------------------------------' ]]></artwork> </artset> </figure> <t><xref target="cloud-provider-2"/> illustrates the pre-provisioning logic for the physical connection to the Cloud Provider. After this connection is delivered to the service provider, the network inventory is updated with 'bearer-reference' set to the value of the Connection Identifier.</t> <figure anchor="cloud-provider-2"> <name>Illustration ofPre-provisioning</name>Pre-Provisioning</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="288" width="584" viewBox="0 0 584 288" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 136,64 L 520,64" fill="none" stroke="black"/> <path d="M 128,112 L 512,112" fill="none" stroke="black"/> <polygon class="arrowhead" points="528,64 516,58.4 516,69.6" fill="black" transform="rotate(0,520,64)"/> <polygon class="arrowhead" points="136,112 124,106.4 124,117.6" fill="black" transform="rotate(180,128,112)"/> <g class="text"> <text x="52" y="36">Customer</text> <text x="544" y="36">Cloud</text> <text x="56" y="52">Orchestration</text> <text x="188" y="52">DIRECT</text> <text x="280" y="52">INTERCONNECTION</text> <text x="380" y="52">ORDERING</text> <text x="440" y="52">(API)</text> <text x="548" y="52">Provider</text> <text x="164" y="100">Connection</text> <text x="240" y="100">Created</text> <text x="292" y="100">with</text> <text x="360" y="100">"Connection</text> <text x="468" y="100">ID:1234-56789"</text> <text x="328" y="132">x</text> <text x="328" y="148">x</text> <text x="328" y="164">x</text> <text x="328" y="180">x</text> <text x="92" y="212">Physical</text> <text x="172" y="212">Connection</text> <text x="260" y="212">1234-56789</text> <text x="316" y="212">is</text> <text x="368" y="212">delivered</text> <text x="424" y="212">and</text> <text x="240" y="228">connected</text> <text x="292" y="228">to</text> <text x="320" y="228">PE1</text> <text x="88" y="260">Network</text> <text x="160" y="260">Inventory</text> <text x="232" y="260">Updated</text> <text x="288" y="260">with:</text> <text x="144" y="276">bearer-reference:</text> <text x="260" y="276">1234-56789</text> <text x="320" y="276">for</text> <text x="392" y="276">PE1/Interface</text> <text x="476" y="276">"If-A"</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ Customer Cloud Orchestration DIRECT INTERCONNECTION ORDERING (API) Provider ------------------------------------------------> Connection Created with "Connection ID:1234-56789" <------------------------------------------------ x x x x Physical Connection 1234-56789 is delivered and connected to PE1 Network Inventory Updated with: bearer-reference: 1234-56789 for PE1/Interface "If-A" ]]></artwork> </artset> </figure> <t>Next, API workflows can be initiated by:</t> <ul spacing="normal"> <!--[rfced] "Step (3)" does not seem accurate here. Does it refer to item 3 in the list of assumptions, i.e., "3. The customer provisions the networking logic..."? If so, may it be updated as follows? Original: * The Cloud Provider for the configuration per Step (3) above. Perhaps: * The Cloud Provider for the configuration per item 3 above. --> <li> <t>The Cloud Provider for the configuration per Step (3) above.</t> </li> <li> <t>TheServiceservice provider network via the ACaaS model. This request can be used in conjunction with additional requests based on the L3SM (VPN provisioning) or Network Slice Service model (5G hybridCloudcloud deployment).</t> </li> </ul> <t><xref target="cloud-provider-ac"/> shows the message body of the request to create the required ACs to connect the virtualized Cloud ProviderVirtualized(VM) using the ACaaS module.</t> <figure anchor="cloud-provider-ac"> <name>Message Body of a Request to Create the ACs for Connecting to the Cloud Provider</name> <sourcecode type="json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "ac--BXT-DC-customer-VPC-foo", "description": "Connection to Cloud Provider BXT on \ connection 1234-56789", "requested-start": "2023-12-12T05:00:00.00Z", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q" }, "bearer-reference": "1243-56789" }, "ip-connection": { "ipv4": { "address-allocation-type": "ietf-ac-common:static-\ address" } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:bgp-routing", "bgp": { "neighbor": [ { "id": "1", "peer-as": 65536 } ] } } ] } } ] } } ]]></sourcecode> </figure> <t><xref target="cloud-provider-ac-res"/> shows the message body of the response received from the provider as a response to a query message. Note that this Cloud Provider mandates the use of MD5 authentication for establishing BGP connections.</t><ul empty="true"> <li> <t>The<!--[rfced] We note that this text was indented. As it is unclear to us why it was indented, we have removed the indentation. Was the intent for this to be a "Note"? If yes, would you like this text to be in an <aside> element, which is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). Original: The module supports MD5 to basically accommodate the installed BGP base (including by some Cloud Providers). Note that MD5 suffers from the security weaknesses discussed in Section 2 of [RFC6151] and Section 2.1 of [RFC6952]. Perhaps: | Note: The module supports MD5 to basically accommodate the installed | BGP base (including by some Cloud Providers). Note that MD5 suffers | from the security weaknesses discussed in Section 2 of [RFC6151] | and Section 2.1 of [RFC6952]. --> <t indent="3">The module supports MD5 to basically accommodate the installed BGP base (including by some Cloud Providers). Note that MD5 suffers from the security weaknesses discussed in <xref section="2" sectionFormat="of" target="RFC6151"/> and <xref section="2.1" sectionFormat="of" target="RFC6952"/>.</t></li> </ul><figure anchor="cloud-provider-ac-res"> <name>Message Body of a Response to the Request to Create ACs for Connecting to the Cloud Provider</name> <sourcecode type="json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "ac--BXT-DC-customer-VPC-foo", "description": "Connection to Cloud Provider BXT on \ connection 1234-56789", "actual-start": "2023-12-12T05:00:00.00Z", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "tag-type": "ietf-vpn-common:c-vlan", "cvlan-id": 50 } }, "bearer-reference": "1243-56789" }, "ip-connection": { "ipv4": { "local-address": "192.0.2.1", "prefix-length": 24, "address": [ { "address-id": "1", "customer-address": "192.0.2.2" } ] } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:bgp-routing", "bgp": { "neighbor": [ { "id": "1", "peer-as": 65536, "local-as": 65550, "authentication": { "enabled": true, "keying-material": { "md5-keychain": "nyxNER_c5sdn608fFQl3331d" } } } ] } } ] } } ] } } ]]></sourcecode> </figure> </section> <section anchor="sec-cus-bgp"> <name>Connect Customer Network Through BGP</name> <t>CE-PE routing using BGP is a common scenario in the context of MPLS VPNs and is widely used in enterprise networks. In the example depicted in <xref target="provider-network"/>, the CE routers are customer-owned devices belonging to an AS (ASN 65536). CEs are located at the edge of the provider's network(PE, or Provider Edge)(PE) and use point-to-point interfaces to establish BGP sessions. The point-to-point interfaces rely upon a physical bearer ("line-113") to reach the provider network.</t> <figure anchor="provider-network"> <name>Illustration of Provider Network Scenario</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="368" width="552" viewBox="0 0 552 368" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,32 L 8,352" fill="none" stroke="black"/> <path d="M 80,80 L 80,176" fill="none" stroke="black"/> <path d="M 80,208 L 80,240" fill="none" stroke="black"/> <path d="M 80,304 L 80,336" fill="none" stroke="black"/> <path d="M 184,80 L 184,176" fill="none" stroke="black"/> <path d="M 184,208 L 184,240" fill="none" stroke="black"/> <path d="M 184,304 L 184,336" fill="none" stroke="black"/> <path d="M 208,32 L 208,88" fill="none" stroke="black"/> <path d="M 208,104 L 208,352" fill="none" stroke="black"/> <path d="M 392,32 L 392,80" fill="none" stroke="black"/> <path d="M 392,112 L 392,144" fill="none" stroke="black"/> <path d="M 464,80 L 464,96" fill="none" stroke="black"/> <path d="M 544,32 L 544,144" fill="none" stroke="black"/> <path d="M 8,32 L 208,32" fill="none" stroke="black"/> <path d="M 392,32 L 544,32" fill="none" stroke="black"/> <path d="M 80,80 L 184,80" fill="none" stroke="black"/> <path d="M 416,80 L 464,80" fill="none" stroke="black"/> <path d="M 184,96 L 352,96" fill="none" stroke="black"/> <path d="M 408,112 L 448,112" fill="none" stroke="black"/> <path d="M 392,144 L 544,144" fill="none" stroke="black"/> <path d="M 80,176 L 184,176" fill="none" stroke="black"/> <path d="M 80,208 L 184,208" fill="none" stroke="black"/> <path d="M 80,240 L 184,240" fill="none" stroke="black"/> <path d="M 80,304 L 184,304" fill="none" stroke="black"/> <path d="M 80,336 L 184,336" fill="none" stroke="black"/> <path d="M 8,352 L 208,352" fill="none" stroke="black"/> <path d="M 448,112 C 456.83064,112 464,104.83064 464,96" fill="none" stroke="black"/> <g class="text"> <text x="60" y="52">Provider</text> <text x="128" y="52">Network</text> <text x="436" y="52">Customer</text> <text x="504" y="52">Network</text> <text x="300" y="68">CE-PE-AC</text> <text x="220" y="84">.2</text> <text x="372" y="84">.1</text> <text x="504" y="84">ASN</text> <text x="132" y="100">PE1(VRF11)</text> <text x="384" y="100">sap#113</text> <text x="432" y="100">CE1</text> <text x="504" y="100">65536</text> <text x="296" y="116">Bearer=line-113</text> <text x="132" y="132">PE1(VRF12)</text> <text x="300" y="132">192.0.2.1/30</text> <text x="132" y="164">PE1(VRF1n)</text> <text x="32" y="196">AS1</text> <text x="132" y="228">PE2(VRF21)</text> <text x="128" y="260">.</text> <text x="128" y="276">.</text> <text x="128" y="292">.</text> <text x="132" y="324">PEm(VRFmn)</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ .------------------------. .------------------. | Provider Network | | Customer Network | | | CE-PE-AC | | | .------------. |.2 .1 | .-----. ASN | | | PE1(VRF11) +---------------------sap#113 CE1 | 65536 | | | | | Bearer=line-113 | '-----' | | | PE1(VRF12) | | 192.0.2.1/30 | | | | | | '------------------' | | PE1(VRF1n) | | | '------------' | | AS1 | | .------------. | | | PE2(VRF21) | | | '------------' | | . | | . | | . | | .------------. | | | PEm(VRFmn) | | | '------------' | '------------------------' ]]></artwork> </artset> </figure> <t>The attachment circuit in this case uses a SAP identifier to refer to the physical interface used for the connection between the PE and the CE. The attachment circuit includes all the additional logical attributes to describe the connection between the two ends, including VLAN information and IP addressing. Also, the configuration details of the BGP sessionmakesmake use of peer group details instead of defining the entire configuration inside the 'neighbor' data node.</t> <figure anchor="add-attachment-circuit-bgp-routing"> <name>Message Body of a Request to Create ACs for Connecting CEs to a Provider Network</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "CE-PE-AC", "customer-name": "Customer-4875", "description": "An AC between a CP and a PE", "peer-sap-id": [ "sap#113" ], "ip-connection": { "ipv4": { "prefix-length": 30, "address": [ { "address-id": "1", "customer-address": "192.0.2.1" } ] } }, "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q" }, "bearer-reference": "line-113" }, "routing-protocols": { "routing-protocol": [ { "id": "BGP-Single-Access", "type": "ietf-vpn-common:bgp-routing", "bgp": { "peer-groups": { "peer-group": [ { "name": "first-peer-group", "peer-as": 65536, "address-family": "ietf-vpn-common:ipv4" } ] }, "neighbor": [ { "id": "session#57", "remote-address": "192.0.2.1", "peer-group": "first-peer-group", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } } } ] } } ] } } ] } } ]]></sourcecode> </figure> <t>This scenario allows the provider to maintain a list of ACs belonging to the same customer without requiring the full service configuration.</t> </section> <section anchor="sec-peering"> <name>Interconnection via InterneteXchangeExchange Points (IXPs)</name> <t>This section illustrates how to use the AC service model for interconnection purposes. To that aim, the document assumes a simplifiedInternet eXchange Point (IXP)IXP configuration without zooming into IXP deployment specifics. Let us assume that networks are interconnected via a Layer 2 facility. Let us also assume a deployment context where selective peering is in place between these networks. Networks that are interested in establishing selective BGP peerings expose a dedicated ACaaS server to the IXP to behave as an ACaaS provider. BGP is used to exchange routing information and reachability announcements between those networks. Any network operator connected to an IXP can behave as a client (i.e., initiate a BGP peering request).</t> <t>This example follows the recursive deployment model depicted in <xref target="_u-ex-r"/>. Specifically, base AC service requests are handled locally by the IXP. However, binding BGP sessions to existing ACs involves a recursion step.</t> <figure anchor="_u-ex-rb"> <name>Recursive Deployment Example</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="320" width="584" viewBox="0 0 584 320" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,48 L 8,80" fill="none" stroke="black"/> <path d="M 8,176 L 8,272" fill="none" stroke="black"/> <path d="M 64,96 L 64,128" fill="none" stroke="black"/> <path d="M 64,160 L 64,176" fill="none" stroke="black"/> <path d="M 104,176 L 104,272" fill="none" stroke="black"/> <path d="M 112,48 L 112,80" fill="none" stroke="black"/> <path d="M 248,48 L 248,80" fill="none" stroke="black"/> <path d="M 248,176 L 248,272" fill="none" stroke="black"/> <path d="M 296,96 L 296,128" fill="none" stroke="black"/> <path d="M 296,160 L 296,176" fill="none" stroke="black"/> <path d="M 336,48 L 336,80" fill="none" stroke="black"/> <path d="M 336,176 L 336,224" fill="none" stroke="black"/> <path d="M 336,256 L 336,272" fill="none" stroke="black"/> <path d="M 472,48 L 472,80" fill="none" stroke="black"/> <path d="M 472,176 L 472,272" fill="none" stroke="black"/> <path d="M 528,96 L 528,128" fill="none" stroke="black"/> <path d="M 528,160 L 528,176" fill="none" stroke="black"/> <path d="M 576,48 L 576,80" fill="none" stroke="black"/> <path d="M 576,176 L 576,272" fill="none" stroke="black"/> <path d="M 24,32 L 96,32" fill="none" stroke="black"/> <path d="M 264,32 L 320,32" fill="none" stroke="black"/> <path d="M 488,32 L 560,32" fill="none" stroke="black"/> <path d="M 120,64 L 240,64" fill="none" stroke="black"/> <path d="M 344,64 L 464,64" fill="none" stroke="black"/> <path d="M 24,96 L 56,96" fill="none" stroke="black"/> <path d="M 72,96 L 96,96" fill="none" stroke="black"/> <path d="M 264,96 L 288,96" fill="none" stroke="black"/> <path d="M 304,96 L 320,96" fill="none" stroke="black"/> <path d="M 488,96 L 520,96" fill="none" stroke="black"/> <path d="M 536,96 L 560,96" fill="none" stroke="black"/> <path d="M 8,176 L 56,176" fill="none" stroke="black"/> <path d="M 72,176 L 104,176" fill="none" stroke="black"/> <path d="M 248,176 L 288,176" fill="none" stroke="black"/> <path d="M 304,176 L 336,176" fill="none" stroke="black"/> <path d="M 472,176 L 520,176" fill="none" stroke="black"/> <path d="M 536,176 L 576,176" fill="none" stroke="black"/> <path d="M 112,190 L 152,190" fill="none" stroke="black"/> <path d="M 112,194 L 152,194" fill="none" stroke="black"/> <path d="M 208,190 L 240,190" fill="none" stroke="black"/> <path d="M 208,194 L 240,194" fill="none" stroke="black"/> <path d="M 344,190 L 376,190" fill="none" stroke="black"/> <path d="M 344,194 L 376,194" fill="none" stroke="black"/> <path d="M 432,190 L 464,190" fill="none" stroke="black"/> <path d="M 432,194 L 464,194" fill="none" stroke="black"/> <path d="M 104,208 L 144,208" fill="none" stroke="black"/> <path d="M 208,208 L 248,208" fill="none" stroke="black"/> <path d="M 336,208 L 376,208" fill="none" stroke="black"/> <path d="M 440,208 L 464,208" fill="none" stroke="black"/> <path d="M 112,254 L 240,254" fill="none" stroke="black"/> <path d="M 112,258 L 240,258" fill="none" stroke="black"/> <path d="M 344,254 L 464,254" fill="none" stroke="black"/> <path d="M 344,258 L 464,258" fill="none" stroke="black"/> <path d="M 8,272 L 104,272" fill="none" stroke="black"/> <path d="M 248,272 L 336,272" fill="none" stroke="black"/> <path d="M 472,272 L 576,272" fill="none" stroke="black"/> <path d="M 24,32 C 15.16936,32 8,39.16936 8,48" fill="none" stroke="black"/> <path d="M 96,32 C 104.83064,32 112,39.16936 112,48" fill="none" stroke="black"/> <path d="M 264,32 C 255.16936,32 248,39.16936 248,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 488,32 C 479.16936,32 472,39.16936 472,48" fill="none" stroke="black"/> <path d="M 560,32 C 568.83064,32 576,39.16936 576,48" fill="none" stroke="black"/> <path d="M 24,96 C 15.16936,96 8,88.83064 8,80" fill="none" stroke="black"/> <path d="M 96,96 C 104.83064,96 112,88.83064 112,80" fill="none" stroke="black"/> <path d="M 264,96 C 255.16936,96 248,88.83064 248,80" fill="none" stroke="black"/> <path d="M 320,96 C 328.83064,96 336,88.83064 336,80" fill="none" stroke="black"/> <path d="M 488,96 C 479.16936,96 472,88.83064 472,80" fill="none" stroke="black"/> <path d="M 560,96 C 568.83064,96 576,88.83064 576,80" fill="none" stroke="black"/> <polygon class="arrowhead" points="536,176 524,170.4 524,181.6" fill="black" transform="rotate(90,528,176)"/> <polygon class="arrowhead" points="536,96 524,90.4 524,101.6" fill="black" transform="rotate(270,528,96)"/> <polygon class="arrowhead" points="472,64 460,58.4 460,69.6" fill="black" transform="rotate(0,464,64)"/> <polygon class="arrowhead" points="352,64 340,58.4 340,69.6" fill="black" transform="rotate(180,344,64)"/> <polygon class="arrowhead" points="304,176 292,170.4 292,181.6" fill="black" transform="rotate(90,296,176)"/> <polygon class="arrowhead" points="304,96 292,90.4 292,101.6" fill="black" transform="rotate(270,296,96)"/> <polygon class="arrowhead" points="248,64 236,58.4 236,69.6" fill="black" transform="rotate(0,240,64)"/> <polygon class="arrowhead" points="128,64 116,58.4 116,69.6" fill="black" transform="rotate(180,120,64)"/> <polygon class="arrowhead" points="72,176 60,170.4 60,181.6" fill="black" transform="rotate(90,64,176)"/> <polygon class="arrowhead" points="72,96 60,90.4 60,101.6" fill="black" transform="rotate(270,64,96)"/> <g class="text"> <text x="172" y="36">AC</text> <text x="396" y="36">AC</text> <text x="56" y="52">Network</text> <text x="152" y="52">Service</text> <text x="208" y="52">Model</text> <text x="296" y="52">IXP</text> <text x="376" y="52">Service</text> <text x="432" y="52">Model</text> <text x="528" y="52">Network</text> <text x="52" y="68">Operator</text> <text x="96" y="68">A</text> <text x="292" y="68">Operator</text> <text x="516" y="68">Operator</text> <text x="560" y="68">B</text> <text x="280" y="84">B2B</text> <text x="312" y="84">C/S</text> <text x="68" y="148">Provisioning</text> <text x="300" y="148">Provisioning</text> <text x="532" y="148">Provisioning</text> <text x="52" y="196">ASBR</text> <text x="180" y="196">Bearer</text> <text x="280" y="196">Layer</text> <text x="312" y="196">2</text> <text x="404" y="196">Bearer</text> <text x="524" y="196">ASBR</text> <text x="164" y="212">Base</text> <text x="196" y="212">AC</text> <text x="292" y="212">Facility</text> <text x="396" y="212">Base</text> <text x="428" y="212">AC</text> <text x="176" y="244">.................</text> <text x="264" y="244">BGP</text> <text x="376" y="244">Session................</text> <text x="16" y="308">B2B</text> <text x="52" y="308">C/S:</text> <text x="124"y="308">Back-to-back</text>y="308">Back-to-Back</text> <text x="232" y="308">Client/Server</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .----------. AC .--------. AC .----------. | Network | Service Model | IXP | Service Model | Network | | Operator A |<-------------->| Operator |<-------------->| Operator B | | | | B2B C/S | | | '-----^----' '----^---' '-----^----' | | | | | | Provisioning Provisioning Provisioning | | | .------v----. .-----v----. .------v-----. | ASBR |======Bearer=====| Layer 2 |=====Bearer=====| ASBR | | +-----Base AC-----+ Facility +-----Base AC----| | | | | | | | | +..................BGP Session................+ | | |=================| |================| | '-----------' '----------' '------------' B2B C/S:Back-to-backBack-to-Back Client/Server ]]></artwork> </artset> </figure> <t>The following subsections exemplify a deployment flow, but BGP sessions can be managed without having toexecutesystematically execute all the steps detailed hereafter.</t> <t>The bearer/AC service models can be used to establish interconnection between two networks without involving an IXP.</t> <section anchor="sec-ret-loc"> <name>Retrieve Interconnection Locations</name> <t><xref target="ex-retrieve-locations"/> shows an exampleamessage body of a request to retrieve a list of interconnection locations. The request includes a customer name and an ASN to filter out the locations.</t> <figure anchor="ex-retrieve-locations"> <name>Message Body of a Request to Retrieve Interconnection Locations</name> <sourcecode type="json"><![CDATA[ { "ietf-bearer-svc:locations": { "filtered-by": "ietf-bearer-svc:customer-name", "customer": [ { "name": "a future peer", "peer-as": 65536 } ] } } ]]></sourcecode> </figure> <t><xref target="ex-retrieve-locations-res"/> provides an example of a response to a query received from the server with a list of available interconnection locations.</t> <figure anchor="ex-retrieve-locations-res"> <name>Message Body of a Response to Retrieve Interconnection Locations</name> <sourcecode type="json"><![CDATA[ { "ietf-bearer-svc:locations": { "filtered-by": "ietf-bearer-svc:customer-name", "customer": [ { "name": "a future peer", "peer-as": 65536, "location": [ { "name": "Location-X", "_comment": "other location attributes" }, { "_comment": "other locations" } ] } ] } } ]]></sourcecode> </figure> </section> <section anchor="create-bearers-and-retrieve-bearer-references"> <name>Create Bearers and Retrieve Bearer References</name> <t>A peer can then use the location information and select the ones where it can request new bearers. As shown in <xref target="ex-create-bearer-parent-ref"/>, the request includes a location referencewhichthat is known to the server (returned in <xref target="ex-retrieve-locations-res"/>).</t> <figure anchor="ex-create-bearer-parent-ref"> <name>Message Body of a Request to Create a BearerusingUsing aProvider-AssignedProvider&nbhy;Assigned Reference</name> <sourcecode type="json"><![CDATA[ { "ietf-bearer-svc:bearers": { "bearer": [ { "name": "a-name-choosen-by-client", "provider-location-reference": "Location-X", "customer-point": { "identified-by": "ietf-bearer-svc:device-id", "device": { "device-id": "ASBR_1_Location_X" } }, "type": "ietf-bearer-svc:ethernet" } ] } } ]]></sourcecode> </figure> <t>The bearer is then activated by the server as shown in <xref target="ex-create-bearer-parent-ref-res"/>. A 'bearer-reference' is also returned. That reference can be used for subsequent AC activation requests.</t> <figure anchor="ex-create-bearer-parent-ref-res"> <name>Message Body of a Response for a Bearer Created in a Specific Location</name> <sourcecode type="json"><![CDATA[ { "ietf-bearer-svc:bearers": { "bearer": [ { "name": "a-name-choosen-by-client", "provider-location-reference": "Location-X", "customer-point": { "identified-by": "ietf-bearer-svc:device-id", "device": { "device-id": "ASBR_1_Location_X" } }, "type": "ietf-bearer-svc:ethernet", "bearer-reference": "Location-X-Line-114", "status": { "oper-status": { "status": "ietf-vpn-common:op-up" } } } ] } } ]]></sourcecode> </figure> </section> <section anchor="sec-manage-ac-bgp"> <name>Manage ACs and BGP Sessions</name> <t>As depicted in <xref target="bgp-peer-network"/>, each network connects to the IXP switch via a bearer over which an AC is created.</t> <figure anchor="bgp-peer-network"> <name>Simple Interconnection Topology</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="432" width="472" viewBox="0 0 472 432" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,32 L 8,176" fill="none" stroke="black"/> <path d="M 8,272 L 8,416" fill="none" stroke="black"/> <path d="M 24,96 L 24,144" fill="none" stroke="black"/> <path d="M 24,336 L 24,384" fill="none" stroke="black"/> <path d="M 152,112 L 152,144" fill="none" stroke="black"/> <path d="M 152,336 L 152,384" fill="none" stroke="black"/> <path d="M 192,32 L 192,104" fill="none" stroke="black"/> <path d="M 192,160 L 192,176" fill="none" stroke="black"/> <path d="M 192,272 L 192,344" fill="none" stroke="black"/> <path d="M 192,360 L 192,416" fill="none" stroke="black"/> <path d="M 248,208 L 248,240" fill="none" stroke="black"/> <path d="M 312,128 L 312,208" fill="none" stroke="black"/> <path d="M 312,240 L 312,336" fill="none" stroke="black"/> <path d="M 368,208 L 368,240" fill="none" stroke="black"/> <path d="M 8,32 L 192,32" fill="none" stroke="black"/> <path d="M 24,96 L 152,96" fill="none" stroke="black"/> <path d="M 160,112 L 296,112" fill="none" stroke="black"/> <path d="M 24,144 L 152,144" fill="none" stroke="black"/> <path d="M 8,176 L 192,176" fill="none" stroke="black"/> <path d="M 248,208 L 304,208" fill="none" stroke="black"/> <path d="M 320,208 L 368,208" fill="none" stroke="black"/> <path d="M 176,224 L 248,224" fill="none" stroke="black"/> <path d="M 368,224 L 424,224" fill="none" stroke="black"/> <path d="M 248,240 L 304,240" fill="none" stroke="black"/> <path d="M 320,240 L 368,240" fill="none" stroke="black"/> <path d="M 8,272 L 192,272" fill="none" stroke="black"/> <path d="M 24,336 L 152,336" fill="none" stroke="black"/> <path d="M 160,352 L 296,352" fill="none" stroke="black"/> <path d="M 24,384 L 152,384" fill="none" stroke="black"/> <path d="M 8,416 L 192,416" fill="none" stroke="black"/> <path d="M 296,112 C 304.83064,112 312,119.16936 312,128" fill="none" stroke="black"/> <path d="M 296,352 C 304.83064,352 312,344.83064 312,336" fill="none" stroke="black"/> <circle cx="144" cy="112" r="6" class="closeddot" fill="black"/> <circle cx="144" cy="352" r="6" class="closeddot" fill="black"/> <circle cx="152" cy="112" r="6" class="closeddot" fill="black"/> <circle cx="152" cy="352" r="6" class="closeddot" fill="black"/> <circle cx="312" cy="208" r="6" class="closeddot" fill="black"/> <circle cx="312" cy="240" r="6" class="closeddot" fill="black"/> <g class="text"> <text x="60" y="52">Provider</text> <text x="128" y="52">Network</text> <text x="168" y="52">A</text> <text x="56" y="68">BGP</text> <text x="112" y="68">ASN:65536</text> <text x="284" y="68">Attachment-Circuit</text> <text x="368" y="68">1</text> <text x="332" y="84">Bearer=Location-X-Line-114</text> <text x="68" y="116">ASBR-A-1</text> <text x="220" y="132">192.0.2.1/24</text> <text x="216" y="148">vlan-id:114</text> <text x="152" y="228">...</text> <text x="288" y="228">IXP</text> <text x="316" y="228">SW</text> <text x="448" y="228">...</text> <text x="60" y="292">Provider</text> <text x="128" y="292">Network</text> <text x="168" y="292">B</text> <text x="56" y="308">BGP</text> <text x="112" y="308">ASN:65537</text> <text x="232" y="340">.2/24</text> <text x="68" y="356">ASBR-B-1</text> <text x="268" y="372">Attachment-Circuit</text> <text x="352" y="372">2</text> <text x="308" y="388">Bearer=Location-X-Line-448</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ .----------------------. | Provider Network A | | BGP ASN:65536 | Attachment-Circuit 1 | | Bearer=Location-X-Line-114 | .---------------. | | | ASBR-A-1 **------------------. | | | 192.0.2.1/24 | | '---------------' vlan-id:114 | | | | '----------------------' | | .-------*------. ... ---------+ IXP SW +------- ... '-------*------' | .----------------------. | | Provider Network B | | | BGP ASN:65537 | | | | | | +---------------+ | .2/24 | | | ASBR-B-1 **------------------' | | | |Attachment-Circuit 2 | '---------------' | Bearer=Location-X-Line-448 | | '----------------------' ]]></artwork> </artset> </figure> <t>The AC configuration (<xref target="bgp-peer-network-add-attachment-circuit"/>) includes parameters such as VLAN configuration, IP addresses, MTU, and any additional settings required for connectivity. The peering location is inferred from the 'bearer-reference'.</t> <figure anchor="bgp-peer-network-add-attachment-circuit"> <name>Message Body of a Request to Create an AC to Connect to an IXP</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "Attachment Circuit 1", "customer-name": "Network A", "description": "An AC to IXP SW in Location X", "requested-start": "2025-12-12T05:00:00.00Z", "peer-sap-id": [ "asbr-1-interface" ], "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q" }, "bearer-reference": "Location-X-Line-114" } } ] } } ]]></sourcecode> </figure> <t><xref target="bgp-peer-network-response"/> shows the received response to a query with the required information for the activation of the AC.</t> <figure anchor="bgp-peer-network-response"> <name>Message Body of a Response to an AC Request to Connect to an IXP</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "Attachment Circuit 1", "customer-name": "Network A", "description": "An AC to IXP SW in Location X", "role": "ietf-ac-common:public-nni", "actual-start": "2025-12-12T05:00:00.00Z", "peer-sap-id": [ "asbr-1-interface" ], "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "tag-type": "ietf-vpn-common:c-vlan", "cvlan-id": 114 } }, "bearer-reference": "Location-X-Line-114" }, "ip-connection": { "ipv4": { "prefix-length": 24, "address": [ { "address-id": "1", "customer-address": "192.0.2.1" } ] } } } ] } } ]]></sourcecode> </figure> <t>Once the ACs are established, BGP peering sessions can be configured between routers of the participating networks. BGP sessions can be established via a route server or between two networks. For the sake of illustration, let us assume that BGP sessions are established directly between twonetwork.networks. <xref target="bgp-peer-network-add-bgp-attachment-circuit"/> shows an example of a request to add a BGP session to an existing AC. The properties of that AC are not repeated in this request because that information is already communicated during the creation of the AC.</t> <figure anchor="bgp-peer-network-add-bgp-attachment-circuit"> <name>Message Body of a Request to Create a BGP Session over an AC</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "Attachment Circuit 1", "routing-protocols": { "routing-protocol": [ { "id": "BGP", "type": "ietf-vpn-common:bgp-routing", "bgp": { "neighbor": [ { "id": "Session-Network-B", "remote-address": "192.0.2.1", "local-as": 65537, "peer-as": 65536, "address-family": "ietf-vpn-common:ipv4", "authentication": { "enabled": true, "keying-material": { "key-id": 1, "key": "test##" } }, "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } } } ] } } ] } } ] } } ]]></sourcecode> </figure> <t><xref target="bgp-awaiting-validation"/> provides the example of a responsewhichthat indicates that the request is awaiting validation. The responseincludesalso includes a server-assigned reference for this BGP session.</t> <figure anchor="bgp-awaiting-validation"> <name>Message Body of a Response for a BGP Session Awaiting Validation</name> <sourcecode type="json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "Attachment Circuit 1", "role": "ietf-ac-common:public-nni", "routing-protocols": { "routing-protocol": [ { "id": "BGP", "type": "ietf-vpn-common:bgp-routing", "bgp": { "neighbor": [ { "id": "Session-Network-B", "server-reference": "peering-svc-45857", "local-address": "192.0.2.2", "remote-address": "192.0.2.1", "local-as": 65537, "peer-as": 65536, "address-family": "ietf-vpn-common:ipv4", "authentication": { "enabled": true, "keying-material": { "key-id": 1, "key": "test##" } }, "status": { "admin-status": { "status": "ietf-ac-common:awaiting-\ validation" } } } ] } } ] } } ] } } ]]></sourcecode> </figure> <t>Once validation is accomplished, a status update is communicated back to the requestor. The BGP session can then be established over the AC. The BGP session configuration includes parameters such as neighbor IP addresses, ASNs, authentication settings (if required), etc. The configuration is triggered at each side of the BGP connection (i.e., peer ASBRs).</t> <figure anchor="bgp-peering-all-sessions"> <name>Message Body of a Response to Report All Active BGPsessionsSessions over an AC</name> <sourcecode type="json"><![CDATA[ { "ietf-ac-svc:routing-protocols": { "routing-protocol": [ { "id": "BGP", "type": "ietf-vpn-common:bgp-routing", "bgp": { "neighbor": [ { "id": "Session-Network-B", "server-reference": "peering-svc-45857", "local-address": "192.0.2.2", "remote-address": "192.0.2.1", "local-as": 65537, "peer-as": 65536, "address-family": "ietf-vpn-common:ipv4", "authentication": { "enabled": true, "keying-material": { "key-id": 1, "key": "test##" } }, "status": { "admin-status": { "status": "ietf-ac-common:up" } } }, { "id": "Session-Network-C", "server-reference": "peering-svc-7866", "local-address": "192.0.2.3", "remote-address": "192.0.2.1", "local-as": 65538, "peer-as": 65536, "address-family": "ietf-vpn-common:ipv4", "authentication": { "enabled": true, "keying-material": { "key-id": 1, "key": "##test##" } }, "status": { "admin-status": { "status": "ietf-ac-common:up" } } }, { "_comment": "other active BGP sessions over the AC" } ] } } ] } } ]]></sourcecode> </figure> </section> </section> <section anchor="sec-cloudified-nfs"> <name>Connectivity of Cloud Network Functions</name> <section anchor="scope"> <name>Scope</name> <t>This section demonstrates how the AC service model permits managing connectivity requirements for complex Network Functions (NFs)--- containerized or virtualized--- that are typically deployed in Telco networks. This integration leverages the concept of "parent AC" to decouple physical and logical connectivity so that several ACs cansharesshare Layer 2 and Layer 3 resources. This approach provides flexibility, scalability, and API stability.</t> <t>The NFs have the following characteristics:</t> <ul spacing="normal"> <li> <t>The NF is distributed on a set of compute nodes with scaled-out and redundant instances.</t> </li> <li> <t>The NF has two distinct type of instances: user plane ("nf-up") and routing control plane ("nf-cp").</t> </li> <li> <t>The user plane component can be distributed among the first 8 compute nodes ("compute-01" to "compute-08") to achieve high performance.</t> </li> <li> <t>The control plane is deployed in a redundant fashion on two instances running on distinct compute nodes ("compute-09" and "compute-10").</t> </li> <li> <t>The NF is attached to distinct networks, each making use of a dedicated VLAN. These VLANs are therefore instantiated as separate ACs. From a realization standpoint, the NF interface connectivity is generally provided thanks to MacVLAN or Single Root I/O Virtualization (SR-IOV). For the sake ofsimplicitysimplicity, only two VLANs are presented in thisexample,example; additional VLANs are configured following a similar logic.</t> </li> </ul> </section> <section anchor="physical-infrastructure"> <name>Physical Infrastructure</name> <t><xref target="cloud-parent-infra"/> describes the physical infrastructure. The compute nodes (customer) are attached to the provider infrastructure thanks to a set of physical links on which attachment circuits are provisioned (i.e., "compute-XX-nicY"). The provider infrastructure can be realized in multiple ways, such as IPFabric,Fabric and Layer2/Layer 32/3 Edge Routers. This document does not intend to detail these aspects.</t> <figure anchor="cloud-parent-infra"> <name>Example Physical Topology for Cloud Deployment</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="400" width="544" viewBox="0 0 544 400" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,48 L 8,112" fill="none" stroke="black"/> <path d="M 8,160 L 8,224" fill="none" stroke="black"/> <path d="M 8,288 L 8,352" fill="none" stroke="black"/> <path d="M 112,48 L 112,112" fill="none" stroke="black"/> <path d="M 112,160 L 112,224" fill="none" stroke="black"/> <path d="M 112,288 L 112,352" fill="none" stroke="black"/> <path d="M 312,32 L 312,368" fill="none" stroke="black"/> <path d="M 360,48 L 360,80" fill="none" stroke="black"/> <path d="M 360,112 L 360,144" fill="none" stroke="black"/> <path d="M 360,176 L 360,208" fill="none" stroke="black"/> <path d="M 360,240 L 360,272" fill="none" stroke="black"/> <path d="M 432,48 L 432,80" fill="none" stroke="black"/> <path d="M 432,112 L 432,144" fill="none" stroke="black"/> <path d="M 432,176 L 432,208" fill="none" stroke="black"/> <path d="M 432,240 L 432,272" fill="none" stroke="black"/> <path d="M 448,112 L 448,144" fill="none" stroke="black"/> <path d="M 448,176 L 448,208" fill="none" stroke="black"/> <path d="M 520,112 L 520,144" fill="none" stroke="black"/> <path d="M 520,176 L 520,208" fill="none" stroke="black"/> <path d="M 536,32 L 536,368" fill="none" stroke="black"/> <path d="M 312,32 L 536,32" fill="none" stroke="black"/> <path d="M 8,48 L 112,48" fill="none" stroke="black"/> <path d="M 360,48 L 432,48" fill="none" stroke="black"/> <path d="M 120,80 L 304,80" fill="none" stroke="black"/> <path d="M 360,80 L 432,80" fill="none" stroke="black"/> <path d="M 8,112 L 112,112" fill="none" stroke="black"/> <path d="M 360,112 L 432,112" fill="none" stroke="black"/> <path d="M 448,112 L 520,112" fill="none" stroke="black"/> <path d="M 360,144 L 432,144" fill="none" stroke="black"/> <path d="M 448,144 L 520,144" fill="none" stroke="black"/> <path d="M 8,160 L 112,160" fill="none" stroke="black"/> <path d="M 360,176 L 432,176" fill="none" stroke="black"/> <path d="M 448,176 L 520,176" fill="none" stroke="black"/> <path d="M 120,192 L 304,192" fill="none" stroke="black"/> <path d="M 360,208 L 432,208" fill="none" stroke="black"/> <path d="M 448,208 L 520,208" fill="none" stroke="black"/> <path d="M 8,224 L 112,224" fill="none" stroke="black"/> <path d="M 360,240 L 432,240" fill="none" stroke="black"/> <path d="M 360,272 L 432,272" fill="none" stroke="black"/> <path d="M 8,288 L 112,288" fill="none" stroke="black"/> <path d="M 120,320 L 304,320" fill="none" stroke="black"/> <path d="M 8,352 L 112,352" fill="none" stroke="black"/> <path d="M 312,368 L 536,368" fill="none" stroke="black"/> <g class="text"> <text x="196" y="52">bearer</text> <text x="232" y="52">=</text> <text x="208" y="68">compute-01-nic1</text> <text x="60" y="84">compute-01</text> <text x="196" y="164">bearer</text> <text x="232" y="164">=</text> <text x="208" y="180">compute-02-nic2</text> <text x="60" y="196">compute-02</text> <text x="208" y="260">[...]</text> <text x="196" y="292">bearer</text> <text x="232" y="292">=</text> <text x="208" y="308">compute-10-nic0</text> <text x="60" y="324">compute-10</text> <text x="388" y="324">Provider</text> <text x="456" y="324">Network</text> <text x="428" y="340">Infrastructure</text> <text x="328" y="356">(IP</text> <text x="376" y="356">Fabric,</text> <text x="448" y="356">Gateways,</text> <text x="512" y="356">etc.)</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ .---------------------------. .------------. bearer = | .--------. | | | compute-01-nic1 | | | | | compute-01 |------------------------| '--------' | | | | | '------------' | .--------. .--------. | | | | | | | | '--------' '--------' | .------------. bearer = | | | | compute-02-nic2 | .--------. .--------. | | compute-02 |------------------------| | | | | | | | | '--------' '--------' | '------------' | | | .--------. | [...] | | | | | '--------' | .------------. bearer = | | | | compute-10-nic0 | | | compute-10 |------------------------| Provider Network | | | | Infrastructure | '------------' |(IP Fabric, Gateways, etc.)| '---------------------------' ]]></artwork> </artset> </figure> </section> <section anchor="nfs-deployment"> <name>NFs Deployment</name> <t>The NFs are deployed on this infrastructure in the following way:</t> <ul spacing="normal"> <li> <t>Configuration of a parent AC as a centralized attachment for "vlan 100". The parent AC captures Layer 2 and Layer 3 properties for this VLAN: vlan-id, IP default gateway and subnet, IP address pool for NFs endpoints, static routes with BFD to user plane, and BGP configuration to control plane NFs. In addition, the IP addresses of the user plane ("nf-up") instances are protected using BFD.</t> </li> <li> <t>Configuration of a parent AC as a centralized attachment for "vlan 200". ThisvlanVLAN is for Layer 2 connectivity between NFs (no IP configuration in the provider network).</t> </li> <li> <t>"Child ACs" binding bearers to parent ACs for "vlan 100" and "vlan 200".</t> </li> <li> <t>The deployment of the network service to all compute nodes ("compute-01" to "compute-10"), even though the NF is not instantiated on "compute-07"/"compute-08". This approach permits handling compute failures and scale-out scenarios in a reactive and flexible fashion thanks to a pre-provisioned networking logic.</t> </li> </ul> <figure anchor="cloud-parent-logical"> <name>Logical Topology of the NFs Deployment</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="1072" width="544" viewBox="0 0 544 1072" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,256 L 8,320" fill="none" stroke="black"/> <path d="M 8,352 L 8,416" fill="none" stroke="black"/> <path d="M 8,464 L 8,528" fill="none" stroke="black"/> <path d="M 8,560 L 8,592" fill="none" stroke="black"/> <path d="M 8,624 L 8,656" fill="none" stroke="black"/> <path d="M 8,688 L 8,752" fill="none" stroke="black"/> <path d="M 8,784 L 8,848" fill="none" stroke="black"/> <path d="M 16,896 L 16,1040" fill="none" stroke="black"/> <path d="M 24,288 L 24,304" fill="none" stroke="black"/> <path d="M 24,384 L 24,400" fill="none" stroke="black"/> <path d="M 24,496 L 24,512" fill="none" stroke="black"/> <path d="M 24,720 L 24,736" fill="none" stroke="black"/> <path d="M 24,816 L 24,832" fill="none" stroke="black"/> <path d="M 80,288 L 80,304" fill="none" stroke="black"/> <path d="M 80,384 L 80,400" fill="none" stroke="black"/> <path d="M 80,496 L 80,512" fill="none" stroke="black"/> <path d="M 80,720 L 80,736" fill="none" stroke="black"/> <path d="M 80,816 L 80,832" fill="none" stroke="black"/> <path d="M 96,256 L 96,320" fill="none" stroke="black"/> <path d="M 96,352 L 96,416" fill="none" stroke="black"/> <path d="M 96,464 L 96,528" fill="none" stroke="black"/> <path d="M 96,560 L 96,592" fill="none" stroke="black"/> <path d="M 96,624 L 96,656" fill="none" stroke="black"/> <path d="M 96,688 L 96,752" fill="none" stroke="black"/> <path d="M 96,784 L 96,848" fill="none" stroke="black"/> <path d="M 208,48 L 208,176" fill="none" stroke="black"/> <path d="M 304,896 L 304,1040" fill="none" stroke="black"/> <path d="M 344,224 L 344,848" fill="none" stroke="black"/> <path d="M 368,304 L 368,384" fill="none" stroke="black"/> <path d="M 368,416 L 368,496" fill="none" stroke="black"/> <path d="M 384,200 L 384,240" fill="none" stroke="black"/> <path d="M 448,240 L 448,296" fill="none" stroke="black"/> <path d="M 520,304 L 520,384" fill="none" stroke="black"/> <path d="M 520,416 L 520,496" fill="none" stroke="black"/> <path d="M 528,48 L 528,176" fill="none" stroke="black"/> <path d="M 536,224 L 536,848" fill="none" stroke="black"/> <path d="M 224,32 L 512,32" fill="none" stroke="black"/> <path d="M 224,192 L 512,192" fill="none" stroke="black"/> <path d="M 344,224 L 376,224" fill="none" stroke="black"/> <path d="M 392,224 L 536,224" fill="none" stroke="black"/> <path d="M 384,240 L 448,240" fill="none" stroke="black"/> <path d="M 8,256 L 96,256" fill="none" stroke="black"/> <path d="M 40,272 L 64,272" fill="none" stroke="black"/> <path d="M 104,288 L 168,288" fill="none" stroke="black"/> <path d="M 240,288 L 336,288" fill="none" stroke="black"/> <path d="M 104,304 L 168,304" fill="none" stroke="black"/> <path d="M 240,304 L 336,304" fill="none" stroke="black"/> <path d="M 368,304 L 520,304" fill="none" stroke="black"/> <path d="M 40,320 L 64,320" fill="none" stroke="black"/> <path d="M 8,352 L 96,352" fill="none" stroke="black"/> <path d="M 40,368 L 64,368" fill="none" stroke="black"/> <path d="M 104,384 L 168,384" fill="none" stroke="black"/> <path d="M 240,384 L 336,384" fill="none" stroke="black"/> <path d="M 368,384 L 520,384" fill="none" stroke="black"/> <path d="M 104,400 L 168,400" fill="none" stroke="black"/> <path d="M 240,400 L 336,400" fill="none" stroke="black"/> <path d="M 40,416 L 64,416" fill="none" stroke="black"/> <path d="M 368,416 L 520,416" fill="none" stroke="black"/> <path d="M 8,464 L 96,464" fill="none" stroke="black"/> <path d="M 40,480 L 64,480" fill="none" stroke="black"/> <path d="M 104,496 L 168,496" fill="none" stroke="black"/> <path d="M 240,496 L 336,496" fill="none" stroke="black"/> <path d="M 368,496 L 520,496" fill="none" stroke="black"/> <path d="M 104,512 L 168,512" fill="none" stroke="black"/> <path d="M 240,512 L 336,512" fill="none" stroke="black"/> <path d="M 40,528 L 64,528" fill="none" stroke="black"/> <path d="M 8,560 L 96,560" fill="none" stroke="black"/> <path d="M 104,576 L 168,576" fill="none" stroke="black"/> <path d="M 240,576 L 336,576" fill="none" stroke="black"/> <path d="M 104,592 L 168,592" fill="none" stroke="black"/> <path d="M 240,592 L 336,592" fill="none" stroke="black"/> <path d="M 8,624 L 96,624" fill="none" stroke="black"/> <path d="M 104,640 L 168,640" fill="none" stroke="black"/> <path d="M 240,640 L 336,640" fill="none" stroke="black"/> <path d="M 104,656 L 168,656" fill="none" stroke="black"/> <path d="M 240,656 L 336,656" fill="none" stroke="black"/> <path d="M 8,688 L 96,688" fill="none" stroke="black"/> <path d="M 112,688 L 192,688" fill="none" stroke="black"/> <path d="M 224,688 L 336,688" fill="none" stroke="black"/> <path d="M 40,704 L 64,704" fill="none" stroke="black"/> <path d="M 104,720 L 168,720" fill="none" stroke="black"/> <path d="M 240,720 L 336,720" fill="none" stroke="black"/> <path d="M 104,736 L 168,736" fill="none" stroke="black"/> <path d="M 240,736 L 336,736" fill="none" stroke="black"/> <path d="M 40,752 L 64,752" fill="none" stroke="black"/> <path d="M 8,784 L 96,784" fill="none" stroke="black"/> <path d="M 112,784 L 200,784" fill="none" stroke="black"/> <path d="M 232,784 L 336,784" fill="none" stroke="black"/> <path d="M 40,800 L 64,800" fill="none" stroke="black"/> <path d="M 104,816 L 168,816" fill="none" stroke="black"/> <path d="M 240,816 L 336,816" fill="none" stroke="black"/> <path d="M 104,832 L 168,832" fill="none" stroke="black"/> <path d="M 240,832 L 336,832" fill="none" stroke="black"/> <path d="M 40,848 L 64,848" fill="none" stroke="black"/> <path d="M 344,848 L 536,848" fill="none" stroke="black"/> <path d="M 32,880 L 288,880" fill="none" stroke="black"/> <path d="M 320,960 L 352,960" fill="none" stroke="black"/> <path d="M 32,1056 L 288,1056" 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 512,32 C 520.83064,32 528,39.16936 528,48" fill="none" stroke="black"/> <path d="M 224,192 C 215.16936,192 208,184.83064 208,176" fill="none" stroke="black"/> <path d="M 512,192 C 520.83064,192 528,184.83064 528,176" fill="none" stroke="black"/> <path d="M 40,272 C 31.16936,272 24,279.16936 24,288" fill="none" stroke="black"/> <path d="M 64,272 C 72.83064,272 80,279.16936 80,288" fill="none" stroke="black"/> <path d="M 40,320 C 31.16936,320 24,312.83064 24,304" fill="none" stroke="black"/> <path d="M 64,320 C 72.83064,320 80,312.83064 80,304" fill="none" stroke="black"/> <path d="M 40,368 C 31.16936,368 24,375.16936 24,384" fill="none" stroke="black"/> <path d="M 64,368 C 72.83064,368 80,375.16936 80,384" fill="none" stroke="black"/> <path d="M 40,416 C 31.16936,416 24,408.83064 24,400" fill="none" stroke="black"/> <path d="M 64,416 C 72.83064,416 80,408.83064 80,400" fill="none" stroke="black"/> <path d="M 40,480 C 31.16936,480 24,487.16936 24,496" fill="none" stroke="black"/> <path d="M 64,480 C 72.83064,480 80,487.16936 80,496" fill="none" stroke="black"/> <path d="M 40,528 C 31.16936,528 24,520.83064 24,512" fill="none" stroke="black"/> <path d="M 64,528 C 72.83064,528 80,520.83064 80,512" fill="none" stroke="black"/> <path d="M 40,704 C 31.16936,704 24,711.16936 24,720" fill="none" stroke="black"/> <path d="M 64,704 C 72.83064,704 80,711.16936 80,720" fill="none" stroke="black"/> <path d="M 40,752 C 31.16936,752 24,744.83064 24,736" fill="none" stroke="black"/> <path d="M 64,752 C 72.83064,752 80,744.83064 80,736" fill="none" stroke="black"/> <path d="M 40,800 C 31.16936,800 24,807.16936 24,816" fill="none" stroke="black"/> <path d="M 64,800 C 72.83064,800 80,807.16936 80,816" fill="none" stroke="black"/> <path d="M 40,848 C 31.16936,848 24,840.83064 24,832" fill="none" stroke="black"/> <path d="M 64,848 C 72.83064,848 80,840.83064 80,832" fill="none" stroke="black"/> <path d="M 32,880 C 23.16936,880 16,887.16936 16,896" fill="none" stroke="black"/> <path d="M 288,880 C 296.83064,880 304,887.16936 304,896" fill="none" stroke="black"/> <path d="M 32,1056 C 23.16936,1056 16,1048.83064 16,1040" fill="none" stroke="black"/> <path d="M 288,1056 C 296.83064,1056 304,1048.83064 304,1040" fill="none" stroke="black"/> <polygon class="arrowhead" points="456,296 444,290.4 444,301.6" fill="black" transform="rotate(90,448,296)"/> <polygon class="arrowhead" points="360,960 348,954.4 348,965.6" fill="black" transform="rotate(0,352,960)"/> <polygon class="arrowhead" points="344,784 332,778.4 332,789.6" fill="black" transform="rotate(0,336,784)"/> <polygon class="arrowhead" points="344,688 332,682.4 332,693.6" fill="black" transform="rotate(0,336,688)"/> <polygon class="arrowhead" points="120,784 108,778.4 108,789.6" fill="black" transform="rotate(180,112,784)"/> <polygon class="arrowhead" points="120,688 108,682.4 108,693.6" fill="black" transform="rotate(180,112,688)"/> <g class="text"> <text x="228" y="52">VLAN</text> <text x="268" y="52">100:</text> <text x="236" y="84">Static</text> <text x="288" y="84">route</text> <text x="324" y="84">to</text> <text x="368" y="84">virtual</text> <text x="416" y="84">BGP</text> <text x="444" y="84">NH</text> <text x="468" y="84">in</text> <text x="500" y="84">user</text> <text x="232" y="100">plane</text> <text x="296" y="100">instances</text> <text x="348" y="100">NF</text> <text x="380" y="100">with</text> <text x="416" y="100">BFD</text> <text x="480" y="100">protection:</text> <text x="216" y="132">-</text> <text x="296" y="132">198.51.100.100/32</text> <text x="384" y="132">via</text> <text x="440" y="132">192.0.2.1</text> <text x="216" y="148">-</text> <text x="296" y="148">198.51.100.100/32</text> <text x="384" y="148">via</text> <text x="440" y="148">192.0.2.2</text> <text x="224" y="164">...</text> <text x="216" y="180">-</text> <text x="296" y="180">198.51.100.100/32</text> <text x="384" y="180">via</text> <text x="440" y="180">192.0.2.8</text> <text x="132" y="228">VLAN</text> <text x="168" y="228">100</text> <text x="196" y="228">IP</text> <text x="236" y="228">subnet</text> <text x="196" y="244">192.0.2.0/24</text> <text x="108" y="276">.1</text> <text x="164" y="276"><-</text> <text x="192" y="276">BFD</text> <text x="220" y="276">-></text> <text x="52" y="292">nf-up1</text> <text x="204" y="292">vlan-100</text> <text x="204" y="308">vlan-200</text> <text x="404" y="324">Bridge</text> <text x="452" y="324">VLAN</text> <text x="488" y="324">100</text> <text x="52" y="340">compute-01</text> <text x="440" y="340">(L2/L3)</text> <text x="404" y="356">IP</text> <text x="452" y="356">gateway:</text> <text x="108" y="372">.2</text> <text x="164" y="372"><-</text> <text x="192" y="372">BFD</text> <text x="220" y="372">-></text> <text x="444" y="372">192.0.2.254/24</text> <text x="52" y="388">nf-up2</text> <text x="204" y="388">vlan-100</text> <text x="204" y="404">vlan-200</text> <text x="52" y="436">compute-02</text> <text x="192" y="452">[...]</text> <text x="404" y="452">Bridge</text> <text x="452" y="452">VLAN</text> <text x="488" y="452">200</text> <text x="416" y="468">(L2</text> <text x="456" y="468">only)</text> <text x="108" y="484">.6</text> <text x="164" y="484"><-</text> <text x="192" y="484">BFD</text> <text x="220" y="484">-></text> <text x="52" y="500">nf-up6</text> <text x="204" y="500">vlan-100</text> <text x="204" y="516">vlan-200</text> <text x="52" y="548">compute-06</text> <text x="204" y="580">vlan-100</text> <text x="204" y="596">vlan-200</text> <text x="52" y="612">compute-07</text> <text x="204" y="644">vlan-100</text> <text x="204" y="660">vlan-200</text> <text x="52" y="676">compute-08</text> <text x="208" y="692">BGP</text> <text x="108" y="708">.9</text> <text x="308" y="708">.252</text> <text x="52" y="724">nf-cp1</text> <text x="204" y="724">vlan-100</text> <text x="204" y="740">vlan-200</text> <text x="52" y="772">compute-09</text> <text x="216" y="788">BGP</text> <text x="112" y="804">.10</text> <text x="316" y="804">.253</text> <text x="52" y="820">nf-cp2</text> <text x="204" y="820">vlan-100</text> <text x="204" y="836">vlan-200</text> <text x="52" y="868">compute-10</text> <text x="40" y="900">nf-cp</text> <text x="96" y="900">routing</text> <text x="144" y="900">for</text> <text x="180" y="900">VLAN</text> <text x="216" y="900">100</text> <text x="60"y="916">advertizes</text>y="916">advertises</text> <text x="128" y="916">pools</text> <text x="172" y="916">with</text> <text x="208" y="916">1:N</text> <text x="252" y="916">backup</text> <text x="44" y="932">route.</text> <text x="32" y="948">BGP</text> <text x="80" y="948">UPDATE:</text> <text x="80" y="964">203.0.113.0/24,</text> <text x="156" y="964">NH</text> <text x="176" y="964">=</text> <text x="244" y="964">198.51.100.100</text> <text x="80" y="980">203.0.113.0/28,</text> <text x="156" y="980">NH</text> <text x="176" y="980">=</text> <text x="224" y="980">192.0.2.1</text> <text x="84" y="996">203.0.113.16/28,</text> <text x="164" y="996">NH</text> <text x="184" y="996">=</text> <text x="232" y="996">192.0.2.2</text> <text x="32" y="1012">...</text> <text x="84" y="1028">203.0.113.80/28,</text> <text x="164" y="1028">NH</text> <text x="184" y="1028">=</text> <text x="232" y="1028">192.0.2.6</text> <text x="84" y="1044">203.0.113.96/28,</text> <text x="164" y="1044">NH</text> <text x="184" y="1044">=</text> <text x="232" y="1044">192.0.2.7</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ .-------------------------------------. |VLAN 100: | | | |Static route to virtual BGP NH in user | |plane instances NF with BFD protection:| | | |- 198.51.100.100/32 via 192.0.2.1 | |- 198.51.100.100/32 via 192.0.2.2 | |... | |- 198.51.100.100/32 via 192.0.2.8 | '-------------------------------------' | VLAN 100 IP subnet .----|------------------. 192.0.2.0/24 | +-------+ | .----------. | | | | .----. |.1 <- BFD -> | | | | |nf-up1| |---------vlan-100-------------| v | | | | |---------vlan-200-------------| .------------------. | | '----' | | | Bridge VLAN 100 | | compute-01 | | (L2/L3) | | .----------. | | IP gateway: | | | .----. |.2 <- BFD -> | | 192.0.2.254/24 | | | |nf-up2| |---------vlan-100-------------| '------------------' | | | | |---------vlan-200-------------| | | '----' | | .------------------. | compute-02 | | | | [...] | | Bridge VLAN 200 | | .----------. | | (L2 only) | | | .----. |.6 <- BFD -> | | | | | |nf-up6| |---------vlan-100-------------| '------------------' | | | | |---------vlan-200-------------| | | '----' | | | compute-06 | | .----------. | | | |---------vlan-100-------------| | | |---------vlan-200-------------| | compute-07 | | .----------. | | | |---------vlan-100-------------| | | |---------vlan-200-------------| | compute-08 | | .----------. <----------BGP-------------->| | | .----. |.9 .252 | | | |nf-cp1| |---------vlan-100-------------| | | | | |---------vlan-200-------------| | | '----' | | | compute-09 | | .----------. <-----------BGP------------->| | | .----. |.10 .253 | | | |nf-cp2| |---------vlan-100-------------| | | | | |---------vlan-200-------------| | | '----' | '-----------------------' compute-10 .---------------------------------. |nf-cp routing for VLAN 100 ||advertizes|advertises pools with 1:N backup | |route. | |BGP UPDATE: | |203.0.113.0/24, NH = 198.51.100.100| ----> |203.0.113.0/28, NH = 192.0.2.1 | |203.0.113.16/28, NH = 192.0.2.2 | |... | |203.0.113.80/28, NH = 192.0.2.6 | |203.0.113.96/28, NH = 192.0.2.7 | '---------------------------------' ]]></artwork> </artset> </figure> <t>Forreadabilityreadability, the payload is displayed as a single JSON file (<xref target="parent-profile"/>). In practice, several API calls may take place to initialize these resources (e.g., GET requests from the customer to retrieve the IP address pools for NFs on "vlan 100" thanks to parent configuration and BGPconfiguration,configuration and POST extra routes for user planes and BFD).</t> <t>Note that no individual IP addresses are assigned for the NF user plane instances (i.e., no 'customer-address' in the Child AC). The assignment of IP addresses to the NF endpoints is managed by the Cloud InfrastructureIPAMIP Address Management (IPAM) based on the 'customer-address' IP address pool "192.0.2.1-200". Like in any conventional LAN-facing scenario, it is assumed that the actual binding of IP endpoints to logical attachments (here Child ACs) relies on a dedicated protocol logic (typically, Address Resolution Protocol (ARP) <xref target="RFC0826"/> or Neighbor Discovery <xref target="RFC4861"/>) and is not captured in the data model. Hence, the IP addresses displayed for NF user plane instances are simply examples to illustrate a realization approach. Note also that theControl Planecontrol plane is defined with static IP address assignments on a given AC/bearer to illustrate another deployment alternative.</t> <figure anchor="parent-profile"> <name>Message Body for the Configuration of the NF ACs</name> <sourcecode type="json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-ac-svc:specific-provisioning-profiles": { "valid-provider-identifiers": { "failure-detection-profile-identifier": [ { "id": "single-hop-bfd-user-plane" } ] } }, "ietf-ac-svc:attachment-circuits": { "ac": [ { "name": "parent-vlan-100", "description": "This parent represents a bridge with L3 \ interface (IRB) to connect NF in vlan 100", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 100 } } }, "ip-connection": { "ipv4": { "virtual-address": "192.0.2.254", "prefix-length": 24, "customer-addresses": { "address-pool": [ { "pool-id": "pool-1", "start-address": "192.0.2.1", "end-address": "192.0.2.200" } ] } } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "ietf-vpn-common:static-routing", "static": { "cascaded-lan-prefixes": { "ipv4-lan-prefix": [ { "lan": "198.51.100.100/32", "next-hop": "192.0.2.1", "lan-tag": "virtual-next-hop", "failure-detection-profile": "single-hop-bfd-\ user-plane" }, { "lan": "198.51.100.100/32", "next-hop": "192.0.2.2", "lan-tag": "virtual-next-hop", "failure-detection-profile": "single-hop-bfd-\ user-plane" }, { "_comment": "192.0.2.3-192.0.2.7 are not \ displayed" }, { "lan": "198.51.100.100/32", "next-hop": "192.0.2.8", "lan-tag": "virtual-next-hop", "failure-detection-profile": "single-hop-bfd-\ user-plane" } ] } } }, { "id": "2", "type": "ietf-vpn-common:bgp-routing", "bgp": { "peer-groups": { "peer-group": [ { "name": "peer-nf-cp-vlan-100-gw1", "local-as": 65536, "peer-as": 65537, "local-address": "192.0.2.252" }, { "name": "peer-nf-cp-vlan-100-gw2", "local-as": 65536, "peer-as": 65537, "local-address": "192.0.2.253" } ] }, "neighbor": [ { "id": "gw1-cp1", "remote-address": "192.0.2.101", "peer-group": "peer-nf-cp-vlan-100-gw1" }, { "id": "gw1-cp2", "remote-address": "192.0.2.102", "peer-group": "peer-nf-cp-vlan-100-gw1" }, { "id": "gw2-cp1", "remote-address": "192.0.2.101", "peer-group": "peer-nf-cp-vlan-100-gw2" }, { "id": "gw2-cp2", "remote-address": "192.0.2.102", "peer-group": "peer-nf-cp-vlan-100-gw2" } ] } } ] }, "oam": { "bfd": { "session": [ { "id": "bfd-gw1-nf-up1", "local-address": "192.0.2.252", "remote-address": "192.0.2.1", "profile": "single-hop-bfd-user-plane" }, { "id": "bfd-gw2-nf-up1", "local-address": "192.0.2.253", "remote-address": "192.0.2.1", "profile": "single-hop-bfd-user-plane" }, { "id": "bfd-gw1-nf-up2", "local-address": "192.0.2.252", "remote-address": "192.0.2.2", "profile": "single-hop-bfd-user-plane" }, { "id": "bfd-gw2-nf-up2", "local-address": "192.0.2.253", "remote-address": "192.0.2.2", "profile": "single-hop-bfd-user-plane" }, { "_comment": "192.0.2.3-192.0.2.7 sessions are not \ displayed" }, { "id": "bfd-gw1-nf-up8", "local-address": "192.0.2.252", "remote-address": "192.0.2.8", "profile": "single-hop-bfd-user-plane" }, { "id": "bfd-gw2-nf-up8", "local-address": "192.0.2.253", "remote-address": "192.0.2.8", "profile": "single-hop-bfd-user-plane" } ] } } }, { "name": "parent-vlan-200", "description": "This parent represents a bridge that \ connects a NF in vlan 200", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 200 } } } }, { "name": "ac-nf-up-01-vlan-100", "description": "attachment to NF-up instance 1 in vlan 100", "parent-ref": ["parent-vlan-100"], "l2-connection": { "bearer-reference": "compute-01-nic1" } }, { "name": "ac-nf-up-02-vlan-100", "description": "attachment to NF-up instance 2 in vlan 100", "parent-ref": ["parent-vlan-100"], "l2-connection": { "bearer-reference": "compute-02-nic2" } }, { "_comment": "ac-nf-up-03-vlan-100 to ac-nf-up-07-vlan-100 \ are hidden" }, { "name": "ac-nf-up-08-vlan-100", "description": "attachment to NF-up instance 10 in vlan 100", "parent-ref": ["parent-vlan-100"], "l2-connection": { "bearer-reference": "compute-08-nic1" } }, { "name": "ac-nf-cp-01-vlan-100", "description": "attachment to NF-CP instance 1 in vlan 100", "parent-ref": ["parent-vlan-100"], "l2-connection": { "bearer-reference": "compute-09-nic0" }, "ip-connection": { "ipv4": { "prefix-length": 24, "address": [ { "address-id": "1", "customer-address": "192.0.2.101" } ] } } }, { "name": "ac-nf-cp-02-vlan-100", "description": "attachment to NF-CP instance 2 in vlan 100", "parent-ref": ["parent-vlan-100"], "l2-connection": { "bearer-reference": "compute-10-nic0" }, "ip-connection": { "ipv4": { "prefix-length": 24, "address": [ { "address-id": "1", "customer-address": "192.0.2.102" } ] } } }, { "name": "ac-nf-up-1-vlan-200", "description": "attachment to NF-up instance 1 in vlan 200", "parent-ref": ["parent-vlan-200"], "l2-connection": { "bearer-reference": "compute-01-nic1" } }, { "_comment": "ac-nf-up-2-vlan-200 to ac-nf-cp-01-vlan-200 \ are not displayed" }, { "name": "ac-nf-cp-2-vlan-200", "description": "attachment to NF-CP instance 2 in vlan 200", "parent-ref": ["parent-vlan-200"], "l2-connection": { "bearer-reference": "compute-10-nic0" } } ] } } ]]></sourcecode> </figure> </section> <section anchor="nf-failure-and-scale-out"> <name>NF Failure and Scale-Out</name> <t>Assuming a failure of "compute-01", the instance "nf-up-1" can be redeployed to "compute-07" by theNF/Cloud Orchestration.NF / cloud orchestration. The NFs can be scaled-out thanks to the creation of an extra instance "nf-up7" on "compute-08". Since connectivity is pre-provisioned, these operations happen without any API calls. In other words, this redeployment is transparent from the perspective of the configuration of the provider network.</t> <figure anchor="cloud-parent-nf-lcm"> <name>Example of Compute Failure andScale-out</name>Scale-Out</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="432" width="544" viewBox="0 0 544 432" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,64 L 8,128" fill="none" stroke="black"/> <path d="M 8,240 L 8,304" fill="none" stroke="black"/> <path d="M 8,336 L 8,400" fill="none" stroke="black"/> <path d="M 24,272 L 24,288" fill="none" stroke="black"/> <path d="M 24,368 L 24,384" fill="none" stroke="black"/> <path d="M 56,160 L 56,232" fill="none" stroke="black"/> <path d="M 80,272 L 80,288" fill="none" stroke="black"/> <path d="M 80,368 L 80,384" fill="none" stroke="black"/> <path d="M 96,64 L 96,128" fill="none" stroke="black"/> <path d="M 96,240 L 96,304" fill="none" stroke="black"/> <path d="M 96,336 L 96,400" fill="none" stroke="black"/> <path d="M 344,32 L 344,416" fill="none" stroke="black"/> <path d="M 368,64 L 368,128" fill="none" stroke="black"/> <path d="M 368,160 L 368,224" fill="none" stroke="black"/> <path d="M 520,64 L 520,128" fill="none" stroke="black"/> <path d="M 520,160 L 520,224" fill="none" stroke="black"/> <path d="M 536,32 L 536,416" fill="none" stroke="black"/> <path d="M 344,32 L 536,32" fill="none" stroke="black"/> <path d="M 8,64 L 96,64" fill="none" stroke="black"/> <path d="M 368,64 L 520,64" fill="none" stroke="black"/> <path d="M 104,96 L 160,96" fill="none" stroke="black"/> <path d="M 232,96 L 336,96" fill="none" stroke="black"/> <path d="M 104,112 L 160,112" fill="none" stroke="black"/> <path d="M 232,112 L 336,112" fill="none" stroke="black"/> <path d="M 368,128 L 520,128" fill="none" stroke="black"/> <path d="M 368,160 L 520,160" fill="none" stroke="black"/> <path d="M 368,224 L 520,224" fill="none" stroke="black"/> <path d="M 8,240 L 96,240" fill="none" stroke="black"/> <path d="M 40,256 L 64,256" fill="none" stroke="black"/> <path d="M 104,272 L 168,272" fill="none" stroke="black"/> <path d="M 240,272 L 336,272" fill="none" stroke="black"/> <path d="M 104,288 L 168,288" fill="none" stroke="black"/> <path d="M 240,288 L 336,288" fill="none" stroke="black"/> <path d="M 40,304 L 64,304" fill="none" stroke="black"/> <path d="M 8,336 L 96,336" fill="none" stroke="black"/> <path d="M 40,352 L 64,352" fill="none" stroke="black"/> <path d="M 104,368 L 168,368" fill="none" stroke="black"/> <path d="M 240,368 L 336,368" fill="none" stroke="black"/> <path d="M 104,384 L 168,384" fill="none" stroke="black"/> <path d="M 240,384 L 336,384" fill="none" stroke="black"/> <path d="M 40,400 L 64,400" fill="none" stroke="black"/> <path d="M 344,416 L 536,416" fill="none" stroke="black"/> <path d="M 40,256 C 31.16936,256 24,263.16936 24,272" fill="none" stroke="black"/> <path d="M 64,256 C 72.83064,256 80,263.16936 80,272" fill="none" stroke="black"/> <path d="M 40,304 C 31.16936,304 24,296.83064 24,288" fill="none" stroke="black"/> <path d="M 64,304 C 72.83064,304 80,296.83064 80,288" fill="none" stroke="black"/> <path d="M 40,352 C 31.16936,352 24,359.16936 24,368" fill="none" stroke="black"/> <path d="M 64,352 C 72.83064,352 80,359.16936 80,368" fill="none" stroke="black"/> <path d="M 40,400 C 31.16936,400 24,392.83064 24,384" fill="none" stroke="black"/> <path d="M 64,400 C 72.83064,400 80,392.83064 80,384" fill="none" stroke="black"/> <polygon class="arrowhead" points="64,232 52,226.4 52,237.6" fill="black" transform="rotate(90,56,232)"/> <g class="text"> <text x="48" y="100">status=</text> <text x="196" y="100">vlan-100</text> <text x="404" y="100">Bridge</text> <text x="452" y="100">VLAN</text> <text x="488" y="100">100</text> <text x="44" y="116">DOWN</text> <text x="196" y="116">vlan-200</text> <text x="52" y="148">compute-01</text> <text x="192" y="180">[...]</text> <text x="404" y="196">Bridge</text> <text x="452" y="196">VLAN</text> <text x="488" y="196">200</text> <text x="108" y="260">.1</text> <text x="160" y="260"><</text> <text x="176" y="260">-</text> <text x="200" y="260">BFD</text> <text x="224" y="260">-</text> <text x="240" y="260">></text> <text x="52" y="276">nf-up1</text> <text x="204" y="276">vlan-100</text> <text x="388" y="276">nf-up1</text> <text x="440" y="276">moved</text> <text x="476" y="276">to</text> <text x="204" y="292">vlan-200</text> <text x="428" y="292">compute-07</text> <text x="52" y="324">compute-07</text> <text x="412" y="340">nf-up7</text> <text x="452" y="340">on</text> <text x="108" y="356">.7</text> <text x="160" y="356"><</text> <text x="176" y="356">-</text> <text x="200" y="356">BFD</text> <text x="224" y="356">-</text> <text x="240" y="356">></text> <text x="420" y="356">compute-08</text> <text x="52" y="372">nf-up7</text> <text x="204" y="372">vlan-100</text> <text x="408" y="372">created</text> <text x="456" y="372">for</text> <text x="204" y="388">vlan-200</text> <text x="424" y="388">scale-out</text> <text x="52" y="420">compute-08</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ .-----------------------. | | .----------. | .------------------. | | | | | | | | status= |--------vlan-100--------------| | Bridge VLAN 100 | | | DOWN |--------vlan-200--------------| | | | | | | '------------------' | compute-01 | | | | .------------------. | | [...] | | | | | | | Bridge VLAN 200 | | | | | | | v | '------------------' | .----------. | | | .----. |.1 < - BFD - > | | | |nf-up1| |---------vlan-100-------------| nf-up1 moved to | | | | |---------vlan-200-------------| compute-07 | | '----' | | | compute-07 | | .----------. | nf-up7 on | | .----. |.7 < - BFD - > | compute-08 | | |nf-up7| |---------vlan-100-------------| created for | | | | |---------vlan-200-------------| scale-out | | '----' | | | compute-08 '-----------------------' ]]></artwork> </artset> </figure> <t>Finally, the addition or deletion of compute nodes in the deployment ("compute-11", "compute-12", etc.) involves merely changes on Child ACs and possible routing on the parent AC. <!--[rfced] To clarify the citation of I-D.ietf-opsawg-ac-lxsm-lxnm-glue (RFC-to-be 9836), we have added "AC Glue" preceding it. Please review and let us know if further updates are needed. Original: In any case, the parent AC is a stable identifier, which can be consumed as a reference by end-to-end service models for VPN configuration such as [I-D.ietf-opsawg-ac-lxsm-lxnm-glue], Slice Service [I-D.ietf-teas-ietf-network-slice-nbi-yang], etc. Current: In any case, the parent AC is a stable identifier, which can be consumed as a reference by end-to-end service models for VPN configuration such as AC Glue [RFC9836], Slice Service [NSSM], etc. --> In any case, the parent AC is a stable identifier, which can be consumed as a reference by end-to-end service models for VPN configuration such as AC Glue <xreftarget="I-D.ietf-opsawg-ac-lxsm-lxnm-glue"/>,target="RFC9836"/>, Slice Service <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/>, etc. This decoupling to a stable identifier provides great benefits in terms of scalability and flexibility since once the reference with the parent AC is implemented, no API call involving the VPN model is needed for any modification in the cloud.</t> </section> </section> <section anchor="sec-bfd-static"> <name>BFD and Static Addressing</name> <t><xref target="ex-bfd-static"/> shows a topology example of a set of CEs connected to a provider network via dedicated bearers. Each of theseCECEs maintains two BFD sessions with the provider network.</t> <figure anchor="ex-bfd-static"> <name>Example of Static Addressing with BFD</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="368" width="464" viewBox="0 0 464 368" 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 8,128 L 8,144" fill="none" stroke="black"/> <path d="M 8,224 L 8,240" fill="none" stroke="black"/> <path d="M 8,336 L 8,352" fill="none" stroke="black"/> <path d="M 80,48 L 80,64" fill="none" stroke="black"/> <path d="M 80,112 L 80,128" fill="none" stroke="black"/> <path d="M 80,208 L 80,224" fill="none" stroke="black"/> <path d="M 80,320 L 80,336" fill="none" stroke="black"/> <path d="M 184,32 L 184,272" fill="none" stroke="black"/> <path d="M 208,96 L 208,128" fill="none" stroke="black"/> <path d="M 208,160 L 208,176" fill="none" stroke="black"/> <path d="M 240,64 L 240,96" fill="none" stroke="black"/> <path d="M 248,176 L 248,224" fill="none" stroke="black"/> <path d="M 264,184 L 264,208" fill="none" stroke="black"/> <path d="M 280,96 L 280,128" fill="none" stroke="black"/> <path d="M 280,160 L 280,176" fill="none" stroke="black"/> <path d="M 312,96 L 312,144" fill="none" stroke="black"/> <path d="M 312,176 L 312,224" fill="none" stroke="black"/> <path d="M 400,96 L 400,144" fill="none" stroke="black"/> <path d="M 400,176 L 400,224" fill="none" stroke="black"/> <path d="M 416,32 L 416,272" fill="none" stroke="black"/> <path d="M 184,32 L 416,32" fill="none" stroke="black"/> <path d="M 24,48 L 80,48" fill="none" stroke="black"/> <path d="M 88,64 L 176,64" fill="none" stroke="black"/> <path d="M 192,64 L 240,64" fill="none" stroke="black"/> <path d="M 8,80 L 64,80" fill="none" stroke="black"/> <path d="M 208,96 L 280,96" fill="none" stroke="black"/> <path d="M 312,96 L 400,96" fill="none" stroke="black"/> <path d="M 24,112 L 80,112" fill="none" stroke="black"/> <path d="M 288,112 L 304,112" fill="none" stroke="black"/> <path d="M 88,128 L 176,128" fill="none" stroke="black"/> <path d="M 8,144 L 64,144" fill="none" stroke="black"/> <path d="M 312,144 L 400,144" fill="none" stroke="black"/> <path d="M 208,176 L 280,176" fill="none" stroke="black"/> <path d="M 312,176 L 400,176" fill="none" stroke="black"/> <path d="M 24,208 L 80,208" fill="none" stroke="black"/> <path d="M 264,208 L 312,208" fill="none" stroke="black"/> <path d="M 88,224 L 176,224" fill="none" stroke="black"/> <path d="M 192,224 L 248,224" fill="none" stroke="black"/> <path d="M 312,224 L 400,224" fill="none" stroke="black"/> <path d="M 8,240 L 64,240" fill="none" stroke="black"/> <path d="M 184,272 L 416,272" fill="none" stroke="black"/> <path d="M 24,320 L 80,320" fill="none" stroke="black"/> <path d="M 120,336 L 144,336" fill="none" stroke="black"/> <path d="M 176,336 L 200,336" fill="none" stroke="black"/> <path d="M 8,352 L 64,352" fill="none" stroke="black"/> <path d="M 120,352 L 144,352" fill="none" stroke="black"/> <path d="M 176,352 L 200,352" 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 64,80 C 72.83064,80 80,72.83064 80,64" fill="none" stroke="black"/> <path d="M 24,112 C 15.16936,112 8,119.16936 8,128" fill="none" stroke="black"/> <path d="M 64,144 C 72.83064,144 80,136.83064 80,128" fill="none" stroke="black"/> <path d="M 24,208 C 15.16936,208 8,215.16936 8,224" fill="none" stroke="black"/> <path d="M 64,240 C 72.83064,240 80,232.83064 80,224" fill="none" stroke="black"/> <path d="M 24,320 C 15.16936,320 8,327.16936 8,336" fill="none" stroke="black"/> <path d="M 64,352 C 72.83064,352 80,344.83064 80,336" fill="none" stroke="black"/> <polygon class="arrowhead" points="208,352 196,346.4 196,357.6" fill="black" transform="rotate(0,200,352)"/> <polygon class="arrowhead" points="208,336 196,330.4 196,341.6" fill="black" transform="rotate(0,200,336)"/> <polygon class="arrowhead" points="128,352 116,346.4 116,357.6" fill="black" transform="rotate(180,120,352)"/> <polygon class="arrowhead" points="128,336 116,330.4 116,341.6" fill="black" transform="rotate(180,120,336)"/> <g class="text"> <text x="100" y="52">.1</text> <text x="48" y="68">CE1</text> <text x="356" y="84">.252</text> <text x="100" y="116">.2</text> <text x="248" y="116">LAN</text> <text x="352" y="116">GW1</text> <text x="48" y="132">CE2</text> <text x="196" y="132">--</text> <text x="352" y="132">[BFD]</text> <text x="244" y="148">192.0.2/24</text> <text x="364" y="164">.253</text> <text x="16" y="180">...</text> <text x="352" y="196">GW2</text> <text x="104" y="212">.10</text> <text x="352" y="212">[BFD]</text> <text x="52" y="228">CE10</text> <text x="260" y="260">Provider</text> <text x="328" y="260">Network</text> <text x="20" y="308">Each</text> <text x="52" y="308">CE</text> <text x="80" y="308">has</text> <text x="104" y="308">a</text> <text x="128" y="308">BFD</text> <text x="176" y="308">session</text> <text x="220" y="308">to</text> <text x="252" y="308">each</text> <text x="304" y="308">gateway</text> <text x="352" y="308">for</text> <text x="416" y="308">redundancy:</text> <text x="48" y="340">CEx</text> <text x="100" y="340">.x</text> <text x="160" y="340">BFD</text> <text x="228" y="340">.252</text> <text x="160" y="356">BFD</text> <text x="228" y="356">.253</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ +----------------------------+ .-------. .1 | | | CE1 |------------|------+ | '-------' | | .252 | | +---+----+ +----------+ | .-------. .2 | | LAN |---| GW1 | | | CE2 |------------|--| | | [BFD] | | '-------' | 192.0.2/24 +----------+ | | | | .253 | ... | +----+---+ +----------+ | | | | | GW2 | | .-------. .10 | | +-----+ [BFD] | | | CE10 |------------|-------+ +----------+ | '-------' | | | Provider Network | +----------------------------+ Each CE has a BFD session to each gateway for redundancy: .-------. | CEx | .x <---BFD---> .252 '-------' <---BFD---> .253 ]]></artwork> </artset> </figure> <t><xref target="ex-json-bfd-static"/> shows the message body of the ACaaS configuration to enable the target architecture shown in <xref target="ex-bfd-static"/>. This example uses an AC group profile to factorize common data between all involved ACs. It also uses child ACs that inherit the properties of two parentACs;ACs, each terminating in a separate gateway in the provider network.</t> <figure anchor="ex-json-bfd-static"> <name>Message Body for the Configuration of CEs with Static Addressing and BFD Protection</name> <sourcecode type="json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-ac-svc:specific-provisioning-profiles": { "valid-provider-identifiers": { "failure-detection-profile-identifier": [ { "id": "single-hop-bfd" } ] } }, "ietf-ac-svc:attachment-circuits": { "ac-group-profile": [ { "name": "profile-vlan-100", "l2-connection": { "encapsulation": { "type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 100 } } }, "ip-connection": { "ipv4": { "virtual-address": "192.0.2.254", "prefix-length": 24, "address": [ { "address-id": "ce1", "customer-address": "192.0.2.1", "failure-detection-profile": "single-hop-bfd" }, { "address-id": "ce2", "customer-address": "192.0.2.2", "failure-detection-profile": "single-hop-bfd" }, { "_comment": "ce3 to ce9 are not displayed" }, { "address-id": "ce10", "customer-address": "192.0.2.10", "failure-detection-profile": "single-hop-bfd" } ] } } } ], "ac": [ { "name": "parent-vlan-100-gw1", "description": "This parent represents a bridge with Layer \ 3 interface (IRB) to connect NFs in VLAN 100", "group-profile-ref": [ "profile-vlan-100" ], "ip-connection": { "ipv4": { "local-address": "192.0.2.252", "prefix-length": 24 } } }, { "name": "parent-vlan-100-gw2", "description": "This parent represents a bridge with Layer \ 3 interface (IRB) to connect NFs in VLAN 100", "group-profile-ref": [ "profile-vlan-100" ], "ip-connection": { "ipv4": { "local-address": "192.0.2.253", "prefix-length": 24 } } }, { "name": "ac-ce-01-vlan-100", "description": "attachment to CE1 in VLAN 100", "parent-ref": [ "parent-vlan-100-gw1", "parent-vlan-100-gw2" ], "l2-connection": { "bearer-reference": "bearer--1" } }, { "name": "ac-ce-02-vlan-100", "description": "attachment to CE2 in VLAN 100", "parent-ref": [ "parent-vlan-100-gw1", "parent-vlan-100-gw2" ], "l2-connection": { "bearer-reference": "bearer--2" } }, { "_comment": "ac-ce-03-vlan-100 to ac-ce-09-vlan-100 are \ hidden" }, { "name": "ac-ce-10-vlan-100", "description": "attachment to CE10 in VLAN 100", "parent-ref": [ "parent-vlan-100-gw1", "parent-vlan-100-gw2" ], "l2-connection": { "bearer-reference": "bearer--10" } } ] } } ]]></sourcecode> </figure> </section> </section> <section anchor="AC-svc-Tree"> <name>Full Tree</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-ac-svc +--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 service-provisioning-profiles | +--rw service-profile-identifier* [id] | +--rw id string +--rw attachment-circuits +--rw ac-group-profile* [name] | +--rw name string | +--rw service-profile* service-profile-reference | +--rw l2-connection {ac-common:layer2-ac}? | | +--rw encapsulation | | | +--rw type? identityref | | | +--rw dot1q | | | | +--rw tag-type? identityref | | | | +--rw cvlan-id? uint16 | | | +--rw priority-tagged | | | | +--rw tag-type? identityref | | | +--rw qinq | | | +--rw tag-type? identityref | | | +--rw svlan-id? uint16 | | | +--rw cvlan-id? uint16 | | +--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 bearer-reference? string | | {ac-common:server-assigned-reference}? | +--rw ip-connection {ac-common:layer3-ac}? | | +--rw ipv4 {vpn-common:ipv4}? | | | +--rw local-address? | | | | inet:ipv4-address | | | +--rw virtual-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 | | | | +--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? | | | failure-detection-profile-reference | | | {vpn-common:bfd}? | | +--rw ipv6 {vpn-common:ipv6}? | | | +--rw local-address? | | | | inet:ipv6-address | | | +--rw virtual-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 | | | | +--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? | | | failure-detection-profile-reference | | | {vpn-common:bfd}? | | +--rw (l3-service)? | | +--:(l3-tunnel-service) | | +--rw l3-tunnel-service | | +--rw type? identityref | +--rw routing-protocols | | +--rw routing-protocol* [id] | | +--rw id string | | +--rw type? identityref | | +--rw routing-profiles* [id] | | | +--rw id routing-profile-reference | | | +--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 failure-detection-profile? | | | | | failure-detection-profile-reference | | | | | {vpn-common:bfd}? | | | | +--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 failure-detection-profile? | | | | failure-detection-profile-reference | | | | {vpn-common:bfd}? | | | +--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-as? inet:as-number | | | | +--rw peer-as? inet:as-number | | | | +--rw address-family? identityref | | | | +--rw role? identityref | | | | +--rw local-address? inet:ip-address | | | | +--rw bgp-max-prefix | | | | | +--rw max-prefix? uint32 | | | | +--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* [id] | | | +--rw id string | | | +--ro server-reference? string | | | | {ac-common:server-assigned-reference}? | | | +--rw remote-address? inet:ip-address | | | +--rw local-address? inet:ip-address | | | +--rw local-as? inet:as-number | | | +--rw peer-as? inet:as-number | | | +--rw address-family? identityref | | | +--rw role? identityref | | | +--rw bgp-max-prefix | | | | +--rw max-prefix? uint32 | | | +--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 requested-start? | | | | yang:date-and-time | | | +--rw requested-stop? | | | | yang:date-and-time | | | +--ro actual-start? | | | | yang:date-and-time | | | +--ro actual-stop? | | | | yang:date-and-time | | | +--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 peer-group? | | | | -> ../../peer-groups/peer-group/name | | | +--rw failure-detection-profile? | | | failure-detection-profile-reference | | | {vpn-common:bfd}? | | +--rw ospf {vpn-common:rtg-ospf}? | | | +--rw address-family? identityref | | | +--rw area-id yang:dotted-quad | | | +--rw metric? uint16 | | | +--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 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 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 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* [id] | | +--rw id string | | +--rw local-address? inet:ip-address | | +--rw remote-address? inet:ip-address | | +--rw profile? | | | failure-detection-profile-reference | | +--rw holdtime? 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 security | | +--rw encryption {vpn-common:encryption}? | | | +--rw enabled? boolean | | | +--rw layer? enumeration | | +--rw encryption-profile | | +--rw (profile)? | | +--:(provider-profile) | | | +--rw provider-profile? | | | encryption-profile-reference | | +--:(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* [profile] | | +--rw profile qos-profile-reference | | +--rw direction? identityref | +--rw access-control-list | +--rw acl-profiles | +--rw acl-profile* [profile] | +--rw profile forwarding-profile-reference +--rw placement-constraints | +--rw constraint* [constraint-type] | +--rw constraint-type identityref | +--rw target | +--rw (target-flavor)? | +--:(id) | | +--rw group* [group-id] | | +--rw group-id string | +--:(all-accesses) | | +--rw all-other-accesses? empty | +--:(all-groups) | +--rw all-other-groups? empty +--rw customer-name? string +--rw requested-start? yang:date-and-time +--rw requested-stop? yang:date-and-time +--ro actual-start? yang:date-and-time +--ro actual-stop? yang:date-and-time +--rw ac* [name] +--rw customer-name? string +--rw description? string +--rw test-only? empty +--rw requested-start? yang:date-and-time +--rw requested-stop? yang:date-and-time +--ro actual-start? yang:date-and-time +--ro actual-stop? yang:date-and-time +--rw role? identityref +--rw peer-sap-id* string +--rw group-profile-ref* ac-group-reference +--rw parent-ref* | ac-svc:attachment-circuit-reference +--ro child-ref* | ac-svc:attachment-circuit-reference +--rw group* [group-id] | +--rw group-id string | +--rw precedence? identityref +--ro service-ref* [service-type service-id] | +--ro service-type identityref | +--ro service-id string +--ro server-reference? string | {ac-common:server-assigned-reference}? +--rw name string +--rw service-profile* service-profile-reference +--rw l2-connection {ac-common:layer2-ac}? | +--rw encapsulation | | +--rw type? identityref | | +--rw dot1q | | | +--rw tag-type? identityref | | | +--rw cvlan-id? uint16 | | +--rw priority-tagged | | | +--rw tag-type? identityref | | +--rw qinq | | +--rw tag-type? identityref | | +--rw svlan-id? uint16 | | +--rw cvlan-id? uint16 | +--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 bearer-reference? string | {ac-common:server-assigned-reference}? +--rw ip-connection {ac-common:layer3-ac}? | +--rw ipv4 {vpn-common:ipv4}? | | +--rw local-address? | | | inet:ipv4-address | | +--rw virtual-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 | | | +--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? | | failure-detection-profile-reference | | {vpn-common:bfd}? | +--rw ipv6 {vpn-common:ipv6}? | | +--rw local-address? | | | inet:ipv6-address | | +--rw virtual-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 | | | +--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? | | failure-detection-profile-reference | | {vpn-common:bfd}? | +--rw (l3-service)? | +--:(l3-tunnel-service) | +--rw l3-tunnel-service | +--rw type? identityref +--rw routing-protocols | +--rw routing-protocol* [id] | +--rw id string | +--rw type? identityref | +--rw routing-profiles* [id] | | +--rw id routing-profile-reference | | +--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 failure-detection-profile? | | | | failure-detection-profile-reference | | | | {vpn-common:bfd}? | | | +--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 failure-detection-profile? | | | failure-detection-profile-reference | | | {vpn-common:bfd}? | | +--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-as? inet:as-number | | | +--rw peer-as? inet:as-number | | | +--rw address-family? identityref | | | +--rw role? identityref | | | +--rw local-address? inet:ip-address | | | +--rw bgp-max-prefix | | | | +--rw max-prefix? uint32 | | | +--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* [id] | | +--rw id string | | +--ro server-reference? string | | | {ac-common:server-assigned-reference}? | | +--rw remote-address? inet:ip-address | | +--rw local-address? inet:ip-address | | +--rw local-as? inet:as-number | | +--rw peer-as? inet:as-number | | +--rw address-family? identityref | | +--rw role? identityref | | +--rw bgp-max-prefix | | | +--rw max-prefix? uint32 | | +--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 requested-start? | | | yang:date-and-time | | +--rw requested-stop? | | | yang:date-and-time | | +--ro actual-start? | | | yang:date-and-time | | +--ro actual-stop? | | | yang:date-and-time | | +--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 peer-group? | | | -> ../../peer-groups/peer-group/name | | +--rw failure-detection-profile? | | failure-detection-profile-reference | | {vpn-common:bfd}? | +--rw ospf {vpn-common:rtg-ospf}? | | +--rw address-family? identityref | | +--rw area-id yang:dotted-quad | | +--rw metric? uint16 | | +--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 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 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 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* [id] | +--rw id string | +--rw local-address? inet:ip-address | +--rw remote-address? inet:ip-address | +--rw profile? | | failure-detection-profile-reference | +--rw holdtime? 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 security | +--rw encryption {vpn-common:encryption}? | | +--rw enabled? boolean | | +--rw layer? enumeration | +--rw encryption-profile | +--rw (profile)? | +--:(provider-profile) | | +--rw provider-profile? | | encryption-profile-reference | +--:(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* [profile] | +--rw profile qos-profile-reference | +--rw direction? identityref +--rw access-control-list +--rw acl-profiles +--rw acl-profile* [profile] +--rw profile forwarding-profile-reference]]></artwork>]]></sourcecode> </section> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>This document leverages <xref target="RFC9182"/> and <xref target="RFC9291"/>. Thanks toGyan Mishra<contact fullname="Gyan Mishra"/> for the review.</t> <t>Thanks toEbben Aries<contact fullname="Ebben Aries"/> for the YANG Doctors review and for providing <xref target="Instance-Data"/>.</t> <t>Thanks toDonald Eastlake<contact fullname="Donald Eastlake"/> for the carefulrtg-dir reviews, Tero KivinenRTGDIR review, <contact fullname="Tero Kivinen"/> for thesec-dirSECDIR review,Gyan Mishra<contact fullname="Gyan Mishra"/> for thegenartGENART review, andAdrian Farrel<contact fullname="Adrian Farrel"/> for theopsdirOPSDIR review.</t> <t>Thanks toLuis<contact fullname="Luis Miguel ContrerasMurilloMurillo"/> for the carefulShepherdshepherd review.</t> <t>Thanks toMahesh Jethanandani<contact fullname="Mahesh Jethanandani"/> for the AD review.</t> <t>Thanks toÉric Vyncke, Gunter<contact fullname="Éric Vyncke"/>, <contact fullname="Gunter Van deVelde, Erik Kline,Velde"/>, <contact fullname="Erik Kline"/>, andPaul Wouters<contact fullname="Paul Wouters"/> for the IESG 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 initials="I." surname="Bykov" fullname="Ivan Bykov"> <organization>Ribbon Communications</organization> <address> <email>Ivan.Bykov@rbbn.com</email> </address> </contact> <contact initials="Q." surname="Wu" fullname="Qin Wu"> <organization>Huawei</organization> <address> <email>bill.wu@huawei.com</email> </address> </contact> <contact initials="K." surname="Ogaki" fullname="Kenichi Ogaki"> <organization>KDDI</organization> <address> <email>ke-oogaki@kddi.com</email> </address> </contact> <contact initials="L. A." surname="Munoz" fullname="Luis Angel Munoz"> <organization>Vodafone</organization> <address> <email>luis-angel.munoz@vodafone.com</email> </address> </contact> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA+y923Ybx7Uo+o4x9j/0oh9IOgQkUbIs0YltiqIU7i1RjCjb yVljrb0bQJPsCEAj3Q1SjKX9LedbzpedeauqWdXVDYCkHScRxloxBdR11qx5 q3np9/u9Oq8n2V6y8Zf945fJ87ROk9fFOJtUyVlRJs+ytMzKKkln42Rzv67T 0cU0m9XJQV6OFnldbfbTqp/2T7PyMh9lydb+QZqebm/00uGwzC5hVPpiozdK 6+y8KK/3kqoe93rjYjRLpzDruEzP6n6e1Wf9Yl6lV+f9OsMR7Uz9Ec/U373f qxbDaV5VeTGrr+fQ+ejw3YvebDEdZuVebwwz7PVGxazKZtWi2kvqcpH1YAkP e7CFFJbyZp6VaQ29eTuv01l6nuEcG72ronx/XhaLOTY7Od3/6eVG7312DV+P 93pJPzmd4O5kl/jFq4c/nhzTH7vyx/6iLqY0PP7rOKtxzODbN+XoIqvq0n5R CdwA3vllVl7TXPLdvCwuc9xsPjvXbavsHBfdGONskn3Ih/kkr6+95vl0PsnP 8lFjbWo7D1+enHg/wX5x2l66qC+KEmHQS+BztphM+OBeFxfw33HyrFiM0nGa l/R7UZ6ns/zvNNUebDednWf0Q1kgjmXjvC64ZTZN88leMuVhBkMzzPcFdRqM immvOevbfHSRluPkbQFnXleROf/nYpbDOXdOWpbc/fu/cuPBLKsjk72pRmmZ vCxmf08n2d/hjJLneRGb8102yc7gnEapnqXA7oNz6T6GZRTV97Vt2rLD03Sa Z3Dv0vJ8kU+Sl3mZTsZFZNLj4n3uzVdRz8GQe/7vc+75/QzbtUz2rEh+WkTG /uMivcpy2NfoYlZMivM8q/RME7g5g6vFsPj+ghry6HD16jIfAsIjvshcPM+P +Qi+TV4V8+zvZrrIDi6p2WCCzbx1e4MdXaaz5Nn1++LSDfU2Hw6LWXJQTKeL maC6t2TsNKBO35fD4Sw27p/ymYKGAYIeBC7XBPbt7dof439lMPtFnrw5T9/n bqj/9fz5kR7ofdYvCmzy/fvxODrQq0VeJftwESbJ68WsUFD7sRingEGZdyDQ uo/XZjKYYuvvL6URDz0rSqRBl0Afe/nsTP0rSY5mVZ3ORlkfKf8eDSoM4fBD CpQjS4qzZP8gOf3xwLYlLkFNiegmu/d3H3FPwL2s3ksu6npe7d27d57XF4sh LuKeveD3IrR9igzn3nBSDO/Bhmb3Pkwn/Yynr+5Vl6M+omw/l+kH8DMt/fDw 8Mn93cGD/Wfewjfwh+QU2o6RVpwR5o3SCVH9aVaXxbwAKglYhIwhmTHNq5D0 MlVl9gAXNk32R6OsqgCxALeLCf53lo0AeEBkgRpUowKp9gbNbkklfvgs5chw PVH4VLLGapBnWTaAxvfwj3uyq3uP7z/6+p4C9P9MZ4u0vAaAP3jsQ+DPq0Pg tYbAPkJAqH7V77/KZ8Czzs/L7JwgceOdjYuctvPg/uDBg/tP72HD03fPB4Aq 9wdPH9z/6v7DR2pjr1PcFLB43NS7H/rv+i8HXz954G/q9Ho2uigLQ6aADF0D pTxbzEbM1HGbZ2X2t0U2G10nVdB6mFbAruCP+gJ468V1lSNAaIylu8QVRbd5 dXU1yOvFIJ/V98psdO9d/+3hAa89emxwT3r9fj9JhygFjIDrPBfOj9dMMNGw bhBTqmoxhf/WF2mdpHOQCOZlDkNCi3oxT4BEWCEB9wbj0O4mcIrSacQIm4wW FQgi+HtWTvMZg2RewLpZGEp5pDG0kFUMkncwFIIzL2FwnrEuknQyKa6SakEX A+4l7jFNsg/AmIEA2UVUZhmwyDI7y0ocBLvjfImjAYnQABQdt3eSq4scSA5u YjGDxUyuQQqhgSLjbAxJON0Y9HrvLuBnECoXNGQ1z0Yg8SAAE5JqrZiFSyVi Q8iyf1DhLqErfzeClQ1hZkQU/J0wRUlhTAoraAO/wlbLZLwo8fsqIrIlW9ng fLDjiVRWhNymNWduyemkKtrX7ZY8RaEVRx+KYE7wBqiNLmhp8GUCEmY6nOTV BchVjG7TfDyeZL3eF0DC4fKPF3Rj4N9fJKcj4LaEAvBTBjAfJz9U0NSjdA4h y8wgyjgZXjvaCSdiUKwCPp4mKO+g0D+OYNwOos8FHqGRdV/YS7x1+qLaTn7+ +bu3Lw6+fvz4q0+fdpIDg7yH43NYxNbBYQWoMs/gG5SvZ8W0WMBY11WdTUGm KRGL3xaLGteytX/67C02p7MfAazxW6Bu2VV6DSsBmOLGS9gJcDxB4hNa5iDZ N/fHAwOiIlATpB+Ta7jKMFOCOgehAk0Dd3tWAa4Cxo4yuN6ATmUxJYSBw8ln gsLJOfw2awIIfyRahn0ACWO3lq9nMfwrrS6rLMJGVyyYPQMdrM7pVOjSA52H PxdzJI9wklnG1NESC2yEXxjCZGgETF4kZ+kIlQ0kR/6mr4Dr5zN3exRR2Ung pueGsI2ZRmHDX5m4JVuLakHHh7iaJifmd8SwZOvkcBswhigdXW9L7KCDR+7G DXoXJZsB7SLgaIL1yxDFny7gPFMHHWKNFcIEwHBlcGOHBg4QBXB6RiOCSokI ex5ZXIU4ChL/+bmcDMtniF8If+JnV7F+DKKQsKZOY70oFpMxrmsBFzQdgfgI BBAxYwi3Aa7QfFJc44gVbHIfCOcOLHmUAtmOLyMOWjmiCrAIKAZhDSwkRvKB KgoyEdZN8/OLOpkVNcw6KbBPwSAEwT1Jx4CAOav4l0CKYR1wDbfsGVzC7i0y Ij0g8AIOF8Y4AUJJnaXTSl8jGtp020myejRAAkhf4CLhr/MynaJYPwIJF+4h n928AJisbrZJgB6kNeC4sRmQ6NEEiGUHYrYw1yAK6EHyAvYp0vwOM7CM2TQR 7IqOaPzXFGkzXAlUAATSs4zR2txzuqsz1EauQBNDPs2MxO6YCBrTs5puYVUs ypEVoEp1MQ25TJFUWlQhBKsAypUgDswlfPwVSZu7IAKeA1YencCaxyXqBmeg d0+umZOcwIKGQGOq7RsJJVsbZAlLR31Qeja2fY4fu4F2X3zWxJOtRkOkBhpZ xuz4LuyMOCFQXARiXsPJwHenL+A/yUXBVx5UxTIFVAZpYVFmtMGUuW6EH1xk awpRMDX+WigxKh1fon437pSn0OgXF6oAHc+It8Kt2dhPXsCNyKgVLsPrUWET o/Ukzxb5pGZuS4Nrs8eGiCJPv3r08NMnI7Z5x4T7XgB93vr55yob4bf8BTSH aUaTxZjOHDgBbr3MFhVIZ1lC5kbYFxAEINTE5dNA4KPTvUqJ8hQoOozKfEhE rhdDBmCqxYi5O9IOj67jtLAMe5qVBlbd2BIAjGjAtdoBXQbiNhnaALZkdUhA jdUFhpOjhKZWWtL0eJu4P+4lP58lo4sCWwBYmIN62wfAvM2Y19kbrYYVEBVC UQinlDDsiayOTl2kTNLgOuR0HuNsVAD7nDjyrygULwzIN4j7287QipjCq4E1 sgJBskIFCwU6jNDagoUBrCZItlAIhMFg7bXCLIQxMsgzILl0IOZu4pcA4fJ6 TlSpGl3AYlhSBZKTC48A7KmF9NfFqJiA0AxTDlGlmCHMk7/CrU/w7/kkRQRI WZAEsQV/zQB7wn0RREUhsmTrLL0sysrJaNgPwAJnDuS8hvOB7S07JMSALB0T uBfAWEYMbCJ8s2JM17G26s9ILpQwBp8kKJK3EvPp9U5zxNYYFTIYLXJAKjqV wBGARJDbCWS1XDSozMhRcv1RG4C18D3ikfgu0YKzGV56RYsV5sLa8tIqdEJG ZARLSpjEuu5IZmsU8MoMZLAMZA0n5QJzx+uF7IB35G6tEbivmYXK7RYikJf6 7Iy4OEhe5e+zK2AUO1qanKbXbu4roWD+VqrFfF6UNdK1wBgzzVB+zqup0wSh RXKIg6AmtoX/PEQ9UFmDPn0CjWxmRAkmpjQ/8Y7mXo0GMWYq9/PP2Yf+CCWc TKALA4IAOYtsmsArnWFoBb/CzVSUjqwTWzR8SAlcrEnCfvZP4IYaGcCwKJID DGdyT2/EsJYNhpzpP5AzPbr/BCHzjEQXJhZ0PwT6jsSH95IYDxAYOMASKIo5 NeybXqb5BDF2J+xpAITHfwZ8kw996pvXzEW6nsMA4dnLuliM7fUOUzJd4GkB sIFPEHyIgaWg7+QwnfvBKpdKpWOREcRMJMtpQzZJyMhKAvyOXPlQyYFTBBSa kEVnupjUOaIXAjkAsbsHViiHVo3hkOjqkYhN/LG4QjjvCIuZz9mIw0o3L4tV 1ZPDpEV5lssrOq4hhQy6i3w8Ru29MJR6Iq8gorOk76E9CszC0pq4cEqStCzM vhLAADmRZ7iX6cSMbxY0YrP4BNAGriazMN7hOKsBgyqxjhATRUrfNzR+WxNr Gv4sNdwaVSsjz7airoZnpeZTsrCYFsximReBmoU3z1y64NGbzYJNfWnDMieG CQiFR/3nA/1uPauvIs/WiDbmoofTLOgdF8H948mxve+IBWZ18hBPlyG6qsg6 QISbfKim8D+zaf98sgDmoXWPhXs8rsxx0ocesu0qeJlbr3ZPXxtr3JNHjx/D WMYmRC/gQXv8bL16qPrsPn0KfZCj5tDv1Qfs41h5QXeDZeqG1DAuoAniAiIv THvNVqO5vOBbxLLIaYVbvH3ZpRizZil/dablYbk7xAOHq4kSHrmPWjUOLHMe F7TwixTZMr8gEahJp+WjvcxBdCicTCbypGLQZMfMxoH+HBWwtM4FE1lBxy2Y hnaatKVNqPohR4H/PNhJ8D+7O8lgMOC//8wqqOX5VxcFW6qFC8B0+kAHydFZ VNLypPvKiVxW4oN1neXni1IUcSCHp8/esmwoSqvfAikeIOKkecsncPD8zpVX HiURXHe2zdpTkKhfQKabZI4xJjhXFmH4REW9sAosc2ymYgACMkZbtLOEqmJu Q/d8E70WNuncYOxNutpVOkf6sjeb5Zs+T2q5OxohiFtepiAo1dcsusOF+aCt 8FvDBRu0Jvk0J5N9AdrEBRqPQgGK32Q/fdrr9b5MDkiYEu5lbo61GIoQ8PPP qZVm6Tdc9Zeg2rEcEb9rZ3TZ3s+Kq5mIVsBnt2ioWWFGwx8QNKSXfymv02Te dvgdNVsaUzJxcFmmiN0gIgL77o+yPg0B1LSS4c0TMOM3qHRjEghpsM7p3MjY zYzGoHutZAQnQNhvDw5tdzMFLM2s6FlOAkM1Ya8gPn8WZ0QoLbO+tqF3r47G cZslOuHbiZRdKWJSX6AQlTx7eZKYQeGu9Yfn83DM5GBSLPC9SZuXzMKV4cez 19tljrCzPXJYm6FpYZ/KWIyEFT3dBQ0CqbhmmudlcUWIBGvvp/OcNC0Shcxr WlMoDW4o4CRZqGd8PWEC9dV8MQSw9vEXGDfLEt6HzMisEajBgizGYuP3pDT3 9JerzcJ53pMxEA7syuY//RDhJi39A115kJGh/d+Rx5VAq8p6kU7on+4BXYQt grA9Q/wHbb8/OzOY99qYXICUjwFpU3xwJ+hUNdmgxTZKZjvRZ8/Gff7RmdHc +8cY+GBm5RHAttkIkb1C+zhgkZCxDU/aqJLDD6ChoxFrA2c5ZbgkDxF6dOIP 7z9FI5yxQsJ9LchcjtxhpF2FnBWFSGbP9CCQpzysldX957FUGUH5LQJdEIHM 4b4IJA1TpPEJhJVEhT5nf6L+KDtuWCR+/BRfRDWPYWNZaM+zsPVZwTib4yPv DK38AKbjw3cHb45f3Ht7eEp/yMGQuOrs0lXzxQrZMWgI5sQia0dpF+AEN2i/ HF0AW+FrvnX8+vn+tl4t87MnDx/tEj/74gvQcysyc7EhMU1P6dnkDQlLykHV 8j6+I55yHdhsWBRIA11AwzTQXwIRVJ5SjJZB9kKWKawIYwxZnuq2WbUob/7b gmmDYyhltxKrT4u6COvFf5HJv/XJFq24mRX5ndkLnR7g7hBZoGeDFr1uBVHK +FDIKgXh1OjMGTwhxDsI/TDB+gl0Qo4P62yc2Mp6V4toZHFhnGl9cr9pOEAT BxJjb+G6l+UwLRreW7HRqltB6J/8CIBFY7i91g8fPWXexF7YbgjxZnjJ/gr4 Tk10KtkCPtt/tO1rgPm4RH7L7nRI+XxdwDN05Wg5BKEXJCYP/VrVMXlBYL5G ph3GjfiTAkDkgFvGAGPe0rA///0QFYnK2rQekLUPicEXyU8X18kxnNgP8r6L OimiyltrlAsVayQZ3/E2VtVqyZEPLhTgM/TvmwtOtHxs3MYHQOegGSwCWFO1 41bjpBiyOeZTwJcJsuDRQqxidsdIL1BZbCh1NJAlOLQeCxutT+3IA0deNR8z 4VTIqw3vt351aYPkwxUhiYYvu8idVvU/pvqLJICYA5ADeqDBa6HhqV20LAdS C5NqcQaENmfmZV5fDWA9lVMAwz4Cyb59NcFnWjuDd1T8ICWghFO/RBpMDy28 UeV0gFi7Q9SXuAW+KBHakPKUOldEdQLEx4g5sMbvRrPamCElLHxlM5DQihnN tx1DlocaWYyhmohyOk85CMC//VZFQQGdVCp6gAy1of0DZsGH5DSfw/4BYYBr v6M3EQBpccnsAk5YGm33etRGuIL7YY/5QiVyWV7Jy4oZxb4As5BsMPVdKGjU 5BFAjzEXxQTJ4WU6WWSBkwANTI1EUAdaJBKuNBeNv86nJGDrWXmlM9xGtZgi Tvw9o0c9azdaDEGrrRdiNzNvUDg5edmdTLK0YsMrs9KzwngPyaroLFlthk/S 73/LplrzVINw41gWwh4ghCGno8gYpr+gl376BEP9GT5LhyJZCAaD9rv3d7/q 33/Qv/+16zVCTYA8Vc1mFWT4K3Ug6ER4YO8Hs4DnSPdz9rknqvse35eAc1XJ xusfTt9t7PB/k+M39Pfbwz/9cPT28Dn+ffrH/Vev7B89aXH6xzc/vHru/nI9 D968fn14/Jw7w7eJ91Vv4/X+XzZ2aFUbb07eHb053n+1EXG4YoVzKCI+KMpM jnrmkZ2Y2LODk//v/33wSJjS7oMHSNBEXH3w9SP4x9VFNuPZihkcPP8TrXc9 wIQsLcn4MkF7zBxoAwo6SC0u0KyBGg8gzpf/iZD5r73k98PR/MGjb+UL3LD3 pYGZ9yXBrPlNozMDMfJVZBoLTe/7ANL+evf/4v3bwF19+fvvJiAZJP0HT777 tsc4gk476P5gb9j1dFhMrARNYkON7jzjPEXnJvOS70QMavIOmzyXJkqeuk/y w6sPQCfp9Y6JTyFuESxDWEv26Wtqe9zS9li3Pea2yBSCxixrkEyDPKNBykh+ 8mkD6gNIFDjMbq+3B3Ko9U2Hq4uuAuSmjs5+2uex0jI/qQ1b5LNRZ9tx8wxK uGLqEgE9BTJZkiSDM12RIIHzgKYVPGB5bguBrXm4yCdj9yZqnKWCOILkJTIb EBD2X9KjrotbsE/b6s3QzOE0Ok/HGfT22PmVXObQUgjgHNGLmH0xbD58F0ax unarlcdEtINZQ5OwYQNbwlunkhnrkH4TltWax/BxRCMzhlhkIxSgUDtTl2EO zj8T1rqYpdNhfr4oFhU64ZiVXyHVUHYyy1PJdmgAAzgyyuZkAvSP/Dyb4VMv MUV2UGF3h1q7rCofU2dtanXlavH5C1EoZnpE/QoWhe5m2sHXs8ryadhhfny1 f1yZV2bdkO6GfvCnM3BhHoCPaHXyPMnRkXwb71xyCFuf0+LMOMp9vQgPM68M YDLvvRdtHSeH7P5O71owMqhBh+7CleSUjm4UwzKHFeBfFSAhypH8Gt50RMYF uvUB5xDnbXYesap7w3LK1CK17+3qzce8w5yRA+oZ4bHzoqaFn+AzqV3MiTIi /8imQ/gO/Sad6WcLSN528o4MHEgrrj2j3FeDXWOWe3R/FzQu9K+mt+7KqeJ8 i+2TToYg8N/t7DW1Dm7GepmyyCvHx3IZ+1rL27LrounIvqyh9UAP9IH2jhsG Ejye5xlKjrgRtxrj+gtKyhyVSHT5M3eo6WHWZvdWU5oQiWTr+AUhxQ9V5BbT nTD3PxJggfEV2/pgHgwemYPhcIttBMvxCzoYfOpb2Gf4wGOdvkAGhk2vYNWT a24MSF4ZdQQdKmVARNrTF8TFZUy0Z5MbfTqcXCPyp4SIjhm+tQy2wWCQkZjT 9nkRq1jizUK8pTJkArQsdtMCAn+BbeVrdNS8II9AInG8DJkQ4xJAc83JMiIr 3D8IVkemla7lSKgRvQEeNJYBX+klmBXAmN7s5jALG0ZeNMDUxEBelliyq+Y1 YOf7IPaMeXIVmZB4DtsZJnH0jtB61lrhqlXZhBGPpWZhecb10nfGNlyJH5q9 B66moVKBJ7xELFZ5dlhEblyyUZHHWQiAKvT7BvK2o41V5JAZ9UMm5+9wMbSI mXcmxRkd2x1P/I58HqbsPqlcLDl0C8TnD9YiK0+Z8FXUd5gcY/F46dEkn4o3 GYnd4vRotRmy4+NY9DT88YRG/ZjI5zW1/qgMTR97H6FPVn9kwyX81SeT4sfE kSYiTKhsPX769MGnT9gFFMs+kIx8xv3cP51a9jW3nKWjKTeCsfG1oo9f2LcG Ge9yPhONmtuqf2tL5Mfez3vJF7g9Dkb9w8ZrcVFFJH7HnpMOgrz7rNr4hNry W3IuhktykVMA5RshCP5TBr1towyEbgSgWY4zuGJ1JZdAjaADtdAujaFvMJh6 rSEjg/Xn5u0QM15qUdi2HbUDa4tHqp5Et9MO8LrNrL6iNitb8L3e6MkU7x5x eNru9f4vfJI0rS7Pe0nw8SHT+Dn5b/2/zZ8/6v+Vnwd9+9lUP2+6rwc93bsx nP5ijZYK/snvMdIzODxvzP9222r/UMuP0elaW6pt+p9Enb1tvezz3yu3/Lhe y83o0hBjEnV8vR5b1P6yl/xZiF6V/IXwiaiAuqaGGPh3eQNILRHnPsik57M/ bHDQKRKDdzrQwlxMIaXoZmlIrMj0jau44984sXN5F0x85wc2c4/RExzJb95w WYIoZFazpYUYvotiS9tYfiQMqMj5NJ+kJZrbreC25jomeWUctJwDG3JNDvNL jXwWhqLaaA79ZB918TYmHTGAsrBl1RwxQ9m4VR/KE/KZPhd7jo6LqXQoVjuE XizwGalEFWPHuUc6jp8Upeb5TjhgX9ADkagC8mi4Mj+i8uLIBEZGKbRvSXcF jHXWTeOoR9kVeiukxJcFzG+DOugPVWYtfx4f/OILOup35qGcRhRrgvOLigSE IwtdjDTnvCokXwMAeE4qaXI2MeEsJBNfFpPLTMvm0hDtXOTk51vrMPcQYAtI 6SCyjpjPagU/y2sO47J2B1FsyZvN2PJYBBQ7kv+lL1unSVWc1VcouKEjD6Al PiCzcJgaFx4XlWQ0PCPgil0lEo2tvBJoZdCgHPdB6cAVeF5Z2wPeYO58DbSf AD7YW/+8AYEjetXwQptQk4h3vHnSFPqjZFHtnA/L0P3gzGlGVNClo8Dfs93g dDJANDIehkRAuXFjraxMjpPRFUIXMELg0xeVl61gm8EQ9yYYiscerwdVxma0 gAGnmvOLB3Tx4I9dfrlIz8/ZbdQ1NsqXvOKFj4bkqhS4U7GE++jh40foUqQB ay1WJJWZcwD1zTfSxQx//OQHLA9FUx+frSsKYuWFiLCG5vl450m5cPANrxZE PF4xJUwwWivD3iEMAt353MRwzuw0Fjup7Is6VNuYFgj7rM83x0MxvqM7mSgx JiIH4M0T1uLoHZkRtAgXa04H7VFBuyY4CIcbDzG3hVkamh/dT4+22axIunwD IeU5QvwIcNkUZDpCZZjtzGhTssATRtcWm7KVDzKYlfV72erJ4RaHJcJU24yC aFGywWKFhMUpP3Dzep27O2cMjpzRA9Qp63HovGF+fPv2xDgePP3q8RN6VeBX aaSGzsaODh11mRKE8cRoQUNtZ5AAVnb/CzIJkHumM49HQ/aYBHSoH/IZhMIy aQn/o615VMz9CM1lnMHy5gNqtTV8sG2nh/lMy9/5o8QG+Mit9g/gf35nVwDf Hhw+aCgN0QFODvUAB4cPcYDNpuJkFht+NqnZ1nB324jzmwHEzPi/OznkoYyl xK7Xg9hHb+A2iD2MQmyVDbdDbFdAvtk9QAixRw2IJZ0DGIg9FIj9rgGxaH8H /mDQj629lXr1O151c4ntvRtLjq1vld6tCuFqvbWSSFA3euH/6G0NP2wnfzAc 4WicfHBa4WIkyuCmpM2rRGnZbNcGMftSBlIXUlegrCf6ZQ0dXvdZMTGWRP07 q5JAhEFJE+d5P+jHOvl1+NQj/WN/YJsWjZydKQ5vXMxr84wWjiBc3qYGwK44 4hlmBpsvahs73fpq2LB5Ene4gO7oPEG8z0VnrpBVxMpUkVgSEQ6NVX4FaW+Q HM04/IrmvyzysQIpvieJFZNN2MyPaj9ocmaNc/Sqhda7ndhh4OrEu5gi881r lZ/YQODVx2cWHWimosBFqdXBydHQGn4v1qe0Y8SrmX5Lshp2Qo6ALLEpe30z IN+eWH2ReX0HdxSn2PDaWBpY+IVVOJ87lztncl1QQAlOfIHZG1IXXO6HZQhi yqbuhb6xvlPECoECRxKyqCIebEoglSFYQpvJtcO91kRabBP8/Rhg2wF7m/FR NHnbzIrjnkvlBSbwTzdCujJKaC91llW1nK9NAW7bnpen8oFkB2Mv2aG3A7wj +IrNOrGRFVVQuCyThU+TbQ0AXhQ2iUrViIYKlrftU0vBdJWrytxWDPybUzho mWH2NfZdN+190S8u5BGjeWZxyXwijQdG2LAWD83kgnAYw/rss700pTFM2zdI 1vD+YuvfNyb8Nmk0dmOszGz52z9ihCZPxWMo5vrfirMu48Su7abm4CsZft3c 9PF47JKPx29vPK861MsGDoSfQaztoBX2f5APo5L8I64o8BgWizC4l374XVTa +aiQyMrP7Tjwh9inZR0tbwVxJIg23lRSF9FvY4ZXCYuPVODWM6HHB5oa2+15 Kdm7bPfCLco74Bae9VHMbwmZ30z2nZA2sg2yIrez0aKsMLecTceD0bvsZXAw Qe/4e3h9cZ8T4jKUiG5Kb8ASwKgmNJzLBDpgvPnRzJvHLYYJtyEOz8rifVb2 WHiphHSKyORot5EAC0N3OJ20YdU7tPpcEqCSgwIZFUe0ExY6VKge9Jc9eFwl ti62ZFS+EcPuSzzaTArO0GCJDJcjdNlBI8yJk/iHZHhSG/XH2x7Q+47ffD6A 19+i7seQ5rsvwt+ITmlWgPfXNQ5I/7fQmgHX+O3bjwE/wIEsG4m9Uj7bfZYc 3Dtt/Eb/VlxBc4QIAej4zScMm72eTLmXPEtH7/t10R/Cf/37EJCNMkI23lqk d+LiUpJgCQJJEyp0sSXVijGhFZR2xxnwTQ0IVuswvkhQncKInIomeL+KjSmC TV1KMJ6PFjS6NWY5A6Po67aOzwTYio1ICZjsoqtFdTnakX8/tP/+mBi3DYI6 haX3TbJSO4t6ndrx3nJxAPLS9B8XO7cy8LayFEbuGi2B0UefvdwcoGFGGDtB ANBZfeUBlP4tAJUkEgG0vFks3Pjhzpul9bMm8LQ97pcGnpnrwEseYnLVtA6o r4wSkNr3trLJaeCNOmj7PuhGwz9nXVBPx/91P4TTNSDY9n24zE21798p8rvp LZOA/DwzN8GHRNSYiR38s1ihQ4jySzuoz0AWO1ixw0dZHjdeqQMH95ardhAj rDC1VTp47VbqYKL6D14dDeKfW08R12wbnGZAsGfxZrni9NG05H4wwEd8/HSo 6G3Ss+vzx7XEt1Jc9GZ/mYU9DoTNBgU233Z+qAspV/vLpmp+qN8zX0yxLkaz oB4LE7EfKrQQbr3QEsKJe+W3dqbtDilG2zopiLGOpBzQTupirpl5oSJ+QL+x yLhIYY+BYaTw8evtHXy63pZcS+K4bgMLjd+5zSdkZtB5KTil80KSKE0liQAI YeSRHBiJN9ESO+lL5PCmddXWqVE3XQ5N04wDq8ihadvzt4fmKg30QqWri9XS wCdro7FxwIGXJYQ8kWyxsOTMZgzxMmWofBXoTPOcohXn+nkydKZB85XcKpvt u+F4tZ2YtAPo5PPzF+o1E6Vc07L2RF0KzvMyVDult5L0wLn4KTk39mbMkLMf Z/h+IAbG7VjAWmtonIsKiESXcVqWtDFaW/jbfku+Tzg1DqBS7/EmBm3QawsL Q7zYSXh9bGFsxoCpB/iRyqnFxsd0NrooSl+hwLHN0zXA0Yad5bOx0ZO3CK0K DnLDXHnNDKkUg2PTazXtqfgg4b7kgzt9YZ63e+zVtRdK2j2iw+WVe/jomYdQ +NIYBr5M/pOuPCXxSqv/6hniy83oN/mAnMImON1A+tE36D6+l1Z9jnn2GhZ2 FTKhm8i20HNF5rPt5KZ/t6zdKK+vv1thPCBTNdCjEVzW77raYdqk7Lvl442K xawur+2Ath1DTG5mTwHRej1gaqaydnNcp7PzPQwJ7wOZ72PEfFu3Yq5W1tWt EEfLcKrVu3lTLV2k9fnoK58PbuCQ0f4C2OH+QaEI/2Xbms/PLjpgz40+RqUd lP7rT9/pHuEENCb+wDeqvoZb2GzP/orBzPzTFv/WZxfG7e8ay8N2e1v5eLv5 i90w5XyAvdJ/+/m4uUlvOaYZfmOxKTZrOpn0TSxVx/TYjCyVpjEeaDadY8XK 1nE5T0Vk2KQ5LLclNFHDavxXZEAPEdKA4KM3b/uMHff9btU+hvz1ccJmr2gf 3pT9ctlhJqudoW1QzAmpAStju4j3MRkYKU6tD6jsd3XMYE/+tNiemGstP0zS 8/40Q7r95dpDYGbpPsgEfXIbm4TwHBbFJEtnwdJtJ/Y9G6/XCW9xE0yNO207 WnHSsKG+5b4eidZ9LI6QJ2Dz3F1Gwv6QGE1s+o8OS7nIq/s++AlwI7IU3c6s Pfgx0ZcnyvCirVvZaLR1KzONtm5lqdHWrYw1vpI29hoAHJMwRMGIPwiwP0P7 rqDNl8WAtdlQ+Gr02tpP+/2tQc7pY26XeG/FZJKAsHn3vBOk9PnZ5QzldzRb xMGNZCQMOxXbv7HBl40B+be9SLVVO16w11ZpkD9t4la0fyirLe/fIR+u2z8y +SrrRwRdOD6buCs0zWf95q8f/Y52zhg2ueagkaSAUxz4/l33uuzWUM2MrMD+ vtoKktVXYI1QVvc3lqjAmED5d06N3363mYnSpKlMao16Imd5WdW6oglFgaHi aepRoBdPReq11S5NOU4UyTm7q9iz+IHXaP2oV0uqL6dwg0rPRSxQfaYKFlTF RufWoUAH9N+aRYpNHnOWra390+NtMzJdX0k6lmzsnyb3N2yEyP2vP32ydied Wl3e5mdFAkOZkUw+GbNViesWh0bnsMexemRcCHZrN7q12SGJbG5zbmJKuiFW Rj/xNxqEYD3Y12bW5FQTBk7I3DAQa4eKiFGFOvZOtG/vYaCLqADfcC0itm1M JX+Py3ljs/8ENWy4iKRUufGjkryqZCr3Q7gcF1Chozv8ZJgUDROkbg13QMYr Kf/DWcMvCixuyRFKoRWLDTzjHTRh0vZ2ZHpK+Wic19R+Iun/XEiackIopDJC w6Njr9d7Cbd0BpNNxhY1MCHBkaT1MPE6O/6WeKW8IFB10hrOicM3rROedYiY puP23AySIDarLwrQQ6RWljkmdtGA+12UDfRFL9gsc7lp+i7dbpaNwzSaysKl 4844GoypzwXH1tjiEfHIELgtMevB5rZBKd3YJjThlEM2/w4G0zDSkEvQvUhM jTMtetGmVIHQGOGo6A9ejxND+bZOipNtRBqdTwOtckif+gaTruWo1K3gFNec sYYdZRFXqIyiAatLhK0zebFN1tY7V4E3r149P/Ezej2TxLPGmM0+oWZVknub M7aTc7Uh7C6mVNxTdU5eVYHBLpm9Lm2JI+d77UpfqltlEDu8XSoeWcd7qaKM NiiNLnPEVOsinF2Uo83BvxJaORu4QyS1ZReXpRdui93ifcQfKY+LnybHz7gC /3L52onsACZpFEpeLCj6Tt2KMsd41xTWHtiyYNXCiILM42cLm89flW61GBbJ fcomd3dlybJtIEnXFmQSyUemgBnIq5s7yaYvgmrASkkkk6fGno/OExSbxrwW jLGenstNtcn9Nk3dECYLtpVJUIqVa8JiEdj9fFIM04k0M9nwnTnJhkZrbHRp XNLKOAQCad9EoWBTJ4QKWahLeGfynCKie6GZ1nNaWKl2v1M+/3YcmNazZG0y N2FKW7kHPdmGV0BG6tqo/eFwavcymK2ciThCKUqbr12uP5m5qOe79FwV8+NX EJXQSzmuB9cOQEejNJEDxndWMn95um6vNDB1gm3cydli0vZQhrVX8smY8joT KonshNGLflrpZrwo+iAaxAivGzqW+YWSNxs2O9rIqQ25qMPUV8YZ1c4Re9E6 897HgGaSLY9p0av9l2piZ+mjiV/llWQoMKTZnga3qtwgyWv5RlYA1HCSlhIC DVffthRqHtkrLiS0F25y8ixO8XHlirAGBevsqyNVJUxO/viXbVXAMK9UpT2b btchZmhvDK6Km9YM7o8tvTxlBtMrYiwEkjQeYpY0N8dB+1yjBBAp80FAJLyJ AJFFCCvBXy4Ow4qM294C/SvZpXH4QEidihOK/c2alnYQjwqRrTSyofba8OGK 3XuzLgJpxUeTpZCDzWouhllMh2ZMPMWsOJMyyTytJ5a0EtNkf0JlhVCo6arf yJUKYNMtZ6czqG6ZUpo79pmbnscNecFRjGmrQbzxGmoVmXIbE7TwC2Ba+Zi3 hMIcJiDH3zLcKksNO1x9LT9joEhRvyQry4I5bV55SvBZlla5JC0HAIzeVw3S w94ThoPbZMscSeRkNTMqUUgny3I4ulRlY4/4ybVNjEmSJGtPDV0rXISL9rNe GxsWkBui9Atz+j+/519o5G//D1Iq4Im1E/fFTwsaZuOcRMKz/BwaWp6iEzV+ 7TJoPt7F/GXbirb6F+ttBkyDcnO74nhOfbaZIhoZQ2Oig74g7zhZQMTBoTU6 cBAtu2rm9IIoWCnj4InYPC35dTG75E+u/GzSBEkyzQnzmB6gzOkSb7L05Lvz WyXTljVHrxibbZ/j1ODPkkQ7FlIRheTy4rE4w2zknrbXEOyMpcRxQ5G3ObhK ZMB+JGNOeG9vi2PWoCTZlKdDSb6YhbMU8zudBDQyYhcMJGfv9Vhx7bIydY/P jZAWpJZTeiPL6m83sF4zG1o9cRs0hdF736OfGrFQwvEl5gZRkV4tMpJlEe3L OXvjXmamNwlCroZOXZwzjpsYHlg2tJzOYVWc9XlT26k3Eb3KfLioA0nf1FE0 18gmAjLJtClnrvA8VdZZp5wWSO9YyBDTqxbDv9qjVpXKayEJfF/6Wv+ztJ6V J9tFTFmuLJDsTYbaJLDJd/6YoATqahhmV5J3fZJ9yF1xDADFeIEF6dzEjrdV QS1jMTLzTF78syh1Ljc7l7HYVDZ71kvwjPSXnsIuxeIrSkauMYSezRAGxZAt y1SpyvNmkxoZzQzPOwoIbrQFJe1cTKRogSlTT4dsMVdtXW0Lk60VQ5rMxGdw wU2DHTzAjiqL5fuFmgPl6pJkW3YM7qFJ+Pn0wZNd4BJcrC/2+y4mBDW7EGMn bD6jFOhHtUumh5y6Lriyhw0sbr0pMmCZkUe9qpZm2YU+P04TwJcSi12Ysmx1 rZz1kAHP0I4eueXWxmfumSwMFFkuI+gh/XZiCkNw3YozEDVMkj6WdMuS7cAB 8tiyrEpP8xZDBgApZkhTjourGdykvPYpuIGfVa2B1hkvRDUrDIfqMg3C0Xxl hqdja4kEoEDbVsWXZg8RLMVyQX4dVRsbJQiqY/cslk6BFAAdr2hHZvXAoUkr l/h2YxXnig3BQqiOh4aeh9TGqJPThfurpFsTqeiimFBSOOfja8zcMYM4nq5H cK2hZlZMU1LqsrMzykuRYWbsPRJLOR0RaiDErtKu8zRa2VDs3JtqX5r+6DwP BC1ROZDmmjMkULq71sSHBlVziRjKdFbJkI5OqnUj9uAkhgn4oObk9ERteXq4 qOfnwpDQuj5SRe0YdsThmJ4j3PBZ6y5qkbH9hjkA1QAEZDXu1c3K3KGrtWRR 9Nys2eh3tkDdT5U5MXQjmn5RFzgg2rl/QHImPsJiCcPTxRDHMsmeXUv/0Yg8 kLnmpy11CQI6xwywD34uCjaWDXsjYo195eWlG2mHVq9qb8eiHmXxKld0QQuv eeHiUGzf04V5uHQNWJ0V/nGWgyLLjq+DwcC154lWbd50ifCcYjEyjnzmZATf Y9COZdt3O5oGjdNRwwHRtrCNJrt9VXlDu4ZMEEF3MVfzd9rhozlEPu8c4uEK Q5RcvbBv1eju5kU67W5QYXBtrtxlWlqVnr+aAMj6Izi8MQ4JBj0B49Z2SqB3 diGLrBnTQwvFmVvDHAaYkNmB0IJyodvkR5HSCPSMmXCJM0CFwvrsMw2S27BC Nm62+ipT/5dcRoeqJllN0a4uhX7n8bu3E1TSpK9YcvFTE3AqoEBmw1n87Tb3 M1iyOJI0QVCJTRqqOjJFNHFur3eYUnFmOoNGaWap/kNvD1ubg8G9dHSPNPxt kwc1lZQ58cqqdJJYW5US9lC8EL6a+Q4ANukv8n0v546YqFwa1mn6PquCis7e 5m0qLZU6qnJWm6C8rn5S98rVmsK07mF7Cy1W1pKxra0NNslUJZY5V9nVILO/ xpaKoJRA8tweOinTVBY0eBD0cIWKuC5H/S2UPlDgwTuMjApf98ZF/eBv+Mff 8hn9lyoIAknpc0ZU/ApoZ70AwjcxIeOb9kXlHRojzzjjcvy9DWuc21c2hEuZ 4fNnWi/hogChF1nKRVD1cxIsy4kjcJwoCennPZsPwCUbU284NoOYLj65ZayW MMRERBdKZ2pkF/rH0cnlI/rfxzuGjjtz6E6SPAMaV2amUAgIl1dpSVTvuRWq tp69eL7tzMVfULY6m4mOWKtEihlOSyntvvCj0vwWfYS5kN3Nbi6/6YqWoxX0 fK7khW0/31YsRR3nT2OS4t7zLDkys9j0TryfsStkyCZ4Dvvja8gFoIOy1Swd 7gh9hA3sJX9acC0iTA5sxMA/FacAS4DoDjIZAbaUQHHHo5aUfUhBJXfrsaUZ zVLzSsgTRW2i9TGSpM9gGFFfm67PD+sSAbDSYyuEVKnVjZZiSqhj5jX8m9cx Bw1oZJ+jzKumBLLFIsaYsq8l9HFLMtL07cOQetANYsRAhi2vCQ/NOKoxyGEc MvHRCCPGux7/GY05+1tR3c1AZ0CsF2S3ktt2R8Na1Lqb8ZQE2D1Y0jLYyuJ5 o2H3fB2T/WsI98m/qXSvyLwR70Om0yHN73sapscydqgcgBy6iCnWmYBo+t5y jkRW505s3hzYtyiiudqvjhrsaDot3/CDcfMpWZVKW0rsxZrghBM1sct4Zyl8 sPVeb7OTVm6GVcaEn1qabwp6i7zqBsOWi3liixEORUg2T4be8gyv2IwT2mWr cM8Fowl6C5yJKL4DkkD53jJcTgtnHRzZNfvh40eP5El1FeLcthTpq2xTFkQy HcgA7juWIb568uQ+OU0qIGF2uPcGSA1mutlJ6YPFkdhgZmTNjKtUFyLQWuEP YZmO3me1WIGuXfkIiUenIHc7GHo4SR6DHfYBMA/niLw4CY66P8JsVphYBXUX 8fvZ2j94ReXKNtuZTBuQrcTkbYqs0QpyBt5Y7lwabreAk6RWU5sMfxCac+/U 3CJDfIDGsK8GalqYVo+zVWRjd7Xo0sad2GudGkKy5aH0quUxemKhNBylWlAg oFlFWuXCUG8uSN7gavsVk+l8nKd9pYXgV/n77CqvKBNwLGew8r3nofnBnAe+ 0nEI7Niyxf6N27GxMEtB7XwQTdlZW4HFrF0KVHsOBrxpKXHEld+9wACpphFu kChs87VdtJqm+bYKNZx0NDdaSyhAbAocKqVcGD+Pync1pTozZL4wfMi3YQBk 2B0B7lnhnCeV82ebM2o6Mo6ovVs5oiZc9VHbciMbRvuAVow4tMPovKxxEKbR uraosp1S3gzYD5IT62ZMxIEdbkVjtGpi3GVapYquW934+V0A6VbTq8dpl0FB a5tJG9N+pwSsM/sEilfxquBiVKrg6skha1tkzZfTdu5bekl51aZDgmafedu1 iQU2KXEI+jnmowVmoTEBON45tcApDys0Cgr8U5neEy1xJ0s+q4vvayaB+PdL 6ZAS685WzOlgWv+CSR2aWR1adC6rUQQYb7QKj/TY2ynvZys9HbSwjtjVjGB9 eDE9EvnPcSnvRGVuzYehcfNfP1lNBIs74LN6NpJ4MHwspr0Zyd4C8ZuFgd8s +PtmId/LV1g0coV05vDAVFOYPTUff9kNWe+eUFg+/mYvUFvgvQtTMOOvG7xf cJ5qPcQNEgB0JpRpso/2pAyO6LalJ5GwdSFUtOz/NP8itmr+EVmF69fKgGON WxbtGjWSNtxdqoaWBENRJAqsoHyeoWnUKT34+ew/EEKv1cKoGK3NrRlRAFf2 IPjHRS6asqXrRC06RfGOIxatgyTOoDTW0IXhbsIGQXcMIXHjEEI2qN0gGEbF wdSmnvA/XTAMVblFg1jdBzlUvS3roJi7CTyI2IJ+2SCElSa8o4CEyFx3H5yw bBK9F5RxAqBZj6aZOK/oQE7o/gPQTiydYLxNjmwxsq0fjo8o44D81NLqGFpR 4J8TmPyLqOpFi/mkzKbomu3KnjbSw5qdiq3k0f0n6OlIc3DcTpmCEkVXy8b2 z7MSdSZy6nUP542UvJKgNk3sijfZjOxS/KpEMHCnbKCx5sMBxfD3qCOPrTnS knbPFGQMjZ8IhG1Runx4JgVKPoON56ZQX7RQHqf5MKH2Utl1fA10Fi3FYVCk ccbiWu3azXr/YKeXmgBhSUGrgv/FAcsYv2p2SaNkD+T6ozycqPTuJOttkMy6 wdVwFTRsTI1Zpepr+FbY14uXsos0RX5zV5+8tgIhMGJyTpe1uqy4ElE2yyhf hdoyGe8mGWVvQY9DFBT0Qsg/n2BCjXCcfdUgeb3/F3wpu+YkQ4QTlHQakcTN Ig8X8sUr6+ND0PS+fciFnjGz0oJKGVcS8lFlbj0SL4CMfMLebgOs0h0vXYTQ E281V5DarKwK/Y8FaYdnxBXqnHMDbVpVRMV563ugbgiaVqnADllUEakdfDhU IELyKn0ofuy/CypnoxFuj1GA7w2mmEZfNW14jeTX2TRqjksSXhcuAl9l0eCo JlvtObA+k4imgN3w30bwZR8whklgpzSiBnMwd6u78GK8KLeLCRJ3znH2wT5K 5Rw0bOaPxJO6RUQCStvyMVmSa6PiOaW1F9yp4at83yJZQtyDrYkIejp44IJi nzzdpXh0JnC+j1Msc7f2FFOJMlxdePyNXt0xAkOl2dg3aECxHSiuEgCab36G WFvP07ZKrPrgzSuLffvki5IGp99veBbgIJ7ix4wjywTNJruMYZ5mF7Z5yG1E dQt+Letz/hlUteAn+MbgLytpwe9VgN/Bz8MrTmiPNlVD8A6c+mn1MHkcgq3I 45C/Yd9lEH7TLoMK0WwMpIggoBGlitQ2ktVT2XPr3wcHks6rxUQKcBrPW7yB 5HiqmapkqBKfiGa3HeUGKsJ3Jc6poecf2TqA9l1lGHXFrY5ULhNTLf3V/nH/ 6Hm1jf3Ue68/P1tOhOG6NQJwC2TZKT0Fm7A4fsacV9liXGAyAVeS/aTkYqEw p/N1/PHkFTo7IkBsw+zPNQZmIZ99RY4s+2WWWrfmrR//DCNsx+DnOZ9HA971 wVItAHfpVDXcS9IikRE4321X3p2GJsLkDPeAFogBwooyI8c4f2f/HW+ZR/O/ kU1/JTe41e1ha1uzrPOnw3f9s20RSQrbYkh0GZPRAz34xY2Xntv80O0DuXfH y0k6k8S1C4Dng8fRKQMf99tNLn6s+SzcRLLeOLZ5tWwTyWrblQdRpNmM6Nvf NZe+t9Xw7t9ug0ejZbNhEkeEzqOzfRw5jDZyzsojm5oYd/1wt7v5WVr2QRkm IM2aiKtXcDn3Tap3NfeXq8z9YZLGf3dNZrnKyrxsEQ6uqIlPTUbplQ7E7wvy jeS8xo1QaRD3VRynLuezEI8Sh0dY9SHYiCoEwb82UbkjC3TLs0LiV5gIB2i8 KPzLmuiV4GZM9BGhcGULvciVRyedIuVDI1L68rESKZcLkDBFRHbUgRiejLeg 4l3QzNg5UGRiRdqkbSdt/VaCidGVHkn2hKVyCucowQAiWg/GEGmPNi8zFcY9 gWiolHdy5rPmCRHoMjKx5NWFKyK8f5CmpyokxTkCsxGcc0imi3PsIqIgpcHE rfUMZbc5Jd2Dw9bm5GEYAbYtjqv+cMZaowO0OAe0ANaIo5RPi5NuoXnz55/z +eUjpVuomliNMGiCo5cXRKRAcz+WPb0tv9amF0yk6Qd+8SnCREuuMGDroIVN DDkSygk7baWdSOVZwL+bweZA7PIP/Uk2O68vOtL1EyN5Eh1Chu9j8oWRU3Va 17VEUtoKxmlIJYkwEbnCETaixjJrIztJbCjFlbiWVXw8vUJu1y/O+rKEvqr4 0CaRqXmyD/iQlNetMyUNVxSZIAsPMfFAGxzIvCgmoBbgf8I3/WZX21uau6/b ikZEe9NDTgvGNfusiqtts4Ho1HYNml3MZ7XJBIFsyNv4YjRfgj/YpK/9JJYf cKPLKtvIAAEls0jX0mlsjBK5bll3Iuu2WGZX42pKNbskDeTU3Tp6JVoY8aXG 7l7ms8LB0X6Yn7s7E9lKEtwVuCbm1kRvSqTLSnckCi9FLVbYkh6iNU4mcsD+ pz3CpumZ1DKEJymfjVs44uOQIz5ucETNfx26ggwR1UMTozOEMsZ20MpCqdEy JvcHeqjmSlYq9oQOXy5+2C4XJ1sogXSVfyVx5vHq4szjW4kzdyzPRE9vtYO/ gSj0+C5Foe7BPotCn0Uhv/c/UhRqw9W22bQolCztYz6rzfZZFmrpkjSw89eW hToO7p9VFurYkh7ity4L/YYEGtfaM/p5Qsh64s3jLvGGY3slYphtffiO7ScL IGsPJeHL5vmoNrYzaOinEED7YMNmqm2EJhbU+CdSVXFlPcP4ffIENBmIqIEJ aD4zOYTI74pth2+040yYycf6+Qa1IaQvW72avUyodI2OhTZTpKTASjHhFb1m X3RlzzehrGZ0k5ySzKTt4c86zYFxGUY3G0qtQCa2RuEYqU1lXNesX5KZ0WZT olDMcLfs4cq+nir3sa7+RVXfqUCdyQRMXmJsiDXjbYkjA5MwcoXYtq/3mNDN mnYx4lxaD8/ntumb05MX5vuimp/ZH45O+0en5pe8yiv7CwLl7ZEdrczNaAPM cat9zaswDjpE1TC0vul6aLM4AaJXhTgXuczIMe9ySeTAsfnGFmsRwfgfhCcy SF4DMuOLfBx+P759a7d8WZZ2z58f0H06vOaz+K8f4xFvYlP5BDyoNAl9/E/0 saz1/b5Ni4ktmA4+upqP4YLCixRlzbrjkhd0uxwmJ81RAr3WtgeC4rF75FDw 3aeQp3cMgbSnMQZ+uc4gSKYag+CX6wwC9KwxBny3zhBIHxpj4JeNQZJ/4IOm liOMaGNEkpWfMb8gSeaUuZIv0CimZMKPqVWQmdePOHadopHHHdv9fOnjHW97 6UUbSatROs7GfXSXYTOQb14I4Yd2QdcW9gb/SGbZh7p/Ucwju0zclei2rzXX Fjh96P8NTQaPZD1LB0S/priBK4oFwQBmn9EBGl4szf5TLCozajGwNf1VmgOs pvnFILWm5hcbolPza641KCDdxAijR0fqXTcbB8N2Fp9u7b1ONez4euPFsWPY Ls1vtNzkdst1hul1r6r5dNuzw3W2X1X1h7NxdFzV5LZXNbnlVU1ue1WTG15V 9cdNr6r6Y7WrmqxwVXWzpVfVfnOjq+r1vinuu/Uuv6pB8xstN7npcj+L2LEh 1haxrdgbkTBtUk9fjF092r4KTHRRKbZRJL2RQU0nxTMBjuS9h3QQw9SF2kXr VE4or7fEW2xMr88we1MOeAWdNrZtOJRxFpRY8CBNMoUUCUWMhcHDTwkSS7Zc 2ejw2kn3KJ9mUu/IZI30i2fSnsR+vUM+dpnZuCXG7N3Ge9nEetlpOebqQ/w0 isaxTckDDktmIhxZMP8QqVLrrxegUZfXriA89rFx6ibOmVtK0KZUwEQjE+zn 5Ulnis7GeUUSckruPZeP0+RakHKqNlqNlxov+sb5Me32TLW31q36RXRN0STl T0q5MSlx/zjbpih4ayTFNNuX+Xgh9Zy88RmTWDdEwyMrhMbuCBdmpvP2q3Hp dLCHMc9JvkVbwLxOJlla1Z4ZeLNK9k+TY3pnTbb2T4+3raXYvMdRk+NBb9+Z DnVxA0FUNPZNbI1Xa2WmKDmTa4GCMjlo16sEa1pV82JWceHjBHqU16Znz+Yv pzyasjpKQoqHJHXppVaGl4AWfkaQYPkpThHr2cBtBciFHTWfpjCvu2U9vO/G 25WdfGewEE6EqobeIa9dEHpGJupWwc8N52iIN6YeqFddUJKQBRrza1N8wj05 7FCadonuoi4MMZX2VcWvyuVwaf/fyXSdpgRBt892BG/t/8zGQzFaZzb7XrNJ pFXDah0orKIHNCK/2rQH3UscdSoVFoLqS1r12e2juzetUXdeq7d5WD5Lpzln TeuURH2UCVONrdzVd02ya44HszS746Wcph9adbvgrF1T4y0TU6c8qHgkp62t bS7vjBoYwwKgE9NTg67vM6SfsBsgaHk66Whvu2xx6prGY3fQOJHn77QI37ub DT/6O+mnhdrL8q0Eg6RFH7YF2kk+W75G9U/o1Kdee/avfgcq+ducjr9aY5/Q +h+wxqgXVrR5ovAjjNBagsHRMRqmhW661ByDkt4XoLWcoz5wMV0ONPXppAvG gpKfXwyLso3vJGvzQtcpngKv2wRLnzWz4TUXyymAPEK3nNIl7VTyBr01Y1jK GZJ2prJG5yZPWW7faGMpq/ZcxhKStflBsioz0EOvwwl0v6VsIFhTBw9IHP52 MADd6mbUPzpCN+kPupjPyjS1sbU40Y+ubAnFv/OlddB6f4obEPq2AVam8tEB GiQ+WfnaRpLprvV6EMuru8YA8RS7NxtAZdtdawvdjzSrvz599Adc5y3n463f ndZ5dLrFi9Ptn5ucYtZ9l/vfgsp4D/5P6Xvqbyqg2TFN+7NKEu3lf27xtKI+ y15XPtvllV0+NNcYozzaeVa2xL+gWrkuSRfmnnO5t5TN0aZOdZ6KWCodbW1G nq3YGmmyqtVessCeCxeXiupclbAGAvz3LCHz15jtq8PrZApsuOJ6GBaBN02V x6zKxDFR/Yqp+HVyLpXqtb5Au+6czZiNElvqVcELineVdhCgeh17Oo3Yc3EV lhxixriPzTmWnxJ6iXzaSMMWmFujVWTJeJj6Ftykgl7NFAbKoujs9rE0ZSLz Rh4APBvxCityhZBWX5HdBbpWzxHxKKGqJ0pHlmasqdzAZgTNsNqSezzBBGuw jE10XsGMzPgyvknV2TbHwjdH7zfxwYW2Fgw6BVSulU3/nHOtukcQQS96b+GE cZXNEGfeX/A2sxM0VyV7+uDJLlUGw8wHJWYzpe3MMctESZkI92UVL3gVXkKw /RdH1XZyD6taVIjUmC+xo/kpt/eKaWHRGVuHiFYAVy2jjZjjSr1qamTSrmrO e/D65NVp8urhjyfHtJgdnCH5Q/Jg58Huk23MYdaWqWLwiHJVAAQePXxs6rJF MtoaRMGfzC0mlBkkb/ErSWqN1xMTW89chlgiQfHpTULBp7sPH2E+DDpta1AX ND5bTOjKUjpE5UVrvdUtnuR0yIaKuIHU9eZD8e542vIgAJiw4EeP5pNAXQLt o/zNBgqYL83T+WIPd+mHfLqYSvSceQIxjmdMcxlGFrruicwSKl//o2neOd/u dIyMQSX9RZaVzcaCOx78HzzknI7u9Ck5MSb+ZPJPCph5vnl3cJLs+28fbzi9 9xb81N9/sy1X6aunu199+iQFAG10gclpCbCcUBAEPxiFlbtfP/8Kz/PUVb3S 91MqSlG1Jp1XnFhWVS2mJlenCgRxtdoKsw9YLGEqJgN1gQpp5V1CUGAS0rDs M7MVk1S9bZh5kBwXPPvcUN9pOs6kQvhFcSXFEtWIlJ1UzT1I/ghHb/30G8HA rmd1USwmmOr30tSkY744zK4LenzC2snQbuMv+8cvk+fY4DXlw0FE+l8wzAEO U21IXtYnD77+GsGKBZyBSp0Cphw952iIbHQJf245dHk4eGAuLB/xtiSlIQ5s JIwOjwCfd+dBEIicuA7hMVlXbSZXdiJwjHvvF8+jqpjjYDmV8Q1sERKqWHfX 2yPfuXD6ozN6E2Xpqpa7wGIYbUg9lPYs/1bTWLGgMsnA3Y93lHleyxK/bMr5 7pnuKNe8nuTuk8y3jq5XrzwifG7inCEcb/YDxKwU6bI2q+zmtv5D6knCe8lJ 1w005S3MdZciF8T0q2g5i2KW+bmYQ9l7Be59J14ocf+TlEBntrP8jrMDCIWY sQeIjTBjrYV+6XzDNx0+P+J7a/9nfsS/E/fEG72AS6cyS71gbDFfFTWS2L8t 0nFbz6arbzN9gzfT8qfo1qeHzqfbtd6fV3955icHWHTfWsy7njv1QvpLn2Nv YplvWdmKb7G3e4W93fvrDc3yS+3Rqxujb2qJvq2BdyVv6pv6Ud/Gg/qf30La YIbGREp8dGUbqW8vpL5tisfeMjuWKd6DhpUdysNEpqkhJuv0TFG5MXg44VYS nG8KQY6IbbQ2ysl+9Dxw8/XKHYjHLlm1qA95opKcXl2kU/IWDhxlYdBaJsAm FG1f2WwDppoymnGNTk9B+bhWkk4v0ksuKj5MR+/HBeyZsrxvaYPR7uBrazL4 CnVH6ulafGV+ffzVY1ERYxYLKVEvUrJvVahGF9mUTRjDzCZNMFZb2p6VcGMJ X4PhmEkoWVayuOLwhQGuWBSqPVbr/RHelSBUilKIrS93RXv+6uv7Tz994r+/ fvT1I4EGtXkobb5+8PixFGRYTZK3hx2I8iJ5cg4DFj1tCgO+APxTp+xpenyW Pb21/9vLnnfyBHdbAdYQV/robz4Lo5+F0c/CaPIbF0Z/XTnST2kVsjUjRTJL vKEYyZ3/8XKkNif7kgOvkAU4Z8eNyFvrC1wCbyN28UxO7uLc9SS9yPuKDaJS Dx0yiH5rsGFM47wEmbHZHTvT21GMuNub3kyPv6p8xTuJCFgsX2EWKElels+V cIXfd4pW0vyzZOWt/bNk9RtxbrqNcPZZzPpNiFmfBaV/DUHpplJOyGFsgquj NbwJQ5mFYp7vSGAJy7tGvHnG7GHFSS4zOyVsgawq6Fyw++irh+iTgNs6xuD8 l1xQlFxN4MvZufE02b3/5D62tIu0a3Lvs8zVKdMhs3Wb6JD5eqRakCmliDkT cG2uBO2JSXW5hQOaZTz96vETEGzwFZd9zH7+2Uyi62J+Fgc+iwO/GXHgTiz5 68sUSSdn8Udt5Sz27zU5i9dvfeLtVtfFWYKGay4uWX1xli00aI3hC0T0bqj7 /pJar1EtO1lJclzU4qhF+zA+f8auzkRXhrLke9ioqBZohp2qIU2kNEK3hFkR Ks0uzQg5X3PZXFKXcZQdqRtcZr28mm3WsJxrdkiGqWiaYDjyq0FHePQQ2qqo XrMtvm3eVHjP2+YxIHkzF75Y7ST7eF9yKi5PWS9w/68x9y2wQvTH2Xqz/3rb uKyk09XSckPDZlpurEkdScQN41Oq/drPw21r831OKqwu+A1q7f76WYWXZnEV Fno2XjEqSJzdoiJC0i6ztFXxFECumbzB7b0RDb1ix5ZcduqP9UOt7OAXxWSM RMDJYVFjevKZkd4VIw3geSd5iDXhtB4N+6/X4cZNP/dG+vsXz/kB3LFt+CqS g01oLXNv8UrYn7kcZqWEyTSKCaAjAg6pohyagRQ+R+3IriTulv54EZfp1min lQbUnqFv8bZVnIYJm8lv2MzcM5YKjA+FUYZpZutTjF2x/Ri5JXbaQfYI0ssk r9CLf1ytI2X46+Vc04J0Jst0NlqNP1PjkD8bDI4x6ZRir2AhFDYokzpu/ZlJ +9f8X4FJr5Zq3RhwyVBI1XAVR3dft9R2U4bfiL3XNqMdMwlvKeAULsMcfVSc 2JIfG8bgRCyttnKVaRjl2Jape207uDstP1zhEs6uSky1L8buzLZtNUn7n2WW 6NWYlqYmNn2oIRJr6ZFRGlSp2APUVTAUTqiRAmdEhSDmJKzMxYWIxugqo8CF P8M4L51plGqCXwPJxNgKWwQlm5jhrEWSHiOB9en8kOo2+JNJBKYplQ7zmfJJ rst2QjGLl8X7zCYzVQPaqARU9YK6MCA2ViOqPePZU13gtA1TmqbXFDh3dAL9 ObBE5XgUWFWR1am6R5YF8diS1vLK1jcIQtE2Talvv167z5eGV40n0M8M5d+L oawkM/MP03ohcn2g6riuQJXmWb8u+oALQ5Dcr/JxfeFnap8NiwWI9IC53+kB nJpqusExIX5ez9VJJYFVmH/nH2KqRtB+KyjTmTQ4EdDyUaHK8CUxHgQtYHHw v14FvqTBgmxrifnwK5O2ts9LBebHj5Z3GFbrdcjWnSFbd4b5ujPMV5mBjqhA c138gJIAhB1DJQHwVmmarT5qtvqo89VHnbeN6m7fiG7fvO32AUH5fP2WtP98 /T5fv3jT7uv3t8J/GYR/t9wx+EULR8GUjTZYGZn/imO7Z+3kr1TviMLT7Mxy NQgqbc+CtmU6wrThfZG/+5g1RDdS7SbRPba0adljeAJujy5bd2SjLrHTlZ/P yRLFddWkhiyt65rGnuPQhAcCUyRk3qgjr9/9QPap4XWdVTvWg5NE/c24JEVV QTfjdB5mArC0daQfQ5OdyGKO5rtMHclWPshAd0JT2qRIdRubMaah5tQFn12Q XqnO8CnMLK5t5eHiDKvqWt1i3rY2b3qTUsSTbM2qZW177CnbBfjW9TulV3I+ gH61qEzw1gGQgxwDfGGDLvfTW7Rebh0cvZWaqYcf8F71mk0OqYkgx0mWvo8M cwJtBryBMjO5+DftAvvIVzmLEulVhKk6089/HPWfD/KsPusX8yq9Ou/XWVoJ HUM9heKigKY0chOYvGV/Kk7N5WQzLmjg1y47B+N0hHS0Drh/8GrpgL0vEsqe 8prs7RUqyGRmf5alJZy80ZS3NmhnQ/oWDScb27qf0aT5Z7bdG8O+WPIpLxXC L8jPRPFzT58+QJOuvHY/eEL/4mC7VcD6f+2H3jx6vz948/wweXb48uj49NuE qF24/u937+9+1b//oH//6wH22ejJOoN2yc89fkjpmweKB4MH38B3qP1Wc9CZ k41FCSoZdNsjO06192E62ZtVe/T8EoINu3IWpMR9+w3ennxKSZaoAz7O9RlY P/f4olEX/P4b+iJkSBsAuAThuEd3BdbpkuK8w4F2EhvYSIv4FEzpmK4/pfu+ Y2I8sr1kvzm1y8djKDaeqthomkzqx5PjKro6q/j7i7Nfd6ztAD5L1rZvTSnJ gZhS2lZhUEIvgU6wdf4/w2cvnJbzcfAlq5guukU04WJWtdkH3E/79lZSTqZt WSv8T1Gep7P8787UvHF0+O5F8ubkdP+nl8mW86EQl4lZek42Hw7S/QmYN5K1 l0jfeFTi1SNe0QYM8VM23IM/f39R1/Nq79495NV1mY7eZyVd0gGs4N7V+T2+ q/e+5a1Ax1dAk6Dn76dpPqmLPf79e9Pl2x43PBzndVHiDK+LC7hgY6DHi1E6 TvMyBIoZacoNB0PT8PuixAfQASCGTI8hrjzq23x0AQJP8rYYZmXdkKnMmGXJ v3//18UsB5gN4No1xnqDRY2Sl8Xs7+kk+zsQteR5XrQOWWDrwbm0HmdjaPt9 nU2yswJz20VXe5pO8b3yWVqeL/JJ28hVRc0GQ272v8/zMp2Mi+9nxfs8Pu6z Ivlp0TbcBJBicLUYFt9fLNKrLKcRCBfQUlvmc4dbRN4JsYV2upe3c3RjzUf2 V7loVHnH+jdIAkghhJihytl9B4IRB8X8uqQkiFuj7QSJdkIo/a4E4cSVCYLu lPLNVapK5ShS2rZ9kBzBWgbJ/mSS0KiYHYqSao3NhG/haNAJY7hgX6XZmKzO mI6sWGDBLfwGi82XxEqnQFgpbr0QDMV/YC402LQN9dmhJGjoBkwizHxRVgtM SFoXzOWqxfCvmdwyI2dNAAhUiAi6VVZmRqbJss7b7DJHg/6z0+dwuagt98dn BlgYLAnW7ILZRzYmyIJvs0peZefpBF192eJcGRhMpJRRwc2fF6MF0gn5fctc /xqHyTJ39WXVfczQuW1A2nzfD/Amd9nokGJ++PDhmwTfCmC5siD4FshfNjkj NDpbwPlNaOmzooYpq8EG8dAy430kjrsLtQ6RF0njLK9zSpXGnQYbvxEqfu+e pNCsUZ4j2UC0SYvgjFdsOWrd4DNMO2i7Ul5JrzvCW+7ewM1uO3BGTrT78AxD N5y3gG9aAdw2Gw01RidyniM2O+ocv+zcOEPrzOgx82sAgFQrxJx2SLAa9guu gcxRZpoR1hwsgXNEViIS67pYZybEfrFhyYkWmIHeopqqdWuH0i825lVeAnOt qnXH/En6xcacpOfrDvcKk4rsn5+XQKwI/iRbJVuv9l9ux6YQltjnmBE+3ot8 5oFGmcfco904JwJbX7cuZT+hgThTJ/nYuDlMqjvDkTF5sqFfucpoJ4/B51kB X33IgZ9dR7dRXc9G/fnF9dqoAn0qfMBm9wka56IsjEjbOlWm4eNN3gqOU2iV GAxKtvCfh9utLODo3Q/9d8nLwdeo55z6q5K1ni1mI5atiUXRg/Rs5N4J9SfY l7uKJMx4MPDYAmpyIGRR/kzcqlkn8upRWVSV6N4Vtq+lseAptBUo0aFMsvTM fQXqTAoSw8Y9p5TuybVtfqW/QTVYgPapDdQuJzmnqS5UdtJUljfw9vk2W1BW SGtqoQ1Zuwt6GNDV0InAu7AMJFHTRycPN8eNsOAUkQYatFD2xf1GvmqODGOf 8M0wNVxpAhwoWp9ziGmR53AoOw4p+EKJzPfw5clJcvz2dXL05kC0s/HhhC74 wAMyLdi4B667ZpOte0tyM5MEihbeetsl5UZmdM9xSG/iEXnvrTnrAXZaaXhQ Eep00kdJff3zoL4k5a82Gborrj/NKfWKTMDHzlBqVmR1x86jopsN3IVz66QC C19geVd2A7KVQS/SS/XwQEuuYufCnVshZ7+j246JgpPN/9zv/z//9fPup02z 30+dhyjLi+zcre/wA1pwJfnu0embZP/VyR/3+7use6llf/IuddQBpf1WH6hG xo8KrpEdhbMzaOKSsGHUjW7hkZ/1z7KUPH82urnrhgETZm7YcEMRr9noxJlX YpVVuxvYHnJ+3nDquOif6klJ/bSGUKCPN0mmqEBvAHptSQr+Phr++wXQddCz tkaLEih0vbW9k2xoHva7ZGNTB0AwK+CZsk3yBAvb32Z8zNom9tPN7e0Nb+NZ WcJoU8A1IJTJxhvM6m1Yk0mE7k4uyohpPo1vBJWhSwLsjkjDLnbAyOjMZBrJ 6OyUGOxGNOO5B7E6Lc+zWm2yZaJ3ZMmwU1BdBbbup+eY8lwCrOQhQO+ci5Po XY0uCqogQVP3zyZYdtwDc3wNeAW5p3l0o6HZBpRr7irTsKznjSw3kjv+HBwQ 3TB2YcvH3lBdi6KFmavW3KzMirfNDN2YOMoGVpt55aOJISOaQPLRAhPDM0SO njeX/qnX9q9PIbDTyaRvVK8A6iQ+wM+k+bU0EjBk07mmH8thsAIEYGpWOptg MGvhuueKZ6+8ZT707h1H2/xjNixLmbK0Z5Lzm6fX1XZv/vrks1ZHV4xs2sFP 32IOzuzS1La5TPMJSeD2YdqNQRfeKI8uWM0cnfZJ1vtQLNg8LJsDoLtOArhU AlqNlbolza0BQ8OsKde33O0WMus/ppsc8vHz+aTnlF00OLhXxnPN6YNKSBot 7tuEEzbffrO8PAqR5AYNnRVWxTxbyOL59eP7X+Nj4tgzHu2fwmwnXPceQNjc Ph6NVYXc/u0Ja85DNUGSM5CSs6XA0KUGzAO3w1KLCXpr9OQc0xW/idwXfV18 ghi5LBhsrNobDmg4PL2g1/mU1PLQmzqxgVe2wgD3U9UFYsUFTO/zSTEEFUeK ELWMVfFgBhpcFMo6TxfA92bs7Y4w4zZuO12SeMuNbJV83HnQGqJDe4pMTvIX waNBHbqpAkWAI71VLhANmeu2JGGfO3fEEMrizwqP2McIokZCWZma9cYL1GOY 1xZfDwomtRE4vyipZJipmJZADGpbIuGN0gjkz3kxwwcpZuXe6RbzPheCqm+8 F6kpKMP4UTlSGpAf/cyDeuo9z9ZZOuX3oKuLfHRBoStsBTAFvqRgCiaAkGNK I7BgawL2lqQLO/KKKlEyiqR5uGZNvMNFPkH3vh0mBztJVo9akEAUJxBC8Xb6 OiYBr2EGxEZLYem77fHo/vZUdNIOm8P0XliYWG5GD/fTV4SkP0nPQU0kY9d6 m7oRh4JFJTxbRNdjo5OxUI/SObGvcFUcV3jDddiruMPigFQgBHJPiaowMzis D8PE82rqWd014KMGeEoD6VWk1NQl0f2PCy4F5mby+uZnZl20qWWAMpnRlwHq HwMSP2+7AogAQQ/iwcN0XBMagXWItrQxGNwLwfWHTdzhphKJlhuSIq8neiHt JglJ+NJ8wWhAzFQk87Ov0ieEYIt4beJXrXDnHhRuRvIDMuXi+q0oa2fost+4 uNcin61gx6EHMGX+KbgKQe0cMLMPQMf8aQUIztelP7z2zrHzkJc9IYfH3WH/ cUDDwn8er+f959ojJ25J087gHJOp5mDEjpoPAds9AARWRLYjKupu3/IjJsp2 I+W6szRdBzYDm2WXKYEtmBR4OyK2kIenTMGnzk9grdMShCKz4Oy9SU7YHEzk UN/1wXxaLWMdu3LlYK3oI2fNhZ2JHIjUPMwmxey8at9e06axOnhfFU6PJSlV vUeYz1Kd0V9QDJHJpeMXQmPxivlnR+KmYe/GKByzEjK39ByIzOeOEJjOuOCz rpp4HIzwT4zWSkEMgXmHaM0TrI9mVn4aN3GMx2wHeQsmtCIfZQjIpinmsbN6 tUorlFdGNbRViC4yf9WGPd6zRlWOcAF1rV+cUTAM1ziN8UpPAlr7fbDhrOSD YwWhTii0uABZz5mitL5WLaoYqMMV7A/PK1hxYGpvWcRPiGd+IdhcWRtMNsGc SmJmaZUP84kO0EfAX2Sj98b2QGI5DEfuvJUtk8S+uXjBSW9pXmSTYqJbgY5J ovp92VnhpJivqcvreobyeoika2mDqsZnpDiwpWdBGJreN6aKYjS/9qycHXo3 B0XErAj8y14zeYXb/g036ovwNvWTwRE8Zo6FE2ebTnvTEltpo5XJ3cHZr5xB 81Pvk0QjHR4/P/1WRSrZSKv9gzDKimEUjbCCn+4ousqvib1qrFWyP6kKm1vG zNzjDGKgp5ATeXMJTx4+erBepBbDoDtKS4Xj3DZCS0CO3YK4nt5vMRDptx2s BWwBby7AauovbwbfdCwMsWQvORYf1AOpGM+yzT7FPZrSLrzU6OT/gNA5m4fK n9F+3bVluH+NsIKwfj3P2fsc3vU5vOs3Et7VGdbleHtiElN5oV0m4OVziNe/ b4gXhlP9e8d4fQkcWIRUcdSvlrv1J1/e0579XVK0wKTL179VFq/sTyPz13p+ /m4VaKGZRUiC96SKb38GlKC8czySbFkFBthtm9R2d71ZP2OeMln8zg1w54Aw eXqb++xKvLlsx3btduHd6QjNZtVOL9NJPu7btxZn6og1jqzVdTCNrB/nDSDX zCcZgVg0Zc9vDVR6kXcJI51AJAKbFfK0/9Yg1b5k1y/S7RYg1ImzIyDsyJf0 m4Ndc613imxu/A6AtZY++q1BK1zonYLK1N9sh5NK/XprOHVlkY3sPJz6l7pZ ysIYAOHel5FPJAQwibW716OAQY7xM2YLlzPWDxvUCWn7Q+rSKjmajZgxbf5Y kgHjGZvNaZyBTl2U+d+NQ64+i8YiL5WtOp0W0GK6mNT5fIKmQWtldQ9EANJ0 Xi0m/itRS7iW9lA1E3sDBJ6Rt4k78sZd96Xh0NuV7zna9LMYF/WDvzU8YNqe onC0nURHFVH/8Lmp9eXHvWjyW5+UKFBvI3V6fk6KG2AEHH7w7AO6zybPuFY0 0btg0IZrszM/0+jt4PpbPrsNtLD7rwosmnAtWFmXzT/lsz/pIg/tMMNJfJDZ wAkgKC9Q/VyHntwVJcF3iiBclF858aFA04x/F8rgexZnn+nEL0cn5mWOJXOv +7LO9QDXFcYZjPwLgjQJg+s2w7nXAu5JAJJVoBxM+Jku3wFdtnGqQHSNKNlJ 4d6pLLGabFpBVGxPNrfJUHkMiH8BEvmUfRnZOxO6vNr98eSYqjxeS4WHa2rm OptZ6wXMOrEJzeyOla/Pbp8bNbbUHmJs5etgGpXNxYsNOyI3zCJwypLyGdI3 r8i5IS99L83gYBqrbSA2kv3JLmCo2gcxD/oy9B8i3AsCO/LxN6sgs88T+EgM CNOqKkY5hUSR1T71+yZHcJjnJf3+VhQz5MPPynx8jv/YOnr7bDt+z5txlst8 P27q+bFqIorbenfEfTsaMDT5YpX2ZwQl1ryOTtqEJK+Ex6pK17A5aIR4qKIs 88tHUZjrohnQZqMTmFhL1WUOiBGr4EbgkI3daQXZW+HjFVb4eOkKH6+7wscd K/Sk3RXPcPnp/bOdm6JK6eKcjPPmSWBifSbxRt7jitumgF9W3Qtz8FiK0Gq6 DDwcWzY9PAtTHnAaieU2XL9XhwPlSUFhnWzM43ETO65vpjGflZx098fjatUh YwT1t3ZnPmPHbwo7RAp8uK4U+HB9KVCLd3aUFaS6h7eW6h7+glJdTJtfLWZI iYJ2izcLHMomcBAsvDU36jLmcNG2ToywGeOcjZ2MKxQB7jGxsBAYe6q2MjOT Y6IMBpZEC5Krzy2vCdYOkIYGksbaNFg7M3IZD+1wmUF6MNxM8MbhyBLF16sc O9GJ3vqPGGFIfd6IzWx9+/lm2W14q18OEMrBA4pUKMRzaPM4v4WxKs/WtlCR L+AOuUHhf1E5LOqLcG0aXU+JVdiNkZD97MXzQOpCsYZ5Slmf97FRnwqQt+Gs 7zJpeR66+ICIlFTNSc02DD1G9BGCLI7+sCrr109oRMuapMhcyM1xHfGNMA36 JrPsQ92/KObdOGfu4Kv9Y3GqzCovBKdbwlOwyzBtnYewq7Dgldjv+qy3zdS0 Hstt8Vdv90QPcOvxHeLW47vDrcfr4dbjfwhuPf6MWw3cAqqWPHt5YoMZPHwb ns/7syw/vxgWZV/8J3W6kWi+YtubyKMpKaAeTPC4RoKXLKXhAsy+zXweh/ZL sAe8GtMzga4rPy4xvGQylq7UbjwfCSU2K1oO5oKSVBfaNK1q17oBjDslfo5k LGavnMPJj4KiUDETAYX3K5+mpZJfIxPYRFFp1Vx+JKUo1fK9G2ipoHq1Hlo9 ZUxTFYozQLAhEASVOIFC4gGappi8t9QATRHZKAMXu/NpdAsNENh0mn4I6U08 b24k4xP0pdrOkkoXzp+OXOiJOm0sbsYRMS07EYBHFiPw5nqxS2+6bxrtXp9Z lpbOIyvs6d+Pau5V2fLRMCjG/0/T2bUb2VbzGmX4mqFHoPpiaeN64qc1Gdmj 3a8pZuVZUWLY5EvY4FV6jV7NLO0/SrZgxf1H217yGPcxTtJPBruD3YhcFsUh 9CtHmXGkImVXiQ5bSjU/ddPGX4swGvu4imL1aKWS6VfOLa0H68qSFZ6+fwiU j6eNZawCQbGwhwb5XwGayvxOQ5ERXbI6GhLoQbllqXf6dhALpPxV3hOWkuxb nzS2+wcet4fv+I7UigBmgFZE+KWuW3nD+9aAavw4XEW0tbQGgGnzPcBx7SX5 Bv1xKUJDRC3p7rgqyvnuB8VVYykpW5iqURaCSSyaOIMQCUxeIqzquqqzadKP nAzhhVobVQ5of4CNyDVKqLF4FJfZLFq1yG3tu2/Kb7zJJVKcz4itSNcu/8Sz qbRIaJ3LvY2khp9VpDUL7pbFtUhtXeu+A+kNP8skOPzcXorDT4ckh59o0eTk jiQ6/MSlOvzEUpmsKOEFz/t48y3NX8tiqomGGSHy6hSnvVG25mkKUZoWdRTH D0dBDQb34P8UBVN/3wtI4XK/s4tML4L4Iee7JO3UAg3FCetP0GKw/RexmHjG kDenJy/i1pCimp91803TbdTKP3H0tvS+OLx66Y/9vIJu06K34NaOTvtHp/G9 5VVe3XZvNHzL5mj89s3Rz7fb3NujFiMW7OO2O8OxxUbqyX7CSPtn6TSfBMV1 VntC8kdY6e3IMZurC6rBRs8EO2TQta8YlsfTwLln1CjNU4yksnXXO6pTI/xu dzQ/vn3bcjaXZXnrw8HROwOEn371+Mle8mNe1guQf/BFDGD2NhsvZuN0NlLM awuH2m4yrh8lQvohiSX0KIM6AwL8nwMb1OEHaKGwQbJydeJC+yGzQ5l98rN6 WfQxdy1/skDHa7zsek8R4ZPszXj/qq/Hra+oK+Yv/YF0C60MGrm37WE4MPJH X8eV+cBJ42qF6G+gV7G66zIKPDLlLT2Y7fnkldYp9QZbRQd8vYGVLNf/VlJj fUjFVNnO7a2u0hK6tKq1+Imptl2Tr6/ihrRtdS037BkqvfhZW/GNSfxNf3uU fAL0vU1QAwlSd4/FWrLzd9aBxriW2+BxOOkSkTIGXRS97hC6JMndPXQ92dID bwd0cS23gW5j0iVCbQy8MOEdQhdlsbsHLoi3A/9+vyiMHCE547IJaoOLqcnL hxKxSRyza54n10Z/WO9tziciluOnSxjDzypOc0uFMn+PKwU93Excx0+HyK7X 0cQ+lK/vEP1IXL97/MN/++K5v/12WX1tjMMd3AbltLKBn39lXAsUAr2Klsjb 1cT/5YL/Zxmf/7uOjC+uXHd32Y2v1J1fd9/pzMe+JixWMGm2X1d/qrjIP0qr UToGEDkPtmxF4d/3QkOzensVQDrLNufQWMOop98qRL+p7d0GDf5VdT4Cs7yE totvn3WP9XQPYyP/19U3fn2Fw9jmPysZvyElg1lzvoR8fJa/f2H5m8sMyitC +6veoUtDyKFonlyqsiBKoFqrhHrQ8FBoy3Bog97CJ9G4Z4xflLt9UInXtwnS mg+ufq2tWIQiV3HoSFP5zSp49dbPFGaLY3StPSK2UC0tW4Arvhv7e5izW+3H /rRn//KrAnYZcc34WOlugrZPVCVojNW0H379qLLRAjOItOk/6DYgTZY9gewf uODXyLDRLEIG6gY0LdfQtexWlHxU3z9w63AjBErSbev92Xp6XAEPGEOZniEI 1O5EQVMx7+okdfBk8gY14Ku8wpKbFHg5zqtAo/W8GbjsXUitgTCbbf1B1rUi 4ZUsKmMO+KTR1D5cJb04EZVLCtywbFYWwu95vbuBRaHjrUARwWIER1lh8WHJ R9IeE+ymengnUz0MpACWA2xx1KMTQDNVenVswmNtWETY3RR4sUG4MfT0d7Vm 9ipGDNgL+8n4h8ictYFTYVR8k9xaaCo8M206Ue72a24gXucT8zo8Tzhyg6N+ EyGZs/FVPq4v2qjl0DZYkRvbDk3qiGVt5lm/LvqjrB8O3B6oNqPSM/3hVTel fBFq/hSJtkmZ5ZGK1yDusZArI7pjc2uRdE5AZwvMgHY1mxTpWP1uzAuub+jP beJuO8Pg7IAAD11YKsRXhNiIIDZfA2IgPN41yMyQS2G2mEcg5nphw4NDA6OT wxtByOf3MG87p1/C4F+apoy5EUeHaN5xz/3IK/y9svP5klLovvUzRItY8sS2 mAfmT/101I0K6ydaNCxesQIMP+vMt2iK6TWTycY3Gkue07nRhytvdFmiHWsC XHGpoYF4iRP+UiN7YHfumLlIp6vNhUjl6tzsJPvjaT7Dah5ShYML32Dsyiz1 PI+33uy/3nbVl0MTgDJ6nmmxcyWn03blUzGVZy+ed/n2nwV5Ahtk1MjMnWBa UdpX3seeGtFCwVfJtKJnHkY4chjnWC9C4T50lQeaArLYxvAaJJHlwDaX/vW7 H1qeP+yqPCrcc49OXVR4Rfr7y5Jay6UGXKBkygVKiJzNMo6djTjdUxqVpLoo FhOudLPZVThk06fYrqhfkCk82ERbBvMl+1olS/i/OPP4p2Ab/wiGcResYv/1 b4jmyzWimBxPBQ7fm9sn0J56L56bwYLKws13Zvq01j7uUMDxji5aH57VEtr1 /iVBacvD0roTlUXTCgilXH19LXkh7mCBxiR4ywXGE8T9onnfGsVQYotrl2Mi v8YSiNCAhoZ+ln1kib+s7OMloS6q5bQPGi1fBtYf8qIr4m4Sqv7Rit4RqrBR +wRCXtXowV0hIis/bdzoQjQKLKm52++oHHG0NlVAh7sIsQ+GWAo0/nxqrmsM YkqYy1KtrN2rDD+hZ5nehx043MendfaFgYRuibAzE0WYaYhHTaTN2VbxA0+p mGxfQl91IsD2tUaMl0FNWuLLW/sHr7bjeJ+OJmviPYy1Mt6r0e8a71F9eHVz xO+qmrUW/r9olJxa8Rq04YQ2xJ2ASD/jcqMHFzkoSvsHDUvcBcg+aTm6MIxo qSF57gYdyaBO46m0XshIyO29uunrVk2PMihXGz01a4KVkCaD+T5mFxnwQQ7U 4JybDnhHM0Lh7ENNb/4YBXsNyig+oquUnXPGFlSLXFev3HqFCuz+wY63AooZ pswASl3FwqLlNDVPDKMyU8ncTc3MkT0jh2xFQrWK7QJhAjVWm1pLI90K5Ctn V9HHYPGBTqHMyKliMcd6tA5Aes0dtbLQ4CUaJyNfW62snifadFZUW4rilTsM KrVmM4N6VohmHtdAJExHliqMzkgv+dSLCGC/8iJjBg9VGs2iylqOwibXTGDk 0Jla7spX+EiG5DBbo22EEyvqqWmnZPugJvTifJFWCaYbogERXngXJc2EjKn7 q0whqTLPXgLpKKaeJ4QW97E4/N44O0sXkxpUmdl1/wqJUhMjIiVc2/GArkYz G0ikRrUFAW6/zqdUfLfA5F4p0TZbFQSz53HGvc10tAkHdYn5i9P3FgZzzJcx JsQqLjOeELBvgTaVYAjTJWKRq2RoDyXDGrU+InoRf1FUJNO43IuJoKW7Esay VV2kaNeianTuYO1NUmXp7HWOa0/zSTrKeFMKkt3Wm5wc9UB1c12COk/sqqWK C8VmCYm9c/25kQXWfxPX1lj77iiEnHwIMipaXqlroYAWDYiOZpKTM1/3lE90 vUFYZqdVuhM8a1KdGwDJL9ekoyU8lxo14w0Xt29ykCDu6+FMIq/WuaFL3SdC GMycTef19ZKJN37iCpA6cWeu4ER0QJKuJaB6V/kwn6iSkAm6/2Ug1QjQBskx ci6uVM8SF2IQl51H8lYtQHcCYUANYBxbWowDS5DQWMiKSQMvOnNqq8QP0FUZ e1ZHIxN8JPVndPbSH46PdpJj/J+sHsUPru+CpKt03r8xM30zy9AtYFqUnPAm Od0/sbmRLEXvWoNHs/s+tIy0GZQ0X47PjRLZ+H61LJOvVWFCY5g5Kuuhywuy KKAFIn8DRJTMT95jkGfRjknJrZt7m2Eq9UokDOI6MqhiU55+4RcKsJkV7Zo0 eq4ZS6fHaTODrhBJpyUwWoFkwX71UCqKHWf1VVG+T04neZgzS5KXbPtabjzB FqcqeXT/CabX+sv+8Us7MD0avib3eKQUNpFKEv/sO54h1oAtxPztHZt466uN 2LX2gB8r+tV8g1gBfH6qReRqFppIs9JGnjFqcg7ihFSUYEeVquGZohfv0f3W zJw3z83ZAoAb3Y2b5uhsZumMcb6GXPep96n3+4M3zw+Tw+Pnp9/2/q/99Hpf IEawwR0UrwrnYweNXo8yilaCL5i0GtEPSfhZLaJxDWx0Akcs+x1y4j30zP7Z 4NnDwdd4nN8d9Z8P8qw+68+yGgbql2ejJ4/ufz3Mq0+fBjgXHAf9LgXZQIPf IOsLf8s6/QZfCui/QKl3TM+FyTh8UIcBerAiOkkbM40GP/jnZZ7SIPhyAP+c prP0nCRQ96S5w4w4JfHm+PDdwZvjF7Cj7+ByPt599ODTJ1rX28NT/cuT+4/u w05QBaky9QR9kV5mklIR3+9Tft/I0N4xqxAbxEtTKMrp6R9lwEe7X+1++rST vHt1aqZ49OgxfpOyI9yffjg6kF+e3r8Pk2/TumRCmm26oHgOP3MTpxQ8JYSv ktc/nL7DABtGKCfhkQ41yTNjGyKKO2F4MjBxFJwQQJjPF4QG5tJKLTpyGR/4 vr2miRUrpwtM01fUvHAemg8Nx6jugfSNCFSQNGF6scqHSGMIpB8uEth3mXBu He8fvN4GkP0HAvMhniSOItdM8jZyYnaS0+Cmj2qzIrEJAhBhq6VFi4Jup8UF AHpZmViITCVgqRZDYYbpBA7kMs0n5GzQMo6NzCmswxSbItGeN6v5CN+RTQ8P J1V5Juk2zIqxvR8mGSbgg3d77FWBoVBfx/XcI5Md/YV3nf5KtvJBBqgplA5d kXfEzs9xQz0ieKT9bw8SuQFqGeLIPRLygtDI4E8yKwBULxcTzLUrhkRYawUn nMzkXLPZZV4WM7yhFQz+ExoWNFTk3mTjnHRIWOG2QUzagdeYBQ5/dZK1GEE+ p0K6ptQFDoPGJe/ykOzImApLPGfbSHZ2Bl3Q0dqs2s1JiCrWwxGc/TV7tJ4V mMMTLxlgRl1mGZ+vWhdN4jCuZ2AG/59V9wzQUOHIyTpBwzZJKJ/2HiHMZlTd 3tzD30DiEFXzPUDh6qIgtWbIpiZzK5Eh2CUSKGB4YUUE9RruzHBRs5Eun51N FsTZMD2p4vmImRM0Fgg5sdfa0jZTPmFMAxlp5xXZa/bPAVxEsbdOX+1vA0Uv JgbWtEve/h1si1eS6W0VZ7bQ5myMR7kAdnEBmgR8g7tEakUC7iKf1ANewdEM fQdy4+XoljMity74J2qjtKDxmPDqylFQvlyEyNmHnOlyMcvgLuiN4RUDCaTA eKXZecapBYyq3hPZZccqZRwKQ/KGUZApNQRtlrOLIK5XoL4C9mDUoyE4vyzi Gi7vIW23sdscMwkrygfLVC9OnRJiaA6tlV9QDIaK5ER4OuPnDc6IbBE1ZGMB VqGd1bFFFtQapEYIoUE/xTitW1UBCgSAZQefT2Uk910RBtYBlUEgDgwIRPRg m2BKaU+ZA5ChZKPFTmuiTbGKNKXm+Pk/rLRWzKv06rxfZ2klojIcEklsdDRd Fv62C+hAtQxIPYajgpP1QrFFIQU4RsyT0D33KhDHjmpFyBiYyH7T0S9GVRjt /v/2vqytjSRb8J3v6/8Qgx+AMikjYVwublf1YIzd3GtjxriWnr7V9SVSAtkW SrVSAtOGeZ/fNX9s4pwT+5KLhG1cRd6+LpQZe5w4W5xFUDO++eva8GPdt7rD yMpceoeX53xhJnk65MIdYEx4hYs2PJmNkJAJVaIthQOAQyMmjEudd4o3fHCs AVtkJwWFg+HY1kK2jM2F2mBTkCgWWsnIuY4Brp8BCGGuxWMmoKkIP1HHTFAq RsDhyHlgLrh0hMOVsbVhYHJHxeaABHGaTdfhH8FyrAtEzdlYdXOzFoLuzp1h BSyl8cq68QIvhFdwDCsyS2rwMANITzIOxNkFpjC6SPtXXHAe4iWJeRWcHgOD pdoiNya8kZaYx9Qz00kF41WAyInU1gnw5Yj4eV72h0VJKwZcqNGV6TRILIiS n9H3SmiOXOX2l6Rv3k5YJsYr5BixYpn0LrIbkncXyypXiu7fU7FWal1Yk9U2 OHvZgMIT7kon2lNtApIfjhCg4iwfCyxLeC2ReK12stg8UMXidJKO+eQAM0o6 LPl5wIq83Aw4teGVuCH0ksryQy5w7TqfqGxC7bUWb6AHgeQscPsnCAJcri9O +Bs7ulE6uAByXWaEfoQUzt9xCd0Ar9WV49MxgAGEUYH/QugP+O8kH0tg8H3h V9ZgJZG2oCWCEHK73357c0PU0BZjxrPJuCgBIbGdEjd2XbrRSTadgJRkMrQy kXpQoS7qW+oicKzmwyoR2KCSVgFtAQzo4UCXnFVd90k/eN6DRgQ98HGPsg+Q IZezq7jepJEhDRyerJ2j3f19RvBIW4NqD94dluclzjjHNuAYl5NDURGaoBrs kojUCf85YKdorDJBnTgkgSvGV8QcKBMYJWML4ptQg6zgmArpyV+LS9hPqT+S 3YgMcLl0BUeUQJdnMrKJdmI0Vj8DDrSfwoxy1YpYI52ZSEM0iQrG3imSJfRH T77burlZ45D38SPfRTCi5cBRGpYtglU2PHclAnG9KAT2kPwWIRB000dgE0oe JPUP2P7OwY6nXQTuAd4Ld31xqQiKl1Mu5ggFo8bGP77d18h0VC4Deqaikyth 1CAZq+X9vXcv2C+vX7G3osCyOA+bT54+vbnheBd1n7w4b3Wbn5gJ5I6dnmzj LMvtD+fD7VG5fcVFqW2HiqKWhloFTgFtVfrTbYK9/b2jl8gW8b75q4NHO/9h S2LQn8jRBMMDhF+OuUhOyKDhYIiIfKqBkFa45eZYHJrcJHz5WiGRA+jD3jba lCcbvQ0Oh4ZhClU9VCC3zGSVjt46aI/PLbA/0lKCzgjM4y+8uBoDzLP9ph9i iLdtxlxYENp7/gUub37hz5I7PL1jtzQ03aAalgkVgSHRtiZJwsWK/ns4lHsk ypbs4wMh1ZY3rs5fC9EjjguyD2ccGSGbLQ1QZE0kfsPhDM2FiCILRGxeaAgd vaWWBCGp6M+AJqJKQ7SoLoaIPgC6Qf3GMYAd3B1yHPTx474olMD1GEqlplCh BneccTjFAQ3hvuCScwloFwr6PkEov/2uh/UfPGC7SAj4nA+4sPKM9DCwRgmZ Mwq44GtljBYvrMRJYXwjy/QULjkHVyhLyAaFUgdW+Ky4FBcldqs3AsLZP8ti tPTxT3xDXUZ+W2jGl7cZfucl6A1/8fc/CWbjo/yDCauTbbacUmqa/lnBKf8o OeasAyr4l9eNwsbNFdTZkYMWM7XK2iKDHo/4rMOI876gMXciRKzgrnndqkjv 3fbUB6jAW9vd++2X34723+399rdls9yN/nFjjhZUYKFRoEqMS4iqEdHAr/Af /vcNHZ6P2+yBtVcML0S+X94zYeC12PtnYu8DwLQMoCO1lIbzptCmj/zkg0IY HSoruLwU29LhAARiqIQeBKzShH4JmpwnHcGNkAWbwooY7FsCfSG+54wY6Whf 7r2TEL79FcFoeTXqJ+Mz3k46Bp0Ar4A3GL9fMDYLu0AGFQEHJt2tJ1F4h/9q mNfgFQT4txKyLMhXjLPAn4omAfAfFNOMqdzHCjQRvzv2VUd899jh2ZX2BEV4 VTywexwsBI4aNVRp8T/3pPJcYXSIz0HLg4r1eRB6mWNhoxulow/ieuhSXBLL Avr6n5JtcUoo76zfj6Ai/F2I1VQ6EqGbU4otlZWSHZHooZtVieBIWh6sM5IJ NPdmYgvrIv/jR4/q3WCUFdQG0I0sXZiuEquAcnP2gS4hBhC2JSlOMHIMKuZy jBA35uOYppz92zncL9di9C5qxG/ilLRfi0/6j7eeblViDwKTUWD3rGqKDwYX yAmgieXeRm8z6fb4/95tbG1vbPD/dTY2/rdVzVLmeLiF71A6LmekAglgCuuw G3ZNg2La/ZeNLmzc0+jgG0gmTvMAZhuRurfitFSeOzj/dA5samUdMWye6I3A DTKNoRFgWdMpAC9xH21ZbK30LyCccz5YESrvFE8YmYWoANxKvEFh9euARS7p zdLh3QHEdac0vfVagXbS0yTWVj+B/XIbAwIt9pFX2trasD/ffLZD0IDhsyki PxM7CG785e5PECd8/znAv0uiSGPyX4jtD4WRKtGnUSFJlDSFraBSQcK0bkR7 lU1zQoOkZd2nTvg+GYNNFtztIGlVd552I9qgb2z6GzqGfiN29ILo3eq0GBfD 4hSuPtbUZQDJakDpX1QQQJPU6YPvXMniYAW1A396cHEjg2NQ4IrRcDF2kJ1j XJBJ0c8GM7raImlzmotNgcFgvMFhMRvA8PGuWBUZQAHR0ymoX6CboD4Zad70 zIjPJqZxR1ANgR6ts9zaBlRvqw7ZGJbb5lBpjCeJ4X+Y5GPjKP7a6ChKKJ2D LAlXRHnMFDmSTXJkUVqESVEeix4p/lZFkhHXIvmU/KAFMGAZfgKs3W642eZe y62O7/RcG11JUcKbHN3j6i3WO2y04JGkSorUiiBF6NE85KiaGtnEaCn0t22h /OsSGeSGABqgbw4qY1GTAIRzggOOELt76+zdZYE2Sh8fwA0AZ+8LTg65LHo+ G05zDpCgA3yVgbG1ut/xtAmc/hwUg+wZW93dW1NKBAoDMLwyLm8F5hbX5xOM Kq7ip5wXx+AFB+rIs3Q2ZKtlloHEAVdBx3BNESBAYvBg2QJBs6gLZZgPwxQD IxFngBwUP4VAfMneSVqEAgX4kddkh3wzMy2GpGl5cbrUScynw7zHLkCllq6t Itd+rWt2uOe+cmo9lM2l/a746yFj3e96nY1Or9O1aonJ2n0hn9HFV72Nje72 4Pjp9nY32JdbqxcedHyEPT3CulrB1WhQ6zlCVV2tFWsnVjCAPbDO1bX8d01G eKdq2ROn2WvMQmcpiFB29xIOi/wwLTfiKOlysowcN5uN5KcUEElSoiIvI32H PsZ2egeRnEfEVqIs1HSdfiJTVYH7pUk/v7cfdvDm3d42W/nvlYB2H+4/QLfP nErfL906Ge5W0OCUneSTcmqgZ7xQRkIMe7T8WYiiJSg1lpOWAnWWLWsUd5CQ 4Mgfm0xrlg4l729TXsMXh1Ie/Xc9+Fc9or/4rCG90t0cZnDJvYB97rK7BRym jPncDymguz6LE4UjxMYy+4iVpcTifX71eZ/1qrPTqzw7JThSDO4Pz/3haTLM 3+PhCQsODqFtJQ1LOUBk0jiCE/UqH71nqwfFlJeCMWcjzmGvkYjs9OWJyQvo bz+5KqRbpQepJ813TodqCKDd21eGmvP1MNWfHBzwODBNK14onhEpvXhzpLyJ yTAbnU7PeNHNDbeEbubv7jp4C2MgIHU4A2XUdW9giL1lt8KN/eLXihWWOLFu PQy5rHZFnjz+QiuiB9lyTSKgFMTA1vKFULDdkX8UorNqioUrzo8xLX1DoDoK o5peNaqp5WTuMq7p3eOaUPF7XLPwitzjmiCuiV6BBJix+bXG7TjBd4YumHQ+ Md5Q2KsXHP2B8X1aohG7tCg9T0dXTEasmaKRZyfQFGBF6VCo+M2U4vnwgY3T /lRrq0CfdMLfFJP832C0OhyKKxqrl8W4TTuGWx3vSdew1ixa4Ph7LCrK3GPR Jityj0WrsOj6FxEYvehh0HkQLfx6p3m/Sjnzy/LJv5clrmSv/SVuzh2Ya3Br OqJBBmmgock1smfX8XzSK0WSwTcc4m8Lv2+wMceNuSL71InwVTet3SDfHjrM 65B4wDuYZkqDAVLrIIsg7powfrRwWpR8gA77AIaAfIeHRamC4xjhXUMjWNX5 P9DGVTmJQgTDRW1YF+cpFkF2m9VHcXqWTxY5idaxqhq7HjYWvXPnc/P2xd96 Tr8C1hsd5R0j6oJvoz4MH2Y0UBR2EodOQOTXYCdCpoWGEQnEuuIVMV7quVlC JtsiC1vhYoIgpPCFinoHbyEB6Lppl4tmdtMUY94Iy5FSNF2ylfGEyxaTqxVl D0826RAfB78THYESlm8ZBMOQZvLUi2cIqQNBB00h5cW0H8wSp7FCRyEfCIdt tEbWTa4YcUHQ/WYKo+WMhQjYIU1kMBfiAB3JadRZSgFiV8XEwapezdGxYWF1 TweNVrzXnP3ZZrJ9RoYJtiVCwPglSR4e7nV5sY42l0GLBjoKv/xP2Niuag3+ lXYkK6GxraAhw/XunlM4YIojJ7JiNHVNE+lt69UJTSRgPYET6QUsL2gif3Mm EhpOYCLqPMvDkfbl8d0ZSU9M9o4MZK9krnXj7O2BdSGF7oIT+gXvS3YUbOzs +tjfxfguXpbnIigDLOsTErgxFN3GfKRaEI8QerbgNIijF+Fodww4/MzLpjr+ pAv3t4qFixM3E802I2cyEDgYOOqqFBcOGRRh0aRN7C2C9UxiavV2d0+SMXk0 OZ0t8cpTWGonAulr9ZNFSKABFdYYg7pq+0fIyeJn6HYswKPYOohm7Ueh7w7h Rn52g5Zk7nMNRTeZTQOu+Vy6EtEGTPrcRxfd3duUqHAlcdFw7Uh0vdAqOG3I cJ9WEW8VwpaMgabT/mPmrMLuXo/NuQqPP9kqBCmV/RhUxoFcebTk2ik6I87a ModdqpAO89PR98v9DOB4mUyBV6RXhgBz0zrQdJu4SCd5MSvJTFCno1BMlX+c XM9jFXPo40d1GAGtgDZ5kI3z/tTzbG5geiDtkz+hCcJcAlx7ffDXoPe5bW3b C9S1ARTMJ2ouJGWG6F0/6yYClG+dTTgitdfRXZptb5HZVuoW3qFm4U5t7eYi k31c7W5Foumdmu7jyulG+TYbOTe+eVRUI8SZHYc4M8HJPQPd3OjUTGqwK7NH kfYQAz5ZORi0bqKEnzKyjXl1WWK412DYLbhaHFKcNuGrAm+NuDXLIj2Dk5YB ymIKh63Hm854RAxjiESlY+FjWFUZFR+pI442GR3nCUT74YTP8CVLEXooGofV KCdfiCch0Bc1gBi8i3ST/PkF5RwNkmmR8P8od8qpZAbSkl1mQlXKZc2zjFJ/ YRjgYpyV20tLCSXYkjUgJUA6yNhsjKT4smAEEKvLJAxQ+H74u7e8tu4yx+AZ mbJ3Kgy+XC7hu7N/+Oj14asjOc41VOCQkyjnBYbFlYjdyjcDtSK4NOi0Ocik Jnf/EMJN8RY6fOg7bOuliiT9Wof9h0G+sea7evT6zRqxDMhD5BBKVG4vdY41 +aSPXpRKwQNQis4qRk4BBH28TmQv+ZAu0ysZTX13bw1HFQTeXe3cvnpwtLsm w/xzsCK+qX5kfqsQdXdSlAQJ3rpD7KQXMmhwZH1DIgss6us3zH2o+6Nd7wOV 17jJ5Y5X3x0Y21FM1pzv1/GqdR+w6p+JW8d/f5Bf/qy1P/IP+xu+/kF2fSR0 QPrxwdh6oEIPagsJxX0cUc8voSSU66MX3XpfKr8Er0darRU+lxV3JM6wQt+w 3pLR+rXZj/Uj9g37l0v88OXPStgk5aFR/XCvp7+9/Jl+8H/kBvzDbPYfbof6 5z+MH/9YMj4qAe3aWBLxyJ/XTBe8Nitb3UTW3nxZVdkR7FZilV/tHHS9ysHH +MQr9Za63z3tbHU7XXDgfdR73KB6b2Ozs9HpdjexQlDHWdXAYhUOz65KCBFA N437z7ervjlducrm2LfekmZmTHoZ0MkiAvcE5x9FvNfniCkFeiVDeaO9nkd/ RfgDO1RARrpdICLp6H2pAv4E6EKKl+JpeiRC6bXQ+O8csSdbW5tPBEJ79vIQ cBy9BS/mCGZiBnKqUL5beEma5mw82txw8ID89Bg/MYWXglgJfz+k3+oPo1dm YCUDJykv2U5Pox788ES839LogvcdxEgmUrLQkYGQTIwk0YwQndVv/4NzcSAx ET+f4rdARvKPHn0g1VDoMBv923+wRkfZGIfQI8WKlINxV/3Vs4tpCsqhyvhh /PrBrmFw88wBc+ObXUew/aQ1gBd7r589++3HQ+dbb3lpiX0jSuk0CRxdJMyV hLZtrAFFxFZtw57A7909effPVjmMrG1rf2wOxlDiUJXQ33rim/BF3pauru4W cj7YmqT29YZrT3Hrwef4G2IWObFe44n9TaA8c2K90MR6xsS2Kib2xJ0YxyVM mMzxYoRlVg+lunvn6GDNAymMHSFKb22wVXUbHCw9yc6LaZZ4I9liq7sqIhp9 XAti9p7E7K8EAn5zAYJAdmnibAh+UOXSZN5K257RKggISLIUHI3ESoGpZ8Ps a/dg3lW6BfQBRwLL/4bVhWNi1mwTKK1Cf1Gp+Wyl+IzoPV21Z4NYILYy1NSF 1rqE2heMS4GKX6tfaHAud8HhUkxZGo569eh7ABRAB56W/XTAYRjQB5n4Zu4c 9Mj43hgFvanEpqQaANhCm2aLNHgjVuVH2YdpclaMHVvtiuYTDt1Q2qUny8E6 N4G3v3rv3FI30eNxm/7gPibqKUzUu8dETTGRYAvuMdHnwETHp+M4GuIfwzho lOWnZ8fFJIJPwtgkOjjxWXBey9tS8PMe//C7R7/VQV+S7y3fdcVySc6syY3B W4PPcji3Bg7pE8P3yQpn3eJq+G5yXI3DgX5lSK4q9BrKZhEo/FLcWNSPqueu SsCNKohOA0c/gCg8j6EAP1PhQtV1mQD7fJun/+6i2HtmTzf/h2T2/ohIsHcL SPC2GcEoEnxyp5Hg1u8BCd5dPjNSSqoNl6Xe8Ivzo/M40++T75jU+yG3amV1 Q25VsatgCTyHptEx+rDdTkDzSOUGQgNpqTU77M1Iet3B8TdS70ovFjs9XeZ0 JoYT4YZt6xVhS7MdfGvwx+Ww4N+yBHLEQpY588R4Hy3gtNEQAuKwuEyg3Kh/ petYKNAhLa+KS1hfUQesKC7TyYAC7p+lFzk/Dx7wEDiJU79szSvM6tPYaCl/ fPvq1S6nxRXk7rkyXXl3IDYArDuwZmLXDKxP3RogDzTDVTYRVzkYe7iKv2uK nuBWyEc2JB8lgsr7aAWFH+etfaxv1hv27jLXzXrv1fQ+PxKB491GqnXP9VvT NdbAH+SVNxLJTFP2Uz4Bjif/NweXPZ3YmL2djTDlMxpD7UIEe6YuY5RVHEa2 d63iVj9+xPcqRyuYkK3VGsvZiWS1tRr1vT86maTldDLj/NlECN9Rnwg7Uux5 +l5cnOtkNWiLjgcGLNK64k7Y8D8W9mOvKby0urrP0nPwloNUAKNsskZZyNmF sYa5PdBJfBk7vD+0ygQ/yr5peIWmWZyvAbt23iSkOFaOs5RbU+wae532z3Lw U7T6kV8PIX/vNDP3lbIoGH2BMYBtaoY+is40IKkC7wky/4gEPNQyJN8x7PTd rKL2hLepaQ6vfKmItvGfkNRZZvgDE0E1BJXQT2/QO1KqaKsHAdtoQLmL/gbW ULUthIaW4xRAjPct7Oy08oWtjqVpiGZX12SmYzQZlCnOMTtuMeGTgkVHI8QR LAakmkV/8OACdBj6tqp6lANVdbXORzkb5fxkWyLLvsqFsQyD0HndYOsmGd+f kdgVPFiH++6CSZjGc1Jiml0jFQa68MKFppk70znwas1wxGKMeuBmug5hmCht VNBc8yTlFBuMMS3vdxw+sZngdOraoDRwXAo/5IPTwF8GHmeiz3eFVUXD6v6j qpNxiflvq+rXP73uXsO/Pfx3k79yjzWNPVyd7D7Mf1v1DnYuPfx3C//t9qhA heWIVT1Rpi3i34eRzYr07g2s41piVQ7efDqy95oNiFS/lst8DRYKv+0cHUgh o1l1CVpYnZ0PtrbdItW9M/byZ/HH8ujqw8He29/6W+Vg9GTj6cmL/zXc3Nzs DpZj1Vfk3Gu2v2rl2T9Yp9eketC77Jr/X90TtxXivfO2RfT+fcPyG5AOfdQv fgObFF0TlpseabBC9xTd3ubjZOvJt0+/czqSf2rDsypbp+sqv21ordONo7Hr 5KJ2VUJobP8k2englkpgluyewmCSVYltadDaNDCDaPXDva5zFrY2WlRfqHcC sVpcdlso/AtWb+CqGTtMOs+sw4WHDVPfGuyYyG2ipQPCfehKhjdlTpNgm6oT NpciRxUJL8hpaOZC+hcEWCzJxXns8QnlCM9Li9cw+TAZLsORBNatXF/56IKz J8UEfU1m4wEyT8hPB9LnAoMtWr1IhzPlHxpkyFzLWWVHNt+DC7Bku5HQ83z/ 7d7uO7Z/8G7v7e6bgwP+Y//NAXvz9vne2/2Dl2yVs33Sx0EuoIee2oLSD0tu E8Yi7Ao1Ea6jxa4+39Yo1rsr+HN9t/YTR7LO8+ELl5RFlXm5sSYGzbHAl7PA 8R6sDEgc66oeJIrfV3D9owHUhjm7b8xpDAQOJG/10b7k0NkykJflKP5Q5o/7 8sQL7eShc+IxO2/2YbqOEhEM9WQIsr8Q8fNRLvLfHV9x4fsbFFIcPlxiC74G J/npTPQFloxH02zMVjfXWHpcXGQdUf0oogrQYpG2dxfqATM0kFQ8cOmH9/hP GUCHZO7BIIdffEdFldKUhzL2avPoNVv96fCAmYuwBnqCoPOeUHisbr1kZ1fH k3wgJq+FchCHPFyb9m/DrtRJKucsu6kMWv3p9dpXbIaaJM9+eZc8303Udc1P h7vJSVE0vid01oY3Bzve1uCoH8ICd9m8rNXlX7f3eNPF9PcmYH+8q7nNJ1/q ys3Dkm2U5vLOy+F7g/xokAHmwFhnMmZlp/dtxBTFQk2ybV3Ghzu5kg12mJnx nhMwBz9BOlrFhHNqBn2/fr7F0hl/wfnVvmbx+SKkx8O8PMOM2lxO1mcUnMF+ QJJKqF7qdEtsC5zKUuRuhleQkBGAciAXEsO4DId8ctAkkEgjoTsG7eRo2Bl1 uWZOC7ooZycnkN9RLVCZ9WcT0PVeZun7EV+LDLJElhytlzK//JFAsD2YM7g4 P+lugds6aBiNr52u+v7dFhdd7slY86eWjP0RDWeq8rZ+CdJZFYHdLukazfQe f0GjGe8S9d5oJjKsmsGJzw5lbmQ0E7WtsclHxJwRS2YjTlQyGNp0MsuiloXv syvYinNONiZ5OqxokRc+H2wlvEL/LM0RtUU14JEmQlaJ4bdfhlkx7YSq82xg UBiPgWnDvBhX/1pRpW62zzjwnp4h6abrfX5iEw63vCJleRXALURCKAc3rYzA n5V9vv2TvJB2P2D6nn3Am10MwMLFY4pxwitd8hFx/kFK3HhtO57kpdLYlSJW rg7SRoHbJL1XCyjK39yQwm93T6WHhutohXOKS7ghHWRoOcSF/WExOtVBw3eO 2OrO0QEdFs6PQCxGqI7iByhpSFTOBqdKGSgHsFIqRcPq4d46iPyK0O7x8ms4 ZWDGxkXOOYBpkeAfxrUoDELxY7isJVyQAieGbFi84gQXES6iU61VJUrDVkWk 6O7m8hr0MMHoKxa/GQwgGb10jVyexTJYe9cR+MQiqvjg6KZwtkrTg1CZ7Ow6 r82SupGOM5frwJVWpyuvbWm6ABNWI3j3sfrT2xfd7hoLX2iW6fgBX3SIgYlD EjeFViP2XOD3M9y07+WW0RfvriM4kt6abIRZ/uQN1iQ0ksATTA4dGMmIRqI/ WRVX6NPOUfAet2qn7L560Fev26Qv69Hwu/CnmhGewwjPG6xG9IrHuMJxMV1c BeuctyOBj2W2JcPKRYghhKnhbgUktRmIVSk72jk0jTkQc5zQH9bljUJDOsv2 9MwyCTnmA8kywuLg/y/CW+3uEVoLjkdkdZKpFgzNqzQn4dUm+fFsSnhThkWp 6hsCimWjQbnOtCyKeepzCJhyTisIo7OsUzpsZ1gW6wEd9CCbpvmwlJTAQNjC 0EyI3pjcAMPyqSogIGfpAL5iEDipWoXlnrj98MJ8Iyjmu+QSjYjvn9ChTCJW U1RTpFQVki8eP/12q0IW3Rlhxg6xISnbPcTFTjlMmLWQZeXIk0QIkxVeFihV c3i/LiYk3Sl/gYWdpu6IHlhxG59XPoP4Q0e84jBLdvp9WNtPLK8hnOKpjnp2 6SLtnbrk6cLcUInRUlSaaiTrGXB6kp7nw6vQguBpaSwuBVy7AqC/iHgrsOqD rW9jcq4d0KWJY5u9OU2X2bB4jy/veT5KasuZbXkbQG3wUXwdsiwmlfHoTGKc qzaa+IAgizHxC4zRbzM3y9LiXAmdcFd0WdryDa96nnI+JUWTaDCyhr4xSqwp APqpZODWF4yS6d5UEumTGedKpJ2JRao7KFm71mlw8YzvOOfGsl/6Z+mIL8Eh CHElW93/5bBcE4I2wB/vRU1K2rkYdjVoNV8gaxE0noeVy50BjGcTMEUGMbIQ Jtr5OXE00rJahGQvMSYsGKJzpm8QGzUOes3hUuRa/bsozsn8nA+TlzMtzMtx 1uct9/lIXvFWZ3YkeCnyhzIfUHDXV+kV35UeJOXMh/n0SjfDWTTZVmr2KJUP l2g5X2ZDtBenhFM4SuDF2HgI/KvBK1oKiAM5LjstA6UgAq2FeYeiuwB+UHRT CmNwK5gsXaPD7mmuGtYLblbAYQjTlIFSAsuNlS2U0LdI94jsg9gaedRcbhYF /vQYF4y/GBWzUV+EItYzLqwZ74yulDYDYoJB3FTbCAViJPOxksWEGizrD3O0 nifLb2newT8YiyFtE8C0wfLOIJ+MUlyT9WeTEpbR2EwZNdlUAM3A+WQCDmlH ArjgRmqdLp2M06EMNmD/+IIN4HYKFZ/DK2miz2fUYX8tLrMLsBs7FlGiTUUM LbjIdgUIJB9dFMOLjC7scMigAZtmY8cezJAUpSS5o2PZehERQ9+EPkWrUa51 9GFcGBLbYVsi31RVEEbfyH3dYdeOKdYPxteqb89cMTlktPys94ztPjoKGzTr H0tCLP6HEIrdZ0V+jH0TNSXNqjS6rP54O00cmoaP7tP4422MRUDQhQlg+ulU fDRrEvSxnaNnb7FZuuYU+ip4rhV6Fh+tb2ZVC2hIe/aMjiv+/ZC9EPjd/+gA jRXYtmpd6qDPGlHHewAHHBEOcD89jDd07V4Kf39d8dEZkakT8mF+peKjrV9a WhIncJs9S/vvQX98zP/LdhFVPzpC+qN5OcKnx5Jhe6vw8HONh+vTvLyzXOzK 2bFgZQDZZ8heXNl0GswCOcrl/IOFboVFHnmlDRSPAe60xLPx5vozTmHKK450 gegJgwShNwJMXAqti3CfS8GUuENDJPn1kctEla4LotbKu6yVoqCXheZf5DCJ OKD5NJJLZA8fcJZ3OgGnNI9RfCWsnGQGqUk2TTiJQmsT2BVRL5HWUGUohVQa jFSkmGzZiMEIu3NSzZN+TqU0VEo5zSCDlEpanBEqyXkHJ/kQbLVh/hShWDYW SYkjdAigq1Jll3UyHGouGyTHWlQ1qtjaKJklRr5drssVw3l5dGoE1sTKouEI 0/U5LIL700jsqQeH5TgECJsjwR26ucTCVkS+5ZFgQoVjqYSL9IKfGrjIrYCQ r3lTrWwnhbrVrkycJzuRe5P84uVB+g2EeMiryItRjhbZuKGztpPnrVd1GW+v jKbgmxNem99BNwPaBzptHjEDdPGrKtNLclDHKBKQ+BnV5ZilFTxkpaCr1tAV b0jgoiwj4P5Mkl5O1twSd0HCWgIwkG6s3Kzgu45DlBA45v+OpqDUlJfJAQyo hqN0n9o3+P0IGjf8UeAWVnnnyk5jZzma/Nk4IGIqxomiN7VHA09U0j8ruLw3 4qcvIYHNPiXyokkZ3Vr63TDka9U2Xk7rkYnP6iYpdubpSh6U53bqY3rvtqc+ CG07sJa/dX+TY/vtl9jJMI+arRA2xpLBKePU3EuDHTxGMehpF7JBHAUyqdCK rmSHc0KnADfqkEj+Stzv5yUdlBS0DqmZFZkgL20K7QR+EIog4AuVCx2LBGNg DdKpAf0mxwQ6KOT5+DQ5b8fZKzE4OjAkiN+D+Z0Bc7Nw6EpHr0Xyim537NRk WtltzQk0R0n4W6X2uxiD6rtpZsBWZ7IhgQMAVkdSureh8lgqmRSdk2SOEkBR 8KMR2T0fSSlG5IPFEnAvS7ZUO6WjygJ9ObIohi0TGutIVZwgs6WpLSw508aL kH5UoARMrE7kCPWHcHpFLKdGNj4x9/igOc9OXP9AwjAsBfgHa1f5azMhQyLz LHRZzNKHmiFtQgAWRVfuZDqqqihwjRqIZCchw5NvvgnMfOnam821aU4j890s XXvWMCvavVwMKmBGYk0p/DNmDeLI+Q1yhYumawrKdftGLZtfodPpaJ9R0HgA 6B39jN+k+RMUqulqxe6qwtvfnkJDQL0OAugzf7V9wPyWPgTLBQbkl3ONwB6K cp2eDo5xrYHwWQUQroSBkP8TODW9MCRCjciJefz4aXReUdjT2NXFUhKdHmFW SU8ekCmOJNfCsZF9b7TqI74kfKEIoaMUC85xOqfxaOBZzgDRlWTLYzVuBpqB sDOv3/24LtQVV6ZNUZlNp3hNoxwkT/SFB4YXEhaY4gZDCyMYHimbTExp2mef PqGJjp/DknUrzXUU3q411RH3d/yY51quY7/Ueyxu1Xh7VJj4pOXxJOkmyqgs bOtzR0xdQnxR0zvzhjDfSoiQuyZNu9U9HSmQvC6lcshyWlPaoZDqCDVEliex KY5L2z+D21cRK3+/R6AYhjxSx7PjYd5PRqO8xjXqKz4snysye9cOvtPOuar6 kN6uAeEX9Z2az4CwJZbSSKGJlpAwkompQpjpDegPpP8tXM+r65ZssG5ZDrj3 QpLYg9JDXMRIrw/pnsEPWt7PxxRMV1s4hG6ZjG6FPIWNSUUKR26h254OeyHQ Xpm+R617blhkr7Ohb+hide5MWMQiBKMEv7NOQEpEwgEvQwyTfz3k3gfx2sI8 Q9ou094YVg6C91HZ4WhtU1Ls8NGPClAEjZWUPDVjahxn/ZR0uOnUIhaoUeKE i8MNoILZSJjFDGbK0KrvxT3+glTkU1qu3mXfQqHFSATRTJ7dog2mE63724W8 GBvatd5J50ZeWNC6WHtUCGY15cfqwYOWpqH35qzNzVlbYNiWOn6tFCQdHdJH zZynl2mOKOQiHeYDBETzbtf0grQvd8XVE0WNz0oZGcK4ueLIVjTOdOPyfl+0 YnjdlDJMLh48cQOhlf3E6PNGDbpx90Mo1GP4Fpz8PTmoIQcCeixeXPBxGEv9 8dbTuD1/48RHqsY99bGK/dGpjz6+CqkuEhxK48yviIYFyEnzuy+DVO1IyvGT XgUpthlNY7R1vuhjKbmljDZFBNrEWyiT00czRHGVJQhVMSGaZMojyhTEEdGQ ggqxwK/keFDGtcYSGTqq4p2jA/6vEzFJ6YlX8xOlAltbZ9m035ER6c1uOSWe 5KenFOBxSpd56MtpuIwaunJhNo8GMHBLUK5VyztxGlRFfbxsIjbFaUlrAlQm Tl8iJK+epsxJTdrQkVYUpJZ21FGNeelFE0pRSyMaUocaulBHEbwEb8EUehG8 3gTzx3F+SNSoyTfXKDmMC6i77QH126dP3LxlVXC6ebtw+vQPDKcPHvwhINU3 F021P5rSOhrEM576ubXEDJuVDoeJilsDdKupQSnEFmQ7wyHbiY1XictG5iLM /cJboyBH8mbnhYjbK21vMNoS2WWNTkphsnMEOWYcV8sBP1wjy9cy5GTJxdZz LnqSXwJwRlYmGsEYkIsdXSSDzP4hMLrVgxflGkvQTTHlkvEE4+3yKmYeoYRp z0NOnIWLAzlPkMb1XTbsmxrpd5S3Z5qdCk5kCC5tfPFLGcain43RxnuZbKNg XSmMRr+YgX5BhfeA23IZcsOaZSlcSUtsekgJ4/gOlWcpGFlJXyCoT39vgqah mE36mRxhOubsCfBESsVxwpcpJ1fFdVbyPlP5A9qBGNLAAJLvJ9kT8AVk6H9o Z3Xq81FwuOcLChmVILNTwqg4ht3mb8kQG0M3q1xKsFGg8YewGuTGgYPgUAPu DORMOZiNBimGX+JDAZvljm4ackCBun6AunO457iiLEaq8DZYSE7A4XSUsdXl 0QmoxdbMBDgyVbRZps/LyG6M+jDcYoRurnSDYc4r5YAs/JXBt509dWa3uix+ Jxtd3Hv9+ylFihK5k9gZ5+YA5FF3zychR2IPFKOZa5BMjaU6Scsz1HnRZYZa DJWqClMwiSWLjvK7ZVwm9aK7oReFtpW0Q+Syo9qTp0LY0p2n7yl0mdChaX9c MB9BLp5/gr/pagYwaMZnLoKajkS8crCqzUCaIIf1DnsB1h+pldEKig/QTpTM yGGQKliOdZZULic42OIwmCmrXqd9NG7hiIFiXLC3RTFl+4/e6Djdwprm6G2y /+anNf9Wity6+4guIXUj7ISepk4xJi9whKZx3bST0eWNmzcjlRp0kg/TCWEM 4e6kouDbiduMELpknol5xm5uVCif0o0zZNaW4pYFK/J2dA2HaEKDFQ7ASWhm ZwZDPKA6HebwCbzbyZrSC1UkV094bEKwdBLiFJj+8kvCBd6/cViV12jBUYgT TPBD23A+G05zQMaX6RUHXymwcjn1RXo8yfvrEsk+kggWAs1x0MAbUIFjlYP/ oOBLBFd1AIOU55P84oS/ewrO+dosW2ffavBUJejqLHlhsvARtqrfq0au7aYs 277rJS9GGWMaf8EKd41GIoHNoBFdiUXTEVEtZQq34jXijiT0VDnlKm/nUA9+ I8aaGH82NQD118T8s10jxpoYf1632+JIB5Vb3IMt7hmNRNfE2OJe3RZH16TN FkfXpM0WR9ek2VNzdiLP3zudzq9uI9Gz02Yk0bPzieGkuwFwEg15aDeiK9XB SSSGZVtU4GQulY00hJNVA/G/5HwHUQVQPa413p2qXFJ+uiiDLrsZrBVRl/a9 FLIHhTDtKS6dI4BJ12814w60UzGNxSicb3TksPZ83pgrZtfStSIzp4QZEY2E /5gIemqQbhjpMpiXse7GxrIgy6pmPx1Dv2EJxjCCUXegwBRtS9N/tDgeZCcp p93slHaJ3BRnx5wTNQ2S2bgoKF4PLEUmWEUg9JjMgoyPhBTy7MVzEfVH8P7r ysvEVjlTUheDLedtYwhdycURK2rquqUyOiiYaF5d8DlTCgEjQv++eN65nZ3o iZ3g64m/c1pguQcWtywNo2DZVkcFTMZV9wfj267BWJd3z/IhJsBZVhFehJ8Z LJ4ad+mACckeeqwi25ARwkAsozSLlxqDKcakaix8gVTDT/UFReWBOMxTJd8Q 92ZIIXyuuqFvlx+ZIpwnYwudBca+ITmTRnTCeUAEeARTEHdR2pURtUopzQk1 EpQiMR1C9gjJzuShraxvfJBuctlAgtfw0yzta6fCv+UapSa+feFMm7pcVRt1 OLVJG0fGkYZVEuodPMAHf4UVxtNX2YYQs9WB5DChcIM4mHzBtz/5XBIz9Sv/ /0ebPTSXVFroW2ij16AN8En61HN5Wt9Gw/yMK3VuWIGB+4/ThgRvQIFEYPQ3 PD0Bvibko2XmOfWGID2bjEA3lkNWXTLdyA90ruqIBmRS3z8nCM7JD83buEZS BQmS1YiQFvNlseZttXHhtCFbdtro+W2EwpzTXFZom+sOGYbXfjbJQVRX+8dE AlslmzZoA57VV1z431xTw2+3L9AGhxzBpmzLNqx9oZMY3xfDO7K39Rjh59rY l16TfQnFFW+7L+E5ttuXyN6aAmWjNfXeRvhzR/4y2jDhoyfho/XeAnigsm9N jcPaW/LGrdzb0Fzk3j75mvY20obeWzeLd/M25sSFVhsmUqtd09ZtNF9TvR7f Vk/lD7ceT6un0nQ9jHCKELLaen6onIs+t9+FS3EE3Kte02u8S2pJK9025HTv yLmNLEaDNmL74m1M033p+tnP8eEbs9lgXxrRyngbcrqfYV9iLO/KkqlUm/NZ aiL5YZQCWjZ1cQoCu+ao5LSgXDq4AK3NvzNSugilSnf7AG0QZ2NZDuWzapyF 5UBs+/Hw+Q4YtVeV621scs6o291EznodRL3vHYnjGuMq/BBpxW3jqWrDlLWc vrpP/II9Va6B2OS09zTQ8ZNAue8C/X4ryzUQk2IKSGl+IFSQr8RPpXkUihdb yQiqR7gCBQ8zGfyYHAKvhkU6EFYAXKa+Ere5dK/6n0dvDiCEYQZxCUT/XLiG NxCaCzRpYzAsyPvZujZ9ONxnYJQBBiG8F7hwpYjS00LEQAbNl7hnU0YQbDXr nHbW2cu9dzo6sQoioEIsmjEbbdWdgGWpQQRlkFZXaY2MUGnZKrKg9pCUiodv jt6x7MN0kkoVJPSgtYMiwM2L52CdqjN2jgp0QLnIB6DYsBSMeBsrvUikk/jB C1PjqNUa4v6UN7fieruuSM2e1OGJO1VqWyrhrK7F3S/vTClYYetlQFERKov0 1o56fv9w57Wd3jswIFedq23xElJpvsrfow4bIk7wxYY07XSXzhFVAnHMwa1V qNrWIWxdLn1FB9qNh9zGlb6SJqknxCdpZMURylW+khgJT+k71yBNGLpvjiy7 B2kiTG2wVWVitM52xNTecpgdzhBwDmXp1Z23h2vs40dIorrxtPfk5obSnAtr 6ud52QejrStR5PHTJ10I4CESv4EqU2jaB3JXMaONyMv+V7CdDOiq9ZklsA/D EAAc2jtcSTMGXCQdR9+x1JBKUpGBFv2f1OLvCn36oTZzOclHIhqtVNYbcKCh USz1aQ7a3J3dR+KeyxnJiKz0DE1yCtExRymoWz+LV5UMy6/VtsJ0HNCeYVSO xv46Z6HODmXaPS4LfXIyyIRKUrZkVLAsw21He8r4QZlczopxcnwySGCTE9xk P74GGSnCL7SMvD13MYH9JSNWESsCFe0CzU4yYUoD1x7HJMYjoLzarMy0qy2D VvffPlsTFznoLI92Q0yh9jsV2sEM07BRkQNXb9tiEReE4jxo0r/lmiHXx2dw EXoWsuBVNtCA4YM+c+HsP7y0iOWAf4b90JYxFkhzvzW+rYPg7Dlk1FoS/9py g+5CNl1CsHEvR/oeNs3up2U/5ZQuASAlYAjuMI2MA5xRMOIcWZGyCeKY4I44 NwrxlE0jzmYBkmvirkgdJNP0FErLc6BaiFaKouMAnl3ERS6Eo80n4gT4iVez ovgfajVNrwDlW5JoKU3G8VhkzJo5u0sQ8PT3CgGBt4FUbLfg9RTwlfsqU+lR TAdQGWnt2ullFb61nafiKfVsJ6qII3mlO+KWl/menrZnpnquVdjwM8518y4l F+QQADrxOeIKbDTMLRiDu0Dd4HY3GP48YRE2opU+6/B7X2T1g8dt3uF//tUP D997N1dgAYP/L9Jzl+PnZM2XyoSbXuD4BbA9rRyQR4Bdst4IxbqrRJaB8u0i gCzHqXac8noAUjO93nzT851+7+b0xO4Fd+P2di9Y/DPuXtvptdy9zzq9OjHA ikr46eSBOQEtxMrfIqAFm/+MgNZ2ei0B7famZ/2uiSsq+6xRsPYWUrCirr4N qKpMCqmpXe3dYe1qr5l2tcGyp30CN/Cba6DcNsz1pwVfLV5T3bSwbkwzrVNu AFPg6dIbxycORfR1/P4CIbcbzb638Ox7X3T25BLXbPYm3tcrsKmGRO7e8v23 +v0i+B8z7eaDQaaCZjXbmKeLg+XGF92Zp3PDZX/uU7l7eFdO5Xfogvc7jbG9 sViU7UYAMB9iMgHgiyIm4YP5ewUAT/S+XQDgCLDbhCVqSJZ7jfe/90XIcpAw 9dSINF0yMGNvXrokhRpPLml0LntzbUv4WH6BbfGP5ZL5Xy+mk238FgziJE25 PP9PYXIFTpbKA5i9oIsTtAA6QjfDN7MppEErZ+cUPURcrWBcIsM/ksyA1Cou i1OyrGNmKB9iK4zNt8vSvuvgxSMy8Xoz6Z9lMjZ/h0k/ZNGQEetHm8+5gegx Nj4YxzkD4r1Z7pjggXmUjwKhXhwHyXVhGAiexSJt8Fk6HmcjlUcabMeUjSHa IJLJ0GUxGZTrMt6+YUCEgSfTUSlEJmVUyHvAKB/gxym2qR/aO9dzdq6gICxu x1uXJ8x8bsnPIO63VdeR/hz1h6Hwbt8bfgZB8+0k7vvFvzx/8/MBNmm14Zpv J1XjaDGXiF9OKx+08PulRkOQZWI+V6E24v5SgZZbjiPic9WyjYpxXPgfQ21E 9uWWfGo8f0smnL+YZYFe56vQ0N+SSrLz4oJQs25DLY7dRthXwXdJum0fks/n 60SkAiiFbsPaFxpK1b4EPJL0vnzbzIdEZANFCm62IbtptC86VoA1l1vclzqf q7gfStiTgC/RsH/uxjKB6JEiFoLPo/DpoStBPiKTaDTHFrE0wOB5kA0zSTrt GA/SqlmTZR31oQtcjf7VWxaBXHili2J4wWtz+SMbXkEcw9Ep2WwrQ24c3bgo SwzBIL1fhI26CmBBUT/A6jwthSW1DsoBRuYYSpE3oK1y10WYM51diezQMYSH zv7AmSowQpwWSYb5143ImOQr8NOhk4dRxS77+PEv+8nzDmpFi3GZXp6Cqe7w Q3nO/xmdJ6fDWQZpb4+G0OSRaNqsNc1SLrzBXzI7Rwllk9FxnlzxtcKkuRSO G021MZ4lJhQqQlPWoSdP4UjwaY+4tDml3csm5xgdxQhEaYS/oN8lsniFTGFl pIOXqfKsVcckmecYaQ99HCRbJzZeZj6CFaRQo2Arn2UDcVZhP/l7MNa2Qp0g lGO8PUQbCL5kmC5M+KFhCoUKun2ymcS8I9kH841KGMWXS3jXWBlHRHy83b1S crWE2VOPZcQwCtrJQIRY6bA9iEVCbCbneXf32HmaY+xTipwJo1eXUHoJ5+BH 3YSs1vPwTzoUVYd1NK9TibSu/4Q81u5el9kRo8SPh7FaEk/ZwZ2urf/QQz6c VCsyCJraQ9mhMc+HWMuYV8+sBf0Ab4NDhx8vf+7SJzWvnj+va6MF+P+/8x36 VdaKzkuoSyichDfC2LysvuRybIrVCPutidXA5QiuRqwv8d9r9fvlzz21GhZs bPi1HsrttlZDwMZGEDYUcLgjrISNyPCr5xWOVhavVXdS/rSEh5af1TOkBMYZ hbOPYVVlqKsTdLmjwK/9q21zKeUCfYBxdj6gxy1vKgHvRwB7dymc75tWgneN swLU3Ed9MlDOssR54E8TQnyAbc6FjuNYBKqmENBpeuTH2qII5lhimk5OMwjS 3D/LwTIU2Ahoc0TJ3R08K+iTRK4zdJPDbIlo+cOU2qVgJ2l/WkBgaEZ3iOQn JYNgadqRDSgS7f6UHJiwzb5iGkQCvrNskk8lUjUT+l2awa/+g3YVKGA+otyJ OcVJFjFv5X5HQm3duy2BnZSnalvAV4kswgxb4yrPJTHw0DXCnbrU/hpdhha4 behncyR1DVRoYYI+j2mKO+igGU3VoIMVPvGgzYuEfraJ/nPZd3GV/yIL0t1o f21020vS5tKJFPzrEpXUIA/7TtCxkJ/P9RGjOEavbDarnR9RFpPaUnMoFkaU lycmPvDwoPr462IopYXNWQChzH1D6G9N735rmm+Nay93m1sDGV2yuWw3QJqM rKJ9LWgtX+UhDRbohZe49X2ieJe0t2/pZ3PZNoBY+jUu0HymWbBInl1WH81q 1EsgagsZ5vKnlWFWH6+P5wHtja9y67rNr8l9WbLdVTmo0hAT+0KrCLOCITfE HOA2nb2YcZnv3STL2McHO7uYVQx+3ZDMRc/SeTGYDbNtZogYSyjqTy5ZteC0 JLUqvGRcdFqS2gYqyFdwcjWOiE3fsL/ng19VDdV6PoCfkLJmdOq096+ivJ2G moh18zRbTC7TycBYt8XaMxzpqxtjkcbEzpLGvH5jjYLV/VV0FpBYl4w6rszK GwaUInhVNRJ4x9xH9cTiY/6GSjoTUefZqWzhAvZRZ2ADqWDS40fk5i+qyrUB 1logNj+rEiAT/8UePK3l9IoPJVgFJWPni24vPU1km/GGVHEpTEPxGefVuk+C XY4neTHhLYG782k2WKxzcULzkTsJ1q4dVbysmwRrNl0qs8q3WkDF2l/8oW/D 9+mMg8JQFYuth1fSL8jCgFC5darOuMxmg+Iyn4Qb1mi4T1MWs97sVRc/SSdw NYeLNPIB1xzBxXhYfoq+v2nS9we+mcHvusgoT1T3tYPQ6wpOk3B/1nxD7Lpc 8BAiBEwkH2XTbf0qDFMX45ELR0zDEWjLnIkYCjT66oOyy6MY9R0MadwXGLhN JCOVsdd0QwauEwh+XIUeNyPoEUQw9tHJBXoTOHSwBqZg5haRwxcrffE4vtYA FbZGb7HGLCHQweTWA4D3NNiE1A+lQ5gkMhmIDWLjqsGsq047HhZjAugGV5x4 5v0A2BltybEhDISaMqB4NDs/zibh9swRUrmkOEnEENRWsDgGN/rJPlAqumhP TCF8L0BTRRXmbgjEXeJsh4jE9Gt1VVVbFNev/bNWUduK51RbpymsxnozokFF t9Z7mnUmAEgx/4Oz/rgGfqCIJJUEurUb7FVpMo2MA6Awlq0aOrY9yTgKi4yb iXErKFOj4RJOeOzm4gerVdRSFQVeNqhMda0WG4fzETGz1JkJTIU5Z4UfE63m DpyUQBXrjKgndliCCxcHXWYtQoOJm+1Hhb5oR/KJi4u+YBFpwqSHxyeDCN18 4tLNJ7dBN5/cJt2sbuyebmq8d083vzTdjMFqrLeF6GZ1Z/d0M1KFfXG6WbFx v2+6WTFxs/27TjdXh5th1Y7cQP69QrVjTtUrGRKlHdVOiAB56lsKlOqP3S2i 9KzOJJS21X6C8n5UBRmjlSwwGtQNB0dz7Q7I1VIH99asWKMEZAby5wcv1kow jKtfWK+fHcmVzw18LmVox8Asmd71am0G88bmqLDMAu4hfCzGU9sgaGnDHFUQ CpwG5DyDDXg6Ob/+OWQb6Ec4Ol/75jfQDIuEVqolFgk1UYlF/LGS514FREjM fZ6PktrCTrNqDePgH6hdcBAopwl5fkAT4NawPUghqg+4XeTn0UVgsgWw7Kwf rio+13DZYsPVklDboyqfagHKHWf8qBp/aHpZcVTZokeVLXhU2aJHlc15VI0/ 5j2qxh/NjiprcFTNYrVHVQ1irqNq1Z4X9vV464+qU3yu4bJ5hyuuIU7H1mZN pqcJfxfaMOMOhQL6+kUCpbyr4evQMPyb4tgZM2vJwLbGVRAc8rRMSBqvri2i 3RpHrE1tyfCfcFl/eFXNCDlVJ8XQYeoaV7U1RmrM4Qus4G4n5+mHKAZ09loX lUqMENKxVmU2PYOp9D1B1PxDFScfC+vu7LjgqxPC5k7V99kVsKvnHMIneTqs KK+qrBZoxeKJF05hJgSOtHAlDL/gtT2TJC2MudRPxWkkLRI+LX6G81H9GI2f vFKCtbbVX0kFKNnTPB9stZgnL/0FxhhUjgWLMwM+3FvZGggOtuER4Gq85LeB tlNFkg5PwUrj7Lx+0YynEi9IPoPiY8ekPDWQoGaiblZM0SZSz4Suq+tEF3xa 3lz7w7eDX7pIuwoBsjjynLeJ0gOLOtLB4lSnbQs+5ZEt1DAMMerTqnodCWGt 6QdrSjzMpttQDrNeLdlwxlRBM9S/rIpgmKXmoxbBFqpJhVNFPo1xsDe1MJEI jqyGQtz60Cpog93FHIQh1kBjqhBswCMJrPHZpVySGdojT6bVy9tKWDdbLsa3 1nAh8hve8niNZm9xsHUqo+b6omu7wTbal+uFNUVt1EQL6IgWVxBpIbF6C8FJ vPOI/8+QPY2/H4HwWNFNe0UIPgtoQfCpU4HQ4IpyfOIJ4PAyLoG3lDxFpUmW 2pdTtFXFFM78v2bpIFbTV0T5t9lWT/Ui4FzCXyuxr7nAR5SbjzlRhKdKyjAH ktRKQQZEtJd/7JE1FIEWE34WE3vmpG61qLc53p0X6S6Kyxqp+uZV8i2i3svL vPTQC7z8FOhFZsnFx3xzjyruUcU9qrjjqGKS+zcB/N1tI4r7I38Xjvz9of19 HNqLycQ/tfDSO7ZsnmPLKnfPbjW6e2zO3bPqtV8gc3Hju+cUbDm4OXZPiH3p udmgUK2eDBpKjSJEW1Dnrwr5Cv+YY9l8d4uqoq+ab1gxIocz/Ud7IVw1flYM B7DyGtUF2Rp2D+KfBsTLrD8Dv2QfznVAAQvc9euIu4TBEgRYAVUM3RppfhGj aHcYEqiCZ21VfPT4BCaIsLIGlwWD4Kwg3ipbAfo4fC/yQjXYG2bb8cGomamy UW7FfuqYFLnvts2t6u58OmtmzqRqQPiLcQbRiPtZcszh7DIfTM9s47DRcTHj AHh8aQCNORxVjSPL40s0p//VKaj6E99pUKGD4ZRfdVxRmAcafHH7hWFrzkJA wUvwwfF/LTNz5sGEKi0Uebb3TbR8PjF8vJ88rq9wXLarkLXtIWvbw7htD+Mm PeAWYbqN8Aa5S1jRlLt4TYpmzVvNmrc6bt7qONaqPn19PH3j2OkrZtP741dT /v743R+/cNHq4/evwtbc8t+RM2YEVCpjZ8UoA95/9FcY2i3enF6ZIZt8DsSv PMgnxK7HxEtVMu33QRjtF6PppBgmw7ycLoVaTPvD4BwjZSJzdHdAzzEQ9MmZ qKgyTPsZxUUqRpBtiu+eHpBEEfIL4hX5w0d+bnGF/iqXjKJRB1dplb4lJ8P0 opjYqFGV217NB2v+FzV8abZLEZ4cnMiMv43iiRNFKtRrOuTSJW53Vlb1D+UQ LajSAEXZ+diQJfyW6Vo40C7z26WyQkTQ7TpcMVwrmwyrOTkp+NrmGKpoTDjy qxVjo4uqao4lhTm9htWsrmoHmfZty+3q9THXRpU0AgjqnoMlp3w5kmJkWbOZ O1O94rGJVC94Ta3IejevZS53/QhDRnkeFlDF0fihTOHYfVO9sl60Viivwrc5 KE63ryI46uaZKqNPVzS+eaTlgoLWOw3fRstRtMVczKasIJz1UqXGnHZlA2nk GtuEQoWnw8n83fTXVp8Co9D1osg+VDgyaF3IM871p4dPG0Nctba1gfxUyXkC +anKzQP5mfsVCORHn1WJJoH8nCpGID/1RbdXFQPPLx6LbOd0GQzkN2/ngutT gfzUB9auHb2xdZNgzaYrGBU/kJ859HggP389IoH8zIIsDAiVW6fquIH8nEJq HJFgerHi4UB+wRHoQH632/c3TfrWgfyc77pIdSC/WLUmgfwq6zYI5KfqP3QD +TFvpm0C+ZmL2TCQH7O40rmwcPNAfub4KgP5mQvkXQFF9iASsMlpKhyQaM7G 5glI5DRRHZDIH1cNZo0FJGI2XLkBiczPRlvBgEROWQnFVkAiv4xqtXFAokg/ jkmBX4p5EoETkChYhbkbEgxIFKuqalcGJKqtHQhIVFGnKazGevMDElVUkU+z zh6qKyo/IJHfycOqgETBMQlmKBKQqHIa3t1beOh+QCKnHBPjrgpI5FdhHnD6 AYmCtVTFWECiWC35NNi4hxUBiZyltM5KKCCRv/T28aoNSBRrIBKQyC/e4niY 7deZ5fv15NPYKCDeRMTMgtl0Mx7IT7U8B918cpt0s7qxe7p5Tzft2l+SbsZg NdbbQnSzurN7uhmpwr443azYuN833ayYuNn+XaebgUB+zNrAWCA/5m1fJJAf Cy1LlSpL6tiDgfzMsVcF8jMnMakP5OcUbxTIz6lTFciPGUfJHlBNID+/Yo0S kBnIXwXy81upCORnFtbr1ySQn1NT7nq1NsMfm6PCMv91D6EdyK+iwWbRwWIN NI0OFqvfODpYrIFmWCS0Ui2xSKiJSizij9W0avXLMI25XfvcYGGn2bghbFXt xuaw0fEGLHaDZVXxuYbLFhuuloTaHlX5VAtQ7jjjR9X4IxzIr6LBuY4qW/Co skWPKpvzqBp/zHtUjT+aHVXW4KiaxWqPqnoz11G1as8L+3q89UfVKT7XcNm8 wxXXENWB/MwujTsUM5CfWSRQyjMHcdD6w8hNceyMmbWaBfKL1W4WyC9Wu4E/ VKxqg0B+NTOuc7aJVQ9FYfLLanYhGogpuioBP02/rCpe561ZUTXosxksr6o4 npuxwkwIHCouU0XBa3smFaGZmjTiR2eqriWfSg+LumnqGE1NhhgI0/QZxhhU jgWLMwM+Kh3UG7ZR6fHapI1IIL/qqvKpxAuSz/AD+Zml1EAaB/IL1G4RyM+p rRiCdjfX/vDbBfILNtEukF9VE80C+QVbaBXIL9hC80B+4YVsHMgvWL2OhLDW 9IM1JR5m020oh1mvlmw4Y6qgGUxDdwXBMEvNRy2CLVSTCqeKfBrjYG9qYSIR HFkNhbj1oVXQBruLOQhDrIHGVCHYQKNQCE59iQRDgfwiHbYS1oOB/BZvOBjI 71abvcXB1qmMmuuLru0G22hfrhfWFLVREy2gI1pcQeQF8gv20yaQX7Cb9ooQ fBbQguBTpwKhwdUG8mMBAGwleYpKDQP5+TWrA/kFeqoXAecS/lqJfc0FvofR UD3B4uZAklopaB4CFxlZQxFoMeFnMbFnTupWi3qb4915ke6iuKyRqm9eJd8i 6r3aQH7+6s2PXmoC+QVq3aOKe1RxjyqcUuzLoIqaQH7+2s2HKO6P/F048veH 9vdxaGsD+bkdtTu2rHL37Faju6f+brl7Vr32C2Qubnz3nIItB8faD06IfTKQ n7kyFYH8mL3tgUB+zNuz6kB+fvm2d4uqYsNAfn7FiBxu/NFeCFeNVwfy88vf g/jtgrgdyM9cnsaB/FiUJQiwAqpYVSC/8DDsQH7MPmtuID9mQ040kB+zwVlB fCiQHwuAPmsSyM8bTCSQHwsBdDSQH/NAAJ86JkXuu21zqz40C+RnNTVPID9n xeORxMyJirKVkcT88quOKwrzQMOKJOaUUEMMRBLzizKjtB9JrKp8MApXVYVg FK6KCuFIYlUV2vYQjiRWVaFJDw/dSGLOd+YsYUVTzFm8JkUDkcSiRZu3Gogk Fi0aa1WfvvaB/FRn98fv/vjdH7+qotXHryKQn2pRlXSC3JldemW8IHfOAC3e nF5VBPILVq4O5GeWjAby88q5gfwqy0Tm6O5Aw0B+/0c9S0sP2E7//ai45Izo KQSYKpc+bpPJTjb4fvkkHZbZ8s3S0ruzvGSDoj+DMmyYXXA29DTjO/rxf7x9 sftd92nv5oZx3Chf9L7r3tx02DvOX78v2bRgLzmDzV7n5dkkhcExfk64oHWR Z5cdaF0W2zs+zkZsZ5LztmWxv+0cvGTPi/60mJSiDnYF34kB5dPkHe+PuCzA 55c8T6cp791s93kxSocDtseZ/mH6PlNt91O+LLMhAz0D32XRfLnO3mVcRviv /IKLfiNVmssARqn1pdCkTjlbP5nKIjjQncEk5wVfpJNJNlQFi3Gp27IG+2rG F/t1fjrjpXcBkvhi8xdc/BgOC2/oR2fZmCOdQail1+lZVp6x/8ym/BUfSjrK Vf2d56Ea/+//TvI+++lq1H+frbOXs9E0m7Cf+OgHGfspGw74y71J/p7915Cv DE3vMOWj+JnTzmyiN21/7+ilav//A5ie718jGwQA[rfced] FYI - We updated artwork to sourcecode in Sections 5.1, 5.2.1, 5.2.2.1, 5.2.4, 5.2.5, 5.2.5.1, 5.2.5.2, 5.2.5.3, 5.2.5.3.1, 5.2.5.3.2, 5.2.5.3.3, 5.2.5.3.4, 5.2.5.3.5, 5.2.5.3.6, 5.2.5.4, 5.2.5.5, and 5.2.5.6 and Appendix B. Please review whether this is correct. We note that a YANG tree diagram is typically held in a sourcecode element (https://authors.ietf.org/en/rfcxml-vocabulary#sourcecode). In addition, please review the "type" attribute of each sourcecode element in the XML file to ensure correctness. The current list of preferred values for "type" is available at <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. --> <!--[rfced] Abbreviations a) 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? attachment circuit (AC) Customer Edge (CE) Layer 2 VPN (L2VPN) Layer 3 VPN (L3VPN) Service Function (SF) b) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Customer VLAN (CVLAN) IP Address Management (IPAM) Layer 2 VPN (L2VPN) Layer 3 VPN (L3VPN) Network Configuration Protocol (NETCONF) --> <!-- [rfced] Terminology a) 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. Network Slice Service vs. Slice Service vs. IETF Network Slice Service b) To reflect how "parent AC" is consistently lowercase, may we update instances of "Child AC" to "child AC"? Note that there is mixed usage throughout the document. --> <!-- [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. For example, please consider whether the following should be updated: natively --> </rfc>