rfc9834.original.xml   rfc9834.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.3. -ietf-opsawg-teas-attachment-circuit-20" number="9834" category="std" consensus=
6) --> "true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" ve
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft rsion="3" xml:lang="en" updates="" obsoletes="">
-ietf-opsawg-teas-attachment-circuit-20" category="std" consensus="true" submiss
ionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.25.0 -->
<front> <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> <title abbrev="ACaaS">YANG Data Models for Bearers and 'Attachment Circuits' -as-a-Service (ACaaS)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-attachment-c <seriesInfo name="RFC" value="9834"/>
ircuit-20"/> <author fullname="Mohamed Boucadair" role="editor" initials="M." surname="Bo
<author fullname="Mohamed Boucadair" role="editor"> ucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Richard Roberts" role="editor"> <author fullname="Richard Roberts" role="editor" initials="R." surname="Robe rts">
<organization>Juniper</organization> <organization>Juniper</organization>
<address> <address>
<email>rroberts@juniper.net</email> <email>rroberts@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Oscar Gonzalez de Dios"> <author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dios">
<organization>Telefonica</organization> <organization>Telefonica</organization>
<address> <address>
<email>oscar.gonzalezdedios@telefonica.com</email> <email>oscar.gonzalezdedios@telefonica.com</email>
</address> </address>
</author> </author>
<author fullname="Samier Barguil Giraldo"> <author fullname="Samier Barguil Giraldo" initials="S." surname="Barguil Gir aldo">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>samier.barguil_giraldo@nokia.com</email> <email>samier.barguil_giraldo@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Bo Wu"> <author fullname="Bo Wu" initials="B." surname="Wu">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<email>lana.wubo@huawei.com</email> <email>lana.wubo@huawei.com</email>
</address> </address>
</author> </author>
<date year="2025" month="January" day="23"/> <date year="2025" month="August"/>
<area>Operations and Management</area> <area>OPS</area>
<workgroup>OPSAWG</workgroup> <workgroup>opsawg</workgroup>
<keyword>Slice Service</keyword> <keyword>Slice Service</keyword>
<keyword>L3VPN</keyword> <keyword>L3VPN</keyword>
<keyword>L2VPN</keyword> <keyword>L2VPN</keyword>
<keyword>Automation</keyword> <keyword>Automation</keyword>
<keyword>Network Automation</keyword> <keyword>Network Automation</keyword>
<keyword>Orchestration</keyword> <keyword>Orchestration</keyword>
<keyword>service delivery</keyword> <keyword>service delivery</keyword>
<keyword>Service provisioning</keyword> <keyword>Service provisioning</keyword>
<keyword>service segmentation</keyword> <keyword>service segmentation</keyword>
<keyword>service flexibility</keyword> <keyword>service flexibility</keyword>
<keyword>service simplification</keyword> <keyword>service simplification</keyword>
<keyword>Network Service</keyword> <keyword>Network Service</keyword>
<keyword>3GPP</keyword> <keyword>3GPP</keyword>
<keyword>Network Slicing</keyword> <keyword>Network Slicing</keyword>
<abstract>
<?line 117?>
<t>Delivery of network services assumes that appropriate setup is provisioned ov <abstract>
er the links that connect customer termination points and a provider network. Th <t>Delivery of network services assumes that appropriate setup is provisioned ov
e required setup to allow successful data exchange over these links is referred er the links that connect customer termination points and a provider network. Th
to as an attachment circuit (AC), while the underlying link is referred to as "b e required setup to allow successful data exchange over these links is referred
earer".</t> 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 c an be used for the provisioning of ACs before or during service provisioning (e. g., Network Slice Service).</t> <t>This document specifies a YANG service data model for ACs. This model c an 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 model for managing bearers o ver which ACs are established.</t> <t>The document also specifies a YANG service data model for managing bear ers over which ACs are established.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
Operations and Management Area Working Group Working Group mailing list (ops
awg@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/
opsawg/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/boucadair/attachment-circuit-model"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 125?> <?line 125?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<section anchor="scope-and-intended-use"> <section anchor="scope-and-intended-use">
<name>Scope and Intended Use</name> <name>Scope and Intended Use</name>
<t>Connectivity services are provided by networks to customers via dedic ated termination points, such as Service Functions (SFs) <xref target="RFC7665"/ >, Customer Edges (CEs), peer Autonomous System Border Routers (ASBRs), data cen ters gateways, or Internet Exchange Points. A connectivity service is basically about ensuring data transfer received from or destined to a given termination po int to or from other termination points. The objectives for the connectivity ser vice can be negotiated and agreed upon between the customer and the network prov ider. To facilitate data transfer within the provider network, it is assumed tha t the appropriate setup is provisioned over the links that connect customer term ination points and a provider network (usually via a Provider Edge (PE)), allowi ng successfully data exchanged over these links. The required setup is referred to in this document as an attachment circuit (AC), while the underlying link is referred to as "bearer".</t> <t>Connectivity services are provided by networks to customers via dedic ated termination points, such as Service Functions (SFs) <xref target="RFC7665"/ >, Customer Edges (CEs), peer Autonomous System Border Routers (ASBRs), data cen ters gateways, or Internet Exchange Points (IXPs). A connectivity service is bas ically about ensuring data transfer received from or destined to a given termina tion point to or from other termination points. The objectives for the connectiv ity service can be negotiated and agreed upon between the customer and the netwo rk provider. To facilitate data transfer within the provider network, it is assu med that the appropriate setup is provisioned over the links that connect custom er termination points and a provider network (usually via a Provider Edge (PE)), allowing data to be successfully exchanged over these links. The required setup is referred to in this document as an attachment circuit (AC), while the underl ying link is referred to as a "bearer".</t>
<t>When a customer requests a new service, the service can be bound to e xisting attachment circuits or trigger the instantiation of new attachment circu its. The provisioning of a service should, thus, accommodate both deployments.</ t> <t>When a customer requests a new service, the service can be bound to e xisting attachment circuits or trigger the instantiation of new attachment circu its. The provisioning of a service should, thus, accommodate both deployments.</ t>
<t>Also, because the instantiation of an attachment circuit requires coo rdinating the provisioning of endpoints that might not belong to the same admini strative entity (customer vs. provider or distinct operational teams within the same provider, etc.), providing programmatic means to expose 'Attachment Circuit s'-as-a-Service (ACaaS) greatly simplifies the provisioning of services delivere d over an attachment circuit. For example, management systems of adjacent domain s 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>Also, because the instantiation of an attachment circuit requires coo rdinating the provisioning of endpoints that might not belong to the same admini strative entity (customer vs. provider or distinct operational teams within the same provider, etc.), providing programmatic means to expose 'Attachment Circuit s'-as-a-Service (ACaaS) greatly simplifies the provisioning of services delivere d over an attachment circuit. For example, management systems of adjacent domain s 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, su ch as an enterprise site, an SF, a hosting infrastructure, or a peer network pro vider. The model can be used for the provisioning of ACs prior to or during adva nced service provisioning (e.g., IETF Network Slice Service defined in "A Framew ork for Network Slices in Networks Built from IETF Technologies" <xref target="R FC9543"/>).</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, su ch as an enterprise site, an SF, a hosting infrastructure, or a peer network pro vider. The model can be used for the provisioning of ACs prior to or during adva nced service provisioning (e.g., IETF Network Slice Service defined in "A Framew ork for Network Slices in Networks Built from IETF Technologies" <xref target="R FC9543"/>).</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 <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 attachment circuits associated with the service reuses structures defined in the
"ietf-ac-svc" or simply includes an AC reference (that was communicated during "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 up AC service instantiation) is a design choice of these service models. Relying up
on the AC service model to manage ACs over which services are delivered has the on 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 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 e allows upgrades (to reflect recent AC technologies or new features such as new e
ncryption schemes, or additional routing protocols) to be done in just one place ncryption 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 rather than in each (core) service model. This document favors the approach of c
completely relying upon the AC service model instead of duplicating data nodes i ompletely relying upon the AC service model instead of duplicating data nodes in
nto specific modules of advanced services that are delivered over an attachment to specific modules of advanced services that are delivered over an attachment c
circuit.</t> ircuit.</t>
<t>Since the provisioning of an AC requires a bearer to be in place, thi <t>Since the provisioning of an AC requires a bearer to be in place, this docume
s document introduces a new module called "ietf-bearer-svc" that enables custome nt introduces a new module called "ietf-bearer-svc", which enables customers to
rs to manage their bearers (<xref target="sec-bearer-module"/>). The customers c manage their bearers (<xref target="sec-bearer-module"/>).
an then retrieve a provider-assigned bearer reference that they will include in
their AC service requests. Likewise, a customer may retrieve whether their beare <!--[rfced] In the second sentence below, does the customer
rs support a synchronization mechanism such as Sync Ethernet (SyncE) <xref targe retrieve "a reference" or "an indication" or something else?
t="ITU-T-G.781"/>. An example of retrieving a bearer reference is provided in <x
ref target="ex-create-bearer"/>.</t> 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 w
ill include in their AC service requests. Likewise, a customer may retrieve whet
her their bearers support a synchronization mechanism such as Sync Ethernet (Syn
cE) <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 f or Service Attachment Points (SAPs)" <xref target="RFC9408"/>. Both schemes are supported in the AC service model. When several bearers are available, the AC se rvice request may filter them based on the bearer type, synchronization support, etc.</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 f or Service Attachment Points (SAPs)" <xref target="RFC9408"/>. Both schemes are supported in the AC service model. When several bearers are available, the AC se rvice 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 doma <t>Each AC is identified with a unique identifier within a provider doma
in. From a network provider standpoint, an AC can be bound to a single or multip in. From a network provider standpoint, an AC can be bound to a single or multip
le SAPs <xref target="RFC9408"/>. Likewise, the same SAP can be bound to one or le SAPs <xref target="RFC9408"/>.
multiple ACs. However, the mapping between an AC and a PE in the provider networ Likewise, the same SAP can be bound to one or multiple ACs. However, the
k that terminates that AC is hidden to the application that makes use of the AC mapping between an AC and a PE in the provider network that terminates that AC i
service model. Such mapping information is internal to the network controllers. s hidden to the application that makes use of the AC service model. Such mapping
As such, the details about the (node-specific) attachment interfaces are not exp information is internal to the network controllers. As such, the details about
osed in the AC service model. However, these details are exposed at the network the (node-specific) attachment interfaces are not exposed in the AC service mode
model per "A Network YANG Data Model for Attachment Circuits" specification <xre l. However, these details are exposed at the network model per "A Network YANG D
f target="I-D.ietf-opsawg-ntw-attachment-circuit"/>. "A YANG Data Model for Augm ata Model for Attachment Circuits" <xref target="RFC9835"/>. "A YANG Data Model
enting VPN Service and Network Models with Attachment Circuits" <xref target="I- for Augmenting VPN Service and Network Models with Attachment Circuits" <xref ta
D.ietf-opsawg-ac-lxsm-lxnm-glue"/> specifies augmentations to the L2VPN Ser rget="RFC9836"/> specifies augmentations to the L2VPN Service Model (L2SM)
vice Model (L2SM) <xref target="RFC8466"/> and the L3VPN Service Model (L3SM <xref target="RFC8466"/> and the L3VPN Service Model (L3SM) <xref target="RF
) <xref target="RFC8299"/> to bind LxVPN services to ACs.</t> C8299"/> to bind LxVPN services to ACs.</t>
<t>The AC service model does not make any assumptions about the internal <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 att structure or even the nature of the services that will be delivered over an att
achment circuit or a set of attachment circuits. Customers do not have access to achment 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 ser that network view other than the ACs that they ordered. For example, the AC ser
vice model can be used to provision a set of ACs to connect multiple sites (Site vice model can be used to provision a set of ACs to connect multiple sites (Site
1, Site2, ..., SiteX) for customer who also requested VPN services. If the provi 1, Site2, ..., SiteX) for a customer who also requested VPN services. If the pro
sioning of these services requires specific configuration on ASBR nodes, such co visioning of these services requires specific configuration on ASBR nodes, such
nfiguration is handled at the network level and is not exposed to the customer a configuration is handled at the network level and is not exposed to the customer
t the service level. However, the network controller will have access to such a at the service level. However, the network controller will have access to such
view as the service points in these ASBRs will be exposed as SAPs with 'role' se a view, as the service points in these ASBRs will be exposed as SAPs with 'role'
t to 'ietf-sap-ntw:nni' <xref target="RFC9408"/>.</t> 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 (b ut not limited to) those provided in <xref target="examples"/>:</t> <t>The AC service model can be used in a variety of contexts, such as (b ut not limited to) those provided in <xref target="examples"/>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Create an AC over an existing bearer <xref target="ac-bearer-exis t"/>.</t> <t>Create an AC over an existing bearer (<xref target="ac-bearer-exi st"/>).</t>
</li> </li>
<li> <li>
<t>Request an attachment circuit for a known peer SAP (<xref target= "ac-no-bearer-peer-sap"/>).</t> <t>Request an attachment circuit for a known peer SAP (<xref target= "ac-no-bearer-peer-sap"/>).</t>
</li> </li>
<li> <li>
<t>Instantiate multiple attachment circuits over the same bearer (<x ref target="sec-ex-one-ce-multi-acs"/>).</t> <t>Instantiate multiple attachment circuits over the same bearer (<x ref target="sec-ex-one-ce-multi-acs"/>).</t>
</li> </li>
<li> <li>
<t>Control the precedence over multiple attachment circuits (<xref t arget="sec-ex-prec"/>).</t> <t>Control the precedence over multiple attachment circuits (<xref t arget="sec-ex-prec"/>).</t>
</li> </li>
<li> <li>
<t>Create Multiple ACs bound to Multiple CEs (<xref target="sec-mult iple-ces"/>).</t> <t>Create multiple ACs bound to multiple CEs (<xref target="sec-mult iple-ces"/>).</t>
</li> </li>
<li> <li>
<t>Bind a slice service to a set of pre-provisioned attachment circu its (<xref target="sec-ex-slice"/>).</t> <t>Bind a Slice Service to a set of pre-provisioned attachment circu its (<xref target="sec-ex-slice"/>).</t>
</li> </li>
<li> <li>
<t>Connect an enterprise network to a provider network using BGP (< xref target="sec-cus-bgp"/>).</t> <t>Connect an enterprise network to a provider network using BGP (< xref target="sec-cus-bgp"/>).</t>
</li> </li>
<li> <li>
<t>Connect a Cloud Infrastructure to a service provider network (<xr ef target="sec-ex-cloud"/>).</t> <t>Connect a Cloud Infrastructure to a service provider network (<xr ef target="sec-ex-cloud"/>).</t>
</li> </li>
<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 'ro le' set to 'ac-common:nni' or 'ac-common:public-nni'. See <xref target="sec-peer ing"/> to illustrate the use of the AC model for interconnection/peering.</t> <t>Interconnect provider networks (e.g., <xref target="RFC8921"/> or <xref target="I-D.ietf-grow-peering-api"/>). Such ACs are identified with a 'ro le' set to 'ac-common:nni' or 'ac-common:public-nni'. See <xref target="sec-peer ing"/> to illustrate the use of the AC model for interconnection/peering.</t>
</li> </li>
<li> <li>
<t>Manage connectivity for complex containerized or virtualized func tions in the cloud (<xref target="sec-cloudified-nfs"/>).</t> <t>Manage connectivity for complex containerized or virtualized func tions in the cloud (<xref target="sec-cloudified-nfs"/>).</t>
</li> </li>
<li> <li>
<t>Manage AC redundancy with static addressing (<xref target="sec-bf d-static"/>).</t> <t>Manage AC redundancy with static addressing (<xref target="sec-bf d-static"/>).</t>
</li> </li>
</ul> </ul>
<t>The document adheres to the principles discussed in "Service Models E xplained" (<xref section="3" sectionFormat="of" target="RFC8309"/>) for the enco ding and communication protocols used <t>The document adheres to the principles discussed in "Service Models E xplained" (<xref section="3" sectionFormat="of" target="RFC8309"/>) for the enco ding 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 independentl y of NETCONF/RESTCONF.</t> 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 independentl y of the Network Configuration Protocol (NETCONF) / RESTCONF.</t>
<t>The YANG data models in this document conform to the Network Manageme nt Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t> <t>The YANG data models in this document conform to the Network Manageme nt Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t>
</section> </section>
<section anchor="positioning-acaas-vs-other-data-models"> <section anchor="positioning-acaas-vs-other-data-models">
<name>Positioning ACaaS vs. Other Data Models</name> <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 specif ic nodes in the provider's network that terminate an AC (e.g., network node iden tifiers). The mapping between an AC as seen by a customer and the network implem entation 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 augmented SAP AC network model <xref target="I-D.ietf-opsawg-ntw-attach ment-circuit"/>.</t> <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 specif ic nodes in the provider's network that terminate an AC (e.g., network node iden tifiers). The mapping between an AC as seen by a customer and the network implem entation 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 <xref target="RFC9835"/>.</t>
<t>The AC service model is not a device model. A network provider may us e a variety of device models (e.g., "A YANG Data Model for Routing Management (N MDA Version)" <xref target="RFC8349"/> or "YANG Model for Border Gateway Protoco l (BGP-4)" <xref target="I-D.ietf-idr-bgp-model"/>) to provision an AC service i n relevant network nodes.</t> <t>The AC service model is not a device model. A network provider may us e a variety of device models (e.g., "A YANG Data Model for Routing Management (N MDA Version)" <xref target="RFC8349"/> or "YANG Model for Border Gateway Protoco l (BGP-4)" <xref target="I-D.ietf-idr-bgp-model"/>) to provision an AC service i n 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> <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" > <section anchor="why-not-use-the-l2sm-as-reference-data-model-for-acaas" >
<name>Why Not Use the L2SM as Reference Data Model for ACaaS?</name> <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 focuse d on Layer 2 aspects. For example, the L2SM does not cover Layer 3 provisioning, which is required for the typical AC instantiation.</t> <t>The L2VPN Service Model (L2SM) <xref target="RFC8466"/> covers some AC-related considerations. Nevertheless, the L2SM structure is primarily focuse d 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>
<section anchor="why-not-use-the-l3sm-as-reference-data-model-for-acaas" > <section anchor="why-not-use-the-l3sm-as-reference-data-model-for-acaas" >
<name>Why Not Use the L3SM as Reference Data Model for ACaaS?</name> <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 s ufficiently address Layer 2 provisioning requirements. Additionally, the L3SM is primarily designed for conventional L3VPN deployments and, as such, has some li mitations for instantiating ACs in other deployment contexts (e.g., cloud enviro nments). For example, the L3SM does not provide the capability to provision mult iple BGP peer groups over the same AC.</t> <t>Like the L2SM, the L3VPN Service Model (L3SM) <xref target="RFC8299 "/> addresses certain AC-related aspects. However, the L3SM structure does not s ufficiently address Layer 2 provisioning requirements. Additionally, the L3SM is primarily designed for conventional L3VPN deployments and, as such, has some li mitations for instantiating ACs in other deployment contexts (e.g., cloud enviro nments). For example, the L3SM does not provide the capability to provision mult iple BGP peer groups over the same AC.</t>
</section> </section>
</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 public
ation.</t>
<t>This document contains placeholder values that need to be replaced wi
th finalized values at the time of publication. This note summarizes all of the
substitutions that are needed.</t>
<t>Please apply the following replacements:</t>
<ul spacing="normal">
<li>
<t>CCCC --&gt; the assigned RFC number for <xref target="I-D.ietf-op
sawg-teas-common-ac"/></t>
</li>
<li>
<t>XXXX --&gt; the assigned RFC number for this I-D</t>
</li>
<li>
<t>2025-01-07 --&gt; the actual date of the publication of this docu
ment</t>
</li>
</ul>
</section>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
<t>The meanings of the symbols in the YANG tree diagrams are defined in "YANG Tr </t>
ee Diagrams" <xref target="RFC8340"/>.</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>LxSM refers to both the L2SM and the L3SM.</t>
<t>LxNM refers to both the L2NM and the L3NM.</t> <t>LxNM refers to both the L2VPN Network Model (L2NM) and the L3VPN Networ
<t>LxVPN refers to both L2VPN and L3VPN.</t> k Model (L3NM).</t>
<t>LxVPN refers to both Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN).</t>
<t>This document uses the following terms:</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> <dt>Bearer:</dt>
<dd> <dd>
<t>A physical or logical link that connects a customer node (or site) <t>A physical or logical link that connects a customer node (or site)
to a provider network. A bearer can be a wireless or wired link. One or multiple to a provider network.</t>
technologies can be used to build a bearer (e.g., Link Aggregation Group (LAG) <t>A bearer can be a wireless or wired link. One or multiple technologi
<xref target="IEEE802.1AX"/>). The bearer type can be specified by a customer.</ es can be used to build a bearer (e.g., Link Aggregation Group (LAG) <xref targe
t> t="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 bear er 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 una mbiguously identify where a service is to be bound.</t> <t>The operator allocates a unique bearer reference to identify a bear er within its network (e.g., customer line identifier). Such a reference can be retrieved by a customer and used in subsequent service placement requests to una mbiguously identify where a service is to be bound.</t>
</dd> <t>The concept of a bearer can be generalized to refer to the required
<dt/> underlying connection for the provisioning of an attachment circuit.</t>
<dd> <t>One or multiple attachment circuits may be hosted over the same bear
<t>The concept of bearer can be generalized to refer to the required u er (e.g., multiple VLANs on the same bearer that is provided by a physical link)
nderlying connection for the provisioning of an attachment circuit. One or multi .</t>
ple 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> </dd>
<dt>Customer Edge (CE):</dt> <dt>Customer Edge (CE):</dt>
<dd> <dd>
<t>Equipment that is dedicated to a customer and is connected to one o r more PEs via ACs.</t> <t>Equipment that is dedicated to a customer and is connected to one o r more PEs via ACs.</t>
</dd>
<dt/>
<dd>
<t>A CE can be a router, a bridge, a switch, etc.</t> <t>A CE can be a router, a bridge, a switch, etc.</t>
</dd> </dd>
<dt>Provider Edge (PE):</dt> <dt>Provider Edge (PE):</dt>
<dd> <dd>
<t>Equipment owned and managed by the service provider that can suppor t multiple services for different customers.</t> <t>Equipment owned and managed by the service provider that can suppor t 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> <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> <t>A PE is connected to one or more CEs via ACs.</t>
</dd> </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> <dt>Network controller:</dt>
<dd> <dd>
<t>Denotes a functional entity responsible for the management of the s ervice provider network.</t> <t>Denotes a functional entity responsible for the management of the s ervice provider network.</t>
</dd> </dd>
<dt>Network Function (NF):</dt> <dt>Network Function (NF):</dt>
<dd> <dd>
<t>Used to refer to the same concept as Service Function (SF) (<xref s ection="1.4" sectionFormat="of" target="RFC7665"/>).</t> <t>Used to refer to the same concept as Service Function (SF) (<xref s ection="1.4" sectionFormat="of" target="RFC7665"/>).</t>
</dd> <t>NF is also used in this document, as this term is widely used outsi
<dt/> de the IETF.</t>
<dd>
<t>NF is also used in this document as this term is widely used outsid
e the IETF.</t>
</dd>
<dt/>
<dd>
<t>NF and SF are used interchangeably.</t> <t>NF and SF are used interchangeably.</t>
</dd> </dd>
<dt>Parent Bearer:</dt> <dt>Parent Bearer:</dt>
<dd> <dd>
<t>Refers to a bearer (e.g., LAG) that is used to build other bearers. These bearers (called, child bearers) inherit the parent bearer properties.</t> <t>Refers to a bearer (e.g., LAG) that is used to build other bearers. These bearers (called child bearers) inherit the parent bearer properties.</t>
</dd> </dd>
<dt>Parent AC:</dt> <dt>Parent AC:</dt>
<dd> <dd>
<t>Refers to an AC that is used to build other ACs. These ACs (called, child ACs) inherit th parent AC properties.</t> <t>Refers to an AC that is used to build other ACs. These ACs (called child ACs) inherit the parent AC properties.</t>
</dd> </dd>
<dt>Service orchestrator:</dt> <dt>Service orchestrator:</dt>
<dd> <dd>
<t>Refers to a functional entity that interacts with the customer of a <t>Refers to a functional entity that interacts with the customer of a
network service. The service orchestrator is typically responsible for the atta network service.</t>
chment circuits, the PE selection, and requesting the activation of the requeste <t>A service orchestrator is typically responsible for the attachment c
d service to a network controller.</t> ircuits, the PE selection, and requesting the activation of the requested servic
e to a network controller.</t>
</dd> </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> <dt>Service provider network:</dt>
<dd> <dd>
<t>A network that is able to provide network services (e.g., Layer 2 V PN, Layer 3 VPN, or Network Slice Services).</t> <t>A network that is able to provide network services (e.g., Layer 2 V PN (L2VPN), Layer 3 VPN (L3VPN), or Network Slice Services).</t>
</dd> </dd>
<dt>Service provider:</dt> <dt>Service provider:</dt>
<dd> <dd>
<t>An entity that offers network services (e.g., Layer 2 VPN, Layer 3 VPN, or Network Slice Services).</t> <t>An entity that offers network services (e.g., Layer 2 VPN, Layer 3 VPN, or Network Slice Services).</t>
</dd> </dd>
</dl> </dl>
<t>The names of data nodes are prefixed using the prefix associated with t he corresponding imported YANG module as shown in <xref target="pref"/>:</t> <t>The names of data nodes are prefixed using the prefix associated with t he corresponding imported YANG module as shown in <xref target="pref"/>:</t>
<table anchor="pref"> <table anchor="pref">
<name>Modules and Their Associated Prefixes</name> <name>Modules and Their Associated Prefixes</name>
<thead> <thead>
skipping to change at line 294 skipping to change at line 346
<xref target="RFC9181"/></td> <xref target="RFC9181"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="relationship-to-other-ac-data-models"> <section anchor="relationship-to-other-ac-data-models">
<name>Relationship to Other AC Data Models</name> <name>Relationship to Other AC Data Models</name>
<t><xref target="ac-overview"/> depicts the relationship between the vario us AC data models:</t> <t><xref target="ac-overview"/> depicts the relationship between the vario us AC data models:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>"ietf-ac-common" (<xref target="I-D.ietf-opsawg-teas-common-ac"/>)< /t> <t>"ietf-ac-common" <xref target="RFC9833"/></t>
</li> </li>
<li> <li>
<t>"ietf-bearer-svc" (<xref target="sec-bearer-module"/>)</t> <t>"ietf-bearer-svc" (<xref target="sec-bearer-module"/>)</t>
</li> </li>
<li> <li>
<t>"ietf-ac-svc" (<xref target="sec-ac-module"/>)</t> <t>"ietf-ac-svc" (<xref target="sec-ac-module"/>)</t>
</li> </li>
<li> <li>
<t>"ietf-ac-ntw" (<xref target="I-D.ietf-opsawg-ntw-attachment-circuit "/>)</t> <t>"ietf-ac-ntw" <xref target="RFC9835"/></t>
</li> </li>
<li> <li>
<t>"ietf-ac-glue" (<xref target="I-D.ietf-opsawg-ac-lxsm-lxnm-glue"/>) </t> <t>"ietf-ac-glue" <xref target="RFC9836"/></t>
</li> </li>
</ul> </ul>
<figure anchor="ac-overview"> <figure anchor="ac-overview">
<name>AC Data Models</name> <name>AC Data Models</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="288" width="368" viewBox="0 0 368 288" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="288" width="368" viewBox="0 0 368 288" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
<path d="M 32,144 L 32,240" fill="none" stroke="black"/> <path d="M 32,144 L 32,240" fill="none" stroke="black"/>
<path d="M 56,80 L 56,112" fill="none" stroke="black"/> <path d="M 56,80 L 56,112" fill="none" stroke="black"/>
<path d="M 72,144 L 72,176" fill="none" stroke="black"/> <path d="M 72,144 L 72,176" fill="none" stroke="black"/>
<path d="M 144,48 L 144,80" fill="none" stroke="black"/> <path d="M 144,48 L 144,80" fill="none" stroke="black"/>
skipping to change at line 379 skipping to change at line 431
</figure> </figure>
<t>The "ietf-ac-common" module is imported by the "ietf-bearer-svc", "ietf -ac-svc", and "ietf-ac-ntw" modules. Bearers managed using the "ietf-bearer-svc" module may be referenced by service ACs managed using the "ietf-ac-svc" module. Similarly, a bearer managed using the "ietf-bearer-svc" module may list the set of ACs that use that bearer. To facilitate correlation between an AC service re quest and the actual AC provisioned in the network, "ietf-ac-ntw" leverages the AC references exposed by the "ietf-ac-svc" module. Furthermore, to bind Layer 2 VPN or Layer 3 VPN services with ACs, the "ietf-ac-glue" module augments the LxS M and LxNM with AC service references exposed by the "ietf-ac-svc" module and AC network references exposed by the "ietf-ac-ntw" module.</t> <t>The "ietf-ac-common" module is imported by the "ietf-bearer-svc", "ietf -ac-svc", and "ietf-ac-ntw" modules. Bearers managed using the "ietf-bearer-svc" module may be referenced by service ACs managed using the "ietf-ac-svc" module. Similarly, a bearer managed using the "ietf-bearer-svc" module may list the set of ACs that use that bearer. To facilitate correlation between an AC service re quest and the actual AC provisioned in the network, "ietf-ac-ntw" leverages the AC references exposed by the "ietf-ac-svc" module. Furthermore, to bind Layer 2 VPN or Layer 3 VPN services with ACs, the "ietf-ac-glue" module augments the LxS M and LxNM with AC service references exposed by the "ietf-ac-svc" module and AC network references exposed by the "ietf-ac-ntw" module.</t>
</section> </section>
<section anchor="sample-uses-of-the-data-models"> <section anchor="sample-uses-of-the-data-models">
<name>Sample Uses of the Data Models</name> <name>Sample Uses of the Data Models</name>
<section anchor="acs-terminated-by-one-or-multiple-customer-edges-ces"> <section anchor="acs-terminated-by-one-or-multiple-customer-edges-ces">
<name>ACs Terminated by One or Multiple Customer Edges (CEs)</name> <name>ACs Terminated by One or Multiple Customer Edges (CEs)</name>
<t><xref target="uc"/> depicts two target topology flavors that involve ACs. These topologies have the following characteristics:</t> <t><xref target="uc"/> depicts two target topology flavors that involve ACs. These topologies have the following characteristics:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A CE can be either a physical device or a logical entity. Such lo gical entity is typically a software component (e.g., a virtual service function that is hosted within the provider's network or a third-party infrastructure). A CE is seen by the network as a peer SAP.</t> <t>A CE can be either a physical device or a logical entity. Such lo gical entity is typically a software component (e.g., a virtual Service Function that is hosted within the provider's network or a third-party infrastructure). A CE is seen by the network as a peer SAP.</t>
</li> </li>
<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> <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>
<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> <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>
<li> <li>
<t>A network provider may bind a single AC to one or multiple peer S APs (e.g., CE#1 and CE#2 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 servi ce.</t> <t>A network provider may bind a single AC to one or multiple peer S APs (e.g., CE1 and CE2 are tagged as peer SAPs for the same AC). For example, an d as discussed in <xref target="RFC4364"/>, multiple CEs can be attached to a PE over the same attachment circuit. This scenario is typically implemented when t he Layer 2 infrastructure between the CE and the network is a multipoint service .</t>
</li> </li>
<li> <li>
<t>A single CE may terminate multiple ACs, which can be associated w ith the same bearer or distinct bearers.</t> <t>A single CE may terminate multiple ACs, which can be associated w ith the same bearer or distinct bearers.</t>
</li> </li>
<li> <li>
<t>Customers may request protection schemes in which the ACs associa ted with their endpoints are terminated by the same PE (e.g., CE#3), distinct PE s (e.g., CE#4), etc. The network provider uses this request to decide where to t erminate the AC in the provider network (i.e., select which PE(s) to use) and al so whether to enable specific capabilities (e.g., Virtual Router Redundancy Prot ocol (VRRP) <xref target="RFC9568"/>). Note that placement constraints may also be requested during the instantiation of the underlying bearers (<xref target="s ec-bearer"/>).</t> <t>Customers may request protection schemes in which the ACs associa ted with their endpoints are terminated by the same PE (e.g., CE3), distinct PEs (e.g., CE4), etc. The network provider uses this request to decide where to ter minate the AC in the provider network (i.e., select which PE(s) to use) and also whether to enable specific capabilities (e.g., Virtual Router Redundancy Protoc ol (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> </li>
</ul> </ul>
<figure anchor="uc"> <figure anchor="uc">
<name>Examples of ACs</name> <name>Examples of ACs</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="304" width="512" viewBox="0 0 512 304" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="304" width="512" viewBox="0 0 512 304" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 8,80 L 8,112" fill="none" stroke="black"/> <path d="M 8,80 L 8,112" fill="none" stroke="black"/>
<path d="M 8,160 L 8,192" fill="none" stroke="black"/> <path d="M 8,160 L 8,192" fill="none" stroke="black"/>
<path d="M 72,64 L 72,96" fill="none" stroke="black"/> <path d="M 72,64 L 72,96" fill="none" stroke="black"/>
<path d="M 72,144 L 72,176" fill="none" stroke="black"/> <path d="M 72,144 L 72,176" fill="none" stroke="black"/>
skipping to change at line 518 skipping to change at line 570
'--' | '--' |
| | | |
'-----------AC----------' '-----------AC----------'
(bx) = bearer Id x (bx) = bearer Id x
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="separate-ac-provisioning-vs-actual-service-provisioning"> <section anchor="separate-ac-provisioning-vs-actual-service-provisioning">
<name>Separate AC Provisioning vs. Actual Service Provisioning</name> <name>Separate AC Provisioning vs. Actual Service Provisioning</name>
<t>The procedure to provision a service in a service provider network ma y depend on the practices adopted by a service provider. This includes the workf low put in place for the provisioning of network services and how they are boun d 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 in place, and then refer to that bearer or AC when requesting services that are bound to the bearer or AC. <xref target="I-D.ietf- opsawg-ac-lxsm-lxnm-glue"/> specifies augmentations to the L2SM and the L3SM to bind LxVPN services to ACs.</t> <t>The procedure to provision a service in a service provider network ma y depend on the practices adopted by a service provider. This includes the workf low put in place for the provisioning of network services and how they are boun d 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 in place and then refer to that bearer or AC when requesting services that are bound to the bearer or AC. <xref target="RFC9836"/> specifies augmentations to the L2SM and the L3SM to bind LxVPN services to ACs. </t>
</section> </section>
<section anchor="sample-deployment-models"> <section anchor="sample-deployment-models">
<name>Sample Deployment Models</name> <name>Sample Deployment Models</name>
<t><xref target="_u-ex-c"/> shows an example to illustrate how the beare r/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><xref target="_u-ex-c"/> illustrates an example of how the bearer/AC service models can be used between a customer and a provider. Internals to the p rovider orchestration domain (or customer orchestration domain) are hidden to th e 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 mod el assumes that the customer may supply a specific identifier (e.g., selected fr om a pool that was pre-provisioned by the provider) in a service request. The pr ovider may accept or reject such request.</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 mod el assumes that the customer may supply a specific identifier (e.g., selected fr om a pool that was pre-provisioned by the provider) in a service request. The pr ovider may accept or reject such request.</t>
<figure anchor="_u-ex-c"> <figure anchor="_u-ex-c">
<name>Example of Interaction Between Customer and Provider Orchestrati ons</name> <name>Example of Interaction Between Customer and Provider Orchestrati ons</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="240" width="544" viewBox="0 0 544 240" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="240" width="544" viewBox="0 0 544 240" class="diagr am" 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,48 L 8,80" fill="none" stroke="black"/>
<path d="M 8,160 L 8,224" 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,96 L 96,112" fill="none" stroke="black"/>
<path d="M 96,144 L 96,160" 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,48 L 192,80" fill="none" stroke="black"/>
skipping to change at line 614 skipping to change at line 666
Provisioning Provisioning Provisioning Provisioning
| | | |
.----------v-----------. .---------v----------. .----------v-----------. .---------v----------.
| |========Bearer=======| | | |========Bearer=======| |
| Customer Site +----------AC---------| Provider Network | | Customer Site +----------AC---------| Provider Network |
| |=====================| | | |=====================| |
'----------------------' '--------------------' '----------------------' '--------------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t><xref target="_u-ex-r"/> shows an example to illustrate how the beare r/AC service models that involve a third party. This deployment model follows a recursive approach but other Client/Server alternative modes with a third party can be considered. In a recursive deployment, the Service Broker <t><xref target="_u-ex-r"/> illustrates an example of how the bearer/AC service models involve a third party. This deployment model follows a recursive approach, but other client/server alternative modes with a third party can be co nsidered. 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 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 ser vice requests is deployment specific.</t> decides to terminate a recursion for a given service request or create child ser vice requests is specific to each deployment.</t>
<figure anchor="_u-ex-r"> <figure anchor="_u-ex-r">
<name>Example of Recursive Deployment</name> <name>Example of Recursive Deployment</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="144" width="584" viewBox="0 0 584 144" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="144" width="584" viewBox="0 0 584 144" class="diagr am" 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,48 L 8,80" fill="none" stroke="black"/>
<path d="M 96,48 L 96,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 232,48 L 232,80" fill="none" stroke="black"/>
<path d="M 320,48 L 320,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 448,48 L 448,80" fill="none" stroke="black"/>
<path d="M 576,48 L 576,80" fill="none" stroke="black"/> <path d="M 576,48 L 576,80" fill="none" stroke="black"/>
skipping to change at line 671 skipping to change at line 723
<text x="48" y="68">Service</text> <text x="48" y="68">Service</text>
<text x="276" y="68">Broker</text> <text x="276" y="68">Broker</text>
<text x="488" y="68">Service</text> <text x="488" y="68">Service</text>
<text x="544" y="68">Order</text> <text x="544" y="68">Order</text>
<text x="52" y="84">Ordering</text> <text x="52" y="84">Ordering</text>
<text x="264" y="84">B2B</text> <text x="264" y="84">B2B</text>
<text x="296" y="84">C/S</text> <text x="296" y="84">C/S</text>
<text x="516" y="84">Handling</text> <text x="516" y="84">Handling</text>
<text x="16" y="132">B2B</text> <text x="16" y="132">B2B</text>
<text x="52" y="132">C/S:</text> <text x="52" y="132">C/S:</text>
<text x="124" y="132">Back-to-back</text> <text x="124" y="132">Back-to-Back</text>
<text x="232" y="132">Client/Server</text> <text x="232" y="132">Client/Server</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
.--------. Bearer/AC .--------. Bearer/AC .-------------. .--------. Bearer/AC .--------. Bearer/AC .-------------.
| Customer | Service Models | Service | Service Model | Provider | | Customer | Service Models | Service | Service Model | Provider |
| Service |<-------------->| Broker |<------------->| Service Order | | Service |<-------------->| Broker |<------------->| Service Order |
| Ordering | | B2B C/S | | Handling | | Ordering | | B2B C/S | | Handling |
'--------' '--------' '-------------' '--------' '--------' '-------------'
B2B C/S: Back-to-back Client/Server B2B C/S: Back-to-Back Client/Server
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </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> <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"> <figure anchor="_u-ex">
<name>An Example of AC Model Usage (Focus on the Provider's Internals) </name> <name>An Example of AC Model Usage (Focus on the Provider's Internals) </name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="688" width="512" viewBox="0 0 512 688" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="688" width="512" viewBox="0 0 512 688" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 8,608 L 8,624" fill="none" stroke="black"/> <path d="M 8,608 L 8,624" fill="none" stroke="black"/>
<path d="M 48,592 L 48,608" fill="none" stroke="black"/> <path d="M 48,592 L 48,608" fill="none" stroke="black"/>
<path d="M 96,480 L 96,496" fill="none" stroke="black"/> <path d="M 96,480 L 96,496" fill="none" stroke="black"/>
<path d="M 104,368 L 104,384" fill="none" stroke="black"/> <path d="M 104,368 L 104,384" fill="none" stroke="black"/>
<path d="M 120,576 L 120,640" fill="none" stroke="black"/> <path d="M 120,576 L 120,640" fill="none" stroke="black"/>
<path d="M 136,400 L 136,464" fill="none" stroke="black"/> <path d="M 136,400 L 136,464" fill="none" stroke="black"/>
skipping to change at line 862 skipping to change at line 922
| | | | | |
.--------------------------------. .--------------------------------.
.---. Bearer | | Bearer .---. .---. Bearer | | Bearer .---.
|CE#1+--------+ Network +--------+CE#2| |CE#1+--------+ Network +--------+CE#2|
'---' | | '---' '---' | | '---'
'--------------------------------' '--------------------------------'
Site A Site B Site A Site B
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In order to ease the mapping between the service model and underlying network models (e.g., the L3VPN Network Model (L3NM), SAP), the name convention s used in existing network data models are reused as much as possible. For examp le, '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> <t>In order to ease the mapping between the service model and underlying network models (e.g., the L3VPN Network Model (L3NM) and SAP), the name convent ions used in existing network data models are reused as much as possible. For ex ample, 'local-address' is used rather than 'provider-address' (or similar) to re fer to an IP address used in the provider network. This approach is consistent w ith the automation framework defined in <xref target="RFC8969"/>.</t>
</section> </section>
</section> </section>
<section anchor="description-of-the-data-models"> <section anchor="description-of-the-data-models">
<name>Description of the Data Models</name> <name>Description of the Data Models</name>
<section anchor="sec-bearer"> <section anchor="sec-bearer">
<name>The Bearer Service ("ietf-bearer-svc") YANG Module</name> <name>The Bearer Service ("ietf-bearer-svc") YANG Module</name>
<t><xref target="bearer-st"/> shows the tree for managing the bearers (t hat 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 be arer can be a wireless or wired link. A reference to a bearer is generated by th e operator. <t><xref target="bearer-st"/> shows the tree for managing the bearers (t hat 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 be arer can be a wireless or wired link. A reference to a bearer is generated by th e 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 bearer reference), a peer SAP identifier (e.g., an identifier of an SF).</t> 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 bearer reference) a peer SAP identifier (e.g., an identifier of an SF).</t>
<figure anchor="bearer-st"> <figure anchor="bearer-st">
<name>Bearer Service Tree Structure</name> <name>Bearer Service Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-bearer-svc module: ietf-bearer-svc
+--rw locations +--rw locations
| +--rw customer* [name peer-as] | +--rw customer* [name peer-as]
| +--rw name string | +--rw name string
| +--rw peer-as inet:as-number | +--rw peer-as inet:as-number
| +--ro location* [name] | +--ro location* [name]
| +--ro name string | +--ro name string
| +--ro address? string | +--ro address? string
| +--ro city? string | +--ro city? string
| +--ro postal-code? string | +--ro postal-code? string
skipping to change at line 956 skipping to change at line 1016
+--rw requested-stop? yang:date-and-time +--rw requested-stop? yang:date-and-time
+--ro actual-start? yang:date-and-time +--ro actual-start? yang:date-and-time
+--ro actual-stop? yang:date-and-time +--ro actual-stop? yang:date-and-time
+--rw status +--rw status
+--rw admin-status +--rw admin-status
| +--rw status? identityref | +--rw status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--ro oper-status +--ro oper-status
+--ro status? identityref +--ro status? identityref
+--ro last-change? yang:date-and-time +--ro last-change? yang:date-and-time
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>In some deployments, a customer may first retrieve a list of availabl <t>In some deployments, a customer may first retrieve a list of availabl
e presence locations before placing an order for a bearer creation. The request e 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). Th is filtered based upon a customer name and an Autonomous System Number (ASN). Th
e reserved value "AS 0" <xref target="RFC7607"/> is used for customers with no A e reserved value "AS 0" <xref target="RFC7607"/> is used for customers with no A
SN. The retrieved location names may be then referenced in a bearer creation req SN. The retrieved location names may then be referenced in a bearer creation req
uest ('provider-location-reference'). See the example provided in <xref target=" uest ('provider-location-reference'). See the example provided in <xref target="
sec-ret-loc"/>.</t> sec-ret-loc"/>.</t>
<t>The same customer site (CE, SF, etc.) can terminate one or multiple b <t>The same customer site (CE, SF, etc.) can terminate one or multiple b
earers; each of them uniquely identified by a reference that is assigned by the earers; each of them is uniquely identified by a reference that is assigned by t
network provider. These bearers can terminate on the same or distinct network no he network provider. These bearers can terminate on the same or distinct network
des. CEs that terminate multiple bearers are called multi-homed CEs.</t> nodes. CEs that terminate multiple bearers are called multi-homed CEs.</t>
<t>A bearer can be created, modified, or discovered from the network. Fo r example, the following deployment options can be considered:</t> <t>A bearer can be created, modified, or discovered from the network. Fo r example, the following deployment options can be considered:</t>
<dl> <dl spacing="normal" newline="false">
<dt>Greenfield creation:</dt> <dt>Greenfield creation:</dt>
<dd> <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 m ay 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> <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 m ay 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> </dd>
<dt>Auto-discovery using network protocols:</dt> <dt>Auto-discovery using network protocols:</dt>
<dd> <dd>
<t>Devices can use specific protocols (e.g., Link Layer Discovery Pr otocol (LLDP) <xref target="IEEE802.1AB"/>) to automatically discover and connec t to available network resources. A network controller can use such reported inf ormation to expose discovered bearers from the network using the same bearer dat a model structure.</t> <t>Devices can use specific protocols (e.g., Link Layer Discovery Pr otocol (LLDP) <xref target="IEEE802.1AB"/>) to automatically discover and connec t to available network resources. A network controller can use such reported inf ormation to expose discovered bearers from the network using the same bearer dat a model structure.</t>
</dd> </dd>
</dl> </dl>
<t>A request to create a bearer may include a set of constraints ('place
ment-constraints') that are used by a controller to decide the network terminati <t>A request to create a bearer may include a set of constraints ('place
ng side of a bearer (e.g., PE selection, PE redundancy, or PoP selection). Futur ment-constraints') that are used by a controller to decide the network terminati
e placement criteria ('constraint-type') may be defined in the future to accommo ng side of a bearer (e.g., PE selection, PE redundancy, or PoP selection).
date specific deployment contexts. A request may also include some timing constr
aints ('requested-start', 'requested-stop') that are applicable for a set of bea <!--[rfced] To avoid repetition of "future", may we remove "in the
rers. The timing constraints can be adjusted at the 'bearer' level. These adjust future" from this sentence?
ed values take precedence over the global values.</t>
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 futur
e to accommodate specific deployment contexts. A request may also include some t
iming 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> <t>The descriptions of the bearer data nodes are as follows:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'name':</dt> <dt>'name':</dt>
<dd> <dd>
<t>Used to uniquely identify a bearer. This name is typically select ed by the client when requesting a bearer.</t> <t>Used to uniquely identify a bearer. This name is typically select ed by the client when requesting a bearer.</t>
</dd> </dd>
<dt>'customer-name':</dt> <dt>'customer-name':</dt>
<dd> <dd>
<t>Indicates the name of the customer who ordered the bearer.</t> <t>Indicates the name of the customer who ordered the bearer.</t>
</dd> </dd>
<dt>'description':</dt> <dt>'description':</dt>
<dd> <dd>
skipping to change at line 1008 skipping to change at line 1085
<dt>'bearer-lag-member':</dt> <dt>'bearer-lag-member':</dt>
<dd> <dd>
<t>Lists the bearers that are members of a LAG. Members can be decla red as part of a LAG using 'bearer-parent-ref'.</t> <t>Lists the bearers that are members of a LAG. Members can be decla red as part of a LAG using 'bearer-parent-ref'.</t>
</dd> </dd>
<dt>'sync-phy-capable':</dt> <dt>'sync-phy-capable':</dt>
<dd> <dd>
<t>Reports whether a synchronization physical (Sync PHY) mechanism i s supported for this bearer.</t> <t>Reports whether a synchronization physical (Sync PHY) mechanism i s supported for this bearer.</t>
</dd> </dd>
<dt>'sync-phy-enabled':</dt> <dt>'sync-phy-enabled':</dt>
<dd> <dd>
<t>Indicates whether a Sync PHY mechanism is enabled for a bearer. O nly applies when 'sync-phy-capable' is set to 'true'.</t> <t>Indicates whether a Sync PHY mechanism is enabled for a bearer. I t only applies when 'sync-phy-capable' is set to 'true'.</t>
</dd> </dd>
<dt>'sync-phy-type':</dt> <dt>'sync-phy-type':</dt>
<dd> <dd>
<t>Specifies the Sync PHY mechanism (e.g., SynchE <xref target="ITU- T-G.781"/>) enabled for the bearer.</t> <t>Specifies the Sync PHY mechanism (e.g., SyncE <xref target="ITU-T -G.781"/>) enabled for the bearer.</t>
</dd> </dd>
<dt>'provider-location-reference':</dt> <dt>'provider-location-reference':</dt>
<dd> <dd>
<t>Indicates a location identified by a provider-assigned reference. </t> <t>Indicates a location identified by a provider-assigned reference. </t>
</dd> </dd>
<dt>'customer-point':</dt> <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> <dd>
<t>Specifies the customer termination point for the bearer. A bearer request can indicate a device, a site, a combination thereof, or a custom infor mation when requesting a bearer. All these schemes are supported in the model.</ t> <t>Specifies the customer termination point for the bearer. A bearer request can indicate a device, a site, a combination thereof, or custom informa tion when requesting a bearer. All these schemes are supported in the model.</t>
</dd> </dd>
<dt>'type':</dt> <dt>'type':</dt>
<dd> <dd>
<t>Specifies the bearer type (Ethernet, wireless, LAG, etc.).</t> <t>Specifies the bearer type (Ethernet, wireless, LAG, etc.).</t>
</dd> </dd>
<dt>'test-only':</dt> <dt>'test-only':</dt>
<dd> <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. T his data node is applicable only when the data model is used with protocols whic h do not natively support such option. For example, this data node is redundant with the "test-only" value of the <tt>&lt;test-option&gt;</tt> parameter in the NETCONF <tt>&lt;edit-config&gt;</tt> operation (<xref section="7.2" sectionForma t="of" target="RFC6241"/>).</t> <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. T his data node is applicable only when the data model is used with protocols that do not natively support such option. For example, this data node is redundant w ith the "test-only" value of the <tt>&lt;test-option&gt;</tt> parameter in the N ETCONF <tt>&lt;edit-config&gt;</tt> operation (<xref section="7.2" sectionFormat ="of" target="RFC6241"/>).</t>
</dd> </dd>
<dt>'bearer-reference':</dt> <dt>'bearer-reference':</dt>
<dd> <dd>
<t>Returns an internal reference for the service provider to uniquel y identify the bearer. This reference can be used when requesting services. <xre f target="ex-create-bearer"/> provides an example about how this reference can b e retrieved by a customer.</t> <t>Returns an internal reference for the service provider to uniquel y identify the bearer. This reference can be used when requesting services. <xre f target="ex-create-bearer"/> provides an example about how this reference can b e 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 > <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> </dd>
<dt>'ac-svc-ref':</dt> <dt>'ac-svc-ref':</dt>
<dd> <dd>
<t>Specifies the set of attachment circuits that are bound to the be arer.</t> <t>Specifies the set of attachment circuits that are bound to the be arer.</t>
</dd> </dd>
<dt>'requested-start':</dt> <dt>'requested-start':</dt>
<dd> <dd>
<t>Specifies the requested date and time when the bearer is expected to be active.</t> <t>Specifies the requested date and time when the bearer is expected to be active.</t>
</dd> </dd>
<dt>'requested-stop':</dt> <dt>'requested-stop':</dt>
<dd> <dd>
<t>Specifies the requested date and time when the bearer is expected to be disabled.</t> <t>Specifies the requested date and time when the bearer is expected to be disabled.</t>
</dd> </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> <dt>'actual-start':</dt>
<dd> <dd>
<t>Reports the actual date and time when the bearer actually was ena bled.</t> <t>Reports the actual date and time when the bearer actually was ena bled.</t>
</dd> </dd>
<dt>'actual-stop':</dt> <dt>'actual-stop':</dt>
<dd> <dd>
<t>Reports the actual date and time when the bearer actually was dis abled.</t> <t>Reports the actual date and time when the bearer actually was dis abled.</t>
</dd> </dd>
<dt>'status':</dt> <dt>'status':</dt>
<dd> <dd>
<t>Used to track the overall status of a given bearer. Both operatio <t>Used to track the overall status of a given bearer. Both the oper
nal and administrative status are maintained together with a timestamp.</t> ational 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> <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> </dd>
<dt>'oper-status':</dt> <dt>'oper-status':</dt>
<dd> <dd>
<t>The 'oper-status' of a bearer reflects its operational state as o <t>Reflects the operational state of a bearer as observed. As a bear
bserved. As a bearer can contain multiple services, the operational status shoul er can contain multiple services, the operational status should only reflect the
d only reflect the status of the bearer connection. To obtain network-level serv status of the bearer connection. To obtain network-level service status, specif
ice status, specific network models such as those in <xref section="7.3" section ic network models, such as those in <xref section="7.3" sectionFormat="of" targe
Format="of" target="RFC9182"/> or <xref section="7.3" sectionFormat="of" target t="RFC9182"/> or <xref section="7.3" sectionFormat="of" target="RFC9291"/>, sho
="RFC9291"/> should be consulted.</t> uld be consulted.</t>
</dd> <t>It is important to note that the 'admin-status' attribute should
<dt/> remain independent of the 'oper-status'. In other words, the setting of the inte
<dd> nded administrative state (e.g., 'admin-up' or 'admin-testing') <bcp14>MUST NOT<
<t>It is important to note that the 'admin-status' attribute should /bcp14> be influenced by the current operational state. If the bearer is adminis
remain independent of the 'oper-status'. In other words, the setting of the inte tratively set to 'admin-down', it is expected that the bearer will also be opera
nded administrative state (e.g., whether 'admin-up' or 'admin-testing') <bcp14>M tionally 'op-down' as a result of this administrative decision.</t>
UST 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 comprehe nsively, it is recommended to consider both administrative and operational servi ce status values in conjunction. This holistic approach allows a network contro ller or operator to identify anomalies effectively.</t> <t>To assess the service delivery status for a given bearer comprehe nsively, it is recommended to consider both administrative and operational servi ce status values in conjunction. This holistic approach allows a network contro ller 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 expect ed that the 'oper-status' of services transported over that bearer is also down. These status values differing should trigger the detection of an anomaly condit ion.</t> <t>For instance, when a bearer is administratively enabled but the ' operational-status' of that bearer is reported as 'op-down', it should be expect ed that the 'oper-status' of services transported over that bearer is also down. These status values differing should trigger the detection of an anomaly condit ion.</t>
</dd> <t>See "<xref target="RFC9181" format="title"/>" <xref target="RFC91
<dt/> 81"/> for more details.</t>
<dd>
<t>See "A Common YANG Data Model for Layer 2 and Layer 3 VPNs" <xref
target="RFC9181"/> for more details.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="the-attachment-circuit-service-ietf-ac-svc-yang-module"> <section anchor="the-attachment-circuit-service-ietf-ac-svc-yang-module">
<name>The Attachment Circuit Service ("ietf-ac-svc") YANG Module</name> <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 <xre f target="AC-svc-Tree"/>. Subtrees are provided in the following subsections <t>The full tree diagram of the "ietf-ac-svc" module is provided in <xre f target="AC-svc-Tree"/>. Subtrees are provided in the following subsections
for the reader's convenience.</t> for the reader's convenience.</t>
<section anchor="overall-structure"> <section anchor="overall-structure">
<name>Overall Structure</name> <name>Overall Structure</name>
<t>The overall tree structure of the AC service module is shown in <xr ef target="o-svc-tree"/>.</t> <t>The overall tree structure of the AC service module is shown in <xr ef target="o-svc-tree"/>.</t>
<figure anchor="o-svc-tree"> <figure anchor="o-svc-tree">
<name>Overall AC Service Tree Structure</name> <name>Overall AC Service Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
+--rw specific-provisioning-profiles +--rw specific-provisioning-profiles
| ... | ...
+--rw service-provisioning-profiles +--rw service-provisioning-profiles
| ... | ...
+--rw attachment-circuits +--rw attachment-circuits
+--rw ac-group-profile* [name] +--rw ac-group-profile* [name]
| ... | ...
+--rw placement-constraints +--rw placement-constraints
| ... | ...
+--rw ac* [name] +--rw ac* [name]
skipping to change at line 1121 skipping to change at line 1208
+--rw ip-connection {ac-common:layer3-ac}? +--rw ip-connection {ac-common:layer3-ac}?
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The rationale for deciding whether a reusable grouping is included in this document or be moved into the AC common module <xref target="I-D.ietf-op sawg-teas-common-ac"/> is as follows:</t> <t>The rationale for deciding whether a reusable grouping is included in this document or moved into the AC common module <xref target="RFC9833"/> is as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Groupings that are reusable among the AC service module, AC net work module, other service models, and network models are included in the AC com mon module.</t> <t>Groupings that are reusable among the AC service module, AC net work module, and other service models and network models are included in the AC common module.</t>
</li> </li>
<li> <li>
<t>Groupings that are reusable only by other service models are ma intained in the "ietf-ac-svc" module.</t> <t>Groupings that are reusable only by other service models are ma intained in the "ietf-ac-svc" module.</t>
</li> </li>
</ul> </ul>
<t>Each AC is identified with a unique name ('../ac/name') within a do <t>Each AC is identified with a unique name ('../ac/name') within a do
main. The mapping between this AC and a local PE that terminates the AC is hidde main. The mapping between this AC and a local PE that terminates the AC is hidde
n to the application that makes use of the AC service model. This information is n to the application that makes use of the AC service model. This information is
internal to the Network controller. As such, the details about the (node-specif internal to the network controller. As such, the details about the (node-specif
ic) attachment interfaces are not exposed in this service model.</t> ic) attachment interfaces are not exposed in this service model.</t>
<t>The AC service model uses groupings and types defined in the AC com <t>The AC service model uses groupings and types defined in the AC com
mon model <xref target="I-D.ietf-opsawg-teas-common-ac"/> ('op-instructions', 'd mon model <xref target="RFC9833"/> ('op-instructions', 'dot1q', 'qinq', 'priorit
ot1q', 'qinq', 'priority-tagged', 'l2-tunnel-service', etc.). Therefore, the des y-tagged', 'l2-tunnel-service', etc.). Therefore, the descriptions of these node
criptions of these nodes are not reiterated in the following subsections.</t> s 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> <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>
<section anchor="sec-profiles"> <section anchor="sec-profiles">
<name>Service Profiles</name> <name>Service Profiles</name>
<section anchor="sec-profiles-desc"> <section anchor="sec-profiles-desc">
<name>Description</name> <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 pro files. The profiles definitions are similar to those defined in <xref target="RF C9181"/>, including: Quality of Service (QoS), BFD, forwarding, and routing prof iles. The exact definition of the profiles is local to each service provider. Th e model only includes an identifier for these profiles in order to facilitate id entifying and binding local policies when building an AC.</t> <t>The 'specific-provisioning-profiles' container (<xref target="gp- svc-tree"/>) can be used by a service provider to maintain a set of reusable pro files. The profiles definitions are similar to those defined in <xref target="RF C9181"/>, including: Quality of Service (QoS), BFD, forwarding, and routing prof iles. The exact definition of the profiles is local to each service provider. Th e model only includes an identifier for these profiles in order to facilitate id entifying and binding local policies when building an AC.</t>
<figure anchor="gp-svc-tree"> <figure anchor="gp-svc-tree">
<name>Service Profiles</name> <name>Service Profiles</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-svc module: ietf-ac-svc
+--rw specific-provisioning-profiles +--rw specific-provisioning-profiles
| +--rw valid-provider-identifiers | +--rw valid-provider-identifiers
| +--rw encryption-profile-identifier* [id] | +--rw encryption-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw qos-profile-identifier* [id] | +--rw qos-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw failure-detection-profile-identifier* [id] | +--rw failure-detection-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw forwarding-profile-identifier* [id] | +--rw forwarding-profile-identifier* [id]
skipping to change at line 1179 skipping to change at line 1266
+--rw ip-connection {ac-common:layer3-ac}? +--rw ip-connection {ac-common:layer3-ac}?
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>As shown in <xref target="gp-svc-tree"/>, two profile types can b e 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>As shown in <xref target="gp-svc-tree"/>, two profile types can b e 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 be defined:</t> <t>The following specific provisioning profiles can be defined as fo
<dl> llows:</t>
<dl spacing="normal" newline="false">
<dt>'encryption-profile-identifier':</dt> <dt>'encryption-profile-identifier':</dt>
<dd> <dd>
<t>Refers to a set of policies related to the encryption setup t hat can be applied when provisioning an AC.</t> <t>Refers to a set of policies related to the encryption setup t hat can be applied when provisioning an AC.</t>
</dd> </dd>
<dt>'qos-profile-identifier':</dt> <dt>'qos-profile-identifier':</dt>
<dd> <dd>
<t>Refers to a set of policies, such as classification, marking, and actions (e.g., <xref target="RFC3644"/>).</t> <t>Refers to a set of policies, such as classification, marking, and actions (e.g., <xref target="RFC3644"/>).</t>
</dd> </dd>
<dt>'failure-detection-profile-identifier':</dt> <dt>'failure-detection-profile-identifier':</dt>
<dd> <dd>
skipping to change at line 1208 skipping to change at line 1295
<t>Refers to the policies that apply to the forwarding of packet s conveyed within an AC. Such policies may consist, for example, of applying Acc ess Control Lists (ACLs).</t> <t>Refers to the policies that apply to the forwarding of packet s conveyed within an AC. Such policies may consist, for example, of applying Acc ess Control Lists (ACLs).</t>
</dd> </dd>
<dt>'routing-profile-identifier':</dt> <dt>'routing-profile-identifier':</dt>
<dd> <dd>
<t>Refers to a set of routing policies that will be invoked (e.g ., BGP policies) when building an AC.</t> <t>Refers to a set of routing policies that will be invoked (e.g ., BGP policies) when building an AC.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="referencing-servicespecific-profiles"> <section anchor="referencing-servicespecific-profiles">
<name>Referencing Service/Specific Profiles</name> <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 p rovider server by an identifier. To ease referencing these profiles by other dat a models, specific typedefs are defined for each of these profiles. Likewise, an attachment circuit reference typedef is defined when referencing a (global) att achment 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> <t>All the above mentioned profiles are uniquely identified by the p rovider server by an identifier. To ease referencing these profiles by other dat a models, specific typedefs are defined for each of these profiles. Likewise, an attachment circuit reference typedef is defined when referencing a (global) att achment 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> </section>
<section anchor="sec-acp"> <section anchor="sec-acp">
<name>Attachment Circuits Profiles</name> <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 a t the 'ac' level. <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 a t 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> 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>
<section anchor="sec-pc"> <section anchor="sec-pc">
<name>AC Placement Contraints</name> <name>AC Placement Constraints</name>
<t>The 'placement-constraints' specifies the placement constraints of an AC. For example, this container can be used to request avoidance of connectin g two ACs to the same PE. The full set of supported constraints is defined in <x ref target="RFC9181"/> (see 'placement-diversity', in particular).</t> <t>The 'placement-constraints' specifies the placement constraints of an AC. For example, this container can be used to request avoidance of connectin g two ACs to the same PE. The full set of supported constraints is defined in <x ref target="RFC9181"/> (see 'placement-diversity', in particular).</t>
<t>The structure of 'placement-constraints' is shown in <xref target=" precedence-tree"/>.</t> <t>The structure of 'placement-constraints' is shown in <xref target=" precedence-tree"/>.</t>
<figure anchor="precedence-tree"> <figure anchor="precedence-tree">
<name>Placement Constraints Subtree Structure</name> <name>Placement Constraints Subtree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
+--rw specific-provisioning-profiles +--rw specific-provisioning-profiles
| ... | ...
+--rw service-provisioning-profiles +--rw service-provisioning-profiles
| ... | ...
+--rw attachment-circuits +--rw attachment-circuits
+--rw ac-group-profile* [name] +--rw ac-group-profile* [name]
| ... | ...
+--rw placement-constraints +--rw placement-constraints
| +--rw constraint* [constraint-type] | +--rw constraint* [constraint-type]
| +--rw constraint-type identityref | +--rw constraint-type identityref
skipping to change at line 1244 skipping to change at line 1343
| +--rw (target-flavor)? | +--rw (target-flavor)?
| +--:(id) | +--:(id)
| | +--rw group* [group-id] | | +--rw group* [group-id]
| | +--rw group-id string | | +--rw group-id string
| +--:(all-accesses) | +--:(all-accesses)
| | +--rw all-other-accesses? empty | | +--rw all-other-accesses? empty
| +--:(all-groups) | +--:(all-groups)
| +--rw all-other-groups? empty | +--rw all-other-groups? empty
+--rw ac* [name] +--rw ac* [name]
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="attachment-circuits"> <section anchor="attachment-circuits">
<name>Attachment Circuits</name> <name>Attachment Circuits</name>
<t>The structure of 'attachment-circuits' is shown in <xref target="ac -svc-tree"/>.</t> <t>The structure of 'attachment-circuits' is shown in <xref target="ac -svc-tree"/>.</t>
<figure anchor="ac-svc-tree"> <figure anchor="ac-svc-tree">
<name>Attachment Circuits Tree Structure</name> <name>Attachment Circuits Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
+--rw specific-provisioning-profiles +--rw specific-provisioning-profiles
| ... | ...
+--rw service-provisioning-profiles +--rw service-provisioning-profiles
| ... | ...
+--rw attachment-circuits +--rw attachment-circuits
+--rw ac-group-profile* [name] +--rw ac-group-profile* [name]
| ... | ...
+--rw placement-constraints +--rw placement-constraints
| ... | ...
+--rw customer-name? string +--rw customer-name? string
skipping to change at line 1302 skipping to change at line 1401
+--rw ip-connection {ac-common:layer3-ac}? +--rw ip-connection {ac-common:layer3-ac}?
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>A request may also include some timing constraints ('requested-star t', 'requested-stop') that are applicable for a set of ACs. The timing constrain ts can be adjusted at the 'ac' level. These adjusted values take precedence over the global values.</t> <t>A request may also include some timing constraints ('requested-star t', 'requested-stop') that are applicable for a set of ACs. The timing constrain ts can be adjusted at the 'ac' level. These adjusted values take precedence over the global values.</t>
<t>The description of the 'ac' data nodes is as follows:</t> <t>The 'ac' data nodes are described as follows:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'customer-name':</dt> <dt>'customer-name':</dt>
<dd> <dd>
<t>Indicates the name of the customer who ordered the AC or a set of ACs.</t> <t>Indicates the name of the customer who ordered the AC or a set of ACs.</t>
</dd> </dd>
<dt>'description':</dt> <dt>'description':</dt>
<dd> <dd>
<t>Includes a textual description of the AC.</t> <t>Includes a textual description of the AC.</t>
</dd> </dd>
<dt>'test-only':</dt> <dt>'test-only':</dt>
<dd> <dd>
<t>Indicates that a request is only for validation test and not fo r 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 protocols wh ich do not have built-in support of such option.</t> <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 check s. This data node is applicable only when the data model is used with protocols that do not have built-in support of such option.</t>
</dd> </dd>
<dt>'requested-start':</dt> <dt>'requested-start':</dt>
<dd> <dd>
<t>Specifies the requested date and time when the attachment circu it is expected to be active.</t> <t>Specifies the requested date and time when the attachment circu it is expected to be active.</t>
</dd> </dd>
<dt>'requested-stop':</dt> <dt>'requested-stop':</dt>
<dd> <dd>
<t>Specifies the requested date and time when the attachment circu it is expected to be disabled.</t> <t>Specifies the requested date and time when the attachment circu it is expected to be disabled.</t>
</dd> </dd>
<dt>'actual-start':</dt> <dt>'actual-start':</dt>
skipping to change at line 1350 skipping to change at line 1449
<dd> <dd>
<t>Includes references to the remote endpoints of an attachment ci rcuit <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> <t>Includes references to the remote endpoints of an attachment ci rcuit <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> </dd>
<dt>'group-profile-ref':</dt> <dt>'group-profile-ref':</dt>
<dd> <dd>
<t>Indicates references to one or more profiles that are defined i n <xref target="sec-acp"/>.</t> <t>Indicates references to one or more profiles that are defined i n <xref target="sec-acp"/>.</t>
</dd> </dd>
<dt>'parent-ref':</dt> <dt>'parent-ref':</dt>
<dd> <dd>
<t>Specifies an AC that is inherited by an attachment circuit.</t> <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, <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 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 boun d to the parent AC, which is exposed to services (as a stable reference).</t> "child" ACs are defined to track dynamic information. These "child" ACs are boun d 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>MUS T</bcp14> be deleted.</t> <t>Whenever a parent AC is deleted, all its "child" ACs <bcp14>MUS T</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 <bc p14>MUST NOT</bcp14> be overlapping. An example to illustrate the use of multipl e parent ACs is provided in <xref target="sec-bfd-static"/>.</t> <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 <bc p14>MUST NOT</bcp14> be overlapping. An example to illustrate the use of multipl e parent ACs is provided in <xref target="sec-bfd-static"/>.</t>
</dd> </dd>
<dt>'child-ref':</dt> <dt>'child-ref':</dt>
<dd> <dd>
<t>Lists one or more references of child ACs that rely upon this a ttachment circuit as a parent AC.</t> <t>Lists one or more references of child ACs that rely upon this a ttachment circuit as a parent AC.</t>
</dd> </dd>
<dt>'group':</dt> <dt>'group':</dt>
<dd> <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 con straints of ACs. An example is provided in <xref target="sec-ex-prec"/>.</t> <t>Lists the groups to which an AC belongs <xref target="RFC9181"/ >. For example, the 'group-id' is used to associate redundancy or protection con straints of ACs. An example is provided in <xref target="sec-ex-prec"/>.</t>
</dd> </dd>
skipping to change at line 1416 skipping to change at line 1506
<dd> <dd>
<t>See <xref target="sec-sec"/>.</t> <t>See <xref target="sec-sec"/>.</t>
</dd> </dd>
<dt>'service':</dt> <dt>'service':</dt>
<dd> <dd>
<t>See <xref target="sec-bw"/>.</t> <t>See <xref target="sec-bw"/>.</t>
</dd> </dd>
</dl> </dl>
<section anchor="sec-l2"> <section anchor="sec-l2">
<name>Layer 2 Connection Structure</name> <name>Layer 2 Connection Structure</name>
<t>The 'l2-connection' container (<xref target="l2-svc-tree"/>) is u sed to configure the relevant Layer 2 properties of an AC including: encapsulati on details and tunnel terminations. For the encapsulation details, the model sup ports the definition of the type as well as the Identifiers (e.g., VLAN-IDs) of each of the encapsulation-type defined. For the second case, attributes for pseu dowire, Virtual Private LAN Service (VPLS), and Virtual eXtensible Local Area N etwork (VXLAN) tunnel terminations are included.</t> <t>The 'l2-connection' container (<xref target="l2-svc-tree"/>) is u sed to configure the relevant Layer 2 properties of an AC, including encapsulati on details and tunnel terminations. For the encapsulation details, the model sup ports the definition of the type as well as the identifiers (e.g., VLAN-IDs) of each of the encapsulation-type defined. For the second case, attributes for pseu dowire, Virtual Private LAN Service (VPLS), and Virtual eXtensible Local Area N etwork (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>'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 <xref target="I-D.ietf-opsawg-teas-common-ac"/>.</t> <t>This structure relies upon the common groupings defined in <xref target="RFC9833"/>.</t>
<figure anchor="l2-svc-tree"> <figure anchor="l2-svc-tree">
<name>Layer 2 Connection Tree Structure</name> <name>Layer 2 Connection Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
+--rw specific-provisioning-profiles +--rw specific-provisioning-profiles
| ... | ...
+--rw service-provisioning-profiles +--rw service-provisioning-profiles
| ... | ...
+--rw attachment-circuits +--rw attachment-circuits
+--rw ac-group-profile* [name] +--rw ac-group-profile* [name]
| ... | ...
+--rw placement-constraints +--rw placement-constraints
| ... | ...
+--rw ac* [name] +--rw ac* [name]
skipping to change at line 1474 skipping to change at line 1564
+--rw ip-connection {ac-common:layer3-ac}? +--rw ip-connection {ac-common:layer3-ac}?
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="sec-l3"> <section anchor="sec-l3">
<name>IP Connection Structure</name> <name>IP Connection Structure</name>
<t>The 'ip-connection' container is used to configure the relevant I P properties of an AC. The model supports the usage of dynamic and static addres sing. This structure relies upon the common groupings defined in <xref section=" 4.3" sectionFormat="of" target="I-D.ietf-opsawg-teas-common-ac"/>. Both IPv4 and IPv6 parameters are supported.</t> <t>The 'ip-connection' container is used to configure the relevant I P properties of an AC. The model supports the usage of dynamic and static addres sing. This structure relies upon the common groupings defined in <xref section=" 4.3" sectionFormat="of" target="RFC9833"/>. Both IPv4 and IPv6 parameters are su pported.</t>
<t>For ACs that require Layer 3 tunnel establishment, the ACaaS incl udes a provision for future augmentations to define <t>For ACs that require Layer 3 tunnel establishment, the ACaaS incl udes 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> 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 co nnection.</t> <t><xref target="ipv4-svc-tree"/> shows the structure of the IPv4 co nnection.</t>
<figure anchor="ipv4-svc-tree"> <figure anchor="ipv4-svc-tree">
<name>Layer 3 Connection Tree Structure (IPv4)</name> <name>Layer 3 Connection Tree Structure (IPv4)</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
| ... | ...
+--rw ip-connection {ac-common:layer3-ac}? +--rw ip-connection {ac-common:layer3-ac}?
| +--rw ipv4 {vpn-common:ipv4}? | +--rw ipv4 {vpn-common:ipv4}?
| | +--rw local-address? | | +--rw local-address?
| | | inet:ipv4-address | | | inet:ipv4-address
| | +--rw virtual-address? | | +--rw virtual-address?
| | | inet:ipv4-address | | | inet:ipv4-address
| | +--rw prefix-length? uint8 | | +--rw prefix-length? uint8
| | +--rw address-allocation-type? | | +--rw address-allocation-type?
| | | identityref | | | identityref
skipping to change at line 1531 skipping to change at line 1621
| | +--rw customer-address? inet:ipv4-address | | +--rw customer-address? inet:ipv4-address
| | +--rw failure-detection-profile? | | +--rw failure-detection-profile?
| | failure-detection-profile-reference | | failure-detection-profile-reference
| | {vpn-common:bfd}? | | {vpn-common:bfd}?
| +--rw ipv6 {vpn-common:ipv6}? | +--rw ipv6 {vpn-common:ipv6}?
| | ... | | ...
| +--rw (l3-service)? | +--rw (l3-service)?
| +--:(l3-tunnel-service) | +--:(l3-tunnel-service)
| +--rw l3-tunnel-service | +--rw l3-tunnel-service
| +--rw type? identityref | +--rw type? identityref
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="ipv6-svc-tree"/> shows the structure of the IPv6 co nnection.</t> <t><xref target="ipv6-svc-tree"/> shows the structure of the IPv6 co nnection.</t>
<figure anchor="ipv6-svc-tree"> <figure anchor="ipv6-svc-tree">
<name>Layer 3 Connection Tree Structure (IPv6)</name> <name>Layer 3 Connection Tree Structure (IPv6)</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
| ... | ...
+--rw ip-connection {ac-common:layer3-ac}? +--rw ip-connection {ac-common:layer3-ac}?
| +--rw ipv4 {vpn-common:ipv4}? | +--rw ipv4 {vpn-common:ipv4}?
| | ... | | ...
| +--rw ipv6 {vpn-common:ipv6}? | +--rw ipv6 {vpn-common:ipv6}?
| | +--rw local-address? | | +--rw local-address?
| | | inet:ipv6-address | | | inet:ipv6-address
| | +--rw virtual-address? | | +--rw virtual-address?
| | | inet:ipv6-address | | | inet:ipv6-address
| | +--rw prefix-length? uint8 | | +--rw prefix-length? uint8
skipping to change at line 1583 skipping to change at line 1673
| | +--rw address-id string | | +--rw address-id string
| | +--rw customer-address? inet:ipv6-address | | +--rw customer-address? inet:ipv6-address
| | +--rw failure-detection-profile? | | +--rw failure-detection-profile?
| | failure-detection-profile-reference | | failure-detection-profile-reference
| | {vpn-common:bfd}? | | {vpn-common:bfd}?
| +--rw (l3-service)? | +--rw (l3-service)?
| +--:(l3-tunnel-service) | +--:(l3-tunnel-service)
| +--rw l3-tunnel-service | +--rw l3-tunnel-service
| +--rw type? identityref | +--rw type? identityref
| ... | ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="sec-rtg"> <section anchor="sec-rtg">
<name>Routing</name> <name>Routing</name>
<t>As shown in the tree depicted in <xref target="rtg-svc-tree"/>, t he 'routing-protocols' container defines the required parameters to enable the d esired routing features for an AC. One or more routing protocols can be associat ed with an AC. Such routing protocols will be then enabled between a PE and the customer termination points. Each routing instance is uniquely identified by th e combination of the 'id' and 'type' to accommodate scenarios where multiple ins tances of the same routing protocol have to be configured on the same link.</t> <t>As shown in the tree depicted in <xref target="rtg-svc-tree"/>, t he 'routing-protocols' container defines the required parameters to enable the d esired routing features for an AC. One or more routing protocols can be associat ed with an AC. Such routing protocols will then be enabled between a PE and the customer termination points. Each routing instance is uniquely identified by th e combination of the 'id' and 'type' to accommodate scenarios where multiple ins tances 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' de fined in <xref target="sec-profiles"/>, so that additional constraints can be ap plied to a specific instance of each routing protocol. Moreover, the module supp orts VRRP (<xref target="sec-vrrp-rtg"/>).</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' de fined in <xref target="sec-profiles"/>, so that additional constraints can be ap plied to a specific instance of each routing protocol. Moreover, the module supp orts VRRP (<xref target="sec-vrrp-rtg"/>).</t>
<figure anchor="rtg-svc-tree"> <figure anchor="rtg-svc-tree">
<name>Routing Tree Structure</name> <name>Routing Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
+--rw specific-provisioning-profiles +--rw specific-provisioning-profiles
| ... | ...
+--rw service-provisioning-profiles +--rw service-provisioning-profiles
| ... | ...
+--rw attachment-circuits +--rw attachment-circuits
+--rw ac-group-profile* [name] +--rw ac-group-profile* [name]
| ... | ...
+--rw placement-constraints +--rw placement-constraints
| ... | ...
+--rw ac* [name] +--rw ac* [name]
skipping to change at line 1633 skipping to change at line 1723
| +--rw rip {vpn-common:rtg-rip}? | +--rw rip {vpn-common:rtg-rip}?
| | ... | | ...
| +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw vrrp {vpn-common:rtg-vrrp}?
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<section anchor="sec-static-rtg"> <section anchor="sec-static-rtg">
<name>Static Routing</name> <name>Static Routing</name>
<t>The static tree structure is shown in <xref target="static-rtg- svc-tree"/>.</t> <t>The static tree structure is shown in <xref target="static-rtg- svc-tree"/>.</t>
<figure anchor="static-rtg-svc-tree"> <figure anchor="static-rtg-svc-tree">
<name>Static Routing Tree Structure</name> <name>Static Routing Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw routing-profiles* [id] | +--rw routing-profiles* [id]
| | +--rw id routing-profile-reference | | +--rw id routing-profile-reference
| | +--rw type? identityref | | +--rw type? identityref
| +--rw static | +--rw static
| | +--rw cascaded-lan-prefixes | | +--rw cascaded-lan-prefixes
skipping to change at line 1695 skipping to change at line 1785
| +--rw bgp {vpn-common:rtg-bgp}? | +--rw bgp {vpn-common:rtg-bgp}?
| | ... | | ...
| +--rw ospf {vpn-common:rtg-ospf}? | +--rw ospf {vpn-common:rtg-ospf}?
| | ... | | ...
| +--rw isis {vpn-common:rtg-isis}? | +--rw isis {vpn-common:rtg-isis}?
| | ... | | ...
| +--rw rip {vpn-common:rtg-rip}? | +--rw rip {vpn-common:rtg-rip}?
| | ... | | ...
| +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw vrrp {vpn-common:rtg-vrrp}?
| ... | ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>As depicted in <xref target="static-rtg-svc-tree"/>, the follow ing data nodes can be defined for a given IP prefix:</t> <t>As depicted in <xref target="static-rtg-svc-tree"/>, the follow ing data nodes can be defined for a given IP prefix:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'lan-tag':</dt> <dt>'lan-tag':</dt>
<dd> <dd>
<t>Indicates a local tag (e.g., "myfavorite-lan") that is used to enforce local policies.</t> <t>Indicates a local tag (e.g., "myfavorite-lan") that is used to enforce local policies.</t>
</dd> </dd>
<dt>'next-hop':</dt> <dt>'next-hop':</dt>
<dd> <dd>
<t>Indicates the next hop to be used for the static route.</t> <t>Indicates the next hop to be used for the static route.</t>
</dd>
<dt/>
<dd>
<t>It can be identified by an IP address, a predefined next-ho p type (e.g., 'discard' or 'local-link'), etc.</t> <t>It can be identified by an IP address, a predefined next-ho p type (e.g., 'discard' or 'local-link'), etc.</t>
</dd> </dd>
<dt>'metric':</dt> <dt>'metric':</dt>
<dd> <dd>
<t>Indicates the metric associated with the static route entry . This metric is used when the route is exported into an IGP.</t> <t>Indicates the metric associated with the static route entry . This metric is used when the route is exported into an IGP.</t>
</dd> </dd>
<dt>'failure-detection-profile':</dt> <dt>'failure-detection-profile':</dt>
<dd> <dd>
<t>Indicates a failure detection profile (e.g., BFD) that appl ies for this entry.</t> <t>Indicates a failure detection profile (e.g., BFD) that appl ies for this entry.</t>
</dd> </dd>
skipping to change at line 1724 skipping to change at line 1811
</dd> </dd>
<dt>'failure-detection-profile':</dt> <dt>'failure-detection-profile':</dt>
<dd> <dd>
<t>Indicates a failure detection profile (e.g., BFD) that appl ies for this entry.</t> <t>Indicates a failure detection profile (e.g., BFD) that appl ies for this entry.</t>
</dd> </dd>
<dt>'status':</dt> <dt>'status':</dt>
<dd> <dd>
<t>Used to convey the status of a static route entry. This dat a node can also be used to control the (de)activation of individual static route entries.</t> <t>Used to convey the status of a static route entry. This dat a node can also be used to control the (de)activation of individual static route entries.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-bgp-rtg"> <section anchor="sec-bgp-rtg">
<name>BGP</name> <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. <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 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 ease the process of automating the provisioning of BGP sessions (the cu stomer does not use the primary IP address 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 u sed to establish the BGP session, to establish the underlying BGP session, communicate the provider's IP address u sed to establish the BGP session,
share authentication parameters, bind the session to a forwarding protection pro file, etc.).</t> share authentication parameters, bind the session to a forwarding protection pro file, etc.).</t>
<t>The BGP tree structure is shown in <xref target="bgp-rtg-svc-tr ee"/>.</t> <t>The BGP tree structure is shown in <xref target="bgp-rtg-svc-tr ee"/>.</t>
<figure anchor="bgp-rtg-svc-tree"> <figure anchor="bgp-rtg-svc-tree">
<name>BGP Tree Structure</name> <name>BGP Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw routing-profiles* [id] | +--rw routing-profiles* [id]
| | +--rw id routing-profile-reference | | +--rw id routing-profile-reference
| | +--rw type? identityref | | +--rw type? identityref
| +--rw static | +--rw static
| | ... | | ...
skipping to change at line 1824 skipping to change at line 1912
| | failure-detection-profile-reference | | failure-detection-profile-reference
| | {vpn-common:bfd}? | | {vpn-common:bfd}?
| +--rw ospf {vpn-common:rtg-ospf}? | +--rw ospf {vpn-common:rtg-ospf}?
| | ... | | ...
| +--rw isis {vpn-common:rtg-isis}? | +--rw isis {vpn-common:rtg-isis}?
| | ... | | ...
| +--rw rip {vpn-common:rtg-rip}? | +--rw rip {vpn-common:rtg-rip}?
| | ... | | ...
| +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw vrrp {vpn-common:rtg-vrrp}?
| ... | ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>For deployment cases where an AC service request includes a lis t of neighbors with redundant information, <t>For deployment cases where an AC service request includes a lis t of neighbors with redundant information,
the ACaaS allows to factorize shared data by means of 'peer-group'. The presence of 'peer-groups' in a service request is thus optional.</t> the ACaaS allows factorizing shared data by means of 'peer-group'. Thus, the pre sence of 'peer-groups' in a service request is optional.</t>
<t>The following data nodes are supported for each BGP 'peer-group ':</t> <t>The following data nodes are supported for each BGP 'peer-group ':</t>
<dl> <dl spacing="normal" newline="false">
<dt>'name':</dt> <dt>'name':</dt>
<dd> <dd>
<t>Defines a name for the peer group.</t> <t>Defines a name for the peer group.</t>
</dd> </dd>
<dt>'local-as':</dt> <dt>'local-as':</dt>
<dd> <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> <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> </dd>
<dt>'peer-as':</dt> <dt>'peer-as':</dt>
<dd> <dd>
<t>Indicates the customer's ASN. This information is used at t he provider side to configure the BGP session with the customer equipment.</t> <t>Indicates the customer's ASN. This information is used at t he provider side to configure the BGP session with the customer equipment.</t>
</dd> </dd>
<dt>'address-family':</dt> <dt>'address-family':</dt>
<dd> <dd>
<t>Indicates the address family of the peer. It can be set to 'ipv4', 'ipv6', or 'dual-stack'.</t> <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 Identi fiers (SAFIs) that will be part of the derived device configurations (e.g., unic ast IPv4 MPLS L3VPN (AFI,SAFI = 1,128) as defined in <xref section="4.3.4" secti onFormat="of" target="RFC4364"/>).</t> <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 Identi fiers (SAFIs) that will be part of the derived device configurations (e.g., unic ast IPv4 MPLS L3VPN (AFI,SAFI = 1,128) as defined in <xref section="4.3.4" secti onFormat="of" target="RFC4364"/>).</t>
</dd> </dd>
<dt>'role':</dt> <dt>'role':</dt>
<dd> <dd>
<t>Specifies the BGP role in a session. Role values are taken from the list defined in <xref section="4" sectionFormat="of" target="RFC9234"/> . This parameter is useful for interconnection scenarios.</t> <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> <t>This is an optional parameter.</t>
</dd> </dd>
<dt>'local-address':</dt> <dt>'local-address':</dt>
<dd> <dd>
<t>Reports a provider's IP address to use to establish the BGP transport session.</t> <t>Reports a provider's IP address to use to establish the BGP transport session.</t>
</dd> </dd>
<dt>'bgp-max-prefix':</dt> <dt>'bgp-max-prefix':</dt>
<dd> <dd>
<t>Indicates the maximum number of BGP prefixes allowed in a s ession for this group.</t> <t>Indicates the maximum number of BGP prefixes allowed in a s ession for this group.</t>
</dd> </dd>
<dt>'authentication':</dt> <dt>'authentication':</dt>
<dd> <dd>
<t>The module adheres to the recommendations in <xref section= "13.2" sectionFormat="of" target="RFC4364"/>, as it allows enabling the TCP Auth entication Option (TCP-AO) <xref target="RFC5925"/> and accommodates the install ed base that makes use of MD5.</t> <t>The module adheres to the recommendations in <xref section= "13.2" sectionFormat="of" target="RFC4364"/>, as it allows enabling the TCP Auth entication Option (TCP-AO) <xref target="RFC5925"/> and accommodates the install ed base that makes use of MD5.</t>
</dd>
<dt/>
<dd>
<t>Similar to <xref target="RFC9182"/>, this version of the AC aaS 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 s uch 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" ta rget="RFC5925"/>).</t> <t>Similar to <xref target="RFC9182"/>, this version of the AC aaS 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 s uch 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" ta rget="RFC5925"/>).</t>
</dd> </dd>
</dl> </dl>
<t>For each neighbor, the following data nodes are supported in ad dition to similar parameters that are provided for a peer group:</t> <t>For each neighbor, the following data nodes are supported in ad dition to similar parameters that are provided for a peer group:</t>
<dl> <dl>
<dt>'server-reference':</dt> <dt>'server-reference':</dt>
<dd> <dd>
<t>Reports the internal reference that is assigned by the prov ider for this BGP session. This is an optional parameter.</t> <t>Reports the internal reference that is assigned by the prov ider for this BGP session. This is an optional parameter.</t>
</dd> </dd>
<dt>'remote-address':</dt> <dt>'remote-address':</dt>
<dd> <dd>
<t>Specifies the customer's IP address used to establishing th <t>Specifies the customer's IP address used to establish this
is BGP session. If not present, this means that the primary BGP session. If not present, this means that the primary
customer IP address is used as remote IP address.</t> customer IP address is used as the remote IP address.</t>
</dd> </dd>
<dt>'requested-start':</dt> <dt>'requested-start':</dt>
<dd> <dd>
<t>Specifies the requested date and time when the BGP session is expected to be active.</t> <t>Specifies the requested date and time when the BGP session is expected to be active.</t>
</dd> </dd>
<dt>'requested-stop':</dt> <dt>'requested-stop':</dt>
<dd> <dd>
<t>Specifies the requested date and time when the BGP session is expected to be disabled.</t> <t>Specifies the requested date and time when the BGP session is expected to be disabled.</t>
</dd> </dd>
<dt>'actual-start':</dt> <dt>'actual-start':</dt>
skipping to change at line 1909 skipping to change at line 1989
<dd> <dd>
<t>Reports the actual date and time when the BGP session actua lly was disabled.</t> <t>Reports the actual date and time when the BGP session actua lly was disabled.</t>
</dd> </dd>
<dt>'status':</dt> <dt>'status':</dt>
<dd> <dd>
<t>Indicates the status of the BGP routing instance.</t> <t>Indicates the status of the BGP routing instance.</t>
</dd> </dd>
<dt>'peer-group':</dt> <dt>'peer-group':</dt>
<dd> <dd>
<t>Specifies a name of a peer group.</t> <t>Specifies a name of a peer group.</t>
</dd> <t>Parameters that are provided at the 'neighbor' level take p
<dt/> recedence over the ones provided in the peer group.</t>
<dd>
<t>Parameters that are provided at the 'neighbor' level takes
precedence over the ones provided in the peer group.</t>
</dd>
<dt/>
<dd>
<t>This is an optional parameter.</t> <t>This is an optional parameter.</t>
</dd> </dd>
<dt>'failure-detection-profile':</dt> <dt>'failure-detection-profile':</dt>
<dd> <dd>
<t>Indicates a failure detection profile (BFD) that applies fo r a BGP neighbor. This is an optional parameter.</t> <t>Indicates a failure detection profile (BFD) that applies fo r a BGP neighbor. This is an optional parameter.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-ospf-rtg"> <section anchor="sec-ospf-rtg">
<name>OSPF</name> <name>OSPF</name>
<t>The OSPF tree structure is shown in <xref target="ospf-rtg-svc- tree"/>.</t> <t>The OSPF tree structure is shown in <xref target="ospf-rtg-svc- tree"/>.</t>
<figure anchor="ospf-rtg-svc-tree"> <figure anchor="ospf-rtg-svc-tree">
<name>OSPF Tree Structure</name> <name>OSPF Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw routing-profiles* [id] | +--rw routing-profiles* [id]
| | +--rw id routing-profile-reference | | +--rw id routing-profile-reference
| | +--rw type? identityref | | +--rw type? identityref
| +--rw static | +--rw static
| | ... | | ...
skipping to change at line 1970 skipping to change at line 2044
| | | +--ro last-change? yang:date-and-time | | | +--ro last-change? yang:date-and-time
| | +--ro oper-status | | +--ro oper-status
| | +--ro status? identityref | | +--ro status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
| +--rw isis {vpn-common:rtg-isis}? | +--rw isis {vpn-common:rtg-isis}?
| | ... | | ...
| +--rw rip {vpn-common:rtg-rip}? | +--rw rip {vpn-common:rtg-rip}?
| | ... | | ...
| +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw vrrp {vpn-common:rtg-vrrp}?
| ... | ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The following OSPF data nodes are supported:</t> <t>The following OSPF data nodes are supported:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'address-family':</dt> <dt>'address-family':</dt>
<dd> <dd>
<t>Indicates whether IPv4, IPv6, or both address families are to be activated.</t> <t>Indicates whether IPv4, IPv6, or both address families are to be activated.</t>
</dd> </dd>
<dt>'area-id':</dt> <dt>'area-id':</dt>
<dd> <dd>
<t>Indicates the OSPF Area ID.</t> <t>Indicates the OSPF Area ID.</t>
</dd> </dd>
<dt>'metric':</dt> <dt>'metric':</dt>
<dd> <dd>
skipping to change at line 2005 skipping to change at line 2079
<dd> <dd>
<t>Indicates the status of the OSPF routing instance.</t> <t>Indicates the status of the OSPF routing instance.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-isis-rtg"> <section anchor="sec-isis-rtg">
<name>IS-IS</name> <name>IS-IS</name>
<t>The IS-IS tree structure is shown in <xref target="isis-rtg-svc -tree"/>.</t> <t>The IS-IS tree structure is shown in <xref target="isis-rtg-svc -tree"/>.</t>
<figure anchor="isis-rtg-svc-tree"> <figure anchor="isis-rtg-svc-tree">
<name>IS-IS Tree Structure</name> <name>IS-IS Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw routing-profiles* [id] | +--rw routing-profiles* [id]
| | +--rw id routing-profile-reference | | +--rw id routing-profile-reference
| | +--rw type? identityref | | +--rw type? identityref
| +--rw static | +--rw static
| | ... | | ...
skipping to change at line 2045 skipping to change at line 2119
| | +--rw admin-status | | +--rw admin-status
| | | +--rw status? identityref | | | +--rw status? identityref
| | | +--ro last-change? yang:date-and-time | | | +--ro last-change? yang:date-and-time
| | +--ro oper-status | | +--ro oper-status
| | +--ro status? identityref | | +--ro status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
| +--rw rip {vpn-common:rtg-rip}? | +--rw rip {vpn-common:rtg-rip}?
| | ... | | ...
| +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw vrrp {vpn-common:rtg-vrrp}?
| ... | ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The following IS-IS data nodes are supported:</t> <t>The following IS-IS data nodes are supported:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'address-family':</dt> <dt>'address-family':</dt>
<dd> <dd>
<t>Indicates whether IPv4, IPv6, or both address families are to be activated.</t> <t>Indicates whether IPv4, IPv6, or both address families are to be activated.</t>
</dd> </dd>
<dt>'area-address':</dt> <dt>'area-address':</dt>
<dd> <dd>
<t>Indicates the IS-IS area address.</t> <t>Indicates the IS-IS area address.</t>
</dd> </dd>
<dt>'authentication':</dt> <dt>'authentication':</dt>
<dd> <dd>
skipping to change at line 2075 skipping to change at line 2149
<dd> <dd>
<t>Indicates the status of the IS-IS routing instance.</t> <t>Indicates the status of the IS-IS routing instance.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-rip-rtg"> <section anchor="sec-rip-rtg">
<name>RIP</name> <name>RIP</name>
<t>The RIP tree structure is shown in <xref target="rip-rtg-svc-tr ee"/>.</t> <t>The RIP tree structure is shown in <xref target="rip-rtg-svc-tr ee"/>.</t>
<figure anchor="rip-rtg-svc-tree"> <figure anchor="rip-rtg-svc-tree">
<name>RIP Tree Structure</name> <name>RIP Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw routing-profiles* [id] | +--rw routing-profiles* [id]
| | +--rw id routing-profile-reference | | +--rw id routing-profile-reference
| | +--rw type? identityref | | +--rw type? identityref
| +--rw static | +--rw static
| | ... | | ...
skipping to change at line 2113 skipping to change at line 2187
| | | +--rw crypto-algorithm? identityref | | | +--rw crypto-algorithm? identityref
| | +--rw status | | +--rw status
| | +--rw admin-status | | +--rw admin-status
| | | +--rw status? identityref | | | +--rw status? identityref
| | | +--ro last-change? yang:date-and-time | | | +--ro last-change? yang:date-and-time
| | +--ro oper-status | | +--ro oper-status
| | +--ro status? identityref | | +--ro status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
| +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw vrrp {vpn-common:rtg-vrrp}?
| ... | ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>'address-family' indicates whether IPv4, IPv6, or both address families are to be activated. For example, this parameter is used to determine w hether RIPv2 <xref target="RFC2453"/>, RIP Next Generation (RIPng) <xref target= "RFC2080"/>, or both are to be enabled.</t> <t>'address-family' indicates whether IPv4, IPv6, or both address families are to be activated. For example, this parameter is used to determine w hether RIPv2 <xref target="RFC2453"/>, RIP Next Generation (RIPng) <xref target= "RFC2080"/>, or both are to be enabled.</t>
</section> </section>
<section anchor="sec-vrrp-rtg"> <section anchor="sec-vrrp-rtg">
<name>VRRP</name> <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> <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"> <figure anchor="vrrp-rtg-svc-tree">
<name>VRRP Tree Structure</name> <name>VRRP Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw routing-profiles* [id] | +--rw routing-profiles* [id]
| | +--rw id routing-profile-reference | | +--rw id routing-profile-reference
| | +--rw type? identityref | | +--rw type? identityref
| +--rw static | +--rw static
| | ... | | ...
skipping to change at line 2150 skipping to change at line 2224
| | ... | | ...
| +--rw vrrp {vpn-common:rtg-vrrp}? | +--rw vrrp {vpn-common:rtg-vrrp}?
| +--rw address-family? identityref | +--rw address-family? identityref
| +--rw status | +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The following data nodes are supported:</t> <t>The following data nodes are supported:</t>
<dl> <dl newline="false" spacing="normal">
<dt>'address-family':</dt> <dt>'address-family':</dt>
<dd> <dd>
<t>Indicates whether IPv4, IPv6, or both address <t>Indicates whether IPv4, IPv6, or both address families
families are to be activated. Note that VRRP version 3 <xref target="RFC956 are to be activated. Note that VRRP version 3 <xref
8"/> target="RFC9568"/> supports both IPv4 and IPv6.</t>
supports both IPv4 and IPv6.</t>
</dd> </dd>
<dt>'status':</dt> <dt>'status':</dt>
<dd> <dd>
<t>Indicates the status of the VRRP instance.</t> <t>Indicates the status of the VRRP instance.</t>
</dd> </dd>
</dl> </dl>
<t>Note that no authentication data node is included for VRRP, as there <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" sectio nFormat="of" target="RFC9568"/>).</t> isn't any type of VRRP authentication at this time (see <xref section="9" sectio nFormat="of" target="RFC9568"/>).</t>
</section> </section>
</section> </section>
<section anchor="sec-oam"> <section anchor="sec-oam">
<name>Operations, Administration, and Maintenance (OAM)</name> <name>Operations, Administration, and Maintenance (OAM)</name>
<t>As shown in the tree depicted in <xref target="oam-svc-tree"/>, t he 'oam' container defines OAM-related parameters of an AC.</t> <t>As shown in the tree depicted in <xref target="oam-svc-tree"/>, t he 'oam' container defines OAM-related parameters of an AC.</t>
<figure anchor="oam-svc-tree"> <figure anchor="oam-svc-tree">
<name>OAM Tree Structure</name> <name>OAM Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
+--rw specific-provisioning-profiles +--rw specific-provisioning-profiles
| ... | ...
+--rw service-provisioning-profiles +--rw service-provisioning-profiles
| ... | ...
+--rw attachment-circuits +--rw attachment-circuits
+--rw ac-group-profile* [name] +--rw ac-group-profile* [name]
| ... | ...
+--rw placement-constraints +--rw placement-constraints
| ... | ...
+--rw ac* [name] +--rw ac* [name]
skipping to change at line 2212 skipping to change at line 2286
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>This version of the module supports BFD. The following BFD data n odes can be specified:</t> <t>This version of the module supports BFD. The following BFD data n odes can be specified:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'id':</dt> <dt>'id':</dt>
<dd> <dd>
<t>An identifier that uniquely identifies a BFD session.</t> <t>An identifier that uniquely identifies a BFD session.</t>
</dd> </dd>
<dt>'local-address':</dt> <dt>'local-address':</dt>
<dd> <dd>
<t>Indicates the provider's IP address used for a BFD session.</ t> <t>Indicates the provider's IP address used for a BFD session.</ t>
</dd> </dd>
<dt>'remote-address':</dt> <dt>'remote-address':</dt>
<dd> <dd>
skipping to change at line 2247 skipping to change at line 2321
<dd> <dd>
<t>Indicates the status of the BFD session.</t> <t>Indicates the status of the BFD session.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-sec"> <section anchor="sec-sec">
<name>Security</name> <name>Security</name>
<t>As shown in the tree depicted in <xref target="sec-svc-tree"/>, t he 'security' container defines a set of AC security parameters.</t> <t>As shown in the tree depicted in <xref target="sec-svc-tree"/>, t he 'security' container defines a set of AC security parameters.</t>
<figure anchor="sec-svc-tree"> <figure anchor="sec-svc-tree">
<name>Security Tree Structure</name> <name>Security Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
+--rw specific-provisioning-profiles +--rw specific-provisioning-profiles
| ... | ...
+--rw service-provisioning-profiles +--rw service-provisioning-profiles
| ... | ...
+--rw attachment-circuits +--rw attachment-circuits
+--rw ac-group-profile* [name] +--rw ac-group-profile* [name]
| ... | ...
+--rw placement-constraints +--rw placement-constraints
| ... | ...
+--rw ac* [name] +--rw ac* [name]
skipping to change at line 2281 skipping to change at line 2355
| +--rw encryption-profile | +--rw encryption-profile
| +--rw (profile)? | +--rw (profile)?
| +--:(provider-profile) | +--:(provider-profile)
| | +--rw provider-profile? | | +--rw provider-profile?
| | encryption-profile-reference | | encryption-profile-reference
| +--:(customer-profile) | +--:(customer-profile)
| +--rw customer-key-chain? | +--rw customer-key-chain?
| key-chain:key-chain-ref | key-chain:key-chain-ref
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The 'security' container specifies a minimum set of encryption-re lated 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 applie d (e.g., Layer 2 or Layer 3 encryption) or invoke a local encryption profile (se e <xref target="sec-profiles-desc"/>). For example, a service provider may use IPsec when a customer requests Layer 3 encryption for an AC.</t> <t>The 'security' container specifies a minimum set of encryption-re lated 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 applie d (e.g., Layer 2 or Layer 3 encryption) or invoke a local encryption profile (se e <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>
<section anchor="sec-bw"> <section anchor="sec-bw">
<name>Service</name> <name>Service</name>
<t>The structure of the 'service' container is depicted in <xref tar get="bw-tree"/>.</t> <t>The structure of the 'service' container is depicted in <xref tar get="bw-tree"/>.</t>
<figure anchor="bw-tree"> <figure anchor="bw-tree">
<name>Bandwidth Tree Structure</name> <name>Bandwidth Tree Structure</name>
<artwork align="center"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
+--rw specific-provisioning-profiles +--rw specific-provisioning-profiles
| ... | ...
+--rw service-provisioning-profiles +--rw service-provisioning-profiles
| ... | ...
+--rw attachment-circuits +--rw attachment-circuits
+--rw ac-group-profile* [name] +--rw ac-group-profile* [name]
| ... | ...
+--rw placement-constraints +--rw placement-constraints
| ... | ...
+--rw ac* [name] +--rw ac* [name]
skipping to change at line 2363 skipping to change at line 2437
| +--rw pbs? uint64 | +--rw pbs? uint64
+--rw qos {vpn-common:qos}? +--rw qos {vpn-common:qos}?
| +--rw qos-profiles | +--rw qos-profiles
| +--rw qos-profile* [profile] | +--rw qos-profile* [profile]
| +--rw profile qos-profile-reference | +--rw profile qos-profile-reference
| +--rw direction? identityref | +--rw direction? identityref
+--rw access-control-list +--rw access-control-list
+--rw acl-profiles +--rw acl-profiles
+--rw acl-profile* [profile] +--rw acl-profile* [profile]
+--rw profile forwarding-profile-reference +--rw profile forwarding-profile-reference
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The 'service' container defines the following data nodes:</t> <t>The 'service' container defines the following data nodes:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'mtu':</dt> <dt>'mtu':</dt>
<dd> <dd>
<t>Specifies the Layer 2 MTU, in bytes, for the AC.</t> <t>Specifies the Layer 2 MTU, in bytes, for the AC.</t>
</dd> </dd>
<dt>'svc-pe-to-ce-bandwidth' and'svc-ce-to-pe-bandwidth':</dt> </dl>
<dd> <dl newline="true" spacing="normal">
<t/> <dt>'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth':</dt>
</dd> <dd>
<dt> 'svc-pe-to-ce-bandwidth':</dt> <dl newline="false" spacing="normal">
<dd> <dt>'svc-pe-to-ce-bandwidth':</dt>
<t>Indicates the inbound bandwidth of the AC (i.e., download ban <dd>Indicates the inbound bandwidth of the AC (i.e.,
dwidth from the service provider to download bandwidth from the service provider to the customer
the customer site).</t> site).</dd>
</dd> <dt>'svc-ce-to-pe-bandwidth':</dt>
<dt>'svc-ce-to-pe-bandwidth':</dt> <dd><t>Indicates the outbound bandwidth of the AC (i.e.,
<dd> upload bandwidth from the customer site to the service
<t>Indicates the outbound bandwidth of the AC (i.e., upload band provider).</t>
width from the customer site to the service </dd>
provider).</t> </dl>
</dd> <t>Both 'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth'
<dt/> can be represented using the Committed Information Rate (CIR),
<dd> the Excess Information Rate (EIR), or the Peak Information
<t>Both 'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth' ca Rate (PIR). Both reuse the 'bandwidth-per-type' grouping
n be represented using the Committed Information Rate (CIR), the Excess defined in <xref
Information Rate (EIR), or the Peak Information Rate (PIR). Both reuse the 'band target="RFC9833"/>.</t>
width-per-type' grouping defined in <xref target="I-D.ietf-opsawg-teas-common-ac </dd>
"/>.</t> </dl>
</dd> <dl newline="false" spacing="normal">
<dt>'qos':</dt> <dt>'qos':</dt>
<dd> <dd>
<t>Specifies a list of QoS profiles to apply for this AC.</t> <t>Specifies a list of QoS profiles to apply for this AC.</t>
</dd> </dd>
<dt>'access-control-list':</dt> <dt>'access-control-list':</dt>
<dd> <dd>
<t>Specifies a list of ACL profiles to apply for this AC.</t> <t>Specifies a list of ACL profiles to apply for this AC.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="yang-modules"> <section anchor="yang-modules">
<name>YANG Modules</name> <name>YANG Modules</name>
<section anchor="sec-bearer-module"> <section anchor="sec-bearer-module">
<name>The Bearer Service ("ietf-bearer-svc") YANG Module</name> <name>The Bearer Service ("ietf-bearer-svc") YANG Module</name>
<t>This module uses types defined in <xref target="RFC6991"/>, <xref tar <t>This module uses types defined in <xref target="RFC6991"/>, <xref tar
get="RFC9181"/>, and <xref target="I-D.ietf-opsawg-teas-common-ac"/>.</t> get="RFC9181"/>, and <xref target="RFC9833"/>.</t>
<sourcecode type="yang"><![CDATA[ <sourcecode name="ietf-bearer-svc@2025-08-11.yang" type="yang" markers="
<CODE BEGINS> file "ietf-bearer-svc@2025-01-07.yang" true"><![CDATA[
module ietf-bearer-svc { module ietf-bearer-svc {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bearer-svc"; namespace "urn:ietf:params:xml:ns:yang:ietf-bearer-svc";
prefix bearer-svc; prefix bearer-svc;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types, Section 4"; "RFC 6991: Common YANG Data Types, Section 4";
} }
import ietf-vpn-common { import ietf-vpn-common {
prefix vpn-common; prefix vpn-common;
reference reference
"RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3
VPNs"; VPNs";
} }
import ietf-ac-common { import ietf-ac-common {
prefix ac-common; prefix ac-common;
reference reference
"RFC CCCC: A Common YANG Data Model for Attachment Circuits"; "RFC 9833: A Common YANG Data Model for Attachment Circuits";
} }
import ietf-ac-svc { import ietf-ac-svc {
prefix ac-svc; prefix ac-svc;
reference reference
"RFC XXXX: YANG Data Models for Bearers and 'Attachment "RFC 9834: YANG Data Models for Bearers and 'Attachment
Circuits'-as-a-Service (ACaaS)"; Circuits'-as-a-Service (ACaaS)";
} }
organization organization
"IETF OPSAWG (Operations and Management Area Working Group)"; "IETF OPSAWG (Operations and Management Area Working Group)";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Editor: Mohamed Boucadair Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Richard Roberts Author: Richard Roberts
<mailto:rroberts@juniper.net> <mailto:rroberts@juniper.net>
Author: Oscar Gonzalez de Dios Author: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com> <mailto:oscar.gonzalezdedios@telefonica.com>
Author: Samier Barguil Author: Samier Barguil
<mailto:ssamier.barguil_giraldo@nokia.com> <mailto:ssamier.barguil_giraldo@nokia.com>
Author: Bo Wu Author: Bo Wu
<mailto:lana.wubo@huawei.com>"; <mailto:lana.wubo@huawei.com>";
description description
"This YANG module defines a generic YANG model for exposing "This YANG module defines a generic YANG module for exposing
network bearers as a service. network bearers as a service.
Copyright (c) 2025 IETF Trust and the persons identified as Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC xxx; see the This version of this YANG module is part of RFC xxx; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2025-01-07 { revision 2025-08-11 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: YANG Data Models for Bearers and 'Attachment "RFC 9834: YANG Data Models for Bearers and 'Attachment
Circuits'-as-a-Service (ACaaS)"; Circuits'-as-a-Service (ACaaS)";
} }
// Identities // Identities
identity identification-type { identity identification-type {
description description
"Base identity for identification of bearers."; "Base identity for identification of bearers.";
} }
skipping to change at line 2572 skipping to change at line 2651
} }
// Reusable groupings // Reusable groupings
grouping location-information { grouping location-information {
description description
"Basic location information."; "Basic location information.";
leaf name { leaf name {
type string; type string;
description description
"Provides a location name. This data node can be mapped, "Provides a location name. This data node can be mapped,
e.g., to the 3GPP NRM IOC ManagedElement."; e.g., to the 3GPP NRM IOC ManagedElement.";
} }
leaf address { leaf address {
type string; type string;
description description
"Address (number and street) of the device/site."; "Address (number and street) of the device/site.";
} }
leaf city { leaf city {
type string; type string;
description description
"City of the device/site."; "City of the device/site.";
} }
leaf postal-code { leaf postal-code {
type string; type string;
description description
"Postal code of the device/site."; "Postal code of the device/site.";
} }
leaf state { leaf state {
type string; type string;
description description
"State of the device/site. This leaf can also be used to "State of the device/site. This leaf can also be used to
describe a region for a country that does not have describe a region for a country that does not have
states."; states.";
} }
leaf country-code { leaf country-code {
type string { type string {
pattern '[A-Z]{2}'; pattern '[A-Z]{2}';
} }
description description
"Country of the device/site. "Country of the device/site.
Expressed as ISO ALPHA-2 code."; Expressed as ISO ALPHA-2 code.";
skipping to change at line 2703 skipping to change at line 2782
key "name"; key "name";
config false; config false;
description description
"Reports the list of available locations."; "Reports the list of available locations.";
uses location-information; uses location-information;
} }
} }
} }
container bearers { container bearers {
description description
"Main container for the bearers. The timing constraints "Main container for the bearers. The timing constraints
indicated at the bearer level take precedence over the indicated at the bearer level take precedence over the
global values indicated at the bearers level."; global values indicated at the bearers level.";
uses ac-common:op-instructions; uses ac-common:op-instructions;
container placement-constraints { container placement-constraints {
description description
"Diversity constraint type."; "Diversity constraint type.";
uses placement-constraints; uses placement-constraints;
} }
list bearer { list bearer {
key "name"; key "name";
skipping to change at line 2738 skipping to change at line 2817
type string; type string;
description description
"Indicates the name of the customer that requested this "Indicates the name of the customer that requested this
bearer."; bearer.";
} }
uses vpn-common:vpn-components-group; uses vpn-common:vpn-components-group;
leaf op-comment { leaf op-comment {
type string; type string;
description description
"Includes comments that can be shared with operational "Includes comments that can be shared with operational
teams and which may be useful for the activation of a teams and that may be useful for the activation of a
bearer. This may include, for example, information bearer. This may include, for example, information
about the building, level, etc."; about the building, level, etc.";
} }
leaf bearer-parent-ref { leaf bearer-parent-ref {
type bearer-svc:bearer-ref; type bearer-svc:bearer-ref;
description description
"Specifies the parent bearer. This can be used, e.g., "Specifies the parent bearer. This can be used, e.g.,
for a Link Aggregation Group (LAG)."; for a Link Aggregation Group (LAG).";
} }
leaf-list bearer-lag-member { leaf-list bearer-lag-member {
type bearer-svc:bearer-ref; type bearer-svc:bearer-ref;
config false; config false;
description description
"Reports LAG members."; "Reports LAG members.";
} }
leaf sync-phy-capable { leaf sync-phy-capable {
type boolean; type boolean;
config false; config false;
description description
"Indicates, when set to true, that a mechanism for physical "Indicates, when set to true, that a mechanism for physical
layer synchronization is supported for this bearer. layer synchronization is supported for this bearer.
No such mechanism is supported if set to false."; No such mechanism is supported if set to false.";
} }
leaf sync-phy-enabled { leaf sync-phy-enabled {
type boolean; type boolean;
description description
"Indicates, when set to true, that a mechanism for physical "Indicates, when set to true, that a mechanism for physical
layer synchronization is enabled for this bearer. No such layer synchronization is enabled for this bearer. No such
mechanism is enabled if set to false."; mechanism is enabled if set to false.";
} }
leaf sync-phy-type { leaf sync-phy-type {
when "../sync-phy-enabled='true'"; when "../sync-phy-enabled='true'";
type identityref { type identityref {
base sync-phy-type; base sync-phy-type;
} }
description description
"Type of the physical layer synchronization that is enabled "Type of the physical layer synchronization that is enabled
for this bearer."; for this bearer.";
} }
leaf provider-location-reference { leaf provider-location-reference {
type string; type string;
description description
"Specifies the provider's location reference."; "Specifies the provider's location reference.";
} }
container customer-point { container customer-point {
description description
"Base container to link the Bearer existence."; "Base container to link the bearer existence.";
leaf identified-by { leaf identified-by {
type identityref { type identityref {
base identification-type; base identification-type;
} }
description description
"Specifies how the customer point is identified."; "Specifies how the customer point is identified.";
} }
container device { container device {
when "derived-from-or-self(../identified-by, " when "derived-from-or-self(../identified-by, "
+ "'bearer-svc:device-id') or " + "'bearer-svc:device-id') or "
skipping to change at line 2840 skipping to change at line 2919
container location { container location {
description description
"Location of the node."; "Location of the node.";
uses location-information; uses location-information;
} }
} }
leaf custom-id { leaf custom-id {
when "derived-from-or-self(../identified-by, " when "derived-from-or-self(../identified-by, "
+ "'bearer-svc:custom')" { + "'bearer-svc:custom')" {
description description
"Only enabled id identified-by is custom."; "Only enabled if identified-by is custom.";
} }
type string; type string;
description description
"The semantic of this identifier is shared between the "The semantics of this identifier is shared between the
customer/provider using out-of-band means."; customer/provider using out-of-band means.";
} }
} }
leaf type { leaf type {
type identityref { type identityref {
base bearer-type; base bearer-type;
} }
description description
"Type of the bearer (e.g., Ethernet or wireless)."; "Type of the bearer (e.g., Ethernet or wireless).";
} }
leaf test-only { leaf test-only {
type empty; type empty;
description description
"When present, this indicates that this is a feasibility "When present, this indicates that this is a feasibility
check request. No resources are committed for such bearer check request. No resources are committed for such bearer
requests."; requests.";
} }
leaf bearer-reference { leaf bearer-reference {
if-feature "ac-common:server-assigned-reference"; if-feature "ac-common:server-assigned-reference";
type string; type string;
config false; config false;
description description
"This is an internal reference for the service provider "This is an internal reference for the service provider
to identify the bearers."; to identify the bearers.";
} }
leaf-list ac-svc-ref { leaf-list ac-svc-ref {
type ac-svc:attachment-circuit-reference; type ac-svc:attachment-circuit-reference;
config false; config false;
description description
"Specifies the set of ACes that are bound to the bearer."; "Specifies the set of ACs that are bound to the bearer.";
} }
uses ac-common:op-instructions; uses ac-common:op-instructions;
uses ac-common:service-status; uses ac-common:service-status;
} }
} }
} }
<CODE ENDS>
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="sec-ac-module"> <section anchor="sec-ac-module">
<name>The AC Service ("ietf-ac-svc") YANG Module</name> <name>The AC Service ("ietf-ac-svc") YANG Module</name>
<t>This module uses types defined in <xref target="RFC6991"/>, <xref tar <t>This module uses types defined in <xref target="RFC6991"/>, <xref tar
get="RFC9181"/>, <xref target="RFC8177"/>, and <xref target="I-D.ietf-opsawg-tea get="RFC9181"/>, <xref target="RFC8177"/>, and <xref target="RFC9833"/>. Also, t
s-common-ac"/>. Also, the module uses he module uses
the extensions defined in <xref target="RFC8341"/>.</t> the extensions defined in <xref target="RFC8341"/>.</t>
<sourcecode type="yang"><![CDATA[
<CODE BEGINS> file "ietf-ac-svc@2025-01-07.yang" <!--[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".)
-->
<sourcecode name="ietf-ac-svc@2025-08-11.yang" type="yang" markers="true
"><![CDATA[
module ietf-ac-svc { module ietf-ac-svc {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ac-svc"; namespace "urn:ietf:params:xml:ns:yang:ietf-ac-svc";
prefix ac-svc; prefix ac-svc;
import ietf-ac-common { import ietf-ac-common {
prefix ac-common; prefix ac-common;
reference reference
"RFC CCCC: A Common YANG Data Model for Attachment Circuits"; "RFC 9833: A Common YANG Data Model for Attachment Circuits";
} }
import ietf-vpn-common { import ietf-vpn-common {
prefix vpn-common; prefix vpn-common;
reference reference
"RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3
VPNs"; VPNs";
} }
import ietf-netconf-acm { import ietf-netconf-acm {
prefix nacm; prefix nacm;
reference reference
skipping to change at line 2939 skipping to change at line 3041
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Richard Roberts Author: Richard Roberts
<mailto:rroberts@juniper.net> <mailto:rroberts@juniper.net>
Author: Oscar Gonzalez de Dios Author: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com> <mailto:oscar.gonzalezdedios@telefonica.com>
Author: Samier Barguil Author: Samier Barguil
<mailto:ssamier.barguil_giraldo@nokia.com> <mailto:ssamier.barguil_giraldo@nokia.com>
Author: Bo Wu Author: Bo Wu
<mailto:lana.wubo@huawei.com>"; <mailto:lana.wubo@huawei.com>";
description description
"This YANG module defines a YANG model for exposing "This YANG module defines a YANG module for exposing
attachment circuits as a service (ACaaS). 'Attachment Circuits'-as-a-Service (ACaaS).
Copyright (c) 2025 IETF Trust and the persons identified as Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC 9834; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2025-01-07 { revision 2025-08-11 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: YANG Data Models for Bearers and 'Attachment "RFC 9834: YANG Data Models for Bearers and 'Attachment
Circuits'-as-a-Service (ACaaS)"; Circuits'-as-a-Service (ACaaS)";
} }
/* A set of typedefs to ease referencing cross-modules */ /* A set of typedefs to ease referencing cross-modules */
typedef attachment-circuit-reference { typedef attachment-circuit-reference {
type leafref { type leafref {
path "/ac-svc:attachment-circuits/ac-svc:ac/ac-svc:name"; path "/ac-svc:attachment-circuits/ac-svc:ac/ac-svc:name";
} }
description description
skipping to change at line 2985 skipping to change at line 3087
type leafref { type leafref {
path "/ac-svc:attachment-circuits/ac-svc:ac-group-profile" path "/ac-svc:attachment-circuits/ac-svc:ac-group-profile"
+ "/ac-svc:name"; + "/ac-svc:name";
} }
description description
"Defines a reference to an attachment circuit profile."; "Defines a reference to an attachment circuit profile.";
} }
typedef encryption-profile-reference { typedef encryption-profile-reference {
type leafref { type leafref {
path path "/ac-svc:specific-provisioning-profiles"
"/ac-svc:specific-provisioning-profiles" + "/ac-svc:valid-provider-identifiers"
+ "/ac-svc:valid-provider-identifiers" + "/ac-svc:encryption-profile-identifier/ac-svc:id";
+ "/ac-svc:encryption-profile-identifier/ac-svc:id";
} }
description description
"Defines a reference to an encryption profile."; "Defines a reference to an encryption profile.";
} }
typedef qos-profile-reference { typedef qos-profile-reference {
type leafref { type leafref {
path path "/ac-svc:specific-provisioning-profiles"
"/ac-svc:specific-provisioning-profiles" + "/ac-svc:valid-provider-identifiers"
+ "/ac-svc:valid-provider-identifiers" + "/ac-svc:qos-profile-identifier/ac-svc:id";
+ "/ac-svc:qos-profile-identifier/ac-svc:id";
} }
description description
"Defines a reference to a QoS profile."; "Defines a reference to a QoS profile.";
} }
typedef failure-detection-profile-reference { typedef failure-detection-profile-reference {
type leafref { type leafref {
path path "/ac-svc:specific-provisioning-profiles"
"/ac-svc:specific-provisioning-profiles" + "/ac-svc:valid-provider-identifiers"
+ "/ac-svc:valid-provider-identifiers" + "/ac-svc:failure-detection-profile-identifier"
+ "/ac-svc:failure-detection-profile-identifier" + "/ac-svc:id";
+ "/ac-svc:id";
} }
description description
"Defines a reference to a BFD profile."; "Defines a reference to a BFD profile.";
} }
typedef forwarding-profile-reference { typedef forwarding-profile-reference {
type leafref { type leafref {
path path "/ac-svc:specific-provisioning-profiles"
"/ac-svc:specific-provisioning-profiles" + "/ac-svc:valid-provider-identifiers"
+ "/ac-svc:valid-provider-identifiers" + "/ac-svc:forwarding-profile-identifier/ac-svc:id";
+ "/ac-svc:forwarding-profile-identifier/ac-svc:id";
} }
description description
"Defines a reference to a forwarding profile."; "Defines a reference to a forwarding profile.";
} }
typedef routing-profile-reference { typedef routing-profile-reference {
type leafref { type leafref {
path path "/ac-svc:specific-provisioning-profiles"
"/ac-svc:specific-provisioning-profiles" + "/ac-svc:valid-provider-identifiers"
+ "/ac-svc:valid-provider-identifiers" + "/ac-svc:routing-profile-identifier/ac-svc:id";
+ "/ac-svc:routing-profile-identifier/ac-svc:id";
} }
description description
"Defines a reference to a routing profile."; "Defines a reference to a routing profile.";
} }
typedef service-profile-reference { typedef service-profile-reference {
type leafref { type leafref {
path path "/ac-svc:service-provisioning-profiles"
"/ac-svc:service-provisioning-profiles" + "/ac-svc:service-profile-identifier"
+ "/ac-svc:service-profile-identifier" + "/ac-svc:id";
+ "/ac-svc:id";
} }
description description
"Defines a reference to a service profile."; "Defines a reference to a service profile.";
} }
/******************** Reusable groupings ********************/ /******************** Reusable groupings ********************/
// Basic Layer 2 connection // Basic Layer 2 connection
grouping l2-connection-basic { grouping l2-connection-basic {
description description
skipping to change at line 3197 skipping to change at line 3293
// Full IP connection // Full IP connection
grouping ip-connection { grouping ip-connection {
description description
"Defines IP connection parameters."; "Defines IP connection parameters.";
container ipv4 { container ipv4 {
if-feature "vpn-common:ipv4"; if-feature "vpn-common:ipv4";
description description
"IPv4-specific parameters."; "IPv4-specific parameters.";
uses ac-common:ipv4-connection { uses ac-common:ipv4-connection {
augment ac-svc:allocation-type/static-addresses/address { augment "ac-svc:allocation-type/static-addresses/address" {
leaf failure-detection-profile { leaf failure-detection-profile {
if-feature "vpn-common:bfd"; if-feature "vpn-common:bfd";
type failure-detection-profile-reference; type failure-detection-profile-reference;
description description
"Points to a failure detection profile."; "Points to a failure detection profile.";
} }
description description
"Adds a failure detection profile."; "Adds a failure detection profile.";
} }
} }
} }
container ipv6 { container ipv6 {
if-feature "vpn-common:ipv6"; if-feature "vpn-common:ipv6";
description description
"IPv6-specific parameters."; "IPv6-specific parameters.";
uses ac-common:ipv6-connection { uses ac-common:ipv6-connection {
augment ac-svc:allocation-type/static-addresses/address { augment "ac-svc:allocation-type/static-addresses/address" {
leaf failure-detection-profile { leaf failure-detection-profile {
if-feature "vpn-common:bfd"; if-feature "vpn-common:bfd";
type failure-detection-profile-reference; type failure-detection-profile-reference;
description description
"Points to a failure detection profile."; "Points to a failure detection profile.";
} }
description description
"Adds a failure detection profile."; "Adds a failure detection profile.";
} }
} }
skipping to change at line 3327 skipping to change at line 3423
// BGP Service // BGP Service
grouping bgp-neighbor-without-name { grouping bgp-neighbor-without-name {
description description
"A grouping with generic parameters for configuring a BGP "A grouping with generic parameters for configuring a BGP
neighbor."; neighbor.";
leaf remote-address { leaf remote-address {
type inet:ip-address; type inet:ip-address;
description description
"The remote IP address of this entry's BGP peer. This is "The remote IP address of this entry's BGP peer. This is
a customer IP address. a customer IP address.
If this leaf is not present, this means that the primary If this leaf is not present, this means that the primary
customer IP address is used as remote IP address."; customer IP address is used as the remote IP address.";
} }
leaf local-address { leaf local-address {
type inet:ip-address; type inet:ip-address;
description description
"The provider's IP address that will be used to establish "The provider's IP address that will be used to establish
the BGP session."; the BGP session.";
} }
uses ac-common:bgp-peer-group-without-name; uses ac-common:bgp-peer-group-without-name;
container bgp-max-prefix { container bgp-max-prefix {
description description
skipping to change at line 3412 skipping to change at line 3508
grouping bgp-svc { grouping bgp-svc {
description description
"Configuration specific to BGP."; "Configuration specific to BGP.";
container peer-groups { container peer-groups {
description description
"Configuration for BGP peer-groups"; "Configuration for BGP peer-groups";
list peer-group { list peer-group {
key "name"; key "name";
description description
"List of BGP peer-groups configured on the local "List of BGP peer-groups configured on the local
system - uniquely identified by peer-group name."; system -- uniquely identified by peer-group name.";
uses ac-common:bgp-peer-group-with-name; uses ac-common:bgp-peer-group-with-name;
leaf local-address { leaf local-address {
type inet:ip-address; type inet:ip-address;
description description
"The provider's local IP address that will be used to "The provider's local IP address that will be used to
establish the BGP session."; establish the BGP session.";
} }
container bgp-max-prefix { container bgp-max-prefix {
description description
"A container for the maximum number of BGP prefixes "A container for the maximum number of BGP prefixes
skipping to change at line 3548 skipping to change at line 3644
if-feature "vpn-common:rtg-bgp"; if-feature "vpn-common:rtg-bgp";
description description
"Configuration specific to BGP."; "Configuration specific to BGP.";
container peer-groups { container peer-groups {
description description
"Configuration for BGP peer-groups"; "Configuration for BGP peer-groups";
list peer-group { list peer-group {
key "name"; key "name";
description description
"List of BGP peer-groups configured on the local "List of BGP peer-groups configured on the local
system - uniquely identified by peer-group system -- uniquely identified by peer-group
name."; name.";
uses ac-common:bgp-peer-group-with-name; uses ac-common:bgp-peer-group-with-name;
} }
} }
} }
container ospf { container ospf {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:ospf-routing')" { + "'vpn-common:ospf-routing')" {
description description
"Only applies when the protocol is OSPF."; "Only applies when the protocol is OSPF.";
skipping to change at line 3571 skipping to change at line 3667
description description
"Configuration specific to OSPF."; "Configuration specific to OSPF.";
uses ac-common:ospf-basic; uses ac-common:ospf-basic;
} }
container isis { container isis {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:isis-routing')" { + "'vpn-common:isis-routing')" {
description description
"Only applies when the protocol is IS-IS."; "Only applies when the protocol is IS-IS.";
} }
if-feature "vpn-common:rtg-isis"; if-feature "vpn-common:rtg-isis";
description description
"Configuration specific to IS-IS."; "Configuration specific to IS-IS.";
uses ac-common:isis-basic; uses ac-common:isis-basic;
} }
container rip { container rip {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:rip-routing')" { + "'vpn-common:rip-routing')" {
description description
"Only applies when the protocol is RIP. "Only applies when the protocol is RIP.
For IPv4, the model assumes that RIP version 2 is used."; For IPv4, the model assumes that RIP version 2 is
used.";
} }
if-feature "vpn-common:rtg-rip"; if-feature "vpn-common:rtg-rip";
description description
"Configuration specific to RIP routing."; "Configuration specific to RIP routing.";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates whether IPv4, IPv6, or both address families "Indicates whether IPv4, IPv6, or both address families
skipping to change at line 3636 skipping to change at line 3733
leaf id { leaf id {
type string; type string;
description description
"Unique identifier for the routing protocol."; "Unique identifier for the routing protocol.";
} }
uses routing-protocol-list; uses routing-protocol-list;
container static { container static {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:static-routing')" { + "'vpn-common:static-routing')" {
description description
"Only applies when the protocol is static routing "Only applies when the protocol is the static
protocol."; routing protocol.";
} }
description description
"Configuration specific to static routing."; "Configuration specific to static routing.";
container cascaded-lan-prefixes { container cascaded-lan-prefixes {
description description
"LAN prefixes from the customer."; "LAN prefixes from the customer.";
uses ipv4-static-rtg-with-bfd; uses ipv4-static-rtg-with-bfd;
uses ipv6-static-rtg-with-bfd; uses ipv6-static-rtg-with-bfd;
} }
} }
skipping to change at line 3686 skipping to change at line 3783
if-feature "vpn-common:rtg-isis"; if-feature "vpn-common:rtg-isis";
description description
"Configuration specific to IS-IS."; "Configuration specific to IS-IS.";
uses isis-svc; uses isis-svc;
} }
container rip { container rip {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:rip-routing')" { + "'vpn-common:rip-routing')" {
description description
"Only applies when the protocol is RIP. "Only applies when the protocol is RIP.
For IPv4, the model assumes that RIP version 2 is used."; For IPv4, the model assumes that RIP version 2 is
used.";
} }
if-feature "vpn-common:rtg-rip"; if-feature "vpn-common:rtg-rip";
description description
"Configuration specific to RIP routing."; "Configuration specific to RIP routing.";
uses rip-svc; uses rip-svc;
} }
container vrrp { container vrrp {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:vrrp-routing')" { + "'vpn-common:vrrp-routing')" {
description description
skipping to change at line 3746 skipping to change at line 3844
description description
"AC-specific security parameters."; "AC-specific security parameters.";
container encryption { container encryption {
if-feature "vpn-common:encryption"; if-feature "vpn-common:encryption";
description description
"Container for AC security encryption."; "Container for AC security encryption.";
leaf enabled { leaf enabled {
type boolean; type boolean;
description description
"If set to 'true', traffic encryption on the connection "If set to 'true', traffic encryption on the connection
is required. Otherwise, it is disabled."; is required. Otherwise, it is disabled.";
} }
leaf layer { leaf layer {
when "../enabled = 'true'" { when "../enabled = 'true'" {
description description
"Included only when encryption is enabled."; "Included only when encryption is enabled.";
} }
type enumeration { type enumeration {
enum layer2 { enum layer2 {
description description
"Encryption occurs at Layer 2."; "Encryption occurs at Layer 2.";
skipping to change at line 3868 skipping to change at line 3966
} }
// Full AC parameters // Full AC parameters
grouping ac { grouping ac {
description description
"Grouping for an attachment circuit."; "Grouping for an attachment circuit.";
leaf name { leaf name {
type string; type string;
description description
"A name of the AC. Data models that need to reference "A name of the AC. Data models that need to reference
an AC should use 'attachment-circuit-reference'."; an AC should use 'attachment-circuit-reference'.";
} }
leaf-list service-profile { leaf-list service-profile {
type service-profile-reference; type service-profile-reference;
description description
"A reference to a service profile."; "A reference to a service profile.";
} }
container l2-connection { container l2-connection {
if-feature "ac-common:layer2-ac"; if-feature "ac-common:layer2-ac";
description description
skipping to change at line 3906 skipping to change at line 4004
"Defines the OAM mechanisms used."; "Defines the OAM mechanisms used.";
container bfd { container bfd {
if-feature "vpn-common:bfd"; if-feature "vpn-common:bfd";
description description
"Container for BFD."; "Container for BFD.";
list session { list session {
key "id"; key "id";
description description
"List of BFD sessions."; "List of BFD sessions.";
leaf id { leaf id {
type string; type string;
description description
"A unique identifier for the BFD session."; "A unique identifier for the BFD session.";
} }
leaf local-address { leaf local-address {
type inet:ip-address; type inet:ip-address;
description description
"Provider's IP address of the BFD session."; "Provider's IP address of the BFD session.";
} }
leaf remote-address { leaf remote-address {
type inet:ip-address; type inet:ip-address;
description description
"Customer's IP address of the BFD session."; "Customer's IP address of the BFD session.";
skipping to change at line 4041 skipping to change at line 4139
"Identification of the service profile to be used. "Identification of the service profile to be used.
The profile only has significance within the service The profile only has significance within the service
provider's administrative domain."; provider's administrative domain.";
} }
} }
nacm:default-deny-write; nacm:default-deny-write;
} }
container attachment-circuits { container attachment-circuits {
description description
"Main container for the attachment circuits. "Main container for the attachment circuits.
The timing constraints indicated at the 'ac' level take The timing constraints indicated at the 'ac' level take
precedence over the values indicated at the precedence over the values indicated at the
'attachment-circuits' level."; 'attachment-circuits' level.";
list ac-group-profile { list ac-group-profile {
key "name"; key "name";
description description
"Maintains a list of profiles that are shared among "Maintains a list of profiles that are shared among
a set of ACs."; a set of ACs.";
uses ac; uses ac;
} }
container placement-constraints { container placement-constraints {
skipping to change at line 4081 skipping to change at line 4179
AC."; AC.";
} }
leaf description { leaf description {
type string; type string;
description description
"Associates a description with an AC."; "Associates a description with an AC.";
} }
leaf test-only { leaf test-only {
type empty; type empty;
description description
"When present, this indicates that this is a feasibility "When present, this indicates that this is a feasibility
check request. No resources are committed for such AC check request. No resources are committed for such AC
requests."; requests.";
} }
uses ac-common:op-instructions; uses ac-common:op-instructions;
leaf role { leaf role {
type identityref { type identityref {
base ac-common:role; base ac-common:role;
} }
description description
"Indicates whether this AC is used as UNI, NNI, etc."; "Indicates whether this AC is used as UNI, NNI, etc.";
} }
leaf-list peer-sap-id { leaf-list peer-sap-id {
skipping to change at line 4140 skipping to change at line 4238
type string; type string;
config false; config false;
description description
"Reports an internal reference for the service provider "Reports an internal reference for the service provider
to identify the AC."; to identify the AC.";
} }
uses ac; uses ac;
} }
} }
} }
<CODE ENDS>
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This section is modeled after the template described in in <xref sectio
n="3.7" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t> <!-- DNE begins -->
<t>Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-cha
in') rely
upon <xref target="RFC8177"/> for authentication purposes. As such, the AC s
ervice module
inherits the security considerations discussed in
<xref section="5" sectionFormat="of" target="RFC8177"/>. Also, these data no
des 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>
<t>This section is modeled after the template described in <xref section="
3.7" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t>
<t>The "ietf-bearer-svc" and "ietf-ac-svc" YANG modules define data models that are <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 designed to be accessed via YANG-based management protocols, such as
NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These protocols have to NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These protocols have to
use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref t arget="RFC8446"/>, and use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref t arget="RFC8446"/>, and
QUIC <xref target="RFC9000"/>) and have to use mutual authentication.</t> QUIC <xref target="RFC9000"/>) and have to use mutual authentication.</t>
<!-- DNE ends -->
<t>Servers <bcp14>MUST</bcp14> verify that requesting clients are entitled to access <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 h ave access to bearers/ACs of other customers. and manipulate a given bearer or AC. For example, a given customer must not h ave access to bearers/ACs of other customers.
The Network Configuration Access Control Model (NACM) <xref target="RFC8341"/ > <!-- DNE begins -->The Network Configuration Access Control Model (NACM) <xre f target="RFC8341"/>
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.</t> RESTCONF protocol operations and content.</t>
<t>There are a number of data nodes defined in these YANG modules that are <t>There are a number of data nodes defined in these YANG modules that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., "config true", which is the
default). These data nodes may be considered sensitive or vulnerable default). All writable data nodes are likely to be reasonably sensitive or v
ulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
and delete operations to these data nodes without proper protection and delete operations to these data nodes without proper protection
or authentication can have a negative effect on network operations. or authentication can have a negative effect on network operations.
Specifically, the following subtrees and data nodes have particular The following subtrees and data nodes have particular
sensitivities/vulnerabilities in the "ietf-bearer-svc" module:</t> sensitivities/vulnerabilities in the "ietf-bearer-svc" module:</t><!-- DNE ends
<dl> -->
<dl spacing="normal" newline="false">
<dt>'placement-constraints':</dt> <dt>'placement-constraints':</dt>
<dd> <dd>
<t>An attacker who is able to access this data node can modify the <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 attributes to influence how a service is delivered to a customer, and
this leads to Service Level Agreement (SLA) violations.</t> this leads to Service Level Agreement (SLA) violations.</t>
</dd> </dd>
<dt>'bearer':</dt> <dt>'bearer':</dt>
<dd> <dd>
<t>An attacker who is able to access this data node can modify <t>An attacker who is able to access this data node can modify
the attributes of bearer and, thus, hinder how ACs are built.</t> the attributes of bearer and thus hinder how ACs are built.</t>
</dd>
<dt/>
<dd>
<t>In addition, an attacker could attempt to add a new bearer or <t>In addition, an attacker could attempt to add a new bearer or
delete existing ones. An attacker may also change the requested delete existing ones. An attacker may also change the requested
type, whether it is for test-only, or the activation scheduling.</t> type, whether it is for test-only, or the activation scheduling.</t>
</dd> </dd>
</dl> </dl>
<t>The following subtrees and data nodes have particular <t>The following subtrees and data nodes have particular
sensitivities/vulnerabilities in the "ietf-ac-svc" module:</t> sensitivities/vulnerabilities in the "ietf-ac-svc" module:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'specific-provisioning-profiles':</dt> <dt>'specific-provisioning-profiles':</dt>
<dd> <dd>
<t>This container includes a set of sensitive data that influence <t>This container includes a set of sensitive data that influences
how an AC will be delivered. For example, an attacker who has access 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 to these data nodes may be able to manipulate routing policies, QoS
policies, or encryption properties.</t> policies, or encryption properties.</t>
</dd> <t>These profiles are defined with "nacm:default-deny-write" tagging
<dt/> <xref target="RFC9833"/>.</t>
<dd>
<t>These profiles are defined with "nacm:default-deny-write"
tagging <xref target="I-D.ietf-opsawg-teas-common-ac"/>.</t>
</dd> </dd>
<dt>'service-provisioning-profiles':</dt> <dt>'service-provisioning-profiles':</dt>
<dd> <dd>
<t>An attacker who has access to these data nodes may be able <t>An attacker who has access to these data nodes may be able to
to manipulate service-specific policies to be applied for an AC.</t> 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> <t>This container is defined with "nacm:default-deny-write" tagging.</ t>
</dd> </dd>
<dt>'ac':</dt> <dt>'ac':</dt>
<dd> <dd>
<t>An attacker who is able to access this data node can modify <t>An attacker who is able to access this data node can modify the
the attributes of an AC (e.g., QoS, bandwidth, routing protocols, attributes of an AC (e.g., QoS, bandwidth, routing protocols, keying
keying material), leading to malfunctioning of services that will material), leading to malfunctioning of services that will be
be delivered over that AC and therefore to SLA violations. delivered over that AC and therefore to SLA violations. In
In addition, an attacker could attempt to add a new AC.</t> addition, an attacker could attempt to add a new AC.</t>
</dd> </dd>
</dl> </dl>
<t>Some of the readable data nodes in these YANG modules may be considered
<!-- DNE begins --><t>Some of the readable data nodes in these YANG module
s may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. Specifically, the following subtrees and d ata nodes have particular notification) to these data nodes. Specifically, the following subtrees and d ata nodes have particular
sensitivities/vulnerabilities in the "ietf-bearer-svc" module:</t> sensitivities/vulnerabilities in the "ietf-bearer-svc" module:</t><!-- DNE ends
<dl> -->
<dl spacing="normal" newline="false">
<dt>'customer-name', 'customer-point' and 'locations':</dt> <dt>'customer-name', 'customer-point' and 'locations':</dt>
<dd> <dd>
<t>An attacker can retrieve privacy-related information about location <t>An attacker can retrieve privacy-related information about
s from where locations from where the customer is connected or can be
the customer is connected or can be serviced. Disclosing such information may b serviced. Disclosing such information may be used to infer the
e used to infer identity of the customer.</t>
the identity of the customer.</t>
</dd> </dd>
</dl> </dl>
<t>The following subtrees and data nodes have particular <t>The following subtrees and data nodes have particular
sensitivities/vulnerabilities in the "ietf-ac-svc" module:</t> sensitivities/vulnerabilities in the "ietf-ac-svc" module:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'customer-name', 'l2-connection', and 'ip-connection':</dt> <dt>'customer-name', 'l2-connection', and 'ip-connection':</dt>
<dd> <dd>
<t>An attacker can retrieve privacy-related information, which can be <t>An attacker can retrieve privacy-related information, which can
used to track a be used to track a customer. Disclosing such information may be
customer. Disclosing such information may be considered a considered a violation of the customer-provider trust
violation of the customer-provider trust relationship.</t> relationship.</t>
</dd> </dd>
<dt>'keying-material':</dt> <dt>'keying-material':</dt>
<dd> <dd>
<t>An attacker can retrieve the cryptographic keys <t>An attacker can retrieve the cryptographic keys protecting the
protecting the underlying connectivity services (routing, in underlying connectivity services (routing, in particular). These
particular). These keys could be used to inject spoofed routing keys could be used to inject spoofed routing advertisements.</t>
advertisements.</t>
</dd> </dd>
</dl> </dl>
<t>Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-cha <t>There are no particularly sensitive RPC or action operations.</t>
in') rely
upon <xref target="RFC8177"/> for authentication purposes. As such, the AC s
ervice module
inherits the security considerations discussed in
<xref section="5" sectionFormat="of" target="RFC8177"/>. Also, these data no
des 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 paramete
rs that can be applied to traffic for a given AC.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to register the following URIs in the "ns" subregistr y within <t>IANA has registered the following URIs in the "ns" subregistry within
the "IETF XML Registry" <xref target="RFC3688"/>:</t> the "IETF XML Registry" <xref target="RFC3688"/>:</t>
<artwork><![CDATA[ <dl spacing="compact" newline="false">
URI: urn:ietf:params:xml:ns:yang:ietf-bearer-svc <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bearer-svc</dd>
Registrant Contact: The IESG. <dt>Registrant Contact:</dt><dd>The IESG.</dd>
XML: N/A; the requested URI is an XML namespace. <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
URI: urn:ietf:params:xml:ns:yang:ietf-ac-svc <dl spacing="compact" newline="false">
Registrant Contact: The IESG. <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-svc</dd>
XML: N/A; the requested URI is an XML namespace. <dt>Registrant Contact:</dt><dd>The IESG.</dd>
]]></artwork> <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
<t>IANA is requested to register the following YANG modules in the "YANG M </dl>
odule <t>IANA has registered the following YANG modules in the "YANG Module
Names" subregistry <xref target="RFC6020"/> within the "YANG Parameters" regi Names" registry <xref target="RFC6020"/> within the "YANG Parameters" registr
stry.</t> y group.</t>
<artwork><![CDATA[
Name: ietf-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 <dl spacing="compact" newline="false">
Maintained by IANA? N <dt>Name:</dt><dd>ietf-bearer-svc</dd>
Namespace: urn:ietf:params:xml:ns:yang:ietf-ac-svc <dt>Maintained by IANA?</dt><dd>N</dd>
Prefix: ac-svc <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bearer-svc</dd>
Reference: RFC XXXX <dt>Prefix:</dt><dd>bearer-svc</dd>
]]></artwork> <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> </section>
</middle> </middle>
<back> <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="NSS
M"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC9408"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 408.xml"/>
<title>A YANG Network Data Model for Service Attachment Points (SAPs <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
)</title> 342.xml"/>
<author fullname="M. Boucadair" initials="M." role="editor" surname= <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
"Boucadair"/> 181.xml"/>
<author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzal <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
ez de Dios"/> 241.xml"/>
<author fullname="S. Barguil" initials="S." surname="Barguil"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="Q. Wu" initials="Q." surname="Wu"/> 040.xml"/>
<author fullname="V. Lopez" initials="V." surname="Lopez"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<date month="June" year="2023"/> 252.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>This document defines a YANG data model for representing an abs 446.xml"/>
tract view of the provider network topology that contains the points from which <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
its services can be attached (e.g., basic connectivity, VPN, network slices). Al 000.xml"/>
so, the model can be used to retrieve the points where the services are actually <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
being delivered to customers (including peer networks).</t> 341.xml"/>
<t>This document augments the 'ietf-network' data model defined in
RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs ar
e the network reference points to which network services, such as Layer 3 Virtua
l Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be att
ached. One or multiple services can be bound to the same SAP. Both User-to-Netwo
rk Interface (UNI) and Network-to-Network Interface (NNI) are supported in the S
AP data model.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9408"/>
<seriesInfo name="DOI" value="10.17487/RFC9408"/>
</reference>
<reference anchor="RFC8342">
<front>
<title>Network Management Datastore Architecture (NMDA)</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwae
lder"/>
<author fullname="P. Shafer" initials="P." surname="Shafer"/>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<author fullname="R. Wilton" initials="R." surname="Wilton"/>
<date month="March" year="2018"/>
<abstract>
<t>Datastores are a fundamental concept binding the data models wr
itten in the YANG data modeling language to network management protocols such as
the Network Configuration Protocol (NETCONF) and RESTCONF. This document define
s an architectural framework for datastores based on the experience gained with
the initial simpler model, addressing requirements that were not well supported
in the initial model. This document updates RFC 7950.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8342"/>
<seriesInfo name="DOI" value="10.17487/RFC8342"/>
</reference>
<reference anchor="RFC9181">
<front>
<title>A Common YANG Data Model for Layer 2 and Layer 3 VPNs</title>
<author fullname="S. Barguil" initials="S." surname="Barguil"/>
<author fullname="O. Gonzalez de Dios" initials="O." role="editor" s
urname="Gonzalez de Dios"/>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="Q. Wu" initials="Q." surname="Wu"/>
<date month="February" year="2022"/>
<abstract>
<t>This document defines a common YANG module that is meant to be
reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN networ
k models.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9181"/>
<seriesInfo name="DOI" value="10.17487/RFC9181"/>
</reference>
<reference anchor="I-D.ietf-opsawg-teas-common-ac">
<front>
<title>A Common YANG Data Model for Attachment Circuits</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Richard Roberts" initials="R." surname="Roberts">
<organization>Juniper</organization>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O. G." surname="
de Dios">
<organization>Telefonica</organization>
</author>
<author fullname="Samier Barguil" initials="S." surname="Barguil">
<organization>Nokia</organization>
</author>
<author fullname="Bo Wu" initials="B." surname="Wu">
<organization>Huawei Technologies</organization>
</author>
<date day="23" month="January" year="2025"/>
<abstract>
<t> The document specifies a common attachment circuits (ACs) YA
NG model,
which is designed to be reusable by other models. This design is
meant to ensure consistent AC structures among models that manipulate
ACs. For example, this common model can be reused by service models
to expose ACs as a service, service models that require binding a
service to a set of ACs, network and device models to provision ACs,
etc.
</t> <!-- [RFC9833] draft-ietf-opsawg-teas-common-ac-15
</abstract> companion doc RFC 9833, in EDIT as of 03/05/25.
</front> -->
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-common <reference anchor="RFC9833" target="https://www.rfc-editor.org/info/rfc9833">
-ac-15"/> <front>
</reference> <title>A Common YANG Data Model for Attachment Circuits</title>
<reference anchor="RFC2119"> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
<front> e="editor">
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <organization>Orange</organization>
le> </author>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <author initials="R." surname="Roberts" fullname="Richard Roberts" role="e
<date month="March" year="1997"/> ditor">
<abstract> <organization>Juniper</organization>
<t>In many standards track documents several words are used to sig </author>
nify the requirements in the specification. These words are often capitalized. T <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez
his document defines these words as they should be interpreted in IETF documents de Dios">
. This document specifies an Internet Best Current Practices for the Internet Co <organization>Telefonica</organization>
mmunity, and requests discussion and suggestions for improvements.</t> </author>
</abstract> <author initials="S." surname="Barguil Giraldo" fullname="Samier Barguil G
</front> iraldo">
<seriesInfo name="BCP" value="14"/> <organization>Nokia</organization>
<seriesInfo name="RFC" value="2119"/> </author>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <author initials="B." surname="Wu" fullname="Bo Wu">
</reference> <organization>Huawei Technologies</organization>
<reference anchor="RFC8174"> </author>
<front> <date month='August' year='2025'/>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti </front>
tle> <seriesInfo name="RFC" value="9833"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/> <seriesInfo name="DOI" value="10.17487/RFC9833"/>
<date month="May" year="2017"/> </reference>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
l specifications. This document aims to reduce the ambiguity by clarifying that 119.xml"/>
only UPPERCASE usage of the key words have the defined special meanings.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 174.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<seriesInfo name="BCP" value="14"/> 991.xml"/>
<seriesInfo name="RFC" value="8174"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="DOI" value="10.17487/RFC8174"/> 177.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<reference anchor="RFC6991"> 364.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<title>Common YANG Data Types</title> 568.xml"/>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
ame="Schoenwaelder"/> 182.xml"/>
<date month="July" year="2013"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<abstract> 291.xml"/>
<t>This document introduces a collection of common data types to b <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
e used with the YANG data modeling language. This document obsoletes RFC 6021.</ 880.xml"/>
t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</abstract> 577.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<seriesInfo name="RFC" value="6991"/> 565.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC6991"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
</reference> 709.xml"/>
<reference anchor="RFC8177"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 474.xml"/>
<title>YANG Data Model for Key Chains</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="A. Lindem" initials="A." role="editor" surname="Li 166.xml"/>
ndem"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<author fullname="Y. Qu" initials="Y." surname="Qu"/> 688.xml"/>
<author fullname="D. Yeung" initials="D." surname="Yeung"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="I. Chen" initials="I." surname="Chen"/> 020.xml"/>
<author fullname="J. Zhang" initials="J." surname="Zhang"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="June" year="2017"/> 792.xml"/>
<abstract>
<t>This document describes the key chain YANG data model. Key chai
ns are commonly used for routing protocol authentication and other applications
requiring symmetric keys. A key chain is a list containing one or more elements
containing a Key ID, key string, send/accept lifetimes, and the associated authe
ntication or encryption algorithm. By properly overlapping the send and accept l
ifetimes of multiple key chain elements, key strings and algorithms may be grace
fully updated. By representing them in a YANG data model, key distribution can b
e automated.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8177"/>
<seriesInfo name="DOI" value="10.17487/RFC8177"/>
</reference>
<reference anchor="RFC8341">
<front>
<title>Network Configuration Access Control Model</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<date month="March" year="2018"/>
<abstract>
<t>The standardization of network configuration interfaces for use
with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requ
ires a structured and secure operating environment that promotes human usability
and multi-vendor interoperability. There is a need for standard mechanisms to r
estrict NETCONF or RESTCONF protocol access for particular users to a preconfigu
red subset of all available NETCONF or RESTCONF protocol operations and content.
This document defines such an access control model.</t>
<t>This document obsoletes RFC 6536.</t>
</abstract>
</front>
<seriesInfo name="STD" value="91"/>
<seriesInfo name="RFC" value="8341"/>
<seriesInfo name="DOI" value="10.17487/RFC8341"/>
</reference>
<reference anchor="RFC4364">
<front>
<title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
<author fullname="E. Rosen" initials="E." surname="Rosen"/>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<date month="February" year="2006"/>
<abstract>
<t>This document describes a method by which a Service Provider ma
y use an IP backbone to provide IP Virtual Private Networks (VPNs) for its custo
mers. This method uses a "peer model", in which the customers' edge routers (CE
routers) send their routes to the Service Provider's edge routers (PE routers);
there is no "overlay" visible to the customer's routing algorithm, and CE router
s at different sites do not peer with each other. Data packets are tunneled thro
ugh the backbone, so that the core routers do not need to know the VPN routes. [
STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4364"/>
<seriesInfo name="DOI" value="10.17487/RFC4364"/>
</reference>
<reference anchor="RFC9568">
<front>
<title>Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4
and IPv6</title>
<author fullname="A. Lindem" initials="A." surname="Lindem"/>
<author fullname="A. Dogra" initials="A." surname="Dogra"/>
<date month="April" year="2024"/>
<abstract>
<t>This document defines version 3 of the Virtual Router Redundanc
y Protocol (VRRP) for IPv4 and IPv6. It obsoletes RFC 5798, which previously spe
cified VRRP (version 3). RFC 5798 obsoleted RFC 3768, which specified VRRP (vers
ion 2) for IPv4. VRRP specifies an election protocol that dynamically assigns re
sponsibility for a Virtual Router to one of the VRRP Routers on a LAN. The VRRP
Router controlling the IPv4 or IPv6 address(es) associated with a Virtual Router
is called the Active Router, and it forwards packets routed to these IPv4 or IP
v6 addresses. Active Routers are configured with virtual IPv4 or IPv6 addresses,
and Backup Routers infer the address family of the virtual addresses being adve
rtised based on the IP protocol version. Within a VRRP Router, the Virtual Route
rs in each of the IPv4 and IPv6 address families are independent of one another
and always treated as separate Virtual Router instances. The election process pr
ovides dynamic failover in the forwarding responsibility should the Active Route
r become unavailable. For IPv4, the advantage gained from using VRRP is a higher
-availability default path without requiring configuration of dynamic routing or
router discovery protocols on every end-host. For IPv6, the advantage gained fr
om using VRRP for IPv6 is a quicker switchover to Backup Routers than can be obt
ained with standard IPv6 Neighbor Discovery mechanisms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9568"/>
<seriesInfo name="DOI" value="10.17487/RFC9568"/>
</reference>
<reference anchor="RFC9182">
<front>
<title>A YANG Network Data Model for Layer 3 VPNs</title>
<author fullname="S. Barguil" initials="S." surname="Barguil"/>
<author fullname="O. Gonzalez de Dios" initials="O." role="editor" s
urname="Gonzalez de Dios"/>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="L. Munoz" initials="L." surname="Munoz"/>
<author fullname="A. Aguado" initials="A." surname="Aguado"/>
<date month="February" year="2022"/>
<abstract>
<t>As a complement to the Layer 3 Virtual Private Network Service
Model (L3SM), which is used for communication between customers and service prov
iders, this document defines an L3VPN Network Model (L3NM) that can be used for
the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a se
rvice provider network. The model provides a network-centric view of L3VPN servi
ces.</t>
<t>The L3NM is meant to be used by a network controller to derive
the configuration information that will be sent to relevant network devices. The
model can also facilitate communication between a service orchestrator and a ne
twork controller/orchestrator.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9182"/>
<seriesInfo name="DOI" value="10.17487/RFC9182"/>
</reference>
<reference anchor="RFC9291">
<front>
<title>A YANG Network Data Model for Layer 2 VPNs</title>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="O. Gonzalez de Dios" initials="O." role="editor" s
urname="Gonzalez de Dios"/>
<author fullname="S. Barguil" initials="S." surname="Barguil"/>
<author fullname="L. Munoz" initials="L." surname="Munoz"/>
<date month="September" year="2022"/>
<abstract>
<t>This document defines an L2VPN Network Model (L2NM) that can be
used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) serv
ices within a network (e.g., a service provider network). The L2NM complements t
he L2VPN Service Model (L2SM) by providing a network-centric view of the service
that is internal to a service provider. The L2NM is particularly meant to be us
ed by a network controller to derive the configuration information that will be
sent to relevant network devices.</t>
<t>Also, this document defines a YANG module to manage Ethernet se
gments and the initial versions of two IANA-maintained modules that include a se
t of identities of BGP Layer 2 encapsulation types and pseudowire types.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9291"/>
<seriesInfo name="DOI" value="10.17487/RFC9291"/>
</reference>
<reference anchor="RFC5880">
<front>
<title>Bidirectional Forwarding Detection (BFD)</title>
<author fullname="D. Katz" initials="D." surname="Katz"/>
<author fullname="D. Ward" initials="D." surname="Ward"/>
<date month="June" year="2010"/>
<abstract>
<t>This document describes a protocol intended to detect faults in
the bidirectional path between two forwarding engines, including interfaces, da
ta link(s), and to the extent possible the forwarding engines themselves, with p
otentially very low latency. It operates independently of media, data protocols,
and routing protocols. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5880"/>
<seriesInfo name="DOI" value="10.17487/RFC5880"/>
</reference>
<reference anchor="RFC4577">
<front>
<title>OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP V
irtual Private Networks (VPNs)</title>
<author fullname="E. Rosen" initials="E." surname="Rosen"/>
<author fullname="P. Psenak" initials="P." surname="Psenak"/>
<author fullname="P. Pillay-Esnault" initials="P." surname="Pillay-E
snault"/>
<date month="June" year="2006"/>
<abstract>
<t>Many Service Providers offer Virtual Private Network (VPN) serv
ices to their customers, using a technique in which customer edge routers (CE ro
uters) are routing peers of provider edge routers (PE routers). The Border Gatew
ay Protocol (BGP) is used to distribute the customer's routes across the provide
r's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tun
nel customer packets across the provider's backbone. This is known as a "BGP/MPL
S IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing
protocol on the interface between a PE router and a CE router is BGP. This docu
ment extends that specification by allowing the routing protocol on the PE/CE in
terface to be the Open Shortest Path First (OSPF) protocol.</t>
<t>This document updates RFC 4364. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4577"/>
<seriesInfo name="DOI" value="10.17487/RFC4577"/>
</reference>
<reference anchor="RFC6565">
<front>
<title>OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Pr
otocol</title>
<author fullname="P. Pillay-Esnault" initials="P." surname="Pillay-E
snault"/>
<author fullname="P. Moyer" initials="P." surname="Moyer"/>
<author fullname="J. Doyle" initials="J." surname="Doyle"/>
<author fullname="E. Ertekin" initials="E." surname="Ertekin"/>
<author fullname="M. Lundberg" initials="M." surname="Lundberg"/>
<date month="June" year="2012"/>
<abstract>
<t>Many Service Providers (SPs) offer Virtual Private Network (VPN
) services to their customers using a technique in which Customer Edge (CE) rout
ers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol
(BGP) is used to distribute the customer's routes across the provider's IP back
bone network, and Multiprotocol Label Switching (MPLS) is used to tunnel custome
r packets across the provider's backbone. Support currently exists for both IPv4
and IPv6 VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as PE-
CE protocol is specified. This document extends those specifications to support
OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functional
ity is identical to that of OSPFv2 except for the differences described in this
document. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6565"/>
<seriesInfo name="DOI" value="10.17487/RFC6565"/>
</reference>
<reference anchor="RFC5709">
<front>
<title>OSPFv2 HMAC-SHA Cryptographic Authentication</title>
<author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
<author fullname="V. Manral" initials="V." surname="Manral"/>
<author fullname="M. Fanto" initials="M." surname="Fanto"/>
<author fullname="R. White" initials="R." surname="White"/>
<author fullname="M. Barnes" initials="M." surname="Barnes"/>
<author fullname="T. Li" initials="T." surname="Li"/>
<author fullname="R. Atkinson" initials="R." surname="Atkinson"/>
<date month="October" year="2009"/>
<abstract>
<t>This document describes how the National Institute of Standards
and Technology (NIST) Secure Hash Standard family of algorithms can be used wit
h OSPF version 2's built-in, cryptographic authentication mechanism. This update
s, but does not supercede, the cryptographic authentication mechanism specified
in RFC 2328. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5709"/>
<seriesInfo name="DOI" value="10.17487/RFC5709"/>
</reference>
<reference anchor="RFC7474">
<front>
<title>Security Extension for OSPFv2 When Using Manual Key Managemen
t</title>
<author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
<author fullname="S. Hartman" initials="S." surname="Hartman"/>
<author fullname="D. Zhang" initials="D." surname="Zhang"/>
<author fullname="A. Lindem" initials="A." role="editor" surname="Li
ndem"/>
<date month="April" year="2015"/>
<abstract>
<t>The current OSPFv2 cryptographic authentication mechanism as de
fined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- sessi
on replay attacks when using manual keying. Additionally, the existing cryptogra
phic authentication mechanism does not cover the IP header. This omission can be
exploited to carry out various types of attacks.</t>
<t>This document defines changes to the authentication sequence nu
mber mechanism that will protect OSPFv2 from both inter-session and intra- sessi
on replay attacks when using manual keys for securing OSPFv2 protocol packets. A
dditionally, we also describe some changes in the cryptographic hash computation
that will eliminate attacks resulting from OSPFv2 not protecting the IP header.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7474"/>
<seriesInfo name="DOI" value="10.17487/RFC7474"/>
</reference>
<reference anchor="RFC7166">
<front>
<title>Supporting Authentication Trailer for OSPFv3</title>
<author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
<author fullname="V. Manral" initials="V." surname="Manral"/>
<author fullname="A. Lindem" initials="A." surname="Lindem"/>
<date month="March" year="2014"/>
<abstract>
<t>Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechan
ism for authenticating protocol packets. This behavior is different from authent
ication mechanisms present in other routing protocols (OSPFv2, Intermediate Syst
em to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Ge
neration (RIPng)). In some environments, it has been found that IPsec is difficu
lt to configure and maintain and thus cannot be used. This document defines an a
lternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does
not depend only upon IPsec for authentication.</t>
<t>The OSPFv3 Authentication Trailer was originally defined in RFC
6506. This document obsoletes RFC 6506 by providing a revised definition, inclu
ding clarifications and refinements of the procedures.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7166"/>
<seriesInfo name="DOI" value="10.17487/RFC7166"/>
</reference>
<reference anchor="RFC3688">
<front>
<title>The IETF XML Registry</title>
<author fullname="M. Mealling" initials="M." surname="Mealling"/>
<date month="January" year="2004"/>
<abstract>
<t>This document describes an IANA maintained registry for IETF st
andards which use Extensible Markup Language (XML) related items such as Namespa
ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew
ork (RDF) Schemas.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference>
<reference anchor="RFC6020">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)</title>
<author fullname="M. Bjorklund" initials="M." role="editor" surname=
"Bjorklund"/>
<date month="October" year="2010"/>
<abstract>
<t>YANG is a data modeling language used to model configuration an
d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON
F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6020"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference>
<reference anchor="RFC8792">
<front>
<title>Handling Long Lines in Content of Internet-Drafts and RFCs</t
itle>
<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" strateg
y, is based on the historical use of a single backslash ('\') character to indic
ate where line-folding has occurred, with the continuation occurring with the fi
rst character that is not a space character (' ') on the next line. The second s
trategy, called the "double backslash" strategy, extends the first strategy by a
dding a second backslash character to identify where the continuation begins and
is thereby able to handle cases not supported by the first strategy. Both strat
egies use a self-describing header enabling automated reconstitution of the orig
inal content.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8792"/>
<seriesInfo name="DOI" value="10.17487/RFC8792"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="Instance-Data" target="https://github.com/boucadair/a ttachment-circuit-model/blob/main/xml-examples/svc-full-instance.xml"> <reference anchor="Instance-Data" target="https://github.com/boucadair/a ttachment-circuit-model/blob/main/xml-examples/svc-full-instance.xml">
<front> <front>
<title>Example of AC SVC Instance Data</title> <title>Example of AC SVC Instance Data</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2024"/> <date month="August" year="2024"/>
</front> </front>
<refcontent>Commit 8081bb7</refcontent>
</reference> </reference>
<reference anchor="IEEE802.1AB" target="https://standards.ieee.org/ieee/
802.1AB/6047/"> <reference anchor="IEEE802.1AB" target="">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks - Stat ion and Media Access Control Connectivity Discovery</title> <title>IEEE Standard for Local and metropolitan area networks - Stat ion and Media Access Control Connectivity Discovery</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date year="2016" month="January"/> <date year="2016" month="January"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.1AB-2016"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7433915"/>
</reference> </reference>
<reference anchor="IEEE802.1AX" target="https://doi.org/10.1109/IEEESTD. 2020.9105034"> <reference anchor="IEEE802.1AX" target="https://doi.org/10.1109/IEEESTD. 2020.9105034">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks--Link Aggregation</title> <title>IEEE Standard for Local and Metropolitan Area Networks--Link Aggregation</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date year="2020" month="May"/> <date year="2020" month="May"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.1AX-2020"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9105034"/>
</reference> </reference>
<reference anchor="ITU-T-G.781" target="https://www.itu.int/rec/T-REC-G. 781"> <reference anchor="ITU-T-G.781" target="https://www.itu.int/rec/T-REC-G. 781">
<front> <front>
<title>Synchronization layer functions for frequency synchronization based on the physical layer</title> <title>Synchronization layer functions for frequency synchronization based on the physical layer</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2024" month="January"/> <date year="2024" month="January"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.781"/>
</reference> </reference>
<reference anchor="RFC7665">
<front>
<title>Service Function Chaining (SFC) Architecture</title>
<author fullname="J. Halpern" initials="J." role="editor" surname="H
alpern"/>
<author fullname="C. Pignataro" initials="C." role="editor" surname=
"Pignataro"/>
<date month="October" year="2015"/>
<abstract>
<t>This document describes an architecture for the specification,
creation, and ongoing maintenance of Service Function Chains (SFCs) in a network
. It includes architectural concepts, principles, and components used in the con
struction of composite services through deployment of SFCs, with a focus on thos
e to be standardized in the IETF. This document does not propose solutions, prot
ocols, or extensions to existing protocols.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7665"/>
<seriesInfo name="DOI" value="10.17487/RFC7665"/>
</reference>
<reference anchor="RFC9543">
<front>
<title>A Framework for Network Slices in Networks Built from IETF Te
chnologies</title>
<author fullname="A. Farrel" initials="A." role="editor" surname="Fa
rrel"/>
<author fullname="J. Drake" initials="J." role="editor" surname="Dra
ke"/>
<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 netwo
rks built from IETF technologies. It defines the term "IETF Network Slice" to de
scribe this type of network slice and establishes the general principles of netw
ork slicing in the IETF context.</t>
<t>The document discusses the general framework for requesting and
operating IETF Network Slices, the characteristics of an IETF Network Slice, th
e necessary system components and interfaces, and the mapping of abstract reques
ts to more specific technologies. The document also discusses related considerat
ions with monitoring and security.</t>
<t>This document also provides definitions of related terms to ena
ble consistent usage in other IETF documents that describe or use aspects of IET
F Network Slices.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9543"/>
<seriesInfo name="DOI" value="10.17487/RFC9543"/>
</reference>
<reference anchor="I-D.ietf-opsawg-ntw-attachment-circuit">
<front>
<title>A Network YANG Data Model for Attachment Circuits</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Richard Roberts" initials="R." surname="Roberts">
<organization>Juniper</organization>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O. G." surname="
de Dios">
<organization>Telefonica</organization>
</author>
<author fullname="Samier Barguil" initials="S." surname="Barguil">
<organization>Nokia</organization>
</author>
<author fullname="Bo Wu" initials="B." surname="Wu">
<organization>Huawei Technologies</organization>
</author>
<date day="9" month="January" year="2025"/>
<abstract>
<t> This document specifies a network model for attachment circu
its. The
model can be used for the provisioning of attachment circuits prior
or during service provisioning (e.g., VPN, Network Slice Service). A
companion service model is specified in the YANG Data Models for
Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf-
opsawg-teas-attachment-circuit).
The module augments the base network ('ietf-network') and the Service <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
Attachment Point (SAP) models with the detailed information for the 665.xml"/>
provisioning of attachment circuits in Provider Edges (PEs). <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
543.xml"/>
</t> <!-- [RFC9835] draft-ietf-opsawg-ntw-attachment-circuit-16
</abstract> IESG State: RFC Ed Queue as of 03/05/25.
</front> -->
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ntw-attachm <reference anchor="RFC9835" target="https://www.rfc-editor.org/info/rfc9835">
ent-circuit-15"/> <front>
</reference> <title>A Network YANG Data Model for Attachment Circuits</title>
<reference anchor="I-D.ietf-opsawg-ac-lxsm-lxnm-glue"> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
<front> e="editor">
<title>A YANG Data Model for Augmenting VPN Service and Network Mode <organization>Orange</organization>
ls with Attachment Circuits</title> </author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai <author initials="R." surname="Roberts" fullname="Richard Roberts">
r"> <organization>Juniper</organization>
<organization>Orange</organization> </author>
</author> <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez
<author fullname="Richard Roberts" initials="R." surname="Roberts"> de Dios">
<organization>Juniper</organization> <organization>Telefonica</organization>
</author> </author>
<author fullname="Samier Barguil" initials="S." surname="Barguil"> <author initials="S." surname="Barguil Giraldo" fullname="Samier Barguil G
<organization>Nokia</organization> iraldo">
</author> <organization>Nokia</organization>
<author fullname="Oscar Gonzalez de Dios" initials="O. G." surname=" </author>
de Dios"> <author initials="B." surname="Wu" fullname="Bo Wu">
<organization>Telefonica</organization> <organization>Huawei Technologies</organization>
</author> </author>
<date day="9" month="January" year="2025"/> <date month="August" year="2025" />
<abstract> </front>
<t> The document specifies a module that updates existing servic <seriesInfo name="RFC" value="9835" />
e (i.e., <seriesInfo name="DOI" value="10.17487/RFC9835"/>
the Layer 2 Service Model (L2SM) and the Layer 3 Service Model </reference>
(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> <!-- [RFC9836] draft-ietf-opsawg-ac-lxsm-lxnm-glue-14
</abstract> IESG State: RFC Ed Queue as of 03/05/25.
</front> -->
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ac-lxsm-lxn <reference anchor="RFC9836" target="https://datatracker.ietf.org/doc/html/draft-
m-glue-13"/> ietf-opsawg-ac-lxsm-lxnm-glue-14">
</reference> <front>
<reference anchor="RFC8466"> <title>A YANG Data Model for Augmenting VPN Service and Network Models wit
<front> h Attachment Circuits</title>
<title>A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
Service Delivery</title> e="editor">
<author fullname="B. Wen" initials="B." surname="Wen"/> <organization>Orange</organization>
<author fullname="G. Fioccola" initials="G." role="editor" surname=" </author>
Fioccola"/> <author initials="R." surname="Roberts" fullname="Richard Roberts">
<author fullname="C. Xie" initials="C." surname="Xie"/> <organization>Juniper</organization>
<author fullname="L. Jalil" initials="L." surname="Jalil"/> </author>
<date month="October" year="2018"/> <author initials="S." surname="Barguil Giraldo" fullname="Samier Barguil G
<abstract> iraldo">
<t>This document defines a YANG data model that can be used to con <organization>Nokia</organization>
figure a Layer 2 provider-provisioned VPN service. It is up to a management syst </author>
em to take this as an input and generate specific configuration models to config <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez
ure the different network elements to deliver the service. How this configuratio de Dios">
n of network elements is done is out of scope for this document.</t> <organization>Telefonica</organization>
<t>The YANG data model defined in this document includes support f </author>
or point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual P <date month="August" year="2025" />
rivate LAN Services (VPLSs) that use Pseudowires signaled using the Label Distri </front>
bution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs <seriesInfo name="RFC" value="9836" />
4761 and 6624.</t> <seriesInfo name="DOI" value="10.17487/RFC9836"/>
<t>The YANG data model defined in this document conforms to the Ne </reference>
twork Management Datastore Architecture defined in RFC 8342.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8466"/>
<seriesInfo name="DOI" value="10.17487/RFC8466"/>
</reference>
<reference anchor="RFC8299">
<front>
<title>YANG Data Model for L3VPN Service Delivery</title>
<author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/>
<author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
<author fullname="L. Tomotaki" initials="L." surname="Tomotaki"/>
<author fullname="K. Ogaki" initials="K." surname="Ogaki"/>
<date month="January" year="2018"/>
<abstract>
<t>This document defines a YANG data model that can be used for co
mmunication between customers and network operators and to deliver a Layer 3 pro
vider-provisioned VPN service. This document is limited to BGP PE-based VPNs as
described in RFCs 4026, 4110, and 4364. This model is intended to be instantiate
d at the management system to deliver the overall service. It is not a configura
tion model to be used directly on network elements. This model provides an abstr
acted view of the Layer 3 IP VPN service configuration components. It will be up
to the management system to take this model as input and use specific configura
tion models to configure the different network elements to deliver the service.
How the configuration of network elements is done is out of scope for this docum
ent.</t>
<t>This document obsoletes RFC 8049; it replaces the unimplementab
le module in that RFC with a new module with the same name that is not backward
compatible. The changes are a series of small fixes to the YANG module and some
clarifications to the text.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8299"/>
<seriesInfo name="DOI" value="10.17487/RFC8299"/>
</reference>
<reference anchor="RFC8921">
<front>
<title>Dynamic Service Negotiation: The Connectivity Provisioning Ne
gotiation 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 ser
vice parameters.</t>
<t>CPNP is a generic protocol that can be used for various negotia
tion purposes that include (but are not necessarily limited to) connectivity pro
visioning 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 in
terdomain
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> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 466.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="Internet-Draft" value="draft-ietf-grow-peering-api-0 299.xml"/>
0"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</reference> 921.xml"/>
<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 languag
e. The majority of these modules are used to construct data models to model devi
ces or monolithic functions.</t>
<t>A small number of YANG modules have been defined to model servi
ces (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produ
ced 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 networkin
g architecture. Note that service models do not make any assumption of how a ser
vice 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 wit
h YANG</title>
<author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="D. Lopez" initials="D." surname="Lopez"/>
<author fullname="C. Xie" initials="C." surname="Xie"/>
<author fullname="L. Geng" initials="L." surname="Geng"/>
<date month="January" year="2021"/>
<abstract>
<t>Data models provide a programmatic approach to represent servic
es and networks. Concretely, they can be used to derive configuration informatio
n for network and service components, and state information that will be monitor
ed and tracked. Data models can be used during the service and network managemen
t life cycle (e.g., service instantiation, service provisioning, service optimiz
ation, service monitoring, service diagnosing, and service assurance). Data mode
ls are also instrumental in the automation of network management, and they can p
rovide closed-loop control for adaptive and deterministic service creation, deli
very, and maintenance.</t>
<t>This document describes a framework for service and network man
agement automation that takes advantage of YANG modeling technologies. This fram
ework is drawn from a network operator perspective irrespective of the origin of
a data model; thus, it can accommodate YANG modules that are developed outside
the IETF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8969"/>
<seriesInfo name="DOI" value="10.17487/RFC8969"/>
</reference>
<reference anchor="RFC8349">
<front>
<title>A YANG Data Model for Routing Management (NMDA Version)</titl
e>
<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. T
ogether, they form the core routing data model that serves as a framework for co
nfiguring and managing a routing subsystem. It is expected that these modules wi
ll be augmented by additional YANG modules defining data models for control-plan
e protocols, route filters, and other functions. The core routing data model pro
vides 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 Manage
ment 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="Jethan
andani">
<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> <!-- [I-D.ietf-grow-peering-api]
</abstract> draft-ietf-grow-peering-api-00
</front> IESG State: I-D Exists as of 03/05/25.
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-model-18"/ -->
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</reference> ietf-grow-peering-api.xml"/>
<reference anchor="RFC8340"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 309.xml"/>
<title>YANG Tree Diagrams</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> 969.xml"/>
<author fullname="L. Berger" initials="L." role="editor" surname="Be <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
rger"/> 349.xml"/>
<date month="March" year="2018"/>
<abstract>
<t>This document captures the current syntax used in YANG module t
ree diagrams. The purpose of this document is to provide a single location for t
his definition. This syntax may be updated from time to time based on the evolut
ion of the YANG language.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="215"/>
<seriesInfo name="RFC" value="8340"/>
<seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference>
<reference anchor="RFC4026">
<front>
<title>Provider Provisioned Virtual Private Network (VPN) Terminolog
y</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 solut
ions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2
VPNs and Layer 3 VPNs) have discussed these proposals and documented specificat
ions. This has lead to the development of a partially new set of concepts used t
o 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 provid
es 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"/>
<date month="August" year="2015"/>
<abstract>
<t>This document updates RFC 4271 and proscribes the use of Autono
mous 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>
</front>
<seriesInfo name="RFC" value="7607"/>
<seriesInfo name="DOI" value="10.17487/RFC7607"/>
</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" surn
ame="Schoenwaelder"/>
<author fullname="A. Bierman" initials="A." role="editor" surname="B
ierman"/>
<date month="June" year="2011"/>
<abstract>
<t>The Network Configuration Protocol (NETCONF) defined in this do
cument provides mechanisms to install, manipulate, and delete the configuration
of network devices. It uses an Extensible Markup Language (XML)-based data encod
ing for the configuration data as well as the protocol messages. The NETCONF pro
tocol operations are realized as remote procedure calls (RPCs). This document ob
soletes 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 Quality of Service (QoS) Information Model</title>
<author fullname="Y. Snir" initials="Y." surname="Snir"/>
<author fullname="Y. Ramberg" initials="Y." surname="Ramberg"/>
<author fullname="J. Strassner" initials="J." surname="Strassner"/>
<author fullname="R. Cohen" initials="R." surname="Cohen"/>
<author fullname="B. Moore" initials="B." surname="Moore"/>
<date month="November" year="2003"/>
<abstract>
<t>This document presents an object-oriented information model for
representing Quality of Service (QoS) network management policies. This documen
t is based on the IETF Policy Core Information Model and its extensions. It defi
nes an information model for QoS enforcement for differentiated and integrated s
ervices using policy. It is important to note that this document defines an info
rmation model, which by definition is independent of any particular data storage
mechanism and access protocol.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3644"/>
<seriesInfo name="DOI" value="10.17487/RFC3644"/>
</reference>
<reference anchor="RFC9234">
<front>
<title>Route Leak Prevention and Detection Using Roles in UPDATE and
OPEN Messages</title>
<author fullname="A. Azimov" initials="A." surname="Azimov"/>
<author fullname="E. Bogomazov" initials="E." surname="Bogomazov"/>
<author fullname="R. Bush" initials="R." surname="Bush"/>
<author fullname="K. Patel" initials="K." surname="Patel"/>
<author fullname="K. Sriram" initials="K." surname="Sriram"/>
<date month="May" year="2022"/>
<abstract>
<t>Route leaks are the propagation of BGP prefixes that violate as
sumptions of BGP topology relationships, e.g., announcing a route learned from o
ne transit provider to another transit provider or a lateral (i.e., non-transit)
peer or announcing a route learned from one lateral peer to another lateral pee
r or a transit provider. These are usually the result of misconfigured or absent
BGP route filtering or lack of coordination between autonomous systems (ASes).
Existing approaches to leak prevention rely on marking routes by operator config
uration, with no check that the configuration corresponds to that of the Externa
l BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the p
eering relationship. This document enhances the BGP OPEN message to establish an
agreement of the peering relationship on each eBGP session between autonomous s
ystems in order to enforce appropriate configuration on both sides. Propagated r
outes are then marked according to the agreed relationship, allowing both preven
tion and detection of route leaks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9234"/>
<seriesInfo name="DOI" value="10.17487/RFC9234"/>
</reference>
<reference anchor="RFC5925">
<front>
<title>The TCP Authentication Option</title>
<author fullname="J. Touch" initials="J." surname="Touch"/>
<author fullname="A. Mankin" initials="A." surname="Mankin"/>
<author fullname="R. Bonica" initials="R." surname="Bonica"/>
<date month="June" year="2010"/>
<abstract>
<t>This document specifies the TCP Authentication Option (TCP-AO),
which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO spec
ifies the use of stronger Message Authentication Codes (MACs), protects against
replays even for long-lived TCP connections, and provides more details on the as
sociation of security with TCP connections than TCP MD5. TCP-AO is compatible wi
th either a static Master Key Tuple (MKT) configuration or an external, out-of-b
and MKT management mechanism; in either case, TCP-AO also protects connections w
hen using the same MKT across repeated instances of a connection, using traffic
keys derived from the MKT, and coordinates MKT changes between endpoints. The re
sult is intended to support current infrastructure uses of TCP MD5, such as to p
rotect long-lived connections (as used, e.g., in BGP and LDP), and to support a
larger set of MACs with minimal other system and operational changes. TCP-AO use
s a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are
never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully c
ompatible with the proposed requirements for the replacement of TCP MD5. [STANDA
RDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5925"/>
<seriesInfo name="DOI" value="10.17487/RFC5925"/>
</reference>
<reference anchor="RFC2453">
<front>
<title>RIP Version 2</title>
<author fullname="G. Malkin" initials="G." surname="Malkin"/>
<date month="November" year="1998"/>
<abstract>
<t>This document specifies an extension of the Routing Information
Protocol (RIP) to expand the amount of useful information carried in RIP messag
es and to add a measure of security. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="56"/>
<seriesInfo name="RFC" value="2453"/>
<seriesInfo name="DOI" value="10.17487/RFC2453"/>
</reference>
<reference anchor="RFC2080">
<front>
<title>RIPng for IPv6</title>
<author fullname="G. Malkin" initials="G." surname="Malkin"/>
<author fullname="R. Minnear" initials="R." surname="Minnear"/>
<date month="January" year="1997"/>
<abstract>
<t>This document specifies a routing protocol for an IPv6 internet
. It is based on protocols and algorithms currently in wide use in the IPv4 Inte
rnet [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2080"/>
<seriesInfo name="DOI" value="10.17487/RFC2080"/>
</reference>
<reference anchor="I-D.ietf-netmod-rfc8407bis">
<front>
<title>Guidelines for Authors and Reviewers of Documents Containing
YANG Data Models</title>
<author fullname="Andy Bierman" initials="A." surname="Bierman">
<organization>YumaWorks</organization>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
</author>
<date day="14" month="January" year="2025"/>
<abstract>
<t> This memo provides guidelines for authors and reviewers of
specifications containing YANG modules, including IANA-maintained
modules. Recommendations and procedures are defined, which are
intended to increase interoperability and usability of Network
Configuration Protocol (NETCONF) and RESTCONF protocol
implementations that utilize YANG modules. This document obsoletes
RFC 8407.
Also, this document updates RFC 8126 by providing additional <!-- [I-D.ietf-idr-bgp-model]
guidelines for writing the IANA considerations for RFCs that specify draft-ietf-idr-bgp-model-18
IANA-maintained modules. The document also updates RFC 6020 by IESG State: I-D Exists as of 03/05/25.
clarifying how modules and their revisions are handled by IANA. -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-idr-bgp-model.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
026.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
607.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
644.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
925.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
453.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
080.xml"/>
</t> <!-- draft-ietf-netmod-rfc8407bis-28 (in queue in EDIT state)
</abstract> -->
</front> <reference anchor="I-D.ietf-netmod-rfc8407bis" target="https://datatracker.ietf.
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis- org/doc/html/draft-ietf-netmod-rfc8407bis-28">
22"/> <front>
</reference> <title>Guidelines for Authors and Reviewers of Documents Containing YANG D
<reference anchor="RFC8040"> ata Models</title>
<front> <author initials="A." surname="Bierman" fullname="Andy Bierman">
<title>RESTCONF Protocol</title> <organization>YumaWorks</organization>
<author fullname="A. Bierman" initials="A." surname="Bierman"/> </author>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
<author fullname="K. Watsen" initials="K." surname="Watsen"/> e="editor">
<date month="January" year="2017"/> <organization>Orange</organization>
<abstract> </author>
<t>This document describes an HTTP-based protocol that provides a <author initials="Q." surname="Wu" fullname="Qin Wu">
programmatic interface for accessing data defined in YANG, using the datastore c <organization>Huawei</organization>
oncepts defined in the Network Configuration Protocol (NETCONF).</t> </author>
</abstract> <date month="June" day="5" year="2025" />
</front> </front>
<seriesInfo name="RFC" value="8040"/> <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis-28"/>
<seriesInfo name="DOI" value="10.17487/RFC8040"/> </reference>
</reference>
<reference anchor="RFC4252">
<front>
<title>The Secure Shell (SSH) Authentication Protocol</title>
<author fullname="T. Ylonen" initials="T." surname="Ylonen"/>
<author fullname="C. Lonvick" initials="C." role="editor" surname="L
onvick"/>
<date month="January" year="2006"/>
<abstract>
<t>The Secure Shell Protocol (SSH) is a protocol for secure remote
login and other secure network services over an insecure network. This document
describes the SSH authentication protocol framework and public key, password, a
nd host-based client authentication methods. Additional authentication methods a
re described in separate documents. The SSH authentication protocol runs on top
of the SSH transport layer protocol and provides a single authenticated tunnel f
or the SSH connection protocol. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4252"/>
<seriesInfo name="DOI" value="10.17487/RFC4252"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC9000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communica
tion, low-latency connection establishment, and network path migration. QUIC inc
ludes security measures that ensure confidentiality, integrity, and availability
in a range of deployment circumstances. Accompanying documents describe the int
egration of TLS for key negotiation, loss detection, and an exemplary congestion
control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC8695">
<front>
<title>A YANG Data Model for the Routing Information Protocol (RIP)<
/title>
<author fullname="X. Liu" initials="X." surname="Liu"/>
<author fullname="P. Sarda" initials="P." surname="Sarda"/>
<author fullname="V. Choudhary" initials="V." surname="Choudhary"/>
<date month="February" year="2020"/>
<abstract>
<t>This document describes a data model for the management of the
Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. Th
e data model includes definitions for configuration, operational state, and Remo
te Procedure Calls (RPCs).</t>
<t>The YANG data model in this document conforms to the Network Ma
nagement Datastore Architecture (NMDA).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8695"/>
<seriesInfo name="DOI" value="10.17487/RFC8695"/>
</reference>
<reference anchor="I-D.ietf-teas-ietf-network-slice-nbi-yang">
<front>
<title>A YANG Data Model for the RFC 9543 Network Slice Service</tit
le>
<author fullname="Bo Wu" initials="B." surname="Wu">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Reza Rokui" initials="R." surname="Rokui">
<organization>Ciena</organization>
</author>
<author fullname="Tarek Saad" initials="T." surname="Saad">
<organization>Cisco Systems, Inc</organization>
</author>
<author fullname="John Mullooly" initials="J." surname="Mullooly">
<organization>Cisco Systems, Inc</organization>
</author>
<date day="21" month="January" year="2025"/>
<abstract>
<t> This document defines a YANG data model for RFC 9543 Network
Slice
Service. The model can be used in the Network Slice Service
interface between a customer and a provider that offers RFC 9543
Network Slice Services.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 695.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network- <!-- [I-D.ietf-teas-ietf-network-slice-nbi-yang]
slice-nbi-yang-18"/> draft-ietf-teas-ietf-network-slice-nbi-yang-22
</reference> IESG State: IESG Evaluation as of 03/05/25.
<reference anchor="RFC6151"> -->
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<title>Updated Security Considerations for the MD5 Message-Digest an ietf-teas-ietf-network-slice-nbi-yang.xml"/>
d the HMAC-MD5 Algorithms</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="S. Turner" initials="S." surname="Turner"/> 151.xml"/>
<author fullname="L. Chen" initials="L." surname="Chen"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<date month="March" year="2011"/> 952.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
<t>This document updates the security considerations for the MD5 m 826.xml"/>
essage digest algorithm. It also updates the security considerations for HMAC-MD <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
5. This document is not an Internet Standards Track specification; it is publish 861.xml"/>
ed for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6151"/>
<seriesInfo name="DOI" value="10.17487/RFC6151"/>
</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="Jethananda
ni"/>
<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 Computat
ion Element Communication Protocol (PCEP), and the Multicast Source Distribution
Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying an
d 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 Networ
k Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Har
dware</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 Pr
otocol 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 c
omment. This is not the specification of an 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 o
ther'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>
</references> </references>
</references> </references>
<?line 3692?> <?line 3692?>
<section anchor="examples"> <section anchor="examples">
<name>Examples</name> <name>Examples</name>
<t>This section includes a non-exhaustive list of examples to illustrate t he use of the service models defined in this document. An example instance data can also be found at <xref target="Instance-Data"/>.</t> <t>This section includes a non-exhaustive list of examples to illustrate t he use of the service models defined in this document. An example of instance da ta can also be found at <xref target="Instance-Data"/>.</t>
<t>Some of the examples below use line wrapping per <xref target="RFC8792" />.</t> <t>Some of the examples below use line wrapping per <xref target="RFC8792" />.</t>
<section anchor="ex-create-bearer"> <section anchor="ex-create-bearer">
<name>Create a New Bearer</name> <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> <t>An example of a request message body to create a bearer is shown in < xref target="create-bearer"/>.</t>
<figure anchor="create-bearer"> <figure anchor="create-bearer">
<name>Example of a Message Body to Create a New Bearer</name> <name>Example of a Message Body to Create a New Bearer</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-bearer-svc:bearers": { "ietf-bearer-svc:bearers": {
"bearer": [ "bearer": [
{ {
"name": "a-name-choosen-by-client", "name": "a-name-chosen-by-client",
"description": "A bearer example", "description": "A bearer example",
"customer-point": { "customer-point": {
"identified-by": "ietf-bearer-svc:device-id", "identified-by": "ietf-bearer-svc:device-id",
"device": { "device": {
"device-id": "CE_X_SITE_Y" "device-id": "CE_X_SITE_Y"
} }
}, },
"type": "ietf-bearer-svc:ethernet" "type": "ietf-bearer-svc:ethernet"
} }
] ]
skipping to change at line 5287 skipping to change at line 4654
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>A 'bearer-reference' is then generated by the controller for this bea rer. <xref target="get-bearer"/> shows the example of a response message body th at is sent by the controller to reply to a GET request:</t> <t>A 'bearer-reference' is then generated by the controller for this bea rer. <xref target="get-bearer"/> shows the example of a response message body th at is sent by the controller to reply to a GET request:</t>
<figure anchor="get-bearer"> <figure anchor="get-bearer">
<name>Example of a Response Message Body with the Bearer Reference</na me> <name>Example of a Response Message Body with the Bearer Reference</na me>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-bearer-svc:bearers": { "ietf-bearer-svc:bearers": {
"bearer": [ "bearer": [
{ {
"name": "a-name-choosen-by-client", "name": "a-name-chosen-by-client",
"description": "A bearer example", "description": "A bearer example",
"sync-phy-capable": true, "sync-phy-capable": true,
"customer-point": { "customer-point": {
"identified-by": "ietf-bearer-svc:device-id", "identified-by": "ietf-bearer-svc:device-id",
"device": { "device": {
"device-id": "CE_X_SITE_Y" "device-id": "CE_X_SITE_Y"
} }
}, },
"type": "ietf-bearer-svc:ethernet", "type": "ietf-bearer-svc:ethernet",
"bearer-reference": "line-156" "bearer-reference": "line-156"
skipping to change at line 5309 skipping to change at line 4676
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>Note that the response also indicates that Sync Phy mechanism is supp orted for this bearer.</t> <t>Note that the response also indicates that Sync Phy mechanism is supp orted for this bearer.</t>
</section> </section>
<section anchor="ac-bearer-exist"> <section anchor="ac-bearer-exist">
<name>Create an AC over an Existing Bearer</name> <name>Create an AC over an Existing Bearer</name>
<t>An example of a request message body to create a simple AC over an ex isting 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, exchanged out-of-band or via propriet ary APIs).</t> <t>An example of a request message body to create a simple AC over an ex isting 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 exchanged out-of-band or via proprieta ry APIs).</t>
<figure anchor="ac-b"> <figure anchor="ac-b">
<name>Example of a Message Body to Request an AC over an Existing Bear er</name> <name>Example of a Message Body to Request an AC over an Existing Bear er</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-ac-svc:attachment-circuits": { "ietf-ac-svc:attachment-circuits": {
"ac": [ "ac": [
{ {
"name": "ac4585", "name": "ac4585",
"description": "An AC on an existing bearer", "description": "An AC on an existing bearer",
"requested-start": "2023-12-12T05:00:00.00Z", "requested-start": "2023-12-12T05:00:00.00Z",
skipping to change at line 5332 skipping to change at line 4699
"type": "ietf-vpn-common:dot1q" "type": "ietf-vpn-common:dot1q"
}, },
"bearer-reference": "line-156" "bearer-reference": "line-156"
} }
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t><xref target="ac-br"/> shows the message body of a GET response recei ved from the controller and which indicates the 'cvlan-id' that was assigned for the requested AC.</t> <t><xref target="ac-br"/> shows the message body of a GET response recei ved from the controller and that indicates the 'cvlan-id' that was assigned for the requested AC.</t>
<figure anchor="ac-br"> <figure anchor="ac-br">
<name>Example of a Message Body of a Response to Assign a CVLAN ID</na me> <name>Example of a Message Body of a Response to Assign a Customer VLA N (C-VLAN) ID</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-ac-svc:attachment-circuits": { "ietf-ac-svc:attachment-circuits": {
"ac": [ "ac": [
{ {
"name": "ac4585", "name": "ac4585",
"description": "An AC on an existing bearer", "description": "An AC on an existing bearer",
"actual-start": "2023-12-12T05:00:00.00Z", "actual-start": "2023-12-12T05:00:00.00Z",
"l2-connection": { "l2-connection": {
"encapsulation": { "encapsulation": {
skipping to change at line 5382 skipping to change at line 4749
"requested-start": "2025-12-12T05:00:00.00Z", "requested-start": "2025-12-12T05:00:00.00Z",
"peer-sap-id": [ "peer-sap-id": [
"nf-termination-ip" "nf-termination-ip"
] ]
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t><xref target="ac-known-ps-res"/> shows the received GET response with the required informaiton to connect the SF.</t> <t><xref target="ac-known-ps-res"/> shows the received GET response with the required information to connect the SF.</t>
<figure anchor="ac-known-ps-res"> <figure anchor="ac-known-ps-res">
<name>Example of a Message Body of a Response to Create an AC with a P eer SAP</name> <name>Example of a Message Body of a Response to Create an AC with a P eer SAP</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-ac-svc:attachment-circuits": { "ietf-ac-svc:attachment-circuits": {
"ac": [ "ac": [
{ {
"name": "ac4585", "name": "ac4585",
"description": "An AC for a known peer SAP", "description": "An AC for a known peer SAP",
"actual-start": "2025-12-12T05:00:00.00Z", "actual-start": "2025-12-12T05:00:00.00Z",
skipping to change at line 5414 skipping to change at line 4781
} }
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="sec-ex-one-ce-multi-acs"> <section anchor="sec-ex-one-ce-multi-acs">
<name>One CE, Two ACs</name> <name>One CE, Two ACs</name>
<t>Let us consider the example of an eNodeB (CE) that is directly connec ted 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 for Control and User Planes).</t> <t>Let us consider the example of an eNodeB (CE) that is directly connec ted 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 for control and user planes).</t>
<figure anchor="enodeb"> <figure anchor="enodeb">
<name>Example of a CE-PE ACs</name> <name>Example of CE-PE ACs</name>
<artset> <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"> <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 8,32 L 8,160" fill="none" stroke="black"/>
<path d="M 120,32 L 120,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 272,32 L 272,224" fill="none" stroke="black"/>
<path d="M 424,32 L 424,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 8,32 L 120,32" fill="none" stroke="black"/>
<path d="M 272,32 L 424,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 120,64 L 184,64" fill="none" stroke="black"/>
<path d="M 216,64 L 272,64" fill="none" stroke="black"/> <path d="M 216,64 L 272,64" fill="none" stroke="black"/>
skipping to change at line 5710 skipping to change at line 5077
} }
} }
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>A customer may request adding a new AC by simply referring to an exis ting 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> <t>A customer may request adding a new AC by simply referring to an exis ting 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"> <figure anchor="add-ac-same-ce-node-profile">
<name>Example of a Message Body to Add a new AC over an existing link (Node Profile)</name> <name>Example of a Message Body to Add a New AC over an Existing Link (Node Profile)</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-ac-svc:attachment-circuits": { "ietf-ac-svc:attachment-circuits": {
"ac-group-profile": [ "ac-group-profile": [
{ {
"name": "simple-node-profile" "name": "simple-node-profile"
} }
], ],
"ac": [ "ac": [
{ {
skipping to change at line 5900 skipping to change at line 5267
| CE1+-------+ +-------+ CE3| | CE1+-------+ +-------+ CE3|
'---' | | '---' '---' | | '---'
| Network | | Network |
.---. ac2 | | ac4 .---. .---. ac2 | | ac4 .---.
|CE2 +-------+ +-------+ CE4| |CE2 +-------+ +-------+ CE4|
'---' | | '---' '---' | | '---'
'----------------------------------' '----------------------------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Let's assume that a request to instantiate various ACs that are shown in <xref target="network-example"/> is sent by the customer. <xref target="mult iple-sites"/> depicts the example of the message body of a GET response that is received from the controller.</t> <t>Let's assume that a request to instantiate the various ACs that are s hown 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"> <figure anchor="multiple-sites">
<name>Example of a Message Body of a Request to Create Multiple ACs bo und to Multiple CEs</name> <name>Example of a Message Body of a Request to Create Multiple ACs Bo und to Multiple CEs</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-ac-svc:attachment-circuits": { "ietf-ac-svc:attachment-circuits": {
"ac-group-profile": [ "ac-group-profile": [
{ {
"name": "simple-profile", "name": "simple-profile",
"l2-connection": { "l2-connection": {
"encapsulation": { "encapsulation": {
"type": "ietf-vpn-common:dot1q", "type": "ietf-vpn-common:dot1q",
"dot1q": { "dot1q": {
skipping to change at line 5969 skipping to change at line 5336
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="sec-ex-slice"> <section anchor="sec-ex-slice">
<name>Binding Attachment Circuits to an IETF Network Slice</name> <name>Binding Attachment Circuits to an IETF Network Slice</name>
<t>This example shows how the AC service model complements the model def ined 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 Servi ce.</t> <t>This example shows how the AC service model complements the model def ined 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 Servi ce.</t>
<t>First, <xref target="slice-vlan-1"/> describes the end-to-end network topology as well the orchestration scopes:</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"> <ul spacing="normal">
<li> <li>
<t>The topology is made up of two sites ("site1" and "site2"), inter connected via a Transport Network (e.g., IP/MPLS network). An SF is deployed wit hin each site in a dedicated IP subnet.</t> <t>The topology is made up of two sites ("site1" and "site2"), inter connected via a Transport Network (e.g., IP/MPLS network). An SF is deployed wit hin each site in a dedicated IP subnet.</t>
</li> </li>
<li> <li>
<t>A 5G Service Management and Orchestration (SMO) is responsible fo r the deployment of SFs and the indirect management of a local Gateway (i.e., CE ).</t> <t>A 5G Service Management and Orchestration (SMO) is responsible fo r the deployment of SFs and the indirect management of a local gateway (i.e., CE ).</t>
</li> </li>
<li> <li>
<t>An IETF Network Slice Controller (NSC) <xref target="RFC9543"/> i s responsible for the deployment of IETF Network Slices across the Transport Net work.</t> <t>An IETF Network Slice Controller (NSC) <xref target="RFC9543"/> i s responsible for the deployment of IETF Network Slices across the Transport Net work.</t>
</li> </li>
</ul> </ul>
<t>SFs are deployed within each site.</t> <t>SFs are deployed within each site.</t>
<figure anchor="slice-vlan-1"> <figure anchor="slice-vlan-1">
<name>An Example of a Network Topology Used to Deploy Slices</name> <name>An Example of a Network Topology Used to Deploy Slices</name>
<artset> <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"> <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">
skipping to change at line 6524 skipping to change at line 5891
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="sec-ex-cloud"> <section anchor="sec-ex-cloud">
<name>Connecting a Virtualized Environment Running in a Cloud Provider</ name> <name>Connecting a Virtualized Environment Running in a Cloud Provider</ name>
<t>This example (<xref target="cloud-provider-1"/>) shows how the AC ser vice model can be used to connect a Cloud Infrastructure to a service provider n etwork. This example makes the following assumptions:</t> <t>This example (<xref target="cloud-provider-1"/>) shows how the AC ser vice model can be used to connect a Cloud Infrastructure to a service provider n etwork. This example makes the following assumptions:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1">
<t>A customer (e.g., Mobile Network Team or partner) has a virtualiz <li>A customer (e.g., Mobile Network Team or partner) has a
ed infrastructure running in a Cloud Provider. A simplistic deployment is repres virtualized infrastructure running in a Cloud Provider. A simplistic
ented here with a set of Virtual Machines running in a Virtual Private Environme deployment is represented here with a set of Virtual Machines (VMs)
nt. The deployment and management of this infrastructure is achieved via private running in a Virtual Private Environment. The deployment and
APIs that are supported by the Cloud Provider: this realization is out of the s management of this infrastructure is achieved via private APIs that
cope of this document.</t> are supported by the Cloud Provider; this realization is out of the
</li> scope of this document.</li>
<li> <li>The connectivity to the data center is achieved thanks to a
<t>The connectivity to the Data Center is achieved thanks to a servi service based on direct attachment (physical connection), which is
ce based on direct attachment (physical connection), which is delivered upon ord delivered upon ordering via an API exposed by the Cloud
ering via an API exposed by the Cloud Provider. When ordering that connection, a Provider. When ordering that connection, a unique "Connection
unique "Connection Identifier" is generated and returned via the API.</t> Identifier" is generated and returned via the API.</li>
</li> <li>The customer provisions the networking logic
<li> within the Cloud Provider based on that unique Connection Identifier
<t>The customer provisions the networking logic within the Cloud Pro (i.e., logical interfaces, IP addressing, and routing).</li>
vider based on that unique connection identifier (i.e., logical interfaces, IP a
ddressing, and routing).</t>
</li>
</ol> </ol>
<figure anchor="cloud-provider-1"> <figure anchor="cloud-provider-1">
<name>An Example of Realization for Connecting a Cloud Site</name> <name>An Example of Realization for Connecting a Cloud Site</name>
<artset> <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"> <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,32 L 32,272" fill="none" stroke="black"/>
<path d="M 32,384 L 32,528" 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 56,80 L 56,112" fill="none" stroke="black"/>
<path d="M 72,112 L 72,144" 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 88,80 L 88,112" fill="none" stroke="black"/>
skipping to change at line 6660 skipping to change at line 6034
| '-----' | | '-----' |
| | | |
| | | |
| | | |
'--------------------------------------------------------' '--------------------------------------------------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t><xref target="cloud-provider-2"/> illustrates the pre-provisioning lo gic 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> <t><xref target="cloud-provider-2"/> illustrates the pre-provisioning lo gic 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"> <figure anchor="cloud-provider-2">
<name>Illustration of Pre-provisioning</name> <name>Illustration of Pre-Provisioning</name>
<artset> <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"> <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 136,64 L 520,64" fill="none" stroke="black"/>
<path d="M 128,112 L 512,112" 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" fil l="black" transform="rotate(0,520,64)"/> <polygon class="arrowhead" points="528,64 516,58.4 516,69.6" fil l="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)"/> <polygon class="arrowhead" points="136,112 124,106.4 124,117.6" fill="black" transform="rotate(180,128,112)"/>
<g class="text"> <g class="text">
<text x="52" y="36">Customer</text> <text x="52" y="36">Customer</text>
<text x="544" y="36">Cloud</text> <text x="544" y="36">Cloud</text>
<text x="56" y="52">Orchestration</text> <text x="56" y="52">Orchestration</text>
skipping to change at line 6728 skipping to change at line 6102
Physical Connection 1234-56789 is delivered and Physical Connection 1234-56789 is delivered and
connected to PE1 connected to PE1
Network Inventory Updated with: Network Inventory Updated with:
bearer-reference: 1234-56789 for PE1/Interface "If-A" bearer-reference: 1234-56789 for PE1/Interface "If-A"
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Next, API workflows can be initiated by:</t> <t>Next, API workflows can be initiated by:</t>
<ul spacing="normal"> <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> <li>
<t>The Cloud Provider for the configuration per Step (3) above.</t> <t>The Cloud Provider for the configuration per Step (3) above.</t>
</li> </li>
<li> <li>
<t>The Service provider network via the ACaaS model. This request ca n be used in conjunction with additional requests based on the L3SM (VPN provisi oning) or Network Slice Service model (5G hybrid Cloud deployment).</t> <t>The service provider network via the ACaaS model. This request ca n be used in conjunction with additional requests based on the L3SM (VPN provisi oning) or Network Slice Service model (5G hybrid cloud deployment).</t>
</li> </li>
</ul> </ul>
<t><xref target="cloud-provider-ac"/> shows the message body of the requ est to create the required ACs to connect the Cloud Provider Virtualized (VM) us ing the ACaaS module.</t> <t><xref target="cloud-provider-ac"/> shows the message body of the requ est to create the required ACs to connect the virtualized Cloud Provider (VM) us ing the ACaaS module.</t>
<figure anchor="cloud-provider-ac"> <figure anchor="cloud-provider-ac">
<name>Message Body of a Request to Create the ACs for Connecting to th e Cloud Provider</name> <name>Message Body of a Request to Create the ACs for Connecting to th e Cloud Provider</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-ac-svc:attachment-circuits": { "ietf-ac-svc:attachment-circuits": {
"ac": [ "ac": [
{ {
"name": "ac--BXT-DC-customer-VPC-foo", "name": "ac--BXT-DC-customer-VPC-foo",
skipping to change at line 6784 skipping to change at line 6170
} }
] ]
} }
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </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> <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> <!--[rfced] We note that this text was indented. As it is unclear to us why
<t>The module supports MD5 to basically accommodate the installed BG it was indented, we have removed the indentation. Was the intent for this
P base (including by some Cloud Providers). Note that MD5 suffers from the secur to be a "Note"? If yes, would you like this text to be in an <aside> element,
ity weaknesses discussed in <xref section="2" sectionFormat="of" target="RFC6151 which is defined as "a container for content that is semantically less important
"/> and <xref section="2.1" sectionFormat="of" target="RFC6952"/>.</t> or tangential to the content that surrounds it"
</li> (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
</ul>
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 insta
lled BGP base (including by some Cloud Providers). Note that MD5 suffers from th
e security weaknesses discussed in <xref section="2" sectionFormat="of" target="
RFC6151"/> and <xref section="2.1" sectionFormat="of" target="RFC6952"/>.</t>
<figure anchor="cloud-provider-ac-res"> <figure anchor="cloud-provider-ac-res">
<name>Message Body of a Response to the Request to Create ACs for Conn ecting to the Cloud Provider</name> <name>Message Body of a Response to the Request to Create ACs for Conn ecting to the Cloud Provider</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-ac-svc:attachment-circuits": { "ietf-ac-svc:attachment-circuits": {
"ac": [ "ac": [
{ {
"name": "ac--BXT-DC-customer-VPC-foo", "name": "ac--BXT-DC-customer-VPC-foo",
skipping to change at line 6856 skipping to change at line 6260
} }
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="sec-cus-bgp"> <section anchor="sec-cus-bgp">
<name>Connect Customer Network Through BGP</name> <name>Connect Customer Network Through BGP</name>
<t>CE-PE routing using BGP is a common scenario in the context of MPLS V PNs 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) 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> <t>CE-PE routing using BGP is a common scenario in the context of MPLS V PNs 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 ) and use point-to-point interfaces to establish BGP sessions. The point-to-poin t interfaces rely upon a physical bearer ("line-113") to reach the provider netw ork.</t>
<figure anchor="provider-network"> <figure anchor="provider-network">
<name>Illustration of Provider Network Scenario</name> <name>Illustration of Provider Network Scenario</name>
<artset> <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"> <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 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,80 L 80,176" fill="none" stroke="black"/>
<path d="M 80,208 L 80,240" 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 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,80 L 184,176" fill="none" stroke="black"/>
<path d="M 184,208 L 184,240" fill="none" stroke="black"/> <path d="M 184,208 L 184,240" fill="none" stroke="black"/>
skipping to change at line 6939 skipping to change at line 6343
| . | | . |
| . | | . |
| . | | . |
| .------------. | | .------------. |
| | PEm(VRFmn) | | | | PEm(VRFmn) | |
| '------------' | | '------------' |
'------------------------' '------------------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </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 a ttachment 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 session makes use of peer group detai ls instead of defining the entire configuration inside the 'neighbor' data node. </t> <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 a ttachment 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 session make use of peer group detail s instead of defining the entire configuration inside the 'neighbor' data node.< /t>
<figure anchor="add-attachment-circuit-bgp-routing"> <figure anchor="add-attachment-circuit-bgp-routing">
<name>Message Body of a Request to Create ACs for Connecting CEs to a Provider Network</name> <name>Message Body of a Request to Create ACs for Connecting CEs to a Provider Network</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-ac-svc:attachment-circuits": { "ietf-ac-svc:attachment-circuits": {
"ac": [ "ac": [
{ {
"name": "CE-PE-AC", "name": "CE-PE-AC",
"customer-name": "Customer-4875", "customer-name": "Customer-4875",
"description": "An AC between a CP and a PE", "description": "An AC between a CP and a PE",
skipping to change at line 7010 skipping to change at line 6414
} }
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </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> <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>
<section anchor="sec-peering"> <section anchor="sec-peering">
<name>Interconnection via Internet eXchange Points (IXPs)</name> <name>Interconnection via Internet Exchange Points (IXPs)</name>
<t>This section illustrates how to use the AC service model for intercon <t>This section illustrates how to use the AC service model for intercon
nection purposes. To that aim, the document assumes a simplified Internet eXchan nection purposes. To that aim, the document assumes a simplified IXP configurati
ge Point (IXP) configuration without zooming into IXP deployment specifics. Let on without zooming into IXP deployment specifics. Let us assume that networks ar
us assume that networks are interconnected via a Layer 2 facility. Let us also a e interconnected via a Layer 2 facility. Let us also assume a deployment context
ssume a deployment context where selective peering is in place between these net where selective peering is in place between these networks. Networks that are i
works. Networks that are interested in establishing selective BGP peerings expos nterested in establishing selective BGP peerings expose a dedicated ACaaS server
e a dedicated ACaaS server to the IXP to behave as an ACaaS provider. BGP is use to the IXP to behave as an ACaaS provider. BGP is used to exchange routing info
d to exchange routing information and reachability announcements between those n rmation and reachability announcements between those networks. Any network opera
etworks. Any network operator connected to an IXP can behave as a client (i.e., tor connected to an IXP can behave as a client (i.e., initiate a BGP peering req
initiate a BGP peering request).</t> uest).</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 s tep.</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 s tep.</t>
<figure anchor="_u-ex-rb"> <figure anchor="_u-ex-rb">
<name>Recursive Deployment Example</name> <name>Recursive Deployment Example</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="320" width="584" viewBox="0 0 584 320" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="320" width="584" viewBox="0 0 584 320" class="diagr am" 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,48 L 8,80" fill="none" stroke="black"/>
<path d="M 8,176 L 8,272" 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,96 L 64,128" fill="none" stroke="black"/>
<path d="M 64,160 L 64,176" 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 104,176 L 104,272" fill="none" stroke="black"/>
skipping to change at line 7130 skipping to change at line 6534
<text x="164" y="212">Base</text> <text x="164" y="212">Base</text>
<text x="196" y="212">AC</text> <text x="196" y="212">AC</text>
<text x="292" y="212">Facility</text> <text x="292" y="212">Facility</text>
<text x="396" y="212">Base</text> <text x="396" y="212">Base</text>
<text x="428" y="212">AC</text> <text x="428" y="212">AC</text>
<text x="176" y="244">.................</text> <text x="176" y="244">.................</text>
<text x="264" y="244">BGP</text> <text x="264" y="244">BGP</text>
<text x="376" y="244">Session................</text> <text x="376" y="244">Session................</text>
<text x="16" y="308">B2B</text> <text x="16" y="308">B2B</text>
<text x="52" y="308">C/S:</text> <text x="52" y="308">C/S:</text>
<text x="124" y="308">Back-to-back</text> <text x="124" y="308">Back-to-Back</text>
<text x="232" y="308">Client/Server</text> <text x="232" y="308">Client/Server</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
.----------. AC .--------. AC .----------. .----------. AC .--------. AC .----------.
| Network | Service Model | IXP | Service Model | Network | | Network | Service Model | IXP | Service Model | Network |
| Operator A |<-------------->| Operator |<-------------->| Operator B | | Operator A |<-------------->| Operator |<-------------->| Operator B |
| | | B2B C/S | | | | | | B2B C/S | | |
'-----^----' '----^---' '-----^----' '-----^----' '----^---' '-----^----'
skipping to change at line 7153 skipping to change at line 6557
Provisioning Provisioning Provisioning Provisioning Provisioning Provisioning
| | | | | |
.------v----. .-----v----. .------v-----. .------v----. .-----v----. .------v-----.
| ASBR |======Bearer=====| Layer 2 |=====Bearer=====| ASBR | | ASBR |======Bearer=====| Layer 2 |=====Bearer=====| ASBR |
| +-----Base AC-----+ Facility +-----Base AC----| | | +-----Base AC-----+ Facility +-----Base AC----| |
| | | | | | | | | | | |
| +..................BGP Session................+ | | +..................BGP Session................+ |
| |=================| |================| | | |=================| |================| |
'-----------' '----------' '------------' '-----------' '----------' '------------'
B2B C/S: Back-to-back Client/Server B2B C/S: Back-to-Back Client/Server
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>The following subsections exemplify a deployment flow, but BGP sessio ns can be managed without having to execute systematically all the steps detaile d hereafter.</t> <t>The following subsections exemplify a deployment flow, but BGP sessio ns can be managed without having to systematically execute all the steps detaile d hereafter.</t>
<t>The bearer/AC service models can be used to establish interconnection between two networks without involving an IXP.</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"> <section anchor="sec-ret-loc">
<name>Retrieve Interconnection Locations</name> <name>Retrieve Interconnection Locations</name>
<t><xref target="ex-retrieve-locations"/> shows an example a message b ody of a request to retrieve a list of interconnection locations. The request in cludes a customer name and an ASN to filter out the locations.</t> <t><xref target="ex-retrieve-locations"/> shows an example message bod y of a request to retrieve a list of interconnection locations. The request incl udes a customer name and an ASN to filter out the locations.</t>
<figure anchor="ex-retrieve-locations"> <figure anchor="ex-retrieve-locations">
<name>Message Body of a Request to Retrieve Interconnection Location s</name> <name>Message Body of a Request to Retrieve Interconnection Location s</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-bearer-svc:locations": { "ietf-bearer-svc:locations": {
"filtered-by": "ietf-bearer-svc:customer-name", "filtered-by": "ietf-bearer-svc:customer-name",
"customer": [ "customer": [
{ {
"name": "a future peer", "name": "a future peer",
"peer-as": 65536 "peer-as": 65536
skipping to change at line 7207 skipping to change at line 6611
] ]
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="create-bearers-and-retrieve-bearer-references"> <section anchor="create-bearers-and-retrieve-bearer-references">
<name>Create Bearers and Retrieve Bearer References</name> <name>Create Bearers and Retrieve Bearer References</name>
<t>A peer can then use the location information and select the ones wh ere it can request new bearers. As shown in <xref target="ex-create-bearer-paren t-ref"/>, the request includes a location reference which is known to the server (returned in <xref target="ex-retrieve-locations-res"/>).</t> <t>A peer can then use the location information and select the ones wh ere it can request new bearers. As shown in <xref target="ex-create-bearer-paren t-ref"/>, the request includes a location reference that is known to the server (returned in <xref target="ex-retrieve-locations-res"/>).</t>
<figure anchor="ex-create-bearer-parent-ref"> <figure anchor="ex-create-bearer-parent-ref">
<name>Message Body of a Request to Create a Bearer using a Provider- Assigned Reference</name> <name>Message Body of a Request to Create a Bearer Using a Provider& nbhy;Assigned Reference</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-bearer-svc:bearers": { "ietf-bearer-svc:bearers": {
"bearer": [ "bearer": [
{ {
"name": "a-name-choosen-by-client", "name": "a-name-chosen-by-client",
"provider-location-reference": "Location-X", "provider-location-reference": "Location-X",
"customer-point": { "customer-point": {
"identified-by": "ietf-bearer-svc:device-id", "identified-by": "ietf-bearer-svc:device-id",
"device": { "device": {
"device-id": "ASBR_1_Location_X" "device-id": "ASBR_1_Location_X"
} }
}, },
"type": "ietf-bearer-svc:ethernet" "type": "ietf-bearer-svc:ethernet"
} }
] ]
skipping to change at line 7238 skipping to change at line 6642
]]></sourcecode> ]]></sourcecode>
</figure> </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. Tha t reference can be used for subsequent AC activation requests.</t> <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. Tha t reference can be used for subsequent AC activation requests.</t>
<figure anchor="ex-create-bearer-parent-ref-res"> <figure anchor="ex-create-bearer-parent-ref-res">
<name>Message Body of a Response for a Bearer Created in a Specific Location</name> <name>Message Body of a Response for a Bearer Created in a Specific Location</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-bearer-svc:bearers": { "ietf-bearer-svc:bearers": {
"bearer": [ "bearer": [
{ {
"name": "a-name-choosen-by-client", "name": "a-name-chosen-by-client",
"provider-location-reference": "Location-X", "provider-location-reference": "Location-X",
"customer-point": { "customer-point": {
"identified-by": "ietf-bearer-svc:device-id", "identified-by": "ietf-bearer-svc:device-id",
"device": { "device": {
"device-id": "ASBR_1_Location_X" "device-id": "ASBR_1_Location_X"
} }
}, },
"type": "ietf-bearer-svc:ethernet", "type": "ietf-bearer-svc:ethernet",
"bearer-reference": "Location-X-Line-114", "bearer-reference": "Location-X-Line-114",
"status": { "status": {
skipping to change at line 7433 skipping to change at line 6837
} }
] ]
} }
} }
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>Once the ACs are established, BGP peering sessions can be configure d 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 u s assume that BGP sessions are established directly between two network. <xref t arget="bgp-peer-network-add-bgp-attachment-circuit"/> shows an example of a requ est to add a BGP session to an existing AC. The properties of that AC are not re peated in this request because that information is already communicated during t he creation of the AC.</t> <t>Once the ACs are established, BGP peering sessions can be configure d 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 u s assume that BGP sessions are established directly between two networks. <xref target="bgp-peer-network-add-bgp-attachment-circuit"/> shows an example of a req uest to add a BGP session to an existing AC. The properties of that AC are not r epeated 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"> <figure anchor="bgp-peer-network-add-bgp-attachment-circuit">
<name>Message Body of a Request to Create a BGP Session over an AC</ name> <name>Message Body of a Request to Create a BGP Session over an AC</ name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-ac-svc:attachment-circuits": { "ietf-ac-svc:attachment-circuits": {
"ac": [ "ac": [
{ {
"name": "Attachment Circuit 1", "name": "Attachment Circuit 1",
"routing-protocols": { "routing-protocols": {
"routing-protocol": [ "routing-protocol": [
skipping to change at line 7479 skipping to change at line 6883
} }
} }
] ]
} }
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t><xref target="bgp-awaiting-validation"/> provides the example of a response which indicates that the request is awaiting validation. The response i ncludes also a server-assigned reference for this BGP session.</t> <t><xref target="bgp-awaiting-validation"/> provides the example of a response that indicates that the request is awaiting validation. The response al so includes a server-assigned reference for this BGP session.</t>
<figure anchor="bgp-awaiting-validation"> <figure anchor="bgp-awaiting-validation">
<name>Message Body of a Response for a BGP Session Awaiting Validati on</name> <name>Message Body of a Response for a BGP Session Awaiting Validati on</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-ac-svc:attachment-circuits": { "ietf-ac-svc:attachment-circuits": {
"ac": [ "ac": [
{ {
"name": "Attachment Circuit 1", "name": "Attachment Circuit 1",
skipping to change at line 7533 skipping to change at line 6937
] ]
} }
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>Once validation is accomplished, a status update is communicated ba ck to the requestor. The BGP session can then be established over the AC. The BG P session configuration includes parameters such as neighbor IP addresses, ASNs, authentication settings (if required), etc. The configuration is triggered at e ach side of the BGP connection (i.e., peer ASBRs).</t> <t>Once validation is accomplished, a status update is communicated ba ck to the requestor. The BGP session can then be established over the AC. The BG P session configuration includes parameters such as neighbor IP addresses, ASNs, authentication settings (if required), etc. The configuration is triggered at e ach side of the BGP connection (i.e., peer ASBRs).</t>
<figure anchor="bgp-peering-all-sessions"> <figure anchor="bgp-peering-all-sessions">
<name>Message Body of a Response to Report All Active BGP sessions o ver an AC</name> <name>Message Body of a Response to Report All Active BGP Sessions o ver an AC</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-ac-svc:routing-protocols": { "ietf-ac-svc:routing-protocols": {
"routing-protocol": [ "routing-protocol": [
{ {
"id": "BGP", "id": "BGP",
"type": "ietf-vpn-common:bgp-routing", "type": "ietf-vpn-common:bgp-routing",
"bgp": { "bgp": {
"neighbor": [ "neighbor": [
{ {
skipping to change at line 7602 skipping to change at line 7006
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="sec-cloudified-nfs"> <section anchor="sec-cloudified-nfs">
<name>Connectivity of Cloud Network Functions</name> <name>Connectivity of Cloud Network Functions</name>
<section anchor="scope"> <section anchor="scope">
<name>Scope</name> <name>Scope</name>
<t>This section demonstrates how the AC service model permits managing connectivity requirements for complex Network Functions (NFs) - containerized o r virtualized - that are typically deployed in Telco networks. This integration leverages the concept of "parent AC" to decouple physical and logical connectiv ity so that several ACs can shares Layer 2 and Layer 3 resources. This approach provides flexibility, scalability, and API stability.</t> <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 integratio n leverages the concept of "parent AC" to decouple physical and logical connecti vity so that several ACs can share Layer 2 and Layer 3 resources. This approach provides flexibility, scalability, and API stability.</t>
<t>The NFs have the following characteristics:</t> <t>The NFs have the following characteristics:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The NF is distributed on a set of compute nodes with scaled-out and redundant instances.</t> <t>The NF is distributed on a set of compute nodes with scaled-out and redundant instances.</t>
</li> </li>
<li> <li>
<t>The NF has two distinct type of instances: user plane ("nf-up") and routing control plane ("nf-cp").</t> <t>The NF has two distinct type of instances: user plane ("nf-up") and routing control plane ("nf-cp").</t>
</li> </li>
<li> <li>
<t>The user plane component can be distributed among the first 8 c ompute nodes ("compute-01" to "compute-08") to achieve high performance.</t> <t>The user plane component can be distributed among the first 8 c ompute nodes ("compute-01" to "compute-08") to achieve high performance.</t>
</li> </li>
<li> <li>
<t>The control plane is deployed in a redundant fashion on two ins tances running on distinct compute nodes ("compute-09" and "compute-10").</t> <t>The control plane is deployed in a redundant fashion on two ins tances running on distinct compute nodes ("compute-09" and "compute-10").</t>
</li> </li>
<li> <li>
<t>The NF is attached to distinct networks, each making use of a d edicated VLAN. These VLANs are therefore instantiated as separate ACs. From a re alization standpoint, the NF interface connectivity is generally provided thanks to MacVLAN or Single Root I/O Virtualization (SR-IOV). For the sake of simplici ty only two VLANs are presented in this example, additional VLANs are configured following a similar logic.</t> <t>The NF is attached to distinct networks, each making use of a d edicated VLAN. These VLANs are therefore instantiated as separate ACs. From a re alization standpoint, the NF interface connectivity is generally provided thanks to MacVLAN or Single Root I/O Virtualization (SR-IOV). For the sake of simplici ty, only two VLANs are presented in this example; additional VLANs are configure d following a similar logic.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="physical-infrastructure"> <section anchor="physical-infrastructure">
<name>Physical Infrastructure</name> <name>Physical Infrastructure</name>
<t><xref target="cloud-parent-infra"/> describes the physical infrastr ucture. 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 multip le ways, such as IP Fabric, Layer 2/Layer 3 Edge Routers. This document does not intend to detail these aspects.</t> <t><xref target="cloud-parent-infra"/> describes the physical infrastr ucture. 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 multip le ways, such as IP Fabric and Layer 2/3 Edge Routers. This document does not in tend to detail these aspects.</t>
<figure anchor="cloud-parent-infra"> <figure anchor="cloud-parent-infra">
<name>Example Physical Topology for Cloud Deployment</name> <name>Example Physical Topology for Cloud Deployment</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="400" width="544" viewBox="0 0 544 400" class="diagram" text-anch or="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="400" width="544" viewBox="0 0 544 400" class="diagram" text-anch or="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,48 L 8,112" fill="none" stroke="black"/>
<path d="M 8,160 L 8,224" 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 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,48 L 112,112" fill="none" stroke="black"/>
<path d="M 112,160 L 112,224" 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 112,288 L 112,352" fill="none" stroke="black"/>
skipping to change at line 7731 skipping to change at line 7135
</figure> </figure>
</section> </section>
<section anchor="nfs-deployment"> <section anchor="nfs-deployment">
<name>NFs Deployment</name> <name>NFs Deployment</name>
<t>The NFs are deployed on this infrastructure in the following way:</ t> <t>The NFs are deployed on this infrastructure in the following way:</ t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Configuration of a parent AC as a centralized attachment for "v lan 100". The parent AC captures Layer 2 and Layer 3 properties for this VLAN: v lan-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 a ddition, the IP addresses of the user plane ("nf-up") instances are protected us ing BFD.</t> <t>Configuration of a parent AC as a centralized attachment for "v lan 100". The parent AC captures Layer 2 and Layer 3 properties for this VLAN: v lan-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 a ddition, the IP addresses of the user plane ("nf-up") instances are protected us ing BFD.</t>
</li> </li>
<li> <li>
<t>Configuration of a parent AC as a centralized attachment for "v lan 200". This vlan is for Layer 2 connectivity between NFs (no IP configuration in the provider network).</t> <t>Configuration of a parent AC as a centralized attachment for "v lan 200". This VLAN is for Layer 2 connectivity between NFs (no IP configuration in the provider network).</t>
</li> </li>
<li> <li>
<t>"Child ACs" binding bearers to parent ACs for "vlan 100" and "v lan 200".</t> <t>"Child ACs" binding bearers to parent ACs for "vlan 100" and "v lan 200".</t>
</li> </li>
<li> <li>
<t>The deployment of the network service to all compute nodes ("co mpute-01" to "compute-10"), even though the NF is not instantiated on "compute-0 7"/"compute-08". This approach permits handling compute failures and scale-out s cenarios in a reactive and flexible fashion thanks to a pre-provisioned networki ng logic.</t> <t>The deployment of the network service to all compute nodes ("co mpute-01" to "compute-10"), even though the NF is not instantiated on "compute-0 7"/"compute-08". This approach permits handling compute failures and scale-out s cenarios in a reactive and flexible fashion thanks to a pre-provisioned networki ng logic.</t>
</li> </li>
</ul> </ul>
<figure anchor="cloud-parent-logical"> <figure anchor="cloud-parent-logical">
<name>Logical Topology of the NFs Deployment</name> <name>Logical Topology of the NFs Deployment</name>
skipping to change at line 7973 skipping to change at line 7377
<text x="316" y="804">.253</text> <text x="316" y="804">.253</text>
<text x="52" y="820">nf-cp2</text> <text x="52" y="820">nf-cp2</text>
<text x="204" y="820">vlan-100</text> <text x="204" y="820">vlan-100</text>
<text x="204" y="836">vlan-200</text> <text x="204" y="836">vlan-200</text>
<text x="52" y="868">compute-10</text> <text x="52" y="868">compute-10</text>
<text x="40" y="900">nf-cp</text> <text x="40" y="900">nf-cp</text>
<text x="96" y="900">routing</text> <text x="96" y="900">routing</text>
<text x="144" y="900">for</text> <text x="144" y="900">for</text>
<text x="180" y="900">VLAN</text> <text x="180" y="900">VLAN</text>
<text x="216" y="900">100</text> <text x="216" y="900">100</text>
<text x="60" y="916">advertizes</text> <text x="60" y="916">advertises</text>
<text x="128" y="916">pools</text> <text x="128" y="916">pools</text>
<text x="172" y="916">with</text> <text x="172" y="916">with</text>
<text x="208" y="916">1:N</text> <text x="208" y="916">1:N</text>
<text x="252" y="916">backup</text> <text x="252" y="916">backup</text>
<text x="44" y="932">route.</text> <text x="44" y="932">route.</text>
<text x="32" y="948">BGP</text> <text x="32" y="948">BGP</text>
<text x="80" y="948">UPDATE:</text> <text x="80" y="948">UPDATE:</text>
<text x="80" y="964">203.0.113.0/24,</text> <text x="80" y="964">203.0.113.0/24,</text>
<text x="156" y="964">NH</text> <text x="156" y="964">NH</text>
<text x="176" y="964">=</text> <text x="176" y="964">=</text>
skipping to change at line 8061 skipping to change at line 7465
| '----' | | | | '----' | | |
compute-09 | | compute-09 | |
.----------. <-----------BGP------------->| | .----------. <-----------BGP------------->| |
| .----. |.10 .253 | | | .----. |.10 .253 | |
| |nf-cp2| |---------vlan-100-------------| | | |nf-cp2| |---------vlan-100-------------| |
| | | |---------vlan-200-------------| | | | | |---------vlan-200-------------| |
| '----' | '-----------------------' | '----' | '-----------------------'
compute-10 compute-10
.---------------------------------. .---------------------------------.
|nf-cp routing for VLAN 100 | |nf-cp routing for VLAN 100 |
|advertizes pools with 1:N backup | |advertises pools with 1:N backup |
|route. | |route. |
|BGP UPDATE: | |BGP UPDATE: |
|203.0.113.0/24, NH = 198.51.100.100| ----> |203.0.113.0/24, NH = 198.51.100.100| ---->
|203.0.113.0/28, NH = 192.0.2.1 | |203.0.113.0/28, NH = 192.0.2.1 |
|203.0.113.16/28, NH = 192.0.2.2 | |203.0.113.16/28, NH = 192.0.2.2 |
|... | |... |
|203.0.113.80/28, NH = 192.0.2.6 | |203.0.113.80/28, NH = 192.0.2.6 |
|203.0.113.96/28, NH = 192.0.2.7 | |203.0.113.96/28, NH = 192.0.2.7 |
'---------------------------------' '---------------------------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>For readability the payload is displayed as single JSON file (<xref <t>For readability, the payload is displayed as a single JSON file (<x
target="parent-profile"/>). In practice, several API calls may take place to in ref target="parent-profile"/>). In practice, several API calls may take place to
itialize these resources (e.g., GET requests from the customer to retrieve the I initialize these resources (e.g., GET requests from the customer to retrieve th
P address pools for NFs on "vlan 100" thanks to parent configuration and BGP con e IP address pools for NFs on "vlan 100" thanks to parent configuration and BGP
figuration, and POST extra routes for user planes and BFD).</t> configuration and POST extra routes for user planes and BFD).</t>
<t>Note that no individual IP addresses are assigned for the NF user p <t>Note that no individual IP addresses are assigned for the NF user p
lane instances (i.e., no 'customer-address' in the Child AC). The assignment of lane instances (i.e., no 'customer-address' in the Child AC). The assignment of
IP addresses to the NF endpoints is managed by the Cloud Infrastructure IPAM bas IP addresses to the NF endpoints is managed by the Cloud Infrastructure IP Addre
ed on the 'customer-address' IP address pool "192.0.2.1-200". Like in any conven ss Management (IPAM) based on the 'customer-address' IP address pool "192.0.2.1-
tional LAN-facing scenario, it is assumed that the actual binding of IP endpoint 200". Like in any conventional LAN-facing scenario, it is assumed that the actua
s to logical attachments (here Child ACs) relies on a dedicated protocol logic ( l binding of IP endpoints to logical attachments (here Child ACs) relies on a de
typically, Address Resolution Protocol (ARP) <xref target="RFC0826"/> or Neighbo dicated protocol logic (typically, Address Resolution Protocol (ARP) <xref targe
r Discovery <xref target="RFC4861"/>) and is not captured in the data model. Hen t="RFC0826"/> or Neighbor Discovery <xref target="RFC4861"/>) and is not capture
ce, the IP addresses displayed for NF user plane instances are simply examples t d in the data model. Hence, the IP addresses displayed for NF user plane instanc
o illustrate a realization approach. Note also that the Control Plane is defined es are simply examples to illustrate a realization approach. Note also that the
with static IP address assignments on a given AC/bearer to illustrate another d control plane is defined with static IP address assignments on a given AC/bearer
eployment alternative.</t> to illustrate another deployment alternative.</t>
<figure anchor="parent-profile"> <figure anchor="parent-profile">
<name>Message Body for the Configuration of the NF ACs</name> <name>Message Body for the Configuration of the NF ACs</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-ac-svc:specific-provisioning-profiles": { "ietf-ac-svc:specific-provisioning-profiles": {
"valid-provider-identifiers": { "valid-provider-identifiers": {
"failure-detection-profile-identifier": [ "failure-detection-profile-identifier": [
{ {
skipping to change at line 8357 skipping to change at line 7761
} }
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="nf-failure-and-scale-out"> <section anchor="nf-failure-and-scale-out">
<name>NF Failure and Scale-Out</name> <name>NF Failure and Scale-Out</name>
<t>Assuming a failure of "compute-01", the instance "nf-up-1" can be r edeployed to "compute-07" by the NF/Cloud Orchestration. The NFs can be scaled-o ut thanks to the creation of an extra instance "nf-up7" on "compute-08". Since c onnectivity is pre-provisioned, these operations happen without any API calls. I n other words, this redeployment is transparent from the perspective of the conf iguration of the provider network.</t> <t>Assuming a failure of "compute-01", the instance "nf-up-1" can be r edeployed to "compute-07" by the 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 co nfiguration of the provider network.</t>
<figure anchor="cloud-parent-nf-lcm"> <figure anchor="cloud-parent-nf-lcm">
<name>Example of Compute Failure and Scale-out</name> <name>Example of Compute Failure and Scale-Out</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="432" width="544" viewBox="0 0 544 432" class="diagram" text-anch or="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="432" width="544" viewBox="0 0 544 432" class="diagram" text-anch or="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,64 L 8,128" fill="none" stroke="black"/>
<path d="M 8,240 L 8,304" 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 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,272 L 24,288" fill="none" stroke="black"/>
<path d="M 24,368 L 24,384" 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 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,272 L 80,288" fill="none" stroke="black"/>
<path d="M 80,368 L 80,384" fill="none" stroke="black"/> <path d="M 80,368 L 80,384" fill="none" stroke="black"/>
skipping to change at line 8488 skipping to change at line 7892
compute-07 | | compute-07 | |
.----------. | nf-up7 on | .----------. | nf-up7 on |
| .----. |.7 < - BFD - > | compute-08 | | .----. |.7 < - BFD - > | compute-08 |
| |nf-up7| |---------vlan-100-------------| created for | | |nf-up7| |---------vlan-100-------------| created for |
| | | |---------vlan-200-------------| scale-out | | | | |---------vlan-200-------------| scale-out |
| '----' | | | | '----' | | |
compute-08 '-----------------------' compute-08 '-----------------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Finally, the addition or deletion of compute nodes in the deploymen <t>Finally, the addition or deletion of compute nodes in the deploymen
t ("compute-11", "compute-12", etc.) involves merely changes on Child ACs and po t ("compute-11", "compute-12", etc.) involves merely changes on Child ACs and po
ssible routing on the parent AC. In any case, the parent AC is a stable identifi ssible routing on the parent AC.
er, which can be consumed as a reference by end-to-end service models for VPN co
nfiguration such as <xref target="I-D.ietf-opsawg-ac-lxsm-lxnm-glue"/>, Slice Se <!--[rfced] To clarify the citation of I-D.ietf-opsawg-ac-lxsm-lxnm-glue
rvice <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/>, etc. This deco (RFC-to-be 9836), we have added "AC Glue" preceding it. Please review
upling to a stable identifier provides great benefits in terms of scalability an and let us know if further updates are needed.
d 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> 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 consume
d as a reference by end-to-end service models for VPN configuration such as AC G
lue <xref target="RFC9836"/>, Slice Service <xref target="I-D.ietf-teas-ietf-net
work-slice-nbi-yang"/>, etc. This decoupling to a stable identifier provides gre
at benefits in terms of scalability and flexibility since once the reference wit
h the parent AC is implemented, no API call involving the VPN model is needed fo
r any modification in the cloud.</t>
</section> </section>
</section> </section>
<section anchor="sec-bfd-static"> <section anchor="sec-bfd-static">
<name>BFD and Static Addressing</name> <name>BFD and Static Addressing</name>
<t><xref target="ex-bfd-static"/> shows a topology example of a set of C Es connected to a provider network via dedicated bearers. Each of these CE maint ains two BFD sessions with the provider network.</t> <t><xref target="ex-bfd-static"/> shows a topology example of a set of C Es connected to a provider network via dedicated bearers. Each of these CEs main tains two BFD sessions with the provider network.</t>
<figure anchor="ex-bfd-static"> <figure anchor="ex-bfd-static">
<name>Example of Static Addressing with BFD</name> <name>Example of Static Addressing with BFD</name>
<artset> <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"> <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,64 L 8,80" fill="none" stroke="black"/>
<path d="M 8,128 L 8,144" 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,224 L 8,240" fill="none" stroke="black"/>
<path d="M 8,336 L 8,352" 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,48 L 80,64" fill="none" stroke="black"/>
<path d="M 80,112 L 80,128" fill="none" stroke="black"/> <path d="M 80,112 L 80,128" fill="none" stroke="black"/>
skipping to change at line 8622 skipping to change at line 8046
| Provider Network | | Provider Network |
+----------------------------+ +----------------------------+
Each CE has a BFD session to each gateway for redundancy: Each CE has a BFD session to each gateway for redundancy:
.-------. .-------.
| CEx | .x <---BFD---> .252 | CEx | .x <---BFD---> .252
'-------' <---BFD---> .253 '-------' <---BFD---> .253
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t><xref target="ex-json-bfd-static"/> shows the message body of the ACa aS configuration to enable the target architecture shown in <xref target="ex-bfd -static"/>. This example uses an AC group profile to factorize common data betwe en all involved ACs. It also uses child ACs that inherit the properties of two p arent ACs; each terminating in a separate gateway in the provider network.</t> <t><xref target="ex-json-bfd-static"/> shows the message body of the ACa aS configuration to enable the target architecture shown in <xref target="ex-bfd -static"/>. This example uses an AC group profile to factorize common data betwe en all involved ACs. It also uses child ACs that inherit the properties of two p arent ACs, each terminating in a separate gateway in the provider network.</t>
<figure anchor="ex-json-bfd-static"> <figure anchor="ex-json-bfd-static">
<name>Message Body for the Configuration of CEs with Static Addressing and BFD Protection</name> <name>Message Body for the Configuration of CEs with Static Addressing and BFD Protection</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-ac-svc:specific-provisioning-profiles": { "ietf-ac-svc:specific-provisioning-profiles": {
"valid-provider-identifiers": { "valid-provider-identifiers": {
"failure-detection-profile-identifier": [ "failure-detection-profile-identifier": [
{ {
skipping to change at line 8753 skipping to change at line 8177
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="AC-svc-Tree"> <section anchor="AC-svc-Tree">
<name>Full Tree</name> <name>Full Tree</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-svc module: ietf-ac-svc
+--rw specific-provisioning-profiles +--rw specific-provisioning-profiles
| +--rw valid-provider-identifiers | +--rw valid-provider-identifiers
| +--rw encryption-profile-identifier* [id] | +--rw encryption-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw qos-profile-identifier* [id] | +--rw qos-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw failure-detection-profile-identifier* [id] | +--rw failure-detection-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw forwarding-profile-identifier* [id] | +--rw forwarding-profile-identifier* [id]
skipping to change at line 9572 skipping to change at line 8996
| +--rw pbs? uint64 | +--rw pbs? uint64
+--rw qos {vpn-common:qos}? +--rw qos {vpn-common:qos}?
| +--rw qos-profiles | +--rw qos-profiles
| +--rw qos-profile* [profile] | +--rw qos-profile* [profile]
| +--rw profile qos-profile-reference | +--rw profile qos-profile-reference
| +--rw direction? identityref | +--rw direction? identityref
+--rw access-control-list +--rw access-control-list
+--rw acl-profiles +--rw acl-profiles
+--rw acl-profile* [profile] +--rw acl-profile* [profile]
+--rw profile forwarding-profile-reference +--rw profile forwarding-profile-reference
]]></artwork> ]]></sourcecode>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>This document leverages <xref target="RFC9182"/> and <xref target="RFC9 <t>This document leverages <xref target="RFC9182"/> and <xref
291"/>. Thanks to Gyan Mishra for the review.</t> target="RFC9291"/>. Thanks to <contact fullname="Gyan Mishra"/> for the
<t>Thanks to Ebben Aries for the YANG Doctors review and for providing <xr review.</t>
ef target="Instance-Data"/>.</t> <t>Thanks to <contact fullname="Ebben Aries"/> for the YANG Doctors
<t>Thanks to Donald Eastlake for the careful rtg-dir reviews, Tero Kivinen review and for providing <xref target="Instance-Data"/>.</t>
for the sec-dir review, <t>Thanks to <contact fullname="Donald Eastlake"/> for the careful
Gyan Mishra for the genart review, and Adrian Farrel for the opsdir review.</t> RTGDIR review, <contact fullname="Tero Kivinen"/> for the SECDIR
<t>Thanks to Luis Miguel Contreras Murillo for the careful Shepherd review review, <contact fullname="Gyan Mishra"/> for the GENART review, and
.</t> <contact fullname="Adrian Farrel"/> for the OPSDIR review.</t>
<t>Thanks to Mahesh Jethanandani for the AD review.</t> <t>Thanks to <contact fullname="Luis Miguel Contreras Murillo"/> for the c
<t>Thanks to Éric Vyncke, Gunter Van de Velde, Erik Kline, and Paul Wouter areful shepherd review.</t>
s for the IESG review.</t> <t>Thanks to <contact fullname="Mahesh Jethanandani"/> for the AD review.<
/t>
<t>Thanks to <contact fullname="Éric Vyncke"/>, <contact
fullname="Gunter Van de Velde"/>, <contact fullname="Erik Kline"/>, and
<contact fullname="Paul Wouters"/> for the IESG review.</t>
</section> </section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse"> <section anchor="contributors" numbered="false" toc="include">
<name>Contributors</name> <name>Contributors</name>
<contact initials="V." surname="Lopez" fullname="Victor Lopez"> <contact initials="V." surname="Lopez" fullname="Victor Lopez">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>victor.lopez@nokia.com</email> <email>victor.lopez@nokia.com</email>
</address> </address>
</contact> </contact>
<contact initials="I." surname="Bykov" fullname="Ivan Bykov"> <contact initials="I." surname="Bykov" fullname="Ivan Bykov">
<organization>Ribbon Communications</organization> <organization>Ribbon Communications</organization>
<address> <address>
skipping to change at line 9618 skipping to change at line 9049
</address> </address>
</contact> </contact>
<contact initials="L. A." surname="Munoz" fullname="Luis Angel Munoz"> <contact initials="L. A." surname="Munoz" fullname="Luis Angel Munoz">
<organization>Vodafone</organization> <organization>Vodafone</organization>
<address> <address>
<email>luis-angel.munoz@vodafone.com</email> <email>luis-angel.munoz@vodafone.com</email>
</address> </address>
</contact> </contact>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+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> </rfc>
 End of changes. 283 change blocks. 
3023 lines changed or deleted 1090 lines changed or added

This html diff was produced by rfcdiff 1.48.