rfc9182xml2.original.xml   rfc9182.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml2rfc.tools.ietf.org. --> <!DOCTYPE rfc [
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY nbsp "&#160;">
<!-- One method to get references from the online citation libraries. <!ENTITY zwsp "&#8203;">
There has to be one entity for each item to be referenced. <!ENTITY nbhy "&#8209;">
An alternate method (rfc include) is described in the references. --> <!ENTITY wj "&#8288;">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2119.xml">
<!ENTITY RFC3688 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3688.xml">
<!ENTITY RFC4026 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4026.xml">
<!ENTITY RFC4176 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4176.xml">
<!ENTITY RFC6020 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6241.xml">
<!ENTITY RFC6242 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6242.xml">
<!ENTITY RFC6991 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6991.xml">
<!ENTITY RFC7950 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7950.xml">
<!ENTITY RFC8040 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8040.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml">
<!ENTITY RFC8277 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8277.xml">
<!ENTITY RFC8299 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8299.xml">
<!ENTITY RFC8294 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8294.xml">
<!ENTITY RFC8309 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8309.xml">
<!ENTITY RFC8340 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8340.xml">
<!ENTITY RFC8341 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8341.xml">
<!ENTITY RFC8466 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8466.xml">
<!ENTITY RFC8453 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8453.xml">
<!ENTITY RFC8512 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8512.xml">
<!ENTITY RFC8519 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8519.xml">
<!ENTITY RFC8349 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8349.xml">
<!ENTITY RFC8345 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8345.xml">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="5"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-opsawg-l3sm-l3nm-18" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-opsawg-l3sm- l3nm-18" number="9182" ipr="trust200902" obsoletes="" updates="" submissionType= "IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth= "5" symRefs="true" sortRefs="true" version="3">
<front> <!-- xml2rfc v2v3 conversion 3.10.0 -->
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="L3NM YANG Model">A Layer 3 VPN Network YANG Model</title> <front>
<title abbrev="L3NM YANG Data Model">A YANG Network Data Model for Layer 3 V
PNs</title>
<seriesInfo name="RFC" value="9182"/>
<author fullname="Samier Barguil" initials="S." surname="Barguil"> <author fullname="Samier Barguil" initials="S." surname="Barguil">
<organization>Telefonica</organization> <organization>Telefonica</organization>
<address> <address>
<postal> <postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Madrid</city> <city>Madrid</city>
<region></region>
<code></code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone></phone>
<email>samier.barguilgiraldo.ext@telefonica.com</email> <email>samier.barguilgiraldo.ext@telefonica.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Oscar Gonzalez de Dios" initials="O." role="editor" surnam
<author fullname="Oscar Gonzalez de Dios" initials="O." role="editor" e="Gonzalez de Dios">
surname="Gonzalez de Dios">
<organization>Telefonica</organization> <organization>Telefonica</organization>
<address> <address>
<postal> <postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Madrid</city> <city>Madrid</city>
<region></region>
<code></code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone></phone>
<email>oscar.gonzalezdedios@telefonica.com</email> <email>oscar.gonzalezdedios@telefonica.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Bo
<author fullname="Mohamed Boucadair" initials="M." role="editor" ucadair">
surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street>Rennes 35000</street> <city>Rennes</city>
<code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Luis Angel Munoz" initials="L." surname="Munoz"> <author fullname="Luis Angel Munoz" initials="L." surname="Munoz">
<organization>Vodafone</organization> <organization>Vodafone</organization>
<address> <address>
<postal> <postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone></phone>
<email>luis-angel.munoz@vodafone.com</email> <email>luis-angel.munoz@vodafone.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Alejandro Aguado" initials="A." surname="Aguado"> <author fullname="Alejandro Aguado" initials="A." surname="Aguado">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Madrid</city> <city>Madrid</city>
<region></region>
<code></code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone></phone>
<email>alejandro.aguado_martin@nokia.com</email> <email>alejandro.aguado_martin@nokia.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date month="February" year="2022"/>
<date day="08" month="October" year="2021" />
<!-- Meta-data Declarations -->
<area>ops</area> <area>ops</area>
<workgroup>OPSAWG</workgroup> <workgroup>OPSAWG</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<keyword>l3vpn</keyword> <keyword>l3vpn</keyword>
<keyword>Automation</keyword> <keyword>Automation</keyword>
<keyword>Service Provisioning</keyword> <keyword>Service Provisioning</keyword>
<keyword>Network Automation</keyword> <keyword>Network Automation</keyword>
<keyword>Service Orchestration</keyword> <keyword>Service Orchestration</keyword>
<keyword>Service Delivery</keyword> <keyword>Service Delivery</keyword>
<keyword>NETCONF</keyword> <keyword>NETCONF</keyword>
<keyword>RESTCONF</keyword> <keyword>RESTCONF</keyword>
<keyword>Slices</keyword> <keyword>Slices</keyword>
<keyword>network slicing</keyword> <keyword>network slicing</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>As a complement to the Layer 3 Virtual Private Network Service YANG <t>As a complement to the Layer 3 Virtual Private Network Service Model (L
data Model (L3SM), used for communication between customers and service 3SM), which is used for communication between customers and service
providers, this document defines an L3VPN Network YANG Model (L3NM) that providers, this document defines an L3VPN Network Model (L3NM) that
can be used for the provisioning of Layer 3 Virtual Private Network can be used for the provisioning of Layer 3 Virtual Private Network
(VPN) services within a service provider network. The model provides a (L3VPN) services within a service provider network. The model provides a
network-centric view of L3VPN services.</t> network-centric view of L3VPN services.</t>
<t>The L3NM is meant to be used by a network controller to derive the
<t>L3NM is meant to be used by a network controller to derive the
configuration information that will be sent to relevant network devices. configuration information that will be sent to relevant network devices.
The model can also facilitate the communication between a service The model can also facilitate communication between a service
orchestrator and a network controller/orchestrator.</t> orchestrator and a network controller/orchestrator.</t>
</abstract> </abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>Please update these statements within the document with the RFC
number to be assigned to this document:<list style="symbols">
<t>"This version of this YANG module is part of RFC XXXX;"</t>
<t>"RFC XXXX: Layer 3 VPN Network Model";</t>
<t>reference: RFC XXXX</t>
</list></t>
<t>Please update "RFC UUUU" to the RFC number to be assigned to
I-D.ietf-opsawg-vpn-common.</t>
<t>Also, please update the "revision" date of the YANG module.</t>
</note>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t><xref target="RFC8299"></xref> defines a Layer 3 Virtual Private <name>Introduction</name>
Network Service YANG data Model (L3SM) that can be used for <t><xref target="RFC8299" format="default"/> defines a YANG Layer 3 Virtua
l Private
Network Service Model (L3SM) that can be used for
communication between customers and service providers. Such a model communication between customers and service providers. Such a model
focuses on describing the customer view of the Virtual Private Network focuses on describing the customer view of the Virtual Private Network
(VPN) services and provides an abstracted view of the customer's (VPN) services and provides an abstracted view of the customer's
requested services. That approach limits the usage of the L3SM to the requested services. That approach limits the usage of the L3SM to the
role of a customer service model (as per <xref role of a customer service model (as per <xref target="RFC8309" format="de
target="RFC8309"></xref>).</t> fault"/>).</t>
<t>This document defines a YANG module called the "L3VPN Network Model"
<t>This document defines a YANG module called L3VPN Network Model
(L3NM). The L3NM is aimed at providing a network-centric view of Layer 3 (L3NM). The L3NM is aimed at providing a network-centric view of Layer 3
(L3) VPN services. This data model can be used to facilitate (L3) VPN services. This data model can be used to facilitate
communication between the service orchestrator and the network communication between the service orchestrator and the network
controller/orchestrator by allowing for more network-centric information controller/orchestrator by allowing more network-centric information
to be included. It enables further capabilities such as resource to be included. It enables such additional capabilities as resource
management or serves as a multi-domain orchestration interface, where management, or it serves as a multi-domain orchestration interface where
logical resources (such as route targets or route distinguishers) must logical resources (such as route targets or route distinguishers) must
be coordinated.</t> be coordinated.</t>
<t>This document uses the common VPN YANG module defined in <xref target="
<t>This document uses the common VPN YANG module defined in <xref RFC9181" format="default"/>.</t>
target="I-D.ietf-opsawg-vpn-common"></xref>.</t> <t>This document does not obsolete <xref target="RFC8299" format="default"
/>. These
<t>This document does not obsolete <xref target="RFC8299"></xref>. These
two modules are used for similar objectives but with different scopes two modules are used for similar objectives but with different scopes
and views.</t> and views.</t>
<t>The L3NM YANG module was initially built with a "prune and extend"
<t>The L3NM YANG module was initially built with a prune and extend approach, taking as a starting point the YANG module described in <xref ta
approach, taking as a starting points the YANG module described in <xref rget="RFC8299" format="default"/>. Nevertheless, the L3NM is not defined as an
target="RFC8299"></xref>. Nevertheless, the L3NM is not defined as an augment to the L3SM, because a specific structure is required to meet
augment to L3SM because a specific structure is required to meet
network-oriented L3 needs.</t> network-oriented L3 needs.</t>
<t>Some information captured in the L3SM can be passed by the <t>Some information captured in the L3SM can be passed by the
orchestrator in the L3NM (e.g., customer) or be used to feed some L3NM orchestrator in the L3NM (e.g., customer) or be used to feed some L3NM
attributes (e.g., actual forwarding policies). Also, some information attributes (e.g., actual forwarding policies). Also, some information
captured in the L3SM may be maintained locally within the orchestrator; captured in the L3SM may be maintained locally within the orchestrator,
which is in charge of maintaining the correlation between a customer which is in charge of maintaining the correlation between a customer
view and its network instantiation. Likewise, some information captured view and its network instantiation. Likewise, some information captured
and exposed using the L3NM can feed the service layer (e.g., and exposed using the L3NM can feed the service layer (e.g.,
capabilities) to drive VPN service order handling, and thus the capabilities) to drive VPN service order handling and thus the
L3SM.</t> L3SM.</t>
<t><xref target="RFC8969" sectionFormat="of" section="5.1"/> illustrates h
<t>Section 5.1 of <xref target="RFC8969"></xref> illustrates how the ow the
L3NM can be used within the network management automation L3NM can be used within the network management automation
architecture.</t> architecture.</t>
<t>The L3NM does not attempt to address all deployment cases, especially <t>The L3NM does not attempt to address all deployment cases, especially
those where the L3VPN connectivity is supported through the coordination those where L3VPN connectivity is supported through the coordination
of different VPNs in different underlying networks. More complex of different VPNs in different underlying networks. More complex
deployment scenarios involving the coordination of different VPN deployment scenarios involving the coordination of different VPN
instances and different technologies to provide an end-to-end VPN instances and different technologies to provide end-to-end VPN
connectivity are addressed by complementary YANG modules, e.g., <xref connectivity are addressed by complementary YANG modules, e.g., <xref targ
target="I-D.evenwu-opsawg-yang-composed-vpn"></xref>.</t> et="YANG-Composed-VPN" format="default"/>.</t>
<t>The L3NM focuses on Layer 3 VPNs based on BGP Provider Edges (PEs) as
<t>The L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs as described in <xref target="RFC4026" format="default"/>, <xref target="RFC4
described in <xref target="RFC4026"></xref><xref 110" format="default"/>, and <xref target="RFC4364" format="default"/>; and Mult
target="RFC4110"></xref><xref target="RFC4364"></xref> and Multicast icast
VPNs as described in <xref target="RFC6037"></xref><xref VPNs as described in <xref target="RFC6037" format="default"/> and <xref t
target="RFC6513"></xref>.</t> arget="RFC6513" format="default"/>.</t>
<t>The YANG data model in this document conforms to the Network <t>The YANG data model in this document conforms to the Network
Management Datastore Architecture (NMDA) defined in <xref Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"
target="RFC8342"></xref>.</t> format="default"/>.</t>
</section> </section>
<section anchor="terminology" numbered="true" toc="default">
<section anchor="terminology" title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 14 "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
<xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and "<bcp14>SHOULD NOT</bcp14>",
only when, they appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<t>This document assumes that the reader is familiar with the contents <t>This document assumes that the reader is familiar with the contents
of <xref target="RFC6241"></xref>, <xref target="RFC7950"></xref>, <xref of <xref target="RFC6241" format="default"/>, <xref target="RFC7950" forma
target="RFC8299"></xref>, <xref target="RFC8309"></xref>, and <xref t="default"/>, <xref target="RFC8299" format="default"/>, <xref target="RFC8309"
target="RFC8453"></xref> and uses the terminology defined in those format="default"/>, and <xref target="RFC8453" format="default"/> and uses the
terminology defined in those
documents.</t> documents.</t>
<t>This document uses the term "network model" as defined in <xref target=
<t>This document uses the term "network model" defined in Section 2.1 of "RFC8969" sectionFormat="of" section="2.1"/>.</t>
<xref target="RFC8969"></xref>.</t> <t>The meanings of the symbols in the tree diagrams are defined in <xref t
arget="RFC8340" format="default"/>.</t>
<t>The meaning of the symbols in the tree diagrams is defined in <xref
target="RFC8340"></xref>.</t>
<t>This document makes use of the following terms:</t> <t>This document makes use of the following terms:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Layer 3 VPN Service Model (L3SM):</dt>
<t hangText="Layer 3 VPN Customer Service Model (L3SM):">A YANG <dd>A YANG data model that describes the service requirements of an L3VP
module that describes the service requirements of an L3VPN that N that
interconnects a set of sites from the point of view of the customer. interconnects a set of sites from the point of view of the customer.
The customer service model does not provide details on the service The customer service model does not provide details on the service
provider network. The L3VPN customer service model is defined in provider network. The L3VPN customer service model is defined in
<xref target="RFC8299"></xref>.</t> <xref target="RFC8299" format="default"/>.</dd>
<dt>Layer 3 VPN Network Model (L3NM):</dt>
<t hangText="Layer 3 VPN Service Network Model (L3NM):">A YANG <dd>A YANG data model that describes a VPN service in the service provid
module that describes a VPN service in the service provider network. er network.
It contains information of the service provider network and might It contains information on the service provider network and might
include allocated resources. It can be used by network controllers include allocated resources. It can be used by network controllers
to manage and control the VPN service configuration in the service to manage and control the VPN service configuration in the service
provider network. The YANG module can be consumed by a service provider network. The corresponding YANG module can be used by a servi
orchestrator to request a VPN service to a network controller.</t> ce
orchestrator to request a VPN service to a network controller.</dd>
<t hangText="Service orchestrator:">A functional entity that <dt>Service orchestrator:</dt>
<dd>A functional entity that
interacts with the customer of an L3VPN. The service orchestrator interacts with the customer of an L3VPN. The service orchestrator
interacts with the customer using the L3SM. The service orchestrator interacts with the customer using the L3SM. The service orchestrator
is responsible for the Customer Edge (CE) - Provider Edge (PE) is responsible for the Customer Edge to Provider Edge (CE-PE)
attachment circuits, the PE selection, and requesting the VPN attachment circuits, the PE selection, and requesting the VPN
service to the network controller.</t> service to the network controller.</dd>
<dt>Network orchestrator:</dt>
<t hangText="Network orchestrator:">A functional entity that is <dd>A functional entity that is
hierarchically intermediate between a service orchestrator and hierarchically intermediate between a service orchestrator and
network controllers. A network orchestrator can manage one or network controllers. A network orchestrator can manage one or
several network controllers.</t> several network controllers.</dd>
<dt>Network controller:</dt>
<t hangText="Network controller:">A functional entity responsible <dd>A functional entity responsible
for the control and management of the service provider network.</t> for the control and management of the service provider network.</dd>
<dt>VPN node:</dt>
<t hangText="VPN node:">An abstraction that represents a set of <dd>An abstraction that represents a set of
policies applied on a PE and that belong to a single VPN service. A policies applied on a PE and belonging to a single VPN service. A
VPN service involves one or more VPN nodes. As it is an abstraction, VPN service involves one or more VPN nodes. As it is an abstraction,
the network controller will take on how to implement a VPN node. For the network controller will decide how to implement a VPN node. For
example, typically, in a BGP-based VPN, a VPN node could be mapped example, in a BGP-based VPN, a VPN node could typically be mapped
into a Virtual Routing and Forwarding (VRF).</t> to a Virtual Routing and Forwarding (VRF) instance.</dd>
<dt>VPN network access:</dt>
<t hangText="VPN network access:">An abstraction that represents the <dd>An abstraction that represents the
network interfaces that are associated to a given VPN node. Traffic network interfaces that are associated with a given VPN node. Traffic
coming from the VPN network access belongs to the VPN. The coming from the VPN network access belongs to the VPN. The
attachment circuits (bearers) between CEs and PEs are terminated in attachment circuits (bearers) between CEs and PEs are terminated in
the VPN network access. A reference to the bearer is maintained to the VPN network access. A reference to the bearer is maintained to
allow keeping the link between L3SM and L3NM when both models are allow keeping the link between the L3SM and L3NM when both models are
used in a given deployment.</t> used in a given deployment.</dd>
<dt>VPN site:</dt>
<t hangText="VPN site: ">A VPN customer's location that is connected <dd>A VPN customer's location that is connected
to the service provider network via a CE-PE link, which can access to the service provider network via a CE-PE link, which can access
at least one VPN <xref target="RFC4176"></xref>.</t> at least one VPN <xref target="RFC4176" format="default"/>.</dd>
<dt>VPN service provider:</dt>
<t hangText="VPN service provider:">A service provider that offers <dd>A service provider that offers
VPN-related services <xref target="RFC4176"></xref>.</t> VPN-related services <xref target="RFC4176" format="default"/>.</dd>
<dt>Service provider network:</dt>
<t hangText="Service provider network:">A network that is able to <dd>A network that is able to
provide VPN-related services.</t> provide VPN-related services.</dd>
</list></t> </dl>
<t>This document is aimed at modeling BGP PE-based VPNs in a service
<t>The document is aimed at modeling BGP PE-based VPNs in a service provider network, so the terms defined in <xref target="RFC4026" format="d
provider network, so the terms defined in <xref target="RFC4026"></xref> efault"/>
and <xref target="RFC4176"></xref> are used.</t> and <xref target="RFC4176" format="default"/> are used in this document as
well.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Acronyms and Abbreviations</name>
<t>The following acronyms and abbreviations are used in this document:</t>
<dl newline="false" spacing="compact" indent="8">
<dt>ACL</dt>
<dd>Access Control List</dd>
<dt>AS</dt>
<dd>Autonomous System</dd>
<dt>ASM</dt>
<dd>Any-Source Multicast</dd>
<dt>ASN</dt>
<dd>AS Number</dd>
<dt>BFD</dt>
<dd>Bidirectional Forwarding Detection</dd>
<dt>BGP</dt>
<dd>Border Gateway Protocol</dd>
<dt>BSR</dt>
<dd>Bootstrap Router</dd>
<dt>CE</dt>
<dd>Customer Edge</dd>
<dt>CsC</dt>
<dd>Carriers' Carriers</dd>
<dt>IGMP</dt>
<dd>Internet Group Management Protocol</dd>
<dt>L3NM</dt>
<dd>L3VPN Network Model</dd>
<dt>L3SM</dt>
<dd>L3VPN Service Model</dd>
<dt>L3VPN</dt>
<dd>Layer 3 Virtual Private Network</dd>
<dt>MLD</dt>
<dd>Multicast Listener Discovery</dd>
<dt>MSDP</dt>
<dd>Multicast Source Discovery Protocol</dd>
<dt>MVPN</dt>
<dd>Multicast VPN</dd>
<dt>NAT</dt>
<dd>Network Address Translation</dd>
<dt>OAM</dt>
<dd>Operations, Administration, and Maintenance</dd>
<dt>OSPF</dt>
<dd>Open Shortest Path First</dd>
<dt>PE</dt>
<dd>Provider Edge</dd>
<dt>PIM</dt>
<dd>Protocol Independent Multicast</dd>
<dt>QoS</dt>
<dd>Quality of Service</dd>
<dt>RD</dt>
<dd>Route Distinguisher</dd>
<dt>RP</dt>
<dd>Rendezvous Point</dd>
<dt>RT</dt>
<dd>Route Target</dd>
<dt>SA</dt>
<dd>Security Association</dd>
<dt>SSM</dt>
<dd>Source-Specific Multicast</dd>
<dt>VPN</dt>
<dd>Virtual Private Network</dd>
<dt>VRF</dt>
<dd>Virtual Routing and Forwarding</dd>
</dl>
<section title="Acronyms">
<t>The following acronyms are used in the document:<?rfc subcompact="yes"
?></t>
<t><list hangIndent="8" style="hanging">
<t hangText="ACL">Access Control List</t>
<t hangText="AS">Autonomous System</t>
<t hangText="ASM">Any-Source Multicast</t>
<t hangText="ASN">AS Number</t>
<t hangText="BSR">Bootstrap Router</t>
<t hangText="BFD">Bidirectional Forwarding Detection</t>
<t hangText="BGP">Border Gateway Protocol</t>
<t hangText="CE">Customer Edge</t>
<t hangText="CsC">Carriers' Carriers</t>
<t hangText="IGMP">Internet Group Management Protocol</t>
<t hangText="L3VPN">Layer 3 Virtual Private Network</t>
<t hangText="L3SM">L3VPN Service Model</t>
<t hangText="L3NM">L3VPN Network Model</t>
<t hangText="MLD">Multicast Listener Discovery</t>
<t hangText="MSDP">Multicast Source Discovery Protocol</t>
<t hangText="MVPN">Multicast VPN</t>
<t hangText="NAT">Network Address Translation</t>
<t hangText="OAM">Operations, Administration, and Maintenance</t>
<t hangText="OSPF">Open Shortest Path First</t>
<t hangText="PE">Provider Edge</t>
<t hangText="PIM">Protocol Independent Multicast</t>
<t hangText="QoS">Quality of Service</t>
<t hangText="RD">Route Distinguisher</t>
<t hangText="RP">Rendezvous Point</t>
<t hangText="RT">Route Target</t>
<t hangText="SA">Security Association</t>
<t hangText="SSM">Source-Specific Multicast</t>
<t hangText="VPN">Virtual Private Network</t>
<t hangText="VRF">Virtual Routing and Forwarding</t>
</list></t>
<t><?rfc subcompact="no" ?></t>
</section> </section>
<section anchor="ref" numbered="true" toc="default">
<section anchor="ref" title="L3NM Reference Architecture"> <name>L3NM Reference Architecture</name>
<t><xref target="xml_happy"></xref> depicts the reference architecture <t><xref target="xml_happy" format="default"/> depicts the reference archi
tecture
for the L3NM. The figure is an expansion of the architecture presented for the L3NM. The figure is an expansion of the architecture presented
in Section 5 of <xref target="RFC8299"></xref>; it decomposes the box in <xref target="RFC8299" sectionFormat="of" section="5"/>; it decomposes the box
marked "orchestration" in that section into three separate functional marked "orchestration" in that section into three separate functional
components: Service Orchestration, Network Orchestration, and Domain components: service orchestration, network orchestration, and domain
Orchestration.</t> orchestration.</t>
<t>Although some deployments may choose to construct a monolithic <t>Although some deployments may choose to construct a monolithic
orchestration component (covering both service and network matters), orchestration component (covering both service and network matters),
this document advocates for a clear separation between service and this document advocates for a clear separation between service and
network orchestration components for the sake of better flexibility. network orchestration components for the sake of better flexibility.
Such design adheres to the L3VPN reference architecture defined in Such a design adheres to the L3VPN reference architecture defined in
Section 1.3 of <xref target="RFC4176"></xref>. This separation relies <xref target="RFC4176" sectionFormat="of" section="1.3"/>. This separation
relies
upon a dedicated communication interface between these components and upon a dedicated communication interface between these components and
appropriate YANG modules that reflect network-related information. Such appropriate YANG modules that reflect network-related information. Such
information is hidden to customers.</t> information is hidden from customers.</t>
<t>The intelligence for translating customer-facing information into <t>The intelligence for translating customer-facing information into
network-centric one (and vice versa) is implementation specific.</t> network-centric information (and vice versa) is implementation specific.</
t>
<t>The terminology from <xref target="RFC8309"></xref> is introduced to <t>The terminology from <xref target="RFC8309" format="default"/> is used
here to
show the distinction between the customer service model, the service show the distinction between the customer service model, the service
delivery model, the network configuration model, and the device delivery model, the network configuration model, and the device
configuration model. In that context, the "Domain Orchestration" and configuration model. In that context, the "domain orchestration" and
"Config Manager" roles may be performed by "Controllers".</t> "config manager" roles may be performed by "controllers".</t>
<figure anchor="xml_happy">
<name>L3NM Reference Architecture</name>
<artwork align="center" name="" type="ascii-art" alt=""><![CDATA[
+---------------+
| Customer |
+-------+-------+
Customer Service Model |
(e.g., 'l3vpn-svc') |
+-------+-------+
| Service |
| Orchestration |
+-------+-------+
Service Delivery Model |
'l3vpn-ntw' |
+-------+-------+
| Network |
| Orchestration |
+-------+-------+
Network Configuration Model |
+-----------+-----------+
| |
+--------+------+ +--------+------+
| Domain | | Domain |
| Orchestration | | Orchestration |
+---+-----------+ +--------+------+
Device | | |
Configuration | | |
Model | | |
+----+----+ | |
| Config | | |
| Manager | | |
+----+----+ | |
| | |
| NETCONF/CLI..................
| | |
+------------------------------------------------+
Network
<figure align="center" anchor="xml_happy" NETCONF: Network Configuration Protocol
title="L3NM Reference Architecture"> CLI: Command-Line Interface
<artwork align="center"><![CDATA[ +---- ]]></artwork>
-----------+
| Customer |
+-------+-------+
Customer Service Model |
e.g., l3vpn-svc |
+-------+-------+
| Service |
| Orchestration |
+-------+-------+
Service Delivery Model |
l3vpn-ntw |
+-------+-------+
| Network |
| Orchestration |
+-------+-------+
Network Configuration Model |
+-----------+-----------+
| |
+--------+------+ +--------+------+
| Domain | | Domain |
| Orchestration | | Orchestration |
+---+-----------+ +--------+------+
Device | | |
Configuration | | |
Model | | |
+----+----+ | |
| Config | | |
| Manager | | |
+----+----+ | |
| | |
| NETCONF/CLI..................
| | |
+------------------------------------------------+
Network
]]></artwork>
</figure> </figure>
<t>The customer may use a variety of means to request a service that may <t>The customer may use a variety of means to request a service that may
trigger the instantiation of an L3NM. The customer may use the L3SM or trigger the instantiation of an L3NM. The customer may use the L3SM or
more abstract models to request a service that relies upon an L3VPN more abstract models to request a service that relies upon an L3VPN
service. For example, the customer may supply an IP Connectivity service. For example, the customer may supply an IP Connectivity
Provisioning Profile (CPP) that characterizes the requested service Provisioning Profile (CPP) that characterizes the requested service
<xref target="RFC7297"></xref>, an enhanced VPN (VPN+) service <xref <xref target="RFC7297" format="default"/>, an enhanced VPN (VPN+) service
target="I-D.ietf-teas-enhanced-vpn"></xref>, or an IETF network slice <xref target="I-D.ietf-teas-enhanced-vpn" format="default"/>, or an IETF network
service <xref target="I-D.ietf-teas-ietf-network-slices"></xref>.</t> slice
service <xref target="Network-Slices-Framework" format="default"/>.</t>
<t>Note also that both the L3SM and the L3NM may be used in the context <t>Note also that both the L3SM and the L3NM may be used in the context
of the Abstraction and Control of TE Networks (ACTN) Framework <xref of the Abstraction and Control of TE Networks (ACTN) framework <xref targe
target="RFC8453"></xref>. <xref target="l3sm_actn"></xref> shows the t="RFC8453" format="default"/>. <xref target="l3sm_actn" format="default"/> show
s the
Customer Network Controller (CNC), the Multi-Domain Service Coordinator Customer Network Controller (CNC), the Multi-Domain Service Coordinator
(MDSC), and the Provisioning Network Controller (PNC) components and the (MDSC), the Provisioning Network Controller (PNC) components, and the
interfaces where L3SM/L3NM are used.</t> interfaces where the L3SM and L3NM are used.</t>
<figure anchor="l3sm_actn">
<figure align="center" anchor="l3sm_actn" <name>L3SM and L3NM in the Context of the ACTN</name>
title="L3SM and L3NM in the Context of ACTN"> <artwork align="center" name="" type="ascii-art" alt=""><![CDATA[
<artwork align="center"><![CDATA[ +----------------------- +----------------------------------+
-----------+ | Customer |
| Customer | | +-----------------------------+ |
| +-----------------------------+ | | | CNC | |
| | CNC | | | +-----------------------------+ |
| +-----------------------------+ | +----+-----------------------+-----+
+----+-----------------------+-----+ | |
| | | L3SM | L3SM
| L3SM | L3SM | |
| | +---------+---------+ +---------+---------+
+---------+---------+ +---------+---------+ | MDSC | | MDSC |
| MDSC | | MDSC | | +---------------+ | | (parent) |
| +---------------+ | | (parent) | | | Service | | +---------+---------+
| | Service | | +---------+---------+ | | Orchestration | | |
| | Orchestration | | | | +-------+-------+ | | L3NM
| +-------+-------+ | | L3NM | | | |
| | | | | | L3NM | +---------+---------+
| | L3NM | +---------+---------+ | | | | MDSC |
| | | | MDSC | | +-------+-------+ | | (child) |
| +-------+-------+ | | (child) | | | Network | | +---------+---------+
| | Network | | +---------+---------+ | | Orchestration | | |
| | Orchestration | | | | +---------------+ | |
| +---------------+ | | +---------+---------+ |
+---------+---------+ | | |
| | | Network Configuration |
| Network Configuration | | |
| | +------------+-------+ +---------+------------+
+------------+-------+ +---------+------------+ | Domain | | Domain |
| Domain | | Domain | | Controller | | Controller |
| Controller | | Controller | | +---------+ | | +---------+ |
| +---------+ | | +---------+ | | | PNC | | | | PNC | |
| | PNC | | | | PNC | | | +---------+ | | +---------+ |
| +---------+ | | +---------+ | +------------+-------+ +---------+------------+
+------------+-------+ +---------+------------+ | |
| | | Device Configuration |
| Device Configuration | | |
| | +----+---+ +----+---+
+----+---+ +----+---+ | Device | | Device |
| Device | | Device | +--------+ +--------+
+--------+ +--------+ ]]></artwork>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="relation" numbered="true" toc="default">
<section anchor="relation" title="Relation with other YANG Models"> <name>Relationship to Other YANG Data Models</name>
<t>The "ietf-vpn-common" module <xref <t>The "ietf-vpn-common" module <xref target="RFC9181" format="default"/>
target="I-D.ietf-opsawg-vpn-common"></xref> includes a set of includes a set of
identities, types, and groupings that are meant to be reused by identities, types, and groupings that are meant to be reused by
VPN-related YANG modules independently of the layer (e.g., Layer 2, VPN-related YANG modules independently of the layer (e.g., Layer 2,
Layer 3) and the type of the module (e.g., network model, service model) Layer 3) and the type of the module (e.g., network model, service model),
including future revisions of existing models (e.g., <xref including future revisions of existing models (e.g., <xref target="RFC8299
target="RFC8299"></xref> or <xref target="RFC8466"></xref>). The L3NM " format="default"/> or <xref target="RFC8466" format="default"/>). The L3NM
reuses these common types and groupings.</t> reuses these common types and groupings.</t>
<t>In order to avoid data duplication and to ease passing data between <t>In order to avoid data duplication and to ease passing data between
layers when required (service layer to network layer and vice versa), layers when required (service layer to network layer and vice versa),
early versions of the L3NM reused many of the data nodes that are early versions of the L3NM reused many of the data nodes that are
defined in <xref target="RFC8299"></xref>. Nevertheless, that approach defined in <xref target="RFC8299" format="default"/>. Nevertheless, that a pproach
was abandoned in favor of the "ietf-vpn-common" module because that was abandoned in favor of the "ietf-vpn-common" module because that
initial design was interpreted as if the deployment of L3NM depends on initial design was interpreted as if the deployment of the L3NM depends on the
L3SM, while this is not the case. For example, a service provider may L3SM, while this is not the case. For example, a service provider may
decide to use the L3NM to build its L3VPN services without exposing the decide to use the L3NM to build its L3VPN services without exposing the
L3SM.</t> L3SM.</t>
<t>As discussed in <xref target="ref" format="default"/>, the L3NM is mean
<t>As discussed in <xref target="ref"></xref>, the L3NM is meant to t to
manage L3VPN services within a service provider network. The module manage L3VPN services within a service provider network. The module
provides a network view of the service. Such a view is only visible provides a network view of the service. Such a view is only visible
within the service provider and is not exposed outside (to customers, within the service provider and is not exposed outside (to customers,
for example). The following discusses how L3NM interfaces with other for example). The items below discuss how the L3NM interfaces with other Y
YANG modules:</t> ANG modules:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>L3SM:</dt>
<t hangText="L3SM:">L3NM is not a customer service model.<vspace <dd>
blankLines="1" />The internal view of the service (i.e., L3NM) may <t>The L3NM is not a customer service model.</t>
be mapped to an external view which is visible to customers: L3VPN <t>The internal view of the service (i.e., the L3NM) may
Service YANG data Model (L3SM) <xref target="RFC8299"></xref>. be mapped to an external view that is visible to customers: the L3VPN
<vspace blankLines="1" />The L3NM can be fed with inputs that are Service Model (L3SM) <xref target="RFC8299" format="default"/>.
requested by customers, typically, relying upon an L3SM template. </t>
<t>The L3NM can be fed with inputs that are
requested by customers. Such requests typically rely upon an L3SM temp
late.
Concretely, some parts of the L3SM module can be directly mapped Concretely, some parts of the L3SM module can be directly mapped
into L3NM while other parts are generated as a function of the to the L3NM, while other parts are generated as a function of the
requested service and local guidelines. Some other parts are local requested service and local guidelines. Some other parts are local
to the service provider and do not map directly to L3SM.<vspace to the service provider and do not map directly to the L3SM.</t>
blankLines="1" />Note that the use of L3NM within a service provider <t>Note that using the L3NM within a service provider does not
does not assume nor preclude exposing the VPN service via the L3SM. assume, nor does it preclude, exposing the VPN service via the L3SM.
This is deployment-specific. Nevertheless, the design of L3NM tries This is deployment specific. Nevertheless, the design of the L3NM trie
s
to align as much as possible with the features supported by the L3SM to align as much as possible with the features supported by the L3SM
to ease grafting both L3NM and L3SM for the sake of highly automated to ease the grafting of both the L3NM and the L3SM for the sake of hig hly automated
VPN service provisioning and delivery.</t> VPN service provisioning and delivery.</t>
</dd>
<t hangText="Network Topology Modules:">An L3VPN involves nodes that <dt>Network Topology Modules:</dt>
<dd>An L3VPN involves nodes that
are part of a topology managed by the service provider network. The are part of a topology managed by the service provider network. The
topology can be represented using the network topology YANG module topology can be represented using the network topology YANG module
defined in <xref target="RFC8345"></xref> or its extension such as a defined in <xref target="RFC8345" format="default"/> or its extension,
User-Network Interface (UNI) topology module (e.g., <xref such as a
target="I-D.ogondio-opsawg-uni-topology"></xref>).</t> network YANG module for Service Attachment Points (SAPs) <xref target=
"YANG-SAPs" format="default"/>.</dd>
<t hangText="Device Modules:">L3NM is not a device model. <vspace <dt>Device Modules:</dt>
blankLines="1" />Once a global VPN service is captured by means of <dd>
<t>The L3NM is not a device model.</t>
<t>Once a global VPN service is captured by means of the
L3NM, the actual activation and provisioning of the VPN service will L3NM, the actual activation and provisioning of the VPN service will
involve a variety of device modules to tweak the required functions involve a variety of device modules to tweak the required functions
for the delivery of the service. These functions are supported by for the delivery of the service. These functions are supported by
the VPN nodes and can be managed using device YANG modules. A the VPN nodes and can be managed using device YANG modules. A
non-comprehensive list of such device YANG modules is provided non-comprehensive list of such device YANG modules is provided
below:<list style="symbols"> below:</t>
<t>Routing management <xref target="RFC8349"></xref>.</t> <ul spacing="normal">
<li>Routing management <xref target="RFC8349" format="default"/>.</l
<t>BGP <xref target="I-D.ietf-idr-bgp-model"></xref>.</t> i>
<li>BGP <xref target="I-D.ietf-idr-bgp-model" format="default"/>.</l
<t>PIM <xref target="I-D.ietf-pim-yang"></xref>.</t> i>
<li>PIM <xref target="PIM-YANG" format="default"/>.</li>
<t>NAT management <xref target="RFC8512"></xref>.</t> <li>NAT management <xref target="RFC8512" format="default"/>.</li>
<li>QoS management <xref target="I-D.ietf-rtgwg-qos-model" format="d
<t>QoS management <xref efault"/>.</li>
target="I-D.ietf-rtgwg-qos-model"></xref>.</t> <li>ACLs <xref target="RFC8519" format="default"/>.</li>
</ul>
<!----> <t>How the L3NM is used to derive
device-specific actions is implementation specific.</t>
<t>ACLs <xref target="RFC8519"></xref>.</t> </dd>
</list><vspace blankLines="1" />How L3NM is used to derive </dl>
device-specific actions is implementation-specific.</t>
</list></t>
</section> </section>
<section anchor="Use_of_the_data_model" numbered="true" toc="default">
<section anchor="Use_of_the_data_model" <name>Sample Uses of the L3NM Data Model</name>
title="Sample Uses of the L3NM Data Model"> <t>This section provides a non-exhaustive list of examples that illustrate
<t>This section provides a non-exhaustive list of examples to illustrate
contexts where the L3NM can be used.</t> contexts where the L3NM can be used.</t>
<section anchor="enterprise_services" numbered="true" toc="default">
<section anchor="enterprise_services" <name>Enterprise Layer 3 VPN Services</name>
title="Enterprise Layer 3 VPN Services">
<t>Enterprise L3VPNs are one of the most demanded services for <t>Enterprise L3VPNs are one of the most demanded services for
carriers, and therefore, L3NM can be useful to automate the carriers; therefore, L3NM can be useful for automating the
provisioning and maintenance of these VPNs. Templates and batch provisioning and maintenance of these VPNs. Templates and batch
processes can be built, and as a result many parameters are needed for processes can be built, and as a result many parameters are needed for
the creation from scratch of a VPN that can be abstracted to the upper the creation from scratch of a VPN that can be abstracted to the upper
Software-Defined Networking (SDN) <xref target="RFC7149"></xref><xref Software-Defined Networking (SDN) layer <xref target="RFC7149" format="d
target="RFC7426"></xref> layer, but some manual intervention will efault"/> <xref target="RFC7426" format="default"/>, but some manual interventio
n will
still be required.</t> still be required.</t>
<t>A common function that is supported by VPNs is the addition or <t>A common function that is supported by VPNs is the addition or
removal of VPN nodes. Workflows can use the L3NM in these scenarios to removal of VPN nodes. Workflows can use the L3NM in these scenarios to
add or prune nodes from the network data model as required.</t> add or prune nodes from the network data model as required.</t>
</section> </section>
<section anchor="mdrmanagement" numbered="true" toc="default">
<section anchor="mdrmanagement" title="Multi-Domain Resource Management"> <name>Multi-Domain Resource Management</name>
<t>The implementation of L3VPN services which span across <t>The implementation of L3VPN services that span
administratively separated domains (i.e., that are under the administratively separated domains (i.e., that are under the
administration of different management systems or controllers) administration of different management systems or controllers)
requires some network resources to be synchronized between systems. requires some network resources to be synchronized between systems.
Particularly, resources must be adequately managed in each domain to Particularly, resources must be adequately managed in each domain to
avoid broken configuration.</t> avoid broken configurations.</t>
<t>For example, route targets (RTs) shall be synchronized between PEs. <t>For example, route targets (RTs) shall be synchronized between PEs.
When all PEs are controlled by the same management system, RT When all PEs are controlled by the same management system, RT
allocation can be performed by that management system. In cases where allocation can be performed by that management system. In cases where
the service spans across multiple management systems, the task of the service spans multiple management systems, the task of
allocating RTs has to be aligned across the domains, therefore, the allocating RTs has to be aligned across the domains; therefore, the
network model must provide a way to specify RTs. In addition, route network model must provide a way to specify RTs. In addition, route
distinguishers (RDs) must also be synchronized to avoid collisions in distinguishers (RDs) must also be synchronized to avoid collisions of
RD allocation between separate management systems. An incorrect RD allocations between separate management systems. An incorrect
allocation might lead to the same RD and IP prefixes being exported by allocation might lead to the same RD and IP prefixes being exported by
different PEs.</t> different PEs.</t>
</section> </section>
<section anchor="ms_management" numbered="true" toc="default">
<section anchor="ms_management" title="Management of Multicast Services"> <name>Management of Multicast Services</name>
<t>Multicast services over L3VPN can be implemented using dual PIM <t>Multicast services over L3VPNs can be implemented using dual PIM
MVPNs (also known as, Draft Rosen model) <xref MVPNs (also known as the draft-rosen model) <xref target="RFC6037" forma
target="RFC6037"></xref> or Multiprotocol BGP (MP-BGP)-based MVPNs t="default"/>
<xref target="RFC6513"></xref><xref target="RFC6514"></xref>. Both or MVPNs based on Multiprotocol BGP (MP-BGP) <xref target="RFC6513" form
at="default"/>
<xref target="RFC6514" format="default"/>. Both
methods are supported and equally effective, but the main difference methods are supported and equally effective, but the main difference
is that MBGP-based MVPN does not require multicast configuration on is that MP-BGP-based MVPNs do not require multicast configuration on
the service provider network. MBGP MVPNs employ the intra-autonomous the service provider network. MP-BGP MVPNs employ the intra-AS BGP contr
system BGP control plane and PIM sparse mode as the data plane. The ol plane and PIM Sparse Mode <xref target="RFC7761"/> as the data plane. The
PIM state information is maintained between PEs using the same PIM state information is maintained between PEs using the same
architecture that is used for unicast VPNs.</t> architecture that is used for unicast VPNs.</t>
<t>On the other hand, <xref target="RFC6037" format="default"/> has limi
<t>On the other hand, <xref target="RFC6037"></xref> has limitations tations,
such as reduced options for transport, control plane scalability, such as reduced options for transport, control plane scalability,
availability, operational inconsistency, and the need of maintaining availability, operational inconsistency, and the need to maintain
state in the backbone. Because of these limitations, MBGP MVPN is the state in the backbone. Because of these limitations, MP-BGP MVPNs provid
e the
architectural model that has been taken as the base for implementing architectural model that has been taken as the base for implementing
multicast service in L3VPNs. In this scenario, BGP is used to multicast services in L3VPNs. In this scenario, BGP is used to
auto-discover MVPN PE members and the customer PIM signaling is sent autodiscover MVPN PE members and the customer PIM signaling is sent
across the provider's core through MP-BGP. The multicast traffic is across the provider's core through MP-BGP. The multicast traffic is
transported on MPLS P2MP LSPs.</t> transported on MPLS Point-to-Multipoint (P2MP) Label Switched Paths (LSP s).</t>
</section> </section>
</section> </section>
<section anchor="YANG_explanation" numbered="true" toc="default">
<section anchor="YANG_explanation" <name>Description of the L3NM YANG Module</name>
title="Description of the L3NM YANG Module"> <t>The L3NM ("ietf-l3vpn-ntw") is defined to manage L3VPNs in a service
<t>The L3NM ('ietf-l3vpn-ntw') is defined to manage L3VPNs in a service provider network. In particular, the "ietf-l3vpn-ntw" module can be used
provider network. In particular, the 'ietf-l3vpn-ntw' module can be used
to create, modify, and retrieve L3VPN services of a network.</t> to create, modify, and retrieve L3VPN services of a network.</t>
<t>The full tree diagram of the module can be generated using the <t>The full tree diagram of the module can be generated using the
"pyang" tool <xref target="PYANG"></xref>. That tree is not included "pyang" tool <xref target="PYANG" format="default"/>. That tree is not inc
here because it is too long (Section 3.3 of <xref luded
target="RFC8340"></xref>). Instead, subtrees are provided for the here because it is too long (<xref target="RFC8340" sectionFormat="of" sec
tion="3.3"/>). Instead, subtrees are provided for the
reader's convenience.</t> reader's convenience.</t>
<section anchor="structure_model" numbered="true" toc="default">
<section anchor="structure_model" <name>Overall Structure of the Module</name>
title="Overall Structure of the Module"> <t>The "ietf-l3vpn-ntw" module uses two main containers:
<t>The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-profiles' and 'vpn-services' (see <xref target="ietf-l3vpn-ntw_tree
'vpn-services' and 'vpn-profiles' (see <xref " format="default"/>).</t>
target="ietf-l3vpn-ntw_tree"></xref>).</t>
<t>The 'vpn-profiles' container is used by the provider to maintain a <t>The 'vpn-profiles' container is used by the provider to maintain a
set of common VPN profiles that apply to one or several VPN services set of common VPN profiles that apply to one or several VPN services
(<xref target="vpn_profiles"></xref>).</t> (<xref target="vpn_profiles" format="default"/>).</t>
<t>The 'vpn-services' container maintains the set of VPN services <t>The 'vpn-services' container maintains the set of VPN services
managed within the service provider network. 'vpn-service' is the data managed within the service provider network. The 'vpn-service' is the da
structure that abstracts a VPN service (<xref ta
target="vpn_service"></xref>).</t> structure that abstracts a VPN service (<xref target="vpn_service" forma
t="default"/>).</t>
<figure align="center" anchor="ietf-l3vpn-ntw_tree" <figure anchor="ietf-l3vpn-ntw_tree">
title="Overall L3NM Tree Structure"> <name>Overall L3NM Tree Structure</name>
<artwork align="center"><![CDATA[module: ietf-l3vpn-ntw <sourcecode name="" type="yangtree"><![CDATA[module: ietf-l3vpn-ntw
+--rw l3vpn-ntw +--rw l3vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| ... | ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
... ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ]]></artwork> ...
]]></sourcecode>
</figure> </figure>
<t>Some of the data nodes are keyed by the address family. For the
<t></t> sake of data representation compactness, it is <bcp14>RECOMMENDED</bcp14
> to use the
<t>Some of the data nodes are keyed by the address-family. For the dual-stack address family for data nodes that have the same value for
sake of data representation compactness, It is RECOMMENDED to use the both IPv4 and IPv6. If, for some reason, a data node is present for
dual-stack address-family for data nodes that have the same value for
both IPv4 and IPv6. If, for some reasons, a data node is present for
both dual-stack and IPv4 (or IPv6), the value that is indicated under both dual-stack and IPv4 (or IPv6), the value that is indicated under
dual-stack takes precedence over the one that is indicated under IPv4 dual-stack takes precedence over the value that is indicated under IPv4
(or IPv6).</t> (or IPv6).</t>
</section> </section>
<section anchor="vpn_profiles" numbered="true" toc="default">
<section anchor="vpn_profiles" title="VPN Profiles"> <name>VPN Profiles</name>
<t>The 'vpn-profiles' container (<xref <t>The 'vpn-profiles' container (<xref target="vpn_profiles_tree" format
target="vpn_profiles_tree"></xref>) allows the VPN service provider to ="default"/>) allows the VPN service provider to
define and maintain a set of VPN profiles <xref define and maintain a set of VPN profiles <xref target="RFC9181" format=
target="I-D.ietf-opsawg-vpn-common"></xref> that apply to one or "default"/> that apply to one or
several VPN services.</t> several VPN services.</t>
<figure anchor="vpn_profiles_tree">
<t><figure align="center" anchor="vpn_profiles_tree" <name>VPN Profiles Subtree Structure</name>
title="VPN Profiles Subtree Structure"> <sourcecode name="" type="yangtree"><![CDATA[ +--rw l3vpn-ntw
<artwork align="center"><![CDATA[ +--rw l3vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| +--rw valid-provider-identifiers | +--rw valid-provider-identifiers
| +--rw external-connectivity-identifier* [id] | +--rw external-connectivity-identifier* [id]
| | {external-connectivity}? | | {external-connectivity}?
| | +--rw id string | | +--rw id string
| +--rw encryption-profile-identifier* [id] | +--rw encryption-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw qos-profile-identifier* [id] | +--rw qos-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw bfd-profile-identifier* [id] | +--rw bfd-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw forwarding-profile-identifier* [id] | +--rw forwarding-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw routing-profile-identifier* [id] | +--rw routing-profile-identifier* [id]
| +--rw id string | +--rw id string
+--rw vpn-services +--rw vpn-services
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>This document does not make any assumption about the exact <t>This document does not make any assumption about the exact
definition of these profiles. The exact definition of the profiles is definition of these profiles. The exact definition of the profiles is
local to each VPN service provider. The model only includes an local to each VPN service provider. The model only includes an
identifier to these profiles in order to facilitate identifying and identifier for these profiles in order to facilitate identifying and
binding local policies when building a VPN service. As shown in <xref binding local policies when building a VPN service. As shown in <xref ta
target="vpn_profiles_tree"></xref>, the following identifiers can be rget="vpn_profiles_tree" format="default"/>, the following identifiers can be
included:<list style="hanging"> included:</t>
<t hangText="'external-connectivity-identifier':">This identifier <dl newline="false" spacing="normal">
<dt>'external-connectivity-identifier':</dt>
<dd>This identifier
refers to a profile that defines the external connectivity refers to a profile that defines the external connectivity
provided to a VPN service (or a subset of VPN sites). An external provided to a VPN service (or a subset of VPN sites). External
connectivity may be an access to the Internet or a restricted connectivity may be access to the Internet or restricted
connectivity such as access to a public/private cloud.</t> connectivity, such as access to a public/private cloud.</dd>
<dt>'encryption-profile-identifier':</dt>
<t hangText="'encryption-profile-identifier':">An encryption <dd>An encryption
profile refers to a set of policies related to the encryption profile refers to a set of policies related to the encryption
schemes and setup that can be applied when building and offering a schemes and setup that can be applied when building and offering a
VPN service.</t> VPN service.</dd>
<dt>'qos-profile-identifier':</dt>
<t hangText="'qos-profile-identifier':">A Quality of Service (QoS) <dd>A Quality of Service (QoS)
profile refers to a set of policies such as classification, profile refers to a set of policies, such as classification,
marking, and actions (e.g., <xref target="RFC3644"></xref>).</t> marking, and actions (e.g., <xref target="RFC3644" format="default"/
>).</dd>
<t hangText="'bfd-profile-identifier':">A Bidirectional Forwarding <dt>'bfd-profile-identifier':</dt>
Detection (BFD) profile refers to a set of BFD <xref <dd>A Bidirectional Forwarding
target="RFC5880"></xref> policies that can be invoked when Detection (BFD) profile refers to a set of BFD policies <xref target
building a VPN service.</t> ="RFC5880" format="default"/> that can be invoked when
building a VPN service.</dd>
<t hangText="'forwarding-profile-identifier':">A forwarding <dt>'forwarding-profile-identifier':</dt>
<dd>A forwarding
profile refers to the policies that apply to the forwarding of profile refers to the policies that apply to the forwarding of
packets conveyed within a VPN. Such policies may consist, for packets conveyed within a VPN. Such policies may consist, for
example, of applying Access Control Lists (ACLs).</t> example, of applying Access Control Lists (ACLs).</dd>
<dt>'routing-profile-identifier':</dt>
<t hangText="'routing-profile-identifier':">A routing profile <dd>A routing profile
refers to a set of routing policies that will be invoked (e.g., refers to a set of routing policies that will be invoked (e.g.,
BGP policies) when delivering the VPN service.</t> BGP policies) when delivering the VPN service.</dd>
</list></t> </dl>
<t></t>
</section> </section>
<section anchor="vpn_service" numbered="true" toc="default">
<section anchor="vpn_service" title="VPN Services"> <name>VPN Services</name>
<t>The 'vpn-service' is the data structure that abstracts a VPN <t>The 'vpn-service' is the data structure that abstracts a VPN
service in the service provider network. Each 'vpn-service' is service in the service provider network. Each 'vpn-service' is
uniquely identified by an identifier: 'vpn-id'. Such 'vpn-id' is only uniquely identified by an identifier: 'vpn-id'. Such a 'vpn-id' is only
meaningful locally (e.g., the network controller). The subtree of the meaningful locally (e.g., the network controller). The subtree of the
'vpn-services' is shown in <xref 'vpn-services' is shown in <xref target="vpn-service_tree" format="defau
target="vpn-service_tree"></xref>.</t> lt"/>.</t>
<figure anchor="vpn-service_tree">
<t><figure align="center" anchor="vpn-service_tree" <name>VPN Services Subtree Structure</name>
title="VPN Services Subtree Structure"> <sourcecode name="" type="yangtree"><![CDATA[ +--rw l3vpn-ntw
<artwork align="center"><![CDATA[ +--rw l3vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| ... | ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
+--rw vpn-id vpn-common:vpn-id +--rw vpn-id vpn-common:vpn-id
+--rw vpn-name? string +--rw vpn-name? string
+--rw vpn-description? string +--rw vpn-description? string
+--rw customer-name? string +--rw customer-name? string
+--rw parent-service-id? vpn-common:vpn-id +--rw parent-service-id? vpn-common:vpn-id
+--rw vpn-type? identityref +--rw vpn-type? identityref
skipping to change at line 906 skipping to change at line 683
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw vpn-instance-profiles +--rw vpn-instance-profiles
| ... | ...
+--rw underlay-transport +--rw underlay-transport
| +-- (type)? | +-- (type)?
| +--:(abstract) | +--:(abstract)
| | +-- transport-instance-id? string | | +--rw transport-instance-id? string
| | +--rw instance-type? identityref
| +--:(protocol) | +--:(protocol)
| +-- protocol* identityref | +--rw protocol* identityref
+--rw external-connectivity +--rw external-connectivity
| {external-connectivity} | {vpn-common:external-connectivity}?
| +--rw (profile)? | +--rw (profile)?
| +--:(profile) | +--:(profile)
| +--rw profile-name? leafref | +--rw profile-name? leafref
+--rw vpn-nodes +--rw vpn-nodes
... ...
]]></sourcecode>
]]></artwork> </figure>
</figure></t> <t>The descriptions of the VPN service data nodes that are depicted in
<xref target="vpn-service_tree" format="default"/> are as follows:</t>
<t>The description of the VPN service data nodes that are depicted in <dl newline="false" spacing="normal">
<xref target="vpn-service_tree"></xref> are as follows:<list <dt>'vpn-id':</dt>
style="hanging"> <dd>An identifier that is used to uniquely
<t hangText="'vpn-id':">Is an identifier that is used to uniquely identify the L3VPN service within the L3NM scope.</dd>
identify the L3VPN service within L3NM scope.</t> <dt>'vpn-name':</dt>
<dd>Associates a name with the service in
<t hangText="'vpn-name':">Associates a name with the service in order to facilitate the identification of the service.</dd>
order to facilitate the identification of the service.</t> <dt>'vpn-description':</dt>
<dd>
<t hangText="'vpn-description':">Includes a textual description of <t>Includes a textual description of
the service. <vspace blankLines="1" />The internal structure of a the service. </t>
<t>The internal structure of a
VPN description is local to each VPN service provider.</t> VPN description is local to each VPN service provider.</t>
</dd>
<t hangText="'customer-name':">Indicates the name of the customer <dt>'customer-name':</dt>
who ordered the service.</t> <dd>Indicates the name of the customer
who ordered the service.</dd>
<t hangText="'parent-service-id':">Refers to an identifier of the <dt>'parent-service-id':</dt>
parent service (e.g, L3SM, IETF network slice, VPN+) that <dd>Refers to an identifier of the
parent service (e.g., L3SM, IETF network slice, VPN+) that
triggered the creation of the VPN service. This identifier is used triggered the creation of the VPN service. This identifier is used
to easily correlate the (network) service as built in the network to easily correlate the (network) service as built in the network
with a service order. A controller can use that correlation to with a service order. A controller can use that correlation to
enrich or populate some fields (e.g., description fields) as a enrich or populate some fields (e.g., description fields) as a
function of local deployments.</t> function of local deployments.</dd>
<dt>'vpn-type':</dt>
<t hangText="'vpn-type':">Indicates the VPN type. The values are <dd>Indicates the VPN type. The values are
taken from <xref target="I-D.ietf-opsawg-vpn-common"></xref>. For taken from <xref target="RFC9181" format="default"/>. For
the L3NM, this is typically set to BGP/MPLS L3VPN, but other the L3NM, this is typically set to "BGP/MPLS L3VPN", but other
values may be defined in the future to support specific Layer 3 values may be defined to support specific Layer 3
VPN capabilities (e.g., <xref VPN capabilities (e.g., <xref target="RFC9136" format="default"/>).<
target="I-D.ietf-bess-evpn-prefix-advertisement"></xref>).</t> /dd>
<dt>'vpn-service-topology':</dt>
<t hangText="'vpn-service-topology':">Indicates the network <dd>Indicates the network
topology for the service: hub-spoke, any-to-any, or custom. The topology for the service: 'hub-spoke', 'any-to-any', or 'custom'. Th
e
network implementation of this attribute is defined by the correct network implementation of this attribute is defined by the correct
usage of import and export profiles (Section 4.3.5 of <xref usage of import and export targets (<xref target="RFC4364" sectionFo
target="RFC4364"></xref>).</t> rmat="of" section="4.3.5"/>).</dd>
<dt>'status':</dt>
<t hangText="'status':">Is used to track the service status of a <dd>
given VPN service. Both operational and administrative status are <t>Used to track the service status of a
given VPN service. Both operational status and administrative status
are
maintained together with a timestamp. For example, a service can maintained together with a timestamp. For example, a service can
be created, but not put into effect.<vspace be created but not put into effect.</t>
blankLines="1" />Administrative and operational status can be used <t>Administrative status and operational status can be used
as a trigger to detect service anomalies. For example, a service as a trigger to detect service anomalies. For example, a service
that is declared at the service layer as being active but still that is declared active at the service layer but is still
inactive at the network layer may be an indication that network inactive at the network layer may be an indication that network
provision actions are needed to align the observed service status provision actions are needed to align the observed service status
with the expected service status.</t> with the expected service status.</t>
</dd>
<t hangText="'vpn-instance-profiles':">Defines reusable parameters <dt>'vpn-instance-profiles':</dt>
for the same 'vpn-service'. <vspace blankLines="1" />More details <dd>
are provided in <xref target="ie_profiles"></xref>.</t> <t>Defines reusable parameters
for the same 'vpn-service'. </t>
<t hangText="'underlay-transport':">Describes the preference for <t>More details
are provided in <xref target="ie_profiles" format="default"/>.</t>
</dd>
<dt>'underlay-transport':</dt>
<dd>
<t>Describes the preference for
the transport technology to carry the traffic of the VPN service. the transport technology to carry the traffic of the VPN service.
This preference is especially useful in networks with multiple This preference is especially useful in networks with multiple
domains and Network-to-Network Interface (NNI) types. The underlay domains and Network-to-Network Interface (NNI) types. The underlay
transport can be expressed as an abstract transport instance transport can be expressed as an abstract transport instance
(e.g., an identifier of a VPN+ instance, a virtual network (e.g., an identifier of a VPN+ instance, a virtual network
identifier, or a network slice name) or as an ordered list of the identifier, or a network slice name) or as an ordered list of the
actual protocols to be enabled in the network. <vspace actual protocols to be enabled in the network. </t>
blankLines="1" />A rich set of protocol identifiers that can be <t>A rich set of protocol identifiers that can be
used to refer to an underlay transport are defined in <xref used to refer to an underlay transport are defined in <xref target="
target="I-D.ietf-opsawg-vpn-common"></xref>.</t> RFC9181" format="default"/>.</t>
</dd>
<t hangText="'external-connectivity':">Indicates whether/how <dt>'external-connectivity':</dt>
<dd>
<t>Indicates whether/how
external connectivity is provided to the VPN service. For example, external connectivity is provided to the VPN service. For example,
a service provider may provide an external connectivity to a VPN a service provider may provide external connectivity to a VPN
customer (e.g., to a public cloud). Such service may involve customer (e.g., to a public cloud). Such a service may involve
tweaking both filtering and NAT rules (e.g., bind a Virtual tweaking both filtering and NAT rules (e.g., binding a Virtual
Routing and Forwarding (VRF) interface with a NAT instance as Routing and Forwarding (VRF) interface with a NAT instance as
discussed in Section 2.10 of <xref target="RFC8512"></xref>). discussed in <xref target="RFC8512" sectionFormat="of" section="2.10
These added value features may be bound to all or a subset of "/>).
network accesses. Some of these added value features may be These value-added features may be bound to all, or a subset of,
implemented in a PE or in other nodes than PEs (e.g., a P node or network accesses. Some of these value-added features may be
even a dedicated node that hosts the NAT function). <vspace implemented in a PE or in nodes other than PEs (e.g., a P node or
blankLines="1" />Only a pointer to a local profile that defines even a dedicated node that hosts the NAT function). </t>
the external connectivity feature is supported in this <t>Only a pointer to a local profile that defines
the external-connectivity feature is supported in this
document.</t> document.</t>
</dd>
<t hangText="'vpn-node':">Is an abstraction that represents a set <dt>'vpn-node':</dt>
of policies applied to a network node and that belong to a single <dd>
<t>An abstraction that represents a set
of policies applied to a network node and belonging to a single
'vpn-service'. A VPN service is typically built by adding 'vpn-service'. A VPN service is typically built by adding
instances of 'vpn-node' to the 'vpn-nodes' container. <vspace instances of 'vpn-node' to the 'vpn-nodes' container. </t>
blankLines="1" />A 'vpn-node' contains 'vpn-network-accesses', <t>A 'vpn-node' contains 'vpn-network-accesses',
which are the interfaces attached to the VPN by which the customer which are the interfaces attached to the VPN by which the customer
traffic is received. Therefore, the customer sites are connected traffic is received. Therefore, the customer sites are connected
to the 'vpn-network-accesses'.<vspace blankLines="1" />Note that, to the 'vpn-network-accesses'.</t>
as this is a network data model, the information about customers <t>Note that
sites is not required in the model. Such information is rather because this is a network data model, information about customers'
sites is not required in the model. Rather, such information is
relevant in the L3SM. Whether that information is included in the relevant in the L3SM. Whether that information is included in the
L3NM, e.g., to populate the various 'description' data node is L3NM, e.g., to populate the various 'description' data nodes, is
implementation specific. <vspace blankLines="1" />More details are implementation specific. </t>
provided in <xref target="vpn_node"></xref>.</t> <t>More details are
</list></t> provided in <xref target="vpn_node" format="default"/>.</t>
</dd>
</dl>
</section> </section>
<section anchor="ie_profiles" numbered="true" toc="default">
<section anchor="ie_profiles" title="VPN Instance Profiles"> <name>VPN Instance Profiles</name>
<t>VPN instance profiles are meant to factorize data nodes that are <t>VPN instance profiles are meant to factorize data nodes that are
used at many levels of the model. Generic VPN instance profiles are used at many levels of the model. Generic VPN instance profiles are
defined at the VPN service level and then called at the VPN node and defined at the VPN service level and then called at the VPN node and
VPN network access levels. Each VPN instance profile is identified by VPN network access levels. Each VPN instance profile is identified by
'profile-id'. This identifier is then referenced for one or multiple 'profile-id'. This identifier is then referenced for one or multiple
VPN nodes (<xref target="vpn_node"></xref>) so that the controller can VPN nodes (<xref target="vpn_node" format="default"/>) so that the contr oller can
identify generic resources (e.g., RTs and RDs) to be configured for a identify generic resources (e.g., RTs and RDs) to be configured for a
given VRF.</t> given VRF instance.</t>
<t>The subtree of the 'vpn-instance-profiles' is shown in <xref target="
<t>The subtree of 'vpn-instance-profile' is shown in <xref ie" format="default"/>.</t>
target="ie"></xref>.</t> <figure anchor="ie">
<name>Subtree Structure of VPN Instance Profiles</name>
<t><figure align="center" anchor="ie" <sourcecode name="" type="yangtree"><![CDATA[ +--rw l3vpn-ntw
title="Subtree Structure of VPN Instance Profiles">
<artwork align="center"><![CDATA[ +--rw l3vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| ... | ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
+--rw vpn-id vpn-common:vpn-id +--rw vpn-id vpn-common:vpn-id
... ...
+--rw vpn-instance-profiles +--rw vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id] | +--rw vpn-instance-profile* [profile-id]
| +--rw profile-id string | +--rw profile-id string
| +--rw role? identityref | +--rw role? identityref
skipping to change at line 1087 skipping to change at line 874
| | | | +--rw route-target-type | | | | +--rw route-target-type
| | | | rt-types:route-target-type | | | | rt-types:route-target-type
| | | +--rw vpn-policies | | | +--rw vpn-policies
| | | +--rw import-policy? string | | | +--rw import-policy? string
| | | +--rw export-policy? string | | | +--rw export-policy? string
| | +--rw maximum-routes* [protocol] | | +--rw maximum-routes* [protocol]
| | +--rw protocol identityref | | +--rw protocol identityref
| | +--rw maximum-routes? uint32 | | +--rw maximum-routes? uint32
| +--rw multicast {vpn-common:multicast}? | +--rw multicast {vpn-common:multicast}?
| ... | ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>The descriptions of the listed data nodes are as follows:</t>
<t>The description of the listed data nodes is as follows:</t> <dl newline="false" spacing="normal">
<dt>'profile-id':</dt>
<t><list style="hanging"> <dd>Used to uniquely identify a VPN
<t hangText="'profile-id':">Is used to uniquely identify a VPN instance profile.</dd>
instance profile.</t> <dt>'role':</dt>
<dd>Indicates the role of the VPN instance
<t hangText="'role':">Indicates the role of the VPN instance profile in the VPN. Role values are defined in <xref target="RFC9181
profile in the VPN. Role values are defined in <xref " format="default"/> (e.g.,
target="I-D.ietf-opsawg-vpn-common"></xref> (e.g., 'any-to-any-role', 'spoke-role', 'hub-role').</dd>
any-to-any-role, spoke-role, hub-role).</t> <dt>'local-as':</dt>
<dd>Indicates the Autonomous System Number
<t hangText="'local-as':">Indicates the Autonomous System Number (ASN) that is configured for the VPN node.</dd>
(ASN) that is configured for the VPN node.</t> <dt>'rd':</dt>
<dd>
<t hangText="'rd':">As defined in <xref <t>As defined in <xref target="RFC9181" format="default"/>, the foll
target="I-D.ietf-opsawg-vpn-common"></xref>, the following RD owing RD
assignment modes are supported: direct assignment, automatic assignment modes are supported: direct assignment, full automatic
assignment from a given pool, automatic assignment, and no assignment, automatic assignment from a given pool, and no
assignment. For illustration purposes, the following modes can be assignment. For illustration purposes, the following modes can be
used in the deployment cases: <list style="hanging"> used in the deployment cases:</t>
<t hangText="'directly-assigned':">The VPN service provider <dl newline="false" spacing="normal">
(service orchestrator) assigns explicitly RDs. This case will <dt>'directly-assigned':</dt>
<dd>The VPN service provider
(service orchestrator) assigns RDs explicitly. This case will
fit with a brownfield scenario where some existing services fit with a brownfield scenario where some existing services
need to be updated by the VPN service provider.</t> need to be updated by the VPN service provider.</dd>
<dt>'full-auto':</dt>
<t hangText="'full-auto':">The network controller auto-assigns <dd>The network controller auto-assigns
RDs. This can apply for the deployment of new services.</t> RDs. This can apply for the deployment of new services.</dd>
<dt>'no-rd':</dt>
<t hangText="'no-rd':">The VPN service provider (service <dd>The VPN service provider (service
orchestrator) explicitly wants no RD to be assigned. This case orchestrator) explicitly wants no RD to be assigned. This case
can be used for CE testing within the network or for can be used for CE testing within the network or for
troubleshooting proposes.</t> troubleshooting proposes.</dd>
</list>Also, the module accommodates deployments where only the </dl>
Assigned Number subfield of RDs (Section 4.2 of <xref
target="RFC4364"></xref>) is assigned from a pool while the <t>Also, the module accommodates deployments where only the
Administrator subfield is set to, e.g., the Router ID that is Assigned Number subfield of RDs (<xref target="RFC4364" sectionForma
t="of" section="4.2"/>) is assigned from a pool while the
Administrator subfield is set to, for example, the Router ID that is
assigned to a VPN node. The module supports these modes for assigned to a VPN node. The module supports these modes for
managing the Assigned Number subfield: explicit assignment, managing the Assigned Number subfield: explicit assignment,
auto-assignment from a pool, and full auto-assignment.</t> auto-assignment from a pool, and full auto-assignment.</t>
</dd>
<t hangText="'address-family':">Includes a set of per-address <dt>'address-family':</dt>
family data nodes:<list style="hanging"> <dd>
<t hangText="'address-family':">Identifies the address family. <t>Includes a set of data nodes per address family:</t>
It can be set to IPv4, IPv6, or dual-stack.</t> <dl newline="false" spacing="normal">
<dt>'address-family':</dt>
<t hangText="'vpn-targets':">Specifies RT import/export rules <dd>Identifies the address family.
for the VPN service (Section 4.3 of <xref It can be set to 'ipv4', 'ipv6', or 'dual-stack'.</dd>
target="RFC4364"></xref>).</t> <dt>'vpn-targets':</dt>
<dd>Specifies RT import/export rules
<t hangText="'maximum-routes':">Indicates the maximum number for the VPN service (<xref target="RFC4364" sectionFormat="of" s
ection="4.3"/>).</dd>
<dt>'maximum-routes':</dt>
<dd>Indicates the maximum number
of prefixes that the VPN node can accept for a given routing of prefixes that the VPN node can accept for a given routing
protocol. If 'protocol' is set to 'any', this means that the protocol. If 'protocol' is set to 'any', this means that the
maximum value applies to each active routing protocol.</t> maximum value applies to each active routing protocol.</dd>
</list></t> </dl>
</dd>
<t hangText="'multicast':">Enables multicast traffic in the VPN <dt>'multicast':</dt>
service. Refer to <xref target="mc"></xref>.</t> <dd>Enables multicast traffic in the VPN
</list></t> service. Refer to <xref target="mc" format="default"/>.</dd>
</dl>
<t></t>
</section> </section>
<section anchor="vpn_node" numbered="true" toc="default">
<section anchor="vpn_node" title="VPN Nodes"> <name>VPN Nodes</name>
<t>The 'vpn-node' is an abstraction that represents a set of common <t>The 'vpn-node' is an abstraction that represents a set of common
policies applied on a given network node (typically, a PE) and belong policies applied on a given network node (typically, a PE) and belonging
to one L3VPN service. The 'vpn-node' includes a parameter to indicate to one L3VPN service. The 'vpn-node' includes a parameter to indicate
the network node on which it is applied. In the case that the 'ne-id' the network node on which it is applied. In the case that the 'ne-id'
points to a specific PE, the 'vpn-node' will likely be mapped into a points to a specific PE, the 'vpn-node' will likely be mapped to a
VRF in the node. However, the model also allows pointing to an VRF instance in the node. However, the model also allows pointing to an
abstract node. In this case, the network controller will decide how to abstract node. In this case, the network controller will decide how to
split the 'vpn-node' into VRFs.</t> split the 'vpn-node' into VRF instances.</t>
<t><figure align="center" anchor="vpn-node_tree" <t>The VPN node subtree structure is shown in <xref target="vpn-node_tre
title="VPN Node Subtree Structure"> e"/>.</t>
<artwork align="center"><![CDATA[ +--rw l3vpn-ntw <figure anchor="vpn-node_tree">
<name>VPN Node Subtree Structure</name>
<sourcecode name="" type="yangtree"><![CDATA[ +--rw l3vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| ... | ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
... ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
+--rw vpn-node-id vpn-common:vpn-id +--rw vpn-node-id vpn-common:vpn-id
+--rw description? string +--rw description? string
+--rw ne-id? string +--rw ne-id? string
skipping to change at line 1218 skipping to change at line 1008
| +--rw group* [group-id] | +--rw group* [group-id]
| +--rw group-id string | +--rw group-id string
+--rw status +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw vpn-network-accesses +--rw vpn-network-accesses
...]]></artwork> ...
</figure></t> ]]></sourcecode>
</figure>
<t>In reference to the subtree shown in <xref <t>The descriptions of the 'vpn-node' data nodes (<xref target="vpn-nod
target="vpn-node_tree"></xref>, the description of VPN node data nodes e_tree"/>) are as follows:</t>
is as follows:<list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="'vpn-node-id':">Is an identifier that uniquely <dt>'vpn-node-id':</dt>
identifies a node that enables a VPN network access.</t> <dd>An identifier that uniquely
identifies a node that enables a VPN network access.</dd>
<t hangText="'description':">Provides a textual description of the <dt>'description':</dt>
VPN node.</t> <dd>Provides a textual description of the
VPN node.</dd>
<t hangText="'ne-id':">Includes a unique identifier of the network <dt>'ne-id':</dt>
element where the VPN node is deployed.</t> <dd>Includes a unique identifier of the network
element where the VPN node is deployed.</dd>
<t hangText="'local-autonomous-system':">Indicates the ASN that is <dt>'local-as':</dt>
configured for the VPN node.</t> <dd>Indicates the ASN that is
configured for the VPN node.</dd>
<t hangText="'router-id':">Indicates a 32-bit number that is used <dt>'router-id':</dt>
to uniquely identify a router within an Autonomous System.</t> <dd>Indicates a 32-bit number that is used
to uniquely identify a router within an AS.</dd>
<t hangText="'active-vpn-instance-profiles':">Lists the set of <dt>'active-vpn-instance-profiles':</dt>
<dd>
<t>Lists the set of
active VPN instance profiles for this VPN node. Concretely, one or active VPN instance profiles for this VPN node. Concretely, one or
more VPN instance profiles that are defined at the VPN service more VPN instance profiles that are defined at the VPN service
level can be enabled at the VPN node level; each of these profiles level can be enabled at the VPN node level; each of these profiles
is uniquely identified by means of 'profile-id'. The structure of is uniquely identified by means of 'profile-id'. The structure of
'active-vpn-instance-profiles' is the same as the one discussed in 'active-vpn-instance-profiles' is the same as the structure discusse
<xref target="ie_profiles"></xref> except 'router-id'. The value d in
<xref target="ie_profiles" format="default"/>, except that the struc
ture of
'active-vpn-instance-profiles' includes 'router-id' but does not include the 'r
ole' leaf. The value
of 'router-id' indicated under 'active-vpn-instance-profiles' of 'router-id' indicated under 'active-vpn-instance-profiles'
takes precedence over the 'router-id' under the 'vpn-node' for the takes precedence over the 'router-id' under the 'vpn-node' for the
indicated address family. For example, Router IDs can be indicated address family. For example, Router IDs can be
configured per address family. This capability can be used, for configured per address family. This capability can be used, for
example, to configure an IPv6 address as a Router ID when such example, to configure an IPv6 address as a Router ID when such a
capability is supported by involved routers. <vspace capability is supported by involved routers. </t>
blankLines="1" />Values defined in 'active-vpn-instance-profiles' <t>Values defined in 'active-vpn-instance-profiles'
overrides the ones defined in the VPN service level. An example is override the values defined at the VPN service level. An example is
shown in <xref target="app-ex"></xref>.</t> shown in <xref target="app-ex" format="default"/>.</t>
</dd>
<t hangText="'msdp':">For redundancy purposes, Multicast Source <dt>'msdp':</dt>
Discovery Protocol (MSDP) <xref target="RFC3618"></xref> may be <dd>For redundancy purposes, the Multicast Source
enabled and used to share the state about sources between multiple Discovery Protocol (MSDP) <xref target="RFC3618" format="default"/>
may be
enabled and used to share state information about sources between mu
ltiple
Rendezvous Points (RPs). The purpose of MSDP in this context is to Rendezvous Points (RPs). The purpose of MSDP in this context is to
enhance the robustness of the multicast service. MSDP may be enhance the robustness of the multicast service. MSDP may be
configured on non-RP routers, which is useful in a domain that configured on non-RP routers; this is useful in a domain that
does not support multicast sources, but does support multicast does not support multicast sources but does support multicast
transit.</t> transit.</dd>
<dt>'groups':</dt>
<t hangText="'groups':">Lists the groups to which a VPN node <dd>Lists the groups to which a VPN node
belongs to <xref target="I-D.ietf-opsawg-vpn-common"></xref>. The belongs <xref target="RFC9181" format="default"/>. For example, the
'group-id' is used to associate, e.g., redundancy or protection 'group-id' is used to associate redundancy or protection
constraints with VPN nodes.</t> constraints with VPN nodes.</dd>
<dt>'status':</dt>
<t hangText="'status':">Tracks the status of a node involved in a <dd>Tracks the status of a node involved in a
VPN service. Both operational and administrative status are VPN service. Both operational status and administrative status are
maintained. A mismatch between the administrative status vs. the maintained. A mismatch between the administrative status vs. the
operational status can be used as a trigger to detect operational status can be used as a trigger to detect
anomalies.</t> anomalies.</dd>
<dt>'vpn-network-accesses':</dt>
<t hangText="'vpn-network-accesses':">Represents the point to <dd>
which sites are connected. <vspace blankLines="1" />Note that, <t>Represents the point to
unlike in the L3SM, the L3NM does not need to model the customer which sites are connected. </t>
site, only the points where the traffic from the site are received <t>Note that
(i.e., the PE side of PE-CE connections). Hence, the VPN network unlike the L3SM, the L3NM does not need to model the customer
site -- only the points that receive traffic from the site
(i.e., the PE side of Provider Edge to Customer Edge (PE-CE) connect
ions). Hence, the VPN network
access contains the connectivity information between the access contains the connectivity information between the
provider's network and the customer premises. The VPN profiles provider's network and the customer premises. The VPN profiles
('vpn-profiles') have a set of routing policies that can be ('vpn-profiles') have a set of routing policies that can be
applied during the service creation. <vspace blankLines="1" />See applied during the service creation. </t>
<xref target="sna"></xref> for more details.</t> <t>See
</list></t> <xref target="sna" format="default"/> for more details.</t>
</dd>
<t></t> </dl>
</section> </section>
<section anchor="sna" numbered="true" toc="default">
<section anchor="sna" title="VPN Network Accesses"> <name>VPN Network Accesses</name>
<t>The 'vpn-network-access' includes a set of data nodes that describe <t>The 'vpn-network-access' includes a set of data nodes that describe
the access information for the traffic that belongs to a particular the access information for the traffic that belongs to a particular
L3VPN (<xref target="vpnaccess"></xref>).</t> L3VPN (<xref target="vpnaccess" format="default"/>).</t>
<figure anchor="vpnaccess">
<t><figure align="center" anchor="vpnaccess" <name>VPN Network Access Subtree Structure</name>
title="VPN Network Access Subtree Structure"> <sourcecode name="" type="yangtree"><![CDATA[...
<artwork align="left"><![CDATA[...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
+--rw id vpn-common:vpn-id +--rw id vpn-common:vpn-id
+--rw interface-id? string +--rw interface-id? string
+--rw description? string +--rw description? string
+--rw vpn-network-access-type? identityref +--rw vpn-network-access-type? identityref
+--rw vpn-instance-profile? leafref +--rw vpn-instance-profile? leafref
skipping to change at line 1328 skipping to change at line 1122
+--rw ip-connection +--rw ip-connection
| ... | ...
+--rw routing-protocols +--rw routing-protocols
| ... | ...
+--rw oam +--rw oam
| ... | ...
+--rw security +--rw security
| ... | ...
+--rw service +--rw service
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>A 'vpn-network-access' (<xref target="vpnaccess" format="default"/>)
<t>In reference to the subtree depicted in <xref includes the following data nodes:</t>
target="vpnaccess"></xref>, a 'vpn-network-access' includes the <dl newline="false" spacing="normal">
following data nodes: <list style="hanging"> <dt>'id':</dt>
<t hangText="'id':">Is an identifier of the VPN network <dd>An identifier of the VPN network
access.</t> access.</dd>
<dt>'interface-id':</dt>
<t hangText="'interface-id':">Indicates the physical or logical <dd>Indicates the physical or logical
interface on which the VPN network access is bound.</t> interface on which the VPN network access is bound.</dd>
<dt>'description':</dt>
<t hangText="'description':">Includes a textual description of the <dd>Includes a textual description of the
VPN network access.</t> VPN network access.</dd>
<dt>'vpn-network-access-type':</dt>
<t hangText="'vpn-network-access-type':">Is used to select the <dd>
<t>Used to select the
type of network interface to be deployed in the devices. The type of network interface to be deployed in the devices. The
available defined values are: <list style="hanging"> available defined values are as follows:</t>
<t hangText="'point-to-point':">Represents a direct connection <dl newline="false" spacing="normal">
<dt>'point-to-point':</dt>
<dd>Represents a direct connection
between the endpoints. The controller must keep the between the endpoints. The controller must keep the
association between a logical or physical interface on the association between a logical or physical interface on the
device with the 'id' of the 'vpn-network-access'.</t> device with the 'id' of the 'vpn-network-access'.</dd>
<dt>'multipoint':</dt>
<t hangText="'multipoint':">Represents a multipoint connection <dd>Represents a multipoint connection
between the customer site and the PEs. The controller must between the customer site and the PEs. The controller must
keep the association between a logical or physical interface keep the association between a logical or physical interface
on the device with the 'id' of the 'vpn-network-access'.</t> on the device with the 'id' of the 'vpn-network-access'.</dd>
<dt>'irb':</dt>
<t hangText="'irb':">Represents a connection coming from an <dd>Represents a connection coming from an
L2VPN service. An identifier of such service ('l2vpn-id') may L2VPN service. An identifier of such a service ('l2vpn-id') may
be included in the 'connection' container as depicted in <xref be included in the 'connection' container, as depicted in <xref
target="bearerethencap_tree"></xref>. The controller must keep target="bearerethencap_tree" format="default"/> (<xref target="connection"/>). T
he controller must keep
the relationship between the logical tunnels or bridges on the the relationship between the logical tunnels or bridges on the
devices with the 'id' of the' vpn-network-access'.</t> devices with the 'id' of the 'vpn-network-access'.</dd>
<dt>'loopback':</dt>
<t hangText="'loopback':">Represents the creation of a logical <dd>Represents the creation of a logical
interface on a device. An example to illustrate how a loopback interface on a device. An example that illustrates how a loopbac
interface can be used in the L3NM is provided in <xref k
target="loop"></xref>.</t> interface can be used in the L3NM is provided in <xref target="l
</list></t> oop" format="default"/>.</dd>
</dl>
<t hangText="'vpn-instance-profile':">Provides a pointer to an </dd>
<dt>'vpn-instance-profile':</dt>
<dd>Provides a pointer to an
active VPN instance profile at the VPN node level. Referencing an active VPN instance profile at the VPN node level. Referencing an
active VPN instance profile implies that all associated data nodes active VPN instance profile implies that all associated data nodes
will be inherited by the VPN network access. However, some will be inherited by the VPN network access. However, some
inherited data nodes (e.g., multicast) can be overridden at the inherited data nodes (e.g., multicast) can be overridden at the
VPN network access level. In such case, adjusted values take VPN network access level. In such a case, adjusted values take
precedence over inherited ones.</t> precedence over inherited values.</dd>
<dt>'status':</dt>
<t hangText="'status':">Indicates both operational and <dd>Indicates both operational status and
administrative status of a VPN network access.</t> administrative status of a VPN network access.</dd>
<dt>'connection':</dt>
<t hangText="'connection':">Represents and groups the set of Layer <dd>Represents and groups the set of Layer
2 connectivity from where the traffic of the L3VPN in a particular 2 connectivity from where the traffic of the L3VPN in a particular
VPN Network access is coming. See <xref VPN network access is coming. See <xref target="connection" format="
target="connection"></xref>.</t> default"/>.</dd>
<dt>'ip-connection':</dt>
<t hangText="'ip-connection':">Contains Layer 3 connectivity <dd>Contains Layer 3 connectivity
information of a VPN network access (e.g., IP addressing). See information on a VPN network access (e.g., IP addressing). See
<xref target="ip_conn"></xref>.</t> <xref target="ip_conn" format="default"/>.</dd>
<dt>'routing-protocols':</dt>
<t hangText="'routing-protocols':">Includes the CE-PE routing <dd>Includes the CE-PE routing
configuration information. See <xref target="rtg"></xref>.</t> configuration information. See <xref target="rtg" format="default"/>
.</dd>
<t hangText="'oam':">Specifies the Operations, Administration, and <dt>'oam':</dt>
<dd>Specifies the Operations, Administration, and
Maintenance (OAM) mechanisms used for a VPN network access. See Maintenance (OAM) mechanisms used for a VPN network access. See
<xref target="sec-oam"></xref>.</t> <xref target="sec-oam" format="default"/>.</dd>
<dt>'security':</dt>
<t hangText="'security':">Specifies the authentication and the <dd>Specifies the authentication and the
encryption to be applied for a given VPN network access. See <xref encryption to be applied for a given VPN network access. See <xref t
target="sec"></xref>.</t> arget="sec" format="default"/>.</dd>
<dt>'service':</dt>
<t hangText="'service':">Specifies the service parameters (e.g., <dd>Specifies the service parameters (e.g.,
QoS, multicast) to apply for a given VPN network access. See <xref QoS, multicast) to apply for a given VPN network access. See <xref t
target="svc"></xref>.</t> arget="svc" format="default"/>.</dd>
</list></t> </dl>
<section anchor="connection" numbered="true" toc="default">
<t></t> <name>Connection</name>
<t>The 'connection' container represents the Layer 2 connectivity to
<section anchor="connection" title="Connection">
<t>The 'connection' container represents the layer 2 connectivity to
the L3VPN for a particular VPN network access. As shown in the tree the L3VPN for a particular VPN network access. As shown in the tree
depicted in <xref target="bearerethencap_tree"></xref>, the depicted in <xref target="bearerethencap_tree" format="default"/>, the
'connection' container defines protocols and parameters to enable 'connection' container defines protocols and parameters to enable
such connectivity at layer 2.</t> such connectivity at Layer 2.</t>
<t>The traffic can enter the VPN with or without encapsulation <t>The traffic can enter the VPN with or without encapsulation
(e.g., VLAN, QinQ). The 'encapsulation' container specifies the (e.g., VLAN, QinQ). The 'encapsulation' container specifies the
layer 2 encapsulation to use (if any) and allows to configure the Layer 2 encapsulation to use (if any) and allows the configuration of the
relevant tags.</t> relevant tags.</t>
<t>The interface that is attached to the L3VPN is identified by the <t>The interface that is attached to the L3VPN is identified by the
'interface-id' at the 'vpn-network-access' level. From a network 'interface-id' at the 'vpn-network-access' level. From a network
model perspective, it is expected that the 'interface-id' is model perspective, it is expected that the 'interface-id' is
sufficient to identify the interface. However, specific layer 2 sufficient to identify the interface. However, specific Layer 2
sub-interfaces may be required to be configured in some sub-interfaces may be required to be configured in some
implementations/deployments. Such a layer 2 specific interface can implementations/deployments. Such a Layer-2-specific interface can
be included in 'l2-termination-point'.</t> be included in 'l2-termination-point'.</t>
<t>If a Layer 2 tunnel is needed to terminate the service in the
<t>If a layer 2 tunnel is needed to terminate the service in the
CE-PE connection, the 'l2-tunnel-service' container is used to CE-PE connection, the 'l2-tunnel-service' container is used to
specify the required parameters to set such tunneling service (e.g., specify the required parameters to set such a tunneling service (e.g.,
VPLS, VXLAN). An identity, called 'l2-tunnel-type', is defined for a Virtual Private LAN Service (VPLS) or a Virtual eXtensible Local Are
layer 2 tunnel selection. The container can also identify the a Network (VXLAN)). An identity called 'l2-tunnel-type' is defined for
pseudowire (Section 6.1 of <xref target="RFC8077"></xref>).</t> Layer 2 tunnel selection. The container can also identify the
pseudowire (<xref target="RFC8077" sectionFormat="of" section="6.1"/>)
<t>As discussed in <xref target="sna"></xref>, 'l2vpn-id' is used to .</t>
identify the L2VPN service that is associated with an IRB <t>As discussed in <xref target="sna" format="default"/>, 'l2vpn-id' i
s used to
identify the L2VPN service that is associated with an Integrated Routi
ng and Bridging (IRB)
interface.</t> interface.</t>
<t>To accommodate implementations that require internal bridging, a <t>To accommodate implementations that require internal bridging, a
local bridge reference can be specified in 'local-bridge-reference'. local bridge reference can be specified in 'local-bridge-reference'.
Such a reference may be a local bridge domain.</t> Such a reference may be a local bridge domain.</t>
<t>A site, as per <xref target="RFC4176" format="default"/>, represent
<t>A site, as per <xref target="RFC4176"></xref> represents a VPN s a VPN
customer's location that is connected to the service provider customer's location that is connected to the service provider
network via a CE-PE link, which can access at least one VPN. The network via a CE-PE link, which can access at least one VPN. The
connection from the site to the service provider network is the connection from the site to the service provider network is the
bearer. Every site is associated with a list of bearers. A bearer is bearer. Every site is associated with a list of bearers. A bearer is
the layer two connection with the site. In the L3NM, it is assumed the Layer 2 connection with the site. In the L3NM, it is assumed
that the bearer has been allocated by the service provider at the that the bearer has been allocated by the service provider at the
service orchestration stage. The bearer is associated to a network service orchestration stage. The bearer is associated with a network
element and a port. Hence, a bearer is just a 'bearer-reference' to element and a port. Hence, a bearer is just a 'bearer-reference' to
allow the association between a service request (e.g., L3SM) and allow the association between a service request (e.g., the L3SM) and
L3NM.</t> the L3NM.</t>
<t>The L3NM can be used to create a Link Aggregation Group (LAG) inter
<t>The L3NM can be used to create a LAG interface for a given L3VPN face for a given L3VPN
service ('lag-interface') <xref target="IEEE802.1AX"></xref>. Such a service ('lag-interface') <xref target="IEEE802.1AX" format="default"/
LAG interface can be referenced under 'interface-id' (<xref >. Such a
target="sna"></xref>).</t> LAG interface can be referenced under 'interface-id' (<xref target="sn
a" format="default"/>).</t>
<t><figure align="center" anchor="bearerethencap_tree" <figure anchor="bearerethencap_tree">
title="Connection Subtree Structure"> <name>Connection Subtree Structure</name>
<artwork align="center"><![CDATA[... <sourcecode name="" type="yangtree"><![CDATA[...
+--rw connection +--rw connection
| +--rw encapsulation | +--rw encapsulation
| | +--rw type? identityref | | +--rw type? identityref
| | +--rw dot1q | | +--rw dot1q
| | | +--rw tag-type? identityref | | | +--rw tag-type? identityref
| | | +--rw cvlan-id? uint16 | | | +--rw cvlan-id? uint16
| | +--rw priority-tagged | | +--rw priority-tagged
| | | +--rw tag-type? identityref | | | +--rw tag-type? identityref
| | +--rw qinq | | +--rw qinq
| | +--rw tag-type? identityref | | +--rw tag-type? identityref
skipping to change at line 1492 skipping to change at line 1273
| | | | +--rw vcid? uint32 | | | | +--rw vcid? uint32
| | | | +--rw far-end* union | | | | +--rw far-end* union
| | | +--rw vxlan | | | +--rw vxlan
| | | +--rw vni-id uint32 | | | +--rw vni-id uint32
| | | +--rw peer-mode? identityref | | | +--rw peer-mode? identityref
| | | +--rw peer-ip-address* inet:ip-address | | | +--rw peer-ip-address* inet:ip-address
| | +--:(l2vpn) | | +--:(l2vpn)
| | +--rw l2vpn-id? vpn-common:vpn-id | | +--rw l2vpn-id? vpn-common:vpn-id
| +--rw l2-termination-point? string | +--rw l2-termination-point? string
| +--rw local-bridge-reference? string | +--rw local-bridge-reference? string
| +--rw bearer-reference? string | +--rw bearer-reference? string
| | {vpn-common:bearer-reference}? | | {vpn-common:bearer-reference}?
| +--rw lag-interface {vpn-common:lag-interface}? | +--rw lag-interface {vpn-common:lag-interface}?
| +--rw lag-interface-id? string | +--rw lag-interface-id? string
| +--rw member-link-list | +--rw member-link-list
| +--rw member-link* [name] | +--rw member-link* [name]
| +--rw name string | +--rw name string
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section anchor="ip_conn" numbered="true" toc="default">
<section anchor="ip_conn" title="IP Connection"> <name>IP Connection</name>
<t>This container is used to group Layer 3 connectivity information, <t>This container is used to group Layer 3 connectivity information,
particularly the IP addressing information, of a VPN network access. particularly the IP addressing information, of a VPN network access.
The allocated address represents the PE interface address The allocated address represents the PE interface address
configuration. Note that a distinct layer 3 interface other than the configuration. Note that a distinct Layer 3 interface other than the
one indicated under the 'connection' container may be needed to interface indicated under the 'connection' container may be needed to
terminate the layer 3 service. The identifier of such interface is terminate the Layer 3 service. The identifier of such an interface is
included in 'l3-termination-point'. For example, this data node can included in 'l3-termination-point'. For example, this data node can
be used to carry the identifier of a bridge domain interface.</t> be used to carry the identifier of a bridge domain interface.</t>
<t>As shown in <xref target="ip_conn_tree" format="default"/>, the
<t>As shown in <xref target="ip_conn_tree"></xref>, the
'ip-connection' container can include IPv4, IPv6, or both if 'ip-connection' container can include IPv4, IPv6, or both if
dual-stack is enabled.</t> dual-stack is enabled.</t>
<figure anchor="ip_conn_tree">
<t><figure align="center" anchor="ip_conn_tree" <name>IP Connection Subtree Structure</name>
title="IP Connection Subtree Structure"> <sourcecode name="" type="yangtree"><![CDATA[...
<artwork align="center"><![CDATA[...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
+--rw ip-connection +--rw ip-connection
| +--rw l3-termination-point? string | +--rw l3-termination-point? string
| +--rw ipv4 {vpn-common:ipv4}? | +--rw ipv4 {vpn-common:ipv4}?
| | ... | | ...
| +--rw ipv6 {vpn-common:ipv6}? | +--rw ipv6 {vpn-common:ipv6}?
| ... | ...
... ...
]]></sourcecode>
]]></artwork> </figure>
</figure></t>
<t>For both IPv4 and IPv6, the IP connection supports three IP <t>For both IPv4 and IPv6, the IP connection supports three IP
address assignment modes for customer addresses: provider DHCP, DHCP address assignment modes for customer addresses: provider DHCP, DHCP
relay, and static addressing. Note that for the IPv6 case, SLAAC relay, and static addressing. Note that for the IPv6 case, Stateless A
<xref target="RFC4862"></xref> can be used. For both IPv4 and IPv6, ddress Autoconfiguration (SLAAC)
<xref target="RFC4862" format="default"/> can be used. For both IPv4 a
nd IPv6,
'address-allocation-type' is used to indicate the IP address 'address-allocation-type' is used to indicate the IP address
allocation mode to activate for a given VPN network access.</t> allocation mode to activate for a given VPN network access.</t>
<t>When 'address-allocation-type' is set to 'provider-dhcp', DHCP <t>When 'address-allocation-type' is set to 'provider-dhcp', DHCP
assignments can be made locally or by an external DHCP server. Such assignments can be made locally or by an external DHCP server. Such
as behavior is controlled by setting 'dhcp-service-type'.</t> behavior is controlled by setting 'dhcp-service-type'.</t>
<t><xref target="ip_conn_tree_v4" format="default"/> shows the structu
<t><xref target="ip_conn_tree_v4"></xref> shows the structure of the re of the
dynamic IPv4 address assignment (i.e., by means of DHCP).</t> dynamic IPv4 address assignment (i.e., by means of DHCP).</t>
<figure anchor="ip_conn_tree_v4">
<t><figure align="center" anchor="ip_conn_tree_v4" <name>IP Connection Subtree Structure (IPv4)</name>
title="IP Connection Subtree Structure (IPv4)"> <sourcecode name="" type="yangtree"><![CDATA[...
<artwork align="center"><![CDATA[...
+--rw ip-connection +--rw ip-connection
| +--rw l3-termination-point? string | +--rw l3-termination-point? string
| +--rw ipv4 {vpn-common:ipv4}? | +--rw ipv4 {vpn-common:ipv4}?
| | +--rw local-address? inet:ipv4-address | | +--rw local-address? inet:ipv4-address
| | +--rw prefix-length? uint8 | | +--rw prefix-length? uint8
| | +--rw address-allocation-type? identityref | | +--rw address-allocation-type? identityref
| | +--rw (allocation-type)? | | +--rw (allocation-type)?
| | +--:(provider-dhcp) | | +--:(provider-dhcp)
| | | +--rw dhcp-service-type? enumeration | | | +--rw dhcp-service-type? enumeration
| | | +--rw (service-type)? | | | +--rw (service-type)?
skipping to change at line 1584 skipping to change at line 1358
| | | +--rw start-address | | | +--rw start-address
| | | | inet:ipv4-address | | | | inet:ipv4-address
| | | +--rw end-address? | | | +--rw end-address?
| | | inet:ipv4-address | | | inet:ipv4-address
| | +--:(dhcp-relay) | | +--:(dhcp-relay)
| | | +--rw customer-dhcp-servers | | | +--rw customer-dhcp-servers
| | | +--rw server-ip-address* inet:ipv4-address | | | +--rw server-ip-address* inet:ipv4-address
| | +--:(static-addresses) | | +--:(static-addresses)
| | ... | | ...
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t><xref target="ip_conn_tree_v6" format="default"/> shows the structu
<t><xref target="ip_conn_tree_v6"></xref> shows the structure of the re of the
dynamic IPv6 address assignment (i.e., DHCPv6 and/or SLAAC). Note dynamic IPv6 address assignment (i.e., DHCPv6 and/or SLAAC). Note
that if 'address-allocation-type' is set to 'slaac', the Prefix that if 'address-allocation-type' is set to 'slaac', the Prefix
Information option of Router Advertisements that will be issued for Information option of Router Advertisements that will be issued for
SLAAC purposes, will carry the IPv6 prefix that is determined by SLAAC purposes will carry the IPv6 prefix that is determined by
'local-address' and 'prefix-length'. For example, if 'local-address' 'local-address' and 'prefix-length'. For example, if 'local-address'
is set to '2001:db8:0:1::1' and 'prefix-length' is set to '64', the is set to '2001:db8:0:1::1' and 'prefix-length' is set to '64', the
IPv6 prefix that will be used is '2001:db8:0:1::/64'.</t> IPv6 prefix that will be used is '2001:db8:0:1::/64'.</t>
<figure anchor="ip_conn_tree_v6">
<t><figure align="center" anchor="ip_conn_tree_v6" <name>IP Connection Subtree Structure (IPv6)</name>
title="IP Connection Subtree Structure (IPv6)"> <sourcecode name="" type="yangtree"><![CDATA[...
<artwork align="center"><![CDATA[...
+--rw ip-connection +--rw ip-connection
| +--rw l3-termination-point? string | +--rw l3-termination-point? string
| +--rw ipv4 {vpn-common:ipv4}? | +--rw ipv4 {vpn-common:ipv4}?
| | ... | | ...
| +--rw ipv6 {vpn-common:ipv6}? | +--rw ipv6 {vpn-common:ipv6}?
| +--rw local-address? inet:ipv6-address | +--rw local-address? inet:ipv6-address
| +--rw prefix-length? uint8 | +--rw prefix-length? uint8
| +--rw address-allocation-type? identityref | +--rw address-allocation-type? identityref
| +--rw (allocation-type)? | +--rw (allocation-type)?
| +--:(provider-dhcp) | +--:(provider-dhcp)
skipping to change at line 1635 skipping to change at line 1407
| | +--rw start-address | | +--rw start-address
| | | inet:ipv6-address | | | inet:ipv6-address
| | +--rw end-address? | | +--rw end-address?
| | inet:ipv6-address | | inet:ipv6-address
| +--:(dhcp-relay) | +--:(dhcp-relay)
| | +--rw customer-dhcp-servers | | +--rw customer-dhcp-servers
| | +--rw server-ip-address* | | +--rw server-ip-address*
| | inet:ipv6-address | | inet:ipv6-address
| +--:(static-addresses) | +--:(static-addresses)
| ... | ...
]]></sourcecode>
]]></artwork> </figure>
</figure></t> <t>In the case of static addressing (<xref target="ip_conn_tree-static
" format="default"/>), the model supports the
<t>In the case of the static addressing (<xref
target="ip_conn_tree-static"></xref>), the model supports the
assignment of several IP addresses in the same 'vpn-network-access'. assignment of several IP addresses in the same 'vpn-network-access'.
To identify which of the addresses is the primary address of a To identify which of the addresses is the primary address of a
connection, the 'primary-address' reference MUST be set with the connection, the 'primary-address' reference <bcp14>MUST</bcp14> be set with the
corresponding 'address-id'.</t> corresponding 'address-id'.</t>
<figure anchor="ip_conn_tree-static">
<figure align="center" anchor="ip_conn_tree-static" <name>IP Connection Subtree Structure (Static Mode)</name>
title="IP Connection Subtree Structure (Static Mode)"> <sourcecode name="" type="yangtree"><![CDATA[...
<artwork align="center"><![CDATA[...
+--rw ip-connection +--rw ip-connection
| +--rw l3-termination-point? string | +--rw l3-termination-point? string
| +--rw ipv4 {vpn-common:ipv4}? | +--rw ipv4 {vpn-common:ipv4}?
| | +--rw address-allocation-type? identityref | | +--rw address-allocation-type? identityref
| | +--rw (allocation-type)? | | +--rw (allocation-type)?
| | ... | | ...
| | +--:(static-addresses) | | +--:(static-addresses)
| | +--rw primary-address? -> ../address/address-id | | +--rw primary-address? -> ../address/address-id
| | +--rw address* [address-id] | | +--rw address* [address-id]
| | +--rw address-id string | | +--rw address-id string
| | +--rw customer-address? inet:ipv4-address | | +--rw customer-address? inet:ipv4-address
| +--rw ipv6 {vpn-common:ipv6}? | +--rw ipv6 {vpn-common:ipv6}?
| +--rw address-allocation-type? identityref | +--rw address-allocation-type? identityref
| +--rw (allocation-type)? | +--rw (allocation-type)?
| ... | ...
| +--:(static-addresses) | +--:(static-addresses)
| +--rw primary-address? -> ../address/address-id | +--rw primary-address? -> ../address/address-id
| +--rw address* [address-id] | +--rw address* [address-id]
| +--rw address-id string | +--rw address-id string
| +--rw customer-address? inet:ipv6-address | +--rw customer-address? inet:ipv6-address
... ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t></t>
</section> </section>
<section anchor="rtg" numbered="true" toc="default">
<section anchor="rtg" title="CE-PE Routing Protocols"> <name>CE-PE Routing Protocols</name>
<t>A VPN service provider can configure one or more routing <t>A VPN service provider can configure one or more routing
protocols associated with a particular 'vpn-network-access'. Such protocols associated with a particular 'vpn-network-access'. Such
routing protocols are enabled between the PE and the CE. Each routing protocols are enabled between the PE and the CE. Each
instance is uniquely identified to accommodate scenarios where instance is uniquely identified to accommodate scenarios where
multiple instances of the same routing protocol have to be multiple instances of the same routing protocol have to be
configured on the same link.</t> configured on the same link.</t>
<t>The subtree of the 'routing-protocols' is shown in <xref target="ro
<t>The subtree of the 'routing-protocols' is shown in <xref uting" format="default"/>.</t>
target="routing"></xref>.</t> <figure anchor="routing">
<name>Routing Subtree Structure</name>
<t><figure align="center" anchor="routing" <sourcecode name="" type="yangtree"><![CDATA[ ...
title="Routing Subtree Structure">
<artwork align="center"><![CDATA[ ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| +--rw id string | +--rw id string
| +--rw type? identityref | +--rw type? identityref
| +--rw routing-profiles* [id] | +--rw routing-profiles* [id]
| | +--rw id leafref | | +--rw id leafref
| | +--rw type? identityref | | +--rw type? identityref
skipping to change at line 1714 skipping to change at line 1477
| +--rw ospf | +--rw ospf
| | ... | | ...
| +--rw isis | +--rw isis
| | ... | | ...
| +--rw rip | +--rw rip
| | ... | | ...
| +--rw vrrp | +--rw vrrp
| ... | ...
+--rw security +--rw security
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>Multiple routing instances can be defined, each uniquely
<t>Multiple routing instances can be defined; each uniquely
identified by an 'id'. The type of routing instance is indicated in identified by an 'id'. The type of routing instance is indicated in
'type'. The values of these attributes are those defined in <xref 'type'. The values of these attributes are those defined in <xref targ
target="I-D.ietf-opsawg-vpn-common"></xref> ('routing-protocol-type' et="RFC9181" format="default"/> (the 'routing-protocol-type'
identity).</t> identity).</t>
<t>Configuring multiple instances of the same routing protocol does <t>Configuring multiple instances of the same routing protocol does
not automatically imply that, from a device configuration not automatically imply that, from a device configuration
perspective, there will be parallel instances (e.g., multiple perspective, there will be parallel instances (e.g., multiple
processes) running on the PE-CE link. It is up to each processes) running on the PE-CE link. It is up to each
implementation (typically, network orchestration shown in <xref implementation (typically, network orchestration, as shown in <xref ta
target="xml_happy"></xref>) to decide about the appropriate rget="xml_happy" format="default"/>) to decide on the appropriate
configuration as a function of underlying capabilities and service configuration as a function of underlying capabilities and service
provider operational guidelines. As an example, when multiple BGP provider operational guidelines. As an example, when multiple BGP
peers need to be implemented, multiple instances of BGP must be peers need to be implemented, multiple instances of BGP must be
configured as part of this model. However, from a device configured as part of this model. However, from a device
configuration point of view, this could be implemented as: <list configuration point of view, this could be implemented as:</t>
style="symbols"> <ul spacing="normal">
<t>Multiple BGP processes with a single neighbor running in each <li>Multiple BGP processes with a single neighbor running in each
process.</t> process.</li>
<li>A single BGP process with multiple neighbors running.</li>
<t>A single BGP process with multiple neighbors running.</t> <li>A combination thereof.</li>
</ul>
<t>A combination thereof.</t>
</list></t>
<t>Routing configuration does not include low-level policies. Such <t>Routing configuration does not include low-level policies. Such
policies are handled at the device configuration level. Local policies are handled at the device configuration level. Local
policies of a service provider (e.g., filtering) are implemented as policies of a service provider (e.g., filtering) are implemented as
part of the device configuration; these are not captured in the part of the device configuration; these are not captured in the
L3NM, but the model allows local profiles to be associated with L3NM, but the model allows local profiles to be associated with
routing instances ('routing-profiles'). Note that these routing routing instances ('routing-profiles'). Note that these routing
profiles can be scoped to capture parameters that are globally profiles can be scoped to capture parameters that are globally
applied to all L3VPN services within a service provider network, applied to all L3VPN services within a service provider network,
while customized L3VPN parameters are captured by means of the L3NM. while customized L3VPN parameters are captured by means of the L3NM.
The provisioning of an L3VPN service will, thus, rely upon the The provisioning of an L3VPN service will thus rely upon the
instantiation of these global routing profiles and the customized instantiation of these global routing profiles and the customized
L3NM.</t> L3NM.</t>
<section numbered="true" toc="default">
<section title="Static Routing"> <name>Static Routing</name>
<t>The L3NM supports the configuration of one or more IPv4/IPv6 <t>The L3NM supports the configuration of one or more IPv4/IPv6
static routes. Since the same structure is used for both IPv4 and static routes. Since the same structure is used for both IPv4 and
IPv6, it was considered to have one single container to group both IPv6, using one single container to group both
static entries independently of their address family, but that static entries independently of their address family was considered
design was abandoned to ease the mapping with the structure in at one time, but that
<xref target="RFC8299"></xref>.</t> design was abandoned to ease the mapping, using the structure provid
ed in
<xref target="RFC8299" format="default"/>.</t>
<t><figure align="center" anchor="routing-static" <t>The static routing subtree structure is shown in <xref target="ro
title="Static Routing Subtree Structure"> uting-static"/>.</t>
<artwork align="center"><![CDATA[... <figure anchor="routing-static">
<name>Static Routing Subtree Structure</name>
<sourcecode name="" type="yangtree"><![CDATA[...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| ... | ...
| +--rw static | +--rw static
| | +--rw cascaded-lan-prefixes | | +--rw cascaded-lan-prefixes
| | +--rw ipv4-lan-prefixes* | | +--rw ipv4-lan-prefixes*
| | | [lan next-hop] | | | [lan next-hop]
| | | {vpn-common:ipv4}? | | | {vpn-common:ipv4}?
| | | +--rw lan inet:ipv4-prefix | | | +--rw lan inet:ipv4-prefix
| | | +--rw lan-tag? string | | | +--rw lan-tag? string
skipping to change at line 1805 skipping to change at line 1562
| | +--rw metric? uint32 | | +--rw metric? uint32
| | +--rw preference? uint32 | | +--rw preference? uint32
| | +--rw status | | +--rw status
| | +--rw admin-status | | +--rw admin-status
| | | +--rw status? identityref | | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time | | | +--rw last-change? yang:date-and-time
| | +--ro oper-status | | +--ro oper-status
| | +--ro status? identityref | | +--ro status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>As depicted in <xref target="routing-static" format="default"/>,
<t>As depicted in <xref target="routing-static"></xref>, the the
following data nodes can be defined for a given IP prefix:<list following data nodes can be defined for a given IP prefix:</t>
style="hanging"> <dl newline="false" spacing="normal">
<t hangText="'lan-tag':">Indicates a local tag (e.g., <dt>'lan-tag':</dt>
"myfavourite-lan") that is used to enforce local policies.</t> <dd>Indicates a local tag (e.g.,
"myfavorite-lan") that is used to enforce local policies.</dd>
<t hangText="'next-hop':">Indicates the next-hop to be used <dt>'next-hop':</dt>
<dd>Indicates the next hop to be used
for the static route. It can be identified by an IP address, for the static route. It can be identified by an IP address,
an interface, etc.</t> a predefined next-hop type (e.g., 'discard' or 'local-link'), et
c.</dd>
<t hangText="'bfd-enable':">Indicates whether BFD is enabled <dt>'bfd-enable':</dt>
or disabled for this static route entry.</t> <dd>Indicates whether BFD is enabled
or disabled for this static route entry.</dd>
<t hangText="'metric':">Indicates the metric associated with <dt>'metric':</dt>
the static route entry.</t> <dd>Indicates the metric associated with
the static route entry. This metric is used when the route is ex
<t hangText="'preference':">Indicates the preference ported
into an IGP.</dd>
<dt>'preference':</dt>
<dd>Indicates the preference
associated with the static route entry. This preference is associated with the static route entry. This preference is
used to selecting a preferred route among routes to the same used to select a preferred route among routes to the same
destination prefix.</t> destination prefix.</dd>
<dt>'status':</dt>
<t hangText="'status':">Used to convey the status of a static <dd>Used to convey the status of a static
route entry. This data node can also be used to control the route entry. This data node can also be used to control the
(de)activation of individual static route entries.</t> (de)activation of individual static route entries.</dd>
</list></t> </dl>
<t></t>
</section> </section>
<section numbered="true" toc="default">
<section title="BGP"> <name>BGP</name>
<t>The L3NM allows the configuration of a BGP neighbor, including <t>The L3NM allows the configuration of a BGP neighbor, including
a set for parameters that are pertinent to be tweaked at the a set of parameters that are pertinent to be tweaked at the
network level for service customization purposes. <vspace network level for service customization purposes. The 'bgp' containe
blankLines="1" />The 'bgp' container does not aim to include every r does not aim to include every
BGP parameter; a comprehensive set of parameters belongs more to BGP parameter; a comprehensive set of parameters belongs more to
the BGP device model. <figure align="center" anchor="routing-bgp" the BGP device model.</t>
title="BGP Routing Subtree Structure"> <t>The BGP routing subtree structure is shown in <xref target="routi
<artwork align="center"><![CDATA[... ng-bgp"/>.</t>
<figure anchor="routing-bgp">
<name>BGP Routing Subtree Structure</name>
<sourcecode name="" type="yangtree"><![CDATA[...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| ... | ...
| +--rw bgp | +--rw bgp
| | +--rw description? string | | +--rw description? string
| | +--rw local-as? inet:as-number | | +--rw local-as? inet:as-number
| | +--rw peer-as inet:as-number | | +--rw peer-as inet:as-number
| | +--rw address-family? identityref | | +--rw address-family? identityref
| | +--rw local-address? union | | +--rw local-address? union
| | +--rw neighbor* inet:ip-address | | +--rw neighbor* inet:ip-address
skipping to change at line 1873 skipping to change at line 1630
| | +--rw redistribute-connected* [address-family] | | +--rw redistribute-connected* [address-family]
| | | +--rw address-family identityref | | | +--rw address-family identityref
| | | +--rw enable? boolean | | | +--rw enable? boolean
| | +--rw bgp-max-prefix | | +--rw bgp-max-prefix
| | | +--rw max-prefix? uint32 | | | +--rw max-prefix? uint32
| | | +--rw warning-threshold? decimal64 | | | +--rw warning-threshold? decimal64
| | | +--rw violate-action? enumeration | | | +--rw violate-action? enumeration
| | | +--rw restart-timer? uint32 | | | +--rw restart-timer? uint32
| | +--rw bgp-timers | | +--rw bgp-timers
| | | +--rw keepalive? uint16 | | | +--rw keepalive? uint16
| | | +--rw hold-time? uint16 | | | +--rw hold-time? uint16
| | +--rw authentication | | +--rw authentication
| | | +--rw enable? boolean | | | +--rw enable? boolean
| | | +--rw keying-material | | | +--rw keying-material
| | | +--rw (option)? | | | +--rw (option)?
| | | +--:(ao) | | | +--:(ao)
| | | | +--rw enable-ao? boolean | | | | +--rw enable-ao? boolean
| | | | +--rw ao-keychain? key-chain:key-chain-ref | | | | +--rw ao-keychain? key-chain:key-chain-ref
| | | +--:(md5) | | | +--:(md5)
| | | | +--rw md5-keychain? key-chain:key-chain-ref | | | | +--rw md5-keychain? key-chain:key-chain-ref
| | | +--:(explicit) | | | +--:(explicit)
| | | | +--rw key-id? uint32 | | | | +--rw key-id? uint32
| | | | +--rw key? string | | | | +--rw key? string
| | | | +--rw crypto-algorithm? identityref | | | | +--rw crypto-algorithm? identityref
| | | +--:(ipsec) | | | +--:(ipsec)
| | | +--rw sa? string | | | +--rw sa? string
| | +--rw status | | +--rw status
| | +--rw admin-status | | +--rw admin-status
| | | +--rw status? identityref | | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time | | | +--rw last-change? yang:date-and-time
| | +--ro oper-status | | +--ro oper-status
| | +--ro status? identityref | | +--ro status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>The following data nodes are captured in <xref target="routing-bg
<t>The following data nodes are captured in <xref p" format="default"/>. It is up to the implementation
target="routing-bgp"></xref>. It is up to the implementation
(e.g., network orchestrator) to derive the corresponding BGP (e.g., network orchestrator) to derive the corresponding BGP
device configuration:<list style="hanging"> device configuration:</t>
<t hangText="'description':">Includes a description of the BGP <dl newline="false" spacing="normal">
session.</t> <dt>'description':</dt>
<dd>Includes a description of the BGP
<t hangText="'local-as':">Indicates a local AS Number (ASN) if session.</dd>
a distinct ASN is required, other than the one configured at <dt>'local-as':</dt>
the VPN node level.</t> <dd>Indicates a local AS Number (ASN), if
a distinct ASN is required other than the ASN configured at
<t hangText="'peer-as':">Conveys the customer's ASN.</t> the VPN node level.</dd>
<dt>'peer-as':</dt>
<t hangText="'address-family':">Indicates the address-family <dd>Conveys the customer's ASN.</dd>
of the peer. It can be set to IPv4, IPv6, or dual-stack. <dt>'address-family':</dt>
<vspace blankLines="1" />This address family will be used <dd>
<t>Indicates the address family
of the peer. It can be set to 'ipv4', 'ipv6', or 'dual-stack'.
</t>
<t>This address family will be used
together with the 'vpn-type' to derive the appropriate Address together with the 'vpn-type' to derive the appropriate Address
Family Identifiers (AFIs)/Subsequent Address Family Family Identifiers (AFIs) / Subsequent Address Family
Identifiers (SAFIs) that will be part of the derived device Identifiers (SAFIs) that will be part of the derived device
configurations (e.g., Unicast IPv4 MPLS L3VPN (AFI,SAFI = configurations (e.g., unicast IPv4 MPLS L3VPN (AFI,SAFI =
1,128) defined in Section 4.3.4 of <xref 1,128) as defined in <xref target="RFC4364" sectionFormat="of" s
target="RFC4364"></xref>).</t> ection="4.3.4"/>).</t>
</dd>
<t hangText="'local-address':">Specifies an address or a <dt>'local-address':</dt>
<dd>Specifies an address or a
reference to an interface to use when establishing the BGP reference to an interface to use when establishing the BGP
transport session.</t> transport session.</dd>
<dt>'neighbor':</dt>
<t hangText="'neighbor':">Can indicate two neighbors (each for <dd>Can indicate two neighbors (each for
a given address-family) or one neighbor (if 'address-family' a given address family) or one neighbor (if the 'address-family'
attribute is set to dual-stack). A list of IP address(es) of attribute is set to 'dual-stack'). A list of IP address(es) of
the BGP neighbors can be then conveyed in this data node.</t> the BGP neighbor(s) can then be conveyed in this data node.</dd>
<dt>'multihop':</dt>
<t hangText="'multihop':">Indicates the number of allowed IP <dd>Indicates the number of allowed IP
hops between a PE and its BGP peer.</t> hops between a PE and its BGP peer.</dd>
<dt>'as-override':</dt>
<t hangText="'as-override':">If set, this parameter indicates <dd>If set, this parameter indicates
whether ASN override is enabled, i.e., replace the ASN of the whether ASN override is enabled, i.e., replacing the ASN of the
customer specified in the AS_PATH BGP attribute with the ASN customer specified in the AS_PATH BGP attribute with the ASN
identified in the 'local-as' attribute.</t> identified in the 'local-as' attribute.</dd>
<dt>'allow-own-as':</dt>
<t hangText="'allow-own-as':">Is used in some topologies <dd>Used in some topologies
(e.g., hub-and-spoke) to allow the provider's ASN to be (e.g., hub-and-spoke) to allow the provider's ASN to be
included in the AS_PATH BGP attribute received from a CE. included in the AS_PATH BGP attribute received from a CE.
Loops are prevented by setting 'allow-own-as' to a maximum Loops are prevented by setting 'allow-own-as' to a maximum
number of provider's ASN occurrences. This parameter is set by number of the provider's ASN occurrences. By default, this param
default to '0' (that is, reject any AS_PATH attribute that eter is set to '0' (that is, reject any AS_PATH attribute that
includes the provider's ASN).</t> includes the provider's ASN).</dd>
<dt>'prepend-global-as':</dt>
<t hangText="'prepend-global-as':">When distinct ASNs are <dd>When distinct ASNs are
configured in the VPN node and network access levels, this configured at the VPN node and network access levels, this
parameter controls whether the ASN provided at the VPN node parameter controls whether the ASN provided at the VPN node
level is prepended to the AS_PATH attribute.</t> level is prepended to the AS_PATH attribute.</dd>
<dt>'send-default-route':</dt>
<t hangText="'send-default-route':">Controls whether default <dd>Controls whether default
routes can be advertised to the peer.</t> routes can be advertised to the peer.</dd>
<dt>'site-of-origin':</dt>
<t hangText="'site-of-origin':">Is meant to uniquely identify <dd>Meant to uniquely identify
the set of routes learned from a site via a particular CE/PE the set of routes learned from a site via a particular CE-PE
connection and is used to prevent routing loops (Section 7 of connection. It is used to prevent routing loops (<xref target="R
<xref target="RFC4364"></xref>). The Site of Origin attribute FC4364" sectionFormat="of" section="7"/>). The Site of Origin attribute
is encoded as a Route Origin Extended Community.</t> is encoded as a Route Origin Extended Community.</dd>
<dt>'ipv6-site-of-origin':</dt>
<t hangText="'ipv6-site-of-origin':">Carries an IPv6 Address <dd>Carries an IPv6 Address
Specific BGP Extended Community that is used to indicate the Specific BGP Extended Community that is used to indicate the
Site of Origin for VRF information <xref Site of Origin for VRF information <xref target="RFC5701" format
target="RFC5701"></xref>. It is used to prevent routing ="default"/>. It is used to prevent routing
loops.</t> loops.</dd>
<dt>'redistribute-connected':</dt>
<t hangText="'redistribute-connected':">Controls whether the <dd>Controls whether the
PE-CE link is advertised to other PEs.</t> PE-CE link is advertised to other PEs.</dd>
<dt>'bgp-max-prefix':</dt>
<t hangText="'bgp-max-prefix':">Controls the behavior when a <dd>
prefix maximum is reached.<list style="hanging"> <t>Controls the behavior when a
<t hangText="'max-prefix':">Indicates the maximum number prefix maximum is reached.</t>
<dl newline="false" spacing="normal">
<dt>'max-prefix':</dt>
<dd>Indicates the maximum number
of BGP prefixes allowed in the BGP session. If the limit of BGP prefixes allowed in the BGP session. If the limit
is reached, the action indicated in 'violate-action' will is reached, the action indicated in 'violate-action' will
be followed.</t> be followed.</dd>
<dt>'warning-threshold':</dt>
<t hangText="'warning-threshold':">A warning notification <dd>A warning notification
is triggered when this limit is reached.</t> is triggered when this limit is reached.</dd>
<dt>'violate-action':</dt>
<t hangText="'violate-action':">Indicates which action to <dd>Indicates which action to
execute when the maximum number of BGP prefixes is execute when the maximum number of BGP prefixes is
reached. Examples of such actions are: send a warning reached. Examples of such actions include sending a warning
message, discard extra paths from the peer, or restart the message, discarding extra paths from the peer, or restarting
session.</t> the
session.</dd>
<t hangText="'restart-timer':">Indicates, in seconds, the <dt>'restart-timer':</dt>
<dd>Indicates, in seconds, the
time interval after which the BGP session will be time interval after which the BGP session will be
reestablished.</t> reestablished.</dd>
</list></t> </dl>
</dd>
<t hangText="'bgp-timers': ">Two timers can be captured in <dt>'bgp-timers':</dt>
this container: (1) 'hold-time' which is the time interval <dd>Two timers can be captured in
that will be used for the HoldTimer (Section 4.2 of <xref this container: (1) 'hold-time', which is the time interval
target="RFC4271"></xref>) when establishing a BGP session. (2) that will be used for the Hold Timer (<xref target="RFC4271" sec
'keepalive' which is the time interval for the KeepAlive timer tionFormat="of" section="4.2"/>) when establishing a BGP session and (2)
between a PE and a BGP peer (Section 4.4 of <xref 'keepalive', which is the time interval for the KeepaliveTimer
target="RFC4271"></xref>). Both timers are expressed in between a PE and a BGP peer (<xref target="RFC4271" sectionForma
seconds.</t> t="of" section="4.4"/>). Both timers are expressed in seconds.</dd>
<dt>'authentication':</dt>
<t hangText="'authentication':">The module adheres to the <dd>
recommendations in Section 13.2 of <xref <t>The module adheres to the
target="RFC4364"></xref> as it allows enabling TCP-AO <xref recommendations in <xref target="RFC4364" sectionFormat="of" sec
target="RFC5925"></xref> and accommodates the installed base tion="13.2"/>, as it allows enabling the TCP Authentication Option (TCP-AO) <xre
f target="RFC5925" format="default"/> and accommodates the installed base
that makes use of MD5. In addition, the module includes a that makes use of MD5. In addition, the module includes a
provision for the use of IPsec.<vspace blankLines="1" />This provision for using IPsec.</t>
version of the L3NM assumes that TCP-AO specific parameters <t>This
are preconfigured as part of the key-chain that is referenced version of the L3NM assumes that parameters specific to the TCP-
in the L3NM. No assumption is made about how such a key-chain AO are preconfigured as part of the key chain that is referenced
is pre-configured. However, the structure of the key-chain in the L3NM. No assumption is made about how such a key chain
should cover data nodes beyond those in <xref is preconfigured. However, the structure of the key chain
target="RFC8177"></xref>, mainly SendID and RecvID (Section should cover data nodes beyond those in <xref target="RFC8177" f
3.1 of <xref target="RFC5925"></xref>).</t> ormat="default"/>, mainly SendID and RecvID (<xref target="RFC5925" sectionForma
t="of" section="3.1"/>).</t>
<t hangText="'status':">Indicates the status of the BGP </dd>
routing instance.</t> <dt>'status':</dt>
</list></t> <dd>Indicates the status of the BGP
routing instance.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="OSPF"> <name>OSPF</name>
<t>OSPF can be configured to run as a routing protocol on the <t>OSPF can be configured to run as a routing protocol on the
'vpn-network-access'. <figure align="center" anchor="routing-ospf" 'vpn-network-access'.</t>
title="OPSF Routing Subtree Structure"> <t>The OSPF routing subtree structure is shown in <xref target="rout
<artwork align="center"><![CDATA[... ing-ospf"/>.</t>
<figure anchor="routing-ospf">
<name>OSPF Routing Subtree Structure</name>
<sourcecode name="" type="yangtree"><![CDATA[...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| ... | ...
| +--rw ospf | +--rw ospf
| | +--rw address-family? identityref | | +--rw address-family? identityref
| | +--rw area-id yang:dotted-quad | | +--rw area-id yang:dotted-quad
| | +--rw metric? uint16 | | +--rw metric? uint16
| | +--rw sham-links {vpn-common:rtg-ospf-sham-link}? | | +--rw sham-links {vpn-common:rtg-ospf-sham-link}?
| | | +--rw sham-link* [target-site] | | | +--rw sham-link* [target-site]
| | | +--rw target-site | | | +--rw target-site string
| | | | vpn-common:vpn-id
| | | +--rw metric? uint16 | | | +--rw metric? uint16
| | +--rw max-lsa? uint32 | | +--rw max-lsa? uint32
| | +--rw authentication | | +--rw authentication
| | | +--rw enable? boolean | | | +--rw enable? boolean
| | | +--rw keying-material | | | +--rw keying-material
| | | +--rw (option)? | | | +--rw (option)?
| | | +--:(auth-key-chain) | | | +--:(auth-key-chain)
| | | | +--rw key-chain? | | | | +--rw key-chain?
| | | | key-chain:key-chain-ref | | | | key-chain:key-chain-ref
| | | +--:(auth-key-explicit) | | | +--:(auth-key-explicit)
skipping to change at line 2060 skipping to change at line 1816
| | | +--:(ipsec) | | | +--:(ipsec)
| | | +--rw sa? string | | | +--rw sa? string
| | +--rw status | | +--rw status
| | +--rw admin-status | | +--rw admin-status
| | | +--rw status? identityref | | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time | | | +--rw last-change? yang:date-and-time
| | +--ro oper-status | | +--ro oper-status
| | +--ro status? identityref | | +--ro status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>The following data nodes are captured in <xref target="routing-os
<t>The following data nodes are captured in <xref pf" format="default"/>:</t>
target="routing-ospf"></xref>:<list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="'address-family':">Indicates whether IPv4, IPv6, <dt>'address-family':</dt>
or both address families are to be activated. <vspace <dd>
blankLines="1" />When the IPv4 or dual-stack address-family is <t>Indicates whether IPv4, IPv6,
or both address families are to be activated. </t>
<t>When the IPv4 or dual-stack address family is
requested, it is up to the implementation (e.g., network requested, it is up to the implementation (e.g., network
orchestrator) to decide whether OSPFv2 <xref orchestrator) to decide whether OSPFv2 <xref target="RFC4577" fo
target="RFC4577"></xref> or OSPFv3 <xref rmat="default"/> or OSPFv3 <xref target="RFC6565" format="default"/> is used to
target="RFC6565"></xref> is used to announce IPv4 routes. Such announce IPv4 routes. Such a
decision will be typically reflected in the device decision will typically be reflected in the device
configurations that will be derived to implement the configurations that will be derived to implement the
L3VPN.</t> L3VPN.</t>
</dd>
<t hangText="'area-id':">Indicates the OSPF Area ID.</t> <dt>'area-id':</dt>
<dd>Indicates the OSPF Area ID.</dd>
<t hangText="'metric':">Associates a metric with OSPF <dt>'metric':</dt>
routes.</t> <dd>Associates a metric with OSPF
routes.</dd>
<t hangText="'sham-links':">Is used to create OSPF sham links <dt>'sham-links':</dt>
<dd>Used to create OSPF sham links
between two VPN network accesses sharing the same area and between two VPN network accesses sharing the same area and
having a backdoor link (Section 4.2.7 of <xref having a backdoor link (<xref target="RFC4577" sectionFormat="of
target="RFC4577"></xref> and Section 5 of <xref " section="4.2.7"/> and <xref target="RFC6565" sectionFormat="of" section="5"/>)
target="RFC6565"></xref>).</t> .</dd>
<dt>'max-lsa':</dt>
<t hangText="'max-lsa':">Sets the maximum number of LSAs that <dd>Sets the maximum number of Link State Advertisements (LSAs) th
the OSPF instance will accept.</t> at
the OSPF instance will accept.</dd>
<t hangText="'authentication':">Controls the authentication <dt>'authentication':</dt>
<dd>Controls the authentication
schemes to be enabled for the OSPF instance. The following schemes to be enabled for the OSPF instance. The following
options are supported: IPsec for OSPFv3 authentication <xref options are supported: IPsec for OSPFv3 authentication <xref tar
target="RFC4552"></xref>, authentication trailer for OSPFv2 get="RFC4552" format="default"/>, and the Authentication Trailer for OSPFv2
<xref target="RFC5709"></xref> <xref target="RFC7474"></xref> <xref target="RFC5709" format="default"/> <xref target="RFC7474"
and OSPFv3 <xref target="RFC7166"></xref>.</t> format="default"/>
and OSPFv3 <xref target="RFC7166" format="default"/>.</dd>
<t hangText="'status':">Indicates the status of the OSPF <dt>'status':</dt>
routing instance.</t> <dd>Indicates the status of the OSPF
</list></t> routing instance.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="IS-IS"> <name>IS-IS</name>
<t>The model (<xref target="routing-isis"></xref>) allows the user <t>The model allows the user
to configure IS-IS <xref target="ISO10589"></xref><xref to configure IS-IS <xref target="ISO10589" format="default"/> <xref
target="RFC1195"></xref><xref target="RFC5308"></xref> to run on target="RFC1195" format="default"/> <xref target="RFC5308" format="default"/> to
the 'vpn-network-access' interface.<figure align="center" run on
anchor="routing-isis" title="IS-IS Routing Subtree Structure"> the 'vpn-network-access' interface. See <xref target="routing-isis"
<artwork align="center"><![CDATA[... format="default"/>.</t>
<figure anchor="routing-isis">
<name>IS-IS Routing Subtree Structure</name>
<sourcecode name="" type="yangtree"><![CDATA[...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| ... | ...
| +--rw isis | +--rw isis
| | +--rw address-family? identityref | | +--rw address-family? identityref
| | +--rw area-address area-address | | +--rw area-address area-address
| | +--rw level? identityref | | +--rw level? identityref
| | +--rw metric? uint16 | | +--rw metric? uint16
| | +--rw mode? enumeration | | +--rw mode? enumeration
| | +--rw authentication | | +--rw authentication
skipping to change at line 2137 skipping to change at line 1890
| | | +--rw key? string | | | +--rw key? string
| | | +--rw crypto-algorithm? identityref | | | +--rw crypto-algorithm? identityref
| | +--rw status | | +--rw status
| | +--rw admin-status | | +--rw admin-status
| | | +--rw status? identityref | | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time | | | +--rw last-change? yang:date-and-time
| | +--ro oper-status | | +--ro oper-status
| | +--ro status? identityref | | +--ro status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>The following IS-IS data nodes are supported:</t>
<t>The following IS-IS data nodes are supported:<list <dl newline="false" spacing="normal">
style="hanging"> <dt>'address-family':</dt>
<t hangText="'address-family':">Indicates whether IPv4, IPv6, <dd>Indicates whether IPv4, IPv6,
or both address families are to be activated.</t> or both address families are to be activated.</dd>
<dt>'area-address':</dt>
<t hangText="'area-address':">Indicates the IS-IS area <dd>Indicates the IS-IS area
address.</t> address.</dd>
<dt>'level':</dt>
<t hangText="'level':">Indicates the IS-IS level: Level 1, <dd>Indicates the IS-IS level: Level 1,
Level 2, or both.</t> Level 2, or both.</dd>
<dt>'metric':</dt>
<t hangText="'metric':">Associates a metric with IS-IS <dd>Associates a metric with IS-IS
routes.</t> routes.</dd>
<dt>'mode':</dt>
<t hangText="'mode':">Indicates the IS-IS interface mode type. <dd>Indicates the IS-IS interface mode type.
It can be set to 'active' (that is, send or receive IS-IS It can be set to 'active' (that is, send or receive IS-IS
protocol control packets) or 'passive' (that is, suppress the protocol control packets) or 'passive' (that is, suppress the
sending of IS-IS updates through the interface).</t> sending of IS-IS updates through the interface).</dd>
<dt>'authentication':</dt>
<t hangText="'authentication':">Controls the authentication <dd>Controls the authentication
schemes to be enabled for the IS-IS instance. Both the schemes to be enabled for the IS-IS instance. Both the
specification of a key-chain <xref target="RFC8177"></xref> specification of a key chain <xref target="RFC8177" format="defa ult"/>
and the direct specification of key and authentication and the direct specification of key and authentication
algorithm are supported.</t> algorithms are supported.</dd>
<dt>'status':</dt>
<t hangText="'status':">Indicates the status of the IS-IS <dd>Indicates the status of the IS-IS
routing instance.</t> routing instance.</dd>
</list></t> </dl>
</section> </section>
<section numbered="true" toc="default">
<section title="RIP"> <name>RIP</name>
<t>The model (<xref target="rip"></xref>) allows the user to <t>The model allows the user to
configure RIP to run on the 'vpn-network-access' interface. configure RIP to run on the 'vpn-network-access' interface. See
<figure align="center" anchor="rip" title="RIP Subtree Structure"> <xref target="rip" format="default"/>.</t>
<artwork align="center"><![CDATA[... <figure anchor="rip">
<name>RIP Subtree Structure</name>
<sourcecode name="" type="yangtree"><![CDATA[...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| ... | ...
| +--rw rip | +--rw rip
| | +--rw address-family? identityref | | +--rw address-family? identityref
| | +--rw timers | | +--rw timers
| | | +--rw update-interval? uint16 | | | +--rw update-interval? uint16
| | | +--rw invalid-interval? uint16 | | | +--rw invalid-interval? uint16
| | | +--rw holddown-interval? uint16 | | | +--rw holddown-interval? uint16
| | | +--rw flush-interval? uint16 | | | +--rw flush-interval? uint16
| | +--rw neighbor* inet:ip-address
| | +--rw default-metric? uint8 | | +--rw default-metric? uint8
| | +--rw authentication | | +--rw authentication
| | | +--rw enable? boolean | | | +--rw enable? boolean
| | | +--rw keying-material | | | +--rw keying-material
| | | +--rw (option)? | | | +--rw (option)?
| | | +--:(auth-key-chain) | | | +--:(auth-key-chain)
| | | | +--rw key-chain? | | | | +--rw key-chain?
| | | | key-chain:key-chain-ref | | | | key-chain:key-chain-ref
| | | +--:(auth-key-explicit) | | | +--:(auth-key-explicit)
| | | +--rw key? string | | | +--rw key? string
| | | +--rw crypto-algorithm? identityref | | | +--rw crypto-algorithm? identityref
| | +--rw status | | +--rw status
| | +--rw admin-status | | +--rw admin-status
| | | +--rw status? identityref | | | +--rw status? identityref
| | | +--rw last-change? yang:date-and-time | | | +--rw last-change? yang:date-and-time
| | +--ro oper-status | | +--ro oper-status
| | +--ro status? identityref | | +--ro status? identityref
| | +--ro last-change? yang:date-and-time | | +--ro last-change? yang:date-and-time
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>As shown in <xref target="rip" format="default"/>, the following
<t>As shown in <xref target="rip"></xref>, the following RIP data RIP data
nodes are supported:<list style="hanging"> nodes are supported:</t>
<t hangText="'address-family':">Indicates whether IPv4, IPv6, <dl newline="false" spacing="normal">
<dt>'address-family':</dt>
<dd>Indicates whether IPv4, IPv6,
or both address families are to be activated. This parameter or both address families are to be activated. This parameter
is used to determine whether RIPv2 <xref is used to determine whether RIPv2 <xref target="RFC2453" format
target="RFC2453"></xref> and/or RIPng are to be enabled <xref ="default"/>, RIP Next Generation (RIPng), or both are to be enabled <xref targe
target="RFC2080"></xref>.</t> t="RFC2080" format="default"/>.</dd>
<dt>'timers':</dt>
<t hangText="'timers':">Indicates the following timers:<list <dd>
style="hanging"> <t>Indicates the following timers:</t>
<t hangText="'update-interval':">Is the interval at which <dl newline="false" spacing="normal">
RIP updates are sent.</t> <dt>'update-interval':</dt>
<dd>The interval at which
<t hangText="'invalid-interval':">Is the interval before a RIP updates are sent.</dd>
RIP route is declared invalid.</t> <dt>'invalid-interval':</dt>
<dd>The interval before a
<t hangText="'holddown-interval':">Is the interval before RIP route is declared invalid.</dd>
better RIP routes are released.</t> <dt>'holddown-interval':</dt>
<dd>The interval before
<t hangText="'flush-interval':">Is the interval before a better RIP routes are released.</dd>
route is removed from the routing table.</t> <dt>'flush-interval':</dt>
</list>These timers are expressed in seconds.</t> <dd>The interval before a
route is removed from the routing table.</dd>
<t hangText="'default-metric':">Sets the default RIP </dl>
metric.</t> <t>These timers are expressed in seconds.</t>
</dd>
<t hangText="'authentication':">Controls the authentication <dt>'default-metric':</dt>
schemes to be enabled for the RIP instance.</t> <dd>Sets the default RIP
metric.</dd>
<t hangText="'status':">Indicates the status of the RIP <dt>'authentication':</dt>
routing instance.</t> <dd>Controls the authentication
</list></t> schemes to be enabled for the RIP instance.</dd>
<dt>'status':</dt>
<dd>Indicates the status of the RIP
routing instance.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="VRRP"> <name>VRRP</name>
<t>The model (<xref target="vrrp"></xref>) allows enabling VRRP on <t>The model allows enabling the Virtual Router Redundancy Protocol
the 'vpn-network-access' interface. <figure align="center" (VRRP) on
anchor="vrrp" title="VRRP Subtree Structure"> the 'vpn-network-access' interface. See <xref target="vrrp" format="
<artwork align="center"><![CDATA[... default"/>.</t>
<figure anchor="vrrp">
<name>VRRP Subtree Structure</name>
<sourcecode name="" type="yangtree"><![CDATA[...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| ... | ...
| +--rw vrrp | +--rw vrrp
| +--rw address-family* identityref | +--rw address-family* identityref
| +--rw vrrp-group? uint8 | +--rw vrrp-group? uint8
| +--rw backup-peer? inet:ip-address | +--rw backup-peer? inet:ip-address
| +--rw virtual-ip-address* inet:ip-address | +--rw virtual-ip-address* inet:ip-address
| +--rw priority? uint8 | +--rw priority? uint8
| +--rw ping-reply? boolean | +--rw ping-reply? boolean
| +--rw status | +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>The following data nodes are supported:</t>
<t>The following data nodes are supported:<list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="'address-family':">Indicates whether IPv4, IPv6, <dt>'address-family':</dt>
<dd>Indicates whether IPv4, IPv6,
or both address families are to be activated. Note that VRRP or both address families are to be activated. Note that VRRP
version 3 <xref target="RFC5798"></xref> supports both IPv4 version 3 <xref target="RFC5798" format="default"/> supports bot
and IPv6.</t> h IPv4
and IPv6.</dd>
<t hangText="'vrrp-group':">Is used to identify the VRRP <dt>'vrrp-group':</dt>
group.</t> <dd>Used to identify the VRRP
group.</dd>
<t hangText="'backup-peer':">Carries the IP address of the <dt>'backup-peer':</dt>
peer.</t> <dd>Carries the IP address of the
peer.</dd>
<t hangText="'virtual-ip-address':">Includes virtual IP <dt>'virtual-ip-address':</dt>
addresses for a single VRRP group.</t> <dd>Includes virtual IP
addresses for a single VRRP group.</dd>
<t hangText="'priority':">Assigns the VRRP election priority <dt>'priority':</dt>
for the backup virtual router.</t> <dd>Assigns the VRRP election priority
for the backup virtual router.</dd>
<t hangText="'ping-reply':">Controls whether ping requests can <dt>'ping-reply':</dt>
be replied to.</t> <dd>Controls whether the VRRP speaker should
reply to ping requests.</dd>
<t hangText="'status':">Indicates the status of the VRRP <dt>'status':</dt>
instance.</t> <dd>Indicates the status of the VRRP
</list>Note that no authentication data node is included for instance.</dd>
VRRP as there isn't currently any type of VRRP authentication (see </dl>
Section 9 of <xref target="RFC5798"></xref>).</t> <t>Note that no authentication data node is included for
VRRP, as there isn't any type of VRRP authentication at this time (s
ee
<xref target="RFC5798" sectionFormat="of" section="9"/>).</t>
</section> </section>
</section> </section>
<section anchor="sec-oam" numbered="true" toc="default">
<section anchor="sec-oam" title="OAM"> <name>OAM</name>
<t>This container (<xref target="oam"></xref>) defines the <t>This container (<xref target="oam" format="default"/>) defines the
Operations, Administration, and Maintenance (OAM) mechanisms used Operations, Administration, and Maintenance (OAM) mechanisms used
for a VPN network access. In the current version of the L3NM, only for a VPN network access. In the current version of the L3NM, only
BFD is supported.</t> BFD is supported.</t>
<figure anchor="oam">
<t><figure align="center" anchor="oam" <name>IP Connection Subtree Structure (OAM)</name>
title="IP Connection Subtree Structure (OAM)"> <sourcecode name="" type="yangtree"><![CDATA[...
<artwork align="center"><![CDATA[...
+--rw oam +--rw oam
| +--rw bfd {vpn-common:bfd}? | +--rw bfd {vpn-common:bfd}?
| +--rw session-type? identityref | +--rw session-type? identityref
| +--rw desired-min-tx-interval? uint32 | +--rw desired-min-tx-interval? uint32
| +--rw required-min-rx-interval? uint32 | +--rw required-min-rx-interval? uint32
| +--rw local-multiplier? uint8 | +--rw local-multiplier? uint8
| +--rw holdtime? uint32 | +--rw holdtime? uint32
| +--rw profile? leafref | +--rw profile? leafref
| +--rw authentication! | +--rw authentication!
| | +--rw key-chain? key-chain:key-chain-ref | | +--rw key-chain? key-chain:key-chain-ref
| | +--rw meticulous? boolean | | +--rw meticulous? boolean
| +--rw status | +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
... ]]></artwork> ...
</figure></t> ]]></sourcecode>
</figure>
<t>The following OAM data nodes can be specified:</t> <t>The following OAM data nodes can be specified:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>'session-type':</dt>
<t hangText="'session-type':">Indicates which BFD flavor is used <dd>Indicates which BFD flavor is used
to set up the session (e.g., classic BFD <xref to set up the session (e.g., classic BFD <xref target="RFC5880" fo
target="RFC5880"></xref>, Seamless BFD <xref rmat="default"/>, Seamless BFD <xref target="RFC7880" format="default"/>). By de
target="RFC7880"></xref>). By default, the BFD session is fault, it is assumed that the BFD session will
assumed to follow the behavior specified in <xref follow the behavior specified in <xref target="RFC5880" format="de
target="RFC5880"></xref>.</t> fault"/>.</dd>
<dt>'desired-min-tx-interval':</dt>
<t hangText="'desired-min-tx-interval':">Is the minimum <dd>The minimum
interval, in microseconds, that a PE would like to use when interval, in microseconds, that a PE would like to use when
transmitting BFD Control packets less any jitter applied.</t> transmitting BFD Control packets, less any jitter applied.</dd>
<dt>'required-min-rx-interval':</dt>
<t hangText="'required-min-rx-interval':">Is the minimum <dd>The minimum
interval, in microseconds, between received BFD Control packets interval, in microseconds, between received BFD Control packets
that a PE is capable of supporting, less any jitter applied by that a PE is capable of supporting, less any jitter applied by
the sender.</t> the sender.</dd>
<dt>'local-multiplier':</dt>
<t hangText="'local-multiplier':">The negotiated transmit <dd>The negotiated transmit
interval, multiplied by this value, provides the detection time interval, multiplied by this value, provides the detection time
for the peer.</t> for the peer.</dd>
<dt>'holdtime':</dt>
<t hangText="'holdtime':">Is used to indicate the expected BFD <dd>Used to indicate the expected BFD
holddown time, in milliseconds. This value may be inherited from holddown time, in milliseconds. This value may be inherited from
the service request (see Section 6.3.2.2.2 of <xref the service request (see <xref target="RFC8299" sectionFormat="of"
target="RFC8299"></xref>).</t> section="6.3.2.2.2"/>).</dd>
<dt>'profile':</dt>
<t hangText="'profile':">Refers to a BFD profile (<xref <dd>Refers to a BFD profile (<xref target="vpn_profiles" format="def
target="vpn_profiles"></xref>). Such a profile can be set by the ault"/>). Such a profile can be set by the
provider or inherited from the service request (see Section provider or inherited from the service request (see <xref target="
6.3.2.2.2 of <xref target="RFC8299"></xref>).</t> RFC8299" sectionFormat="of" section="6.3.2.2.2"/>).</dd>
<dt>'authentication':</dt>
<t hangText="'authentication':">Includes the required <dd>Includes the required
information to enable the BFD authentication modes discussed in information to enable the BFD authentication modes discussed in
Section 6.7 of <xref target="RFC5880"></xref>. In particular <xref target="RFC5880" sectionFormat="of" section="6.7"/>. In part
'meticulous' controls the activation of the meticulous mode icular,
discussed in Sections 6.7.3 and 6.7.4 of <xref 'meticulous' controls the activation of meticulous mode as
target="RFC5880"></xref>.</t> discussed in Sections&nbsp;<xref target="RFC5880" section="6.7.3"
sectionFormat="bare"/> and <xref target="RFC5880" section="6.7.4"
<t hangText="'status':">Indicates the status of BFD.</t> sectionFormat="bare"/> of <xref target="RFC5880"/>.</dd>
</list></t> <dt>'status':</dt>
<dd>Indicates the status of BFD.</dd>
</dl>
</section> </section>
<section anchor="sec" numbered="true" toc="default">
<section anchor="sec" title="Security"> <name>Security</name>
<t>The 'security' container specifies the authentication and the <t>The 'security' container specifies the authentication and the
encryption to be applied for a given VPN network access traffic. As encryption to be applied to traffic for a given VPN network access. As
depicted in the subtree shown in <xref target="security"></xref>, depicted in the subtree shown in <xref target="security" format="defau
the L3NM can be used to directly control the encryption to put in lt"/>,
place (e.g., Layer 2 or Layer 3 encryption) or invoke a local the L3NM can be used to directly control the encryption to be
applied (e.g., Layer 2 or Layer 3 encryption) or invoke a local
encryption profile.</t> encryption profile.</t>
<figure anchor="security">
<t><figure align="center" anchor="security" <name>Security Subtree Structure</name>
title="Security Subtree Structure"> <sourcecode name="" type="yangtree"><![CDATA[ ...
<artwork align="left"><![CDATA[ ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
... ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
+--rw security +--rw security
| +--rw encryption {vpn-common:encryption}? | +--rw encryption {vpn-common:encryption}?
| | +--rw enabled? boolean | | +--rw enabled? boolean
| | +--rw layer? enumeration | | +--rw layer? enumeration
| +--rw encryption-profile | +--rw encryption-profile
| +--rw (profile)? | +--rw (profile)?
| +--:(provider-profile) | +--:(provider-profile)
| | +--rw profile-name? leafref | | +--rw profile-name? leafref
| +--:(customer-profile) | +--:(customer-profile)
| +--rw customer-key-chain? | +--rw customer-key-chain?
| kc:key-chain-ref | key-chain:key-chain-ref
+--rw service +--rw service
... ]]></artwork> ...
</figure></t> ]]></sourcecode>
</figure>
</section> </section>
<section anchor="svc" numbered="true" toc="default">
<section anchor="svc" title="Services"> <name>Services</name>
<section title="Overview"> <section numbered="true" toc="default">
<name>Overview</name>
<t>The 'service' container specifies the service parameters to <t>The 'service' container specifies the service parameters to
apply for a given VPN network access (<xref apply for a given VPN network access (<xref target="services" format
target="services"></xref>).</t> ="default"/>).</t>
<figure anchor="services">
<t><figure align="center" anchor="services" <name>Services Subtree Structure</name>
title="Services Subtree Structure"> <sourcecode name="" type="yangtree"><![CDATA[...
<artwork align="center"><![CDATA[...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
+--rw service +--rw service
+--rw inbound-bandwidth? uint64 {vpn-common:inbound-bw}? +--rw pe-to-ce-bandwidth? uint64 {vpn-common:inbound-bw}?
+--rw outbound-bandwidth? uint64 {vpn-common:outbound-bw}? +--rw ce-to-pe-bandwidth? uint64 {vpn-common:outbound-bw}?
+--rw mtu? uint32 +--rw mtu? uint32
+--rw qos {vpn-common:qos}? +--rw qos {vpn-common:qos}?
| ... | ...
+--rw carriers-carrier +--rw carriers-carrier
| {vpn-common:carriers-carrier}? | {vpn-common:carriers-carrier}?
| +--rw signaling-type? enumeration | +--rw signaling-type? enumeration
+--rw ntp +--rw ntp
| +--rw broadcast? enumeration | +--rw broadcast? enumeration
| +--rw auth-profile | +--rw auth-profile
| | +--rw profile-id? string | | +--rw profile-id? string
| +--rw status | +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw multicast {vpn-common:multicast}? +--rw multicast {vpn-common:multicast}?
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>The following data nodes are defined:</t>
<t>The following data nodes are defined: <list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="'inbound-bandwidth':">Indicates, in bits per <dt>'pe-to-ce-bandwidth':</dt>
second (bps), the inbound bandwidth of the connection (i.e., <dd>Indicates, in bits per
download bandwidth from the service provider to the site).</t> second (bps), the inbound bandwidth of the connection (i.e., the
download bandwidth from the service provider to the site).</dd>
<t hangText="'outbound-bandwidth':">Indicates, in bps, the <dt>'ce-to-pe-bandwidth':</dt>
outbound bandwidth of the connection (i.e., upload bandwidth <dd>Indicates, in bps, the
from the site to the service provider).</t> outbound bandwidth of the connection (i.e., the upload bandwidth
from the site to the service provider).</dd>
<t hangText="'mtu':">Indicates the MTU at the service <dt>'mtu':</dt>
level.</t> <dd>Indicates the MTU at the service
level.</dd>
<t hangText="'qos':">Is used to define a set of QoS policies <dt>'qos':</dt>
to apply on a given connection (refer to <xref <dd>Used to define a set of QoS policies
target="qos"></xref> for more details).</t> to apply on a given connection (refer to <xref target="qos" form
at="default"/> for more details).</dd>
<t hangText="'carriers-carrier':">Groups a set of parameters <dt>'carriers-carrier':</dt>
that are used when Carriers' Carriers (CsC) is enabled such <dd>Groups a set of parameters
the use of BGP for signaling purposes <xref that are used when Carriers' Carriers (CsC) is enabled, such as
target="RFC8277"></xref>.</t> using BGP for signaling purposes <xref target="RFC8277" format="
default"/>.</dd>
<t hangText="'ntp':">Time synchronization may be needed in <dt>'ntp':</dt>
some VPNs such as infrastructure and management VPNs. This <dd>Time synchronization may be needed in
container is used to enable the NTP service <xref some VPNs, such as infrastructure and management VPNs. This
target="RFC5905"></xref>.</t> container is used to enable the NTP service <xref target="RFC590
5" format="default"/>.</dd>
<t hangText="'multicast':">Specifies the multicast mode and <dt>'multicast':</dt>
other data nodes such as the address-family. Refer to <xref <dd>Specifies the multicast mode and
target="mc"></xref>.</t> other data nodes, such as the address family. Refer to <xref tar
</list></t> get="mc" format="default"/>.</dd>
</dl>
</section> </section>
<section anchor="qos" numbered="true" toc="default">
<section anchor="qos" title="QoS "> <name>QoS</name>
<t>'qos' container is used to define a set of QoS policies to <t>The 'qos' container is used to define a set of QoS policies to
apply on a given connection (<xref target="qos-sub"></xref>). A apply on a given connection (<xref target="qos-sub" format="default"
/>). A
QoS policy may be a classification or an action policy. For QoS policy may be a classification or an action policy. For
example, a QoS action can be defined to rate limit example, a QoS action can be defined to rate-limit
inbound/outbound traffic of a given class of service. <figure inbound/outbound traffic of a given class of service. </t>
align="center" anchor="qos-sub" <figure anchor="qos-sub">
title="Services Subtree Structure"> <name>Overall QoS Subtree Structure</name>
<artwork align="center"><![CDATA[... <sourcecode name="" type="yangtree"><![CDATA[...
+--rw qos {vpn-common:qos}? +--rw qos {vpn-common:qos}?
| +--rw qos-classification-policy | +--rw qos-classification-policy
| | +--rw rule* [id] | | +--rw rule* [id]
| | +--rw id string | | +--rw id string
| | +--rw (match-type)? | | +--rw (match-type)?
| | | +--:(match-flow) | | | +--:(match-flow)
| | | | +--rw (l3)? | | | | +--rw (l3)?
| | | | | +--:(ipv4) | | | | | +--:(ipv4)
| | | | | | ... | | | | | | ...
| | | | | +--:(ipv6) | | | | | +--:(ipv6)
| | | | | ... | | | | | ...
| | | | +--rw (l4)? | | | | +--rw (l4)?
| | | | +--:(tcp) | | | | +--:(tcp)
| | | | | ... | | | | | ...
| | | | +--:(udp) | | | | +--:(udp)
| | | | ... | | | | ...
| | | +--:(match-application) | | | +--:(match-application)
| | | +--rw match-application? | | | +--rw match-application?
| | | identityref | | | identityref
| | +--rw target-class-id? | | +--rw target-class-id? string
| | string
| +--rw qos-action | +--rw qos-action
| | +--rw rule* [id] | | +--rw rule* [id]
| | +--rw id string | | +--rw id string
| | +--rw target-class-id? string | | +--rw target-class-id? string
| | +--rw inbound-rate-limit? decimal64 | | +--rw inbound-rate-limit? decimal64
| | +--rw outbound-rate-limit? decimal64 | | +--rw outbound-rate-limit? decimal64
| +--rw qos-profile | +--rw qos-profile
| +--rw qos-profile* [profile] | +--rw qos-profile* [profile]
| +--rw profile leafref | +--rw profile leafref
| +--rw direction? identityref | +--rw direction? identityref
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>QoS classification can be based on many criteria such as: <list <t>QoS classification can be based on many criteria, such as the fol
style="hanging"> lowing:</t>
<t hangText="Layer 3:">As shown in <xref <dl newline="false" spacing="normal">
target="services-l3"></xref>, classification can be based on <dt>Layer 3:</dt>
<dd>As shown in <xref target="services-l3" format="default"/>, cla
ssification can be based on
any IP header field or a combination thereof. Both IPv4 and any IP header field or a combination thereof. Both IPv4 and
IPv6 are supported. <figure align="center" IPv6 are supported.</dd>
anchor="services-l3" title="QoS Subtree Structure (L3)"> </dl>
<artwork align="center"><![CDATA[+--rw qos {vpn-common:qos}? <figure anchor="services-l3">
<name>QoS Subtree Structure (L3)</name>
<sourcecode name="" type="yangtree"><![CDATA[+--rw qos {vpn-co
mmon:qos}?
| +--rw qos-classification-policy | +--rw qos-classification-policy
| | +--rw rule* [id] | | +--rw rule* [id]
| | +--rw id string | | +--rw id string
| | +--rw (match-type)? | | +--rw (match-type)?
| | | +--:(match-flow) | | | +--:(match-flow)
| | | | +--rw (l3)? | | | | +--rw (l3)?
| | | | | +--:(ipv4) | | | | | +--:(ipv4)
| | | | | | +--rw ipv4 | | | | | | +--rw ipv4
| | | | | | +--rw dscp? inet:dscp | | | | | | +--rw dscp? inet:dscp
| | | | | | +--rw ecn? uint8 | | | | | | +--rw ecn? uint8
skipping to change at line 2571 skipping to change at line 2322
| | | | | | +--:(destination-ipv6-network) | | | | | | +--:(destination-ipv6-network)
| | | | | | +--rw destination-ipv6-network? | | | | | | +--rw destination-ipv6-network?
| | | | | | inet:ipv6-prefix | | | | | | inet:ipv6-prefix
| | | | | +--rw (source-network)? | | | | | +--rw (source-network)?
| | | | | | +--:(source-ipv6-network) | | | | | | +--:(source-ipv6-network)
| | | | | | +--rw source-ipv6-network? | | | | | | +--rw source-ipv6-network?
| | | | | | inet:ipv6-prefix | | | | | | inet:ipv6-prefix
| | | | | +--rw flow-label? | | | | | +--rw flow-label?
| | | | | inet:ipv6-flow-label | | | | | inet:ipv6-flow-label
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<dl newline="false" spacing="normal">
<t hangText="Layer 4:">As discussed in <xref <dt>Layer 4:</dt>
target="I-D.ietf-opsawg-vpn-common"></xref>, any layer 4 <dd>
<t>As discussed in <xref target="RFC9181" format="default"/>, an
y Layer 4
protocol can be indicated in the 'protocol' data node under protocol can be indicated in the 'protocol' data node under
'l3' (<xref target="services-l3"></xref>), but only TCP and 'l3' (<xref target="services-l3" format="default"/>), but only T
UDP specific match criteria are elaborated in this version as CP- and
UDP-specific match criteria are elaborated in this version, as
these protocols are widely used in the context of VPN these protocols are widely used in the context of VPN
services. Augmentations can be considered in the future to add services. Augmentations can be considered in the future to add
other Layer 4 specific data nodes, if needed.<vspace other Layer-4-specific data nodes, if needed.</t>
blankLines="1" />TCP or UDP-related match criteria can be <t>TCP- or UDP-related match criteria can be
specified in the L3NM as shown in <xref specified in the L3NM, as shown in <xref target="services-l4" fo
target="services-l4"></xref>. <vspace blankLines="1" />As rmat="default"/>. </t>
discussed in <xref <t>As
target="I-D.ietf-opsawg-vpn-common"></xref>, some transport discussed in <xref target="RFC9181" format="default"/>, some tra
protocols use existing protocols (e.g., TCP or UDP) as nsport
protocols use existing protocols (e.g., TCP or UDP) as the
substrate. The match criteria for such protocols may rely upon substrate. The match criteria for such protocols may rely upon
the 'protocol' under 'l3', TCP/UDP match criteria shown in the 'protocol' setting under 'l3', TCP/UDP match criteria as sho
<xref target="services-l4"></xref>, part of the TCP/UDP wn in
<xref target="services-l4" format="default"/>, part of the TCP/U
DP
payload, or a combination thereof. This version of the module payload, or a combination thereof. This version of the module
does not support such advanced match criteria. Future does not support such advanced match criteria. Future
revisions of the VPN common module or augmentations to the revisions of the VPN common module or augmentations to the
L3NM may consider adding match criteria based on the transport L3NM may consider adding match criteria based on the transport
protocol payload (e.g., by means of a bitmask match). <figure protocol payload (e.g., by means of a bitmask match).</t>
align="center" anchor="services-l4" </dd>
title="QoS Subtree Structure (L4)"> </dl>
<artwork align="center"><![CDATA[+--rw qos {vpn-common:qos}? <figure anchor="services-l4">
<name>QoS Subtree Structure (L4)</name>
<sourcecode name="" type="yangtree"><![CDATA[+--rw qos {vpn-co
mmon:qos}?
| +--rw qos-classification-policy | +--rw qos-classification-policy
| | +--rw rule* [id] | | +--rw rule* [id]
| | +--rw id string | | +--rw id string
| | +--rw (match-type)? | | +--rw (match-type)?
| | | +--:(match-flow) | | | +--:(match-flow)
| | | | +--rw (l3)? | | | | +--rw (l3)?
| | | | | ... | | | | | ...
| | | | +--rw (l4)? | | | | +--rw (l4)?
| | | | +--:(tcp) | | | | +--:(tcp)
| | | | | +--rw tcp | | | | | +--rw tcp
skipping to change at line 2631 skipping to change at line 2384
| | | | | | +--:(range) | | | | | | +--:(range)
| | | | | | | +--rw lower-port | | | | | | | +--rw lower-port
| | | | | | | | inet:port-number | | | | | | | | inet:port-number
| | | | | | | +--rw upper-port | | | | | | | +--rw upper-port
| | | | | | | inet:port-number | | | | | | | inet:port-number
| | | | | | +--:(operator) | | | | | | +--:(operator)
| | | | | | +--rw operator? operator | | | | | | +--rw operator? operator
| | | | | | +--rw port | | | | | | +--rw port
| | | | | | inet:port-number | | | | | | inet:port-number
| | | | | +--rw (destination-port)? | | | | | +--rw (destination-port)?
| | | | +--:(destination-port-range-or-operator) | | | | | +--:(destination-port-range-or-operator)
| | | | | +--rw destination-port-range-or-operator | | | | | +--rw destination-port-range-or-operator
| | | | | +--rw (port-range-or-operator)? | | | | | +--rw (port-range-or-operator)?
| | | | | +--:(range) | | | | | +--:(range)
| | | | | | +--rw lower-port | | | | | | +--rw lower-port
| | | | | | | inet:port-number | | | | | | | inet:port-number
| | | | | | +--rw upper-port | | | | | | +--rw upper-port
| | | | | | inet:port-number | | | | | | inet:port-number
| | | | | +--:(operator) | | | | | +--:(operator)
| | | | | +--rw operator? operator | | | | | +--rw operator? operator
| | | | | +--rw port | | | | | +--rw port
skipping to change at line 2673 skipping to change at line 2426
| | | | +--:(range) | | | | +--:(range)
| | | | | +--rw lower-port | | | | | +--rw lower-port
| | | | | | inet:port-number | | | | | | inet:port-number
| | | | | +--rw upper-port | | | | | +--rw upper-port
| | | | | inet:port-number | | | | | inet:port-number
| | | | +--:(operator) | | | | +--:(operator)
| | | | +--rw operator? operator | | | | +--rw operator? operator
| | | | +--rw port | | | | +--rw port
| | | | inet:port-number | | | | inet:port-number
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<dl newline="false" spacing="normal">
<t hangText="Application match:">Relies upon <dt>Application match:</dt>
application-specific classification.</t> <dd>Relies upon
</list></t> application-specific classification (<xref target="qos-sub"/>).<
/dd>
</dl>
</section> </section>
</section> </section>
</section> </section>
<section anchor="mc" numbered="true" toc="default">
<section anchor="mc" title="Multicast"> <name>Multicast</name>
<t>Multicast may be enabled for a particular VPN at the VPN node and <t>Multicast may be enabled for a particular VPN at the VPN node and
VPN network access levels (see <xref target="all-multicast"></xref>). VPN network access levels (see <xref target="all-multicast" format="defa
Some data nodes (e.g., max-groups) can be controlled at various ult"/>).
Some data nodes (e.g., max-groups (<xref target="mcast-vpn-profile"/>))
can be controlled at various
levels: VPN service, VPN node level, or VPN network access.</t> levels: VPN service, VPN node level, or VPN network access.</t>
<figure anchor="all-multicast">
<t><figure align="center" anchor="all-multicast" <name>Overall Multicast Subtree Structure</name>
title="Overall Multicast Subtree Structure"> <sourcecode name="" type="yangtree"><![CDATA[ ...
<artwork align="center"><![CDATA[ ...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
... ...
+--rw vpn-instance-profiles +--rw vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id] | +--rw vpn-instance-profile* [profile-id]
| .... | ....
| +--rw multicast {vpn-common:multicast}? | +--rw multicast {vpn-common:multicast}?
| ... | ...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
skipping to change at line 2715 skipping to change at line 2468
| ... | ...
| +--rw multicast {vpn-common:multicast}? | +--rw multicast {vpn-common:multicast}?
| ... | ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
+--rw service +--rw service
... ...
+--rw multicast {vpn-common:multicast}? +--rw multicast {vpn-common:multicast}?
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>Multicast-related data nodes at the VPN instance profile level have
<t>Multicast-related data nodes at the VPN instance profile level has the structure shown in <xref target="mcast-vpn-profile"/>.
the structure that is shown in <xref target="mcast-vpaccess"></xref>. </t>
<figure align="center" anchor="mcast-vpn-profile" <figure anchor="mcast-vpn-profile">
title="Multicast Subtree Structure (VPN Instance Profile Level)"> <name>Multicast Subtree Structure (VPN Instance Profile Level)</name>
<artwork align="center"><![CDATA[... <sourcecode name="" type="yangtree"><![CDATA[...
+--rw vpn-services +--rw vpn-services
+--rw vpn-service* [vpn-id] +--rw vpn-service* [vpn-id]
... ...
+--rw vpn-instance-profiles +--rw vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id] | +--rw vpn-instance-profile* [profile-id]
| .... | ....
| +--rw multicast {vpn-common:multicast}? | +--rw multicast {vpn-common:multicast}?
| +--rw tree-flavor? identityref | +--rw tree-flavor? identityref
| +--rw rp | +--rw rp
| | +--rw rp-group-mappings | | +--rw rp-group-mappings
skipping to change at line 2748 skipping to change at line 2501
| | | | +--rw optimal-traffic-delivery? boolean | | | | +--rw optimal-traffic-delivery? boolean
| | | | +--rw anycast | | | | +--rw anycast
| | | | +--rw local-address? inet:ip-address | | | | +--rw local-address? inet:ip-address
| | | | +--rw rp-set-address* inet:ip-address | | | | +--rw rp-set-address* inet:ip-address
| | | +--rw rp-address inet:ip-address | | | +--rw rp-address inet:ip-address
| | | +--rw groups | | | +--rw groups
| | | +--rw group* [id] | | | +--rw group* [id]
| | | +--rw id uint16 | | | +--rw id uint16
| | | +--rw (group-format) | | | +--rw (group-format)
| | | +--:(group-prefix) | | | +--:(group-prefix)
| | | | +--rw group-address? inet:ip-prefix | | | | +--rw group-address?
| | | | inet:ip-prefix
| | | +--:(startend) | | | +--:(startend)
| | | +--rw group-start? inet:ip-address | | | +--rw group-start?
| | | +--rw group-end? inet:ip-address | | | | inet:ip-address
| | | +--rw group-end?
| | | | inet:ip-address
| | +--rw rp-discovery | | +--rw rp-discovery
| | +--rw rp-discovery-type? identityref | | +--rw rp-discovery-type? identityref
| | +--rw bsr-candidates | | +--rw bsr-candidates
| | +--rw bsr-candidate-address* inet:ip-address | | +--rw bsr-candidate-address*
| | | inet:ip-address
| +--rw igmp {vpn-common:igmp and vpn-common:ipv4}? | +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
| | +--rw static-group* [group-addr] | | +--rw static-group* [group-addr]
| | | +--rw group-addr | | | +--rw group-addr
| | | | rt-types:ipv4-multicast-group-address | | | | rt-types:ipv4-multicast-group-address
| | | +--rw source-addr? | | | +--rw source-addr?
| | | rt-types:ipv4-multicast-source-address | | | rt-types:ipv4-multicast-source-address
| | +--rw max-groups? uint32 | | +--rw max-groups? uint32
| | +--rw max-entries? uint32 | | +--rw max-entries? uint32
| | +--rw version? identityref | | +--rw version? identityref
| +--rw mld {vpn-common:mld and vpn-common:ipv6}? | +--rw mld {vpn-common:mld and vpn-common:ipv6}?
| | +--rw static-group* [group-addr] | | +--rw static-group* [group-addr]
| | | +--rw group-addr | | | +--rw group-addr
| | | | rt-types:ipv6-multicast-group-address | | | | rt-types:ipv6-multicast-group-address
| | | +--rw source-addr? | | | +--rw source-addr?
| | | rt-types:ipv6-multicast-source-address | | | rt-types:ipv6-multicast-source-address
| | +--rw max-groups? uint32 | | +--rw max-groups? uint32
| | +--rw max-entries? uint32 | | +--rw max-entries? uint32
| | +--rw version? identityref | | +--rw version? identityref
| +--rw pim {vpn-common:pim}? | +--rw pim {vpn-common:pim}?
| +--rw hello-interval? rt-types:timer-value-seconds16 | +--rw hello-interval?
| | rt-types:timer-value-seconds16
| +--rw dr-priority? uint32 | +--rw dr-priority? uint32
... ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>The model supports a single type of tree per VPN access <t>The model supports a single type of tree per VPN access
('tree-flavor'): Any-Source Multicast (ASM), Source-Specific Multicast ('tree-flavor'): Any-Source Multicast (ASM), Source-Specific Multicast
(SSM), or bidirectional.</t> (SSM), or bidirectional.</t>
<t>When ASM is used, the model supports the configuration of <t>When ASM is used, the model supports the configuration of
Rendezvous Points (RPs). RP discovery may be 'static', 'bsr-rp', or Rendezvous Points (RPs). RP discovery may be 'static', 'bsr-rp', or
'auto-rp'. When set to 'static', RP to multicast grouping mappings 'auto-rp'. When set to 'static', RP-to-multicast-group mappings
MUST be configured as part of the 'rp-group-mappings' container. The <bcp14>MUST</bcp14> be configured as part of the 'rp-group-mappings' con
RP MAY be a provider node or a customer node. When the RP is a tainer. The
RP <bcp14>MAY</bcp14> be a provider node or a customer node. When the RP
is a
customer node, the RP address must be configured using the customer node, the RP address must be configured using the
'rp-address' leaf.</t> 'rp-address' leaf.</t>
<t>The model supports RP redundancy through the 'rp-redundancy' leaf. <t>The model supports RP redundancy through the 'rp-redundancy' leaf.
How the redundancy is achieved is out of scope.</t> How the redundancy is achieved is out of scope.</t>
<t>When a particular VPN using ASM requires traffic
<t>When a particular VPN using ASM requires a more optimal traffic delivery that is more optimal (e.g., requested per the guidance in <xref
delivery (e.g., requested using <xref target="RFC8299"></xref>), target="RFC8299" format="default"/>),
'optimal-traffic-delivery' can be set. When set to 'true', the 'optimal-traffic-delivery' can be set. When set to 'true', the
implementation must use any mechanism to provide a more optimal implementation must use any mechanism to provide
traffic delivery for the customer. For example, anycast is one of the traffic delivery that is more optimal for the customer. For example, any
mechanisms to enhance RPs redundancy, resilience against failures, and cast is one of the
to recover from failures quickly.</t> mechanisms for enhancing RP redundancy, providing resilience against fai
lures, and
<t>The same structure as the one depicted in <xref recovering from failures quickly.</t>
target="mcast-vpaccess"></xref> is used when configuring <t>
multicast-related parameters at the VPN node level. When defined at When configuring multicast-related parameters at the VPN node level
the VPN node level (<xref target="mcast-vpn"></xref>), Internet Group (<xref target="mcast-vpn" format="default"/>), the same structure as the struct
Management Protocol (IGMP) <xref target="RFC1112"></xref><xref ure depicted in
target="RFC2236"></xref><xref target="RFC3376"></xref>, Multicast <xref target="mcast-vpaccess" format="default"/> is used. When defined at the
Listener Discovery (MLD) <xref target="RFC2710"></xref><xref VPN node level, Internet Group Management Protocol (IGMP) parameters <xref targe
target="RFC3810"></xref>, and Protocol Independent Multicast (PIM) t="RFC1112" format="default"/> <xref target="RFC2236" format="default"/> <xref t
<xref target="RFC7761"></xref> parameters are applicable to all VPN arget="RFC3376" format="default"/>, Multicast
Listener Discovery (MLD) parameters <xref target="RFC2710" format="defau
lt"/> <xref target="RFC3810" format="default"/>, and Protocol Independent Multic
ast (PIM) parameters <xref target="RFC7761" format="default"/> are applicable to
all VPN
network accesses of that VPN node unless corresponding nodes are network accesses of that VPN node unless corresponding nodes are
overridden at the VPN network access level.</t> overridden at the VPN network access level.</t>
<figure anchor="mcast-vpn">
<t><figure align="center" anchor="mcast-vpn" <name>Multicast Subtree Structure (VPN Node Level)</name>
title="Multicast Subtree Structure (VPN Node Level)"> <sourcecode name="" type="yangtree"><![CDATA[...
<artwork align="center"><![CDATA[...
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [vpn-node-id] +--rw vpn-node* [vpn-node-id]
... ...
+--rw active-vpn-instance-profiles +--rw active-vpn-instance-profiles
| +--rw vpn-instance-profile* [profile-id] | +--rw vpn-instance-profile* [profile-id]
| ... | ...
| +--rw multicast {vpn-common:multicast}? | +--rw multicast {vpn-common:multicast}?
| +--rw tree-flavor* identityref | +--rw tree-flavor* identityref
| +--rw rp | +--rw rp
| | ... | | ...
| +--rw igmp {vpn-common:igmp and vpn-common:ipv4}? | +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
| | ... | | ...
| +--rw mld {vpn-common:mld and vpn-common:ipv6}? | +--rw mld {vpn-common:mld and vpn-common:ipv6}?
| | ... | | ...
| +--rw pim {vpn-common:pim}? | +--rw pim {vpn-common:pim}?
| ... | ...
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>Multicast-related data nodes at the VPN network access level are <t>Multicast-related data nodes at the VPN network access level are
shown in <xref target="mcast-vpaccess"></xref>. The values configured shown in <xref target="mcast-vpaccess" format="default"/>. The values co nfigured
at the VPN network access level override the values configured for the at the VPN network access level override the values configured for the
corresponding data nodes in other levels.<figure align="center" corresponding data nodes at other levels.</t>
anchor="mcast-vpaccess" <figure anchor="mcast-vpaccess">
title="Multicast Subtree Structure (VPN Network Access Level)"> <name>Multicast Subtree Structure (VPN Network Access Level)</name>
<artwork align="center"><![CDATA[... <sourcecode name="" type="yangtree"><![CDATA[...
+--rw vpn-network-accesses +--rw vpn-network-accesses
+--rw vpn-network-access* [id] +--rw vpn-network-access* [id]
... ...
+--rw service +--rw service
... ...
+--rw multicast {vpn-common:multicast}? +--rw multicast {vpn-common:multicast}?
+--rw access-type? enumeration +--rw access-type? enumeration
+--rw address-family? identityref +--rw address-family? identityref
+--rw protocol-type? enumeration +--rw protocol-type? enumeration
+--rw remote-source? boolean +--rw remote-source? boolean
+--rw igmp {vpn-common:igmp}? +--rw igmp {vpn-common:igmp}?
| +--rw static-group* [group-addr] | +--rw static-group* [group-addr]
| | +--rw group-addr | | +--rw group-addr
| | rt-types:ipv4-multicast-group-address | | rt-types:ipv4-multicast-group-address
| | +--rw source-addr? | | +--rw source-addr?
| | rt-types:ipv4-multicast-source-address | | rt-types:ipv4-multicast-source-address
| +--rw max-groups? uint32 | +--rw max-groups? uint32
| +--rw max-entries? uint32 | +--rw max-entries? uint32
| +--rw max-group-sources? uint32 | +--rw max-group-sources? uint32
| +--rw version? identityref | +--rw version? identityref
| +--rw status | +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw mld {vpn-common:mld}? +--rw mld {vpn-common:mld}?
| +--rw static-group* [group-addr] | +--rw static-group* [group-addr]
| | +--rw group-addr | | +--rw group-addr
| | rt-types:ipv6-multicast-group-address | | rt-types:ipv6-multicast-group-address
| | +--rw source-addr? | | +--rw source-addr?
| | rt-types:ipv6-multicast-source-address | | rt-types:ipv6-multicast-source-address
| +--rw max-groups? uint32 | +--rw max-groups? uint32
| +--rw max-entries? uint32 | +--rw max-entries? uint32
| +--rw max-group-sources? uint32 | +--rw max-group-sources? uint32
| +--rw version? identityref | +--rw version? identityref
| +--rw status | +--rw status
| +--rw admin-status | +--rw admin-status
| | +--rw status? identityref | | +--rw status? identityref
| | +--rw last-change? yang:date-and-time | | +--rw last-change? yang:date-and-time
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
skipping to change at line 2899 skipping to change at line 2646
+--rw pim {vpn-common:pim}? +--rw pim {vpn-common:pim}?
+--rw hello-interval? rt-types:timer-value-seconds16 +--rw hello-interval? rt-types:timer-value-seconds16
+--rw dr-priority? uint32 +--rw dr-priority? uint32
+--rw status +--rw status
+--rw admin-status +--rw admin-status
| +--rw status? identityref | +--rw status? identityref
| +--rw last-change? yang:date-and-time | +--rw last-change? yang:date-and-time
+--ro oper-status +--ro oper-status
+--ro status? identityref +--ro status? identityref
+--ro last-change? yang:date-and-time +--ro last-change? yang:date-and-time
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
</section> </section>
<section anchor="YANG_module" numbered="true" toc="default">
<section anchor="YANG_module" title="L3NM YANG Module"> <name>L3NM YANG Module</name>
<t>This module uses types defined in <xref target="RFC6991"></xref> and <t>This module uses types defined in <xref target="RFC6991" format="defaul
<xref target="RFC8343"></xref>. It also uses groupings defined in <xref t"/>,
target="RFC8519"></xref>, <xref target="RFC8177"></xref>, and <xref <xref target="RFC8343" format="default"/>, and <xref target="RFC9181"/>. I
target="RFC8294"></xref>.</t> t also uses groupings defined in <xref target="RFC8519" format="default"/>, <xre
f target="RFC8177" format="default"/>, and <xref target="RFC8294" format="defaul
<figure align="center"> t"/>.</t>
<artwork align="center"><![CDATA[<CODE BEGINS> file "ietf-l3vpn-ntw@202 <sourcecode name="ietf-l3vpn-ntw@2022-01-19.yang" type="yang" markers="tru
1-09-28.yang" e"><![CDATA[
module ietf-l3vpn-ntw { module ietf-l3vpn-ntw {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw"; namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw";
prefix l3nm; prefix l3nm;
import ietf-vpn-common { import ietf-vpn-common {
prefix vpn-common; prefix vpn-common;
reference reference
"RFC UUUU: A Layer 2/3 VPN Common YANG Model"; "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3
VPNs";
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types, Section 4"; "RFC 6991: Common YANG Data Types, Section 4";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"RFC 6991: Common YANG Data Types, Section 3"; "RFC 6991: Common YANG Data Types, Section 3";
} }
import ietf-key-chain { import ietf-key-chain {
prefix key-chain; prefix key-chain;
reference reference
"RFC 8177: YANG Key Chain."; "RFC 8177: YANG Data Model for Key Chains";
} }
import ietf-routing-types { import ietf-routing-types {
prefix rt-types; prefix rt-types;
reference reference
"RFC 8294: Common YANG Data Types for the Routing Area"; "RFC 8294: Common YANG Data Types for the Routing Area";
} }
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
reference reference
"RFC 8343: A YANG Data Model for Interface Management"; "RFC 8343: A YANG Data Model for Interface Management";
} }
organization organization
"IETF OPSAWG (Operations and Management Area Working Group)"; "IETF OPSAWG (Operations and Management Area Working Group)";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Author: Samier Barguil Author: Samier Barguil
<mailto:samier.barguilgiraldo.ext@telefonica.com> <mailto:samier.barguilgiraldo.ext@telefonica.com>
Editor: Oscar Gonzalez de Dios Editor: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com> <mailto:oscar.gonzalezdedios@telefonica.com>
Editor: Mohamed Boucadair Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Luis Angel Munoz Author: Luis Angel Munoz
<mailto:luis-angel.munoz@vodafone.com> <mailto:luis-angel.munoz@vodafone.com>
Author: Alejandro Aguado Author: Alejandro Aguado
<mailto:alejandro.aguado_martin@nokia.com>"; <mailto:alejandro.aguado_martin@nokia.com>";
description description
"This YANG module defines a generic network-oriented model "This YANG module defines a generic network-oriented model
for the configuration of Layer 3 Virtual Private Networks. for the configuration of Layer 3 Virtual Private Networks.
Copyright (c) 2021 IETF Trust and the persons identified as Copyright (c) 2022 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 Simplified 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
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9182; see the
the RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2021-09-28 { revision 2022-01-19 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A Layer 3 VPN Network YANG Model"; "RFC 9182: A YANG Network Data Model for Layer 3 VPNs";
} }
/* Features */ /* Features */
feature msdp { feature msdp {
description description
"This feature indicates that Multicast Source Discovery Protocol "This feature indicates that Multicast Source Discovery
(MSDP) capabilities are supported by the VPN."; Protocol (MSDP) capabilities are supported by the VPN.";
reference reference
"RFC 3618: Multicast Source Discovery Protocol (MSDP)"; "RFC 3618: Multicast Source Discovery Protocol (MSDP)";
} }
/* Identities */ /* Identities */
identity address-allocation-type { identity address-allocation-type {
description description
"Base identity for address allocation type in the "Base identity for address allocation type in the
Provider Edge (PE)-Customer Edge (CE) link."; Provider Edge to Customer Edge (PE-CE) link.";
} }
identity provider-dhcp { identity provider-dhcp {
base address-allocation-type; base address-allocation-type;
description description
"The Provider's network provides a DHCP service to the customer."; "The provider's network provides a DHCP service to the
customer.";
} }
identity provider-dhcp-relay { identity provider-dhcp-relay {
base address-allocation-type; base address-allocation-type;
description description
"The Provider's network provides a DHCP relay service to the "The provider's network provides a DHCP relay service to the
customer."; customer.";
} }
identity provider-dhcp-slaac { identity provider-dhcp-slaac {
if-feature "vpn-common:ipv6"; if-feature "vpn-common:ipv6";
base address-allocation-type; base address-allocation-type;
description description
"The Provider's network provides a DHCP service to the customer "The provider's network provides a DHCP service to the
as well as IPv6 Stateless Address Autoconfiguration (SLAAC)."; customer as well as IPv6 Stateless Address
Autoconfiguration (SLAAC).";
reference reference
"RFC 4862: IPv6 Stateless Address Autoconfiguration"; "RFC 4862: IPv6 Stateless Address Autoconfiguration";
} }
identity static-address { identity static-address {
base address-allocation-type; base address-allocation-type;
description description
"The Provider's network provides static IP addressing to the "The provider's network provides static IP addressing to the
customer."; customer.";
} }
identity slaac { identity slaac {
if-feature "vpn-common:ipv6"; if-feature "vpn-common:ipv6";
base address-allocation-type; base address-allocation-type;
description description
"The Provider's network uses IPv6 SLAAC to provide addressing "The provider's network uses IPv6 SLAAC to provide
to the customer."; addressing to the customer.";
reference reference
"RFC 4862: IPv6 Stateless Address Autoconfiguration"; "RFC 4862: IPv6 Stateless Address Autoconfiguration";
} }
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 "Indicates an action to discard traffic for the
corresponding destination. corresponding destination.
For example, this can be used to blackhole traffic."; For example, this can be used to black-hole 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
prefix as though they are connected to a local link."; next-hop prefix as though they are connected to a local
link.";
} }
identity l2-tunnel-type { identity l2-tunnel-type {
description description
"Base identity for layer-2 tunnel selection under the VPN "Base identity for Layer 2 tunnel selection under the VPN
network access."; network access.";
} }
identity pseudowire { identity pseudowire {
base l2-tunnel-type; base l2-tunnel-type;
description description
"Pseudowire tunnel termination in the VPN network access."; "Pseudowire tunnel termination in the VPN network access.";
} }
identity vpls { identity vpls {
skipping to change at line 3099 skipping to change at line 2846
termination in the VPN network access."; termination in the VPN network access.";
} }
/* Typedefs */ /* Typedefs */
typedef predefined-next-hop { typedef predefined-next-hop {
type identityref { type identityref {
base local-defined-next-hop; base local-defined-next-hop;
} }
description description
"Pre-defined next-hop designation for locally generated routes."; "Predefined next-hop designation for locally generated
routes.";
} }
typedef area-address { typedef area-address {
type string { type string {
pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}'; pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
} }
description description
"This type defines the area address format."; "This type defines the area address format.";
} }
/* Groupings */ /* Groupings */
grouping vpn-instance-profile { grouping vpn-instance-profile {
description description
"Grouping for data nodes that may be factorized "Grouping for data nodes that may be factorized
among many levels of the model. The grouping can among many levels of the model. The grouping can
be used to define generic profiles at the VPN service be used to define generic profiles at the VPN service
level and then referenced at the VPN node and VPN level and then referenced at the VPN node and VPN
network access levels."; network access levels.";
leaf local-as { leaf local-as {
if-feature "vpn-common:rtg-bgp"; if-feature "vpn-common:rtg-bgp";
type inet:as-number; type inet:as-number;
description description
"Provider's Autonomous System (AS) number. Used if the "Provider's Autonomous System (AS) number. Used if the
customer requests BGP routing."; customer requests BGP routing.";
} }
uses vpn-common:route-distinguisher; uses vpn-common:route-distinguisher;
list address-family { list address-family {
key "address-family"; key "address-family";
description description
"Set of per-address family parameters."; "Set of parameters per address family.";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates the address family (IPv4 and/or IPv6)."; "Indicates the address family (IPv4 and/or IPv6).";
} }
container vpn-targets { container vpn-targets {
description description
"Set of route targets to match for import and export routes "Set of route targets to match for import and export
to/from VRF."; routes to/from VRF.";
uses vpn-common:vpn-route-targets; uses vpn-common:vpn-route-targets;
} }
list maximum-routes { list maximum-routes {
key "protocol"; key "protocol";
description description
"Defines the maximum number of routes for the VRF."; "Defines the maximum number of routes for VRF.";
leaf protocol { leaf protocol {
type identityref { type identityref {
base vpn-common:routing-protocol-type; base vpn-common:routing-protocol-type;
} }
description description
"Indicates the routing protocol. 'any' value can "Indicates the routing protocol. A value of 'any'
be used to identify a limit that will apply for can be used to identify a limit that will apply for
each active routing protocol."; each active routing protocol.";
} }
leaf maximum-routes { leaf maximum-routes {
type uint32; type uint32;
description description
"Indicates the maximum number of prefixes that the "Indicates the maximum number of prefixes that VRF can
VRF can accept for this address family and protocol."; accept for this address family and protocol.";
} }
} }
} }
container multicast { container multicast {
if-feature "vpn-common:multicast"; if-feature "vpn-common:multicast";
description description
"Global multicast parameters."; "Global multicast parameters.";
leaf tree-flavor { leaf tree-flavor {
type identityref { type identityref {
base vpn-common:multicast-tree-type; base vpn-common:multicast-tree-type;
} }
description description
"Type of the multicast tree to be used."; "Type of the multicast tree to be used.";
} }
container rp { container rp {
description description
"Rendezvous Point (RP) parameters."; "Rendezvous Point (RP) parameters.";
container rp-group-mappings { container rp-group-mappings {
description description
"RP-to-group mappings parameters."; "RP-to-group mapping parameters.";
list rp-group-mapping { list rp-group-mapping {
key "id"; key "id";
description description
"List of RP-to-group mappings."; "List of RP-to-group mappings.";
leaf id { leaf id {
type uint16; type uint16;
description description
"Unique identifier for the mapping."; "Unique identifier for the mapping.";
} }
container provider-managed { container provider-managed {
description description
"Parameters for a provider-managed RP."; "Parameters for a provider-managed RP.";
leaf enabled { leaf enabled {
type boolean; type boolean;
default "false"; default "false";
description description
"Set to true if the Rendezvous Point (RP) "Set to 'true' if the RP must be a
must be a provider-managed node. Set to provider-managed node. Set to 'false' if it is
false if it is a customer-managed node."; a customer-managed node.";
} }
leaf rp-redundancy { leaf rp-redundancy {
type boolean; type boolean;
default "false"; default "false";
description description
"If set to true, it indicates that a redundancy "If set to 'true', it indicates that a
mechanism for the RP is required."; redundancy mechanism for the RP is required.";
} }
leaf optimal-traffic-delivery { leaf optimal-traffic-delivery {
type boolean; type boolean;
default "false"; default "false";
description description
"If set to true, the service provider (SP) must "If set to 'true', the service provider (SP)
ensure that the traffic uses an optimal path. must ensure that the traffic uses an optimal
An SP may use Anycast RP or RP-tree-to-SPT path. An SP may use Anycast RP or
RP-tree-to-SPT ('SPT' is 'shortest path tree')
switchover architectures."; switchover architectures.";
} }
container anycast { container anycast {
when "../rp-redundancy = 'true' and when "../rp-redundancy = 'true' and
../optimal-traffic-delivery = 'true'" { ../optimal-traffic-delivery = 'true'" {
description description
"Only applicable if both RP redundancy and "Only applicable if both RP redundancy and
delivery through optimal path are delivery through an optimal path are
activated."; activated.";
} }
description description
"PIM Anycast-RP parameters."; "PIM Anycast-RP parameters.";
leaf local-address { leaf local-address {
type inet:ip-address; type inet:ip-address;
description description
"IP local address for PIM RP. Usually, it "IP local address for the PIM RP. Usually
corresponds to the Router ID or the corresponds to the Router ID or the
primary address."; primary address.";
} }
leaf-list rp-set-address { leaf-list rp-set-address {
type inet:ip-address; type inet:ip-address;
description description
"Specifies the IP address of other RP routers "Specifies the IP address of other RP routers
that share the same RP IP address."; that share the same RP IP address.";
} }
} }
} }
leaf rp-address { leaf rp-address {
when "../provider-managed/enabled = 'false'" { when "../provider-managed/enabled = 'false'" {
description description
"Relevant when the RP is not "Relevant when the RP is not managed by the
provider-managed."; provider.";
} }
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
description description
"Defines the address of the RP. "Defines the address of the RP.
Used if the RP is customer-managed."; Used if the RP is managed by the customer.";
} }
container groups { container groups {
description description
"Multicast groups associated with the RP."; "Multicast groups associated with the RP.";
list group { list group {
key "id"; key "id";
description description
"List of multicast groups."; "List of multicast groups.";
leaf id { leaf id {
type uint16; type uint16;
skipping to change at line 3312 skipping to change at line 3061
base vpn-common:multicast-rp-discovery-type; base vpn-common:multicast-rp-discovery-type;
} }
default "vpn-common:static-rp"; default "vpn-common:static-rp";
description description
"Type of RP discovery used."; "Type of RP discovery used.";
} }
container bsr-candidates { container bsr-candidates {
when "derived-from-or-self(../rp-discovery-type, " when "derived-from-or-self(../rp-discovery-type, "
+ "'vpn-common:bsr-rp')" { + "'vpn-common:bsr-rp')" {
description description
"Only applicable if discovery type is BSR-RP."; "Only applicable if the discovery type
is 'bsr-rp'.";
} }
description description
"Container for the customer Bootstrap Router (BSR) "Container for the customer Bootstrap Router (BSR)
candidate's addresses."; candidate's addresses.";
leaf-list bsr-candidate-address { leaf-list bsr-candidate-address {
type inet:ip-address; type inet:ip-address;
description description
"Specifies the address of candidate BSR."; "Specifies the address of the candidate BSR.";
} }
} }
} }
} }
container igmp { container igmp {
if-feature "vpn-common:igmp and vpn-common:ipv4"; if-feature "vpn-common:igmp and vpn-common:ipv4";
description description
"Includes IGMP-related parameters."; "Includes IGMP-related parameters.";
list static-group { list static-group {
key "group-addr"; key "group-addr";
description description
"Multicast static source/group associated to the "Multicast static source/group associated with the
IGMP session."; IGMP session.";
leaf group-addr { leaf group-addr {
type rt-types:ipv4-multicast-group-address; type rt-types:ipv4-multicast-group-address;
description description
"Multicast group IPv4 address."; "Multicast group IPv4 address.";
} }
leaf source-addr { leaf source-addr {
type rt-types:ipv4-multicast-source-address; type rt-types:ipv4-multicast-source-address;
description description
"Multicast source IPv4 address."; "Multicast source IPv4 address.";
skipping to change at line 3364 skipping to change at line 3114
} }
leaf version { leaf version {
type identityref { type identityref {
base vpn-common:igmp-version; base vpn-common:igmp-version;
} }
default "vpn-common:igmpv2"; default "vpn-common:igmpv2";
description description
"Indicates the IGMP version."; "Indicates the IGMP version.";
reference reference
"RFC 1112: Host Extensions for IP Multicasting "RFC 1112: Host Extensions for IP Multicasting
RFC 2236: Internet Group Management Protocol, Version 2 RFC 2236: Internet Group Management Protocol,
RFC 3376: Internet Group Management Protocol, Version 3"; Version 2
RFC 3376: Internet Group Management Protocol,
Version 3";
} }
} }
container mld { container mld {
if-feature "vpn-common:mld and vpn-common:ipv6"; if-feature "vpn-common:mld and vpn-common:ipv6";
description description
"Includes MLD-related parameters."; "Includes MLD-related parameters.";
list static-group { list static-group {
key "group-addr"; key "group-addr";
description description
"Multicast static source/group associated with the "Multicast static source/group associated with the
skipping to change at line 3407 skipping to change at line 3159
} }
leaf version { leaf version {
type identityref { type identityref {
base vpn-common:mld-version; base vpn-common:mld-version;
} }
default "vpn-common:mldv2"; default "vpn-common:mldv2";
description description
"Indicates the MLD protocol version."; "Indicates the MLD protocol version.";
reference reference
"RFC 2710: Multicast Listener Discovery (MLD) for IPv6 "RFC 2710: Multicast Listener Discovery (MLD) for IPv6
RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) RFC 3810: Multicast Listener Discovery Version 2
for IPv6"; (MLDv2) for IPv6";
} }
} }
container pim { container pim {
if-feature "vpn-common:pim"; if-feature "vpn-common:pim";
description description
"Only applies when protocol type is PIM."; "Only applies when the protocol type is 'pim'.";
leaf hello-interval { leaf hello-interval {
type rt-types:timer-value-seconds16; type rt-types:timer-value-seconds16;
default "30"; default "30";
description description
"PIM hello-messages interval. If set to "Interval between PIM Hello messages. If set to
'infinity' or 'not-set', no periodic 'infinity' or 'not-set', no periodic Hello messages
Hello messages are sent."; are sent.";
reference reference
"RFC 7761: Protocol Independent Multicast - Sparse "RFC 7761: Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised), Mode (PIM-SM): Protocol Specification
Section 4.11"; (Revised), Section 4.11
RFC 8294: Common YANG Data Types for the Routing
Area";
} }
leaf dr-priority { leaf dr-priority {
type uint32; type uint32;
default "1"; default "1";
description description
"Indicates the preference in the Designated Router (DR) "Indicates the preference associated with the
election process. A larger value has a higher Designated Router (DR) election process. A larger
priority over a smaller value."; value has a higher priority over a smaller value.";
reference reference
"RFC 7761: Protocol Independent Multicast - Sparse "RFC 7761: Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised), Mode (PIM-SM): Protocol Specification
Section 4.3.2"; (Revised), Section 4.3.2";
} }
} }
} }
} }
/* Main Blocks */ /* Main Blocks */
/* Main l3vpn-ntw */ /* Main l3vpn-ntw */
container l3vpn-ntw { container l3vpn-ntw {
description description
"Main container for L3VPN services management."; "Main container for management of Layer 3 Virtual Private
Network (L3VPN) services.";
container vpn-profiles { container vpn-profiles {
description description
"Contains a set of valid VPN profiles to reference in the VPN "Contains a set of valid VPN profiles to reference
service."; in the VPN service.";
uses vpn-common:vpn-profile-cfg; uses vpn-common:vpn-profile-cfg;
} }
container vpn-services { container vpn-services {
description description
"Container for the VPN services."; "Container for the VPN services.";
list vpn-service { list vpn-service {
key "vpn-id"; key "vpn-id";
description description
"List of VPN services."; "List of VPN services.";
uses vpn-common:vpn-description; uses vpn-common:vpn-description;
leaf parent-service-id { leaf parent-service-id {
type vpn-common:vpn-id; type vpn-common:vpn-id;
description description
"Pointer to the parent service, if any. "Pointer to the parent service, if any.
A parent service can be an L3SM, a slice request, a VPN+ A parent service can be an L3SM, a slice request,
service, etc."; a VPN+ service, etc.";
} }
leaf vpn-type { leaf vpn-type {
type identityref { type identityref {
base vpn-common:service-type; base vpn-common:service-type;
} }
description description
"Indicates the service type."; "Indicates the service type.";
} }
leaf vpn-service-topology { leaf vpn-service-topology {
type identityref { type identityref {
skipping to change at line 3511 skipping to change at line 3266
} }
default "vpn-common:any-to-any-role"; default "vpn-common:any-to-any-role";
description description
"Role of the VPN node in the VPN."; "Role of the VPN node in the VPN.";
} }
uses vpn-instance-profile; uses vpn-instance-profile;
} }
} }
container underlay-transport { container underlay-transport {
description description
"Container for underlay transport."; "Container for the underlay transport.";
uses vpn-common:underlay-transport; uses vpn-common:underlay-transport;
} }
container external-connectivity { container external-connectivity {
if-feature "vpn-common:external-connectivity"; if-feature "vpn-common:external-connectivity";
description description
"Container for external connectivity."; "Container for external connectivity.";
choice profile { choice profile {
description description
"Choice for the external connectivity profile."; "Choice for the external connectivity profile.";
case profile { case profile {
leaf profile-name { leaf profile-name {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-profiles" path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers" + "/valid-provider-identifiers"
+ "/external-connectivity-identifier/id"; + "/external-connectivity-identifier/id";
} }
description description
"Name of the service provider's profile to be applied "Name of the service provider's profile to be
at the VPN service level."; applied at the VPN service level.";
} }
} }
} }
} }
container vpn-nodes { container vpn-nodes {
description description
"Container for VPN nodes."; "Container for VPN nodes.";
list vpn-node { list vpn-node {
key "vpn-node-id"; key "vpn-node-id";
description description
skipping to change at line 3555 skipping to change at line 3310
"An identifier of the VPN node."; "An identifier of the VPN node.";
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of the VPN node."; "Textual description of the VPN node.";
} }
leaf ne-id { leaf ne-id {
type string; type string;
description description
"Unique identifier of the network element where the VPN "Unique identifier of the network element where
node is deployed."; the VPN node is deployed.";
} }
leaf local-as { leaf local-as {
if-feature "vpn-common:rtg-bgp"; if-feature "vpn-common:rtg-bgp";
type inet:as-number; type inet:as-number;
description description
"Provider's AS number in case the customer requests BGP "Provider's AS number. Used if the customer
routing."; requests BGP routing.";
} }
leaf router-id { leaf router-id {
type rt-types:router-id; type rt-types:router-id;
description description
"A 32-bit number in the dotted-quad format that is used "A 32-bit number in the dotted-quad format that is
to uniquely identify a node within an autonomous used to uniquely identify a node within an AS.
system. This identifier is used for both IPv4 and This identifier is used for both IPv4 and IPv6.";
IPv6.";
} }
container active-vpn-instance-profiles { container active-vpn-instance-profiles {
description description
"Container for active VPN instance profiles."; "Container for active VPN instance profiles.";
list vpn-instance-profile { list vpn-instance-profile {
key "profile-id"; key "profile-id";
description description
"Includes a list of active VPN instance profiles."; "Includes a list of active VPN instance
profiles.";
leaf profile-id { leaf profile-id {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-services/vpn-service" path "/l3vpn-ntw/vpn-services/vpn-service"
+ "/vpn-instance-profiles/vpn-instance-profile" + "/vpn-instance-profiles"
+ "/profile-id"; + "/vpn-instance-profile/profile-id";
} }
description description
"Node's active VPN instance profile."; "Node's active VPN instance profile.";
} }
list router-id { list router-id {
key "address-family"; key "address-family";
description description
"Router-id per address family."; "Router ID per address family.";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates the address family for which the "Indicates the address family for which the
Router-ID applies."; Router ID applies.";
} }
leaf router-id { leaf router-id {
type inet:ip-address; type inet:ip-address;
description description
"The router-id information can be an IPv4 or IPv6 "The 'router-id' information can be an IPv4
address. This can be used, for example, to or IPv6 address. This can be used,
configure an IPv6 address as a router-id for example, to configure an IPv6 address
when such capability is supported by underlay as a Router ID when such a capability is
routers. In such case, the configured value supported by underlay routers. In such a
overrides the generic one defined at the VPN case, the configured value overrides the
node level."; generic value defined at the VPN node
level.";
} }
} }
uses vpn-instance-profile; uses vpn-instance-profile;
} }
} }
container msdp { container msdp {
if-feature "msdp"; if-feature "msdp";
description description
"Includes MSDP-related parameters."; "Includes MSDP-related parameters.";
leaf peer { leaf peer {
skipping to change at line 3654 skipping to change at line 3410
type vpn-common:vpn-id; type vpn-common:vpn-id;
description description
"Identifier for the network access."; "Identifier for the network access.";
} }
leaf interface-id { leaf interface-id {
type string; type string;
description description
"Identifier for the physical or logical "Identifier for the physical or logical
interface. interface.
The identification of the sub-interface The identification of the sub-interface
is provided at the connection and/or IP is provided at the connection level and/or
connection levels."; the IP connection level.";
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of the network access."; "Textual description of the network access.";
} }
leaf vpn-network-access-type { leaf vpn-network-access-type {
type identityref { type identityref {
base vpn-common:site-network-access-type; base vpn-common:site-network-access-type;
} }
default "vpn-common:point-to-point"; default "vpn-common:point-to-point";
description description
"Describes the type of connection, e.g., "Describes the type of connection, e.g.,
point-to-point."; point to point.";
} }
leaf vpn-instance-profile { leaf vpn-instance-profile {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes" path "/l3vpn-ntw/vpn-services/vpn-service"
+ "/vpn-node/active-vpn-instance-profiles" + "/vpn-nodes/vpn-node"
+ "/active-vpn-instance-profiles"
+ "/vpn-instance-profile/profile-id"; + "/vpn-instance-profile/profile-id";
} }
description description
"An identifier of an active VPN instance profile."; "An identifier of an active VPN instance
profile.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
container connection { container connection {
description description
"Defines layer 2 protocols and parameters that are "Defines Layer 2 protocols and parameters that
required to enable connectivity between the PE are required to enable connectivity between
and the CE."; the PE and the CE.";
container encapsulation { container encapsulation {
description description
"Container for layer 2 encapsulation."; "Container for Layer 2 encapsulation.";
leaf type { leaf type {
type identityref { type identityref {
base vpn-common:encapsulation-type; base vpn-common:encapsulation-type;
} }
default "vpn-common:priority-tagged"; default "vpn-common:priority-tagged";
description description
"Encapsulation type. By default, the type of "Encapsulation type. By default, the type
the tagged interface is 'priority-tagged'."; of the tagged interface is
'priority-tagged'.";
} }
container dot1q { container dot1q {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:dot1q')" { + "'vpn-common:dot1q')" {
description description
"Only applies when the type of the "Only applies when the type of the
tagged interface is 'dot1q'."; tagged interface is 'dot1q'.";
} }
description description
"Tagged interface."; "Tagged interface.";
leaf tag-type { leaf tag-type {
type identityref { type identityref {
base vpn-common:tag-type; base vpn-common:tag-type;
} }
default "vpn-common:c-vlan"; default "vpn-common:c-vlan";
description description
"Tag type. By default, the tag type is "Tag type. By default, the tag type is
'c-vlan'."; 'c-vlan'.";
} }
leaf cvlan-id { leaf cvlan-id {
type uint16 { type uint16 {
range "1..4094"; range "1..4094";
} }
description description
"VLAN identifier."; "VLAN identifier.";
} }
} }
container priority-tagged { container priority-tagged {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:priority-tagged')" { + "'vpn-common:priority-tagged')" {
description description
"Only applies when the type of the "Only applies when the type of
tagged interface is 'priority-tagged'."; the tagged interface is
'priority-tagged'.";
} }
description description
"Priority tagged."; "Priority tagged.";
leaf tag-type { leaf tag-type {
type identityref { type identityref {
base vpn-common:tag-type; base vpn-common:tag-type;
} }
default "vpn-common:c-vlan"; default "vpn-common:c-vlan";
description description
"Tag type. By default, the tag type is "Tag type. By default, the tag type is
'c-vlan'."; 'c-vlan'.";
} }
} }
container qinq { container qinq {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:qinq')" { + "'vpn-common:qinq')" {
description description
"Only applies when the type of the tagged "Only applies when the type of the
interface is QinQ."; tagged interface is 'qinq'.";
} }
description description
"Includes QinQ parameters."; "Includes QinQ parameters.";
leaf tag-type { leaf tag-type {
type identityref { type identityref {
base vpn-common:tag-type; base vpn-common:tag-type;
} }
default "vpn-common:s-c-vlan"; default "vpn-common:s-c-vlan";
description description
"Tag type. By default, the tag type is "Tag type.";
'c-s-vlan'.";
} }
leaf svlan-id { leaf svlan-id {
type uint16; type uint16;
mandatory true; mandatory true;
description description
"S-VLAN identifier."; "Service VLAN (S-VLAN) identifier.";
} }
leaf cvlan-id { leaf cvlan-id {
type uint16; type uint16;
mandatory true; mandatory true;
description description
"C-VLAN identifier."; "Customer VLAN (C-VLAN) identifier.";
} }
} }
} }
choice l2-service { choice l2-service {
description description
"The layer 2 connectivity service can be "The Layer 2 connectivity service can be
provided by indicating a pointer to an L2VPN or provided by indicating a pointer to an
by specifying a layer 2 tunnel service."; L2VPN or by specifying a Layer 2 tunnel
service.";
container l2-tunnel-service { container l2-tunnel-service {
description description
"Defines a layer 2 tunnel termination. "Defines a Layer 2 tunnel termination.
It is only applicable when a tunnel is It is only applicable when a tunnel is
required. The supported values are: required. The supported values are
pseudowire, VPLS, and VXLAN. Other 'pseudowire', 'vpls', and 'vxlan'. Other
values may be defined, if needed."; values may be defined, if needed.";
leaf type { leaf type {
type identityref { type identityref {
base l2-tunnel-type; base l2-tunnel-type;
} }
description description
"Selects the tunnel termiantion option for "Selects the tunnel termination option
each vpn-network-access."; for each VPN network access.";
} }
container pseudowire { container pseudowire {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'pseudowire')" { + "'pseudowire')" {
description description
"Only applies when the type of the layer 2 "Only applies when the Layer 2 service
service type is pseudowire ."; type is 'pseudowire'.";
} }
description description
"Includes pseudowire termination parameters."; "Includes pseudowire termination
parameters.";
leaf vcid { leaf vcid {
type uint32; type uint32;
description description
"Indicates a PW or VC identifier."; "Indicates a pseudowire (PW) or
virtual circuit (VC) identifier.";
} }
leaf far-end { leaf far-end {
type union { type union {
type uint32; type uint32;
type inet:ip-address; type inet:ip-address;
} }
description description
"Neighbor reference."; "Neighbor reference.";
reference reference
"RFC 8077: Pseudowire Setup and Maintenance "RFC 8077: Pseudowire Setup and
Using the Label Distribution Maintenance Using the Label
Protocol (LDP), Section 6.1"; Distribution Protocol
(LDP), Section 6.1";
} }
} }
container vpls { container vpls {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpls')" { + "'vpls')" {
description description
"Only applies when the type of the layer 2 "Only applies when the Layer 2 service
service type is VPLS."; type is 'vpls'.";
} }
description description
"VPLS termination parameters."; "VPLS termination parameters.";
leaf vcid { leaf vcid {
type uint32; type uint32;
description description
"VC Identifier."; "VC identifier.";
} }
leaf-list far-end { leaf-list far-end {
type union { type union {
type uint32; type uint32;
type inet:ip-address; type inet:ip-address;
} }
description description
"Neighbor reference."; "Neighbor reference.";
} }
} }
container vxlan { container vxlan {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vxlan')" { + "'vxlan')" {
description description
"Only applies when the type of the layer 2 "Only applies when the Layer 2 service
service type is VXLAN."; type is 'vxlan'.";
} }
description description
"VXLAN termination parameters."; "VXLAN termination parameters.";
leaf vni-id { leaf vni-id {
type uint32; type uint32;
mandatory true; mandatory true;
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;
} }
default "vpn-common:static-mode"; default "vpn-common:static-mode";
description description
"Specifies the VXLAN access mode. By "Specifies the VXLAN access mode. By
default, the peer mode is set to default, the peer mode is set to
'static-mode'."; 'static-mode'.";
} }
leaf-list peer-ip-address { leaf-list peer-ip-address {
type inet:ip-address; type inet:ip-address;
description description
"List of peer's IP addresses."; "List of a peer's IP addresses.";
} }
} }
} }
case l2vpn { case l2vpn {
leaf l2vpn-id { leaf l2vpn-id {
type vpn-common:vpn-id; type vpn-common:vpn-id;
description description
"Indicates the L2VPN service associated with "Indicates the L2VPN service associated
an Integrated Routing and Bridging (IRB) with an Integrated Routing and Bridging
interface."; (IRB) interface.";
} }
} }
} }
leaf l2-termination-point { leaf l2-termination-point {
type string; type string;
description description
"Specifies a reference to a local layer 2 "Specifies a reference to a local Layer 2
termination point such as a layer 2 termination point, such as a Layer 2
sub-interface."; sub-interface.";
} }
leaf local-bridge-reference { leaf local-bridge-reference {
type string; type string;
description description
"Specifies a local bridge reference to "Specifies a local bridge reference to
accommodate, for example, implementations accommodate, for example, implementations
that require internal bridging. that require internal bridging.
A reference may be a local bridge domain."; A reference may be a local bridge domain.";
} }
leaf bearer-reference { leaf bearer-reference {
if-feature "vpn-common:bearer-reference"; if-feature "vpn-common:bearer-reference";
type string; type string;
description description
"This is an internal reference for the service "This is an internal reference for the
provider to identify the bearer associated service provider to identify the bearer
with this VPN."; associated with this VPN.";
} }
container lag-interface { container lag-interface {
if-feature "vpn-common:lag-interface"; if-feature "vpn-common:lag-interface";
description description
"Container of LAG interface attributes "Container for configuration of Link
configuration."; Aggregation Group (LAG) interface
attributes.";
leaf lag-interface-id { leaf lag-interface-id {
type string; type string;
description description
"LAG interface identifier."; "LAG interface identifier.";
} }
container member-link-list { container member-link-list {
description description
"Container of Member link list."; "Container for the member link list.";
list member-link { list member-link {
key "name"; key "name";
description description
"Member link."; "Member link.";
leaf name { leaf name {
type string; type string;
description description
"Member link name."; "Member link name.";
} }
} }
} }
} }
} }
container ip-connection { container ip-connection {
description description
"Defines IP connection parameters."; "Defines IP connection parameters.";
leaf l3-termination-point { leaf l3-termination-point {
type string; type string;
description description
"Specifies a reference to a local layer 3 "Specifies a reference to a local Layer 3
termination point such as a bridge domain termination point, such as a bridge domain
interface."; interface.";
} }
container ipv4 { container ipv4 {
if-feature "vpn-common:ipv4"; if-feature "vpn-common:ipv4";
description description
"IPv4-specific parameters."; "IPv4-specific parameters.";
leaf local-address { leaf local-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"The IP address used at the provider's "The IP address used at the provider's
skipping to change at line 3970 skipping to change at line 3734
description description
"Subnet prefix length expressed in bits. "Subnet prefix length expressed in bits.
It is applied to both local and customer It is applied to both local and customer
addresses."; 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(), " must "not(derived-from-or-self(current(), "
+ "'slaac') or derived-from-or-self(current()," + "'slaac') or "
+ " 'provider-dhcp-slaac'))" { + "derived-from-or-self(current(), "
error-message + "'provider-dhcp-slaac'))" {
"SLAAC is only applicable to IPv6."; error-message "SLAAC is only applicable "
+ "to IPv6.";
} }
description description
"Defines how addresses are allocated to the "Defines how addresses are allocated to
peer site. the peer site.
If there is no value for the address If there is no value for the address
allocation type, then IPv4 addressing is not allocation type, then IPv4 addressing
enabled."; is not enabled.";
} }
choice allocation-type { choice allocation-type {
description description
"Choice of the IPv4 address allocation."; "Choice of the IPv4 address allocation.";
case provider-dhcp { case provider-dhcp {
description description
"DHCP allocated addresses related "Parameters related to DHCP-allocated
parameters. IP addresses are allocated addresses. IP addresses are allocated
by DHCP that is operated by the provider"; by DHCP, which is provided 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 "Local DHCP relay. DHCP requests
relayed to a provider's server."; are relayed to a provider's
server.";
} }
} }
description description
"Indicates the type of DHCP service to "Indicates the type of DHCP service to
be enabled on this access."; be enabled on this access.";
} }
choice service-type { choice service-type {
description description
"Choice based on the DHCP service type."; "Choice based on the DHCP service
type.";
case relay { case relay {
description description
"Container for list of provider's DHCP "Container for a list of the
servers (i.e., dhcp-service-type is set provider's DHCP servers (i.e.,
to relay)."; 'dhcp-service-type' is set to
'relay').";
leaf-list server-ip-address { leaf-list server-ip-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 addresses of the provider's DHCP "IPv4 addresses of the provider's
server to use by the local DHCP DHCP server, for use by the local
relay."; DHCP relay.";
} }
} }
case server { case server {
description description
"A choice about how addresses are assigned "A choice for how addresses are
when a local DHCP server is enabled."; assigned when a local DHCP server
is enabled.";
choice address-assign { choice address-assign {
default "number"; default "number";
description description
"Choice for how IPv4 addresses are "A choice for how IPv4 addresses
assigned."; are assigned.";
case number { case number {
leaf number-of-dynamic-address { leaf number-of-dynamic-address {
type uint16; type uint16;
default "1"; default "1";
description description
"Specifies the number of IP "Specifies the number of IP
addresses to be assigned to the addresses to be assigned to
customer on this access."; the customer on this
access.";
} }
} }
case explicit { case explicit {
container customer-addresses { container customer-addresses {
description description
"Container for customer "Container for customer
addresses to be allocated addresses to be allocated
using DHCP."; using DHCP.";
list address-pool { list address-pool {
key "pool-id"; key "pool-id";
description description
"Describes IP addresses to be "Describes IP addresses to
allocated by DHCP. be allocated by DHCP.
When only start-address is When only 'start-address'
present, it represents a single is present, it represents a
address. single address.
When both start-address and When both 'start-address'
end-address are specified, it and 'end-address' are
implies a range inclusive of both specified, it implies a
range inclusive of both
addresses."; addresses.";
leaf pool-id { leaf pool-id {
type string; type string;
description description
"A pool identifier for the "A pool identifier for the
address range from start- address range from
address to end-address."; 'start-address' to
'end-address'.";
} }
leaf start-address { leaf start-address {
type inet:ipv4-address; type inet:ipv4-address;
mandatory true; mandatory true;
description description
"Indicates the first address "Indicates the first
in the pool."; address in the pool.";
} }
leaf end-address { leaf end-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"Indicates the last address "Indicates the last
in the pool."; address in the pool.";
} }
} }
} }
} }
} }
} }
} }
} }
case dhcp-relay { case dhcp-relay {
description description
"DHCP relay is provided by the operator."; "The DHCP relay is provided by the
operator.";
container customer-dhcp-servers { container customer-dhcp-servers {
description description
"Container for a list of customer's DHCP "Container for a list of the
servers."; customer's DHCP servers.";
leaf-list server-ip-address { leaf-list server-ip-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 addresses of the customer's DHCP "IPv4 addresses of the customer's
server."; DHCP server.";
} }
} }
} }
case static-addresses { case static-addresses {
description description
"Lists the IPv4 addresses that are used."; "Lists the IPv4 addresses that are
used.";
leaf primary-address { leaf primary-address {
type leafref { type leafref {
path "../address/address-id"; path "../address/address-id";
} }
description description
"Primary address of the connection."; "Primary address of the connection.";
} }
list address { list address {
key "address-id"; key "address-id";
description description
"Lists the IPv4 addresses that are used."; "Lists the IPv4 addresses that are
used.";
leaf address-id { leaf address-id {
type string; type string;
description description
"An identifier of the static IPv4 "An identifier of the static IPv4
address."; address.";
} }
leaf customer-address { leaf customer-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 address at the customer side."; "IPv4 address of the customer
side.";
} }
} }
} }
} }
} }
container ipv6 { container ipv6 {
if-feature "vpn-common:ipv6"; if-feature "vpn-common:ipv6";
description description
"IPv6-specific parameters."; "IPv6-specific parameters.";
leaf local-address { leaf local-address {
skipping to change at line 4163 skipping to change at line 3940
base address-allocation-type; base address-allocation-type;
} }
description description
"Defines how addresses are allocated. "Defines how addresses are allocated.
If there is no value for the address If there is no value for the address
allocation type, then IPv6 addressing is allocation type, then IPv6 addressing is
disabled."; disabled.";
} }
choice allocation-type { choice allocation-type {
description description
"A choice based on the IPv6 allocation type."; "A choice based on the IPv6 allocation
type.";
container provider-dhcp { container provider-dhcp {
when "derived-from-or-self(../address-allo" when "derived-from-or-self(../address-allo"
+ "cation-type, 'provider-dhcp') " + "cation-type, 'provider-dhcp') or "
+ "or derived-from-or-self(../address-allo" + "derived-from-or-self(../address-allo"
+ "cation-type, 'provider-dhcp-slaac')" { + "cation-type, 'provider-dhcp-slaac')" {
description description
"Only applies when addresses are "Only applies when addresses are
allocated by DHCPv6 provided by the allocated by DHCPv6 as provided by
operator."; the operator.";
} }
description description
"DHCPv6 allocated addresses related "Parameters related to DHCP-allocated
parameters."; addresses.";
leaf dhcp-service-type { leaf dhcp-service-type {
type enumeration { type enumeration {
enum server { enum server {
description description
"Local DHCPv6 server."; "Local DHCPv6 server.";
} }
enum relay { enum relay {
description description
"DHCPv6 relay."; "DHCPv6 relay.";
} }
} }
description description
"Indicates the type of the DHCPv6 service to "Indicates the type of the DHCPv6
be enabled on this access."; service to be enabled on this
access.";
} }
choice service-type { choice service-type {
description description
"Choice based on the DHCPv6 service type."; "Choice based on the DHCPv6 service
type.";
case relay { case relay {
leaf-list server-ip-address { leaf-list server-ip-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IPv6 addresses of the provider's "IPv6 addresses of the provider's
DHCPv6 server."; DHCPv6 server.";
} }
} }
case server { case server {
choice address-assign { choice address-assign {
default "number"; default "number";
description description
"Choice about how IPv6 prefixes are "Choice for how IPv6 prefixes are
assigned by the DHCPv6 server."; assigned by the DHCPv6 server.";
case number { case number {
leaf number-of-dynamic-address { leaf number-of-dynamic-address {
type uint16; type uint16;
default "1"; default "1";
description description
"Describes the number of IPv6 "Describes the number of IPv6
prefixes that are allocated to prefixes that are allocated
the customer on this access."; to the customer on this
access.";
} }
} }
case explicit { case explicit {
container customer-addresses { container customer-addresses {
description description
"Container for customer IPv6 "Container for customer IPv6
addresses allocated by DHCPv6."; addresses allocated by
DHCPv6.";
list address-pool { list address-pool {
key "pool-id"; key "pool-id";
description description
"Describes IPv6 addresses "Describes IPv6 addresses
allocated by DHCPv6. allocated by DHCPv6.
When only start-address is When only 'start-address'
present, it represents a single is present, it represents a
address. single address.
When both start-address and When both 'start-address'
end-address are specified, it and 'end-address' are
implies a range inclusive of specified, it implies a
both addresses."; range inclusive of both
addresses.";
leaf pool-id { leaf pool-id {
type string; type string;
description description
"Pool identifier for the address "A pool identifier for the
range from identified by start- address range from
address and end-address."; 'start-address' to
'end-address'.";
} }
leaf start-address { leaf start-address {
type inet:ipv6-address; type inet:ipv6-address;
mandatory true; mandatory true;
description description
"Indicates the first address."; "Indicates the first
address.";
} }
leaf end-address { leaf end-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Indicates the last address."; "Indicates the last
address.";
} }
} }
} }
} }
} }
} }
} }
} }
case dhcp-relay { case dhcp-relay {
description description
"DHCPv6 relay provided by the operator."; "DHCPv6 relay provided by the
operator.";
container customer-dhcp-servers { container customer-dhcp-servers {
description description
"Container for a list of customer DHCP "Container for a list of the
servers."; customer's DHCP servers.";
leaf-list server-ip-address { leaf-list server-ip-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Contains the IP addresses of the customer "Contains the IP addresses of the
DHCPv6 server."; customer's DHCPv6 server.";
} }
} }
} }
case static-addresses { case static-addresses {
description description
"IPv6-specific parameters for static "IPv6-specific parameters for static
allocation."; allocation.";
leaf primary-address { leaf primary-address {
type leafref { type leafref {
path "../address/address-id"; path "../address/address-id";
} }
description description
"Principal address of the connection"; "Principal address of the
connection.";
} }
list address { list address {
key "address-id"; key "address-id";
description description
"Describes IPv6 addresses that are used."; "Describes IPv6 addresses that are
used.";
leaf address-id { leaf address-id {
type string; type string;
description description
"An identifier of an IPv6 address."; "An identifier of an IPv6 address.";
} }
leaf customer-address { leaf customer-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"An IPv6 address of the customer side."; "An IPv6 address of the customer
side.";
} }
} }
} }
} }
} }
} }
container routing-protocols { container routing-protocols {
description description
"Defines routing protocols."; "Defines routing protocols.";
list routing-protocol { list routing-protocol {
key "id"; key "id";
description description
"List of routing protocols used on "List of routing protocols used on the
the CE/PE link. This list can be augmented."; CE-PE link. This list can be augmented.";
leaf id { leaf id {
type string; type string;
description description
"Unique identifier for routing protocol."; "Unique identifier for the routing
protocol.";
} }
leaf type { leaf type {
type identityref { type identityref {
base vpn-common:routing-protocol-type; base vpn-common:routing-protocol-type;
} }
description description
"Type of routing protocol."; "Type of routing protocol.";
} }
list routing-profiles { list routing-profiles {
key "id"; key "id";
skipping to change at line 4353 skipping to change at line 4144
base vpn-common:ie-type; base vpn-common:ie-type;
} }
description description
"Import, export, or both."; "Import, export, or both.";
} }
} }
container static { container static {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:static-routing')" { + "'vpn-common:static-routing')" {
description description
"Only applies when protocol is static."; "Only applies when the protocol is a
static routing protocol.";
} }
description description
"Configuration specific to static routing."; "Configuration specific to static
routing.";
container cascaded-lan-prefixes { container cascaded-lan-prefixes {
description description
"LAN prefixes from the customer."; "LAN prefixes from the customer.";
list ipv4-lan-prefixes { list ipv4-lan-prefixes {
if-feature "vpn-common:ipv4"; if-feature "vpn-common:ipv4";
key "lan next-hop"; key "lan next-hop";
description description
"List of LAN prefixes for the site."; "List of LAN prefixes for the site.";
leaf lan { leaf lan {
type inet:ipv4-prefix; type inet:ipv4-prefix;
skipping to change at line 4382 skipping to change at line 4175
description description
"Internal tag to be used in VPN "Internal tag to be used in VPN
policies."; policies.";
} }
leaf next-hop { leaf next-hop {
type union { type union {
type inet:ip-address; type inet:ip-address;
type predefined-next-hop; type predefined-next-hop;
} }
description description
"The next-hop that is to be used "The next hop that is to be used
for the static route. This may be for the static route. This may be
specified as an IP address or a specified as an IP address or a
pre-defined next-hop type (e.g., predefined next-hop type (e.g.,
discard or local-link)."; 'discard' or 'local-link').";
} }
leaf bfd-enable { leaf bfd-enable {
if-feature "vpn-common:bfd"; if-feature "vpn-common:bfd";
type boolean; type boolean;
description description
"Enables BFD."; "Enables Bidirectional Forwarding
Detection (BFD).";
} }
leaf metric { leaf metric {
type uint32; type uint32;
description description
"Indicates the metric associated with "Indicates the metric associated
the static route."; with the static route.";
} }
leaf preference { leaf preference {
type uint32; type uint32;
description description
"Indicates the preference of the static "Indicates the preference associated
routes."; with the static route.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
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 site."; "List of LAN prefixes for the site.";
leaf lan { leaf lan {
type inet:ipv6-prefix; type inet:ipv6-prefix;
skipping to change at line 4430 skipping to change at line 4224
description description
"Internal tag to be used in VPN "Internal tag to be used in VPN
policies."; policies.";
} }
leaf next-hop { leaf next-hop {
type union { type union {
type inet:ip-address; type inet:ip-address;
type predefined-next-hop; type predefined-next-hop;
} }
description description
"The next-hop that is to be used for the "The next hop that is to be used for
static route. This may be specified as the static route. This may be
an IP address or a pre-defined next-hop specified as an IP address or a
type (e.g., discard or local-link)."; predefined next-hop type (e.g.,
'discard' or 'local-link').";
} }
leaf bfd-enable { leaf bfd-enable {
if-feature "vpn-common:bfd"; if-feature "vpn-common:bfd";
type boolean; type boolean;
description description
"Enables BFD."; "Enables BFD.";
} }
leaf metric { leaf metric {
type uint32; type uint32;
description description
"Indicates the metric associated with "Indicates the metric associated
the static route."; with the static route.";
} }
leaf preference { leaf preference {
type uint32; type uint32;
description description
"Indicates the preference associated "Indicates the preference associated
with the static route."; with the static route.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
} }
} }
container bgp { container bgp {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:bgp-routing')" { + "'vpn-common:bgp-routing')" {
description description
"Only applies when protocol is BGP."; "Only applies when the protocol is
BGP.";
} }
description description
"BGP-specific configuration."; "Configuration specific to BGP.";
leaf description { leaf description {
type string; type string;
description description
"Includes a description of the BGP session. "Includes a description of the BGP
session.
This description is meant to be used for This description is meant to be used
diagnosis purposes. The semantic of the for diagnostic purposes. The semantic
description is local to an of the description is local to an
implementation."; implementation.";
} }
leaf local-as { leaf local-as {
type inet:as-number; type inet:as-number;
description description
"Indicates a local AS Number (ASN) if a "Indicates a local AS Number (ASN), if
distinct ASN than the one configured at an ASN distinct from the ASN configured
the VPN node level is needed."; at the VPN node level is needed.";
} }
leaf peer-as { leaf peer-as {
type inet:as-number; type inet:as-number;
mandatory true; mandatory true;
description description
"Indicates the customer's ASN when "Indicates the customer's ASN when
the customer requests BGP routing."; the customer requests BGP routing.";
} }
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"This node contains the address families to be "This node contains the address families
activated. Dual-stack means that both IPv4 to be activated. 'dual-stack' means
and IPv6 will be activated."; that both IPv4 and IPv6 will be
activated.";
} }
leaf local-address { leaf local-address {
type union { type union {
type inet:ip-address; type inet:ip-address;
type if:interface-ref; type if:interface-ref;
} }
description description
"Set the local IP address to use for the BGP "Sets the local IP address to use for
transport session. This may be expressed as the BGP transport session. This may be
either an IP address or a reference to an expressed as either an IP address or a
interface."; reference to an interface.";
} }
leaf-list neighbor { leaf-list neighbor {
type inet:ip-address; type inet:ip-address;
description description
"IP address(es) of the BGP neighbor. IPv4 "IP address(es) of the BGP neighbor.
and IPv6 neighbors may be indicated if IPv4 and IPv6 neighbors may be
two sessions will be used for IPv4 and indicated if two sessions will be used
IPv6."; for IPv4 and IPv6.";
} }
leaf multihop { leaf multihop {
type uint8; type uint8;
description description
"Describes the number of IP hops allowed "Describes the number of IP hops allowed
between a given BGP neighbor and the PE."; between a given BGP neighbor and
the PE.";
} }
leaf as-override { leaf as-override {
type boolean; type boolean;
default "false"; default "false";
description description
"Defines whether ASN override is enabled, "Defines whether ASN override is
i.e., replace the ASN of the customer enabled, i.e., replacing the ASN of
specified in the AS_Path attribute with the customer specified in the AS_PATH
the local ASN."; attribute with the local ASN.";
} }
leaf allow-own-as { leaf allow-own-as {
type uint8; type uint8;
default "0"; default "0";
description description
"Specifies the number of occurrences "If set, specifies the maximum number of
of the provider's ASN that can occur occurrences of the provider's ASN that
within the AS_PATH before it are permitted within the AS_PATH
is rejected."; before it is rejected.";
} }
leaf prepend-global-as { leaf prepend-global-as {
type boolean; type boolean;
default "false"; default "false";
description description
"In some situations, the ASN that is "In some situations, the ASN that is
provided at the VPN node level may be provided at the VPN node level may be
distinct from the one configured at the distinct from the ASN configured at the
VPN network access level. When such VPN network access level. When such
ASNs are provided, they are both ASNs are provided, they are both
prepended to the BGP route updates prepended to the BGP route updates
for this access. To disable that for this access. To disable that
behavior, the prepend-global-as behavior, 'prepend-global-as'
must be set to 'false'. In such a case, must be set to 'false'. In such a
the ASN that is provided at case, the ASN that is provided at
the VPN node level is not prepended to the VPN node level is not prepended
the BGP route updates for this access."; to the BGP route updates for
this access.";
} }
leaf send-default-route { leaf send-default-route {
type boolean; type boolean;
default "false"; default "false";
description description
"Defines whether default routes can be "Defines whether default routes can be
advertised to its peer. If set, the advertised to a peer. If set, the
default routes are advertised to its default routes are advertised to a
peer."; peer.";
} }
leaf site-of-origin { leaf site-of-origin {
when "../address-family = 'vpn-common:ipv4' or " when "../address-family = 'vpn-common:ipv4' "
+ "'vpn-common:dual-stack'" { + "or 'vpn-common:dual-stack'" {
description description
"Only applies if IPv4 is activated."; "Only applies if IPv4 is activated.";
} }
type rt-types:route-origin; type rt-types:route-origin;
description description
"The Site of Origin attribute is encoded as "The Site of Origin attribute is encoded
a Route Origin Extended Community. It is as a Route Origin Extended Community.
meant to uniquely identify the set of routes It is meant to uniquely identify the
learned from a site via a particular CE/PE set of routes learned from a site via a
connection and is used to prevent routing particular CE-PE connection and is used
loops."; to prevent routing loops.";
reference reference
"RFC 4364: BGP/MPLS IP Virtual Private "RFC 4364: BGP/MPLS IP Virtual Private
Networks (VPNs), Section 7"; Networks (VPNs), Section 7";
} }
leaf ipv6-site-of-origin { leaf ipv6-site-of-origin {
when "../address-family = 'vpn-common:ipv6' or " when "../address-family = 'vpn-common:ipv6' "
+ "'vpn-common:dual-stack'" { + "or 'vpn-common:dual-stack'" {
description description
"Only applies if IPv6 is activated."; "Only applies if IPv6 is activated.";
} }
type rt-types:ipv6-route-origin; type rt-types:ipv6-route-origin;
description description
"IPv6 Route Origins are IPv6 Address Specific "The IPv6 Site of Origin attribute is
BGP Extended that are meant to the Site of encoded as an IPv6 Route Origin
Origin for VRF information."; Extended Community. It is meant to
uniquely identify the set of routes
learned from a site via VRF
information.";
reference reference
"RFC 5701: IPv6 Address Specific BGP Extended "RFC 5701: IPv6 Address Specific BGP
Community Attribute"; Extended Community
Attribute";
} }
list redistribute-connected { list redistribute-connected {
key "address-family"; key "address-family";
description description
"Indicates the per-AF policy to follow "Indicates, per address family, the
for connected routes."; policy to follow for connected
routes.";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates the address family."; "Indicates the address family.";
} }
leaf enable { leaf enable {
type boolean; type boolean;
description description
"Enables to redistribute connected "Enables the redistribution of
routes."; connected routes.";
} }
} }
container bgp-max-prefix { container bgp-max-prefix {
description description
"Controls the behavior when a prefix "Controls the behavior when a prefix
maximum is reached."; maximum is reached.";
leaf max-prefix { leaf max-prefix {
type uint32; type uint32;
default "5000"; default "5000";
description description
"Indicates the maximum number of BGP "Indicates the maximum number of BGP
prefixes allowed in the BGP session. prefixes allowed in the BGP session.
It allows control of how many prefixes It allows control of how many
can be received from a neighbor. prefixes can be received from a
neighbor.
If the limit is exceeded, the action If the limit is exceeded, the action
indicated in violate-action will be indicated in 'violate-action' will be
followed."; followed.";
reference reference
"RFC 4271: A Border Gateway Protocol 4 "RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 8.2.2"; (BGP-4), Section 8.2.2";
} }
leaf warning-threshold { leaf warning-threshold {
type decimal64 { type decimal64 {
fraction-digits 5; fraction-digits 5;
range "0..100"; range "0..100";
} }
skipping to change at line 4667 skipping to change at line 4473
exceeded."; exceeded.";
} }
enum discard-extra-paths { enum discard-extra-paths {
description description
"Discards extra paths when the "Discards extra paths when the
limit is exceeded."; limit is exceeded.";
} }
enum restart { enum restart {
description description
"The BGP session restarts after "The BGP session restarts after
a time interval."; the indicated time interval.";
} }
} }
description description
"BGP neighbor max-prefix violate "If the BGP neighbor 'max-prefix'
action."; limit is reached, the action
indicated in 'violate-action'
will be followed.";
} }
leaf restart-timer { leaf restart-timer {
type uint32; type uint32;
units "seconds"; units "seconds";
description description
"Time interval after which the BGP "Time interval after which the BGP
session will be reestablished."; session will be reestablished.";
} }
} }
container bgp-timers { container bgp-timers {
description description
"Includes two BGP timers that can be "Includes two BGP timers that can be
customized when building a VPN service customized when building a VPN service
with BGP used as CE-PE routing with BGP used as the CE-PE routing
protocol."; protocol.";
leaf keepalive { leaf keepalive {
type uint16 { type uint16 {
range "0..21845"; range "0..21845";
} }
units "seconds"; units "seconds";
default "30"; default "30";
description description
"This timer indicates the KEEPALIVE "This timer indicates the KEEPALIVE
messages' frequency between a PE messages' frequency between a PE
and a BGP peer. and a BGP peer.
If set to '0', it indicates KEEPALIVE If set to '0', it indicates that
messages are disabled. KEEPALIVE messages are disabled.
It is suggested that the maximum time It is suggested that the maximum
between KEEPALIVE messages would be time between KEEPALIVE messages be
one third of the Hold Time interval."; one-third of the Hold Time
interval.";
reference reference
"RFC 4271: A Border Gateway Protocol 4 "RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 4.4"; (BGP-4), Section 4.4";
} }
leaf hold-time { leaf hold-time {
type uint16 { type uint16 {
range "0 | 3..65535"; range "0 | 3..65535";
} }
units "seconds"; units "seconds";
default "90"; default "90";
description description
"It indicates the maximum number of "Indicates the maximum number of
seconds that may elapse between the seconds that may elapse between the
receipt of successive KEEPALIVE receipt of successive KEEPALIVE
and/or UPDATE messages from the peer. and/or UPDATE messages from the peer.
The Hold Time must be either zero or The Hold Time must be either zero or
at least three seconds."; at least three seconds.";
reference reference
"RFC 4271: A Border Gateway Protocol 4 "RFC 4271: A Border Gateway Protocol 4
(BGP-4), Section 4.2"; (BGP-4), Section 4.2";
} }
skipping to change at line 4741 skipping to change at line 4550
parameters between a PE and a CE."; parameters between a PE and a CE.";
leaf enable { leaf enable {
type boolean; type boolean;
default "false"; default "false";
description description
"Enables or disables authentication."; "Enables or disables authentication.";
} }
container keying-material { container keying-material {
when "../enable = 'true'"; when "../enable = 'true'";
description description
"Container for describing how a BGP routing "Container for describing how a BGP
session is to be secured between a PE and routing session is to be secured
a CE."; between a PE and a CE.";
choice option { choice option {
description description
"Choice of authentication options."; "Choice of authentication options.";
case ao { case ao {
description description
"Uses TCP-Authentication Option "Uses the TCP Authentication
(TCP-AO)."; Option (TCP-AO).";
reference reference
"RFC 5925: The TCP Authentication "RFC 5925: The TCP Authentication
Option."; Option";
leaf enable-ao { leaf enable-ao {
type boolean; type boolean;
description description
"Enables TCP-AO."; "Enables the TCP-AO.";
} }
leaf ao-keychain { leaf ao-keychain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"Reference to the TCP-AO key chain."; "Reference to the TCP-AO key
chain.";
reference reference
"RFC 8177: YANG Key Chain."; "RFC 8177: YANG Data Model for
Key Chains";
} }
} }
case md5 { case md5 {
description description
"Uses MD5 to secure the session."; "Uses MD5 to secure the session.";
reference reference
"RFC 4364: BGP/MPLS IP Virtual Private "RFC 4364: BGP/MPLS IP Virtual
Networks (VPNs), Private Networks
Section 13.2"; (VPNs), Section 13.2";
leaf md5-keychain { leaf md5-keychain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"Reference to the MD5 key chain."; "Reference to the MD5 key
chain.";
reference reference
"RFC 8177: YANG Key Chain"; "RFC 8177: YANG Data Model for
Key Chains";
} }
} }
case explicit { case explicit {
leaf key-id { leaf key-id {
type uint32; type uint32;
description description
"Key Identifier."; "Key identifier.";
} }
leaf key { leaf key {
type string; type string;
description description
"BGP authentication key. "BGP authentication key.
This model only supports the subset This model only supports the
of keys that are representable as subset of keys that are
ASCII strings."; representable as ASCII
strings.";
} }
leaf crypto-algorithm { leaf crypto-algorithm {
type identityref { type identityref {
base key-chain:crypto-algorithm; base key-chain:crypto-algorithm;
} }
description description
"Indicates the cryptographic algorithm "Indicates the cryptographic
associated with the key."; algorithm associated with the
key.";
} }
} }
case ipsec { case ipsec {
description description
"Specifies a reference to an IKE "Specifies a reference to an
Security Association (SA)."; Internet Key Exchange Protocol
(IKE) Security Association
(SA).";
leaf sa { leaf sa {
type string; type string;
description description
"Indicates the administrator-assigned "Indicates the
name of the SA."; administrator-assigned name
of the SA.";
} }
} }
} }
} }
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
container ospf { container ospf {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:ospf-routing')" { + "'vpn-common:ospf-routing')" {
description description
"Only applies when protocol is OSPF."; "Only applies when the protocol is
OSPF.";
} }
description description
"OSPF-specific configuration."; "Configuration specific to OSPF.";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates whether IPv4, IPv6, or "Indicates whether IPv4, IPv6, or
both are to be activated."; both are to be activated.";
} }
leaf area-id { leaf area-id {
type yang:dotted-quad; type yang:dotted-quad;
skipping to change at line 4855 skipping to change at line 4674
Virtual Private Networks Virtual Private Networks
(VPNs), Section 4.2.3 (VPNs), Section 4.2.3
RFC 6565: OSPFv3 as a Provider Edge to RFC 6565: OSPFv3 as a Provider Edge to
Customer Edge (PE-CE) Routing Customer Edge (PE-CE) Routing
Protocol, Section 4.2"; Protocol, Section 4.2";
} }
leaf metric { leaf metric {
type uint16; type uint16;
default "1"; default "1";
description description
"Metric of the PE-CE link. It is used "Metric of the PE-CE link. It is used
in the routing state calculation and in the routing state calculation and
path selection."; path selection.";
} }
container sham-links { container sham-links {
if-feature "vpn-common:rtg-ospf-sham-link"; if-feature "vpn-common:rtg-ospf-sham-link";
description description
"List of sham links."; "List of sham links.";
reference reference
"RFC 4577: OSPF as the Provider/Customer "RFC 4577: OSPF as the Provider/Customer
Edge Protocol for BGP/MPLS IP Edge Protocol for BGP/MPLS IP
Virtual Private Networks Virtual Private Networks
(VPNs), Section 4.2.7 (VPNs), Section 4.2.7
RFC 6565: OSPFv3 as a Provider Edge to RFC 6565: OSPFv3 as a Provider Edge to
Customer Edge (PE-CE) Routing Customer Edge (PE-CE) Routing
Protocol, Section 5"; Protocol, Section 5";
list sham-link { list sham-link {
key "target-site"; key "target-site";
description description
"Creates a sham link with another site."; "Creates a sham link with another
site.";
leaf target-site { leaf target-site {
type string; type string;
description description
"Target site for the sham link connection. "Target site for the sham link
The site is referred to by its connection. The site is referred
identifier."; to by its identifier.";
} }
leaf metric { leaf metric {
type uint16; type uint16;
default "1"; default "1";
description description
"Metric of the sham link. It is used in "Metric of the sham link. It is
the routing state calculation and path used in the routing state
selection. The default value is set calculation and path selection.
to 1."; The default value is set to '1'.";
reference reference
"RFC 4577: OSPF as the Provider/Customer "RFC 4577: OSPF as the
Edge Protocol for BGP/MPLS IP Provider/Customer Edge
Protocol for BGP/MPLS IP
Virtual Private Networks Virtual Private Networks
(VPNs), Section 4.2.7.3 (VPNs), Section 4.2.7.3
RFC 6565: OSPFv3 as a Provider Edge to RFC 6565: OSPFv3 as a Provider Edge
Customer Edge (PE-CE) Routing to Customer Edge (PE-CE)
Protocol, Section 5.2"; Routing Protocol,
Section 5.2";
} }
} }
} }
leaf max-lsa { leaf max-lsa {
type uint32 { type uint32 {
range "1..4294967294"; range "1..4294967294";
} }
description description
"Maximum number of allowed LSAs OSPF."; "Maximum number of allowed Link State
Advertisements (LSAs) that the OSPF
instance will accept.";
} }
container authentication { container authentication {
description description
"Authentication configuration."; "Authentication configuration.";
leaf enable { leaf enable {
type boolean; type boolean;
default "false"; default "false";
description description
"Enables or disables authentication."; "Enables or disables authentication.";
} }
skipping to change at line 4930 skipping to change at line 4754
"Container for describing how an OSPF "Container for describing how an OSPF
session is to be secured between a CE session is to be secured between a CE
and a PE."; and a PE.";
choice option { choice option {
description description
"Options for OSPF authentication."; "Options for OSPF authentication.";
case auth-key-chain { case auth-key-chain {
leaf key-chain { leaf key-chain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"key-chain name."; "Name of the key chain.";
} }
} }
case auth-key-explicit { case auth-key-explicit {
leaf key-id { leaf key-id {
type uint32; type uint32;
description description
"Key identifier."; "Key identifier.";
} }
leaf key { leaf key {
type string; type string;
description description
"OSPF authentication key. "OSPF authentication key.
This model only supports the subset This model only supports the
of keys that are representable as subset of keys that are
ASCII strings."; representable as ASCII
strings.";
} }
leaf crypto-algorithm { leaf crypto-algorithm {
type identityref { type identityref {
base key-chain:crypto-algorithm; base key-chain:crypto-algorithm;
} }
description description
"Indicates the cryptographic algorithm "Indicates the cryptographic
associated with the key."; algorithm associated with the
key.";
} }
} }
case ipsec { case ipsec {
leaf sa { leaf sa {
type string; type string;
description description
"Indicates the administrator-assigned "Indicates the
name of the SA."; administrator-assigned name
of the SA.";
reference reference
"RFC 4552: Authentication "RFC 4552: Authentication/
/Confidentiality for Confidentiality for
OSPFv3"; OSPFv3";
} }
} }
} }
} }
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
container isis { container isis {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:isis-routing')" { + "'vpn-common:isis-routing')" {
description description
"Only applies when protocol is IS-IS."; "Only applies when the protocol is
IS-IS.";
} }
description description
"IS-IS specific configuration."; "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;
} }
description description
"Indicates whether IPv4, IPv6, or both "Indicates whether IPv4, IPv6, or both
are to be activated."; are to be activated.";
} }
leaf area-address { leaf area-address {
type area-address; type area-address;
mandatory true; mandatory true;
description description
"Area address."; "Area address.";
} }
leaf level { leaf level {
type identityref { type identityref {
base vpn-common:isis-level; base vpn-common:isis-level;
} }
description description
"Can be level-1, level-2, or level-1-2."; "Can be 'level-1', 'level-2', or
'level-1-2'.";
reference
"RFC 9181: A Common YANG Data Model for
Layer 2 and Layer 3 VPNs";
} }
leaf metric { leaf metric {
type uint16; type uint16;
default "1"; default "1";
description description
"Metric of the PE-CE link. It is used "Metric of the PE-CE link. It is used
in the routing state calculation and in the routing state calculation and
path selection."; path selection.";
} }
leaf mode { leaf mode {
type enumeration { type enumeration {
enum active { enum active {
description description
"Interface sends or receives IS-IS "The interface sends or receives
protocol control packets."; IS-IS protocol control packets.";
} }
enum passive { enum passive {
description description
"Suppresses the sending of IS-IS "Suppresses the sending of IS-IS
updates through the specified updates through the specified
interface."; interface.";
} }
} }
default "active"; default "active";
description description
skipping to change at line 5050 skipping to change at line 4882
"Container for describing how an IS-IS "Container for describing how an IS-IS
session is to be secured between a CE session is to be secured between a CE
and a PE."; and a PE.";
choice option { choice option {
description description
"Options for IS-IS authentication."; "Options for IS-IS authentication.";
case auth-key-chain { case auth-key-chain {
leaf key-chain { leaf key-chain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"key-chain name."; "Name of the key chain.";
} }
} }
case auth-key-explicit { case auth-key-explicit {
leaf key-id { leaf key-id {
type uint32; type uint32;
description description
"Key Identifier."; "Key identifier.";
} }
leaf key { leaf key {
type string; type string;
description description
"IS-IS authentication key. "IS-IS authentication key.
This model only supports the subset This model only supports the
of keys that are representable as subset of keys that are
ASCII strings."; representable as ASCII
strings.";
} }
leaf crypto-algorithm { leaf crypto-algorithm {
type identityref { type identityref {
base key-chain:crypto-algorithm; base key-chain:crypto-algorithm;
} }
description description
"Indicates the cryptographic algorithm "Indicates the cryptographic
associated with the key."; algorithm associated with the
key.";
} }
} }
} }
} }
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
container rip { container rip {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:rip-routing')" { + "'vpn-common:rip-routing')" {
skipping to change at line 5111 skipping to change at line 4945
"Indicates the RIP timers."; "Indicates the RIP timers.";
reference reference
"RFC 2453: RIP Version 2"; "RFC 2453: RIP Version 2";
leaf update-interval { leaf update-interval {
type uint16 { type uint16 {
range "1..32767"; range "1..32767";
} }
units "seconds"; units "seconds";
default "30"; default "30";
description description
"Indicates the RIP update time. "Indicates the RIP update time, i.e.,
That is, the amount of time for which the amount of time for which RIP
RIP updates are sent."; updates are sent.";
} }
leaf invalid-interval { leaf invalid-interval {
type uint16 { type uint16 {
range "1..32767"; range "1..32767";
} }
units "seconds"; units "seconds";
default "180"; default "180";
description description
"Is the interval before a route is declared "The interval before a route is
invalid after no updates are received. declared invalid after no updates are
This value is at least three times received. This value is at least
the value for the update-interval three times the value for the
argument."; 'update-interval' argument.";
} }
leaf holddown-interval { leaf holddown-interval {
type uint16 { type uint16 {
range "1..32767"; range "1..32767";
} }
units "seconds"; units "seconds";
default "180"; default "180";
description description
"Specifies the interval before better routes "Specifies the interval before better
are released."; routes are released.";
} }
leaf flush-interval { leaf flush-interval {
type uint16 { type uint16 {
range "1..32767"; range "1..32767";
} }
units "seconds"; units "seconds";
default "240"; default "240";
description description
"Indicates the RIP flush timer. That is, "Indicates the RIP flush timer, i.e.,
the amount of time that must elapse before the amount of time that must elapse
a route is removed from the routing before a route is removed from the
table."; routing table.";
} }
} }
leaf default-metric { leaf default-metric {
type uint8 { type uint8 {
range "0..16"; range "0..16";
} }
default "1"; default "1";
description description
"Sets the default metric."; "Sets the default metric.";
} }
skipping to change at line 5176 skipping to change at line 5010
"Enables or disables authentication."; "Enables or disables authentication.";
} }
container keying-material { container keying-material {
when "../enable = 'true'"; when "../enable = 'true'";
description description
"Container for describing how a RIP "Container for describing how a RIP
session is to be secured between a CE session is to be secured between a CE
and a PE."; and a PE.";
choice option { choice option {
description description
"Specifies the authentication scheme."; "Specifies the authentication
scheme.";
case auth-key-chain { case auth-key-chain {
leaf key-chain { leaf key-chain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"key-chain name."; "Name of the key chain.";
} }
} }
case auth-key-explicit { case auth-key-explicit {
leaf key { leaf key {
type string; type string;
description description
"RIP authentication key. "RIP authentication key.
This model only supports the subset This model only supports the
of keys that are representable as subset of keys that are
ASCII strings."; representable as ASCII
strings.";
} }
leaf crypto-algorithm { leaf crypto-algorithm {
type identityref { type identityref {
base key-chain:crypto-algorithm; base key-chain:crypto-algorithm;
} }
description description
"Indicates the cryptographic algorithm "Indicates the cryptographic
associated with the key."; algorithm associated with the
key.";
} }
} }
} }
} }
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
container vrrp { container vrrp {
when "derived-from-or-self(../type, " when "derived-from-or-self(../type, "
+ "'vpn-common:vrrp-routing')" { + "'vpn-common:vrrp-routing')" {
description description
"Only applies when protocol is VRRP."; "Only applies when the protocol is the
Virtual Router Redundancy Protocol
(VRRP).";
} }
description description
"Configuration specific to VRRP."; "Configuration specific to VRRP.";
reference reference
"RFC 5798: Virtual Router Redundancy Protocol "RFC 5798: Virtual Router Redundancy
(VRRP) Version 3 for IPv4 and IPv6"; Protocol (VRRP) Version 3 for
IPv4 and IPv6";
leaf address-family { leaf address-family {
type identityref { type identityref {
base vpn-common:address-family; base vpn-common:address-family;
} }
description description
"Indicates whether IPv4, IPv6, or both "Indicates whether IPv4, IPv6, or both
address families are to be enabled."; address families are to be enabled.";
} }
leaf vrrp-group { leaf vrrp-group {
type uint8 { type uint8 {
skipping to change at line 5244 skipping to change at line 5084
type inet:ip-address; type inet:ip-address;
description description
"Indicates the IP address of the peer."; "Indicates the IP address of the peer.";
} }
leaf-list virtual-ip-address { leaf-list virtual-ip-address {
type inet:ip-address; type inet:ip-address;
description description
"Virtual IP addresses for a single VRRP "Virtual IP addresses for a single VRRP
group."; group.";
reference reference
"RFC 5798: Virtual Router Redundancy Protocol "RFC 5798: Virtual Router Redundancy
(VRRP) Version 3 for IPv4 and Protocol (VRRP) Version 3 for
IPv6, Sections 1.2 and 1.3"; IPv4 and IPv6,
Sections 1.2 and 1.3";
} }
leaf priority { leaf priority {
type uint8 { type uint8 {
range "1..254"; range "1..254";
} }
default "100"; default "100";
description description
"Sets the local priority of the VRRP "Sets the local priority of the VRRP
speaker."; speaker.";
} }
leaf ping-reply { leaf ping-reply {
type boolean; type boolean;
default "false"; default "false";
description description
"Controls whether the VRRP speaker should "Controls whether the VRRP speaker
answer to ping requests."; should reply to ping requests.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
} }
} }
container oam { container oam {
description description
"Defines the Operations, Administration, "Defines the Operations, Administration,
and Maintenance (OAM) mechanisms used. and Maintenance (OAM) mechanisms used.
skipping to change at line 5293 skipping to change at line 5134
} }
default "vpn-common:classic-bfd"; default "vpn-common:classic-bfd";
description description
"Specifies the BFD session type."; "Specifies the BFD session type.";
} }
leaf desired-min-tx-interval { leaf desired-min-tx-interval {
type uint32; type uint32;
units "microseconds"; units "microseconds";
default "1000000"; default "1000000";
description description
"The minimum interval between transmission of "The minimum interval between
BFD control packets that the operator transmissions of BFD Control packets, as
desires."; desired by the operator.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection "RFC 5880: Bidirectional Forwarding
(BFD), Section 6.8.7"; Detection (BFD),
Section 6.8.7";
} }
leaf required-min-rx-interval { leaf required-min-rx-interval {
type uint32; type uint32;
units "microseconds"; units "microseconds";
default "1000000"; default "1000000";
description description
"The minimum interval between received BFD "The minimum interval between received BFD
control packets that the PE should support."; Control packets that the PE should
support.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection "RFC 5880: Bidirectional Forwarding
(BFD), Section 6.8.7"; Detection (BFD),
Section 6.8.7";
} }
leaf local-multiplier { leaf local-multiplier {
type uint8 { type uint8 {
range "1..255"; range "1..255";
} }
default "3"; default "3";
description description
"Specifies the detection multiplier that is "Specifies the detection multiplier that
transmitted to a BFD peer. is transmitted to a BFD peer.
The detection interval for the receiving The detection interval for the receiving
BFD peer is calculated by multiplying the value BFD peer is calculated by multiplying the
of the negotiated transmission interval by value of the negotiated transmission
the received detection multiplier value."; interval by the received detection
multiplier value.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection "RFC 5880: Bidirectional Forwarding
(BFD), Section 6.8.7"; Detection (BFD),
Section 6.8.7";
} }
leaf holdtime { leaf holdtime {
type uint32; type uint32;
units "milliseconds"; units "milliseconds";
description description
"Expected BFD holdtime. "Expected BFD holdtime.
The customer may impose some fixed The customer may impose some fixed
values for the holdtime period if the values for the holdtime period if the
provider allows the customer use of provider allows the customer to use
this function. this function.
If the provider doesn't allow the If the provider doesn't allow the
customer to use this function, customer to use this function,
the fixed-value will not be set."; fixed values will not be set.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection "RFC 5880: Bidirectional Forwarding
(BFD), Section 6.8.18"; Detection (BFD),
Section 6.8.18";
} }
leaf profile { leaf profile {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-profiles" path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers" + "/valid-provider-identifiers"
+ "/bfd-profile-identifier/id"; + "/bfd-profile-identifier/id";
} }
description description
"Well-known service provider profile name. "Well-known service provider profile name.
skipping to change at line 5367 skipping to change at line 5214
service level the customer wants to service level the customer wants to
achieve."; achieve.";
} }
container authentication { container authentication {
presence "Enables BFD authentication"; presence "Enables BFD authentication";
description description
"Parameters for BFD authentication."; "Parameters for BFD authentication.";
leaf key-chain { leaf key-chain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"Name of the key-chain."; "Name of the key chain.";
} }
leaf meticulous { leaf meticulous {
type boolean; type boolean;
description description
"Enables meticulous mode."; "Enables meticulous mode.";
reference reference
"RFC 5880: Bidirectional Forwarding "RFC 5880: Bidirectional Forwarding
Detection (BFD), Section 6.7"; Detection (BFD),
Section 6.7";
} }
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
} }
container security { container security {
description description
"Site-specific security parameters."; "Site-specific security parameters.";
container encryption { container encryption {
if-feature "vpn-common:encryption"; if-feature "vpn-common:encryption";
description description
"Container for CE-PE security encryption."; "Container for CE-PE security encryption.";
leaf enabled { leaf enabled {
type boolean; type boolean;
default "false"; default "false";
description description
"If true, traffic encryption on the "If set to 'true', traffic encryption on
connection is required. Otherwise, it the connection is required. Otherwise,
is disabled."; it is disabled.";
} }
leaf layer { leaf layer {
when "../enabled = 'true'" { when "../enabled = 'true'" {
description description
"It is included only when encryption "Included only when encryption
is enabled."; is enabled.";
} }
type enumeration { type enumeration {
enum layer2 { enum layer2 {
description description
"Encryption occurs at Layer 2."; "Encryption occurs at Layer 2.";
} }
enum layer3 { enum layer3 {
description description
"Encryption occurs at Layer 3. "Encryption occurs at Layer 3.
skipping to change at line 5427 skipping to change at line 5275
is applied."; is applied.";
} }
} }
container encryption-profile { container encryption-profile {
when "../encryption/enabled = 'true'" { when "../encryption/enabled = 'true'" {
description description
"Indicates the layer on which encryption "Indicates the layer on which encryption
is enabled."; is enabled.";
} }
description description
"Container for encryption profile."; "Container for the encryption profile.";
choice profile { choice profile {
description description
"Choice for the encryption profile."; "Choice for the encryption profile.";
case provider-profile { case provider-profile {
leaf profile-name { leaf profile-name {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-profiles" path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers" + "/valid-provider-identifiers"
+ "/encryption-profile-identifier/id"; + "/encryption-profile-identifier/id";
} }
description description
"Name of the service provider's profile "Name of the service provider's
to be applied."; profile to be applied.";
} }
} }
case customer-profile { case customer-profile {
leaf customer-key-chain { leaf customer-key-chain {
type key-chain:key-chain-ref; type key-chain:key-chain-ref;
description description
"Customer-supplied key chain."; "Customer-supplied key chain.";
} }
} }
} }
} }
} }
container service { container service {
description description
"Service parameters of the attachment."; "Service parameters of the attachment.";
leaf inbound-bandwidth { leaf pe-to-ce-bandwidth {
if-feature "vpn-common:inbound-bw"; if-feature "vpn-common:inbound-bw";
type uint64; type uint64;
units "bps"; units "bps";
description description
"From the customer site's perspective, the "From the customer site's perspective, the
service inbound bandwidth of the connection service inbound bandwidth of the connection
or download bandwidth from the SP to or download bandwidth from the SP to the
the site. Note that the L3SM uses 'input- site. Note that the L3SM uses
-bandwidth' to refer to the same concept."; 'input-bandwidth' to refer to the same
concept.";
} }
leaf outbound-bandwidth { leaf ce-to-pe-bandwidth {
if-feature "vpn-common:outbound-bw"; if-feature "vpn-common:outbound-bw";
type uint64; type uint64;
units "bps"; units "bps";
description description
"From the customer site's perspective, "From the customer site's perspective,
the service outbound bandwidth of the the service outbound bandwidth of the
connection or upload bandwidth from connection or upload bandwidth from
the site to the SP. Note that the L3SM uses the site to the SP. Note that the L3SM
'output-bandwidth' to refer to the same uses 'output-bandwidth' to refer to the
concept."; same concept.";
} }
leaf mtu { leaf mtu {
type uint32; type uint32;
units "bytes"; units "bytes";
description description
"MTU at service level. If the service is IP, "MTU at the service level. If the service
it refers to the IP MTU. If Carriers' is IP, it refers to the IP MTU. If
Carriers (CsC) is enabled, the requested MTU Carriers' Carriers (CsC) is enabled, the
will refer to the MPLS maximum labeled packet requested MTU will refer to the MPLS
size and not to the IP MTU."; maximum labeled packet size and not to the
IP MTU.";
} }
container qos { container qos {
if-feature "vpn-common:qos"; if-feature "vpn-common:qos";
description description
"QoS configuration."; "QoS configuration.";
container qos-classification-policy { container qos-classification-policy {
description description
"Configuration of the traffic classification "Configuration of the traffic
policy."; classification policy.";
uses vpn-common:qos-classification-policy; uses vpn-common:qos-classification-policy;
} }
container qos-action { container qos-action {
description description
"List of QoS action policies."; "List of QoS action policies.";
list rule { list rule {
key "id"; key "id";
description description
"List of QoS actions."; "List of QoS actions.";
leaf id { leaf id {
type string; type string;
description description
"An identifier of the QoS action rule."; "An identifier of the QoS action
rule.";
} }
leaf target-class-id { leaf target-class-id {
type string; type string;
description description
"Identification of the class of service. "Identification of the class of
This identifier is internal to the service. This identifier is internal
administration."; to the administration.";
} }
leaf inbound-rate-limit { leaf inbound-rate-limit {
type decimal64 { type decimal64 {
fraction-digits 5; fraction-digits 5;
range "0..100"; range "0..100";
} }
units "percent"; units "percent";
description description
"Specifies whether/how to rate-limit the "Specifies whether/how to rate-limit
inbound traffic matching this QoS policy. the inbound traffic matching this QoS
It is expressed as a percent of the value policy. It is expressed as a percent
that is indicated in 'input-bandwidth'."; of the value that is indicated in
'input-bandwidth'.";
} }
leaf outbound-rate-limit { leaf outbound-rate-limit {
type decimal64 { type decimal64 {
fraction-digits 5; fraction-digits 5;
range "0..100"; range "0..100";
} }
units "percent"; units "percent";
description description
"Specifies whether/how to rate-limit the "Specifies whether/how to rate-limit
outbound traffic matching this QoS policy. the outbound traffic matching this
It is expressed as a percent of the value QoS policy. It is expressed as a
that is indicated in 'output-bandwidth'."; percent of the value that is
indicated in 'output-bandwidth'.";
} }
} }
} }
container qos-profile { container qos-profile {
description description
"QoS profile configuration."; "QoS profile configuration.";
list qos-profile { list qos-profile {
key "profile"; key "profile";
description description
"QoS profile. "QoS profile.
Can be standard profile or customized Can be a standard profile or
profile."; a customized profile.";
leaf profile { leaf profile {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-profiles" path "/l3vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers" + "/valid-provider-identifiers"
+ "/qos-profile-identifier/id"; + "/qos-profile-identifier/id";
} }
description description
"QoS profile to be used."; "QoS profile to be used.";
} }
leaf direction { leaf direction {
type identityref { type identityref {
base vpn-common:qos-profile-direction; base vpn-common:qos-profile-direction;
} }
default "vpn-common:both"; default "vpn-common:both";
description description
"The direction to which the QoS profile "The direction to which the QoS
is applied."; profile is applied.";
} }
} }
} }
} }
container carriers-carrier { container carriers-carrier {
if-feature "vpn-common:carriers-carrier"; if-feature "vpn-common:carriers-carrier";
description description
"This container is used when the customer "This container is used when the customer
provides MPLS-based services. This is provides MPLS-based services. This is
only used in the case of CsC (i.e., a only used in the case of CsC (i.e., a
customer builds an MPLS service using an customer builds an MPLS service using an
IP VPN to carry its traffic)."; IP VPN to carry its traffic).";
leaf signaling-type { leaf signaling-type {
type enumeration { type enumeration {
enum ldp { enum ldp {
description description
"Use LDP as the signaling protocol "Uses LDP as the signaling protocol
between the PE and the CE. In this between the PE and the CE. In this
case, an IGP routing protocol must case, an IGP routing protocol must
also be configured."; also be configured.";
} }
enum bgp { enum bgp {
description description
"Use BGP as the signaling protocol "Uses BGP as the signaling protocol
between the PE and the CE. between the PE and the CE.
In this case, BGP must also be configured In this case, BGP must also be
as the routing protocol."; configured as the routing protocol.";
reference reference
"RFC 8277: Using BGP to Bind MPLS Labels "RFC 8277: Using BGP to Bind MPLS
to Address Prefixes"; Labels to Address
Prefixes";
} }
} }
default "bgp"; default "bgp";
description description
"MPLS signaling type."; "MPLS signaling type.";
} }
} }
container ntp { container ntp {
description description
"Time synchronization may be needed in some "Time synchronization may be needed in some
VPNs such as infrastructure and Management VPNs, such as infrastructure and management
VPNs. This container includes parameters to VPNs. This container includes parameters
enable NTP service."; to enable the NTP service.";
reference reference
"RFC 5905: Network Time Protocol Version 4: "RFC 5905: Network Time Protocol Version 4:
Protocol and Algorithms Protocol and Algorithms
Specification"; Specification";
leaf broadcast { leaf broadcast {
type enumeration { type enumeration {
enum client { enum client {
description description
"The VPN node will listen to NTP broadcast "The VPN node will listen to NTP
messages on this VPN network access."; broadcast messages on this VPN
network access.";
} }
enum server { enum server {
description description
"The VPN node will behave as a broadcast "The VPN node will behave as a
server."; broadcast server.";
} }
} }
description description
"Indicates NTP broadcast mode to use for the "Indicates the NTP broadcast mode to use
VPN network access."; for the VPN network access.";
} }
container auth-profile { container auth-profile {
description description
"Pointer to a local profile."; "Pointer to a local profile.";
leaf profile-id { leaf profile-id {
type string; type string;
description description
"A pointer to a local authentication "A pointer to a local authentication
profile on the VPN node is provided."; profile on the VPN node is provided.";
} }
skipping to change at line 5685 skipping to change at line 5540
description description
"Indicates the address family."; "Indicates the address family.";
} }
leaf protocol-type { leaf protocol-type {
type enumeration { type enumeration {
enum host { enum host {
description description
"Hosts are directly connected to the "Hosts are directly connected to the
provider network. provider network.
Host protocols such as IGMP or MLD are Host protocols, such as IGMP or MLD,
required."; are required.";
} }
enum router { enum router {
description description
"Hosts are behind a customer router. "Hosts are behind a customer router.
PIM will be implemented."; PIM will be implemented.";
} }
enum both { enum both {
description description
"Some hosts are behind a customer router, "Some hosts are behind a customer
and some others are directly connected router, and some others are directly
to the provider network. Both host and connected to the provider network.
routing protocols must be used. Both host and routing protocols must
be used.
Typically, IGMP and PIM will be Typically, IGMP and PIM will be
implemented."; implemented.";
} }
} }
default "both"; default "both";
description description
"Multicast protocol type to be used with "Multicast protocol type to be used with
the customer site."; the customer site.";
} }
leaf remote-source { leaf remote-source {
type boolean; type boolean;
default "false"; default "false";
description description
"A remote multicast source is a source that is "A remote multicast source is a source
not on the same subnet as the that is not on the same subnet as the
vpn-network-access. When set to 'true', the VPN network access. When set to 'true',
multicast traffic from a remote source is the multicast traffic from a remote
accepted."; source is accepted.";
} }
container igmp { container igmp {
when "../protocol-type = 'host' and " when "../protocol-type = 'host' and "
+ "../address-family = 'vpn-common:ipv4' or " + "../address-family = 'vpn-common:ipv4' "
+ "'vpn-common:dual-stack'"; + "or 'vpn-common:dual-stack'";
if-feature "vpn-common:igmp"; if-feature "vpn-common:igmp";
description description
"Includes IGMP-related parameters."; "Includes IGMP-related parameters.";
list static-group { list static-group {
key "group-addr"; key "group-addr";
description description
"Multicast static source/group associated to "Multicast static source/group
IGMP session"; associated with the IGMP session.";
leaf group-addr { leaf group-addr {
type rt-types:ipv4-multicast-group-address; type rt-types:ipv4-multicast-group-address;
description description
"Multicast group IPv4 address."; "Multicast group IPv4 address.";
} }
leaf source-addr { leaf source-addr {
type rt-types:ipv4-multicast-source-address; type rt-types:ipv4-multicast-source\
-address;
description description
"Multicast source IPv4 address."; "Multicast source IPv4 address.";
} }
} }
leaf max-groups { leaf max-groups {
type uint32; type uint32;
description description
"Indicates the maximum number of groups."; "Indicates the maximum number of
groups.";
} }
leaf max-entries { leaf max-entries {
type uint32; type uint32;
description description
"Indicates the maximum number of IGMP "Indicates the maximum number of IGMP
entries."; entries.";
} }
leaf max-group-sources { leaf max-group-sources {
type uint32; type uint32;
description description
"The maximum number of group sources."; "The maximum number of group sources.";
} }
leaf version { leaf version {
type identityref { type identityref {
base vpn-common:igmp-version; base vpn-common:igmp-version;
} }
default "vpn-common:igmpv2"; default "vpn-common:igmpv2";
description description
"Version of the IGMP."; "Indicates the IGMP version.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
container mld { container mld {
when "../protocol-type = 'host' and " when "../protocol-type = 'host' and "
+ "../address-family = 'vpn-common:ipv6' or " + "../address-family = 'vpn-common:ipv6' "
+ "'vpn-common:dual-stack'"; + "or 'vpn-common:dual-stack'";
if-feature "vpn-common:mld"; if-feature "vpn-common:mld";
description description
"Includes MLD-related parameters."; "Includes MLD-related parameters.";
list static-group { list static-group {
key "group-addr"; key "group-addr";
description description
"Multicast static source/group associated to "Multicast static source/group associated
the MLD session"; with the MLD session.";
leaf group-addr { leaf group-addr {
type rt-types:ipv6-multicast-group-address; type rt-types:ipv6-multicast-group-address;
description description
"Multicast group IPv6 address."; "Multicast group IPv6 address.";
} }
leaf source-addr { leaf source-addr {
type rt-types:ipv6-multicast-source-address; type rt-types:ipv6-multicast-source\
-address;
description description
"Multicast source IPv6 address."; "Multicast source IPv6 address.";
} }
} }
leaf max-groups { leaf max-groups {
type uint32; type uint32;
description description
"Indicates the maximum number of groups."; "Indicates the maximum number of
groups.";
} }
leaf max-entries { leaf max-entries {
type uint32; type uint32;
description description
"Indicates the maximum number of MLD "Indicates the maximum number of MLD
entries."; entries.";
} }
leaf max-group-sources { leaf max-group-sources {
type uint32; type uint32;
description description
"The maximum number of group sources."; "The maximum number of group sources.";
} }
leaf version { leaf version {
type identityref { type identityref {
base vpn-common:mld-version; base vpn-common:mld-version;
} }
default "vpn-common:mldv2"; default "vpn-common:mldv2";
description description
"Version of the MLD protocol."; "Indicates the MLD protocol version.";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
container pim { container pim {
when "../protocol-type = 'router'"; when "../protocol-type = 'router'";
if-feature "vpn-common:pim"; if-feature "vpn-common:pim";
description description
"Only applies when protocol type is PIM."; "Only applies when the protocol type is
'pim'.";
leaf hello-interval { leaf hello-interval {
type rt-types:timer-value-seconds16; type rt-types:timer-value-seconds16;
default "30"; default "30";
description description
"PIM hello-messages interval. If set to "Interval between PIM Hello messages.
'infinity' or 'not-set', no periodic If set to 'infinity' or 'not-set',
Hello messages are sent."; no periodic Hello messages are sent.";
reference reference
"RFC 7761: Protocol Independent Multicast - "RFC 7761: Protocol Independent
Sparse Mode (PIM-SM): Protocol Multicast - Sparse Mode
(PIM-SM): Protocol
Specification (Revised), Specification (Revised),
Section 4.11"; Section 4.11
RFC 8294: Common YANG Data Types for
the Routing Area";
} }
leaf dr-priority { leaf dr-priority {
type uint32; type uint32;
default "1"; default "1";
description description
"Indicates the preference in the DR election "Indicates the preference associated
process. A larger value has a higher with the DR election process. A larger
priority over a smaller value."; value has a higher priority over a
smaller value.";
reference reference
"RFC 7761: Protocol Independent Multicast - "RFC 7761: Protocol Independent
Sparse Mode (PIM-SM): Protocol Multicast - Sparse Mode
(PIM-SM): Protocol
Specification (Revised), Specification (Revised),
Section 4.3.2"; Section 4.3.2";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
} }
} }
} }
} }
} }
} }
} }
} }
} }
} }
} }
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The YANG module specified in this document defines schema for data <t>The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such as that is designed to be accessed via network management protocols such
NETCONF <xref target="RFC6241"></xref> or RESTCONF <xref as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.
target="RFC8040"></xref>. The lowest NETCONF layer is the secure The lowest NETCONF layer is the secure transport layer, and the
transport layer, and the mandatory-to-implement secure transport is mandatory-to-implement secure transport is Secure Shell (SSH)
Secure Shell (SSH) <xref target="RFC6242"></xref>. The lowest RESTCONF <xref target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the
layer is HTTPS, and the mandatory-to-implement secure transport is TLS mandatory-to-implement secure transport is TLS <xref target="RFC8446"/>.</t>
<xref target="RFC8446"></xref>.</t> <t>The Network Configuration Access Control Model (NACM) <xref target="RFC8341"/
>
<t>The Network Configuration Access Control Model (NACM) <xref provides the means to restrict access for particular NETCONF or RESTCONF users
target="RFC8341"></xref> provides the means to restrict access for to a preconfigured subset of all available NETCONF or RESTCONF protocol
particular NETCONF or RESTCONF users to a preconfigured subset of all operations and content.</t>
available NETCONF or RESTCONF protocol operations and content.</t> <t>There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the default). These
<t>There are a number of data nodes defined in this YANG module that are data nodes may be considered sensitive or vulnerable in some network
writable/creatable/deletable (i.e., config true, which is the default). environments. Write operations (e.g., edit-config) and delete operations to thes
These data nodes may be considered sensitive or vulnerable in some e data nodes without
network environments. Write operations (e.g., edit-config) and delete proper protection or authentication can have a negative effect on network operat
operations to these data nodes without proper protection or ions. These are
authentication can have a negative effect on network operations. These the subtrees and data nodes and their sensitivity/vulnerability in
are the subtrees and data nodes and their sensitivity/vulnerability in the "ietf-l3vpn-ntw" module:</t>
the "ietf-l3vpn-ntw" module: <list style="symbols"> <dl newline="false" spacing="normal">
<t>'vpn-profiles': This container includes a set of sensitive data <dt>'vpn-profiles':</dt><dd>This container includes a set of sensitive d
ata
that influence how the L3VPN service is delivered. For example, an that influence how the L3VPN service is delivered. For example, an
attacker who has access to these data nodes may be able to attacker who has access to these data nodes may be able to
manipulate routing policies, QoS policies, or encryption properties. manipulate routing policies, QoS policies, or encryption properties.
These data nodes are defined with "nacm:default-deny-write" tagging These data nodes are defined with "nacm:default-deny-write" tagging
<xref target="I-D.ietf-opsawg-vpn-common"></xref>.</t> <xref target="RFC9181" format="default"/>.</dd>
<dt>'vpn-services':</dt><dd>An attacker who is able to access network no
<t>'vpn-services': An attacker who is able to access network nodes des
can undertake various attacks, such as deleting a running L3VPN can undertake various attacks, such as deleting a running L3VPN
service, interrupting all the traffic of a client. In addition, an service, interrupting all the traffic of a client. In addition, an
attacker may modify the attributes of a running service (e.g., QoS, attacker may modify the attributes of a running service (e.g., QoS,
bandwidth, routing protocols, keying material), leading to bandwidth, routing protocols, keying material), leading to
malfunctioning of the service and therefore to SLA violations. In malfunctioning of the service and therefore to Service Level Agreement (SLA) violations. In
addition, an attacker could attempt to create an L3VPN service or addition, an attacker could attempt to create an L3VPN service or
add a new network access. In addition to using NACM to prevent add a new network access. In addition to using NACM to prevent
authorized access, such activity can be detected by adequately unauthorized access, such activity can be detected by adequately
monitoring and tracking network configuration changes.</t> monitoring and tracking network configuration changes.</dd>
</list></t> </dl>
<t>Some of the readable data nodes in this YANG module may be considered
<t>Some readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to
sensitive or vulnerable in some network environments. It is thus control read access (e.g., via get, get-config, or notification) to these data
important to control read access (e.g., via get, get-config, or nodes. These are the subtrees and data nodes and their
notification) to these data nodes. These are the subtrees and data nodes sensitivity/vulnerability:</t>
and their sensitivity/vulnerability:</t> <dl newline="false" spacing="normal">
<dt>'customer-name' and 'ip-connection':</dt><dd>An attacker can retriev
<t><list style="symbols"> e
<t>'customer-name' and 'ip-connection': An attacker can retrieve privacy-related information, which can be used to track a customer.
privacy-related information which can be used to track a customer. Disclosing such information may be considered a violation of the
Disclosing such information may be considered as a violation of the customer-provider trust relationship.</dd>
customer-provider trust relationship.</t> <dt>'keying-material':</dt><dd>An attacker can retrieve the cryptographi
c
<t>'keying-material': An attacker can retrieve the cryptographic
keys protecting the underlying VPN service (CE-PE routing, in keys protecting the underlying VPN service (CE-PE routing, in
particular). These keys could be used to inject spoofed routing particular). These keys could be used to inject spoofed routing
advertisements.</t> advertisements.</dd>
</list></t> </dl>
<t>Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely <t>Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely
upon <xref target="RFC8177"></xref> for authentication purposes. upon <xref target="RFC8177" format="default"/> for authentication purposes .
Therefore, this module inherits the security considerations discussed in Therefore, this module inherits the security considerations discussed in
Section 5 of <xref target="RFC8177"></xref>. Also, these data nodes <xref target="RFC8177" sectionFormat="of" section="5"/>. Also, these data nodes
support supplying explicit keys as strings in ASCII format. The use of support supplying explicit keys as strings in ASCII format. The use of
keys in hexadecimal string format would afford greater key entropy with keys in hexadecimal string format would afford greater key entropy with
the same number of key-string octets. However, such format is not the same number of key-string octets. However, such a format is not
included in this version of the L3NM because it is not supported by the included in this version of the L3NM, because it is not supported by the
underlying device modules (e.g., <xref target="RFC8695"></xref>).</t> underlying device modules (e.g., <xref target="RFC8695" format="default"/>
).</t>
<t>As discussed in <xref target="rtg"></xref>, the module supports MD5 <t>As discussed in <xref target="rtg" format="default"/>, the module suppo
rts MD5
to basically accommodate the installed BGP base. MD5 suffers from the to basically accommodate the installed BGP base. MD5 suffers from the
security weaknesses discussed in Section 2 of <xref security weaknesses discussed in <xref target="RFC6151" sectionFormat="of"
target="RFC6151"></xref> or Section 2.1 of <xref section="2"/> and <xref target="RFC6952" sectionFormat="of" section="2.1"/>.</t
target="RFC6952"></xref>.</t> >
<t><xref target="RFC8633" format="default"/> describes best current practi
<t><xref target="RFC8633"></xref> describes best current practices to be ces to be
considered in VPNs making use of NTP. Moreover, a mechanism to provide considered in VPNs making use of NTP. Moreover, a mechanism to provide
cryptographic security for NTP is specified in <xref cryptographic security for NTP is specified in <xref target="RFC8915" form
target="RFC8915"></xref>.</t> at="default"/>.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document requests IANA to register the following URI in the "ns" <t>IANA has registered the following URI in the "ns"
subregistry within the "IETF XML Registry" <xref subregistry within the "IETF XML Registry" <xref target="RFC3688" format="
target="RFC3688"></xref>:</t> default"/>:</t>
<dl newline="false" spacing="compact">
<t><figure> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw</dd>
<artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-nt <dt>Registrant Contact:</dt><dd>The IESG.</dd>
w <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
Registrant Contact: The IESG. </dl>
XML: N/A; the requested URI is an XML namespace. <t>IANA has registered the following YANG module in
]]></artwork> the "YANG Module Names" subregistry <xref target="RFC6020" format="default
</figure></t> "/>
<t>This document requests IANA to register the following YANG module in
the "YANG Module Names" subregistry <xref target="RFC6020"></xref>
within the "YANG Parameters" registry.</t> within the "YANG Parameters" registry.</t>
<dl newline="false" spacing="compact">
<t><figure> <dt>Name:</dt><dd>ietf-l3vpn-ntw</dd>
<artwork><![CDATA[ name: ietf-l3vpn-ntw <dt>Maintained by IANA?</dt><dd>N</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw</dd>
maintained by IANA: N <dt>Prefix:</dt><dd>l3nm</dd>
prefix: l3nm <dt>Reference:</dt><dd>RFC 9182</dd>
reference: RFC XXXX </dl>
]]></artwork>
</figure></t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie
s:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here
(as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm
l"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.
xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included fi
les in the same
directory as the including file. You can also define the XML_LIBRARY enviro
nment variable
with a value containing a set of directories to search. These can be eithe
r in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4364'?>
<?rfc include='reference.RFC.6513'?>
<?rfc include='reference.RFC.6514'?>
<?rfc include='reference.RFC.8294'?>
<?rfc include='reference.RFC.8519'?>
<?rfc include='reference.RFC.6991'?>
<?rfc include='reference.RFC.6242'?>
<?rfc include='reference.RFC.8466'?>
<?rfc include='reference.RFC.6241'?>
<?rfc include='reference.RFC.8040'?>
<?rfc include='reference.RFC.8341'?>
<?rfc include='reference.RFC.8174'?>
<?rfc include='reference.RFC.7950'?>
<?rfc include='reference.RFC.6020'?>
<?rfc include='reference.RFC.3688'?>
<?rfc include='reference.I-D.ietf-opsawg-vpn-common'?>
<?rfc include='reference.RFC.5701'?>
<?rfc include='reference.RFC.5925'?>
<?rfc include='reference.RFC.4577'?>
<?rfc include='reference.RFC.4552'?>
<?rfc include='reference.RFC.5709'?>
<?rfc include='reference.RFC.7474'?>
<?rfc include='reference.RFC.7166'?>
<?rfc include='reference.RFC.6565'?>
<?rfc include='reference.RFC.8177'?>
<?rfc include='reference.RFC.5798'?>
<?rfc include='reference.RFC.4271'?>
<?rfc include='reference.RFC.5880'?>
<?rfc include='reference.RFC.2453'?>
<?rfc include='reference.RFC.2080'?>
<?rfc include='reference.RFC.8343'?> <displayreference target="I-D.ietf-idr-bgp-model" to="BGP-YANG"/>
<displayreference target="I-D.ietf-rtgwg-qos-model" to="QoS-YANG"/>
<?rfc include='reference.RFC.1112'?> <displayreference target="I-D.ietf-teas-enhanced-vpn" to="Enhanced-VPN-Framework
"/>
<?rfc include='reference.RFC.2236'?>
<?rfc include='reference.RFC.3376'?>
<?rfc include='reference.RFC.2710'?>
<?rfc include='reference.RFC.3810'?>
<?rfc include='reference.RFC.7761'?>
<?rfc include='reference.RFC.8446'?>
<?rfc include='reference.RFC.5905'?>
<?rfc include='reference.RFC.5308'?>
<?rfc include='reference.RFC.1195'?>
<reference anchor="ISO10589"
target="International Standard 10589:2002, Second Edition">
<front>
<title>Intermediate System to Intermediate System intra- domain
routeing information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode network service
(ISO 8473)</title>
<author fullname="ISO">
<organization></organization>
</author>
<date year="2002" />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3644'?>
<?rfc include='reference.RFC.4110'?>
<?rfc include='reference.RFC.4026'?>
<?rfc include='reference.RFC.8299'?>
<?rfc include='reference.RFC.8309'?>
<?rfc include='reference.RFC.8340'?>
<?rfc include='reference.RFC.8453'?>
<?rfc include='reference.RFC.7149'?>
<?rfc include='reference.RFC.7426'?>
<?rfc include='reference.RFC.6037'?>
<?rfc include='reference.RFC.8342'?>
<?rfc include='reference.RFC.8969'?>
<?rfc include='reference.RFC.3618'?>
<?rfc include='reference.RFC.4862'?>
<?rfc include='reference.RFC.7942'?>
<?rfc include='reference.RFC.8512'?>
<?rfc include='reference.RFC.8349'?>
<?rfc include='reference.RFC.4176'?>
<?rfc include='reference.RFC.8345'?>
<?rfc include='reference.RFC.8277'?>
<?rfc include='reference.I-D.evenwu-opsawg-yang-composed-vpn'?>
<?rfc include='reference.I-D.ogondio-opsawg-uni-topology'?>
<?rfc include='reference.I-D.ietf-idr-bgp-model'?>
<?rfc include='reference.I-D.ietf-pim-yang'?>
<?rfc include='reference.I-D.ietf-rtgwg-qos-model'?>
<?rfc include='reference.I-D.ietf-teas-enhanced-vpn'?>
<?rfc include='reference.RFC.7297'?>
<?rfc include='reference.I-D.ietf-bess-evpn-prefix-advertisement'?>
<?rfc include='reference.I-D.ietf-teas-ietf-network-slices'?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4364.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6513.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6514.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8294.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8519.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6991.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6242.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8466.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6241.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8341.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7950.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3688.xml"/>
<?rfc include='reference.RFC.8077'?> <!-- draft-ietf-opsawg-vpn-common (RFC 9181) -->
<reference anchor='RFC9181' target="https://www.rfc-editor.org/info/rfc9181">
<front>
<title>A Common YANG Data Model for Layer 2 and Layer 3 VPNs</title>
<author initials='S' surname='Barguil' fullname='Samier Barguil'>
<organization />
</author>
<author initials='O' surname='Gonzalez de Dios' fullname='Oscar Gonzalez de Dios
' role="editor">
<organization />
</author>
<author initials='M' surname='Boucadair' fullname='Mohamed Boucadair' role="edit
or">
<organization />
</author>
<author initials='Q' surname='Wu' fullname='Qin Wu'>
<organization />
</author>
<date year='2022' month='February'/>
</front>
<seriesInfo name="RFC" value="9181"/>
<seriesInfo name="DOI" value="10.17487/RFC9181"/>
</reference>
<?rfc include='reference.RFC.7880'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5701.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5925.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4577.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4552.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5709.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7474.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7166.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6565.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8177.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5798.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4271.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5880.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2453.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2080.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8343.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1112.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2236.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3376.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2710.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3810.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7761.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5905.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5308.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1195.xml"/>
<?rfc include='reference.RFC.6151'?> <reference anchor="ISO10589" target="https://www.iso.org/standard/30932.
html">
<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 (ISO 8473)</title>
<author><organization>ISO</organization></author>
<date year="2002"/>
</front>
<refcontent>ISO/IEC 10589:2002</refcontent>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3644.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4110.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4026.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8299.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8309.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8453.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7149.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7426.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6037.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8342.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8969.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3618.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4862.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8512.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8349.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4176.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8345.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8277.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8792.
xml"/>
<?rfc include='reference.RFC.6952'?> <!-- draft-evenwu-opsawg-yang-composed-vpn (Expired)
One name messed up; have to do long way. -->
<reference anchor='YANG-Composed-VPN'>
<front>
<title>YANG Data Model for Composed VPN Service Delivery</title>
<author initials='R' surname='Even' fullname='Roni Even'>
<organization/></author>
<author initials='B' surname='Wu' fullname='Bo Wu'>
<organization/></author>
<author initials='Q' surname='Wu' fullname='Qin Wu'>
<organization/></author>
<author initials='Y' surname='Cheng' fullname='Ying Cheng'>
<organization/></author>
<date month='March' day='8' year='2019' />
</front>
<seriesInfo name='Internet-Draft' value='draft-evenwu-opsawg-yang-composed-vpn-0
3' />
</reference>
<?rfc include='reference.RFC.8915'?> <!-- draft-ietf-opsawg-sap (I-D Exists) -->
<reference anchor='YANG-SAPs'>
<front>
<title>A Network YANG Model for Service Attachment Points</title>
<author initials='O' surname='Gonzalez de Dios' fullname='Oscar Gonzalez de Dios
'>
<organization/></author>
<author initials='S' surname='Barguil' fullname='Samier Barguil'>
<organization/></author>
<author initials='Q' surname='Wu' fullname='Qin Wu'>
<organization/></author>
<author initials='M' surname='Boucadair' fullname='Mohamed Boucadair'>
<organization/></author>
<author initials='V' surname='Lopez' fullname='Victor Lopez'>
<organization/></author>
<date month='January' day='25' year='2022' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-opsawg-sap-00' />
</reference>
<?rfc include='reference.RFC.8633'?> <!-- draft-ietf-idr-bgp-model (I-D Exists) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-idr-bgp-model.xml"/>
<?rfc include='reference.RFC.8695'?> <!-- draft-ietf-pim-yang (AUTH48 since 2021-09-04) -->
<reference anchor="PIM-YANG">
<front>
<title>A YANG Data Model for Protocol Independent Multicast (PIM)</title>
<author fullname="Xufeng Liu">
<organization/>
</author>
<author fullname="Pete McAllister">
<organization/>
</author>
<author fullname="Anish Peter">
<organization/>
</author>
<author fullname="Mahesh Sivakumar">
<organization/>
</author>
<author fullname="Yisong Liu">
<organization/>
</author>
<author fullname="Fangwei Hu">
<organization/>
</author>
<date month="May" day="19" year="2018" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pim-yang-17" />
</reference>
<reference anchor="PYANG" target="https://github.com/mbj4668/pyang"> <!-- draft-ietf-rtgwg-qos-model (I-D Exists) -->
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<title>pyang</title> .ietf-rtgwg-qos-model.xml"/>
<author> <!-- draft-ietf-teas-enhanced-vpn (I-D Exists) -->
<organization></organization> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
</author> .ietf-teas-enhanced-vpn.xml"/>
<date month="November" year="2020" /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.7297.xml"/>
</reference>
<reference anchor="IEEE802.1AX"> <!-- draft-ietf-bess-evpn-prefix-advertisement (Published; RFC 9136) -->
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>Link Aggregation</title> FC.9136.xml"/>
<author> <!-- draft-ietf-teas-ietf-network-slices (I-D Exists)
<organization></organization> One author is editor; have to do long way. -->
</author> <reference anchor="Network-Slices-Framework">
<front>
<title>Framework for IETF Network Slices</title>
<author initials="A" surname="Farrel" fullname="Adrian Farrel" role="editor">
<organization/></author>
<author initials="E" surname="Gray" fullname="Eric Gray">
<organization/></author>
<author initials="J" surname="Drake" fullname="John Drake">
<organization/></author>
<author initials="R" surname="Rokui" fullname="Reza Rokui">
<organization/></author>
<author initials="S" surname="Homma" fullname="Shunsuke Homma">
<organization/></author>
<author initials="K" surname="Makhijani" fullname="Kiran Makhijani">
<organization/></author>
<author initials="LM" surname="Contreras" fullname="Luis M. Contreras">
<organization/></author>
<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
<organization/></author>
<date month='October' day='25' year='2021'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-teas-ietf-network-slices-05'
/>
</reference>
<date month="" year="2020" /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.8077.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7880.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6151.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6952.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8915.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8633.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8695.xml"/>
<reference anchor="PYANG" target="https://github.com/mbj4668/pyang">
<front>
<title>pyang</title>
<author>
<organization/>
</author>
<date month="December" year="2021"/>
</front>
<refcontent>commit 524cf61</refcontent>
</reference>
<seriesInfo name="IEEE" value="Std 802.1AX-2020" /> <reference anchor="IEEE802.1AX" target="https://ieeexplore.ieee.org/docu
</reference> ment/9105034">
<front>
<title>802.1AX-2020 - IEEE Standard for Local and Metropolitan Area
Networks--Link Aggregation</title>
<author><organization>IEEE</organization></author>
<!-- <date month="" year="2020"/> -->
</front>
<refcontent>IEEE Std 802.1AX-2020</refcontent>
<!-- <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9105034"/> -->
</reference>
</references>
</references> </references>
<!----> <section anchor="examples" numbered="true" toc="default">
<name>L3VPN Examples</name>
<section anchor="examples" title="L3VPN Examples"> <section anchor="mbh-vpn" numbered="true" toc="default">
<t></t> <name>4G VPN Provisioning Example</name>
<section anchor="mbh-vpn" title="4G VPN Provisioning Example">
<t>L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise <t>L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise
services mainly because several traffic discrimination policies can be services, mainly because several traffic discrimination policies can be
applied within the network to deliver to the mobile customers a applied within the network to deliver to the mobile customers a
service that meets the SLA requirements.</t> service that meets the SLA requirements.</t>
<t>Typically, and as shown in <xref target="vpn-service-mbh" format="def
<t>As it is shown in the <xref target="vpn-service-mbh"></xref>, ault"/>,
typically, an eNodeB (CE) is directly connected to the access routers an eNodeB (CE) is directly connected to the access routers
of the mobile backhaul and their logical interfaces (one or many of the mobile backhaul and their logical interfaces (one or many,
according to the service type) are configured in a VPN that transports according to the service type) are configured in a VPN that transports
the packets to the mobile core platforms. In this example, a the packets to the mobile core platforms. In this example, a
'vpn-node' is created with two 'vpn-network-accesses'.</t> 'vpn-node' is created with two 'vpn-network-accesses'.</t>
<figure anchor="vpn-service-mbh">
<figure align="center" anchor="vpn-service-mbh" <name>Mobile Backhaul Example</name>
title="Mobile Backhaul Example"> <artwork align="center" name="" type="ascii-art" alt=""><![CDATA[
<artwork align="left"><![CDATA[ +-------------+ +------------------+
+-------------+ +------------------+ | | | PE |
| | | PE | | | | 198.51.100.1 |
| | | 198.51.100.1 | | eNodeB |>--------/------->|........... |
| eNodeB |>--------/------->|........... | | | vlan 1 | | |
| | vlan 1 | | | | |>--------/------->|...... | |
| |>--------/------->|...... | | | | vlan 2 | | | |
| | vlan 2 | | | | | | Direct | +-------------+ |
| | Direct | +-------------+ | +-------------+ Routing | | vpn-node-id | |
+-------------+ Routing | | vpn-node-id | | | | 44 | |
| | 44 | | | +-------------+ |
| +-------------+ | | |
| | +------------------+
+------------------+ ]]></artwork>
]]></artwork>
</figure> </figure>
<t>To create an L3VPN service using the L3NM, the following steps can <t>To create an L3VPN service using the L3NM, the following steps can
be followed.</t> be followed.</t>
<t>First, create the 4G VPN service (<xref target="service-mbh2" format= "default"/>).</t>
<t>First: Create the 4G VPN service (<xref <figure anchor="service-mbh2">
target="service-mbh2"></xref>).</t> <name>Create VPN Service</name>
<sourcecode name="" type=""><![CDATA[
<figure align="center" anchor="service-mbh2" POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services
title="Create VPN Service">
<artwork align="center"><![CDATA[POST: /restconf/data/ietf-l3vpn-ntw:l
3vpn-ntw/vpn-services
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-l3vpn-ntw:vpn-services": { "ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [ "vpn-service": [
{ {
"vpn-id": "4G", "vpn-id": "4G",
"customer-name": "mycustomer", "vpn-description": "VPN to deploy 4G services",
"vpn-service-topology": "custom", "customer-name": "mycustomer",
"vpn-description": "VPN to deploy 4G services", "vpn-service-topology": "custom",
"vpn-instance-profiles": { "vpn-instance-profiles": {
"vpn-instance-profile": [ "vpn-instance-profile": [
{ {
"profile-id": "simple-profile", "profile-id": "simple-profile",
"local-as": 65550, "local-as": 65550,
"rd": "0:65550:1", "rd": "0:65550:1",
"address-family": [ "address-family": [
{ {
"address-family": "ietf-vpn-common:dual-stack", "address-family": "ietf-vpn-common:dual-stack",
"vpn-target": [ "vpn-targets": {
{ "vpn-target": [
"id": 1, {
"route-targets": [ "id": 1,
{ "route-targets": [
"route-target": "0:65550:1" {
} "route-target": "0:65550:1"
], }
"route-target-type": "both" ],
} "route-target-type": "both"
] }
} ]
] }
} }
] ]
} }
} ]
] }
} }
]
}
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>Second, create a VPN node, as depicted in <xref target="service-mbh3"
<t>Second: Create a VPN node as depicted in <xref format="default"/>. In this type of service, the VPN node
target="service-mbh3"></xref>. In this type of service, the VPN node is equivalent to VRF configured in the physical device
is equivalent to the VRF configured in the physical device ('ne-id'=198.51.100.1). NOTE: '\' line wrapping in Figures&nbsp;<xref t
('ne-id'=198.51.100.1).</t> arget="service-mbh3" format="counter"/> and <xref target="service-mbh4" format="
counter"/> is implemented per <xref target="RFC8792"/>.</t>
<figure align="center" anchor="service-mbh3" title="Create VPN Node"> <figure anchor="service-mbh3">
<artwork align="center"><![CDATA[=============== NOTE: '\' line wrappi <name>Create VPN Node</name>
ng per RFC 8792 ================ <sourcecode name="" type=""><![CDATA[POST: /restconf/data/ietf-l3vpn-n
tw:l3vpn-ntw/\
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
vpn-services/vpn-service=4G vpn-services/vpn-service=4G
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-l3vpn-ntw:vpn-nodes": { "ietf-l3vpn-ntw:vpn-nodes": {
"vpn-node": [ "vpn-node": [
{ {
"vpn-node-id": "44", "vpn-node-id": "44",
"ne-id": "198.51.100.1", "ne-id": "198.51.100.1",
"active-vpn-instance-profiles": { "active-vpn-instance-profiles": {
"vpn-instance-profile": [ "vpn-instance-profile": [
{ {
"profile-id": "simple-profile" "profile-id": "simple-profile"
} }
] ]
} }
} }
] ]
} }
}]]></artwork> }
]]></sourcecode>
</figure> </figure>
<t>Finally, two VPN network accesses are created using the same <t>Finally, two VPN network accesses are created using the same
physical port ('interface-id'=1/1/1). Each 'vpn-network-access' has a physical port ('interface-id'=1/1/1). Each 'vpn-network-access' has a
particular VLAN (1,2) to differentiate the traffic between: Sync and particular VLAN interface (1,2): "SYNC" and "DATA" (<xref target="servic
data (<xref target="service-mbh4"></xref>).</t> e-mbh4" format="default"/>). These interfaces differentiate the traffic between
them.</t>
<figure align="center" anchor="service-mbh4" <figure anchor="service-mbh4">
title="Create VPN Network Access"> <name>Create VPN Network Access</name>
<artwork align="center"><![CDATA[=============== NOTE: '\' line wrappi <sourcecode name="" type=""><![CDATA[POST: /restconf/data/ietf-l3vpn-n
ng per RFC 8792 ================ tw:l3vpn-ntw/\
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44 vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44
content-type: application/yang-data+json content-type: application/yang-data+json
{ {
"ietf-l3vpn-ntw:vpn-network-accesses": { "ietf-l3vpn-ntw:vpn-network-accesses": {
"vpn-network-access": [ "vpn-network-access": [
{ {
"id": "1/1/1.1", "id": "1/1/1.1",
"interface-id": "1/1/1", "interface-id": "1/1/1",
"description": "Interface SYNC to eNODE-B", "description": "Interface SYNC to eNODE-B",
skipping to change at line 6443 skipping to change at line 6298
"routing-protocol": [ "routing-protocol": [
{ {
"id": "1", "id": "1",
"type": "ietf-vpn-common:direct" "type": "ietf-vpn-common:direct"
} }
] ]
} }
} }
] ]
} }
}]]></artwork> }
]]></sourcecode>
</figure> </figure>
<t></t>
</section> </section>
<section anchor="loop" numbered="true" toc="default">
<section anchor="loop" title="Loopback Interface"> <name>Loopback Interface</name>
<t>An example of loopback interface is depicted in <xref <t>An example of a loopback interface is depicted in <xref target="loopb
target="loopback"></xref>.</t> ack" format="default"/>.</t>
<figure anchor="loopback">
<figure align="center" anchor="loopback" <name>VPN Network Access with a Loopback Interface (Message Body)</nam
title="VPN Network Access with a Loopback Interface (Message Bod e>
y)"> <sourcecode name="" type="json"><![CDATA[{
<artwork align="center"><![CDATA[{
"ietf-l3vpn-ntw:vpn-network-accesses": { "ietf-l3vpn-ntw:vpn-network-accesses": {
"vpn-network-access": [ "vpn-network-access": [
{ {
"id": "vpn-access-loopback", "id": "vpn-access-loopback",
"interface-id": "Loopback1", "interface-id": "Loopback1",
"description": "An example of loopback interface.", "description": "An example of a loopback interface.",
"vpn-network-access-type": "ietf-vpn-common:loopback", "vpn-network-access-type": "ietf-vpn-common:loopback",
"status": { "status": {
"admin-status": { "admin-status": {
"status": "ietf-vpn-common:admin-up" "status": "ietf-vpn-common:admin-up"
} }
}, },
"ip-connection": { "ip-connection": {
"ipv6": { "ipv6": {
"local-address": "2001:db8::4", "local-address": "2001:db8::4",
"prefix-length": 128 "prefix-length": 128
} }
} }
} }
] ]
} }
} ]]></artwork> }
]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="app-ex" numbered="true" toc="default">
<section anchor="app-ex" <name>Overriding VPN Instance Profile Parameters</name>
title="Overriding VPN Instance Profile Parameters"> <t><xref target="override-ex" format="default"/> shows a simplified exam
<t><xref target="override-ex"></xref> shows a simplified example to ple to
illustrate how some information that is provided at the VPN service illustrate how some information that is provided at the VPN service
level (particularly as part of the 'vpn-instance-profiles') can be level (particularly as part of the 'vpn-instance-profiles') can be
overridden by the one configured at the VPN node level. In this overridden by information configured at the VPN node level. In this
example, PE3 and PE4 inherit the 'vpn-instance-profiles' parameters example, PE3 and PE4 inherit the 'vpn-instance-profiles' parameters
that are specified at the VPN service level, but PE1 and PE2 are that are specified at the VPN service level, but PE1 and PE2 are
provided with "maximum-routes" values at the VPN node level that provided with "maximum-routes" values at the VPN node level that
override the ones that are specified at the VPN service level.</t> override the values that are specified at the VPN service level.</t>
<figure anchor="override-ex">
<t><figure align="center" anchor="override-ex" <name>VPN Instance Profile Example (Message Body)</name>
title="VPN Instance Profile Example (Message Body)"> <sourcecode name="" type="json"><![CDATA[{
<artwork><![CDATA[{
"ietf-l3vpn-ntw:vpn-services": { "ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [ "vpn-service": [
{ {
"vpn-id": "override-example", "vpn-id": "override-example",
"vpn-service-topology": "ietf-vpn-common:hub-spoke", "vpn-service-topology": "ietf-vpn-common:hub-spoke",
"vpn-instance-profiles": { "vpn-instance-profiles": {
"vpn-instance-profile": [ "vpn-instance-profile": [
{ {
"profile-id": "HUB", "profile-id": "HUB",
"role": "ietf-vpn-common:hub-role", "role": "ietf-vpn-common:hub-role",
skipping to change at line 6550 skipping to change at line 6401
"vpn-node-id": "PE1", "vpn-node-id": "PE1",
"ne-id": "pe1", "ne-id": "pe1",
"router-id": "198.51.100.1", "router-id": "198.51.100.1",
"active-vpn-instance-profiles": { "active-vpn-instance-profiles": {
"vpn-instance-profile": [ "vpn-instance-profile": [
{ {
"profile-id": "HUB", "profile-id": "HUB",
"rd": "1:198.51.100.1:1001", "rd": "1:198.51.100.1:1001",
"address-family": [ "address-family": [
{ {
"address-family": "ietf-vpn-common:dual-stack", "address-family":
"ietf-vpn-common:dual-stack",
"maximum-routes": [ "maximum-routes": [
{ {
"protocol": "ietf-vpn-common:any", "protocol": "ietf-vpn-common:any",
"maximum-routes": 10 "maximum-routes": 10
} }
] ]
} }
] ]
} }
] ]
skipping to change at line 6573 skipping to change at line 6425
{ {
"vpn-node-id": "PE2", "vpn-node-id": "PE2",
"ne-id": "pe2", "ne-id": "pe2",
"router-id": "198.51.100.2", "router-id": "198.51.100.2",
"active-vpn-instance-profiles": { "active-vpn-instance-profiles": {
"vpn-instance-profile": [ "vpn-instance-profile": [
{ {
"profile-id": "SPOKE", "profile-id": "SPOKE",
"address-family": [ "address-family": [
{ {
"address-family": "ietf-vpn-common:dual-stack", "address-family":
"ietf-vpn-common:dual-stack",
"maximum-routes": [ "maximum-routes": [
{ {
"protocol": "ietf-vpn-common:any", "protocol": "ietf-vpn-common:any",
"maximum-routes": 100 "maximum-routes": 100
} }
] ]
} }
] ]
} }
] ]
skipping to change at line 6615 skipping to change at line 6468
"profile-id": "SPOKE" "profile-id": "SPOKE"
} }
] ]
} }
} }
] ]
} }
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t></t>
</section> </section>
<section anchor="multicast_vpn_example" numbered="true" toc="default">
<section anchor="multicast_vpn_example" <name>Multicast VPN Provisioning Example</name>
title="Multicast VPN Provisioning Example">
<t>IPTV is mainly distributed through multicast over the LANs. In the <t>IPTV is mainly distributed through multicast over the LANs. In the
following example, PIM-SM is enabled and functional between the PE and following example, PIM - Sparse Mode (PIM-SM) is enabled and functional between the PE and
the CE. The PE receives multicast traffic from a CE that is directly the CE. The PE receives multicast traffic from a CE that is directly
connected to the multicast source. The signaling between PE and CE is connected to the multicast source. The signaling between the PE and the
achieved using BGP. Also, RP is statically configured for a multicast CE is
achieved using BGP. Also, the RP is statically configured for a multicas
t
group.</t> group.</t>
<figure anchor="service-mc1">
<figure align="center" anchor="service-mc1" <name>Multicast L3VPN Service Example</name>
title="Multicast L3VPN Service Example"> <artwork align="center" name="" type="ascii-art" alt=""><![CDATA[
<artwork align="center"><![CDATA[ +-----------+ +------+ +------+ +-----------+
+-----------+ +------+ +------+ +-----------+ | Multicast |---| CE |--/--| PE |----| Backbone |
| Multicast |---| CE |--/--| PE |----| Backbone | | source | +------+ +------+ | IP/MPLS |
| source | +------+ +------+ | IP/MPLS | +-----------+ +-----------+
+-----------+ +-----------+ ]]></artwork>
]]></artwork>
</figure> </figure>
<t><xref target="service-mc2"/> illustrates how to configure a
<t>An example is provided below to illustrate how to configure a
multicast L3VPN service using the L3NM.</t> multicast L3VPN service using the L3NM.</t>
<t>First, the multicast service is created together with a generic VPN <t>First, the multicast service is created together with a generic VPN
instance profile (see the excerpt of the request message body shown in instance profile (see the excerpt of the request message body shown in
<xref target="service-mc2"></xref>)</t> <xref target="service-mc2" format="default"/>).</t>
<figure anchor="service-mc2">
<figure align="center" anchor="service-mc2" <name>Create Multicast VPN Service (Excerpt of the Message Request Bod
title=" Create Multicast VPN Service (Excerpt of the Message Req y)</name>
uest Body)"> <sourcecode name="" type="json"><![CDATA[{
<artwork align="center"><![CDATA[{
"ietf-l3vpn-ntw:vpn-services": { "ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [ "vpn-service": [
{ {
"vpn-id": "Multicast-IPTV", "vpn-id": "Multicast-IPTV",
"vpn-description": "Multicast IPTV VPN service", "vpn-description": "Multicast IPTV VPN service",
"customer-name": "a-name", "customer-name": "a-name",
"vpn-service-topology": "ietf-vpn-common:hub-spoke", "vpn-service-topology": "ietf-vpn-common:hub-spoke",
"vpn-instance-profiles": { "vpn-instance-profiles": {
"vpn-instance-profile": [ "vpn-instance-profile": [
{ {
skipping to change at line 6694 skipping to change at line 6540
} }
} }
} }
} }
] ]
} }
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>Then, the VPN nodes are created (see the excerpt of the request <t>Then, the VPN nodes are created (see the excerpt of the request
message body shown in <xref target="service-mc3"></xref>). In this message body shown in <xref target="service-mc3" format="default"/>). In this
example, the VPN node will represent VRF configured in the physical example, the VPN node will represent VRF configured in the physical
device.</t> device.</t>
<figure anchor="service-mc3">
<figure align="center" anchor="service-mc3" <name>Create Multicast VPN Node (Excerpt of the Message Request Body)<
title="Create Multicast VPN Node (Excerpt of the Message Request /name>
Body)"> <sourcecode name="" type="json"><![CDATA[{
<artwork align="left"><![CDATA[{
"ietf-l3vpn-ntw:vpn-node": [ "ietf-l3vpn-ntw:vpn-node": [
{ {
"vpn-node-id": "500003105", "vpn-node-id": "500003105",
"description": "VRF-IPTV-MULTICAST", "description": "VRF-IPTV-MULTICAST",
"ne-id": "198.51.100.10", "ne-id": "198.51.100.10",
"router-id": "198.51.100.10", "router-id": "198.51.100.10",
"active-vpn-instance-profiles": { "active-vpn-instance-profiles": {
"vpn-instance-profile": [ "vpn-instance-profile": [
{ {
"profile-id": "multicast", "profile-id": "multicast",
"rd": "65536:31050202" "rd": "65536:31050202"
} }
] ]
} }
} }
] ]
}]]></artwork> }
]]></sourcecode>
</figure> </figure>
<t>Finally, create the VPN network access with multicast enabled (see <t>Finally, create the VPN network access with multicast enabled (see
the excerpt of the request message body shown in <xref the excerpt of the request message body shown in <xref target="service-m
target="service-mc4"></xref>).</t> c4" format="default"/>).</t>
<figure anchor="service-mc4">
<figure align="center" anchor="service-mc4" <name>Create VPN Network Access (Excerpt of the Message Request Body)<
title="Create VPN Network Access (Excerpt of the Message Request /name>
Body)"> <sourcecode name="" type="json"><![CDATA[{
<artwork align="left"><![CDATA[{
"ietf-l3vpn-ntw:vpn-network-access": { "ietf-l3vpn-ntw:vpn-network-access": {
"id": "1/1/1", "id": "1/1/1",
"description": "Connected-to-source", "description": "Connected-to-source",
"vpn-network-access-type": "ietf-vpn-common:point-to-point", "vpn-network-access-type": "ietf-vpn-common:point-to-point",
"vpn-instance-profile": "multicast", "vpn-instance-profile": "multicast",
"status": { "status": {
"admin-status": { "admin-status": {
"status": "vpn-common:admin-up" "status": "ietf-vpn-common:admin-up"
}, },
"ip-connection": { "ip-connection": {
"ipv4": { "ipv4": {
"local-address": "203.0.113.1", "local-address": "203.0.113.1",
"prefix-length": 30, "prefix-length": 30,
"address-allocation-type": "static-address", "address-allocation-type": "static-address",
"static-addresses": { "static-addresses": {
"primary-address": "1", "primary-address": "1",
"address": [ "address": [
{ {
skipping to change at line 6771 skipping to change at line 6613
"bgp": { "bgp": {
"description": "Connected to CE", "description": "Connected to CE",
"peer-as": "65537", "peer-as": "65537",
"address-family": "ietf-vpn-common:ipv4", "address-family": "ietf-vpn-common:ipv4",
"neighbor": "203.0.113.2" "neighbor": "203.0.113.2"
} }
} }
] ]
}, },
"service": { "service": {
"inbound-bandwidth": "100000000", "pe-to-ce-bandwidth": "100000000",
"outbound-bandwidth": "100000000", "ce-to-pe-bandwidth": "100000000",
"mtu": 1500, "mtu": 1500,
"multicast": { "multicast": {
"access-type": "source-only", "access-type": "source-only",
"address-family": "ietf-vpn-common:ipv4", "address-family": "ietf-vpn-common:ipv4",
"protocol-type": "router", "protocol-type": "router",
"pim": { "pim": {
"hello-interval": 30, "hello-interval": 30,
"status": { "status": {
"admin-status": { "admin-status": {
"status": "ietf-vpn-common:admin-up" "status": "ietf-vpn-common:admin-up"
} }
} }
} }
} }
} }
} }
} }
}]]></artwork> }
]]></sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
<section numbered="false" toc="default">
<section anchor="Implementation" title="Implementation Status"> <name>Acknowledgements</name>
<t>This section records the status of known implementations of the YANG
module defined by this specification at the time of posting of this
document and is based on a proposal described in <xref
target="RFC7942"></xref>. The description of implementations in this
section is intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information
presented here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to note that
other implementations may exist.</t>
<t>According to <xref target="RFC7942"></xref>, "this will allow
reviewers and working groups to assign due consideration to documents
that have the benefit of running code, which may serve as evidence of
valuable experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working groups to use
this information as they see fit".</t>
<t>Note to the RFC Editor: As per <xref target="RFC7942"></xref>
guidelines, please remove this Implementation Status apendix prior
publication.</t>
<section title="Nokia Implementation">
<t>Details can be found at:
https://github.com/IETF-OPSAWG-WG/l3nm/blob/master/Implementattion/Nokia
.txt</t>
</section>
<section title="Huawei Implementation">
<t>Details can be found at:
https://github.com/IETF-OPSAWG-WG/l3nm/blob/master/Implementattion/Huawe
i.txt</t>
</section>
<section title="Infinera Implementation">
<t>Details can be found at:
https://github.com/IETF-OPSAWG-WG/l3nm/blob/master/Implementattion/Infin
era.txt</t>
</section>
<section title="Ribbon-ECI Implementation">
<t>Details can be found at:
https://github.com/IETF-OPSAWG-WG/l3nm/blob/master/Implementattion/Ribbo
n-ECI.txt</t>
</section>
<section title="Juniper Implementation">
<t>https://github.com/IETF-OPSAWG-WG/lxnm/blob/master/Implementattion/Ju
niper</t>
</section>
</section>
<section numbered="false" title="Acknowledgements" toc="default">
<t>During the discussions of this work, helpful comments, suggestions, <t>During the discussions of this work, helpful comments, suggestions,
and reviews were received from (listed alphabetically): Raul Arco, and reviews were received from (listed alphabetically) <contact fullname="
Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Raul Arco"/>,
Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Greg <contact fullname="Miguel Cros Cecilia"/>, <contact fullname="Joe Clarke"/
Mirsky, and Tom Petch. Many thanks to them. Thanks to Philip Eardly for >, <contact fullname="Dhruv Dhody"/>, <contact fullname="Adrian Farrel"/>, <cont
the review of an early version of the document.</t> act fullname="Roque Gagliano"/>, <contact fullname="Christian Jacquenet"/>, <con
tact fullname="Kireeti Kompella"/>, <contact fullname="Julian Lucek"/>, <contact
<t>Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski fullname="Greg Mirsky"/>, and <contact fullname="Tom Petch"/>. Many thanks to t
contributed to early version of the individual submission. <vspace hem. Thanks to <contact fullname="Philip Eardley"/> for
blankLines="1" />Many thanks to Robert Wilton for the AD review. <vspace the review of an early draft version of the document.</t>
blankLines="1" />Thanks to Andrew Malis for the routing directorate <t><contact fullname="Daniel King"/>, <contact fullname="Daniel Voyer"/>,
review, Rifaat Shekh-Yusef for the security directorate review, Qin Wu <contact fullname="Luay Jalil"/>, and <contact fullname="Stephane Litkowski"/>
for the opsdir review, and Pete Resnick for the genart directorate contributed to early draft versions of this document. Many thanks to <cont
review. Thanks to Michael Scharf for the discussion on TCP-AO. <vspace act fullname="Robert Wilton"/> for the AD review. Thanks to <contact fullname="A
blankLines="1" />Thanks to Martin Duke, Lars Eagert, Zaheduzzaman ndrew Malis"/> for the routing directorate
Sarker, Roman Danyliw, Erik Kline, Benjamin Kaduk, Francesca Palombini, review, <contact fullname="Rifaat Shekh-Yusef"/> for the security director
and &Eacute;ric Vyncke for the IESG review.</t> ate review, <contact fullname="Qin Wu"/>
for the opsdir review, and <contact fullname="Pete Resnick"/> for the gena
<t>This work was supported in part by the European Commission funded rt directorate
review. Thanks to <contact fullname="Michael Scharf"/> for the discussion
on the TCP-AO. Thanks to <contact fullname="Martin Duke"/>, <contact fullname="L
ars Eggert"/>, <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Rom
an Danyliw"/>, <contact fullname="Erik Kline"/>, <contact fullname="Benjamin Kad
uk"/>, <contact fullname="Francesca Palombini"/>,
and <contact fullname="Éric Vyncke"/> for the IESG review.</t>
<t>This work was supported in part by the European Commission-funded
H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020 H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020
Secured autonomic traffic management for a Tera of SDN flows (Teraflow) Secured autonomic traffic management for a Tera of SDN flows (Teraflow)
project (G.A. 101015857).</t> project (G.A. 101015857).</t>
</section> </section>
<section anchor="Contributors" numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="Victor Lopez">
<organization>Nokia</organization>
<address>
<postal>
<street></street>
<city>Madrid</city>
<region></region>
<code></code>
<country>Spain</country>
</postal>
<email>victor.lopez@nokia.com</email>
</address>
</contact>
<section anchor="Contributors" numbered="false" title="Contributors"> <contact fullname="Qin Wu">
<figure> <organization>Huawei</organization>
<artwork><![CDATA[Victor Lopez <address>
Telefonica <email>bill.wu@huawei.com</email>
Email: victor.lopezalvarez@telefonica.com </address>
</contact>
Qin Wu
Huawei
Email: bill.wu@huawei.com>
Manuel Julian <contact fullname="Manuel Lopez">
Vodafone <organization>Vodafone</organization>
Email: manuel-julian.lopez@vodafone.com <address>
<postal>
<country>Spain</country>
</postal>
<email>manuel-julian.lopez@vodafone.com</email>
</address>
</contact>
Lucia Oliva Ballega <contact fullname="Lucia Oliva Ballega">
Telefonica <organization>Telefonica</organization>
Email: lucia.olivaballega.ext@telefonica.com <address>
<email>lucia.olivaballega.ext@telefonica.com</email>
</address>
</contact>
Erez Segev <contact fullname="Erez Segev">
ECI Telecom <organization>Ribbon Communications</organization>
Email: erez.segev@ecitele.com> <address>
<email>erez.segev@rbbn.com</email>
</address>
</contact>
Paul Sherratt <contact fullname="Paul Sherratt">
Gamma Telecom <organization>Gamma Telecom</organization>
Email: paul.sherratt@gamma.co.uk <address>
]]></artwork> <email>paul.sherratt@gamma.co.uk</email>
</figure> </address>
</contact>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 697 change blocks. 
2709 lines changed or deleted 2792 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/