rfc9833.original.xml   rfc9833.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" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.3. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
6) --> -ietf-opsawg-teas-common-ac-15" number="9833" category="std" consensus="true" su
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft bmissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3"
-ietf-opsawg-teas-common-ac-15" category="std" consensus="true" submissionType=" xml:lang="en" updates="" obsoletes="">
IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.25.0 -->
<front> <front>
<title abbrev="Common Attachment Circuit YANG">A Common YANG Data Model for Attachment Circuits</title> <title abbrev="Common Attachment Circuit YANG">A Common YANG Data Model for Attachment Circuits</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-common-ac-15 <seriesInfo name="RFC" value="9833"/>
"/> <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>Operations and Management Area Working Group</workgroup> <workgroup>opsawg</workgroup>
<keyword>Slice Service</keyword> <keyword>Slice Service</keyword>
<keyword>L3VPN</keyword> <keyword>L3VPN</keyword>
<keyword>L2VPN</keyword> <keyword>L2VPN</keyword>
<keyword>Automation</keyword> <keyword>Automation</keyword>
<keyword>Network Automation</keyword> <keyword>Network Automation</keyword>
<keyword>Orchestration</keyword> <keyword>Orchestration</keyword>
<keyword>service delivery</keyword> <keyword>service delivery</keyword>
<keyword>Service provisioning</keyword> <keyword>Service provisioning</keyword>
<keyword>service segmentation</keyword> <keyword>service segmentation</keyword>
<keyword>service flexibility</keyword> <keyword>service flexibility</keyword>
<keyword>service simplification</keyword> <keyword>service simplification</keyword>
<keyword>Network Service</keyword> <keyword>Network Service</keyword>
<keyword>3GPP</keyword> <keyword>3GPP</keyword>
<keyword>Network Slicing</keyword> <keyword>Network Slicing</keyword>
<abstract>
<?line 106?>
<t>The document specifies a common attachment circuits (ACs) YANG model, which i <abstract>
s designed to be reusable by other models. This design is meant to ensure consis <t>The document specifies a common attachment circuits (ACs) YANG data model, wh
tent AC structures among models that manipulate ACs. For example, this common mo ich is designed to be reusable by other models. This design is meant to ensure c
del can be reused by service models to expose ACs as a service, service models t onsistent AC structures among models that manipulate ACs. For example, this comm
hat require binding a service to a set of ACs, network and device models to prov on model can be reused by service models to expose ACs as a service, service mod
ision ACs, etc.</t> els that require binding a service to a set of ACs, network and device models to
provision ACs, etc.</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 110?> <?line 110?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Connectivity services are provided by networks to customers via dedicat ed terminating points (e.g., Service Functions (SFs), Customer Premises Equipmen t (CPEs), Autonomous System Border Routers (ASBRs), data centers gateways, or In ternet Exchange Points). A connectivity service ensures data transfer from (or d estined to) a given terminating point to (or originate from) other terminating p oints. Objectives for such a connectivity service may be negotiated and agreed u pon between a customer and a network provider.</t> <t>Connectivity services are provided by networks to customers via dedicat ed terminating points (e.g., Service Functions (SFs), Customer Premises Equipmen t (CPE), Autonomous System Border Routers (ASBRs), data center gateways, or Inte rnet Exchange Points (IXPs)). A connectivity service ensures data transfer from (or destined to) a given terminating point to (or originating from) other termin ating points. Objectives for such a connectivity service may be negotiated and a greed upon between a customer and a network provider.</t>
<t>For that data transfer to take place within the provider network, it is assumed that adequate setup is provisioned over the links connecting the custom er's terminating <t>For that data transfer to take place within the provider network, it is assumed that adequate setup is provisioned over the links connecting the custom er's terminating
points to the provider network (typically, a Provider Edge (PE)), thereby points to the provider network (typically, a Provider Edge (PE)), thereby
enabling successful data exchange. This necessary provisioning is referred to enabling successful data exchange. This necessary provisioning is referred to
in this document as "attachment circuit" (AC), while the underlying link in this document as an "attachment circuit" (AC), while the underlying link
is referred to as the "bearer".</t> is referred to as the "bearer".</t>
<t>When a customer requests a new service, that service can be associated with existing <t>When a customer requests a new service, that service can be associated with existing
attachment circuits or may require the instantiation of new attachment circuits. attachment circuits or may require the instantiation of new attachment circuits.
Whether these attachment circuits are dedicated to a particular service or share d Whether these attachment circuits are dedicated to a particular service or share d
among multiple services depends on the specific deployment.</t> among multiple services depends on the specific deployment.</t>
<t>Examples of attachment circuits are depicted in <xref target="uc"/>. A Customer Edge (CE) <t>Examples of attachment circuits are depicted in <xref target="uc"/>. A Customer Edge (CE)
may be realized as a physical node or a logical entity. From the network's may be realized as a physical node or a logical entity. From the network's
perspective, a CE is treated as a peer Service Attachment Point (SAP) <xref targ et="RFC9408"/>. perspective, a CE is treated as a peer Service Attachment Point (SAP) <xref targ et="RFC9408"/>.
CEs can be dedicated to a single service (e.g., Layer 3 Virtual Private Network (VPN) CEs can be dedicated to a single service (e.g., Layer 3 Virtual Private Network (VPN)
or Layer 2 VPN) or can host multiple services (e.g., Service Functions <xref tar get="RFC7665"/>). or Layer 2 VPN) or can host multiple services (e.g., Service Functions <xref tar get="RFC7665"/>).
skipping to change at line 220 skipping to change at line 212
'------' | '--' (b3) '---+-' '------' | '--' (b3) '---+-'
| .--. | | | .--. | |
'----------+PE+------' | '----------+PE+------' |
'--' | '--' |
| | | |
'-----------AC----------' '-----------AC----------'
(bx) = bearer Id x (bx) = bearer Id x
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>This document specifies a common module ("ietf-ac-common") for attachme nt circuits (<xref target="sec-module"/>). The module is designed to be reusable by other models, thereby ensuring consistent AC structures among modules that manipulate ACs. For example, the common module can be reused by service models t o expose AC-as-a-Service (ACaaS) (e.g., <xref target="I-D.ietf-opsawg-teas-attac hment-circuit"/>) or by service models that require binding a service to a set o f ACs (e.g., Network Slice Service <xref target="I-D.ietf-teas-ietf-network-slic e-nbi-yang"/>)). It can also be used by network models to provision ACs (e.g., < xref target="I-D.ietf-opsawg-ntw-attachment-circuit"/>) and device models, among others.</t> <t>This document specifies a common module ("ietf-ac-common") for attachme nt circuits (<xref target="sec-module"/>). The module is designed to be reusable by other models, thereby ensuring consistent AC structures among modules that manipulate ACs. For example, the common module can be reused by service models t o expose AC-as-a-Service (ACaaS) (e.g., <xref target="RFC9834"/>) or by service models that require binding a service to a set of ACs (e.g., Network Slice Servi ce <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/>)). It can also be used by network models to provision ACs (e.g., <xref target="RFC9835"/>) and dev ice models, among others.</t>
<t>The common AC module eases data inheritance between modules (e.g., from service to network models as per <xref target="RFC8969"/>).</t> <t>The common AC module eases data inheritance between modules (e.g., from service to network models as per <xref target="RFC8969"/>).</t>
<t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t> <t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t>
<section anchor="editorial-note-to-be-removed-by-rfc-editor">
<name>Editorial Note (To be removed by RFC Editor)</name>
<t>Note to the RFC Editor: This section is to be removed prior to public
ation.</t>
<t>This document contains placeholder values that need to be replaced wi
th finalized values at the time of publication. This note summarizes all of the
substitutions that are needed.</t>
<t>Please apply the following replacements:</t>
<ul spacing="normal">
<li>
<t>XXXX --&gt; the assigned RFC number for this I-D</t>
</li>
<li>
<t>2025-01-07 --&gt; the actual date of the publication of this docu
ment</t>
</li>
</ul>
</section>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The meanings of the symbols in the YANG tree diagrams are defined in <x ref target="RFC8340"/>.</t> <t>The meanings of the symbols in the YANG tree diagrams are defined in <x ref target="RFC8340"/>.</t>
<t>LxSM refers to both the Layer 2 Service Model (L2SM) <xref target="RFC8 466"/> and the Layer 3 Service Model (L3SM) <xref target="RFC8299"/>.</t> <t>LxSM refers to both the Layer 2 Service Model (L2SM) <xref target="RFC8 466"/> and the Layer 3 Service Model (L3SM) <xref target="RFC8299"/>.</t>
<t>LxNM refers to both the Layer 2 Network Model (L2NM) <xref target="RFC9 291"/> and the Layer 3 Network Model (L3NM) <xref target="RFC9182"/>.</t> <t>LxNM refers to both the Layer 2 Network Model (L2NM) <xref target="RFC9 291"/> and the Layer 3 Network Model (L3NM) <xref target="RFC9182"/>.</t>
<t>This document uses the following term:</t> <t>This document uses the following term:</t>
<dl> <dl spacing="normal" newline="false">
<dt>Bearer:</dt> <dt>Bearer:</dt>
<dd> <dd>
<t>A physical or logical link that connects a CE (or site) to a provid er network.</t> <t>A physical or logical link that connects a CE (or site) to a provid er network.</t>
</dd> <t>A bearer can be a wireless or wired link. One or multiple
<dt/> technologies can be used to build a bearer. The bearer type can be
<dd> specified by a customer.</t>
<t>A bearer can be a wireless or wired link. One or multiple technolog <t>The operator allocates a unique bearer reference to identify a
ies can be used to build a bearer. The bearer type can be specified by a custome bearer within its network (e.g., customer line identifier). Such a
r.</t> reference can be retrieved by a customer and then used in subsequent
</dd> service placement requests to unambiguously identify where a service
<dt/> is to be bound.</t>
<dd> <t>The concept of bearer can be generalized to refer to the required
<t>The operator allocates a unique bearer reference to identify a bear underlying connection for the provisioning of an attachment
er within its network (e.g., customer line identifier). Such a reference can be circuit.</t>
retrieved by a customer and then used in subsequent service placement requests t <t>One or multiple attachment circuits may be hosted over the same
o unambiguously identify where a service is to be bound.</t> bearer (e.g., multiple Virtual Local Area Networks (VLANs) on the
</dd> same bearer that is provided by a physical link).</t>
<dt/>
<dd>
<t>The concept of bearer can be generalized to refer to the required u
nderlying connection for the provisioning of an attachment circuit.</t>
</dd>
<dt/>
<dd>
<t>One or multiple attachment circuits may be hosted over the same bea
rer (e.g., multiple Virtual Local Area Networks (VLANs) on the same bearer that
is provided by a physical link).</t>
</dd> </dd>
</dl> </dl>
<t>The names of data nodes are prefixed using the prefix associated with t he corresponding imported YANG module as shown in <xref target="pref"/>.</t> <t>The names of data nodes are prefixed using the prefix associated with t he corresponding imported YANG module as shown in <xref target="pref"/>.</t>
<table anchor="pref"> <table anchor="pref">
<name>Modules and Their Associated Prefixes</name> <name>Modules and Their Associated Prefixes</name>
<thead> <thead>
<tr> <tr>
<th align="left">Prefix</th> <th align="left">Prefix</th>
<th align="left">Module</th> <th align="left">Module</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
skipping to change at line 318 skipping to change at line 295
</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="sec-module"/>)</t> <t>"ietf-ac-common" (<xref target="sec-module"/>)</t>
</li> </li>
<li> <li>
<t>"ietf-bearer-svc" (<xref section="5.1" sectionFormat="of" target="I -D.ietf-opsawg-teas-attachment-circuit"/>)</t> <t>"ietf-bearer-svc" (<xref section="6.1" sectionFormat="of" target="R FC9834"/>)</t>
</li> </li>
<li> <li>
<t>"ietf-ac-svc" (<xref section="5.2" sectionFormat="of" target="I-D.i etf-opsawg-teas-attachment-circuit"/>)</t> <t>"ietf-ac-svc" (<xref section="6.2" sectionFormat="of" target="RFC98 34"/>)</t>
</li> </li>
<li> <li>
<t>"ietf-ac-ntw" (<xref target="I-D.ietf-opsawg-ntw-attachment-circuit "/>)</t> <t>"ietf-ac-ntw" <xref target="RFC9835"/></t>
</li> </li>
<li> <li>
<t>"ietf-ac-glue" (<xref target="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 404 skipping to change at line 381
To facilitate correlation between an AC service request and the actual AC provis ioned in the network, "ietf-ac-ntw" leverages the AC references exposed by the " ietf-ac-svc" module. To facilitate correlation between an AC service request and the actual AC provis ioned in the network, "ietf-ac-ntw" leverages the AC references exposed by the " ietf-ac-svc" module.
Furthermore, to bind Layer 2 VPN or Layer 3 VPN services with ACs, the "ietf-ac- glue" module augments the LxSM and LxNM with AC service references exposed by th e "ietf-ac-svc" module and AC network references exposed by the "ietf-ac-ntw" mo dule.</t> Furthermore, to bind Layer 2 VPN or Layer 3 VPN services with ACs, the "ietf-ac- glue" module augments the LxSM and LxNM with AC service references exposed by th e "ietf-ac-svc" module and AC network references exposed by the "ietf-ac-ntw" mo dule.</t>
</section> </section>
<section anchor="description-of-the-ac-common-yang-module"> <section anchor="description-of-the-ac-common-yang-module">
<name>Description of the AC Common YANG Module</name> <name>Description of the AC Common YANG Module</name>
<t>The full tree diagram of the module is provided in <xref target="AC-Com mon-Tree"/>. Subtrees are provided in the following subsections <t>The full tree diagram of the module is provided in <xref target="AC-Com mon-Tree"/>. Subtrees are provided in the following subsections
for the reader's convenience.</t> for the reader's convenience.</t>
<section anchor="features"> <section anchor="features">
<name>Features</name> <name>Features</name>
<t>The module defines the following features:</t> <t>The module defines the following features:</t>
<dl> <dl spacing="normal" newline="false">
<dt>'layer2-ac':</dt> <dt>'layer2-ac':</dt>
<dd> <dd>
<t>Used to indicate support of ACs with Layer 2 properties.</t> <t>Used to indicate support of ACs with Layer 2 properties.</t>
</dd> </dd>
<dt>'layer3-ac':</dt> <dt>'layer3-ac':</dt>
<dd> <dd>
<t>Used to indicate support of ACs with Layer 3 properties.</t> <t>Used to indicate support of ACs with Layer 3 properties.</t>
</dd> </dd>
<dt>'server-assigned-reference':</dt> <dt>'server-assigned-reference':</dt>
<dd> <dd>
<t>Used to indicate support of server-generated references to access
relevant resources. For example, a server can be a network controller or a rout <!--[rfced] To avoid back-to-back use of "For example", may we update
er in a provider network.</t> the second occurrence as follows?
</dd>
<dt/> Original:
<dd> For example, a
<t>For example, a bearer request is first created using a name which server can be a network controller or a router in a provider
is assigned by the client, but if this feature is supported, the request will a network.
lso include a server-generated reference. That reference can be used when reques
ting the creating of an AC over the existing bearer.</t> For example, a bearer request is first created using a name which
is assigned by the client, but if this feature is supported, the
request will also include a server-generated reference.
Perhaps:
For example, a
server can be a network controller or a router in a provider
network.
As another example, a bearer request is first created using a name that
is assigned by the client, but if this feature is supported, the
request will also include a server-generated reference.
-->
<t>Used to indicate support of server-generated references to
access relevant resources. For example, a server can be a network
controller or a router in a provider network.</t>
<t>For example, a bearer request is first created using a name
that is assigned by the client, but if this feature is supported,
the request will also include a server-generated reference. That
reference can be used when requesting the creation of an AC over
the existing bearer.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="identities"> <section anchor="identities">
<name>Identities</name> <name>Identities</name>
<t>The module defines a set of identities, including the following:</t> <t>The module defines a set of identities, including the following:</t>
<dl> <dl>
<dt>'address-allocation-type':</dt> <dt>'address-allocation-type':</dt>
<dd> <dd>
<t>Used to specify the IP address allocation type in an AC. For exam <t>Used to specify the IP address allocation type in an AC. For
ple, this identity is used to indicate whether the provider network provides DHC example, this identity is used to indicate whether the provider
P service, DHCP relay, or static addressing. Note that for the IPv6 case, Statel network provides DHCP service, DHCP relay, or static
ess Address Autoconfiguration (SLAAC) <xref target="RFC4862"/> can be used.</t> addressing. Note that for the IPv6 case, Stateless Address
Autoconfiguration (SLAAC) <xref target="RFC4862"/> can be
used.</t>
</dd> </dd>
<dt>'local-defined-next-hop':</dt> <dt>'local-defined-next-hop':</dt>
<dd> <dd>
<t>Used to specify next hop actions. For example, this identity can <t>Used to specify next-hop actions. For example, this identity
be used to indicate an action to discard traffic for a given destination or trea can be used to indicate an action to discard traffic for a given
t traffic towards addresses within the specified next-hop prefix as though they destination or treat traffic towards addresses within the
are connected to a local link.</t> specified next-hop prefix as though they are connected to a local
link.</t>
</dd> </dd>
<dt>'l2-tunnel-type':</dt> <dt>'l2-tunnel-type':</dt>
<dd> <dd>
<t>Used to control the Layer 2 tunnel selection for an AC. The curre <t>Used to control the Layer 2 tunnel selection for an AC. The
nt version supports indicating pseudowire, Virtual Private LAN Service (VPLS), a current version supports indicating pseudowire, Virtual Private
nd Virtual eXtensible Local Area Network (VXLAN).</t> LAN Service (VPLS), and Virtual eXtensible Local Area Network
(VXLAN).</t>
</dd> </dd>
<dt>'l3-tunnel-type':</dt> <dt>'l3-tunnel-type':</dt>
<dd> <dd>
<t>Used to control the Layer 3 tunnel selection for an AC. Examples <t>Used to control the Layer 3 tunnel selection for an
of such type are: IP-in-IP <xref target="RFC2003"/>, IPsec <xref target="RFC4301 AC. Examples of such type are: IP-in-IP <xref target="RFC2003"/>,
"/>, and Generic Routing Encapsulation (GRE) <xref target="RFC1701"/><xref targe IPsec <xref target="RFC4301"/>, and Generic Routing Encapsulation
t="RFC1702"/><xref target="RFC7676"/>.</t> (GRE) <xref target="RFC1701"/><xref target="RFC1702"/><xref
target="RFC7676"/>.</t>
</dd> </dd>
<dt>'precedence-type':</dt> <dt>'precedence-type':</dt>
<dd> <dd>
<t>Used to indicate the redundancy type when requesting ACs. For exa <t>Used to indicate the redundancy type when requesting ACs. For
mple, this identity can be used to tag primary and secondary ACs.</t> example, this identity can be used to tag primary and secondary
ACs.</t>
</dd> </dd>
<dt>'role':</dt> <dt>'role':</dt>
<dd> <dd>
<t>Used to indicate the type of an AC: User-to-Network Interface (UN <t>Used to indicate the type of an AC: User-to-Network Interface
I), Network-to-Network Interface (NNI), or public NNI.</t> (UNI), Network-to-Network Interface (NNI), or public NNI.</t>
</dd> <t>The reader may refer to <xref target="MEF6"/>, <xref
<dt/> target="MEF17"/>, <xref target="RFC6004"/>, or <xref
<dd> target="RFC6215"/> for examples of discussions regarding the use
<t>The reader may refer to <xref target="MEF6"/>, <xref target="MEF1 of UNI and NNI reference points.</t>
7"/>, <xref target="RFC6004"/>, or <xref target="RFC6215"/> for examples of disc
ussions regarding the use of UNI and NNI reference points.</t>
</dd> </dd>
<dt>New administrative status types:</dt> <dt>New administrative status types:</dt>
<dd> <dd>
<t>In addition to the status types already defined in <xref target=" <t>In addition to the status types already defined in <xref target="
RFC9181"/>, this document defines: RFC9181"/>, this document defines:</t>
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>'awaiting-validation' to report that a request is pending an <t>'awaiting-validation' to report that a request is pending
adiministrator approval.</t> an administrator approval.</t>
</li> </li>
<li> <li>
<t>'awaiting-processing' to report that a request was approved a <t>'awaiting-processing' to report that a request was approved
nd validated, but is awaiting more processing before activation.</t> and validated but is awaiting more processing before
activation.</t>
</li> </li>
<li> <li>
<t>'admin-prohibited' to report that a request cannot be handled <t>'admin-prohibited' to report that a request cannot be
because of administrative policies.</t> handled because of administrative policies.</t>
</li> </li>
<li> <li>
<t>'rejected' to report that a request was rejected reasons not <t>'rejected' to report that a request was rejected due to reaso
covered by the other status types.</t> ns
not covered by the other status types.</t>
</li> </li>
</ul> </ul>
</dd> </dd>
<dt>'bgp-role':</dt> <dt>'bgp-role':</dt>
<dd> <dd>
<t>Used to indicate BGP role when establishing a BGP session per <xr <t>Used to indicate the BGP role when establishing a BGP session per
ef target="RFC9234"/>.</t> <xref target="RFC9234"/>.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="reusable-groupings"> <section anchor="reusable-groupings">
<name>Reusable Groupings</name> <name>Reusable Groupings</name>
<t>The module also defines a set of reusable groupings, including the fo llowing:</t> <t>The module also defines a set of reusable groupings, including the fo llowing:</t>
<dl> <dl>
<dt>'service-status' (<xref target="op-full-tree"/>):</dt> <dt>'service-status' (<xref target="op-full-tree"/>):</dt>
<dd> <dd>
<t>Controls the administrative service status and reports the operat ional service status.</t> <t>Controls the administrative service status and reports the operat ional service status.</t>
</dd> </dd>
<dt>'ac-profile-cfg' (<xref target="op-full-tree"/>):</dt> <dt>'ac-profile-cfg' (<xref target="op-full-tree"/>):</dt>
<dd> <dd>
<t>A grouping with a set of valid provider profile identifiers. The <t>A grouping with a set of valid provider profile
following profiles are supported: identifiers. The following profiles are supported:</t>
</t>
<dl> <dl>
<dt>'encryption-profile-identifier':</dt> <dt>'encryption-profile-identifier':</dt>
<dd> <dd>
<t>Refers to a set of policies related <t>Refers to a set of policies related to the encryption setup
to the encryption setup that can be applied when provisioning an AC.</t> that 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 <t>Refers to a set of policies, such as classification,
classification, marking, and actions (e.g., <xref target="RFC3644"/>).</t> 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>
<t>Refers to a set of failure <t>Refers to a set of failure detection policies (e.g.,
detection policies (e.g., Bidirectional Forwarding Detection (BFD) policies <xre Bidirectional Forwarding Detection (BFD) policies <xref
f target="RFC5880"/>) that can be target="RFC5880"/>) that can be invoked when building an
invoked when building an AC.</t> AC.</t>
</dd> </dd>
<dt>'forwarding-profile-identifier':</dt> <dt>'forwarding-profile-identifier':</dt>
<dd> <dd>
<t>Refers to the policies that apply <t>Refers to the policies that apply to the forwarding of
to the forwarding of packets conveyed within an AC. Such policies packets conveyed within an AC. Such policies may consist, for
may consist, for example, of applying Access Control Lists (ACLs).</t> example, of applying Access 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 <t>Refers to a set of routing policies that will be invoked
that will be invoked (e.g., BGP policies) when building an AC.</t> (e.g., BGP policies) when building an AC.</t>
</dd> </dd>
</dl> </dl>
</dd> </dd>
<dt>'op-instructions' (<xref target="op-full-tree"/>):</dt> <dt>'op-instructions' (<xref target="op-full-tree"/>):</dt>
<dd> <dd>
<t>Defines a set of parameters to specify basic scheduling instructi ons and report related events for a service request (e.g., AC or bearer) ('servi ce-status'). Advanced scheduling groupings are defined in <xref target="I-D.ietf -netmod-schedule-yang"/>.</t> <t>Defines a set of parameters to specify basic scheduling instructi ons and report related events for a service request (e.g., AC or bearer) ('servi ce-status'). Advanced scheduling groupings are defined in <xref target="I-D.ietf -netmod-schedule-yang"/>.</t>
</dd>
</dl>
<figure anchor="op-full-tree"> <figure anchor="op-full-tree">
<name>Service Status, Profiles, and Operational Instructions Groupings </name> <name>Service Status, Profiles, and Operational Instructions Groupings </name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping service-status: grouping service-status:
+-- status +-- status
+-- admin-status +-- admin-status
| +-- status? identityref | +-- 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
grouping ac-profile-cfg: grouping ac-profile-cfg:
+-- valid-provider-identifiers +-- valid-provider-identifiers
skipping to change at line 555 skipping to change at line 583
| +-- id string | +-- id string
+-- forwarding-profile-identifier* [id] +-- forwarding-profile-identifier* [id]
| +-- id string | +-- id string
+-- routing-profile-identifier* [id] +-- routing-profile-identifier* [id]
+-- id string +-- id string
grouping op-instructions: grouping op-instructions:
+-- requested-start? yang:date-and-time +-- requested-start? yang:date-and-time
+-- requested-stop? yang:date-and-time +-- 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
]]></sourcecode>
]]></artwork>
</figure> </figure>
<dl> </dd>
<dt>Layer 2 encapsulations (<xref target="l2-full-tree"/>):</dt> <dt>Layer 2 encapsulations (<xref target="l2-full-tree"/>):</dt>
<dd> <dd>
<t>Groupings for the following encapsulation schemes are supported: <t>Groupings for the following encapsulation schemes are
dot1Q, QinQ, and priority-tagged.</t> supported: dot1Q, QinQ, and priority-tagged.</t>
</dd> </dd>
<dt>Layer 2 tunnel services (<xref target="l2-full-tree"/>):</dt> <dt>Layer 2 tunnel services (<xref target="l2-full-tree"/>):</dt>
<dd> <dd>
<t>These groupings are used to define Layer 2 tunnel services that m <t>These groupings are used to define Layer 2 tunnel services that
ay be needed for the activation of an AC. Examples of supported Layer 2 services may be needed for the activation of an AC. Examples of supported
are the pseudowire Layer 2 services are the pseudowire (<xref section="6.1"
(<xref section="6.1" sectionFormat="of" target="RFC8077"/>), VPLS, or VXLAN <xre sectionFormat="of" target="RFC8077"/>), VPLS, or VXLAN <xref
f target="RFC7348"/>.</t> target="RFC7348"/>.</t>
</dd>
</dl>
<figure anchor="l2-full-tree"> <figure anchor="l2-full-tree">
<name>Layer 2 Connection Groupings</name> <name>Layer 2 Connection Groupings</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping dot1q: grouping dot1q:
+-- tag-type? identityref +-- tag-type? identityref
+-- cvlan-id? uint16 +-- cvlan-id? uint16
grouping priority-tagged: grouping priority-tagged:
+-- tag-type? identityref +-- tag-type? identityref
grouping qinq: grouping qinq:
+-- tag-type? identityref +-- tag-type? identityref
+-- svlan-id? uint16 +-- svlan-id? uint16
+-- cvlan-id? uint16 +-- cvlan-id? uint16
grouping pseudowire: grouping pseudowire:
skipping to change at line 603 skipping to change at line 633
+-- pseudowire +-- pseudowire
| +-- vcid? uint32 | +-- vcid? uint32
| +-- far-end? union | +-- far-end? union
+-- vpls +-- vpls
| +-- vcid? uint32 | +-- vcid? uint32
| +-- far-end* union | +-- far-end* union
+-- vxlan +-- vxlan
+-- vni-id? uint32 +-- vni-id? uint32
+-- peer-mode? identityref +-- peer-mode? identityref
+-- peer-ip-address* inet:ip-address +-- peer-ip-address* inet:ip-address
]]></artwork> ]]></sourcecode>
</figure> </figure>
<dl> </dd>
<dt>Layer 3 address allocation (<xref target="l3-full-tree"/>):</dt> <dt>Layer 3 address allocation (<xref target="l3-full-tree"/>):</dt>
<dd> <dd>
<t>Defines both IPv4 and IPv6 groupings to specify IP address alloca <t>Defines both IPv4 and IPv6 groupings to specify IP address
tion over an AC. Both dynamic and static address schemes are supported.</t> allocation over an AC. Both dynamic and static address schemes are
</dd> supported.</t>
<dt/> <t>For both IPv4 and IPv6, 'address-allocation-type' is used to
<dd> indicate the IP address allocation mode to activate. When
<t>For both IPv4 and IPv6, 'address-allocation-type' is used to indi 'address-allocation-type' is set to 'provider-dhcp', DHCP
cate the IP address allocation mode to activate. When 'address-allocation-type' assignments can be made locally or by an external DHCP
is set to 'provider-dhcp', DHCP assignments can be made locally or by an externa server. Such behavior is controlled by setting
l DHCP server. Such behavior is controlled by setting 'dhcp-service-type'.</t> 'dhcp-service-type'.</t>
</dd> <t>Note that if 'address-allocation-type' is set to 'slaac', the
<dt/> Prefix Information option of Router Advertisements that will be
<dd> issued for SLAAC purposes will carry the IPv6 prefix that is
<t>Note that if 'address-allocation-type' is set to 'slaac', the Pre determined by 'local-address' and 'prefix-length'.</t>
fix Information option of Router Advertisements that will be issued for SLAAC pu
rposes will carry the IPv6 prefix that is determined by 'local-address' and 'pre
fix-length'.</t>
</dd> </dd>
<dt>IP connections (<xref target="l3-full-tree"/>):</dt> <dt>IP connections (<xref target="l3-full-tree"/>):</dt>
<dd> <dd>
<t>Defines IPv4 and IPv6 groupings for managing Layer 3 connectivity <t>Defines IPv4 and IPv6 groupings for managing Layer 3
over an AC. Both basic and more elaborated IP connection groupings are supporte connectivity over an AC. Both basic and more elaborated IP
d.</t> connection groupings are supported.</t>
</dd>
</dl>
<figure anchor="l3-full-tree"> <figure anchor="l3-full-tree">
<name>Layer 3 Connection Groupings</name> <name>Layer 3 Connection Groupings</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping ipv4-allocation-type: grouping ipv4-allocation-type:
+-- prefix-length? uint8 +-- prefix-length? uint8
+-- address-allocation-type? identityref +-- address-allocation-type? identityref
grouping ipv6-allocation-type: grouping ipv6-allocation-type:
+-- prefix-length? uint8 +-- prefix-length? uint8
+-- address-allocation-type? identityref +-- address-allocation-type? identityref
grouping ipv4-connection-basic: grouping ipv4-connection-basic:
+-- prefix-length? uint8 +-- prefix-length? uint8
+-- address-allocation-type? identityref +-- address-allocation-type? identityref
+-- (allocation-type)? +-- (allocation-type)?
+--:(dynamic) +--:(dynamic)
+-- (provider-dhcp)? +-- (provider-dhcp)?
| +--:(dhcp-service-type) | +--:(dhcp-service-type)
| +-- dhcp-service-type? enumeration | +-- dhcp-service-type? enumeration
+-- (dhcp-relay)? +-- (dhcp-relay)?
+--:(customer-dhcp-servers) +--:(customer-dhcp-servers)
+-- customer-dhcp-servers +-- customer-dhcp-servers
+-- server-ip-address* inet:ipv4-address +-- server-ip-address* inet:ipv4-address
grouping ipv6-connection-basic: grouping ipv6-connection-basic:
+-- prefix-length? uint8 +-- prefix-length? uint8
+-- address-allocation-type? identityref +-- address-allocation-type? identityref
+-- (allocation-type)? +-- (allocation-type)?
+--:(dynamic) +--:(dynamic)
+-- (provider-dhcp)? +-- (provider-dhcp)?
| +--:(dhcp-service-type) | +--:(dhcp-service-type)
| +-- dhcp-service-type? enumeration | +-- dhcp-service-type? enumeration
+-- (dhcp-relay)? +-- (dhcp-relay)?
+--:(customer-dhcp-servers) +--:(customer-dhcp-servers)
+-- customer-dhcp-servers +-- customer-dhcp-servers
+-- server-ip-address* inet:ipv6-address +-- server-ip-address* inet:ipv6-address
grouping ipv4-connection: grouping ipv4-connection:
+-- local-address? inet:ipv4-address +-- local-address? inet:ipv4-address
+-- virtual-address? inet:ipv4-address +-- virtual-address? inet:ipv4-address
+-- prefix-length? uint8 +-- prefix-length? uint8
+-- address-allocation-type? identityref +-- address-allocation-type? identityref
+-- (allocation-type)? +-- (allocation-type)?
+--:(dynamic) +--:(dynamic)
| +-- (address-assign)? | +-- (address-assign)?
| | +--:(number) | | +--:(number)
| | | +-- number-of-dynamic-address? uint16 | | | +-- number-of-dynamic-address? uint16
| | +--:(explicit) | | +--:(explicit)
| | +-- customer-addresses | | +-- customer-addresses
| | +-- address-pool* [pool-id] | | +-- address-pool* [pool-id]
| | +-- pool-id string | | +-- pool-id string
| | +-- start-address inet:ipv4-address | | +-- start-address inet:ipv4-address
| | +-- end-address? inet:ipv4-address | | +-- end-address? inet:ipv4-address
| +-- (provider-dhcp)? | +-- (provider-dhcp)?
| | +--:(dhcp-service-type) | | +--:(dhcp-service-type)
| | +-- dhcp-service-type? enumeration | | +-- dhcp-service-type? enumeration
| +-- (dhcp-relay)? | +-- (dhcp-relay)?
| +--:(customer-dhcp-servers) | +--:(customer-dhcp-servers)
| +-- customer-dhcp-servers | +-- customer-dhcp-servers
| +-- server-ip-address* inet:ipv4-address | +-- server-ip-address* inet:ipv4-address
+--:(static-addresses) +--:(static-addresses)
+-- address* [address-id] +-- address* [address-id]
+-- address-id string +-- address-id string
+-- customer-address? inet:ipv4-address +-- customer-address? inet:ipv4-address
grouping ipv6-connection: grouping ipv6-connection:
+-- local-address? inet:ipv6-address +-- local-address? inet:ipv6-address
+-- virtual-address? inet:ipv6-address +-- virtual-address? inet:ipv6-address
+-- prefix-length? uint8 +-- prefix-length? uint8
+-- address-allocation-type? identityref +-- address-allocation-type? identityref
+-- (allocation-type)? +-- (allocation-type)?
+--:(dynamic) +--:(dynamic)
| +-- (address-assign)? | +-- (address-assign)?
| | +--:(number) | | +--:(number)
| | | +-- number-of-dynamic-address? uint16 | | | +-- number-of-dynamic-address? uint16
| | +--:(explicit) | | +--:(explicit)
| | +-- customer-addresses | | +-- customer-addresses
| | +-- address-pool* [pool-id] | | +-- address-pool* [pool-id]
| | +-- pool-id string | | +-- pool-id string
| | +-- start-address inet:ipv6-address | | +-- start-address inet:ipv6-address
| | +-- end-address? inet:ipv6-address | | +-- end-address? inet:ipv6-address
| +-- (provider-dhcp)? | +-- (provider-dhcp)?
| | +--:(dhcp-service-type) | | +--:(dhcp-service-type)
| | +-- dhcp-service-type? enumeration | | +-- dhcp-service-type? enumeration
| +-- (dhcp-relay)? | +-- (dhcp-relay)?
| +--:(customer-dhcp-servers) | +--:(customer-dhcp-servers)
| +-- customer-dhcp-servers | +-- customer-dhcp-servers
| +-- server-ip-address* inet:ipv6-address | +-- server-ip-address* inet:ipv6-address
+--:(static-addresses) +--:(static-addresses)
+-- address* [address-id] +-- address* [address-id]
+-- address-id string +-- address-id string
+-- customer-address? inet:ipv6-address +-- customer-address? inet:ipv6-address
]]></artwork> ]]></sourcecode>
</figure> </figure>
<dl> </dd>
<dt>Routing parameters &amp; OAM (<xref target="rtg-full-tree"/>):</dt <dt>Routing parameters &amp; Operations, Administration, and Maintenan
> ce (OAM) (<xref target="rtg-full-tree"/>):</dt>
<dd>
<t>In addition to static routing, the module supports the following
routing protocols: BGP <xref target="RFC4271"/>, OSPF <xref target="RFC4577"/> o
r <xref target="RFC6565"/>, IS-IS <xref target="ISO10589"/><xref target="RFC1195
"/><xref target="RFC5308"/>, and RIP <xref target="RFC2453"/>. For all supported
routing protocols, 'address-family' indicates whether IPv4, IPv6, or both addre
ss families are to be activated. For example, this parameter is used to determin
e whether RIPv2 <xref target="RFC2453"/>, RIP Next Generation (RIPng), or both a
re to be enabled <xref target="RFC2080"/>. More details about supported routing
groupings are provided hereafter:
</t>
<ul spacing="normal">
<li>
<dl>
<dt>Authentication:</dt>
<dd>
<t>These groupings include the required information to manag
e the authentication of OSPF, IS-IS, BGP, and RIP. The groupings support local s
pecification of authentication keys and the associated authentication algorithm
to accomodate legacy implementations that do not support key chains <xref target
="RFC8177"/>.</t>
</dd>
<dt/>
<dd>
<t>Note that this version of the common AC model covers auth
entication options that are common to both OSPFv2 <xref target="RFC4577"/> and O
SPFv3 <xref target="RFC6565"/>; as such, the model does not support <xref target
="RFC4552"/>.</t>
</dd>
<dt/>
<dd>
<t>Similar to <xref target="RFC9182"/>, this version of the
common AC model assumes that parameters specific to the TCP-AO are preconfigured
as part of the key chain that is referenced in the model. No assumption is made
about how such a key chain is preconfigured. However, the structure of the key
chain should cover data nodes beyond those in <xref target="RFC8177"/>, mainly S
endID and RecvID (Section 3.1 of <xref target="RFC5925"/>).</t>
</dd>
</dl>
</li>
<li>
<t>BGP peer groups ('bgp-peer-group-without-name' and 'bgp-peer-
group-with-name'): Includes a set of parameters to identify a BGP peer group. Su
ch a group can be defined by providing a local AS Number (ASN), a customer's ASN
, and the address families to be activated for this group. BGP peer groups can b
e identified by a name ('bgp-peer-group-with-name').</t>
</li>
<li>
<t>Basic OSPF and IS-IS parameters ('ospf-basic' and 'isis-basic
'): These groupings include the minimal set of routing configuration that is req
uired for the activation of OSPF and IS-IS.</t>
</li>
<li>
<t>Static routing: Parameters to configure an entry or a list of
IP static routing entries.</t>
</li>
</ul>
</dd>
<dt/>
<dd> <dd>
<t>The 'redundancy-group' grouping lists the groups to which an AC b <t>In addition to static routing, the module supports the
elongs <xref target="RFC9181"/>. For example, the 'group-id' is used to associat following routing protocols: BGP <xref target="RFC4271"/>, OSPF
e redundancy or protection constraints of ACs.</t> <xref target="RFC4577"/> <xref target="RFC6565"/>, IS-IS <xref
</dd> target="ISO10589"/><xref target="RFC1195"/><xref
</dl> target="RFC5308"/>, and RIP <xref target="RFC2453"/>. For all
supported routing protocols, 'address-family' indicates whether
IPv4, IPv6, or both address families are to be activated. For
example, this parameter is used to determine whether RIPv2 <xref
target="RFC2453"/>, RIP Next Generation (RIPng), or both are to be
enabled <xref target="RFC2080"/>. More details about supported
routing groupings are provided hereafter:</t>
<dl spacing="normal" newline="false">
<dt>Authentication:</dt>
<dd>
<t>These groupings include the required information to manage
the authentication of OSPF, IS-IS, BGP, and RIP. The groupings
support local specification of authentication keys and the
associated authentication algorithm to accommodate legacy
implementations that do not support key chains <xref
target="RFC8177"/>.</t>
<t>Note that this version of the common AC model covers
authentication options that are common to both OSPFv2 <xref
target="RFC4577"/> and OSPFv3 <xref target="RFC6565"/>; as
such, the model does not support <xref target="RFC4552"/>.</t>
<t>Similar to <xref target="RFC9182"/>, this version of the
common AC model assumes that parameters specific to the TCP Auth
entication Option (TCP-AO)
are preconfigured as part of the key chain that is referenced
in the model. No assumption is made about how such a key chain
is preconfigured. However, the structure of the key chain
should cover data nodes beyond those in <xref
target="RFC8177"/>, mainly SendID and RecvID (<xref
target="RFC5925" sectionFormat="of" section="3.1"/>).</t>
</dd>
<dt>BGP peer groups ('bgp-peer-group-without-name' and 'bgp-peer-g
roup-with-name'):</dt>
<dd>Includes a set of parameters to identify a BGP peer
group. Such a group can be defined by providing a local Autonomous
System
Number (ASN), a customer's ASN, and the address families to be
activated for this group. BGP peer groups can be identified by a
name ('bgp-peer-group-with-name').</dd>
<dt>Basic OSPF and IS-IS parameters ('ospf-basic' and 'isis-basic'
):</dt>
<dd>These groupings include the minimal set of routing
configuration that is required for the activation of OSPF and
IS-IS.</dd>
<dt>Static routing:</dt>
<dd>Parameters to configure an entry or a list of IP static routing
entries.</dd>
</dl>
<t>The 'redundancy-group' grouping lists the groups to which an AC
belongs <xref target="RFC9181"/>. For example, the 'group-id' is
used to associate redundancy or protection constraints of ACs.</t>
<!--[rfxed] In Figure 6, is it intentional that the first item
(grouping bgp-authentication) is indented one space less than each of the
groupings that follow? In the original XML (and current XML), it's one space
for grouping bgp-authentication vs. two spaces for the others.
-->
<figure anchor="rtg-full-tree"> <figure anchor="rtg-full-tree">
<name>Routing &amp; OAM Groupings</name> <name>Routing &amp; OAM Groupings</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping bgp-authentication: grouping bgp-authentication:
+-- authentication +-- authentication
+-- enabled? boolean +-- enabled? boolean
+-- keying-material +-- keying-material
+-- (option)? +-- (option)?
+--:(ao) +--:(ao)
| +-- enable-ao? boolean | +-- enable-ao? boolean
| +-- ao-keychain? key-chain:key-chain-ref | +-- ao-keychain? key-chain:key-chain-ref
+--:(md5) +--:(md5)
| +-- md5-keychain? key-chain:key-chain-ref | +-- md5-keychain? key-chain:key-chain-ref
skipping to change at line 859 skipping to change at line 913
| +--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
grouping bfd: grouping bfd:
+-- holdtime? uint32 +-- holdtime? uint32
grouping redundancy-group: grouping redundancy-group:
+-- group* [group-id] +-- group* [group-id]
+-- group-id? string +-- group-id? string
+-- precedence? identityref +-- precedence? identityref
]]></artwork> ]]></sourcecode>
</figure> </figure>
<dl> </dd>
<dt>Bandwidth parameters (<xref target="bw-full-tree"/>):</dt> <dt>Bandwidth parameters (<xref target="bw-full-tree"/>):</dt>
<dd> <dd><t>Bandwidth parameters can be represented using the Committed
<t>Bandwidth parameters can be represented using the Committed Information Rate (CIR), the Excess Information Rate (EIR), or the Peak
Information Rate (CIR), the Excess Information Rate (EIR), or the Peak Information Rate (PIR).</t>
Information Rate (PIR).</t> <t>These parameters can be provided per bandwidth type. Type values are
</dd> taken from <xref target="RFC9181"/>. For example, the following values
<dt/> can be used:</t>
<dd> <dl spacing="normal" newline="false">
<t>These parameters can be provided per bandwidth type. Type values <dt>'bw-per-cos':</dt>
are <dd>The bandwidth is per Class of Service (CoS).</dd>
taken from <xref target="RFC9181"/>. For example, the following values can be us
ed:</t> <!--[rfced] To improve readability, may we update "to" to "for"?
<ul spacing="normal">
<li> Original:
<dl> * 'bw-per-site': The bandwidth is to all ACs that belong to the
<dt>'bw-per-cos':</dt> same site.
<dd>
<t>The bandwidth is per Class of Service (CoS).</t> Perhaps:
</dd> 'bw-per-site': The bandwidth is for all ACs that belong to the
</dl> same site.
</li> -->
<li>
<dl> <dt>'bw-per-site':</dt>
<dt>'bw-per-site':</dt> <dd>The bandwidth is to all ACs that belong to the same site.</dd>
<dd> </dl>
<t>The bandwidth is to all ACs that belong to the same site.
</t>
</dd>
</dl>
</li>
</ul>
</dd>
</dl>
<figure anchor="bw-full-tree"> <figure anchor="bw-full-tree">
<name>Bandwidth Groupings</name> <name>Bandwidth Groupings</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping bandwidth-parameters: grouping bandwidth-parameters:
+-- cir? uint64 +-- cir? uint64
+-- cbs? uint64 +-- cbs? uint64
+-- eir? uint64 +-- eir? uint64
+-- ebs? uint64 +-- ebs? uint64
+-- pir? uint64 +-- pir? uint64
+-- pbs? uint64 +-- pbs? uint64
grouping bandwidth-per-type: grouping bandwidth-per-type:
+-- bandwidth* [bw-type] +-- bandwidth* [bw-type]
+-- bw-type identityref +-- bw-type identityref
skipping to change at line 922 skipping to change at line 971
| +-- ebs? uint64 | +-- ebs? uint64
| +-- pir? uint64 | +-- pir? uint64
| +-- pbs? uint64 | +-- pbs? uint64
+--:(other) +--:(other)
+-- cir? uint64 +-- cir? uint64
+-- cbs? uint64 +-- cbs? uint64
+-- eir? uint64 +-- eir? uint64
+-- ebs? uint64 +-- ebs? uint64
+-- pir? uint64 +-- pir? uint64
+-- pbs? uint64 +-- pbs? uint64
]]></artwork> ]]></sourcecode>
</figure> </figure>
</dd>
</dl>
</section> </section>
</section> </section>
<section anchor="sec-module"> <section anchor="sec-module">
<name>Common Attachment Circuit YANG Module</name> <name>Common Attachment Circuit YANG Module</name>
<!-- [rfced] We note that the following reference is cited only in
the YANG module. In order to have a 1:1 matchup between the references
section and the text, may we add the following reference entry to
the Normative References and add it to the list of citations preceding
the YANG module?
Original:
This module uses types defined in [RFC6991], [RFC8177], and
[RFC9181].
Perhaps:
This module uses types defined in [RFC6991], [RFC8177],
[RFC9181], and [IEEE_802.1Q].
...
[IEEE_802.1Q]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks-Bridges and Bridged Networks", IEEE Std 802.1Q-
2022, DOI 10.1109/IEEESTD.2022.10004498, December 2022,
<https://doi.org/10.1109/IEEESTD.2022.10004498>.
-->
<!--[rfced] FYI, the YANG module has been updated per the
formatting option of pyang. Please let us know any concerns.
-->
<t>This module uses types defined in <xref target="RFC6991"/>, <xref targe t="RFC8177"/>, and <xref target="RFC9181"/>.</t> <t>This module uses types defined in <xref target="RFC6991"/>, <xref targe t="RFC8177"/>, and <xref target="RFC9181"/>.</t>
<sourcecode markers="true" name="ietf-ac-common@2025-01-07.yang"><![CDATA[ <sourcecode markers="true" name="ietf-ac-common@2025-08-11.yang" type="yan g"><![CDATA[
module ietf-ac-common { module ietf-ac-common {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ac-common"; namespace "urn:ietf:params:xml:ns:yang:ietf-ac-common";
prefix ac-common; prefix ac-common;
import ietf-vpn-common { import ietf-vpn-common {
prefix vpn-common; prefix vpn-common;
reference reference
"RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3
VPNs"; VPNs";
skipping to change at line 980 skipping to change at line 1058
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 common attachment circuit (AC) "This YANG module defines a common attachment circuit (AC)
YANG model with a set of reusable features, types, YANG module with a set of reusable features, types,
identities, and groupings. identities, and groupings.
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 9833; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2025-01-07 { revision 2025-08-11 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A Common YANG Data Model for Attachment Circuits"; "RFC 9833: A Common YANG Data Model for Attachment Circuits";
} }
/****************************Features************************/ /****************************Features************************/
feature layer2-ac { feature layer2-ac {
description description
"Indicates support of Layer 2 ACs."; "Indicates support of Layer 2 ACs.";
} }
feature layer3-ac { feature layer3-ac {
skipping to change at line 1088 skipping to change at line 1166
identity local-defined-next-hop { identity local-defined-next-hop {
description description
"Base identity of local defined next hops."; "Base identity of local defined next hops.";
} }
identity discard { identity discard {
base local-defined-next-hop; base local-defined-next-hop;
description description
"Indicates an action to discard traffic for the corresponding "Indicates an action to discard traffic for the corresponding
destination. For example, this can be used to black-hole destination. For example, this can be used to black-hole
traffic."; traffic.";
} }
identity local-link { identity local-link {
base local-defined-next-hop; base local-defined-next-hop;
description description
"Treat traffic towards addresses within the specified next-hop "Treat traffic towards addresses within the specified next-hop
prefix as though they are connected to a local link."; prefix as though they are connected to a local link.";
} }
skipping to change at line 1136 skipping to change at line 1214
// Layer 3 tunnel types // Layer 3 tunnel types
identity l3-tunnel-type { identity l3-tunnel-type {
description description
"Base identity for Layer 3 tunnel selection for an AC."; "Base identity for Layer 3 tunnel selection for an AC.";
} }
identity ip-in-ip { identity ip-in-ip {
base l3-tunnel-type; base l3-tunnel-type;
description description
"IP in IP Tunneling."; "IP-in-IP tunneling.";
reference reference
"RFC 2003: IP Encapsulation within IP"; "RFC 2003: IP Encapsulation within IP";
} }
identity ipsec { identity ipsec {
base l3-tunnel-type; base l3-tunnel-type;
description description
"IP Security (IPsec)."; "IP Security (IPsec).";
reference reference
"RFC 4301: Security Architecture for the Internet "RFC 4301: Security Architecture for the Internet
skipping to change at line 1165 skipping to change at line 1243
"RFC 1701: Generic Routing Encapsulation (GRE) "RFC 1701: Generic Routing Encapsulation (GRE)
RFC 1702: Generic Routing Encapsulation over IPv4 networks RFC 1702: Generic Routing Encapsulation over IPv4 networks
RFC 7676: IPv6 Support for Generic Routing Encapsulation RFC 7676: IPv6 Support for Generic Routing Encapsulation
(GRE)"; (GRE)";
} }
// Tagging precedence // Tagging precedence
identity precedence-type { identity precedence-type {
description description
"Redundancy type. Attachment to a network can be created "Redundancy type. Attachment to a network can be created
with primary and secondary tagging."; with primary and secondary tagging.";
} }
identity primary { identity primary {
base precedence-type; base precedence-type;
description description
"Identifies the main attachment circuit."; "Identifies the main attachment circuit.";
} }
identity secondary { identity secondary {
skipping to change at line 1190 skipping to change at line 1268
// AC type // AC type
identity role { identity role {
description description
"Base identity for the network role of an AC."; "Base identity for the network role of an AC.";
} }
identity uni { identity uni {
base role; base role;
description description
"User-to-Network Interface (UNI)."; "User-to-Network Interface (UNI).";
} }
identity nni { identity nni {
base role; base role;
description description
"Network-to-Network Interface (NNI)."; "Network-to-Network Interface (NNI).";
} }
identity public-nni { identity public-nni {
base role; base role;
description description
"Public peering. This is typically set using a shared "Public peering. This is typically set using a shared
network, such as an Internet Exchange Point (IXP)."; network, such as an Internet Exchange Point (IXP).";
} }
// More Admin status types // More Admin status types
identity awaiting-validation { identity awaiting-validation {
base vpn-common:administrative-status; base vpn-common:administrative-status;
description description
"This administrative status reflects that a request is "This administrative status reflects that a request is
pending an administrator approval."; pending an administrator approval.";
} }
identity awaiting-processing { identity awaiting-processing {
base vpn-common:administrative-status; base vpn-common:administrative-status;
description description
"This administrative status reflects that a request was "This administrative status reflects that a request was
approved and validated, but is awaiting more processing approved and validated but is awaiting more processing
before activation."; before activation.";
} }
identity admin-prohibited { identity admin-prohibited {
base vpn-common:administrative-status; base vpn-common:administrative-status;
description description
"This administrative status reflects that a request cannot "This administrative status reflects that a request cannot
be handled because of administrative policies."; be handled because of administrative policies.";
} }
skipping to change at line 1243 skipping to change at line 1321
description description
"This administrative status reflects that a request was "This administrative status reflects that a request was
rejected because, e.g., there are no sufficient resources rejected because, e.g., there are no sufficient resources
or other reasons not covered by the other status types."; or other reasons not covered by the other status types.";
} }
// BGP role // BGP role
identity bgp-role { identity bgp-role {
description description
"Used to indicate BGP role when establishing a BGP session."; "Used to indicate the BGP role when establishing a BGP
session.";
reference reference
"RFC 9234: Route Leak Prevention and Detection Using "RFC 9234: Route Leak Prevention and Detection Using
Roles in UPDATE and OPEN Messages, Section 4"; Roles in UPDATE and OPEN Messages, Section 4";
} }
identity provider { identity provider {
base bgp-role; base bgp-role;
description description
"The local AS is a transit provider of the remote AS."; "The local AS is a transit provider of the remote AS.";
} }
skipping to change at line 1270 skipping to change at line 1349
identity rs { identity rs {
base bgp-role; base bgp-role;
description description
"The local AS is a Route Server (RS)."; "The local AS is a Route Server (RS).";
} }
identity rs-client { identity rs-client {
base bgp-role; base bgp-role;
description description
"The local AS is a client of an RS and the RS is the "The local AS is a client of an RS, and the RS is the
remote AS."; remote AS.";
} }
identity peer { identity peer {
base bgp-role; base bgp-role;
description description
"The local and remote ASes have a peering relationship."; "The local and remote ASes have a peering relationship.";
} }
/****************************Typedefs************************/ /****************************Typedefs************************/
skipping to change at line 1557 skipping to change at line 1636
leaf vni-id { leaf vni-id {
type uint32; type uint32;
description description
"VXLAN Network Identifier (VNI)."; "VXLAN Network Identifier (VNI).";
} }
leaf peer-mode { leaf peer-mode {
type identityref { type identityref {
base vpn-common:vxlan-peer-mode; base vpn-common:vxlan-peer-mode;
} }
description description
"Specifies the VXLAN access mode. By default, the peer mode "Specifies the VXLAN access mode. By default, the peer mode
is set to 'static-mode'."; is set to 'static-mode'.";
} }
leaf-list peer-ip-address { leaf-list peer-ip-address {
type inet:ip-address; type inet:ip-address;
description description
"List of a peer's IP addresses."; "List of a peer's IP addresses.";
} }
} }
// Layer 2 Tunnel service // Layer 2 Tunnel service
skipping to change at line 1620 skipping to change at line 1699
// IPv4 allocation type // IPv4 allocation type
grouping ipv4-allocation-type { grouping ipv4-allocation-type {
description description
"IPv4-specific parameters."; "IPv4-specific parameters.";
leaf prefix-length { leaf prefix-length {
type uint8 { type uint8 {
range "0..32"; range "0..32";
} }
description description
"Subnet prefix length expressed in bits. It is applied to "Subnet prefix length expressed in bits. It is applied to
both local and customer addresses."; both local and customer addresses.";
} }
leaf address-allocation-type { leaf address-allocation-type {
type identityref { type identityref {
base address-allocation-type; base address-allocation-type;
} }
must "not(derived-from-or-self(current(), 'ac-common:slaac') " must "not(derived-from-or-self(current(), 'ac-common:slaac') "
+ "or derived-from-or-self(current(), " + "or derived-from-or-self(current(), "
+ "'ac-common:provider-dhcp-slaac'))" { + "'ac-common:provider-dhcp-slaac'))" {
error-message "SLAAC is only applicable to IPv6."; error-message "SLAAC is only applicable to IPv6.";
skipping to change at line 1648 skipping to change at line 1727
// IPv6 allocation type // IPv6 allocation type
grouping ipv6-allocation-type { grouping ipv6-allocation-type {
description description
"IPv6-specific parameters."; "IPv6-specific parameters.";
leaf prefix-length { leaf prefix-length {
type uint8 { type uint8 {
range "0..128"; range "0..128";
} }
description description
"Subnet prefix length expressed in bits. It is applied to "Subnet prefix length expressed in bits. It is applied to
both local and customer addresses."; both local and customer addresses.";
} }
leaf address-allocation-type { leaf address-allocation-type {
type identityref { type identityref {
base address-allocation-type; base address-allocation-type;
} }
description description
"Defines how IPv6 addresses are allocated to the peer "Defines how IPv6 addresses are allocated to the peer
termination points."; termination points.";
} }
skipping to change at line 1676 skipping to change at line 1755
uses ipv4-allocation-type; uses ipv4-allocation-type;
choice allocation-type { choice allocation-type {
description description
"Choice of the IPv4 address allocation."; "Choice of the IPv4 address allocation.";
case dynamic { case dynamic {
description description
"When the addresses are allocated by DHCP or other dynamic "When the addresses are allocated by DHCP or other dynamic
means local to the infrastructure."; means local to the infrastructure.";
choice provider-dhcp { choice provider-dhcp {
description description
"Parameters related to DHCP-allocated addresses. IP "Parameters related to DHCP-allocated addresses. IP
addresses are allocated by DHCP, that is provided by addresses are allocated by DHCP, which is provided by
the operator."; the operator.";
leaf dhcp-service-type { leaf dhcp-service-type {
type enumeration { type enumeration {
enum server { enum server {
description description
"Local DHCP server."; "Local DHCP server.";
} }
enum relay { enum relay {
description description
"Local DHCP relay. DHCP requests are relayed to "Local DHCP relay. DHCP requests are relayed to
a provider's server."; a provider's server.";
} }
} }
description description
"Indicates the type of DHCP service to be enabled on "Indicates the type of DHCP service to be enabled on
an AC."; an AC.";
} }
} }
choice dhcp-relay { choice dhcp-relay {
description description
skipping to change at line 1729 skipping to change at line 1808
choice allocation-type { choice allocation-type {
description description
"Choice of the IPv6 address allocation."; "Choice of the IPv6 address allocation.";
case dynamic { case dynamic {
description description
"When the addresses are allocated by DHCP or other dynamic "When the addresses are allocated by DHCP or other dynamic
means local to the infrastructure."; means local to the infrastructure.";
choice provider-dhcp { choice provider-dhcp {
description description
"Parameters related to DHCP-allocated addresses. "Parameters related to DHCP-allocated addresses.
IP addresses are allocated by DHCP, that is provided IP addresses are allocated by DHCP, which is provided
by the operator."; by the operator.";
leaf dhcp-service-type { leaf dhcp-service-type {
type enumeration { type enumeration {
enum server { enum server {
description description
"Local DHCP server."; "Local DHCP server.";
} }
enum relay { enum relay {
description description
"Local DHCP relay. DHCP requests are relayed to a "Local DHCP relay. DHCP requests are relayed to a
provider's server."; provider's server.";
} }
} }
description description
"Indicates the type of DHCP service to be enabled on "Indicates the type of DHCP service to be enabled on
the AC."; the AC.";
} }
} }
choice dhcp-relay { choice dhcp-relay {
description description
skipping to change at line 1839 skipping to change at line 1918
type inet:ipv4-address; type inet:ipv4-address;
description description
"Indicates the last address in the pool."; "Indicates the last address in the pool.";
} }
} }
} }
} }
} }
choice provider-dhcp { choice provider-dhcp {
description description
"Parameters related to DHCP-allocated addresses. IP "Parameters related to DHCP-allocated addresses. IP
addresses are allocated by DHCP, which is provided by addresses are allocated by DHCP, which is provided by
the operator."; the operator.";
leaf dhcp-service-type { leaf dhcp-service-type {
type enumeration { type enumeration {
enum server { enum server {
description description
"Local DHCP server."; "Local DHCP server.";
} }
enum relay { enum relay {
description description
"Local DHCP relay. DHCP requests are relayed to "Local DHCP relay. DHCP requests are relayed to
a provider's server."; a provider's server.";
} }
} }
description description
"Indicates the type of DHCP service to be enabled on "Indicates the type of DHCP service to be enabled on
this AC."; this AC.";
} }
} }
choice dhcp-relay { choice dhcp-relay {
description description
skipping to change at line 1880 skipping to change at line 1959
} }
} }
} }
case static-addresses { case static-addresses {
description description
"Lists the IPv4 addresses that are used."; "Lists the IPv4 addresses that are used.";
list address { list address {
key "address-id"; key "address-id";
ordered-by user; ordered-by user;
description description
"Lists the IPv4 addresses that are used. The first "Lists the IPv4 addresses that are used. The first
address of the list is the primary address of the address of the list is the primary address of the
connection."; connection.";
leaf address-id { leaf address-id {
type string; type string;
description description
"An identifier of the static IPv4 address."; "An identifier of the static IPv4 address.";
} }
leaf customer-address { leaf customer-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
skipping to change at line 1983 skipping to change at line 2062
IP addresses are allocated by DHCP, which is provided IP addresses are allocated by DHCP, which is provided
by the operator."; by the operator.";
leaf dhcp-service-type { leaf dhcp-service-type {
type enumeration { type enumeration {
enum server { enum server {
description description
"Local DHCP server."; "Local DHCP server.";
} }
enum relay { enum relay {
description description
"Local DHCP relay. DHCP requests are relayed "Local DHCP relay. DHCP requests are relayed
to a provider's server."; to a provider's server.";
} }
} }
description description
"Indicates the type of DHCP service to be enabled "Indicates the type of DHCP service to be enabled
on this access."; on this access.";
} }
} }
choice dhcp-relay { choice dhcp-relay {
description description
skipping to change at line 2013 skipping to change at line 2092
} }
} }
} }
case static-addresses { case static-addresses {
description description
"Lists the IPv6 addresses that are used by the customer."; "Lists the IPv6 addresses that are used by the customer.";
list address { list address {
key "address-id"; key "address-id";
ordered-by user; ordered-by user;
description description
"Lists the IPv6 addresses that are used. The first "Lists the IPv6 addresses that are used. The first
address of the list is the primary IP address of address of the list is the primary IP address of
the connection."; the connection.";
leaf address-id { leaf address-id {
type string; type string;
description description
"An identifier of the static IPv6 address."; "An identifier of the static IPv6 address.";
} }
leaf customer-address { leaf customer-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
skipping to change at line 2278 skipping to change at line 2357
} }
// Basic routing parameters // Basic routing parameters
grouping bgp-peer-group-without-name { grouping bgp-peer-group-without-name {
description description
"Identifies a BGP peer-group configured on the local system."; "Identifies a BGP peer-group configured on the local system.";
leaf local-as { leaf local-as {
type inet:as-number; type inet:as-number;
description description
"Indicates a local AS Number (ASN). This ASN is exposed to "Indicates a local Autonomous System Number (ASN). This ASN
a customer so that it knows which ASN to use to set up is exposed to a customer so that it knows which ASN to use
a BGP session."; to set up a BGP session.";
} }
leaf peer-as { leaf peer-as {
type inet:as-number; type inet:as-number;
description description
"Indicates the customer's ASN when the customer requests "Indicates the customer's ASN when the customer requests
BGP routing."; BGP routing.";
} }
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
skipping to change at line 2311 skipping to change at line 2390
description description
"Specifies the BGP role (provider, customer, peer, etc.)."; "Specifies the BGP role (provider, customer, peer, etc.).";
reference reference
"RFC 9234: Route Leak Prevention and Detection Using "RFC 9234: Route Leak Prevention and Detection Using
Roles in UPDATE and OPEN Messages, Section 4"; Roles in UPDATE and OPEN Messages, Section 4";
} }
} }
grouping bgp-peer-group-with-name { grouping bgp-peer-group-with-name {
description description
"Identifies a BGP peer-group configured on the local system - "Identifies a BGP peer-group configured on the local system,
identified by a peer-group name."; identified by a peer-group name.";
leaf name { leaf name {
type string; type string;
description description
"Specifies the name of the BGP peer-group."; "Specifies the name of the BGP peer-group.";
} }
uses bgp-peer-group-without-name; uses bgp-peer-group-without-name;
} }
grouping ospf-basic { grouping ospf-basic {
skipping to change at line 2346 skipping to change at line 2425
reference reference
"RFC 4577: OSPF as the Provider/Customer Edge Protocol "RFC 4577: OSPF as the Provider/Customer Edge Protocol
for BGP/MPLS IP Virtual Private Networks for BGP/MPLS IP Virtual Private Networks
(VPNs), Section 4.2.3 (VPNs), Section 4.2.3
RFC 6565: OSPFv3 as a Provider Edge to Customer Edge RFC 6565: OSPFv3 as a Provider Edge to Customer Edge
(PE-CE) Routing Protocol, Section 4.2"; (PE-CE) Routing Protocol, Section 4.2";
} }
leaf metric { leaf metric {
type uint16; type uint16;
description description
"Metric of the AC. It is used in the routing state "Metric of the AC. It is used in the routing state
calculation and path selection."; calculation and path selection.";
} }
} }
grouping isis-basic { grouping isis-basic {
description description
"Basic configuration specific to IS-IS."; "Basic configuration specific to IS-IS.";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
skipping to change at line 2453 skipping to change at line 2532
} }
} }
grouping ipv6-static-rtg { grouping ipv6-static-rtg {
description description
"A set of parameters specific to IPv6 static routing."; "A set of parameters specific to IPv6 static routing.";
list ipv6-lan-prefixes { list ipv6-lan-prefixes {
if-feature "vpn-common:ipv6"; if-feature "vpn-common:ipv6";
key "lan next-hop"; key "lan next-hop";
description description
"List of LAN prefixes for the customer terminating points."; "List of LAN prefixes for the customer-terminating points.";
uses ipv6-static-rtg-entry; uses ipv6-static-rtg-entry;
uses ac-common:service-status; uses ac-common:service-status;
} }
} }
// OAM // OAM
grouping bfd { grouping bfd {
description description
"Groups a set of basic BFD parameters."; "Groups a set of basic BFD parameters.";
skipping to change at line 2488 skipping to change at line 2567
Section 6.8.18"; Section 6.8.18";
} }
} }
// redundancy // redundancy
grouping redundancy-group { grouping redundancy-group {
description description
"A grouping for redundancy group."; "A grouping for redundancy group.";
list group { list group {
key "group-id"; key "group-id";
description description
"Specifies a list of group identifiers."; "Specifies a list of group identifiers.";
leaf group-id { leaf group-id {
type string; type string;
description description
"Indicates the group-id to which an AC belongs."; "Indicates the group-id to which an AC belongs.";
} }
leaf precedence { leaf precedence {
type identityref { type identityref {
base ac-common:precedence-type; base ac-common:precedence-type;
} }
description description
"Defines redundancy of an AC."; "Defines redundancy of an AC.";
} }
} }
} }
// QoS // QoS
grouping bandwidth-parameters { grouping bandwidth-parameters {
description description
"A grouping for bandwidth parameters."; "A grouping for bandwidth parameters.";
leaf cir { leaf cir {
type uint64; type uint64;
units "bps"; units "bps";
description description
"Committed Information Rate (CIR). The maximum number of bits "Committed Information Rate (CIR). The maximum number of
that a port can receive or send during one second over bits that a port can receive or send during one second over
an interface."; an interface.";
} }
leaf cbs { leaf cbs {
type uint64; type uint64;
units "bytes"; units "bytes";
description description
"Committed Burst Size (CBS). CBS controls the bursty nature "Committed Burst Size (CBS). CBS controls the bursty nature
of the traffic. Traffic that does not use the configured of the traffic. Traffic that does not use the configured
CIR accumulates credits until the credits reach the CIR accumulates credits until the credits reach the
configured CBS."; configured CBS.";
} }
leaf eir { leaf eir {
type uint64; type uint64;
units "bps"; units "bps";
description description
"Excess Information Rate (EIR), i.e., excess frame delivery "Excess Information Rate (EIR), i.e., excess frame delivery
allowed not subject to a Service Level Agreement (SLA). allowed not subject to a Service Level Agreement (SLA).
The traffic rate can be limited by EIR."; The traffic rate can be limited by EIR.";
} }
leaf ebs { leaf ebs {
type uint64; type uint64;
units "bytes"; units "bytes";
description description
"Excess Burst Size (EBS). The bandwidth available for burst "Excess Burst Size (EBS). The bandwidth available for burst
traffic from the EBS is subject to the amount of bandwidth traffic from the EBS is subject to the amount of bandwidth
that is accumulated during periods when traffic allocated that is accumulated during periods when traffic allocated
by the EIR policy is not used."; by the EIR policy is not used.";
} }
leaf pir { leaf pir {
type uint64; type uint64;
units "bps"; units "bps";
description description
"Peak Information Rate (PIR), i.e., maximum frame delivery "Peak Information Rate (PIR), i.e., maximum frame delivery
allowed. It is equal to or less than sum of CIR and EIR."; allowed. It is equal to or less than the sum of the CIR and
EIR.";
} }
leaf pbs { leaf pbs {
type uint64; type uint64;
units "bytes"; units "bytes";
description description
"Peak Burst Size (PBS)."; "Peak Burst Size (PBS).";
} }
} }
grouping bandwidth-per-type { grouping bandwidth-per-type {
skipping to change at line 2609 skipping to change at line 2689
uses bandwidth-parameters; uses bandwidth-parameters;
} }
} }
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<!--[rfced] *AD - We note that there is some text in the
Security Considerations that differs from the template on
<https://wiki.ietf.org/group/ops/yang-security-guidelines>. Please
review and let us know if the text is acceptable. Specifically:
- Paragraph 5 matches the template except for the last sentence
is an addition. Paragraph 6 does not seem to correspond to the template.
- This sentence is not present, although the template says to include it.
"There are no particularly sensitive RPC or action operations."
If it should be added, should it be at the end of the section?
-->
<t>This section is modeled after the template described in <xref section=" 3.7" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t> <t>This section is modeled after the template described in <xref section=" 3.7" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t>
<t>The "ietf-ac-common" YANG module defines a data model that is <t>The "ietf-ac-common" YANG module defines a data model that is
designed to be accessed via YANG-based management protocols, such as designed to be accessed via YANG-based management protocols, such as
NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These pr otocols have to NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These pr otocols have to
use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref targ et="RFC8446"/>, and use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref targ et="RFC8446"/>, and
QUIC <xref target="RFC9000"/>) and have to use mutual authentication.</t> QUIC <xref target="RFC9000"/>) and have to use mutual authentication.</t>
<t>The Network Configuration Access Control Model (NACM) <xref target="RFC 8341"/> <t>The Network Configuration Access Control Model (NACM) <xref target="RFC 8341"/>
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.</t> RESTCONF protocol operations and content.</t>
skipping to change at line 2643 skipping to change at line 2737
will inherit the security considerations discussed in will inherit the security considerations discussed in
<xref section="5" sectionFormat="of" target="RFC8177"/>. Also, these groupin gs support supplying explicit keys as <xref section="5" sectionFormat="of" target="RFC8177"/>. Also, these groupin gs support supplying explicit keys as
strings in ASCII format. The use of keys in hexadecimal string strings in ASCII format. The use of keys in hexadecimal string
format would afford greater key entropy with the same number of format would afford greater key entropy with the same number of
key-string octets. However, such a format is not included in this key-string octets. However, such a format is not included in this
version of the common AC model, because it is not supported by the underlying version of the common AC model, because it is not supported by the underlying
device modules (e.g., <xref target="RFC8695"/>).</t> device modules (e.g., <xref target="RFC8695"/>).</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to register the following URI in the "ns" subregistry within <t>IANA has registered the following URI in the "ns" subregistry within
the "IETF XML Registry" <xref target="RFC3688"/>:</t> the "IETF XML Registry" <xref target="RFC3688"/>:</t>
<artwork><![CDATA[ <dl spacing="compact" newline="false">
URI: urn:ietf:params:xml:ns:yang:ietf-ac-common <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-common</dd>
Registrant Contact: The IESG. <dt>Registrant Contact:</dt><dd>The IESG.</dd>
XML: N/A; the requested URI is an XML namespace. <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
]]></artwork> </dl>
<t>IANA is requested to register the following YANG module in the "YANG Mo <t>IANA has registered the following YANG module in the "YANG Module
dule
Names" subregistry <xref target="RFC6020"/> within the "YANG Parameters" regi stry:</t> Names" subregistry <xref target="RFC6020"/> within the "YANG Parameters" regi stry:</t>
<artwork><![CDATA[ <dl spacing="compact" newline="false">
Name: ietf-ac-common <dt>Name:</dt><dd>ietf-ac-common</dd>
Namespace: urn:ietf:params:xml:ns:yang:ietf-ac-common <dt>Maintained by IANA?</dt><dd>N</dd>
Prefix: ac-common <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-common</dd>
Maintained by IANA? N <dt>Prefix:</dt><dd>ac-common</dd>
Reference: RFC XXXX <dt>Reference:</dt><dd>RFC 9833</dd>
]]></artwork> </dl>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-netmod-rfc8407bis" to="YANG-GUIDELINES"/>
<displayreference target="I-D.ietf-teas-ietf-network-slice-nbi-yang" to="YAN
G-NSS"/>
<displayreference target="I-D.ietf-netmod-schedule-yang" to="YANG-SCHEDULE"/
>
<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="ISO10589" target="https://www.iso.org/standard/30932. html"> <reference anchor="ISO10589" target="https://www.iso.org/standard/30932. html">
<front> <front>
<title>Information technology - Telecommunications and information e xchange between systems - Intermediate System to Intermediate System intra-domai n routeing information exchange protocol for use in conjunction with the protoco l for providing the connectionless-mode network service (ISO8473)</title> <title>Information technology - Telecommunications and information e xchange between systems - Intermediate System to Intermediate System intra-domai n routeing information exchange protocol for use in conjunction with the protoco l for providing the connectionless-mode network service (ISO8473)</title>
<author> <author>
<organization>ISO</organization> <organization>ISO/IEC</organization>
</author> </author>
<date year="2002"/> <date year="2002" month="November"/>
</front>
</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="RFC6991">
<front>
<title>Common YANG Data Types</title>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
ame="Schoenwaelder"/>
<date month="July" year="2013"/>
<abstract>
<t>This document introduces a collection of common data types to b
e used with the YANG data modeling language. This document obsoletes RFC 6021.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="6991"/>
<seriesInfo name="DOI" value="10.17487/RFC6991"/>
</reference>
<reference anchor="RFC8177">
<front>
<title>YANG Data Model for Key Chains</title>
<author fullname="A. Lindem" initials="A." role="editor" surname="Li
ndem"/>
<author fullname="Y. Qu" initials="Y." surname="Qu"/>
<author fullname="D. Yeung" initials="D." surname="Yeung"/>
<author fullname="I. Chen" initials="I." surname="Chen"/>
<author fullname="J. Zhang" initials="J." surname="Zhang"/>
<date month="June" year="2017"/>
<abstract>
<t>This document describes the key chain YANG data model. Key chai
ns are commonly used for routing protocol authentication and other applications
requiring symmetric keys. A key chain is a list containing one or more elements
containing a Key ID, key string, send/accept lifetimes, and the associated authe
ntication or encryption algorithm. By properly overlapping the send and accept l
ifetimes of multiple key chain elements, key strings and algorithms may be grace
fully updated. By representing them in a YANG data model, key distribution can b
e automated.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8177"/>
<seriesInfo name="DOI" value="10.17487/RFC8177"/>
</reference>
<reference anchor="RFC8341">
<front>
<title>Network Configuration Access Control Model</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<date month="March" year="2018"/>
<abstract>
<t>The standardization of network configuration interfaces for use
with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requ
ires a structured and secure operating environment that promotes human usability
and multi-vendor interoperability. There is a need for standard mechanisms to r
estrict NETCONF or RESTCONF protocol access for particular users to a preconfigu
red subset of all available NETCONF or RESTCONF protocol operations and content.
This document defines such an access control model.</t>
<t>This document obsoletes RFC 6536.</t>
</abstract>
</front>
<seriesInfo name="STD" value="91"/>
<seriesInfo name="RFC" value="8341"/>
<seriesInfo name="DOI" value="10.17487/RFC8341"/>
</reference>
<reference anchor="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="RFC8077">
<front>
<title>Pseudowire Setup and Maintenance Using the Label Distribution
Protocol (LDP)</title>
<author fullname="L. Martini" initials="L." role="editor" surname="M
artini"/>
<author fullname="G. Heron" initials="G." role="editor" surname="Her
on"/>
<date month="February" year="2017"/>
<abstract>
<t>Layer 2 services (such as Frame Relay, Asynchronous Transfer Mo
de, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Lay
er 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs
). It is also possible to use pseudowires to provide low-rate Time-Division Mult
iplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enable
d network. This document specifies a protocol for establishing and maintaining t
he pseudowires, using extensions to the Label Distribution Protocol (LDP). Proce
dures for encapsulating Layer 2 PDUs are specified in other documents.</t>
<t>This document is a rewrite of RFC 4447 for publication as an In
ternet Standard.</t>
</abstract>
</front>
<seriesInfo name="STD" value="84"/>
<seriesInfo name="RFC" value="8077"/>
<seriesInfo name="DOI" value="10.17487/RFC8077"/>
</reference>
<reference anchor="RFC7348">
<front>
<title>Virtual eXtensible Local Area Network (VXLAN): A Framework fo
r Overlaying Virtualized Layer 2 Networks over Layer 3 Networks</title>
<author fullname="M. Mahalingam" initials="M." surname="Mahalingam"/
>
<author fullname="D. Dutt" initials="D." surname="Dutt"/>
<author fullname="K. Duda" initials="K." surname="Duda"/>
<author fullname="P. Agarwal" initials="P." surname="Agarwal"/>
<author fullname="L. Kreeger" initials="L." surname="Kreeger"/>
<author fullname="T. Sridhar" initials="T." surname="Sridhar"/>
<author fullname="M. Bursell" initials="M." surname="Bursell"/>
<author fullname="C. Wright" initials="C." surname="Wright"/>
<date month="August" year="2014"/>
<abstract>
<t>This document describes Virtual eXtensible Local Area Network (
VXLAN), which is used to address the need for overlay networks within virtualize
d data centers accommodating multiple tenants. The scheme and the related protoc
ols can be used in networks for cloud service providers and enterprise data cent
ers. This memo documents the deployed VXLAN protocol for the benefit of the Inte
rnet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7348"/>
<seriesInfo name="DOI" value="10.17487/RFC7348"/>
</reference>
<reference anchor="RFC4271">
<front>
<title>A Border Gateway Protocol 4 (BGP-4)</title>
<author fullname="Y. Rekhter" initials="Y." role="editor" surname="R
ekhter"/>
<author fullname="T. Li" initials="T." role="editor" surname="Li"/>
<author fullname="S. Hares" initials="S." role="editor" surname="Har
es"/>
<date month="January" year="2006"/>
<abstract>
<t>This document discusses the Border Gateway Protocol (BGP), whic
h is an inter-Autonomous System routing protocol.</t>
<t>The primary function of a BGP speaking system is to exchange ne
twork reachability information with other BGP systems. This network reachability
information includes information on the list of Autonomous Systems (ASes) that
reachability information traverses. This information is sufficient for construct
ing a graph of AS connectivity for this reachability from which routing loops ma
y be pruned, and, at the AS level, some policy decisions may be enforced.</t>
<t>BGP-4 provides a set of mechanisms for supporting Classless Int
er-Domain Routing (CIDR). These mechanisms include support for advertising a set
of destinations as an IP prefix, and eliminating the concept of network "class"
within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes,
including aggregation of AS paths.</t>
<t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4271"/>
<seriesInfo name="DOI" value="10.17487/RFC4271"/>
</reference>
<reference anchor="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="RFC1195">
<front>
<title>Use of OSI IS-IS for routing in TCP/IP and dual environments<
/title>
<author fullname="R. Callon" initials="R." surname="Callon"/>
<date month="December" year="1990"/>
<abstract>
<t>This memo specifies an integrated routing protocol, based on th
e OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gate
way protocol (IGP) to support TCP/IP as well as OSI. This allows a single routin
g protocol to be used to support pure IP environments, pure OSI environments, an
d dual environments. This specification was developed by the IS-IS working group
of the Internet Engineering Task Force. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1195"/>
<seriesInfo name="DOI" value="10.17487/RFC1195"/>
</reference>
<reference anchor="RFC5308">
<front>
<title>Routing IPv6 with IS-IS</title>
<author fullname="C. Hopps" initials="C." surname="Hopps"/>
<date month="October" year="2008"/>
<abstract>
<t>This document specifies a method for exchanging IPv6 routing in
formation using the IS-IS routing protocol. The described method utilizes two ne
w TLVs: a reachability TLV and an interface address TLV to distribute the necess
ary IPv6 information throughout a routing domain. Using this method, one can rou
te IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. [S
TANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5308"/>
<seriesInfo name="DOI" value="10.17487/RFC5308"/>
</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="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="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> </front>
<seriesInfo name="RFC" value="6020"/> <seriesInfo name="ISO/IEC" value="10589:2002"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
41.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
040.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
342.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
991.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
177.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
181.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
077.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
348.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
577.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
565.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
195.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
308.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"/>
<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.3
688.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
020.xml"/>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="MEF6" target="https://www.mef.net/Assets/Technical_Sp ecifications/PDF/MEF_6.pdf"> <reference anchor="MEF6" target="https://www.mef.net/Assets/Technical_Sp ecifications/PDF/MEF_6.pdf">
<front> <front>
<title>Technical Specification MEF 6, Ethernet Services Definitions - Phase I</title> <title>Ethernet Services Definitions - Phase I</title>
<author> <author>
<organization>The Metro Ethernet Forum</organization> <organization>The Metro Ethernet Forum</organization>
</author> </author>
<date year="2004" month="June"/> <date year="2004" month="August"/>
</front> </front>
<seriesInfo name="MEF" value="6"/>
<refcontent>MEF Technical Specification</refcontent>
</reference> </reference>
<reference anchor="MEF17" target="https://www.mef.net/wp-content/uploads /2015/04/MEF-17.pdf"> <reference anchor="MEF17" target="https://www.mef.net/wp-content/uploads /2015/04/MEF-17.pdf">
<front> <front>
<title>Technical Specification MEF 17, Service OAM Requirements &amp ; Framework - Phase 1</title> <title>Service OAM Requirements &amp; Framework - Phase 1</title>
<author> <author>
<organization>The Metro Ethernet Forum</organization> <organization>The Metro Ethernet Forum</organization>
</author> </author>
<date year="2007" month="April"/> <date year="2007" month="April"/>
</front> </front>
<seriesInfo name="MEF" value="17"/>
<refcontent>MEF Technical Specification</refcontent>
</reference> </reference>
<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.7
)</title> 665.xml"/>
<author fullname="M. Boucadair" initials="M." role="editor" surname= <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
"Boucadair"/> 364.xml"/>
<author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzal
ez de Dios"/>
<author fullname="S. Barguil" initials="S." surname="Barguil"/>
<author fullname="Q. Wu" initials="Q." surname="Wu"/>
<author fullname="V. Lopez" initials="V." surname="Lopez"/>
<date month="June" year="2023"/>
<abstract>
<t>This document defines a YANG data model for representing an abs
tract view of the provider network topology that contains the points from which
its services can be attached (e.g., basic connectivity, VPN, network slices). Al
so, the model can be used to retrieve the points where the services are actually
being delivered to customers (including peer networks).</t>
<t>This document augments the 'ietf-network' data model defined in
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="RFC7665">
<front>
<title>Service Function Chaining (SFC) Architecture</title>
<author fullname="J. Halpern" initials="J." role="editor" surname="H
alpern"/>
<author fullname="C. Pignataro" initials="C." role="editor" surname=
"Pignataro"/>
<date month="October" year="2015"/>
<abstract>
<t>This document describes an architecture for the specification,
creation, and ongoing maintenance of Service Function Chains (SFCs) in a network
. It includes architectural concepts, principles, and components used in the con
struction of composite services through deployment of SFCs, with a focus on thos
e to be standardized in the IETF. This document does not propose solutions, prot
ocols, or extensions to existing protocols.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7665"/>
<seriesInfo name="DOI" value="10.17487/RFC7665"/>
</reference>
<reference anchor="RFC4364">
<front>
<title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
<author fullname="E. Rosen" initials="E." surname="Rosen"/>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<date month="February" year="2006"/>
<abstract>
<t>This document describes a method by which a Service Provider ma
y use an IP backbone to provide IP Virtual Private Networks (VPNs) for its custo
mers. This method uses a "peer model", in which the customers' edge routers (CE
routers) send their routes to the Service Provider's edge routers (PE routers);
there is no "overlay" visible to the customer's routing algorithm, and CE router
s at different sites do not peer with each other. Data packets are tunneled thro
ugh the backbone, so that the core routers do not need to know the VPN routes. [
STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4364"/>
<seriesInfo name="DOI" value="10.17487/RFC4364"/>
</reference>
<reference anchor="I-D.ietf-opsawg-teas-attachment-circuit">
<front>
<title>YANG Data Models for Bearers and 'Attachment Circuits'-as-a-S
ervice (ACaaS)</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Richard Roberts" initials="R." surname="Roberts">
<organization>Juniper</organization>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O. G." surname="
de Dios">
<organization>Telefonica</organization>
</author>
<author fullname="Samier Barguil" initials="S." surname="Barguil">
<organization>Nokia</organization>
</author>
<author fullname="Bo Wu" initials="B." surname="Wu">
<organization>Huawei Technologies</organization>
</author>
<date day="9" month="January" year="2025"/>
<abstract>
<t> Delivery of network services assumes that appropriate setup
is
provisioned over the links that connect customer termination points
and a provider network. The required setup to allow successful data
exchange over these links is referred to as an attachment circuit
(AC), while the underlying link is referred to as "bearer".
This document specifies a YANG service data model for ACs. This <!-- [RFC9834]
model can be used for the provisioning of ACs before or during draft-ietf-opsawg-teas-attachment-circuit-20
service provisioning (e.g., Network Slice Service). IESG State: RFC Ed Queue as of 03/04/25.
-->
<reference anchor="RFC9834" target="https://www.rfc-editor.org/info/rfc9834">
<front>
<title>YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service
(ACaaS)</title>
<author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
e="editor">
<organization>Orange</organization>
</author>
<author initials="R." surname="Roberts" fullname="Richard Roberts" role="e
ditor">
<organization>Juniper</organization>
</author>
<author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez
de Dios">
<organization>Telefonica</organization>
</author>
<author initials="S." surname="Barguil Giraldo" fullname="Samier Barguil G
iraldo">
<organization>Nokia</organization>
</author>
<author initials="B." surname="Wu" fullname="Bo Wu">
<organization>Huawei Technologies</organization>
</author>
<date month="August" year="2025" />
</front>
<seriesInfo name="RFC" value="9834"/>
</reference>
The document also specifies a YANG service model for managing bearers <!-- [I-D.ietf-teas-ietf-network-slice-nbi-yang]
over which ACs are established. draft-ietf-teas-ietf-network-slice-nbi-yang-22
IESG State: IESG Evaluation as of 03/04/25.
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-teas-ietf-network-slice-nbi-yang.xml"/>
</t> <!-- [RFC9835]
</abstract> draft-ietf-opsawg-ntw-attachment-circuit-16
</front> IESG State: RFC Ed Queue as of 03/04/25.
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-attach -->
ment-circuit-19"/> <reference anchor="RFC9835" target="https://www.rfc-editor.org/info/rfc9835">
</reference> <front>
<reference anchor="I-D.ietf-teas-ietf-network-slice-nbi-yang"> <title>A Network YANG Data Model for Attachment Circuits</title>
<front> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<title>A YANG Data Model for the RFC 9543 Network Slice Service</tit <organization>Orange</organization>
le> </author>
<author fullname="Bo Wu" initials="B." surname="Wu"> <author fullname="Richard Roberts" initials="R." surname="Roberts">
<organization>Huawei Technologies</organization> <organization>Juniper</organization>
</author> </author>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody"> <author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dio
<organization>Huawei Technologies</organization> s">
</author> <organization>Telefonica</organization>
<author fullname="Reza Rokui" initials="R." surname="Rokui"> </author>
<organization>Ciena</organization> <author fullname="Samier Barguil Giraldo" initials="S." surname="Barguil Giraldo
</author> ">
<author fullname="Tarek Saad" initials="T." surname="Saad"> <organization>Nokia</organization>
<organization>Cisco Systems, Inc</organization> </author>
</author> <author fullname="Bo Wu" initials="B." surname="Wu">
<author fullname="John Mullooly" initials="J." surname="Mullooly"> <organization>Huawei Technologies</organization>
<organization>Cisco Systems, Inc</organization> </author>
</author> <date month="August" year="2025"/>
<date day="21" month="January" year="2025"/> </front>
<abstract> <seriesInfo name="RFC" value="9835"/>
<t> This document defines a YANG data model for RFC 9543 Network </reference>
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> 969.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network- 340.xml"/>
slice-nbi-yang-18"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</reference> 466.xml"/>
<reference anchor="I-D.ietf-opsawg-ntw-attachment-circuit"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 299.xml"/>
<title>A Network YANG Data Model for Attachment Circuits</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai 291.xml"/>
r"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<organization>Orange</organization> 182.xml"/>
</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 <!-- [RFC9836]
Attachment Point (SAP) models with the detailed information for the draft-ietf-opsawg-ac-lxsm-lxnm-glue-14
provisioning of attachment circuits in Provider Edges (PEs). IESG State: RFC Ed Queue as of 03/04/25.
-->
</t> <reference anchor="RFC9836" target="https://www.rfc-editor.org/info/rfc9836">
</abstract> <front>
</front> <title>A YANG Data Model for Augmenting VPN Service and Network Models wit
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ntw-attachm h Attachment Circuits</title>
ent-circuit-15"/> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
</reference> e="editor">
<reference anchor="RFC8969"> <organization>Orange</organization>
<front> </author>
<title>A Framework for Automating Service and Network Management wit <author initials="R." surname="Roberts" fullname="Richard Roberts">
h YANG</title> <organization>Juniper</organization>
<author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/> </author>
<author fullname="M. Boucadair" initials="M." role="editor" surname= <author initials="S." surname="Barguil Giraldo" fullname="Samier Barguil G
"Boucadair"/> iraldo">
<author fullname="D. Lopez" initials="D." surname="Lopez"/> <organization>Nokia</organization>
<author fullname="C. Xie" initials="C." surname="Xie"/> </author>
<author fullname="L. Geng" initials="L." surname="Geng"/> <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez
<date month="January" year="2021"/> de Dios">
<abstract> <organization>Telefonica</organization>
<t>Data models provide a programmatic approach to represent servic </author>
es and networks. Concretely, they can be used to derive configuration informatio <date month="August" year="2025" />
n for network and service components, and state information that will be monitor </front>
ed and tracked. Data models can be used during the service and network managemen <seriesInfo name="RFC" value="9836" />
t life cycle (e.g., service instantiation, service provisioning, service optimiz
ation, service monitoring, service diagnosing, and service assurance). Data mode
ls are also instrumental in the automation of network management, and they can p
rovide closed-loop control for adaptive and deterministic service creation, deli
very, and maintenance.</t>
<t>This document describes a framework for service and network man
agement automation that takes advantage of YANG modeling technologies. This fram
ework is drawn from a network operator perspective irrespective of the origin of
a data model; thus, it can accommodate YANG modules that are developed outside
the IETF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8969"/>
<seriesInfo name="DOI" value="10.17487/RFC8969"/>
</reference>
<reference anchor="RFC8340">
<front>
<title>YANG Tree Diagrams</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="L. Berger" initials="L." role="editor" surname="Be
rger"/>
<date month="March" year="2018"/>
<abstract>
<t>This document captures the current syntax used in YANG module t
ree diagrams. The purpose of this document is to provide a single location for t
his definition. This syntax may be updated from time to time based on the evolut
ion of the YANG language.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="215"/>
<seriesInfo name="RFC" value="8340"/>
<seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference>
<reference anchor="RFC8466">
<front>
<title>A YANG Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery</title>
<author fullname="B. Wen" initials="B." surname="Wen"/>
<author fullname="G. Fioccola" initials="G." role="editor" surname="
Fioccola"/>
<author fullname="C. Xie" initials="C." surname="Xie"/>
<author fullname="L. Jalil" initials="L." surname="Jalil"/>
<date month="October" year="2018"/>
<abstract>
<t>This document defines a YANG data model that can be used to con
figure a Layer 2 provider-provisioned VPN service. It is up to a management syst
em to take this as an input and generate specific configuration models to config
ure the different network elements to deliver the service. How this configuratio
n of network elements is done is out of scope for this document.</t>
<t>The YANG data model defined in this document includes support f
or point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual P
rivate LAN Services (VPLSs) that use Pseudowires signaled using the Label Distri
bution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs
4761 and 6624.</t>
<t>The YANG data model defined in this document conforms to the Ne
twork Management Datastore Architecture defined in RFC 8342.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8466"/>
<seriesInfo name="DOI" value="10.17487/RFC8466"/>
</reference>
<reference anchor="RFC8299">
<front>
<title>YANG Data Model for L3VPN Service Delivery</title>
<author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/>
<author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
<author fullname="L. Tomotaki" initials="L." surname="Tomotaki"/>
<author fullname="K. Ogaki" initials="K." surname="Ogaki"/>
<date month="January" year="2018"/>
<abstract>
<t>This document defines a YANG data model that can be used for co
mmunication between customers and network operators and to deliver a Layer 3 pro
vider-provisioned VPN service. This document is limited to BGP PE-based VPNs as
described in RFCs 4026, 4110, and 4364. This model is intended to be instantiate
d at the management system to deliver the overall service. It is not a configura
tion model to be used directly on network elements. This model provides an abstr
acted view of the Layer 3 IP VPN service configuration components. It will be up
to the management system to take this model as input and use specific configura
tion models to configure the different network elements to deliver the service.
How the configuration of network elements is done is out of scope for this docum
ent.</t>
<t>This document obsoletes RFC 8049; it replaces the unimplementab
le module in that RFC with a new module with the same name that is not backward
compatible. The changes are a series of small fixes to the YANG module and some
clarifications to the text.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8299"/>
<seriesInfo name="DOI" value="10.17487/RFC8299"/>
</reference>
<reference anchor="RFC9291">
<front>
<title>A YANG Network Data Model for Layer 2 VPNs</title>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="O. Gonzalez de Dios" initials="O." role="editor" s
urname="Gonzalez de Dios"/>
<author fullname="S. Barguil" initials="S." surname="Barguil"/>
<author fullname="L. Munoz" initials="L." surname="Munoz"/>
<date month="September" year="2022"/>
<abstract>
<t>This document defines an L2VPN Network Model (L2NM) that can be
used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) serv
ices within a network (e.g., a service provider network). The L2NM complements t
he L2VPN Service Model (L2SM) by providing a network-centric view of the service
that is internal to a service provider. The L2NM is particularly meant to be us
ed by a network controller to derive the configuration information that will be
sent to relevant network devices.</t>
<t>Also, this document defines a YANG module to manage Ethernet se
gments and the initial versions of two IANA-maintained modules that include a se
t of identities of BGP Layer 2 encapsulation types and pseudowire types.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9291"/>
<seriesInfo name="DOI" value="10.17487/RFC9291"/>
</reference>
<reference anchor="RFC9182">
<front>
<title>A YANG Network Data Model for Layer 3 VPNs</title>
<author fullname="S. Barguil" initials="S." surname="Barguil"/>
<author fullname="O. Gonzalez de Dios" initials="O." role="editor" s
urname="Gonzalez de Dios"/>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="L. Munoz" initials="L." surname="Munoz"/>
<author fullname="A. Aguado" initials="A." surname="Aguado"/>
<date month="February" year="2022"/>
<abstract>
<t>As a complement to the Layer 3 Virtual Private Network Service
Model (L3SM), which is used for communication between customers and service prov
iders, this document defines an L3VPN Network Model (L3NM) that can be used for
the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a se
rvice provider network. The model provides a network-centric view of L3VPN servi
ces.</t>
<t>The L3NM is meant to be used by a network controller to derive
the configuration information that will be sent to relevant network devices. The
model can also facilitate communication between a service orchestrator and a ne
twork controller/orchestrator.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9182"/>
<seriesInfo name="DOI" value="10.17487/RFC9182"/>
</reference>
<reference anchor="I-D.ietf-opsawg-ac-lxsm-lxnm-glue">
<front>
<title>A YANG Data Model for Augmenting VPN Service and Network Mode
ls with Attachment Circuits</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Richard Roberts" initials="R." surname="Roberts">
<organization>Juniper</organization>
</author>
<author fullname="Samier Barguil" initials="S." surname="Barguil">
<organization>Nokia</organization>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O. G." surname="
de Dios">
<organization>Telefonica</organization>
</author>
<date day="9" month="January" year="2025"/>
<abstract>
<t> The document specifies a module that updates existing servic
e (i.e.,
the Layer 2 Service Model (L2SM) and the Layer 3 Service Model
(L3SM)) and network (i.e., the Layer 2 Network Model (L2NM) and the
Layer 3 Network Model (L3NM)) Virtual Private Network (VPN) modules
with the required information to bind specific VPN services to
attachment circuits (ACs) that are created using the AC service
("ietf-ac-svc") and network ("ietf-ac-ntw") models.
</t> </reference>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ac-lxsm-lxn
m-glue-13"/>
</reference>
<reference anchor="RFC4862">
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<author fullname="S. Thomson" initials="S." surname="Thomson"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="T. Jinmei" initials="T." surname="Jinmei"/>
<date month="September" year="2007"/>
<abstract>
<t>This document specifies the steps a host takes in deciding how
to autoconfigure its interfaces in IP version 6. The autoconfiguration process i
ncludes generating a link-local address, generating global addresses via statele
ss address autoconfiguration, and the Duplicate Address Detection procedure to v
erify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4862"/>
<seriesInfo name="DOI" value="10.17487/RFC4862"/>
</reference>
<reference anchor="RFC2003">
<front>
<title>IP Encapsulation within IP</title>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<date month="October" year="1996"/>
<abstract>
<t>This document specifies a method by which an IP datagram may be
encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2003"/>
<seriesInfo name="DOI" value="10.17487/RFC2003"/>
</reference>
<reference anchor="RFC4301">
<front>
<title>Security Architecture for the Internet Protocol</title>
<author fullname="S. Kent" initials="S." surname="Kent"/>
<author fullname="K. Seo" initials="K." surname="Seo"/>
<date month="December" year="2005"/>
<abstract>
<t>This document describes an updated version of the "Security Arc
hitecture for IP", which is designed to provide security services for traffic at
the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRAC
K]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4301"/>
<seriesInfo name="DOI" value="10.17487/RFC4301"/>
</reference>
<reference anchor="RFC1701">
<front>
<title>Generic Routing Encapsulation (GRE)</title>
<author fullname="S. Hanks" initials="S." surname="Hanks"/>
<author fullname="T. Li" initials="T." surname="Li"/>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="P. Traina" initials="P." surname="Traina"/>
<date month="October" year="1994"/>
<abstract>
<t>This document specifies a protocol for performing encapsulation
of an arbitrary network layer protocol over another arbitrary network layer pro
tocol. This memo provides information for the Internet community. This memo does
not specify an Internet standard of any kind.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1701"/>
<seriesInfo name="DOI" value="10.17487/RFC1701"/>
</reference>
<reference anchor="RFC1702">
<front>
<title>Generic Routing Encapsulation over IPv4 networks</title>
<author fullname="S. Hanks" initials="S." surname="Hanks"/>
<author fullname="T. Li" initials="T." surname="Li"/>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="P. Traina" initials="P." surname="Traina"/>
<date month="October" year="1994"/>
<abstract>
<t>This memo addresses the case of using IP as the delivery protoc
ol or the payload protocol and the special case of IP as both the delivery and p
ayload. This memo also describes using IP addresses and autonomous system number
s as part of a GRE source route. This memo provides information for the Internet
community. This memo does not specify an Internet standard of any kind.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1702"/>
<seriesInfo name="DOI" value="10.17487/RFC1702"/>
</reference>
<reference anchor="RFC7676">
<front>
<title>IPv6 Support for Generic Routing Encapsulation (GRE)</title>
<author fullname="C. Pignataro" initials="C." surname="Pignataro"/>
<author fullname="R. Bonica" initials="R." surname="Bonica"/>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<date month="October" year="2015"/>
<abstract>
<t>Generic Routing Encapsulation (GRE) can be used to carry any ne
twork- layer payload protocol over any network-layer delivery protocol. Currentl
y, GRE procedures are specified for IPv4, used as either the payload or delivery
protocol. However, GRE procedures are not specified for IPv6.</t>
<t>This document specifies GRE procedures for IPv6, used as either
the payload or delivery protocol.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7676"/>
<seriesInfo name="DOI" value="10.17487/RFC7676"/>
</reference>
<reference anchor="RFC6004">
<front>
<title>Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and
G.8011 Ethernet Service Switching</title>
<author fullname="L. Berger" initials="L." surname="Berger"/>
<author fullname="D. Fedyk" initials="D." surname="Fedyk"/>
<date month="October" year="2010"/>
<abstract>
<t>This document describes a method for controlling two specific t
ypes of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS
). This document supports the types of switching corresponding to the Ethernet s
ervices that have been defined in the context of the Metro Ethernet Forum (MEF)
and International Telecommunication Union (ITU) G.8011. Specifically, switching
in support of Ethernet private line and Ethernet virtual private line services a
re covered. Support for MEF- and ITU-defined parameters is also covered.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6004"/>
<seriesInfo name="DOI" value="10.17487/RFC6004"/>
</reference>
<reference anchor="RFC6215">
<front>
<title>MPLS Transport Profile User-to-Network and Network-to-Network
Interfaces</title>
<author fullname="M. Bocci" initials="M." surname="Bocci"/>
<author fullname="L. Levrau" initials="L." surname="Levrau"/>
<author fullname="D. Frost" initials="D." surname="Frost"/>
<date month="April" year="2011"/>
<abstract>
<t>The framework for MPLS in transport networks (RFC 5921) provide
s reference models for the MPLS Transport Profile (MPLS-TP) Transport Service In
terfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network
Interface (NNI). This document updates those reference models to show detailed r
eference points for these interfaces, along with further clarification of the fu
nctional architecture of MPLS-TP at a UNI and NNI.</t>
<t>This document is a product of a joint Internet Engineering Task
Force (IETF) / International Telecommunication Union Telecommunication Standard
ization Sector (ITU-T) effort to include an MPLS Transport Profile within the IE
TF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support th
e capabilities and functionalities of a packet transport network as defined by t
he ITU-T. This document is not an Internet Standards Track specification; it is
published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6215"/>
<seriesInfo name="DOI" value="10.17487/RFC6215"/>
</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="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="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="I-D.ietf-netmod-schedule-yang">
<front>
<title>A Common YANG Data Model for Scheduling</title>
<author fullname="Qiufang Ma" initials="Q." surname="Ma">
<organization>Huawei</organization>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Daniel King" initials="D." surname="King">
<organization>Lancaster University</organization>
</author>
<date day="10" month="October" year="2024"/>
<abstract>
<t> This document defines a common schedule YANG module which is
designed
to be applicable for scheduling purposes such as event, policy,
services, or resources based on date and time. For the sake of
better modularity, the module includes a set of recurrence related
groupings with varying granularity levels (i.e., from basic to
advanced).
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</abstract> 862.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-schedule-ya 003.xml"/>
ng-03"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</reference> 301.xml"/>
<reference anchor="RFC4552"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<front> 701.xml"/>
<title>Authentication/Confidentiality for OSPFv3</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<author fullname="M. Gupta" initials="M." surname="Gupta"/> 702.xml"/>
<author fullname="N. Melam" initials="N." surname="Melam"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<date month="June" year="2006"/> 676.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<t>This document describes means and mechanisms to provide authent 004.xml"/>
ication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulat <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
ing Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]</t> 215.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</front> 234.xml"/>
<seriesInfo name="RFC" value="4552"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<seriesInfo name="DOI" value="10.17487/RFC4552"/> 644.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<reference anchor="I-D.ietf-netmod-rfc8407bis"> 880.xml"/>
<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-netmod-schedule-yang]
guidelines for writing the IANA considerations for RFCs that specify draft-ietf-netmod-schedule-yang-04
IANA-maintained modules. The document also updates RFC 6020 by IESG State: I-D Exists as of 03/04/25.
clarifying how modules and their revisions are handled by IANA. -->
</t> <reference anchor="I-D.ietf-netmod-schedule-yang" target="https://datatracker.ie
</abstract> tf.org/doc/html/draft-ietf-netmod-schedule-yang-04">
</front> <front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis- <title>A Common YANG Data Model for Scheduling</title>
22"/> <author initials="Q." surname="Ma" fullname="Qiufang Ma" role="editor">
</reference> <organization>Huawei</organization>
<reference anchor="RFC6241"> </author>
<front> <author initials="Q." surname="Wu" fullname="Qin Wu">
<title>Network Configuration Protocol (NETCONF)</title> <organization>Huawei</organization>
<author fullname="R. Enns" initials="R." role="editor" surname="Enns </author>
"/> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
<author fullname="M. Bjorklund" initials="M." role="editor" surname= e="editor">
"Bjorklund"/> <organization>Orange</organization>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn </author>
ame="Schoenwaelder"/> <author initials="D." surname="King" fullname="Daniel King">
<author fullname="A. Bierman" initials="A." role="editor" surname="B <organization>Lancaster University</organization>
ierman"/> </author>
<date month="June" year="2011"/> <date month="February" day="7" year="2025" />
<abstract> </front>
<t>The Network Configuration Protocol (NETCONF) defined in this do <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-schedule-yang-04"
cument provides mechanisms to install, manipulate, and delete the configuration />
of network devices. It uses an Extensible Markup Language (XML)-based data encod </reference>
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 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
soletes RFC 4741. [STANDARDS-TRACK]</t> 552.xml"/>
</abstract>
</front> <!-- [I-D.ietf-netmod-rfc8407bis]
<seriesInfo name="RFC" value="6241"/> draft-ietf-netmod-rfc8407bis-22
<seriesInfo name="DOI" value="10.17487/RFC6241"/> IESG State: Publication Requested as of 03/04/25.
</reference> -->
<reference anchor="RFC8040">
<front> <reference anchor="I-D.ietf-netmod-rfc8407bis" target="https://datatracker.ietf.
<title>RESTCONF Protocol</title> org/doc/html/draft-ietf-netmod-rfc8407bis-22">
<author fullname="A. Bierman" initials="A." surname="Bierman"/> <front>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <title>Guidelines for Authors and Reviewers of Documents Containing YANG D
<author fullname="K. Watsen" initials="K." surname="Watsen"/> ata Models</title>
<date month="January" year="2017"/> <author initials="A." surname="Bierman" fullname="Andy Bierman">
<abstract> <organization>YumaWorks</organization>
<t>This document describes an HTTP-based protocol that provides a </author>
programmatic interface for accessing data defined in YANG, using the datastore c <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
oncepts defined in the Network Configuration Protocol (NETCONF).</t> e="editor">
</abstract> <organization>Orange</organization>
</front> </author>
<seriesInfo name="RFC" value="8040"/> <author initials="Q." surname="Wu" fullname="Qin Wu">
<seriesInfo name="DOI" value="10.17487/RFC8040"/> <organization>Huawei</organization>
</reference> </author>
<reference anchor="RFC4252"> <date month="January" day="14" year="2025" />
<front> </front>
<title>The Secure Shell (SSH) Authentication Protocol</title> <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis-22" />
<author fullname="T. Ylonen" initials="T." surname="Ylonen"/> </reference>
<author fullname="C. Lonvick" initials="C." role="editor" surname="L
onvick"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<date month="January" year="2006"/> 252.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>The Secure Shell Protocol (SSH) is a protocol for secure remote 000.xml"/>
login and other secure network services over an insecure network. This document <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
describes the SSH authentication protocol framework and public key, password, a 695.xml"/>
nd host-based client authentication methods. Additional authentication methods a
re described in separate documents. The SSH authentication protocol runs on top
of the SSH transport layer protocol and provides a single authenticated tunnel f
or the SSH connection protocol. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4252"/>
<seriesInfo name="DOI" value="10.17487/RFC4252"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC9000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communica
tion, low-latency connection establishment, and network path migration. QUIC inc
ludes security measures that ensure confidentiality, integrity, and availability
in a range of deployment circumstances. Accompanying documents describe the int
egration of TLS for key negotiation, loss detection, and an exemplary congestion
control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC8695">
<front>
<title>A YANG Data Model for the Routing Information Protocol (RIP)<
/title>
<author fullname="X. Liu" initials="X." surname="Liu"/>
<author fullname="P. Sarda" initials="P." surname="Sarda"/>
<author fullname="V. Choudhary" initials="V." surname="Choudhary"/>
<date month="February" year="2020"/>
<abstract>
<t>This document describes a data model for the management of the
Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. Th
e data model includes definitions for configuration, operational state, and Remo
te Procedure Calls (RPCs).</t>
<t>The YANG data model in this document conforms to the Network Ma
nagement Datastore Architecture (NMDA).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8695"/>
<seriesInfo name="DOI" value="10.17487/RFC8695"/>
</reference>
</references> </references>
</references> </references>
<?line 2410?> <?line 2410?>
<section anchor="AC-Common-Tree"> <section anchor="AC-Common-Tree">
<name>Full Tree</name> <name>Full Tree</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-ac-common module: ietf-ac-common
grouping service-status: grouping service-status:
+-- status +-- status
+-- admin-status +-- admin-status
| +-- status? identityref | +-- 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
skipping to change at line 3811 skipping to change at line 3262
| +-- ebs? uint64 | +-- ebs? uint64
| +-- pir? uint64 | +-- pir? uint64
| +-- pbs? uint64 | +-- pbs? uint64
+--:(other) +--:(other)
+-- cir? uint64 +-- cir? uint64
+-- cbs? uint64 +-- cbs? uint64
+-- eir? uint64 +-- eir? uint64
+-- ebs? uint64 +-- ebs? uint64
+-- pir? uint64 +-- pir? uint64
+-- pbs? uint64 +-- pbs? uint64
]]></artwork> ]]></sourcecode>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The document reuses many of the structures that were defined <t>The document reuses many of the structures that were defined in <xref
in <xref target="RFC9181"/> and <xref target="RFC9182"/>.</t> target="RFC9181"/> and <xref target="RFC9182"/>.</t>
<t>Thanks to Ebben Aries for the YANG Doctors review, Andy Smith and Gyanh <t>Thanks to <contact fullname="Ebben Aries"/> for the YANG Doctors
Mishra for the review, <contact fullname="Andy Smith"/> and <contact fullname="Gyanh
rtg-dir reviews, Watson Ladd for the sec-dir review, and Behcet Sarikaya for the Mishra"/> for the RTGDIR reviews, <contact fullname="Watson Ladd"/> for
genart review.</t> the SECDIR review, and <contact fullname="Behcet Sarikaya"/> for the
<t>Thanks to Reza Rokui for the Shepherd review.</t> GENART review.</t>
<t>Thanks to Mahesh Jethanandani for the AD review.</t> <t>Thanks to <contact fullname="Reza Rokui"/> for the shepherd review.</t>
<t>Thanks to Éric Vyncke, Gunter Van de Velde, Orie Steele, and Paul Woute <t>Thanks to <contact fullname="Mahesh Jethanandani"/> for the AD review.<
rs for the IESG review.</t> /t>
<t>Thanks to <contact fullname="Éric Vyncke"/>, <contact
fullname="Gunter Van de Velde"/>, <contact fullname="Orie Steele"/>, 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" removeInRFC="f alse">
<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">
skipping to change at line 3857 skipping to change at line 3313
</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+19a3PbRrLod1bd/zBHqboSE4LWy7St7K4jS3JW59iyVnKS
PbU35xRIgBTWJMAAoGStrfP9/q77x24/5gkMQNJyYm/WrK2sTM709PT09HT3
9HQHQdApk3IaH4iNQ3GUzWZZKv7z8Ox7cRyWoXiZRfFUjLNcHJZlOLqaxWkp
jpJ8tEjKYqMTDod5fA1dZcd6I4K10RmFZTzJ8tsDUZRRpxNlozScwZhRHo7L
IInLcZDNi/BmEpRxWAQjAheEo2DnYadYDGdJUSRZWt7Ooc/pyevnnXQxG8b5
QScCwAedUZYWcVosigNR5ou4AyjtdcI8DgG1V/M4D0voXYgwjcTLMA0nMaK4
0bnJ8jeTPFvM25qJQ4AjfoKmSToR32Pzjc6b+BY6RwcdEYjLaTKKxWWcX8P/
4xcv9n48P6M/duUfh4symxF0/NdZXOLIlW9f5aOruChz/UXBEAWsQHId57c0
lvxunmfXCZIEcLLbFvEEca7BGE/jt8kwmSblrdM8mc2nyTgZ1XCzprP3/fm5
8xPMF4cNF+VVliMJOgI+48V0yov6MruC/4/Es2wxCqMwyen3LJ+EafIPGukA
Zhumk5h+yDPkvjhKyoxbxrMwmR6IGYPpDxWY7zLq1Afu6NRHvUhGV2EeiYsM
GKMsPGP++yJNYJVbB81z7v7d37lxP41Lz2CvilGYi++z9B/hNP4HLJE4TjLf
mK/jaTyGZRqF9igZdu9PZPcI0MiK70rdtGGGl+EsiXPxLMwni2Qqvk/ycBpl
nkHPsjeJM15BPftD7vnfE+75XYrtGgZ7lomfFh7Yf16EN3EC8xpdpdk0myRx
YY80hX3Tv1kMs++uqCFDh/1Z5skQ+B35RY7F4/yYjOBb8SKbx/9Qw3lmcE3N
+lNs5uDtADu9DlPx7PZNdm1AXSTDIYgmlFCLVHK6gzJ26lOn7/LhMPXB/UuS
WtRQRLCBwN6awrydWbsw/iOG0a8S8WoSvkkMqP84Pj61Ab2JgyzDJt+9iSIv
oBeLpBCHsBGm4uUizSyq/ZhFIXBQ7CwItA5w20z7M2z93bVsxKDTLEcRdB3j
upxevtrZfvj4yQEBkMfCaTrmNkDEUq36LcgDZO2RQ1WSnInVPn4LexLGFkOQ
HXGciuK2KONZAb1P0zLOYXsnIMDFJX0tysz7dQLMEwYRyEpYBpC/ZYyS2DsO
yMUyG2V8ZC2KGFoJYD7YzCNqeJOUV6K8qjQkaRohUPwJ2qcxNZ/GRRHM4AgU
qZR9SnBuAake7z/a6xKltCQUeingd/onnU9id3t7l2kKOzAuD8RVWc6LgwcP
bm5u+kmR9aHPg6IE8oEEe7C3/WRvt39Vzqadjp4lr9DLk+cDZ3VoHwL9p+Jy
Ho+0KMeGYtATJzChHJBX8rwQx/E4SRNerkCcX4VApNOmWbwGcryMyzwzgJ5n
+WJmTQ2Eaozz22+c3yweoxR9cFgUcVk80Bj/t4Nx8eD8+PkDQPu/B/15NO7w
ZHcerTzbnUc9fTy+OnwpLuJfFklOR3gh/rd4nsPmoTVUs965x6zF4TwHEQzz
frR03jfzAOUf4PFgMZ9mYVQ82N3eefhgex+nG+w84vkGQSDCISoAIzhxEAfQ
khakgRQ8WVi9ULBqJEKjaY2kOia2Do+KLitvyLTTnri5ApEjQFxEcZFMUjiT
YYsNY5HHiyIcTmFf3ooM58gdij7MXbfGfrM4hBGgE2pXOe2NIilKUouOQJfL
F6MSvgfEAKmJhAK7KCzFDA6N+WKK+xjw6iMJYZ+GoHDEPWgBwOVUqJMYgeSW
mAGagJfaagom4PB2nhUETYRICtmiV2uKw+e8/CCYU9rZujlCwn+UIhsjrJ7e
3Ci9orgyqNa0uG1cjvq8VrMkiqZxp/MVyqw8ixYkMjqdIyk+rkHXUmMCtrlU
2iKenRyThhgtClAE47yAUy4UqA2gugxrBZIwSYHDAf15liAfb8X9Sd/w+XMp
1+CHy+dFtyeOJChxDpyfFDDwCZBhTnyydXR+gm1Q7UyzWbYolIB9Bqos9LlA
0ZojH10+u8CWEZoAozilbyeA0014CzSAhSQxjRvjREnec0Kw2xeHWoDaFJAM
VDBMYPK0GMOQ4zybiS0ACCwH8yQG7cLyTEDepXUCILWwdZYnE/whJgBdycN1
evXFq+HfCRUYGSV9sYD9EPoxnIW3yIEpGCplQguADBFO8hj+XMyzVJ9ioV4y
bqI5SK5wDiyC7E6M6E4YJlCGb4AXpiEMiccRnFDyQKKuClZPgPGUIKcXC1Sm
CVYYAVfjtIF9F3P8WbMnNMmucQCANU3SN4WepDrWJMqbhU2ojmQsxMuDhdgC
mwsF7vS2B/M8Vz+fRLDkW+cn3S7u5TiPh7edOAWRgqMBkYHlC9AlefLqdJbS
BZCCX8P81rFicDJ5DCTKiQk6RBaURUoIwpbfqEu9DZR6XZJ0IM5wCosUEJze
IkikQ8eFi2Cw1cYwhi2Zb8BK/XTlLilKDuDGgtb1xkgZWgHFLFJcwepkI2YW
Ui3AyiqIrD75DByBPKYkE6KRpHjqI7uhhAGBhCN6+vYRS2ZyMBJjr/hHEWMJ
D5Ry8zAvkxEI4VwjjpsA7KQ46kiRvZiWCchkI6qieB6nEaDLjCkPnxF+P81u
cUwg2glL8gJxbkYGWAdxgbV8924xurtD6aBFFPPQ0Um3I3ce2NnT5B+475D2
86vbgo76FBUwQDsUaG7gNzASbFw4UlB6II6SWzeLDphsiDDueGTYoxPkqxIg
lxpuDGMrAWo5LEiAgRw9PO8Ctk8vnh892d9+DDh3jk4Ktd4V+haw1IZ0Sjq/
CG9hiD0wbfJyAeie58k1blplQG/9eH7W7aDRQw13Bf4bZ4iDXGVF6VmURsHP
qD4aDB7e3XX7nUOF0+FRD+d7ncQ3fOJYdNLbvKeEHtjYKc0JBAnxaYbnFVCq
A/TQo28cnexskMiDv3Y3unyoMw/jDoHxoqSAjVSoRUfc9vcG+3d3PT0pTU/m
G6bk+YkRX2Ct+jhcio9wDtiHpNZ0tHCSzInbEHczQlHEBQ06D7WmomU4NgHu
wMnAnx2t4C/m8yynzc/4ElfIZUD2leSFrki6cFpkWpzGZoqooxii7Wmi7W90
lVYmKT8K8zyxhTfNHk9EkiSjUrCkAhHQ+R/4iDAsridSXa19+oHn0/9fTc3f
e7+E5hJOf3nzPrXaGu509fAwnmr5jQvFB+A9tzo8gv98ozGAb4HZZI/37QDO
T2wAQG4EsMkz2HS69WtTws8mNdsa7nbpb+xVoZiC/835CYNSW1nj61DsvQO4
iWJ7XoqtMuFmiu1Kkm+2A6hSbL9GMdEKQFFsT1LsmxrFvP0N+StA3zf23jRs
/A1jXUexuXcNZR9+q/T275SVe1uzYKrLD1Bta/i2K/4oN7k4jcRb2uaddwfi
q8WIDd8/btrHLciWTThfiQEDODEn6R83WEnfuEPD0VaaPJYjmDYLEGBbG+R1
D0fS2b7RJQXZa1e+e1fEo4A74ilDFrKEs7px2RNKVWRjADW05fbkAme9ikEZ
Vya4jkEZhEUQBupwBY0yDC+7SoDDKXYaHPdrlxSGVIEkFdAGJbdnrLUsUjWw
7XDXFwwOOoQH/SXPr6DAtkE6TIJbULkBIVit05KPWzyrgCKKHurIa7B1W6af
ljcNs6+Z0D25ksQIeIa9NgsFKy7XCqahTMMkhYYJKRT6rFZsIDEio9GiXWUi
oIWAFiiVj8dPBk9IMaKByTdCw7DToWZkAD+iv03bQ2oJrOsgvBcDDRYW8jAf
XSVlzHrF1tnL48MuTH5MZixpP/+GCOzt76IS2fnqK9B48bohAZXwLAMu3not
98sMDn9aEmgvG3U7HWoj8TA/HLAWVLCHkrRbB8o8TzIyM+cLsMbYP9avigX0
R4Wgt7EZepVN0aa7DqcLtdfS2NrO1EgaODA7qaTL5tAYESwT1FrGzqjS3MNp
gA07C3PoBx2mU2xIqs5iCDpOuWBNli3cPKbB4wiQPp8iY6DGN2X9dZxNp9kN
bh6JFXn3Djqdr8Vf4SOC4E/UDswylkhIN74qJOlGiw3cDO13t3cfBts7wfYj
02tE6jp6+BSG1nT4K4uK6Po5ytJrtEaU89vyrjLHoQMN8C30lG9nwwyYVFr9
xJBgnoBlkYSTPJwpy8nioqfMRdvERS/eXr5ke5YXPpP+bKXtKinBF7dbL3Yv
Xypz5vH+YHB3pzRebaVUe+xZPXafPJGjnrWOqreJGvVMw3iy+2THM2q1x57V
Y+cx7xiXZxdFXFSYABVvWPxndHYedA5APddWI6y2MhfRDcDcJV0iBVuG6Ekq
YAN3pbFc8X30CaA8mJW9D7sgj/FeAAfAvyMC3xevpOGkLLfSuiBTvUnyIv0W
yRTdRgybj1M5Dl5xq+bq8CbRYBwUiBf2yOjGGs9soAcapTitRZr8stDQaMni
lMUkzA04dXyrB1buJzzjtb+HRax2hsDkYtUziXM4TS7ZhWZA64O2BEPmuoqt
WvmUZw/D4a5HF4uxq4Tey8b5Aggv0nA2TCaLbFHA/tfo36ASYZ2eWgSSEauo
A0s9iud0pLpLOIlToBvLMOhH81BiVh7Rke1EMtdBUoS4t+/kAPH54xGRKlP4
tCtpB6LdXzMDJeZyUTQY5Vh4kSF7U3zCmfInb/344vCs6GrvjQWGtoDyGUZq
ofSOQT5WByXeNJLMosMSPTDKhQ2S6S0SqFB+Rf6q5gljhSwHXW6esb6TzNCy
ht/VDQWe/HBYF1fZTcqiDmHR1n9/TlC11v2SWr8XF5rr3oPBA7xZvifFBP8K
cO8U7wHMpVyvfZwBHsKDJyiEsMub+DYYXcHZx/3MP9VxvfPoEbdMw9HsvdKt
UC8I8At9qEt41/NUKtDc1vo3NwVpJpuiQsaN8K86tntVbNEEQIpII2DjpVSD
cEfBIiW5ODREZ4LFBdoAXwGdpnyrdpXMkblfkR4OCpeJ6oED6t07UP+R49BL
BEKaHXaF3AoWBNtpcg3nON4dADCjSfEZXDUpapaDbsMcGRTXI2qkSPCwv4NE
WEPftketQ9u9BzRQcgna6tqv3XsCypG/O/w4fVvM4D/pjJphzzbXjkvUurn5
X/Z/6z+/t/8rf7bcRLaDxDJT+x27dw2c/cUaLa2VEn/AS7QKMzgw/8tMq/lD
LSs+k2UtbWvc+Qhr7XXrZZ//Wrnl+/VabnpRQ44R1vJ1Oqz2/ueB+KsUsYX4
T+NDsHa4kiOuGNho8yXE9T1t7H4t0KV3uba1e+7e7LEX1Nlg0rTrSyUOj0O0
tOwDpi4xJAr62kCeCY6VjxZsEywlKxhOv3OZzJJpmPMdlzws18RjmhRsCFlm
PJ23GIRCf0hlrwNG3zgcYSge2hl0RLKkNdeLZBqriUiNSGvQ0kqBFvbdn7Qn
9OWhS+Up6GU5TIdFO3TVNCukE6SyiFUKPV/keILgtUCPtK0EsLGuL4S+zdij
f+p7C9IF6ObcAc7iUekAiwlHaZCBgAYOzpVsDtndIsY6eBMc6K2U2xV6W0yJ
NjsYdMUoT+bGACTy2XGyfCrzZsHwOcecU33MptHKFyk8h0cBwwpeQy+8IAP9
eogQKiEDcn2N7UNaNN8BdZReCopgRBe8IzJLE5wqex6exyH51aRRytiwlVk1
qsayKZzom1Nc0l2gyyZaVz9I8wX9VyO6hebLEsXvtFiKKQBzsE/KBPe2BLT3
AYD2KoCQEWD7KQM/0Eu6FLDsyeo/Si2LG9D+oztrVHvi65AMkSJb5PBdxdEY
SkDGIlTcRUGOQMY459tKilTD67EG27ICVptsvN2BVcZJDn+M5OUlC6KQVHMT
2KM9HZKRR1NY9bIHJiaAkA4LuaLYXNIjjnra3sHBbhLgW/IPJulouohiPU0f
vdBgJX9mxQIkA4/u3yRcHXqAUzC2EmwgbeaoC3MtHpFbT8nUwyX38qv2lSa6
XU8irkbU7IxcHEZRjpF80k6GLUPKt8MxbGszDU/PhewiTBe2zBMpnX3hTBKb
W6TzosqIN+b6vh5kIb8oxPGfj85NwAH9C0+HW4q5KTCse6RQg7n12Y1Ip4sS
Aafn1wNYjwK6X+IBQ66KQzkbjPxBSwZsag4zF1uXLw4Pj5TnZf/xYBfMAGs5
ae+ilRlIlxQYQ2/L4Cqbe6mHP4IlO8dDCiVTK5kqThFNKrSmWYGHb/E+GaO6
yzwcYxAC3VHI8CCOGZLOuZxv+XXDMruBfoUilzyKEiemAQZW0zFmLDTIFhMy
YG9JBksHgLrzJ3Kw0weJsxuUC/h9WmcpKQ8cRxm3hSWeWi4FyVHktViAOgDS
B7YH+eH1dbSkDoU2FfEiytD31KuFGIDtrx16Wz+ev7jsstKl2sV/LeO0SPB2
pu48gB5/BQBdmtfeGvPaa52XfXdF8Ve0k4CyB8CtYLkHsN+Y/3a3t/cwUuD0
HI42HT2wvYPf4Sy+R1kEa4uBakiJk3QUzouFVJ+2vr84UZy88wh76b931d+P
Bo8G5GDYhPUGjRHFV32GmhVZRkaLNArT0S0jXhVwDcGNTWxehhP00c8w/gnn
BDPNMOz3lgABYvgyoRkbQkGJUWqTB2UWqBWkuLwxhpZt/XB22tV3SA1tzqgN
RkCTn1vAv5X/jHUJGbAkXWTv3mH8Ma4G/bXziP9Ewg62tynII1MXL4PdnYcg
S8aGMOxP4vgQcpjn8QS2qBLZqChDA0Cb6AKoWCeMDOfrdM4wPiqaJWnCT2Wu
Y5KLi4IoUyDdTlPc9ImSILTfrSYg03Fut/WrGnbV9CpXQvLUOcCIZPGN2Axv
wgQXPrgGeyki1ttkRyJpGnyLYR/jGE1FRzfilWjUcYNgKAuA6VdBw9cjlvEt
oG9CGQxzLUMVJUJ4uNPxDz9LgDKeR0MFhhzjNyhnr+UVkUQBaYvjXyXDBEC1
jA+MnWYl+S5h9CnqIPEolMtYWaN5ho+GUIXjYfL47yRSl0xPNUNuLJBlcMAR
Kg9G4+ErZnuFcRcNJ/OgeSc9+/6cXgDxZobRMHKxuGIFC38sYuJR6yLxye7e
vrrHu1A33PQaDK93HD2FFKmasqKvxSeqU6vSIrWAgCe2ia6kbB6ggRGUZCp0
cWZHLItZh6/uC/XIi0mDHMKU5taZevAWTitNkX5gCgETjJNpHIzGk6bhD/Vk
WGfXkyVWNIqOBGVdJBR83hmzQzZhs0erqbzrNkEG5LdkhGmsDKhNCt4/EOwc
LpzbdMV37M6MI+mrkmLBgJUBtXxJJBX7+XyaKIXW8fjzucaY/ZIVH4hSTwYj
FxKn0RR1efWkASPz6MUhn3yhCvPWd/LAknuD/X2+20ZMxmEyBS0fFLWSz+A1
8ZL9JTYaiiGhHPtZEoHqMZKcAwffjRTix7rL1rPnx13TkbF9+PjxNoYIWDSW
YyXpdfZGUZruxqpUHutRVpsUadlqeJYreIfsrr4BSssSjt7EpTSdb+UthlH3
+dpLwZSA8HCUESw9+6TrkQTEEUlBYMtSblXxIin4rcaLQi1dzvrMmgsme1WR
oumSQTeMNWnV2oFoU827DfTehH2OIZ05P2hoFD3HVQE3D/GJTSnRVCbBMCxA
sShGV6BGTfndloFtCSW1Q0V8Tb4gVvSrTjA5D7Qgc2kydsVWVVjiK4ToOiSX
oDWyFryeO3btpQebDMR4ILvFMoxGBl8CibXAc8fkB0TfBIGUocoPj9/wmep+
/95u/FT5fZXSCIqP2zDPBIiHMuBAemyPeB3gaR8ADQMMv7CGhOYo3itj6t+W
jyrWGVWTxD00DEnoNAjUaWCxt0OmViH/tfhbEv1coR4cMQKDxugRtAHkl8nr
QFhFlq4Fr01+rQOoWVK4UIQPil6nyg43CyW3GZj5wCJ52cJn1dbZnNipuXWe
Sc+1Ab1yewnc395cddhCSt11KGP4kli+hy9YSM3gY/WVpQOd2nJJK3Z4DaKM
99g2NyksEqz/qljUPbVLxug4DgCSTLOawgOGR7nzlx4+Of4LI0kRXbA9AzAd
J+SSqXkTpLO9ASXUtIq4Iv6UPcpisO6gkCBl5KV8GYVxWXpexnjQBmnV2JeT
0tCd53B0SGtfBq67dXc74Jtgumzfxit5sFPRn0EWJrkppNH2aG//sVc+Ix1/
MawNxCND/6lH4OHvo+tpmMJ+wt8XYGzuDGxglTVYBazu+0uSroFH4cNjJRQ1
KS3BO+LWssPerv5lHOYB2KUEKqXcDwbS9XxarAHjay+Mt4CrBSRNAg3GCwwf
m9Bba9PIRx5qlswD6dbDsTH248B8ZWNhvHOS86x1kGvQMpTDm0ow+8nxvpGq
sheQdF0oX9ehIFHt46CdrKtTdnXiamFryxklbNU2PzIhUx5BuufzrqPk2mvU
MSng8PT8ep8EIvm4jTSzlE2/554uG6R8eoaQots0nKErHf1vjlfdL5TVbU0d
jZ5ovF3wXgM0Xy9QmgG6hyKpGvcFvUtsBY+KN3TZ1JpVdDWab8qLA74Z4otV
adLOQhiD/NfTWxmoHmLyBHzLCyegvn3AmESyd4bxVXiN8cT0Wlteb8lr9pKM
j00cUu0uxgypZS4mkvFqcyimYTja5GspjmVyMk9k+gqWXymjgo+3gkWsro5t
q6coFvKgovsNMV/keN1bcAt8cqVueoCTpOdfRcehzofvuXie8vZDzmCTFn6T
ewTTOJ2UVzDfDiypCRMsljBzEx+PMxl1gHRVW8V5qVxjZDauEBY5+MCCGmZ8
WedgVDn6Lb6unZrJ/Hq/uk5GaDoTd8QOyZ3HumHDireckjDw4FMNvB8YWgVE
05VG/gAczMd34mxVenSfWtL5YEuKrW5Fyd9ytr/pow8U6FndpF23kYRUa6ZQ
jtPFLFaZqdzBqQ9dUjojK5xVGHCgYYPV13UbSlDepr7XVaQm8e2097BCDq7r
AsRgX9b597TOg4Z1tvezWWFHkjetsBB+NpL6Fl+jLgfSDGIlPsPPB/AajXx/
fnuveqkxSZMwnd4bhuO3NV33F9mffwuycSAHsMlmmTYuxPjtHP2TZQWmqPCO
vtavNasQbJ5l06/F3/D/AtfNYkdi0spwE/Ol637x9CBPhkKFiO9ddn9n0PBd
Pmrr3Lb/36+y/9+vtP/x45EB71tkgIa6TAY4q9MqA2pkXlXWG1RYqzdcUpWl
GtDfFJ+4zjO3WQtXeKZkLeo6B9I9BNXg/oKqDuKLoPoXEFSD+wgqX+cvgmoV
ZcWg8pkJKoOkcfTsNTl69hodPSpAy7oS/N+UlA8s47yc1EzjSsiO9MnIy46e
HUGtA+Iqz4HVgDKtY3FAd53sIt7ffURxPa8uz5+rrx6iT5mjlejJ1UPMn9MT
p5fB6SV8pzJhYtwY/r6z8+Sh+vvhHqYFYt/8xakaZHf/4R7Gbz/nB5mW87uG
m+U0GoO4md5uagdRoQNF0UvQkz4m5XpSG5h6JcqNTm8fldso8sWi6WWwfVLa
z6GHhMlc7zrT6dEEzzCq83uOAyZfHXyZTroWXhoNygEG8CWQbbzy74uXGd23
lmGCz/OHQA8PeVwfhQ58x8ee4bjE973Ayl9jDOsVHhx8SuCheVC731BBzM6T
TjtfKCDL7zv4IsMBiT4m5BTJDHRprhebo1bMSCq+nINCCycpJV6KuJDfxLeF
ecdh3u5VmoXTCV42XM1kXHoGvI/Ow2k8CUe3+OxmGussz9L1FWUUG6XwgZEE
vWssnHeNfSKXcc4Rd6hYU/lUwUnOgIkZ0etU1Ig0rzzal93U63CkoGYmudvo
xg2/33N23bf0CHQxutIbHUaNsrhwZiSjQR8+3FXTkK92ODDRPBzvrTQrTqsn
8bfElM52JoNEXh+dB4ev1NtXFTzNucQwu5qCrwmu/YjWsyQZdUwjY9A2jz5X
CRzILcvb4iq7UTkKDUR6NWKN3Rd/zm7wRU9PBjeq3FY1XIqrbDGNeAntp7zD
+DYjNsw4Ra7NIxh5lKTTW3EJB//pMXN+PLqGP7f0U1W+nZPy8MnuQxWG9DWH
mGCKNdokhdiiUDy6WaBvAoyrgakG+I5B+lM9LfjnLh4NtJcb40ysV+3u0Pql
Ov3LJHAbK9euyfqrgroPL8UZJ4vYOrw8w9BpO2sifNUzu7cqiiti2KSbkMhU
6SLx0Rf48jU2ve7w0kxSpM9UJscvHWjkSaZjyyLM1mZWzMfs45JEToqkkF90
20UmRhHOKCrQiTNyXw4YNpfy1X8t7KLIyF86x/uBOHcWVPM53U2kZX4rk//h
CzuACAeSqx9QI34exKHLmyZkm+m3ad0IUvRVqYQ4jciPafhhyjCeZkgPOyLY
k2pok9cliZxrHi3S7aBxzi+tQuMwXKzMQ8q5ya+dtBNe44iLH9aOOanoOd/b
l3fy6LU15CEYCrF7YwiyAeNH4ByMMRFN1cvHYt3r4QuzijvvvT1uEGbWyJWB
nfZhhq/uST7pHvoZ/oH+K3CjkRQWs+ihHw34oQZ3dbA1Y84hC/auXLNW7lmr
zWvmrk8Zl80p6ikL9KnfcldBm/ozZA0Y2aRS8K+P/tnCYvX10SP8kywUCdsv
C/X5L1SefJay9jNap1+J8C1aYc0TavkvyVERFgH77IyzMqZHwRauDQ1dw7sp
CAvfhrRd47XNojIF/JcLyqLfP8UcjSZ5sOYQWIHJcUnJ+M2sxKDRXxZhpJvO
MHvUyManHuFmNNgPQsRyfwrnm9rtoXTKoaeKFFCLIUOz3Yxzn13ldiOME3zq
WWz13LQeIWYTQEvCJrQMQvQDDigzM6GnEP6pB/pZvDMpiQjbO9unjriK1gm1
z6kyLeFMq21m+ldfiLo3Yl6sETSv264TNy9UD3/ovP55peHFOsO7V0Lrcd/g
t+G+QRP3DdbivsFy7ht84b5PxH3DsRXYjElBsYG6A3M5omphm370T2ADZSD/
bJNbfcno11fSPMquSnJ9HeFcH6j7CHXfwJcMzlXEM5jpTRKVV4575N274U3t
FsLbVGc3BNwKzIxkpwTC3C1Jye8K7WjFC/QBbB2dXnB5DKySgidPvckJNZGe
k/M4fOMFdA6tlHejiD3YaW85vlcd6mngjVlfvMYn4ypbKwUzYwWSlNPoLvFz
mBsWCcB6zc5vM8XXYhNoiUw7ygp+ryb4zYGFScI5eY/wjSP6PXSOgqPsUr6C
swBhUs4WSOhpmU5NiiX22ei33uhBQwie6EYNJjA0NKw7SnLF7YN98+2w8Hwb
e9vG3rZzb9t5pa0PSXzc78RB6t9ghwGx8Edng8nvGmUDGR7uzbqQFoFcwW5d
4sG3MBz8t3L3aN12Z+rq0QQD1NowFVxC1BoNi+WN4lUgxatAmq8Cad4MiQhH
D9Ar5pOfndyfa7zi/FxnMPfn9t51lnN/dnpr2WrLRCVajVB0xOpXKgdWQ8lX
mRZLvPvKSgApU/rKq1xO6EspGWqpGDgFZq9yMYF+ZFdi8RbnT+cPR6+OT8Sz
k+9Pzy7/JOjBeSV73Xcm63Mfz8KNjkrM5TQT7zp8VgbqFmmnv/NthwswFnNM
nbGxyEGhgV4HJEmKg7ez6UFaHNAJW0mZhz1Vehn15bco8ziBnqgkDqXRdQ/z
/bf0tb5Wkqu6gSmukRr4Gr+lfq96mxHqxG17NRMeU7cVhO5dBTsrBaqLHmZJ
bUEME6Ue6PwyR84NQuVdNKHqHdwkd3XHxu9bxkYeOqiTBI/DAivpyByx3iFN
hlZ3SPz+3kPueYfUHht3RP11G5Vhfxx4V/0/4ltxRPfAcsyOW8+VoGxgRWXx
6vzy8KfvxdY6hZC7BJWyyY9KhgUgfoqHcGyLP6hiiHjxiGUN38Q5vbGmapc3
kwecEPXBn3gq0BGfxkPPP2Dl0jI74N+/U13+xGqCzoMvGgoNWx8Fqa2UsBz+
kOtAwl++QsIemL5KwTVYLXWCPSBXKAtcG8EtCtwEuVhWAbgG19T/9YDzVfn9
E/FCZPIlMj+QxLczPpvEKI2lLKmmG49tqllWMozodCoqX2GPz5Ie97NTwyEb
65tOqWzCJp3f5snkCgYbdakaABUWF6/zhZVsE8uJ4U6wrmlVwg4uHFqYAIMI
60OBXkpQ8WKUwsEiNeBFjBWdqAoyBXmkkSpQy4kG6ZthkmIqKKpB0eMZy/rU
QnpIkRhWlhBWrNkIwWdOxYILdvKsiwWVP2QAUj/GAiEpJiWNsc6FrARBZy+r
/BfxdYL3mc8uj2FDUlvuj4QHxFAHT4347I8UBQz5NgvxIp5QWjKZNqVQNJhy
DjOs9IvNj2WWJfn7lhIZJYKJYyMuJNYBRvEog4HrSziBHhVeS0yQBspJrBHx
LcyDrrklRvB1UhbxdEzykhJ4Tgn3NCvxqXJ/g47qPJaVUay6ESynqxyP8hRL
QAAI1am/0SK8EaklZ3ddx7LE+YOvWz4q72fT7w8AAPxPZYjU+T7b5qYi1azc
mkq5wOtsg5kDde9Doe41QG3MBLrOKFQTtCUxqNylSg6qDHZNqUNld5U5dMVF
Muku25bpwYOWxJQFqZMq5VxDDHYzYZ5hmRXdnVKvNCTAlGUFDo+syemOTtyv
HG1IFVz8CH3bhM9rK0vmZlHPkxk6mTKlZFOLpOtkLMOQI4R/Azx5nPtiSy9k
JbbJOFD7YKPiYZWy5reju56CmlJYiJsYE8oW/MR1jUSkrZIS05MerAzSQ083
2PrXXHgZoWQ2bKIdVKss/KdbajLKmcT0clpVBYtiayZqCpX1/3UXT73NoHqe
9107S5Lik28GTc/iVTEdnV8QC7NYc3bLidoi/oG5iFDp2pwJ+PPoriqU4ejh
IEXlK1G5dgsfA6m0uRaZ/MM3UsmclUvz8ZbVUi+KVlaCXm/990pVpCmYiIDT
VG8ROYhvgjwbquz04XN8fZ+MwQrJD0kc7HBNJfVO/Th3cwyvc4qvkHbYd+zo
xCcObR0sGml6bjqrCalq41YFJf/AmCXlA4ZcngS5ARXNZ80YYcaVe6C0Ur5l
iZ3GZhm9NM/stfDM3v14pjWls4dQCaYUCxJH63NxaJY052hQwn9fU2NMbN52
kGCSaDxIKtmf5V49PfciR/mkPwQzsHMXmPhJbFFS6iUKyt72zoHp4tSH1Ana
MfsynLZqtc3nXL4P8kxgUtmKq6G/Qrrs1ulgEu2DVZJuq7nITrvLOtFzBEqD
ItWOwoaAObqVpmCZaa0g69QkxJw98zqcTPgdlrpkrijbTkLw5i1z4SYE79vm
OQl6XRCCzzdZwEGhSE4dfwbwkjH0mwLcweKCCsLNXKx8Vxz3jq87fOXqfGqo
xux+w4YWpNaRYZVQ5wSwDh6UqnkNEWZVwuG+Oj+dZ5KLNLGnh+2/laDrg8Fw
S1Ku+4ZIm4bwzGZ5wnYve1D+9mCdgc455TtGFSLPsTMtoRs5qQqjw09VHSmu
QKPRPKzLDMkUxkhdJdgw2IECTsQ5Jm0HwfnX8667xvQe8BCjbJy83a4Po55m
3Z6aZQm5aa9l6EyL9o950b0Z5EEITuORSiZl53DXup6dyt2byd2zNp6s7p9q
Jjc62/SHZo5X3esJ5H0zryST/1TT5kz1BvV1EtZ7pqWz0n/6VdSoyJn0BCdI
LrlGKhZTzmCTon2DdYGMb1IBAN7lBPrrZdh3trPKpu8QSSXgb5bbH5yVv1Vp
wTz9B5wkTryIwzeYTE6WaJYVmtVTrB9oJ9Y1h4sM85eCbPrh/Pjw9Qk/Wz0/
ORMvYXgsola/PO54nHY2dyhitPok9BtEZAi0SsFwKA04ecuCdb5haoeXPs7k
6k8faWRdwXeVkfPinqPyil1yba2ti0vvMZcXwUeZogTCasHFpb7uu6DfLSdd
65zpOeeHIcJ5zyVs4Lar8BprbsnD2Cm+uuotAgYZRPG45Q4BIJTcCJW4BkcU
l7kykWPy6xUcLHeNmoYezHjIoFkysYxclZVS38LoFUC+sAWOmoIT02/hzlGl
Gu05KJygl4jNv20HTw6D52Ew/vnd7t3W/+nbX+zfdd9t9wZ3m0umQtKahrGL
5yEq5kUwBW+usmoXtYogjXc/+If2aXAua6EXtSElfbPkVYBkO9VfyVV1J6xl
vqKlVx92gSkYNhQ7nlrD8kMDeIdtVUwMeCGmcTiuYtjKwRYfr3Zc8+fO+tuP
8zpY37n4WwHa9UnUw7VtvNhhLsbhtHC+b8TRuHRLU0c04pJrIP8AvBL1Lvru
EcnI+qZ0V1t5K5bdmp0f8QZ2eNVcpsZCga4trEW1Bia6wZ+z+bcOnnfO/hSH
Or2AKkRT319ufYPm/aUiJfny/kiXv3GuOOq7rblMQvsOPNIQcLwVSu8Y+spb
IJ5whlkf6CRC2UxBJnidbnvBeQFMf+sGqaLDRhk6Gswa0fP91hIPFodgBouN
JNpYyh0vZFIAq5KPb8JVqZFE9c3G58ZqG0mCNoleKtWEFA6cFIIKKbbsFyKN
v2jFfWjyl+zy0xHDHnwNKqxSeOM+NHn2/PjT0UROzqqtpMryPD+uxI9/COna
aozch2ZWnaRPR7o6DmuQprlqyn3oYuX1+jREqSJgKAKWu8tPleach8zOJ95C
QgzxPgB1N1xMS9iY6W1wkydlbDRl6xS1T2un0FP9MK0UoWnRVv21oxTKRN9K
4RpN7CVqlPc4ddUkDbmiKZGPwtaVEktPit/O9cWvygqkVaY7P9raAvtcsI4S
sk4iD952JZ9VsfZpfSvMxKumVqdh5sDNQY/B8pEyTUPbBFan+ifA37cC1mZr
qEtkBQweYw0cZ9dRVZzmvWaKuk1sHZar3sD2kxcR7uZTJW1cSvotsKr1pfq6
unkDZV+HE75yqy+oqo3j4sA5BKzhKepfbOz0+/vbT/Y3Vhr1R4wnMMK9vhgP
quWBHIpXfmum/blsKKn9+ZBYzRJLUjlTw8pGzfPRmduwn/Vo9fOZmPIh/Hq8
o5wjxENbl8GPFO/hZ6Zfn5OPlEeX0TlqRccjaKrFwSxJY8UMbZ3/1HV3QDWe
qI1ZrMZ2IEwD+2AdpTqh9nZXFNChOP8Jr0Bkumzz/uTHoyWrJGs0VcZOzS1l
A0KKwd2ySiut3lmcTK6GWW7uPYzWVr0KUQ/DtvFhmBWSdUllbvldF0rzlCz8
H/SD9hfhMK49IsLPsf12RUWqiK0Xx+ddcx0y6O94xAZGYDn8YIV5+UKnoPmv
tvQ/HrUuayCN0M9obR1KYriYS0orPs1HSyqUtwoxqZDY+uQk+DpOwZhVWz/q
QAVn2+haZB8i72mygQaxmgCWcZusjDG+8r3GjF5sPaNC8Gjb9OSLL6x6Dz+Z
XWBXqeIIcvx9s4l9KlXUKjP1M4cXd2Vo8r3QZmFFLRsNzOYPJadfO3LaYZha
RbxVdMFqhKrhJ/csX+cc9wVSLj1M1XW4N7aURqwEKSqIxslaO4wEa+MbUZyD
kRYFmBYjyPIA34Rt9fsPECxm7FYvtw8MhM3uxvL7jFfoVeVi4oVR/CsVMSW5
HFf7pjWQkfStFFr/FJWuc9PeTzVLZK9NL+z78SklNgnuioRZ4VDRlwjTooEG
lqxdnwjY+VehAgFelQwrnAeKDgi3RRvcs+vLuY/UsLyd+2zMEUG+EnMtiuE5
Zj5TWbkbji+nVkn9FHtc15u3+/293RV1+MUQw9pknL8cI347JzlMOSuGSVn0
xSkHTtHKoQ/FLCplRDcX/zqwwivMlYei9Q3fcvna+irGzHiGr5030qzc8rLy
aJGDNlJudR1m5lqNXbFhpviN2ADJuwyG28GWqfWXbptdZ7fEeQ4AZxyCA4tC
r5MSeWlFRB/RXTq+LD6/Hqy4IdQZh3nXmXH14w8MnjKPgeRTJzyIzRycjYTB
jt5TmSKZl2yIWunD1g0x+HU2xM7u4y87YiU+GfwafMI53a3kXlKXIb60hG1d
mFarGjYzD48hX/KLJtlqvepSgBXCdDb4JDj/PLrK8HRqWiK/V4L7qCwC1i60
4FhxJbiWqoLv0tP0J3WANi3Y8JbftOpASAna1sRmcZgWkl3lAvueAUr8eDq+
t9BtmKID0CyAeksOoyF2gcHX7BAgldN/2RR7Ome/ThfnuybK6Aony+05yR1Y
K8fkzEvuQKssU+VnLtkk39vXfmsmjCQPP6CyixQ7GOLnzjee/cr7w4YjCH31
N92sMI3ph4poM5/QDo9YDWX3X80YVi4Z+Gn+uPY626rIU59k7eLPHv6uys+1
B/PtKFKso/X43eW6FkYz+ra39FZlHVso5EbFmPoR9otlWBeLn4rq6hibvlbZ
q8ZPtnVv6v1VV7uN5zYqCkgrrlVU71pXsRrx1HrYDCyxX9dT7nHWeNWWFc6a
mnL0Ec+awZezZpWzxmVW2w+16lnjQmgVAV/OmvazRoS+0+azPmvsN8z18b8c
NuIeh83gQw+bwW912DzHrFoekV+xbNoMm1UdRFaPBtPYqa7rdc7Xj2//jbKb
R4TirqimnpNYRcdMeCzaSpXe+yGT6MwVYgZ7QEWCjelSSb9Yni/yeVazr3/3
Vp3NvmqUDzlp3UrDqwmnQ9UZl6LJ0SSzmFXEExKFi3tURACxT2PdYr+84BCC
tYSEe3smMeEabAZ/GeMmZ1A/mipZgqopxMzHL1YkGVSdmsrcPBLcYFYlQ+tc
XRFe90ipeSoeq0+U30oj39WPXhLsdqlnj5JAEaiyuHMNwFId4ph+HsaFb3Ws
DEdeS1VNSmVWdD+03cjRuulUkt6UpSkxL35PJJ6cFsIkzqc0AECgqd5FLYOR
f7A6GJUxtKpRb8p09rWPTtaDSFG9VM5CwK5OKnVY4BsF4GQcyEuRqiPS/rCL
VVbhrq9jY3yv+rSvJIkMYhErTllXV5Q7nKeCfnYvhBrt8PLaJp1vWlWN1jyx
soqHN053qe2LnxmsIaphoJTli/iDaONqo+MkNxtLFVpF4q0xQYsu95zemsjj
468Pxb1Zl2/Rqz9HpyRX3/zilVx7uN+nV5Iyw30xFf+V/JJSw3Ozc8YrPBV+
oYv5VlDUVcmrz4NsNcwhFeleSj+rqF9ZHmE6jAD4A+Dl367CZiuiRg8w6Qzz
Sk1Fa0KbMxOY1FFOE7d73Zcqp2/fo9Z0l0atpYWbD1NbS1HPh1X2UzPzpv2s
gp4ryrsPsyVM3I6kY4BWOBjU0iheJnDW8mqs6kJf9Zb/o3g1an4ifwiZ7ROX
hNKPiW1CrevHWG34j+PH+N3eGNic/Tn4MWqBEP/sfoy6xqSm5PdjILdSOPEX
Z4b7+eLM0IN9cWb80zozGu9W8PPP78xond4XZ4aL5Sq33jVnhgviy7V303DL
nBk+DqRku5+PM6OKYpt+8MWhUVMDf0d33x/HoTFo8hqoda3W3SBKfhIHRyOq
93FwWHfrWaW4tT9eTFLgt/ZxDH4FH0cDXy/1cdRM93v5OOi5j8q3bj3xUV9h
CTykCxvBjqMDc2G6Pzf7Opx0aZjntdKx7vKwcgv6xlgpT9pKA2mlit3VZsVo
tYag3sTqlVTz+mycUPcCrXiZ0qOoDF1/rmKmCDsXkxfN4CjKsaqcQYLfoPX7
DxR+fxSbqIpubixFyaUFNxriGqBhH8pUvLzKMusuV9622W6I+UtGi5z8+PVw
YnmeZfOantIoVIyzpbIyDKTwuBXCbPWT6odCHuavQbwfuiO8YjS34Kfg8FW3
KvbrD+wlTHxm//DJ7kMqzt4M2HPgSa4KajNo4q5l87M4TU4SZtJ2filhmWHx
Wbv2bAUTXYP2QP+F5fbWwuxCl+eTfhRGj84lgljX25poLtaseuuffM0pM4se
rslKL48f4mx4E8h8Pk6G6mUzkVVDBvsHuOMevMRXqnDsVQvanFWqZNQ/W1i5
2crEsLPX3/WxHMzxN1hr424LzdTVuiPRPp9Fb/DEEbGQAB6fiDfzw5pUQQLU
E1H4sDS4+BHxO2ZaEfGcfADe58BS5dqBxOQxk2UzWb4Ui6FMmQq9We+rQ2AT
TnrN6IFmWIjDy6PTU4l5q+NUaU6YVzMDE32CCZKuZn5KNKf8xQ89ATTMXQW5
zMxttyccS5FBT/JwfgUKokE6LIpslPi9rVQUBjvjQnyAxaF1NpNer5iPV9bA
KkfWkjy1H65zvbo8f/5F6WpQulImj6NuVW4klLpVy3JByK+vb7FuUjStjU/d
gga1UvXqo6Xmb3a+0HVOaBJXNx4srYeAntS/4mng25NfjoPf23GQFEmx8nFw
ehmcXlZ54lc7FLyj/QudCuauUx4DTBDrHJBi32YDf+reex4BvpX4cgZU5vUR
zwA7EeEnPQO8W/DLIfB7OwTyZHWn7MVpzUj8iCeATlTmGeZfV/QTNar6v1f6
fxx3qytDK8tQjK7iWfy5in93e/124v+jiVxb//dsgi/C93cifHWuDV1+QYu3
2oUZZQ6lbwIcHzoExNnNirpdYxfdegaCltZ8O0OXrBRuUdwWZTzzBQ/7AnfD
IuBwSUWCBnFuFBldae+Mwyy3Di/PurK8LPyJcg32WFZUHqiE1lVlJrNHlOJN
mt0UMqoGO4NExHqd5HQvxWJu9/dUiLRilIkyH2WKlVgBREunadRzUDEsBkHr
Ss2DnrqwHoezZHpbwXKl7LguhOpB1hxsnWI2XnnOFU5YHkFKTLAo13rFuEo9
qc1I1oEYvdmUgci0dBTyyDH3acQX0zfJdIpgrCXTAOv0sEqHrpDZTecRdEsw
Lpm+e/zp6qNbKqSop5ezR+zTE3E56ltXgw1Zt+9fgvQDipD69D2PTPnVBIoI
1DS0FUOBKqENAgd3JI+FjfcoXWHd7LPfxdjzNqBFyn5bIx+50JckOdKKrKMc
C/1yA7YOOticSX+SvW7kFwgrfEpA27NHe7OHOjFtWdQOqrvdI6yw9GY1XThX
TslKrGbzyyKMFFb+KNklC4sFtrGo5unx0t22/xBvBNmLyRxxLvfvA13v4CSa
xDprvW+7yYCQD7qBrd697vd3+3umIeI4eDh4yDhe71G5dI0jowYkd3D1DnN+
EhyddHXwjZqOM3B9rUDVyK2nKJ4XFN6leMnd5L4CS0Mm81zIBJ+lVVAKQ6Es
lEEmjGQxGhJb8xAYq6Dc3ZWj2eOiXCmnWPNeI0fG73CzeV9W2b98lN1WiWOz
ddhLDndTS15P1SODHfNyEgBR89vmNbSCsGH2+lTBFxVqJUlzKJwhFd4E3NVe
razclYeCnKF2VdVVvhLEFNnc0bMaWIGgDCdrn1mnmAYIq6JhZ6tQG2wlFUzs
lpx3Rq3UaG4rSdFQYED+6qn7vKKmGBMSApFQqd2saagXHdaaxZaayGYrv+bT
71lIEKZOmGdOAd0KRdNfz58mIasmbkZJMQrzaBP7bbINM03SN5u+whNNYnDl
UjE4OwnE2I3GTHQm3izi3J3SciGvq9GazeLIufoG0XuCQmlxIKqWQYxsxR4n
42Ach/gsUGxYQg476JOWYoVxWym6b7QSSdWpMBsnNq9hi6S0nEgm0VRVXjgt
rFTjTknrFroOProEGtxfAg0+RAINPpkEkhsL9JnuF2n0LyGNBh9LGlU3S1Ua
DdaVRoNfRRpp/4xOyY4eOSclu/2K/GMIKVCeXh2+dO3ycUsZQIqGp/elTHPW
iKlwsf/p/1U2jaiqZAs7weYsC7EBCiwsSAwSLyraqeja2LoyKKKhxrP9069t
2uLWSmbo4hMFfCFwCSKsS74wK2G6avTncZ5kII8qOQfwld2N63UznZU/EHf0
eJGyhWHhdVoBFmVxkW6WDLTCEQTKAm3D7LmTIF9WmpV8PVMutVEfPn68fSCe
JVGSsxUEYvi5KWlsHEJbWAq65zP/TI21x/2dx9U9DUxmkiO4d376a+mDadnl
Ts1PK9mC402hHW2DUluUXSr20yKvj965+VBvxRiev4IyMbkCbl8k+K9eGi4G
KsJTw4NlZ/cyXajBgk4z9w7kzsEDJMoIToR0FNcwabzuqPgoDQin/oQ9VPMs
VCEKa3XwtUTlMlACov/T1TsztwrfECzFmyQqrwJLqq/KHLpzk1AaJXldHg32
K/JoOF8iho6AZAm6lMRpCuPO2OK/QJfM1tHpRZffl83Ct8lsMbMSO2D9EXsr
45M0gTdlYgS0wgWgJ/M57N40EtEiJ39fSpetIBwpvMb0hy5taVxHw2KVud4C
760622cLfAl+mfwD5/nsEuYJ/yUvfY6Fu5GDh9jkVqR0ehpcpcemzMMxnM5A
H/6DaYDij+QWC83Y8ukaCEBXfLO6mKETBz2b8CvOYAHcPZUXavxNHoejK1ea
W05iwNhDrPjjMMbJW6rhV+eKE+CKnkj6MehkMTcaI4cCmCmseW6ljKBDABBF
ghSL4d9BwvKbYlW19UV8HU/F4SSP4xnsbbF1+eKw6yiSmtAix9GRuYb4mhGW
kd3fgI6PCB+LYyQZbHY5IXZB1MwmDa/DZEqXvbR5F85zTDUDzL9AywsQKOrM
kIRuhWYZcABrJBJuZYfxW2fJN3pX8bGuSpnJsTyJR+SjViAY2x70lFnyqs8v
Nv84jHSOFzR1Njq32EiJlyV8pFyk8S8LzsQDpJ7i6gBxwMYCAEA72lwgYPx8
Mf9YfEGzsrniHLmi+aLInAVxvqT+1PcN5wCqULemvjKd7OZnNSvSFIY3NMYK
erx/jOYQIQm5ZoY2HM1VV6/sbo5kcyI3RPC4WoVB1SaFFU7EMToVFJteC3Bj
xDESizmwZhN4GcOCazfK3HfFjbE/zxyqHk1DfjOsRN/WUXZZeQRJK1qFL1cU
vq7n+Wl5PqeMNBilnpWGD9XM83rbLmH2beWX9oCQ2vttGBn2t1w9eVN5nIxJ
fS8bgkIuVeHrI7wzP0ezUWwdXx6dd9lZcHQSHKHZCbDF1uPt3f7OvFuHQjaE
ukNRrheSLWu9hjs9OTkRl2UkaKC/gHmRJ9GEvEiR/DvS91atIT18M+pRB+1O
3owVyHVcyWQlnntFTV0urqz+Crj4Am3uOn84enV8Ik7Oji//1Pkf/el0vkLL
CU4iUJWOshRfwfO1UdHpkB+okHaViqtCT9C4jNldUMazOR5m6q0Ou8vevVPG
2F7/EfLT09PguJ/E5ThI4xKgBPl49Hh/+9EwKe7u+jhQLDbod20FbPAbRmi8
mCJ4VWo3wkeNHOAlz9QOjK0TkNFdER75aIsmIQEJWELMwjScsJ4yl1eDRQ+O
HTRtis7ZyeujV2fPAfenYJAOdvd37u6IUy5OLu1fHm/vbwPOqD8UsQEkrsJr
vKzqoOIY6heveZgWpFVPqSaodIVdXv5ZQtvffbh7d9cTr19cKvj7+wP8Bobu
/OWH0yP59ZPtbRi2SxjJoUhHnS3oGrYSpskUVWWnj5zbwEMu7nzEqrJ8H7p1
dnj0sgtj/RuisIeT70ifgPKlUehKBhsODUrQemSRaDyAgAlhaNBqcqHImOUd
TThMmVGoZDSxpQCbeDzQECwdzAdEUVoma6GQfKqMmGGV9lJO2c8zchB5yCUY
G0I7i6msDvlCLSoG/HBuHaoAH2nOymOVXYT3NI7W4dEKaWjx0NACFJF4OjYG
BYd0wYC3zMI8CIUg4kg3sAFx7r3qryryCG2JKOCYRrxOplvSi/Ojot85LIiL
qTx3Tree0B+9tIn0pBRqgydFsYjt1E6dskI0GjKN9ZRHUiRQsriXPFVupCwk
TT6T2EQ6hFmEg9yIMlB6gfad4ipbTCPlxpBJWrIceApO74hzKUhUR44s6qM3
CMVZ/DYEiQOzx7WgDpmObilsZMgDJYk+xyCF0W0g541wEkuhVQ7qmheWXdW1
q6JNMB/gKCxG04xRQBFiA5yFpPw65AM2vE4yeetfyT0SaPdbmS/Y8iBUceZX
yRwofwmGVg4raea3tVnPILIJk/A8a8WvPc+bNnucY68e9L7ZxfFpDqRWSbGw
8+gRyER6WlkJSFe5RoXQvDizeYUWg3ZPdZ1wDPo1SYF5k1Ke+V4mwKh0IBnf
yWBHc848RJIaJBGRaZH1alwhw4Hp/6cYr27et1NIcEgIyThf5F8O/OWl7bNB
i7NQIcTQ4gpYMopHyQw3GnVEENxD3BC/g0mX5RGgEWNwPCmE6C3P5rfWjQSa
Tto/gyAw9JcBimxUxlgvVvwZ7KhrDLTjY0sNIw3BhGOt9MZDKJhNymY5OlzR
kUdnaA+YdBTijBINRdLIpFFagAjMiVodUl5IH1PrKzePPLwGTx7CKdVHreL0
8OywplFAf/o+KVQAKEuaPJ6AwiuVinGG9iLO+4eLU6UHbqTFBh4Y3DJnyjEb
0M+nJ6+fi7++fCEuZIMNybZ7g8eP7+4OOqT0YHMAegCMnacHqHEckAZVHLyd
TQ/S4oCCtFxNBPtIoCHoDvQ2b1QeMDOcnlx+Tw4PGBq+Ontw+C2H/ujZ0Rzo
6gyxw0C6Yo5uMsZnXYrYslpRhr5j2YzgznAIl1ZMicH2LugQknBWV3PbuyFU
F4teCA+mVifKmZrL2uQ8J0l6IITz7Us45ugxCXEeUuUpDMLkl1r+AYeL/RU+
kn5BEIA6PHqDLEcJp1/nMdiOXx0eBUcEOcAv7jq2zsv0O6hOyTb43RurA9Kk
v4Gh+N9K1cZvwmiWpIH7/Xu78VOll1tGttswzyg5JAb6p5MY23OsIEiLAER0
gLc/1pDQHJWgypj6t+WjinVG1SQBQsE5NU6mcTAaTwxJwFxLIn2EBdYdhU0m
WD18ZQBiQEMxLb8Wf0uinyvUA+NWWBJVAfoF7N77QRiDngn6ZxCpW6X7wtMX
VfcEJK+Gl0IRPigmKnceJCnntkahaxZKy5eAkry28Fm1dTYndmpuDbwEMlGG
ujPoldtL4Ev5L8rKnV/MbMpwQr6opx4ex99H16izJRH+zvGcNjBQCfGRyy1G
ikziaBWwuu8vSboGHoXEQ9h4uCgKP4pFvIhA6uextddGPCHZYW9X/zIO8wBs
FZptyo4FDel6Pi3WgPG1F8ZbwNUCkiYScf2pAKMoclQytCTykoeamQAYHLsS
E2NjMd0NykWaxlOVAtZaB7kGLUNpgnasvegnx/tGqspeQNJ1oXxdh4JEtSVA
O1lXp+wHEddX39DQl62fYBqnk/LqaQ3Fx7qhTp3vQmrZUL6CBL/VwPu1gs0r
jfwBOJiPjzm3Kj26T62FPNiSKd1tbyn1cnI8mz6a96BnNWFy120kIdWaKZSt
XMrVwU0mXmdkhbM3bW7d30uS0Ne07hmWErWaAtfia1P8pMZgX9b597TOg0YJ
ZtbZrLBT/aVphYXws5EUzW4Nl2YgzSBW4jP8fACv0cj357f3qpdT/8R0em8Y
jp0VXfcX2b+xYomjjVUhKl9MBaao8I5OpVxrViEYZtcHzVnWbvjZ11ytjCzv
oD+ucu7p4dZJEE3L7u9s1SDgVWzr3Lb/36+y/9+vtP/x45EB71tkgIa6TAY4
q9MqA2pkXlXWG1SqWcWrslQD+ptJgv1zTazZGbL1x+UKz5SsRV3nQLqHoBrc
X1DVQXwRVP8CgmpwH0Hl6/xFUK2irBhUPjNB5dWo6pdMRlZVsts7bEOJfuwV
k0mI7FaVjEFVrZMT9Xg1zjCrqJfv7XGDMLNGrgzstLcSe+seDcl3PFjMood+
NOwk0k/XBlsTLg5ZOMNa3Qw2LoJq85r49TGHbF5NMtNiO3suGj8L1nCSL/nX
R/9sYbH6+tQyIX3mC+W5+v2yUO4UPo+Fql/Ef1mn34TwLUlPapq5pU+7yZGM
8syJlCxcGxq6eROa7g8w5U6bW2lpMhszBfyXC8qi3z/FHE3GmYM1h1ApWcyn
mo9FN+V3ozY+9csZk4vjgxCx1HHhfFPzZlVfWFoMGZrtVs3oYDfCK66nnsVW
r0Xrlxs2AbQkbELLIFQLlALN1X6W+rN4V3lQf2fbePRKvHVC7XOqTEs402qb
mf7Vd6Huvd8Xa1zx67br3PIL1cN/0a9/Xml4sc7w7SkD2rlv8Ntw36CJ+wZr
cd9gOfcNvnDfJ+K+4di6k1cvoJVPxuWI6gNe04/+CWyg3rL+bJNbP3AV/pU0
r1DbNAdPIL4Zf5TkCuXBvvl2WHi+jb1tY2/bubftvNK25fGSQVH/BmSSj3sc
Kqn3Qk0LTNqj664TUq2Tr226dbaFb2E4fsDys/uz0C2suIjH/jZMBZcQtUbD
YnmjeBVI8SqQ5qtAmjdDIsJRcHm3toU87OT+XOMV5+c6g7k/t/eus5z7s9Pb
fV5yOMIkpWCiTDAGvOi8O2AdMY7+uDEOp0W8ccfB+ypMnCOFMQNJemuqSWI8
0yLXEcWxiTPvJCpE+cnOY/VsQz6b2Hm8K1+YhOkbeoRwMhzGqTjMEyvrBZfL
ykZlRoWPr5P4picO0+hWXM4wQBcBfg8C60q8TIqrPNRJGvBgjJJc9il64qew
LLJUvAB1zmRZiUdWI466fhZfjeJSXIZ58ia81QDFBMy5vJRNHbwv4n+E4iJ7
s0h048ureA6sEvmavwyv4uJK/HuMjysx51lq+h0e+3r8v/+L2VJ+vE1Hb+Ke
+H6BD7rFj3AqRrH4MZ5G8OUroJq4LOMYI/BxGufhYip+wiwquaEmxsTqAf4/
0iSZKkBfAQA=
<!-- [rfced] Please review the "type" attribute of each sourcecode element
in the XML file to ensure correctness. If the current list of preferred
values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable type, then feel free to let us know.
Also, it is acceptable to leave the "type" attribute not set.
-->
<!--[rfced] Abbreviation
a) FYI - We have added expansions for the following abbreviation
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Operations, Administration, and Maintenance (OAM)
b) Both the expansion and the acronym for the following terms are used
throughout the document. Would you like to update to using the expansion upon
first usage and the acronym for the rest of the document?
Attachment Circuit (AC)
Service Function (SF)
-->
<!-- [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:
black-hole
--> -->
</rfc> </rfc>
 End of changes. 130 change blocks. 
2030 lines changed or deleted 760 lines changed or added

This html diff was produced by rfcdiff 1.48.