<?xmlversion="1.0" encoding="US-ASCII"?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[<!-- One method to get references from the online citation libraries. There has to be one entity for each item to be referenced. An alternate method (rfc include) is described in the references. --> <!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC3688 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"> <!ENTITY RFC6020 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"><!ENTITYRFC6241 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml">nbsp " "> <!ENTITYRFC6242 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml">zwsp "​"> <!ENTITYRFC7950 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml">nbhy "‑"> <!ENTITYRFC7432 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"> <!ENTITY RFC8040 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"> <!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC8214 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8214.xml"> <!ENTITY RFC8309 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8309.xml"> <!ENTITY RFC8340 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"> <!ENTITY RFC8341 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"> <!ENTITY RFC8453 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml"> <!ENTITY RFC8466 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8466.xml">wj "⁠"> ]><?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 xmlns:xi="http://www.w3.org/2001/XInclude" category="std" number="9291" docName="draft-ietf-opsawg-l2nm-19"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 ***** -->ipr="trust200902" obsoletes="" updates="" consensus="true" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="5" symRefs="true" sortRefs="true" version="3"> <front><!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters --><titleabbrev="L2NM">Aabbrev="A Network YANG Data Model for L2VPNs">A YANG Network Data Model for Layer 2 VPNs</title><!-- add 'role="editor"' below for the editors if appropriate --> <!-- Another author who claims to be an editor --><seriesInfo name="RFC" value="9291"/> <author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Boucadair "> <organization>Orange</organization> <address> <postal><street></street> <!-- Reorder these if your country does things differently --><street/> <city>Rennes</city><region></region> <code></code><region/> <code/> <country>France</country> </postal><phone></phone><phone/> <email>mohamed.boucadair@orange.com</email><!-- uri and facsimile elements may also be added --></address> </author> <author fullname="Oscar Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"> <organization>Telefonica</organization> <address> <postal><street></street> <!-- Reorder these if your country does things differently --><street/> <city>Madrid</city><region></region> <code></code><region/> <code/> <country>Spain</country> </postal> <email>oscar.gonzalezdedios@telefonica.com</email><!-- uri and facsimile elements may also be added --></address> </author> <author fullname="Samier Barguil" initials="S." surname="Barguil"> <organization>Telefonica</organization> <address> <postal><street></street> <!-- Reorder these if your country does things differently --><street/> <city>Madrid</city><region></region> <code></code><region/> <code/> <country>Spain</country> </postal><phone></phone><phone/> <email>samier.barguilgiraldo.ext@telefonica.com</email><!-- uri and facsimile elements may also be added --></address> </author> <author fullname="Luis Angel Munoz" initials="L." surname="Munoz"> <organization>Vodafone</organization> <address> <postal><street></street> <!-- Reorder these if your country does things differently --> <city></city> <region></region> <code></code><street/> <city/> <region/> <code/> <country>Spain</country> </postal><phone></phone><phone/> <email>luis-angel.munoz@vodafone.com</email><!-- uri and facsimile elements may also be added --></address> </author> <dateday="02" month="June" year="2022" /> <!-- Meta-data Declarations -->month="September" year="2022"/> <area>ops</area> <workgroup>OPSAWG</workgroup> <keyword>automation</keyword> <keyword>network model</keyword> <keyword>service provider</keyword> <keyword>service provisionning</keyword> <keyword>network automation</keyword> <keyword>service delivery</keyword> <abstract> <t>This document defines an L2VPN NetworkYANGModel (L2NM)whichthat can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements theLayer 2L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices.</t> <t>Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types.</t> </abstract><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: A YANG Network Data Model for Layer 2 VPNs";</t> <t>reference: RFC XXXX</t> </list></t> <t>Also, please update the "revision" date of the YANG modules.</t> </note></front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t><xreftarget="RFC8466"></xref>target="RFC8466" format="default"/> defines an L2VPN Service Model (L2SM) YANG data model that can be used between customers and service providers for ordering Layer 2 Virtual Private Network (L2VPN) services. This document complements the L2SM by creating a network-centric view of the service: the L2VPN Network Model (L2NM).</t> <t>Also, this document defines the initial versions of two IANA-maintained modules that define a set of identities of BGP Layer 2 encapsulation types (<xreftarget="iana-bgp"></xref>)target="iana-bgp" format="default"/>) and pseudowire types (<xreftarget="iana-pw"></xref>).target="iana-pw" format="default"/>). These types are used in the L2NM to identify a Layer 2 encapsulation type as a function of thesignallingsignaling option used to deliver an L2VPN service. Relying upon these IANA-maintained modules is meant to provide more flexibility in handling new types rather than being limited by a set of identities defined in the L2NM itself. <xreftarget="es-yang"></xref>target="es-yang" format="default"/> defines another YANG module to manage Ethernet Segments (ESes) that are required for instantiating Ethernet VPNs (EVPNs). References to Ethernet segments that are created using the module in <xreftarget="es-yang"></xref>target="es-yang" format="default"/> can be included in the L2NM for EVPNs.</t> <t>The L2NM (<xreftarget="YANG_module"></xref>)target="YANG_module" format="default"/>) can be exposed, for example, by a network controller to a service controller within the service provider's network. In particular, the model can be used in the communication interface between the entity that interacts directly with the customer (i.e., the service orchestrator) and the entity in charge of network orchestration and control (a.k.a., network controller/orchestrator) by allowing for more network-centric information to be included.</t> <t>The L2NM supportscapabilities,capabilities such as exposing operational parameters, transport protocols selection, and precedence. It can also serve as a multi-domain orchestration interface.</t> <t>The L2NM is scoped for a variety of Layer 2 Virtual PrivateNetworks,Networks such as:<?rfc subcompact="yes" ?><list style="symbols"> <t>Virtual</t> <ul spacing="compact"> <li>Virtual Private LAN Service (VPLS) <xreftarget="RFC4761"></xref><xref target="RFC4762"></xref></t> <t>Virtualtarget="RFC4761" format="default"/> <xref target="RFC4762" format="default"/></li> <li>Virtual Private Wire Service (VPWS)(Section 3.1.1 of <xref target="RFC4664"></xref>)</t>(<xref target="RFC4664" sectionFormat="of" section="3.1.1" format="default"/>)</li> <li> <t>Various flavors of EVPNs:<list style="symbols"> <t>VPWS</t> <ul spacing="compact"> <li>VPWS EVPN <xreftarget="RFC8214"></xref>,</t> <t>Providertarget="RFC8214" format="default"/>,</li> <li>Provider Backbone Bridging Combined with Ethernet VPNs(PBB EVPNs)(PBB-EVPNs) <xreftarget="RFC7623"></xref>,</t> <t>EVPNtarget="RFC7623" format="default"/>,</li> <li>EVPN over MPLS <xreftarget="RFC7432"></xref>, and</t> <t>EVPNtarget="RFC7432" format="default"/>, and</li> <li>EVPN over VirtualeXtensible Local Area NetworkExtensible LAN (VXLAN) <xreftarget="RFC8365"></xref>.</t> </list></t> </list></t> <t><?rfc subcompact="no" ?>Thetarget="RFC8365" format="default"/>.</li> </ul> </li> </ul> <t>The L2NM is designed to easily support future Layer 2 VPN flavors and procedures (e.g., advanced configuration such as pseudowires resilience orMulti-Segmentmulti-segment pseudowires <xreftarget="RFC7267"></xref>).target="RFC7267" format="default"/>). A set of examples to illustrate the use of the L2NM are provided in <xreftarget="examples"></xref>.</t>target="examples" format="default"/>.</t> <t>This document uses the common Virtual Private Network (VPN) YANG module defined in <xreftarget="RFC9181"></xref>.</t>target="RFC9181" format="default"/>.</t> <t>The YANG data models in this documentconformsconform to the Network Management Datastore Architecture (NMDA) defined in <xreftarget="RFC8342"></xref>.</t>target="RFC8342" format="default"/>.</t> </section> <section anchor="terminology"title="Terminology">numbered="true" toc="default"> <name>Terminology</name> <t>This document assumes that the reader is familiar with <xreftarget="RFC6241"></xref>,target="RFC6241" format="default"/>, <xreftarget="RFC7950"></xref>,target="RFC7950" format="default"/>, <xreftarget="RFC8466"></xref>,target="RFC8466" format="default"/>, <xreftarget="RFC4026"></xref>,target="RFC4026" format="default"/>, and <xreftarget="RFC8309"></xref>.target="RFC8309" format="default"/>. This document uses terminology from those documents.</t> <t>This document uses the term "network model" as defined inSection 2.1 of<xreftarget="RFC8969"></xref>.</t>target="RFC8969" sectionFormat="of" section="2.1" format="default"/>.</t> <t>The meanings of the symbols in the YANG tree diagramsisare defined in <xreftarget="RFC8340"></xref>.</t>target="RFC8340" format="default"/>.</t> <t>This document makes use of the following terms:</t><t><list style="hanging"> <t hangText="Ethernet segment (ES):">Refers<dl newline="false" spacing="normal"> <dt>Ethernet Segment (ES):</dt> <dd>Refers to the set oftheEthernet links that are used by a customer site (device or network) to connect to one or more Provider Edges(PEs).</t> <t hangText="Layer 2 VPN(PEs).</dd> <dt>L2VPN Service Model(L2SM):">Describes(L2SM):</dt> <dd>Describes the service characterization of an L2VPN that interconnects a set of sites from the customer's perspective. The customer service model does not provide details on the service provider network. An L2VPN customer service model is defined in <xreftarget="RFC8466"></xref>.</t> <t hangText="Layer 2 VPNtarget="RFC8466" format="default"/>.</dd> <dt>L2VPN Network Model(L2NM):">Refers(L2NM):</dt> <dd>Refers to the YANG data model that describes an L2VPN service with a network-centric view. It contains information on the service provider network and might include allocated resources. Network controllers can use it to manage the Layer 2 VPN service configuration in the service provider's network. The corresponding YANG module can be used by a service orchestrator to request a VPN service to a network controller or to expose the list of active L2VPN services. The L2NM can also be used to retrieve a set of L2VPN-related state information (includingOAM).</t> <t hangText="MAC-VRF:">RefersOperations, Administration, and Maintenance (OAM)).</dd> <dt>MAC-VRF:</dt> <dd>Refers to a Virtual Routing and Forwarding (VRF) table for Media Access Control (MAC) addresses on aPE.</t> <t hangText="Network controller:">DenotesPE.</dd> <dt>Network controller:</dt> <dd>Denotes a functional entity responsible for the management of the service providernetwork.</t> <t hangText="Service orchestrator:">Refersnetwork.</dd> <dt>Service orchestrator:</dt> <dd>Refers to a functional entity that interacts with the customer of an L2VPN relying upon, e.g., the L2SM. The service orchestrator is responsible for the Customer Edge-to Provider Edge (CE-PE) attachment circuits, the PE selection, and requesting the activation of the L2VPN service to a networkcontroller.</t> <t hangText="Servicecontroller.</dd> <dt>Service providernetwork:">Is anetwork:</dt> <dd>A network that is able to provide L2VPN-relatedservices.</t> <t hangText="VPN node:">Is anservices.</dd> <dt>VPN node:</dt> <dd>An abstraction that represents a set of policies applied on a PE andbelongingbelongs to a single VPN service. A VPN service involves one or more VPN nodes. The VPN node will identify the service providers' node on which the VPN isdeployed.</t> <t hangText="VPNdeployed.</dd> <dt>VPN networkaccess:">Is anaccess:</dt> <dd>An abstraction that represents the network interfaces that are associated with a given VPN node. Traffic coming from the VPN network access belongs to the VPN. The attachment circuits (bearers) betweenCustomer Edges (CEs)CEs andProvider Edges (PEs)PEs are terminated in the VPN networkaccess.</t> <t hangText="VPNaccess.</dd> <dt>VPN serviceprovider:">Is aprovider:</dt> <dd>A service provider that offers L2VPN-relatedservices.</t> </list></t>services.</dd> </dl> </section> <sectiontitle="Acronymsnumbered="true" toc="default"> <name>Acronyms andAbbreviations ">Abbreviations</name> <t>The following acronyms and abbreviations are used in thisdocument:<?rfc subcompact="yes" ?></t> <t><list hangIndent="8" style="hanging"> <t hangText="ACL">Accessdocument:</t> <dl newline="false" spacing="compact" indent="8"> <dt>ACL</dt> <dd>Access ControlList</t> <t hangText="BGP">BorderList</dd> <dt>BGP</dt> <dd>Border GatewayProtocol</t> <t hangText="BUM">Broadcast, unknown unicast, or multicast</t> <t hangText="CE">Customer Edge</t> <t hangText="ES">Ethernet Segment</t> <t hangText="ESI">EthernetProtocol</dd> <dt>BUM</dt> <dd>Broadcast, Unknown Unicast, or Multicast</dd> <dt>CE</dt> <dd>Customer Edge</dd> <dt>ES</dt> <dd>Ethernet Segment</dd> <dt>ESI</dt> <dd>Ethernet SegmentIdentifier</t> <t hangText="EVPN">Ethernet VPN</t> <t hangText="L2VPN">LayerIdentifier</dd> <dt>EVPN</dt> <dd>Ethernet VPN</dd> <dt>L2VPN</dt> <dd>Layer 2 Virtual PrivateNetwork</t> <t hangText="L2SM">L2VPNNetwork</dd> <dt>L2SM</dt> <dd>L2VPN ServiceModel</t> <t hangText="L2NM">L2VPNModel</dd> <dt>L2NM</dt> <dd>L2VPN NetworkModel</t> <t hangText="MAC">MediaModel</dd> <dt>MAC</dt> <dd>Media AccessControl</t> <t hangText="PBB">ProviderControl</dd> <dt>PBB</dt> <dd>Provider BackboneBridging</t> <t hangText="PCP">PriorityBridging</dd> <dt>PCP</dt> <dd>Priority CodePoint</t> <t hangText="PE">Provider Edge</t> <t hangText="QoS">Quality of Service</t> <t hangText="RD">Route Distinguisher</t> <t hangText="RT">Route Target</t> <t hangText="VPLS">VirtualPoint</dd> <dt>PE</dt> <dd>Provider Edge</dd> <dt>QoS</dt> <dd>Quality of Service</dd> <dt>RD</dt> <dd>Route Distinguisher</dd> <dt>RT</dt> <dd>Route Target</dd> <dt>VPLS</dt> <dd>Virtual Private LANService</t> <t hangText="VPN">VirtualService</dd> <dt>VPN</dt> <dd>Virtual PrivateNetwork</t> <t hangText="VPWS">VirtualNetwork</dd> <dt>VPWS</dt> <dd>Virtual Private WireService</t> <t hangText="VRF">VirtualService</dd> <dt>VRF</dt> <dd>Virtual Routing andForwarding</t> </list></t> <t><?rfc subcompact="no" ?></t>Forwarding</dd> </dl> <t/> </section> <section anchor="ref"title="Reference Architecture">numbered="true" toc="default"> <name>Reference Architecture</name> <t><xreftarget="L2SM_and_L2NM"></xref>target="L2SM_and_L2NM" format="default"/> illustrates how the L2NM is used. As a reminder, this figure is an expansion of the architecture presented inSection 3 of<xreftarget="RFC8466"></xref>target="RFC8466" sectionFormat="of" section="3" format="default"/> and decomposes the box marked "orchestration" in that figure into three separate functional components called "Service Orchestration", "Network Orchestration", and "Domain Orchestration".</t> <t>Similar toSection 3 of<xreftarget="RFC8466"></xref>,target="RFC8466" sectionFormat="of" section="3" format="default"/>, CE to PE attachment is achieved through a bearer with a Layer 2 connection on top. The bearer refers to properties of the attachment that are below Layer 2, while the connection refers to Layer 2 protocol-oriented properties.</t> <t>The reader may refer to <xreftarget="RFC8309"></xref>target="RFC8309" format="default"/> for the distinction between the "Customer Service Model",the"Service Delivery Model",the"Network Configuration Model", andthe"Device Configuration Model". The "Domain Orchestration" and "Config Manager" roles may be performed by "SDN Controllers".</t> <figurealign="center" anchor="L2SM_and_L2NM" title="L2SManchor="L2SM_and_L2NM"> <name>L2SM and L2NMInteraction">Interaction</name> <artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ +---------------+ | Customer | +-------+-------+ Customer Service Model | e.g., l2vpn-svc | +-------+-------+ | Service | | Orchestration | +-------+-------+ Network Model | l2vpn-ntw + l2vpn-es | +-------+-------+ | Network | | Orchestration | +-------+-------+ Network Configuration Model | +-----------+-----------+ | | +--------+------+ +--------+------+ | Domain | | Domain | | Orchestration | | Orchestration | +---+-----------+ +--------+------+ Device | | | Configuration | | | Model | | | +----+----+ | | | Config | | | | Manager | | | +----+----+ | | | | | | NETCONF/CLI.................. | | | +--------------------------------+ \ Network / \ / +----+ Bearer +----+ +----+ +----+ |CE A+ ---------- +PE A+ +PE B+ ------- +CE B| +----+ Connection +----+ +----+ +----+ Site A Site B NETCONF: Network Configuration Protocol CLI: Command-Line Interface ]]></artwork> </figure><t></t><t/> <t>The customer may use various means to request a service that may trigger the instantiation of an L2NM. The customer may use the L2SM or may rely upon more abstract models to request a service that relies upon an L2VPN service. For example, the customer may supply an IP Connectivity Provisioning Profile (CPP) that characterizes the requested service <xreftarget="RFC7297"></xref>,target="RFC7297" format="default"/>, an enhanced VPN (VPN+) service <xreftarget="I-D.ietf-teas-enhanced-vpn"></xref>,target="I-D.ietf-teas-enhanced-vpn" format="default"/>, or an IETF network slice service <xreftarget="I-D.ietf-teas-ietf-network-slices"></xref>.</t>target="I-D.ietf-teas-ietf-network-slices" format="default"/>.</t> <t>Note also that both the L2SM andtheL2NM may be used in the context of the Abstraction and Control of TE Networks (ACTN) framework <xreftarget="RFC8453"></xref>.target="RFC8453" format="default"/>. <xreftarget="l2sm_actn"></xref>target="l2sm_actn" format="default"/> shows the Customer Network Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and the Provisioning Network Controller (PNC).</t> <figurealign="center" anchor="l2sm_actn" title="L2SManchor="l2sm_actn"> <name>L2SM and L2NM in the Context ofACTN">ACTN</name> <artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ +----------------------------------+ | Customer | | +-----------------------------+ | | | CNC | | | +-----------------------------+ | +----+-----------------------+-----+ | | | L2SM | L2SM | | +---------+---------+ +---------+---------+ | MDSC | | MDSC | | +---------------+ | | (parent) | | | Service | | +---------+---------+ | | Orchestration | | | | +-------+-------+ | | L2NM | | | | | | L2NM | +---------+---------+ | | | | MDSC | | +-------+-------+ | | (child) | | | Network | | +---------+---------+ | | Orchestration | | | | +---------------+ | | +---------+---------+ | | | | Network Configuration | | | +------------+-------+ +---------+------------+ | Domain | | Domain | | Controller | | Controller | | +---------+ | | +---------+ | | | PNC | | | | PNC | | | +---------+ | | +---------+ | +------------+-------+ +---------+------------+ | | | Device Configuration | | | +----+---+ +----+---+ | Device | | Device | +--------+ +--------+ ]]></artwork> </figure> </section> <section anchor="relation"title="Relationshipnumbered="true" toc="default"> <name>Relationship to Other YANG DataModels">Models</name> <t>The "ietf-vpn-common" module <xreftarget="RFC9181"></xref>target="RFC9181" format="default"/> includes a set of identities, types, and groupings that are meant to be reused by VPN-related YANG modules independently of the layer (e.g., Layer2,2 or Layer 3) and the type of the module (e.g., networkmodel,model or service model) including future revisions of existing models (e.g., <xreftarget="RFC8466"></xref>).target="RFC8466" format="default"/>). The L2NM reuses these common types and groupings.</t> <t>Also, the L2NM uses the IANA-maintained modules "iana-bgp-l2-encaps" (<xreftarget="iana-bgp"></xref>)target="iana-bgp" format="default"/>) and "iana-pseudowire-types" (<xreftarget="iana-pw"></xref>)target="iana-pw" format="default"/>) to identify Layer 2 encapsulation and pseudowire types. More details are provided in Sections <xref format="counter"target="bgp"></xref>target="bgp"/> and <xref format="counter"target="l2tp"></xref>.</t>target="l2tp"/>.</t> <t>For the particular case of EVPN, the L2NM includes a name that refers to an Ethernet segment that is created using the "ietf-ethernet-segment" module (<xreftarget="es-yang"></xref>).target="es-yang" format="default"/>). Some ES-related examples are provided in Appendices <xref format="counter"target="evpn-vpws-app"></xref>target="evpn-vpws-app"/> and <xref format="counter"target="auto-ex"></xref>.</t>target="auto-ex"/>.</t> <t>As discussed in <xreftarget="ref"></xref>,target="ref" format="default"/>, the L2NM is used to manage L2VPN services within a service provider network. The module provides a network view of the L2VPN service. Such a view is only visible to the service provider and is not exposed outside (to customers, for example). The following discusses how the L2NM interfaces with other YANG modules:</t><t><list style="hanging"> <t hangText="L2SM:">The<dl newline="false" spacing="normal"> <dt>L2SM:</dt> <dd> <t>The L2NM is not a customer servicemodel.<vspace blankLines="1" />Themodel.</t> <t>The internal view of the service (i.e., the L2NM) may be mapped to an external viewwhichthat is visible to customers: L2VPN Service Model (L2SM) <xreftarget="RFC8466"></xref>. <vspace blankLines="1" />Thetarget="RFC8466" format="default"/>. </t> <t>The L2NM can be fed with inputs that are requested bycustomers, typically, relying uponcustomers and that typically rely on an L2SM template. Concretely, some parts of the L2SM module can be directly mapped into the L2NM while other parts are generated as a function of the requested service and local guidelines. Finally, there are parts local to the serviceproviderprovider, and they do not map directly to theL2SM.<vspace blankLines="1" />NoteL2SM.</t> <t>Note that using the L2NM within a service provider does not assume, nor does it preclude, exposing the VPN service via the L2SM. This is deployment specific. Nevertheless, the design of L2NM tries to align as much as possible with the features supported by the L2SM to ease the grafting of both the L2NM and the L2SM for the sake of highly automated VPN service provisioning and delivery.</t><t hangText="Network</dd> <dt>Network TopologyModules:">AnModules:</dt> <dd>An L2VPN involves nodes that are part of a topology managed by the service provider network. Such a topology can be represented using the network topology module in <xreftarget="RFC8345"></xref>target="RFC8345" format="default"/> or its extension, such as a network YANG module for Service Attachment Points (SAPs) <xreftarget="I-D.ietf-opsawg-sap"></xref>.</t> <t hangText="Device Modules:">Thetarget="I-D.ietf-opsawg-sap" format="default"/>.</dd> <dt>Device Modules:</dt> <dd> <t>The L2NM is not a device model.<vspace blankLines="1" />Once</t> <t>Once a global VPN service is captured by means of the L2NM, the actual activation and provisioning of the VPN service will involve a variety of device modules to tweak the required functions for the delivery of the service. These functions are supported by the VPN nodes and can be managed using device YANG modules. A non-comprehensive list of such device YANG modules is providedbelow:<list style="symbols"> <t>Interfaces <xref target="RFC8343"></xref>.</t> <t>BGP <xref target="I-D.ietf-idr-bgp-model"></xref>.</t> <t>MPLS <xref target="RFC8960"></xref>.</t> <t>Accessbelow:</t> <ul spacing="normal"> <li>Interfaces <xref target="RFC8343" format="default"/></li> <li>BGP <xref target="I-D.ietf-idr-bgp-model" format="default"/></li> <li>MPLS <xref target="RFC8960" format="default"/></li> <li>Access Control Lists (ACLs) <xreftarget="RFC8519"></xref>.</t> </list><vspace blankLines="1" />Howtarget="RFC8519" format="default"/></li> </ul> <t>How the L2NM is used to derive device-specific actions is implementation specific.</t></list></t></dd> </dl> </section> <section anchor="es"title="Descriptionnumbered="true" toc="default"> <name>Description of the Ethernet Segment YANGModule">Module</name> <t>The 'ietf-ethernet-segment' module (<xreftarget="es-tree"></xref>)target="es-tree" format="default"/>) is used to manage a set of Ethernet segments in the context of an EVPN service.</t><t><figure align="center" anchor="es-tree" title="Ethernet<figure anchor="es-tree"> <name>Ethernet Segments TreeStructure"> <artwork align="center"><![CDATA[module:Structure</name> <sourcecode type="yangtree"><![CDATA[module: ietf-ethernet-segment +--rw ethernet-segments +--rw ethernet-segment* [name] +--rw name string +--rw esi-type? identityref +--rw (esi-choice)? | +--:(directly-assigned) | | +--rw ethernet-segment-identifier? yang:hex-string | +--:(auto-assigned) | +--rw esi-auto | +--rw (auto-mode)? | | +--:(from-pool) | | | +--rw esi-pool-name? string | | +--:(full-auto) | | +--rw auto? empty | +--ro auto-ethernet-segment-identifier? | yang:hex-string +--rw esi-redundancy-mode? identityref +--rw df-election | +--rw df-election-method? identityref | +--rw revertive? boolean | +--rw election-wait-time? uint32 +--rw split-horizon-filtering? boolean +--rw pbb | +--rw backbone-src-mac? yang:mac-address +--rw member* [ne-id interface-id] +--rw ne-id string +--rw interface-id string]]></artwork> </figure></t>]]></sourcecode> </figure> <t>The descriptions of the data nodes depicted in <xreftarget="es-tree"></xref>target="es-tree" format="default"/> are asfollows:<list style="hanging"> <t hangText="'name':">Setsfollows:</t> <dl newline="false" spacing="normal"> <dt>'name':</dt> <dd> <t>Sets a name to uniquely identify an ES within a service provider network. In order to ease referencing ESes by their name in other modules, "es-ref" typedef isdefined.<vspace blankLines="1" />Thisdefined.</t> <t>This typedef is used in the VPN network access level of the L2NM to reference an ES (<xreftarget="sna"></xref>).target="sna" format="default"/>). An example to illustrate such a use in the L2NM is provided in <xreftarget="evpn-vpws-app"></xref>.</t> <t hangText="'esi-type':">Indicatestarget="evpn-vpws-app" format="default"/>.</t> </dd> <dt>'esi-type':</dt> <dd> <t>Indicates the Ethernet Segment Identifier (ESI) type as discussed inSection 5 of<xreftarget="RFC7432"></xref>.target="RFC7432" sectionFormat="of" section="5" format="default"/>. ESIs can be automatically assigned either with or without indicating a pool from which an ESI should be taken ('esi-pool-name'). The following types are supported:<list style="hanging"> <t hangText="'esi-type-0-operator':">The</t> <dl newline="false" spacing="normal"> <dt>'esi-type-0-operator':</dt> <dd>The ESI is directly configured by the VPN service provider. The configured value is provided in'ethernet-segment-identifier'.</t> <t hangText="'esi-type-1-lacp':">The'ethernet-segment-identifier'.</dd> <dt>'esi-type-1-lacp':</dt> <dd>The ESI is auto-generated from the IEEE 802.1AX Link Aggregation Control Protocol (LACP) <xreftarget="IEEE802.1AX"></xref>.</t> <t hangText="'esi-type-2-bridge':">Thetarget="IEEE802.1AX" format="default"/>.</dd> <dt>'esi-type-2-bridge':</dt> <dd>The ESI is auto-generated and determined based on the Layer 2 bridgeprotocol.</t> <t hangText="'esi-type-3-mac':">Theprotocol.</dd> <dt>'esi-type-3-mac':</dt> <dd>The ESI is a MAC-based ESI value that can be auto-generated or configured by the VPN serviceprovider.</t> <t hangText="'esi-type-4-router-id':">Theprovider.</dd> <dt>'esi-type-4-router-id':</dt> <dd>The ESI is auto-generated or configured by the VPN service provider based on the Router ID. The 'router-id' supplied in <xreftarget="vpn_node"></xref>target="vpn_node" format="default"/> can be used to auto-derive an ESI when this type isused.</t> <t hangText="'esi-type-5-asn':">Theused.</dd> <dt>'esi-type-5-asn':</dt> <dd>The ESI is auto-generated or configured by the VPN service provider based on the Autonomous System (AS) number. The 'local-autonomous-system' supplied in <xreftarget="profile"></xref>target="profile" format="default"/> can be used to auto-derive an ESI when this type isused.</t> </list><vspace blankLines="1" />Auto-generatedused.</dd> </dl> <t>Auto-generated values can be retrieved using 'auto-ethernet-segment-identifier'.</t><t hangText="'esi-redundancy-mode':">Specifies</dd> <dt>'esi-redundancy-mode':</dt> <dd>Specifies the EVPN redundancy mode for a given ES. The following modes are supported: Single-Active(Section 14.1.1 of <xref target="RFC7432"></xref>)(<xref target="RFC7432" sectionFormat="of" section="14.1.1" format="default"/>) or All-Active(Section 14.1.2 of <xref target="RFC7432"></xref>).</t> <t hangText="'df-election':">Specifies(<xref target="RFC7432" sectionFormat="of" section="14.1.2" format="default"/>).</dd> <dt>'df-election':</dt> <dd> <t>Specifies a set of parameters related to the Designated Forwarder (DF) election(Section 8.5 of <xref target="RFC7432"></xref>).(<xref target="RFC7432" sectionFormat="of" section="8.5" format="default"/>). For example, this data node can be used to indicate an election method (e.g., <xreftarget="RFC8584"></xref>target="RFC8584" format="default"/> or <xreftarget="I-D.ietf-bess-evpn-pref-df"></xref>).target="I-D.ietf-bess-evpn-pref-df" format="default"/>). If no election method is indicated, the default method defined inSection 8.5 of<xreftarget="RFC7432"></xref>target="RFC7432" sectionFormat="of" section="8.5" format="default"/> is used.<vspace blankLines="1" />As</t> <t>As discussed inSection 1.3.2 of<xreftarget="RFC8584"></xref>,target="RFC8584" sectionFormat="of" section="1.3.2" format="default"/>, the default behavior is to trigger the DF election procedure when a DF fails (e.g., link failure). The former DF will take over when it is available again. Such a mode is calledrevertive.'revertive'. The behavior can be overridden by setting the 'revertive' leaf to 'false'.<vspace blankLines="1" />Also,</t> <t>Also, this data node can be used to configure a DF Wait timer ('election-wait-time')(Section 2.1 of <xref target="RFC8584"></xref>).</t> <t hangText="'split-horizon-filtering':">Controls(<xref target="RFC8584" sectionFormat="of" section="2.1" format="default"/>).</t> </dd> <dt>'split-horizon-filtering':</dt> <dd>Controls the activation of the split-horizon filtering for an ES(Section 8.3 of <xref target="RFC7432"></xref>).</t> <t hangText="'pbb':">Indicates(<xref target="RFC7432" sectionFormat="of" section="8.3" format="default"/>).</dd> <dt>'pbb':</dt> <dd> <t>Indicates data nodes that are specific to PBB <xreftarget="IEEE-802-1ah"></xref>: <list style="hanging"> <t hangText="'backbone-src-mac':">Associatestarget="IEEE-802-1ah" format="default"/>: </t> <dl newline="false" spacing="normal"> <dt>'backbone-src-mac':</dt> <dd>Associates a Provider Backbone MAC (B-MAC) address with an ES. This is particularly useful for All-Active multihomed ESes(Section 9.1 of <xref target="RFC7623"></xref>).</t> </list></t> <t hangText="'member':">Lists(<xref target="RFC7623" sectionFormat="of" section="9.1" format="default"/>).</dd> </dl> </dd> <dt>'member':</dt> <dd>Lists the members of an ES in a service providernetwork.</t> </list></t>network.</dd> </dl> </section> <section anchor="design_data_model"title="Descriptionnumbered="true" toc="default"> <name>Description of the L2NM YANGModule">Module</name> <t>The L2NM('ietf-l2vpn-ntw',('ietf-l2vpn-ntw'; see <xreftarget="YANG_module"></xref>)target="YANG_module" format="default"/>) is used to manage L2VPNs within a service provider network. In particular, the 'ietf-l2vpn-ntw' module can be used to create, modify,deletedelete, and retrieve L2VPN services in a network controller. The module is designed to minimize the amount of customer-related information.</t> <t>The full tree diagram of the module can be generated using the "pyang" tool <xreftarget="PYANG"></xref>.target="PYANG" format="default"/>. That tree is not included here because it is too long(Section 3.3 of <xref target="RFC8340"></xref>).(<xref target="RFC8340" sectionFormat="of" section="3.3" format="default"/>). Instead, subtrees are provided for the reader's convenience.</t> <t>Note that the following subsections introduce some data nodes that enclose textual descriptions (e.g., VPN service (<xreftarget="l2_vpn_service"></xref>),target="l2_vpn_service" format="default"/>), VPN node (<xreftarget="vpn_node"></xref>),target="vpn_node" format="default"/>), or VPN network access (<xreftarget="sna"></xref>)).target="sna" format="default"/>)). Such descriptions are not intended for random end users but for network/system/software engineers that use their local context to provide and interpret such information. Therefore, no mechanism for language tagging is needed.</t> <section anchor="structure_model"title="Overallnumbered="true" toc="default"> <name>Overall Structure of theModule">Module</name> <t>The 'ietf-l2vpn-ntw' module uses two main containers: 'vpn-profiles' and 'vpn-services' (see <xreftarget="ietf-l2vpn-ntw_tree"></xref>).</t>target="ietf-l2vpn-ntw_tree" format="default"/>).</t> <t>The 'vpn-profiles' container is used by the provider to define and maintain a set of common VPN profiles that apply to VPN services (<xreftarget="vpn_profiles"></xref>).</t> <t hangText="'ethernet-segments':">Thetarget="vpn_profiles" format="default"/>).</t> <t>The 'vpn-services' container maintains the set of L2VPN services managed in the service provider network. The module allows creating a new L2VPN service by adding a new instance of 'vpn-service'. The 'vpn-service' is the data structure that abstracts the VPN service (<xreftarget="l2_vpn_service"></xref>).</t>target="l2_vpn_service" format="default"/>).</t> <figurealign="center" anchor="ietf-l2vpn-ntw_tree" title="Overallanchor="ietf-l2vpn-ntw_tree"> <name>Overall L2NM TreeStructure"> <artwork align="center"><![CDATA[module:Structure</name> <sourcecode type="yangtree"><![CDATA[module: ietf-l2vpn-ntw +--rw l2vpn-ntw +--rw vpn-profiles | ... +--rw vpn-services +--rw vpn-service* [vpn-id] ... +--rw vpn-nodes +--rw vpn-node* [vpn-node-id] ... +--rw vpn-network-accesses +--rw vpn-network-access* [id] ...]]></artwork>]]></sourcecode> </figure><t></t><t/> </section> <section anchor="vpn_profiles"title="VPN Profiles">numbered="true" toc="default"> <name>VPN Profiles</name> <t>The 'vpn-profiles' container (<xreftarget="vpn_profiles_tree"></xref>)target="vpn_profiles_tree" format="default"/>) is used by a VPN service provider to define and maintain a set of VPN profiles <xreftarget="RFC9181"></xref>target="RFC9181" format="default"/> that apply to one or several VPN services.</t><t><figure align="center" anchor="vpn_profiles_tree" title="VPN<figure anchor="vpn_profiles_tree"> <name>VPN Profiles SubtreeStructure"> <artwork align="center"><![CDATA[Structure</name> <sourcecode type="yangtree"><![CDATA[ +--rw l2vpn-ntw +--rw vpn-profiles | +--rw valid-provider-identifiers | +--rw external-connectivity-identifier* [id] | | {external-connectivity}? | | +--rw id string | +--rw encryption-profile-identifier* [id] | | +--rw id string | +--rw qos-profile-identifier* [id] | | +--rw id string | +--rw bfd-profile-identifier* [id] | | +--rw id string | +--rw forwarding-profile-identifier* [id] | | +--rw id string | +--rw routing-profile-identifier* [id] | +--rw id string +--rw vpn-services ...]]></artwork> </figure></t>]]></sourcecode> </figure> <t>The exact definition of these profiles is local to each VPN service provider. The model only includes an identifier for these profiles in order to ease identifying and binding local policies when building a VPN service. As shown in <xreftarget="vpn_profiles_tree"></xref>,target="vpn_profiles_tree" format="default"/>, the following identifiers can beincluded:<list style="hanging"> <t hangText="'external-connectivity-identifier':">Thisincluded:</t> <dl newline="false" spacing="normal"> <dt>'external-connectivity-identifier':</dt> <dd>This identifier refers to a profile that defines the external connectivity provided to a VPN service (or a subset of VPN sites). External connectivity may be access to the Internet or restrictedconnectivity,connectivity such as access to a public/privatecloud.</t> <t hangText="'encryption-profile-identifier':">Ancloud.</dd> <dt>'encryption-profile-identifier':</dt> <dd>An encryption profile refers to a set of policies related to the encryption schemes and setup that can be applied when building and offering a VPNservice.</t> <t hangText="'qos-profile-identifier':">Aservice.</dd> <dt>'qos-profile-identifier':</dt> <dd>A Quality of Service (QoS) profile refers toasa set ofpolicies,policies such as classification, marking, and actions (e.g., <xreftarget="RFC3644"></xref>).</t> <t hangText="'bfd-profile-identifier':">Atarget="RFC3644" format="default"/>).</dd> <dt>'bfd-profile-identifier':</dt> <dd>A Bidirectional Forwarding Detection (BFD) profile refers to a set of BFD policies <xreftarget="RFC5880"></xref>target="RFC5880" format="default"/> that can be invoked when building a VPNservice.</t> <t hangText="'forwarding-profile-identifier':">Aservice.</dd> <dt>'forwarding-profile-identifier':</dt> <dd>A forwarding profile refers to the policies that apply to the forwarding of packets conveyed within a VPN. Such policies mayconsist,consist of, for example,ofapplyingACLs.</t> <t hangText="'routing-profile-identifier':">AACLs.</dd> <dt>'routing-profile-identifier':</dt> <dd>A routing profile refers to a set of routing policies that will be invoked (e.g., BGP policies) when delivering the VPNservice.</t> </list></t> <t></t>service.</dd> </dl> <t/> </section> <section anchor="l2_vpn_service"title="VPN Services">numbered="true" toc="default"> <name>VPN Services</name> <t>The 'vpn-service' is the data structure that abstracts an L2VPN service in the service provider network. Each 'vpn-service' is uniquely identified by an identifier: 'vpn-id'. Such a 'vpn-id' is only meaningful locally within the network controller. The subtree of the 'vpn-services' is shown in <xreftarget="vpn-service_tree"></xref>.</t>target="vpn-service_tree" format="default"/>.</t> <figurealign="center" anchor="vpn-service_tree" title="VPNanchor="vpn-service_tree"> <name>VPN ServicesSubtree"> <artwork align="center"><![CDATA[Subtree</name> <sourcecode type="yangtree"><![CDATA[ +--rw vpn-services +--rw vpn-service* [vpn-id] +--rw vpn-id vpn-common:vpn-id +--rw vpn-name? string +--rw vpn-description? string +--rw customer-name? string +--rw parent-service-id? vpn-common:vpn-id +--rw vpn-type? identityref +--rw vpn-service-topology? identityref +--rw bgp-ad-enabled? boolean +--rw signaling-type? identityref +--rw global-parameters-profiles | ... +--rw underlay-transport | +--rw (type)? | +--:(abstract) | | +--rw transport-instance-id? string | | +--rw instance-type? identityref | +--:(protocol) | +--rw protocol* identityref +--rw status | +--rw admin-status | | +--rw status? identityref | | +--rw last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref | +--ro last-change? yang:date-and-time +--rw vpn-nodes ...]]></artwork>]]></sourcecode> </figure> <t>The descriptions of the VPN service data nodes that are depicted in <xreftarget="vpn-service_tree"></xref>target="vpn-service_tree" format="default"/> are as follows:<list style="hanging"> <t hangText="'vpn-id':">An</t> <dl newline="false" spacing="normal"> <dt>'vpn-id':</dt> <dd>An identifier that is used to uniquely identify the L2VPN service within the L2NMscope.</t> <t hangText="'vpn-name':">Associatesscope.</dd> <dt>'vpn-name':</dt> <dd>Associates a name with the service in order to facilitate the identification of theservice.</t> <t hangText="'vpn-description':">Includesservice.</dd> <dt>'vpn-description':</dt> <dd> <t>Includes a textual description of the service.<vspace blankLines="1" />The</t> <t>The internal structure of a VPN description is local to each VPN service provider.</t><t hangText="'customer-name':">Indicates</dd> <dt>'customer-name':</dt> <dd>Indicates the name of the customer who ordered theservice.</t> <t hangText="'parent-service-id':">Refersservice.</dd> <dt>'parent-service-id':</dt> <dd>Refers to an identifier of the parent service (e.g., the L2SM, IETF network slice, and VPN+) that triggered the creation of the L2VPN service. This identifier is used to easily correlate the (network) service as built in the network with a service order. A controller can use that correlation to enrich or populate some fields (e.g., description fields) as a function of localdeployments.</t> <t hangText="'vpn-type':">Indicatesdeployments.</dd> <dt>'vpn-type':</dt> <dd> <t>Indicates the L2VPN type. The following types, defined in <xreftarget="RFC9181"></xref>,target="RFC9181" format="default"/>, can be used for theL2NM:<list style="hanging"> <t hangText="'vpls':">VirtualL2NM:</t> <dl newline="false" spacing="normal"> <dt>'vpls':</dt> <dd>Virtual Private LAN Service (VPLS) as defined in <xreftarget="RFC4761"></xref>target="RFC4761" format="default"/> or <xreftarget="RFC4762"></xref>.target="RFC4762" format="default"/>. This type is also used for hierarchical VPLS (H-VPLS)(Section 10 of <xref target="RFC4762"></xref>).</t> <t hangText="'vpws':">Virtual(<xref target="RFC4762" sectionFormat="of" section="10" format="default"/>).</dd> <dt>'vpws':</dt> <dd>Virtual Private Wire Service (VPWS) as defined inSection 3.1.1 of<xreftarget="RFC4664"></xref>.</t> <t hangText="'vpws-evpn':">VPWStarget="RFC4664" sectionFormat="of" section="3.1.1" format="default"/>.</dd> <dt>'vpws-evpn':</dt> <dd>VPWS EVPNs as defined in <xreftarget="RFC8214"></xref>.</t> <t hangText="'pbb-evpn':">Providertarget="RFC8214" format="default"/>.</dd> <dt>'pbb-evpn':</dt> <dd>Provider Backbone Bridging (PBB) EVPNs as defined in <xreftarget="RFC7623"></xref>.</t> <t hangText="'mpls-evpn':">MPLS-basedtarget="RFC7623" format="default"/>.</dd> <dt>'mpls-evpn':</dt> <dd>MPLS-based EVPNs <xreftarget="RFC7432"></xref>.</t> <t hangText="'vxlan-evpn':">VXLAN basedtarget="RFC7432" format="default"/>.</dd> <dt>'vxlan-evpn':</dt> <dd>VXLAN-based EVPNs <xreftarget="RFC8365"></xref>.</t> </list>Thetarget="RFC8365" format="default"/>.</dd> </dl> <t>The type is used as a condition for the presence of some data nodes in the L2NM.</t><t hangText="'vpn-service-topology':">Indicates</dd> <dt>'vpn-service-topology':</dt> <dd>Indicates the network topology for the service: hub-spoke, any-to-any, or custom. These types are defined in <xreftarget="RFC9181"></xref>.</t> <t hangText="'bgp-ad-enabled':">Controlstarget="RFC9181" format="default"/>.</dd> <dt>'bgp-ad-enabled':</dt> <dd>Controls whether BGP auto-discovery is enabled. If so, additional data nodes are included (<xreftarget="bgpad"></xref>).</t> <t hangText="'signaling-type':">Indicatestarget="bgpad" format="default"/>).</dd> <dt>'signaling-type':</dt> <dd> <t>Indicates the signaling that is used for setting up pseudowires. Signaling type values are taken from <xreftarget="RFC9181"></xref>.target="RFC9181" format="default"/>. The following signaling options aresupported:<list style="hanging"> <t hangText="'bgp-signaling':">Thesupported:</t> <dl newline="false" spacing="normal"> <dt>'bgp-signaling':</dt> <dd> <t>The L2NM supports two flavors of BGP-signaled L2VPNs:<list style="hanging"> <t hangText="'l2vpn-bgp':">The</t> <dl newline="false" spacing="normal"> <dt>'l2vpn-bgp':</dt> <dd>The service is a Multipoint VPLS that uses a BGP control plane as described in <xreftarget="RFC4761"></xref>target="RFC4761" format="default"/> and <xreftarget="RFC6624"></xref>.</t> <t hangText="'evpn-bgp':">Thetarget="RFC6624" format="default"/>.</dd> <dt>'evpn-bgp':</dt> <dd>The service is a Multipoint VPLS that usesalsoa BGP controlplane,plane but also includes the additional EVPN features and related parameters as described in <xreftarget="RFC7432"></xref>target="RFC7432" format="default"/> and <xreftarget="RFC7209"></xref>.</t> </list></t> <t hangText="'ldp-signaling':">Atarget="RFC7209" format="default"/>.</dd> </dl> </dd> <dt>'ldp-signaling':</dt> <dd>A Multipoint VPLS that uses a mesh of LDP-signaledPseudowirespseudowires <xreftarget="RFC6074"></xref>.</t> <t hangText="'l2tp-signaling':">Thetarget="RFC6074" format="default"/>.</dd> <dt>'l2tp-signaling':</dt> <dd>The L2NM uses L2TP-signaledPseudowirespseudowires as described in <xreftarget="RFC6074"></xref>.</t> </list>Table 1target="RFC6074" format="default"/>.</dd> </dl> <t><xref target="options-vpn"/> summarizes the allowed signaling types for each VPN service type ('vpn-type'). See <xreftarget="signaling_options"></xref>target="signaling_options" format="default"/> for moredetails.<figure align="center"> <artwork align="center"><![CDATA[+============+================================+ | VPN Type | Signalingdetails.</t> <table anchor="options-vpn"> <name>Signaling Options| +============+================================+ | vpls | l2tp-signaling,per VPN Service Type</name> <thead> <tr> <th>VPN Type</th> <th>Signaling Options</th> </tr> </thead> <tbody> <tr> <td>vpls</td> <td>l2tp-signaling, ldp-signaling,| | |bgp-signaling(l2vpn-bgp) | +------------+--------------------------------+ | vpws | l2tp-signaling,(l2vpn-bgp)</td> </tr> <tr> <td>vpws</td> <td>l2tp-signaling, ldp-signaling,| | |bgp-signaling (l2vpn-bgp)| +------------+--------------------------------+ | vpws-evpn | bgp-signaling (evpn-bgp) | +------------+--------------------------------+ | pbb-evpn | bgp-signaling (evpn-bgp) | +------------+--------------------------------+ | mpls-evpn | bgp-signaling (evpn-bgp) | +------------+--------------------------------+ | vxlan-evpn | bgp-signaling (evpn-bgp) | +------------+--------------------------------+ Table 1: Signaling Options per VPN Service Type]]></artwork> </figure></t> <t hangText="'global-parameters-profiles':">Defines</td> </tr> <tr> <td>vpws-evpn</td> <td>bgp-signaling (evpn-bgp)</td> </tr> <tr> <td>pbb-evpn</td> <td>bgp-signaling (evpn-bgp)</td> </tr> <tr> <td>mpls-evpn</td> <td>bgp-signaling (evpn-bgp)</td> </tr> <tr> <td>vxlan-evpn</td> <td>bgp-signaling (evpn-bgp)</td> </tr> </tbody> </table> </dd> <dt>'global-parameters-profiles':</dt> <dd> <t>Defines reusable parameters for the same L2VPN service.<vspace blankLines="1" />More</t> <t>More details are provided in <xreftarget="profile"></xref>.</t> <t hangText="'underlay-transport':">Describestarget="profile" 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. This preference is especially useful in networks with multiple domains and Network-to-Network Interface (NNI) types. The underlay transport can be expressed as an abstract transport instance (e.g., an identifier of a VPN+ instance, a virtual network identifier, or a network slice name) or as an ordered list of the actual protocols to be enabled in the network.<vspace blankLines="1" />A</t> <t>A rich set of protocol identifiers that can be used to refer to an underlay transport (or how such an underlay is set up) are defined in <xreftarget="RFC9181"></xref>. <vspace blankLines="1" />Thetarget="RFC9181" format="default"/>. </t> <t>The model defined inSection 6.3.2 of<xreftarget="I-D.ietf-teas-te-service-mapping-yang"></xref>target="I-D.ietf-teas-te-service-mapping-yang" format="default" sectionFormat="of" section="6.3.2"/> may be used if specific protection and availability requirements are needed between PEs.</t><t hangText="'status':">Used</dd> <dt>'status':</dt> <dd> <t>Used to track the overall status of a given VPN service. Both operational and administrative status are maintained together with a timestamp. For example, a service can becreated,created but not put intoeffect.<vspace blankLines="1" />Administrativeeffect.</t> <t>Administrative and operational status can be used as a trigger to detect service anomalies. For example, a service that is declared at the service layer as being created but still inactive at the network layer is an indication that network provisioning actions are needed to align the observed service status with the expected service status.</t><t hangText="'vpn-node':">An</dd> <dt>'vpn-node':</dt> <dd> <t>An abstraction that represents a set of policies applied to a network node and belonging to a single 'vpn-service'. An L2VPN service is typically built by adding instances of 'vpn-node' to the 'vpn-nodes' container.<vspace blankLines="1" />A</t> <t>A 'vpn-node' contains 'vpn-network-accesses', which are the interfaces attached to the VPN by which the customer traffic is received. Therefore, the customer sites are connected to the'vpn-network-accesses'.<vspace blankLines="1" />Note'vpn-network-accesses'.</t> <t>Note that, as this is a network data model, the information about customers sites is not required in the model. Such information is rather relevant in the L2SM. Whether that information is included in the L2NM, e.g., to populate the various 'description' datanodesnodes, is implementation specific.<vspace blankLines="1" />More</t> <t>More details are provided in <xreftarget="vpn_node"></xref>.</t> </list></t> <t></t>target="vpn_node" format="default"/>.</t> </dd> </dl> <t/> </section> <section anchor="profile"title="Globalnumbered="true" toc="default"> <name>Global ParametersProfiles">Profiles</name> <t>The 'global-parameters-profile' defines reusable parameters for the same L2VPN service instance ('vpn-service'). Global parameters profiles are defined at the VPN service level, activated at the VPN node level, and then an activated VPN profile may be used at the VPN network access level. Each VPN instance profile is identified by 'profile-id'. Some of the data nodes can be adjusted at the VPN node or VPN network access levels. These adjusted values take precedence over the global values. The subtree of 'global-parameters-profile' is depicted in <xreftarget="global_param_prof_tree"></xref>.</t>target="global_param_prof_tree" format="default"/>.</t> <figurealign="center" anchor="global_param_prof_tree" title="Globalanchor="global_param_prof_tree"> <name>Global Parameters ProfilesSubtree"> <artwork align="center"><![CDATA[Subtree</name> <sourcecode type="yangtree"><![CDATA[ ... +--rw vpn-services +--rw vpn-service* [vpn-id] ... +--rw global-parameters-profiles | +--rw global-parameters-profile* [profile-id] | +--rw profile-id string | +--rw (rd-choice)? | | +--:(directly-assigned) | | | +--rw rd? | | | rt-types:route-distinguisher | | +--:(directly-assigned-suffix) | | | +--rw rd-suffix? uint16 | | +--:(auto-assigned) | | | +--rw rd-auto | | | +--rw (auto-mode)? | | | | +--:(from-pool) | | | | | +--rw rd-pool-name? string | | | | +--:(full-auto) | | | | +--rw auto? empty | | | +--ro auto-assigned-rd? | | | rt-types:route-distinguisher | | +--:(auto-assigned-suffix) | | | +--rw rd-auto-suffix | | | +--rw (auto-mode)? | | | | +--:(from-pool) | | | | | +--rw rd-pool-name? string | | | | +--:(full-auto) | | | | +--rw auto? empty | | | +--ro auto-assigned-rd-suffix? uint16 | | +--:(no-rd) | | +--rw no-rd? empty | +--rw vpn-target* [id] | | +--rw id uint8 | | +--rw route-targets* [route-target] | | | +--rw route-target rt-types:route-target | | +--rw route-target-type | | rt-types:route-target-type | +--rw vpn-policies | | +--rw import-policy? string | | +--rw export-policy? string | +--rw local-autonomous-system? inet:as-number | +--rw svc-mtu? uint32 | +--rw ce-vlan-preservation? boolean | +--rw ce-vlan-cos-preservation? boolean | +--rw control-word-negotiation? boolean | +--rw mac-policies | | +--rw mac-addr-limit | | | +--rw limit-number? uint16 | | | +--rw time-interval? uint32 | | | +--rw action? identityref | | +--rw mac-loop-prevention | | +--rw window? uint32 | | +--rw frequency? uint32 | | +--rw retry-timer? uint32 | | +--rw protection-type? identityref | +--rw multicast {vpn-common:multicast}? | +--rw enabled? boolean | +--rw customer-tree-flavors | +--rw tree-flavor* identityref ...]]></artwork>]]></sourcecode> </figure> <t>The description of the global parameters profile is as follows:</t><t><list style="hanging"> <t hangText="'profile-id':">Uniquely<dl newline="false" spacing="normal"> <dt>'profile-id':</dt> <dd>Uniquely identifies a global parameter profile in the context of an L2VPNservice.</t> <t hangText="'rd':">Asservice.</dd> <dt>'rd':</dt> <dd> <t>As defined in <xreftarget="RFC9181"></xref>,target="RFC9181" format="default"/>, these RD assignment modes are supported: direct assignment, automatic assignment from a given pool, full automatic assignment, and no assignment.<vspace blankLines="1" />Also,</t> <t>Also, the module accommodates deployments where only the Assigned Number subfield of RDs is assigned from a pool while the Administrator subfield is set to, e.g., the Router ID that is assigned to a VPN node. The module supports these modesfor managingto manage the Assigned Number subfield: explicit assignment, auto-assignment from a pool, and full auto-assignment.</t><t hangText="'vpn-targets':">Specifies</dd> <dt>'vpn-targets':</dt> <dd>Specifies RT import/export rules for the VPNservice.</t> <t hangText="'local-autonomous-system':">Indicatesservice.</dd> <dt>'local-autonomous-system':</dt> <dd>Indicates the Autonomous System Number (ASN) that is configured for the VPN node. The ASN can be used to auto-derive some other attributes such as RDs or Ethernet Segment Identifiers(ESIs).</t> <t hangText="'svc-mtu':">Is(ESIs).</dd> <dt>'svc-mtu':</dt> <dd>Is the service MTU for an L2VPN service (i.e., a Layer 2 MTU including an L2 frame header/trailer). It is also known as the maximum transmission unit or maximum frame size. It is expressed inbytes.</t> <t hangText="'ce-vlan-preservation':">Isbytes.</dd> <dt>'ce-vlan-preservation':</dt> <dd>Is set to preserve the Customer Edge VLAN (CE VLAN) IDs(CE-VLAN IDs)from ingress to egress, i.e.,CE-VLAN tagCE VLAN tags of the egress frame are identical to those of the ingress frame that yielded this egress service frame. If all-to-one bundling within a site is enabled, then preservation applies to all ingress service frames. If all-to-one bundling is disabled, then preservation applies to tagged Ingress service frames havingCE-VLANCE VLAN ID 1 through4094.</t> <t hangText="'ce-vlan-cos-preservation':">Controls4094.</dd> <dt>'ce-vlan-cos-preservation':</dt> <dd>Controls the CE VLANCoSClass of Service (CoS) preservation. When set, Priority Code Point (PCP) bits in theCE-VLANCE VLAN tag of the egress frame are identical to those of the ingress frame that yielded this egress serviceframe.</t> <t hangText="'control-word-negotiation':">Controlsframe.</dd> <dt>'control-word-negotiation':</dt> <dd>Controls whether control-word negotiation is enabled (if set to true) or not (if set to false). Refer toSection 7 of<xreftarget="RFC8077"></xref>target="RFC8077" sectionFormat="of" section="7" format="default"/> for moredetails.</t> <t hangText="'mac-policies':">Includesdetails.</dd> <dt>'mac-policies':</dt> <dd> <t>Includes a set of MAC policies that apply to theservice:<list style="hanging"> <t hangText="'mac-addr-limit':">Isservice:</t> <dl newline="false" spacing="normal"> <dt>'mac-addr-limit':</dt> <dd> <t>Is a container of MAC address limit configuration. It includes the following data nodes:<list style="hanging"> <t hangText="'limit-number':">Maximum</t> <dl newline="false" spacing="normal"> <dt>'limit-number':</dt> <dd>Maximum number of MAC addresses learned from the customer for a single serviceinstance.</t> <t hangText="'time-interval':">Theinstance.</dd> <dt>'time-interval':</dt> <dd>The aging time of the MACaddress.</t> <t hangText="'action':">Specifiesaddress.</dd> <dt>'action':</dt> <dd>Specifies the action when the upper limit is exceeded: drop the packet, flood the packet, or simply send a warningmessage.</t> </list></t> <t hangText="'mac-loop-prevention':">Containermessage.</dd> </dl> </dd> <dt>'mac-loop-prevention':</dt> <dd> <t>Container for MAC loopprevention.<list style="hanging"> <t hangText="'window':">Theprevention.</t> <dl newline="false" spacing="normal"> <dt>'window':</dt> <dd>The time interval over which a MAC mobility event is detected andchecked.</t> <t hangText="'frequency':">Thechecked.</dd> <dt>'frequency':</dt> <dd>The number of times to detect MAC duplication, where a 'duplicate MAC address' situation has occurred within the 'window' time interval, and the duplicate MAC address has been added to a list of duplicate MACaddresses.</t> <t hangText="'retry-timer':">Theaddresses.</dd> <dt>'retry-timer':</dt> <dd>The retry timer. When the retry timer expires, the duplicate MAC address will be flushed from theMAC-VRF.</t> <t hangText="'protection-type':">ItMAC-VRF.</dd> <dt>'protection-type':</dt> <dd>It defines the loop prevention type (e.g.,shut).</t> </list></t> </list></t> <t hangText="'multicast':">Controlsshut).</dd> </dl> </dd> </dl> </dd> <dt>'multicast':</dt> <dd>Controls whether multicast is allowed in theservice.</t> </list></t>service.</dd> </dl> </section> <section anchor="vpn_node"title="VPN Nodes">numbered="true" toc="default"> <name>VPN Nodes</name> <t>The 'vpn-node' (<xreftarget="vpn-node_tree"></xref>)target="vpn-node_tree" format="default"/>) is an abstraction that represents a set ofpolicies/configurationspolicies applied to a network nodeandthatbelongbelongs to a single 'vpn-service'. A 'vpn-node' contains 'vpn-network-accesses', which are the interfaces involved in the creation of the VPN. The customer sites are connected to the 'vpn-network-accesses'.</t> <figurealign="right" anchor="vpn-node_tree" title="VPNanchor="vpn-node_tree"> <name>VPN NodesSubtree"> <artwork align="center"><![CDATA[Subtree</name> <sourcecode type="yangtree"><![CDATA[ +--rw l2vpn-ntw +--rw vpn-profiles | ... +--rw vpn-services +--rw vpn-service* [vpn-id] ... +--rw vpn-nodes +--rw vpn-node* [vpn-node-id] +--rw vpn-node-id vpn-common:vpn-id +--rw description? string +--rw ne-id? string +--rw role? identityref +--rw router-id? rt-types:router-id +--rw active-global-parameters-profiles | +--rw global-parameters-profile* [profile-id] | +--rw profile-id leafref | +--rw local-autonomous-system? | | inet:as-number | +--rw svc-mtu? uint32 | +--rw ce-vlan-preservation? boolean | +--rw ce-vlan-cos-preservation? boolean | +--rw control-word-negotiation? boolean | +--rw mac-policies | | +--rw mac-addr-limit | | | +--rw limit-number? uint16 | | | +--rw time-interval? uint32 | | | +--rw action? identityref | | +--rw mac-loop-prevention | | +--rw window? uint32 | | +--rw frequency? uint32 | | +--rw retry-timer? uint32 | | +--rw protection-type? identityref | +--rw multicast {vpn-common:multicast}? | +--rw enabled? boolean | +--rw customer-tree-flavors | +--rw tree-flavor* identityref +--rw status | ... +--rw bgp-auto-discovery | ... +--rw signaling-option | ... +--rw vpn-network-accesses ...]]></artwork>]]></sourcecode> </figure> <t>The descriptions of VPN node data nodes are asfollows:<list style="hanging"> <t hangText="'vpn-node-id':">Usedfollows:</t> <dl newline="false" spacing="normal"> <dt>'vpn-node-id':</dt> <dd>Used to uniquely identify a node that enables a VPN networkaccess.</t> <t hangText="'description':">Providesaccess.</dd> <dt>'description':</dt> <dd>Provides a textual description of the VPNnode.</t> <t hangText="'ne-id':">Includesnode.</dd> <dt>'ne-id':</dt> <dd>Includes an identifier of the network element where the VPN node isdeployed.</t> <t hangText="'role':">Indicatesdeployed.</dd> <dt>'role':</dt> <dd>Indicates the role of the VPN instance profile in the VPN. Role values are defined in <xreftarget="RFC9181"></xref>target="RFC9181" format="default"/> (e.g., 'any-to-any-role', 'spoke-role','hub-role').</t> <t hangText="'router-id':">Indicatesand 'hub-role').</dd> <dt>'router-id':</dt> <dd>Indicates a 32-bit number that is used to uniquely identify a router within anAutonomous System (AS).</t> <t hangText="'active-global-parameters-profiles':">ListsAS.</dd> <dt>'active-global-parameters-profiles':</dt> <dd> <t>Lists the set of active global VPNparametersparameter profiles for this VPN node. Concretely, one or more global profiles that are defined at the VPN service level (i.e., under 'l2vpn-ntw/vpn-services/vpn-service' level) can be activated at the VPN node level; each of these profiles is uniquely identified by means of 'profile-id'. The structure of 'active-global-parameters-profiles' uses the same data nodes as <xreftarget="profile"></xref> excepttarget="profile" format="default"/> with the exception of the data nodes related to RD andRT related data nodes.<vspace blankLines="1" />ValuesRT.</t> <t>Values defined in 'active-global-parameters-profiles'overridesoverride the values defined in the VPN service level.</t><t hangText="'status':">Tracks</dd> <dt>'status':</dt> <dd>Tracks the status of a node involved in a VPN service. Both operational and administrative status are maintained. A mismatch between the administrative status vs. the operational status can be used as a trigger to detectanomalies.</t> <t hangText="'bgp-auto-discovery':">See <xref target="bgpad"></xref>.</t> <t hangText="'signaling-option':">See <xref target="signaling_options"></xref>.</t> <t hangText="'vpn-network-accesses':">Representsanomalies.</dd> <dt>'bgp-auto-discovery':</dt> <dd>See <xref target="bgpad" format="default"/>.</dd> <dt>'signaling-option':</dt> <dd>See <xref target="signaling_options" format="default"/>.</dd> <dt>'vpn-network-accesses':</dt> <dd> <t>Represents the point to which sites are connected.<vspace blankLines="1" />Note</t> <t>Note that, unlike the L2SM, the L2NM does not need to model the customersite --site; only the points that receive traffic from the site are covered (i.e., the PE side of Provider Edge to Customer Edge (PE-CE) connections). Hence, the VPN network access contains the connectivity information between the provider's network and the customer premises. The VPN profiles ('vpn-profiles') have a set of routing policies that can be applied during the service creation.<vspace blankLines="1" />See</t> <t>See <xreftarget="sna"></xref>target="sna" format="default"/> for more details.</t></list></t></dd> </dl> <section anchor="bgpad"title="BGP Auto-Discovery">numbered="true" toc="default"> <name>BGP Auto-Discovery</name> <t>The 'bgp-auto-discovery' container (<xreftarget="bgpad-tree"></xref>)target="bgpad-tree" format="default"/>) includes the required information for the activation of BGP auto-discovery <xreftarget="RFC4761"></xref><xref target="RFC6624"></xref>.</t> <t><figure align="right" anchor="bgpad-tree" title="BGPtarget="RFC4761" format="default"/><xref target="RFC6624" format="default"/>.</t> <figure anchor="bgpad-tree"> <name>BGP Auto-DiscoverySubtree"> <artwork align="center"><![CDATA[Subtree</name> <sourcecode type="yangtree"><![CDATA[ +--rw l2vpn-ntw +--rw vpn-profiles | ... +--rw vpn-services +--rw vpn-service* [vpn-id] ... +--rw vpn-nodes +--rw vpn-node* [vpn-node-id] ... +--rw bgp-auto-discovery | +--rw (bgp-type)? | | +--:(l2vpn-bgp) | | | +--rw vpn-id? | | | vpn-common:vpn-id | | +--:(evpn-bgp) | | +--rw evpn-type? leafref | | +--rw auto-rt-enable? boolean | | +--ro auto-route-target? | | rt-types:route-target | +--rw (rd-choice)? | | +--:(directly-assigned) | | | +--rw rd? | | | rt-types:route-distinguisher | | +--:(directly-assigned-suffix) | | | +--rw rd-suffix? uint16 | | +--:(auto-assigned) | | | +--rw rd-auto | | | +--rw (auto-mode)? | | | | +--:(from-pool) | | | | | +--rw rd-pool-name? string | | | | +--:(full-auto) | | | | +--rw auto? empty | | | +--ro auto-assigned-rd? | | | rt-types:route-distinguisher | | +--:(auto-assigned-suffix) | | | +--rw rd-auto-suffix | | | +--rw (auto-mode)? | | | | +--:(from-pool) | | | | | +--rw rd-pool-name? string | | | | +--:(full-auto) | | | | +--rw auto? empty | | | +--ro auto-assigned-rd-suffix? uint16 | | +--:(no-rd) | | +--rw no-rd? empty | +--rw vpn-target* [id] | | +--rw id uint8 | | +--rw route-targets* [route-target] | | | +--rw route-target rt-types:route-target | | +--rw route-target-type | | rt-types:route-target-type | +--rw vpn-policies | +--rw import-policy? string | +--rw export-policy? string +--rw signaling-option | ... +--rw vpn-network-accesses ...]]></artwork> </figure></t>]]></sourcecode> </figure> <t>As discussed inSection 1 of<xreftarget="RFC6624"></xref>,target="RFC6624" sectionFormat="of" section="1" format="default"/>, allofBGP-based methods include the notion of a VPN identifier that serves to unify components of a given VPN and the concept ofauto-discovery;auto-discovery, hence the support of the data node 'vpn-id'.</t> <t>For the particular case of EVPN, the L2NM supports RT auto-derivation based on the Ethernet Tag ID specified inSection 7.10.1 of<xreftarget="RFC7432"></xref>.target="RFC7432" sectionFormat="of" section="7.10.1" format="default"/>. A VPN service provider can enable/disable this functionality by means of 'auto-rt-enable'. The assigned RT can be retrieved using 'auto-route-target'.</t> <t>For all BGP-based L2VPN flavors, other data nodes such as RD and RT are used. These data nodes have the same structure as the one discussed in <xreftarget="profile"></xref>.</t>target="profile" format="default"/>.</t> </section> <section anchor="signaling_options"title="Signaling Options">numbered="true" toc="default"> <name>Signaling Options</name> <t>The 'signaling-option' container (<xreftarget="so"></xref>)target="so" format="default"/>) defines a set of data nodes for a given signaling protocol that is used for an L2VPN service. As discussed in <xreftarget="l2_vpn_service"></xref>,target="l2_vpn_service" format="default"/>, several signaling options to exchange membership information between PEs of an L2VPN are supported. The signaling type to be used for an L2VPN service is controlled at the VPN service level by means of 'signaling-type'.</t><t><figure align="center" anchor="so" title="Signaling<figure anchor="so"> <name>Signaling Option OverallSubtree"> <artwork align="center"><![CDATA[...Subtree</name> <sourcecode type="yangtree"><![CDATA[... +--rw vpn-nodes +--rw vpn-node* [vpn-node-id] ... +--rw signaling-option | +--rw advertise-mtu? boolean | +--rw mtu-allow-mismatch? boolean | +--rw signaling-type? leafref | +--rw (signaling-option)? | +--:(bgp) | | ... | +--:(ldp-or-l2tp) | +--rw ldp-or-l2tp | ... | +--rw (ldp-or-l2tp)? | +--:(ldp) | | ... | +--:(l2tp) | ...]]></artwork> </figure></t>]]></sourcecode> </figure> <t>The following signaling data nodes aresupported:<list style="hanging"> <t hangText="'advertise-mtu':">Controlssupported:</t> <dl newline="false" spacing="normal"> <dt>'advertise-mtu':</dt> <dd>Controls whether MTU is advertised when setting a pseudowire (e.g.,Section 4.3 of<xreftarget="RFC4667"></xref>, Section 5.1 of <xref target="RFC6624"></xref>, or Section 6.1 of <xref target="RFC4762"></xref>).</t> <t hangText="'mtu-allow-mismatch':">Whentarget="RFC4667" sectionFormat="of" section="4.3" format="default"/>, <xref target="RFC6624" sectionFormat="of" section="5.1" format="default"/>, or <xref target="RFC4762" sectionFormat="of" section="6.1" format="default"/>).</dd> <dt>'mtu-allow-mismatch':</dt> <dd>When set to true, it allows an MTU mismatch for a pseudowire (see, e.g.,Section 4.3 of<xreftarget="RFC4667"></xref>).</t> <t hangText="'signaling-type':">Indicatestarget="RFC4667" sectionFormat="of" section="4.3" format="default"/>).</dd> <dt>'signaling-type':</dt> <dd>Indicates the signaling type. This type inherits the value of 'signaling-type' defined at the service level (<xreftarget="l2_vpn_service"></xref>).</t> <t hangText="'bgp':">Istarget="l2_vpn_service" format="default"/>).</dd> <dt>'bgp':</dt> <dd>Is provided when BGP is used for L2VPN signaling. Refer to <xreftarget="bgp"></xref>target="bgp" format="default"/> for moredetails.</t> <t hangText="'ldp':">Thedetails.</dd> <dt>'ldp':</dt> <dd>The model supports the configuration of the parameters that are discussed inSection 6 of<xreftarget="RFC4762"></xref>.target="RFC4762" sectionFormat="of" section="6" format="default"/>. Refer to <xreftarget="ldp"></xref>target="ldp" format="default"/> for moredetails.</t> <t hangText="'l2tp':">Thedetails.</dd> <dt>'l2tp':</dt> <dd>The model supports the configuration of the parameters that are discussed inSection 4 of<xreftarget="RFC4667"></xref>.target="RFC4667" section="4" sectionFormat="of" format="default"/>. Refer to <xreftarget="l2tp"></xref>target="l2tp" format="default"/> for moredetails.</t> </list></t>details.</dd> </dl> <t>Note that LDP and L2TP choices are bundled ("ldp-or-l2tp") because they share a set of common parameters that are further detailed in Sections <xref format="counter"target="ldp"></xref>target="ldp"/> and <xref format="counter"target="l2tp"></xref>.</t>target="l2tp"/>.</t> <section anchor="bgp"title="BGP">numbered="true" toc="default"> <name>BGP</name> <t>The structure of the BGP-related data nodes is provided in <xreftarget="so-bgp"></xref>.</t> <t><figure align="center" anchor="so-bgp" title="Signalingtarget="so-bgp" format="default"/>.</t> <figure anchor="so-bgp"> <name>Signaling Option Subtree(BGP)"> <artwork align="center"><![CDATA[(BGP)</name> <sourcecode type="yangtree"><![CDATA[ ... | +--rw (signaling-option)? | ... | +--:(bgp) | | +--rw (bgp-type)? | | +--:(l2vpn-bgp) | | | +--rw ce-range? uint16 | | | +--rw pw-encapsulation-type? | | | | identityref | | | +--rw vpls-instance | | | +--rw vpls-edge-id? uint16 | | | +--rw vpls-edge-id-range? uint16 | | +--:(evpn-bgp) | | +--rw evpn-type? leafref | | +--rw service-interface-type? | | | identityref | | +--rw evpn-policies | | +--rw mac-learning-mode? | | | identityref | | +--rw ingress-replication? | | | boolean | | +--rw p2mp-replication? | | | boolean | | +--rw arp-proxy {vpn-common:ipv4}? | | | +--rw enable? boolean | | | +--rw arp-suppression? | | | | boolean | | | +--rw ip-mobility-threshold? | | | | uint16 | | | +--rw duplicate-ip-detection-interval? | | | uint16 | | +--rw nd-proxy {vpn-common:ipv6}? | | | +--rw enable? boolean | | | +--rw nd-suppression? | | | | boolean | | | +--rw ip-mobility-threshold? | | | | uint16 | | | +--rw duplicate-ip-detection-interval? | | | uint16 | | +--rw underlay-multicast? | | | boolean | | +--rwflood-unknown-unicast-supression?flood-unknown-unicast-suppression? | | | boolean | | +--rw vpws-vlan-aware? boolean | | +--rw bum-management | | | +--rw discard-broadcast? | | | | boolean | | | +--rw discard-unknown-multicast? | | | | boolean | | | +--rw discard-unknown-unicast? | | | boolean | | +--rw pbb | | +--rw backbone-src-mac? | | yang:mac-address | +--:(ldp-or-l2tp) |...]]></artwork> </figure></t>...]]></sourcecode> </figure> <t>Remote CEs that are entitled to connect to the same VPN should fit with the CE range ('ce-range') as discussed inSection 2.2.3 of<xreftarget="RFC6624"></xref>.target="RFC6624" sectionFormat="of" section="2.2.3" format="default"/>. 'pw-encapsulation-type' is used to control the pseudowire encapsulation type(Section 3 of <xref target="RFC6624"></xref>).(<xref target="RFC6624" sectionFormat="of" section="3" format="default"/>). The value of the 'pw-encapsulation-type'areis taken from the IANA-maintained "iana-bgp-l2-encaps" module (<xreftarget="iana-bgp"></xref>).</t>target="iana-bgp" format="default"/>).</t> <t>For the specific case of VPLS, the VPLS EdgeIDIdentifier (VEID, 'vpls-edge-id')ID) ('vpls-edge-id') and a VE ID range ('vpls-edge-id-range') are provided as perSection 3.2 of<xreftarget="RFC4761"></xref>.target="RFC4761" sectionFormat="of" section="3.2" format="default"/>. If different VE IDs are required (e.g., multihoming as perSection 3.5 of<xreftarget="RFC4761"></xref>),target="RFC4761" sectionFormat="of" section="3.5" format="default"/>), these IDs are configured at the VPN network access level (under 'signaling-option' in <xreftarget="sna"></xref>).</t>target="sna" format="default"/>).</t> <t>For EVPN-related L2VPNs, 'service-interface-type' indicates whether this is a VLAN-based,VLAN bundle,VLAN-aware, orVLAN-awareVLAN bundle service interface(Section 6 of <xref target="RFC7432"></xref>).(<xref target="RFC7432" sectionFormat="of" section="6" format="default"/>). Moreover, a set of policies can be provided such as the MAC address learning mode(Section 9 of <xref target="RFC7432"></xref>),(<xref target="RFC7432" sectionFormat="of" section="9" format="default"/>), ingress replication(Section 12.1 of <xref target="RFC7432"></xref>),(<xref target="RFC7432" sectionFormat="of" section="12.1" format="default"/>), the Address Resolution Protocol (ARP) andNighborNeighbor Discovery (ND) proxy(Section 10 of <xref target="RFC7432"></xref>),(<xref target="RFC7432" sectionFormat="of" section="10" format="default"/>), the processing of Broadcast,unknown unicast,Unknown Unicast, ormulticastMulticast (BUM)(Section 12 of <xref target="RFC7432"></xref>),(<xref target="RFC7432" sectionFormat="of" section="12" format="default"/>), etc.</t> </section> <section anchor="ldp"title="LDP">numbered="true" toc="default"> <name>LDP</name> <t>ThemodelL2NM supports the configuration of the parameters that are discussed inSection 6 of<xreftarget="RFC4762"></xref>.target="RFC4762" sectionFormat="of" section="6" format="default"/>. Such parameters include an Attachment Group Identifier (AGI) (a.k.a., VPLS-id), a Source Attachment Individual Identifier (SAII), a list of peers that are associated with a Target Attachment Individual Identifier (TAII), a pseudowire type, and a pseudowire description (<xreftarget="so-ldp"></xref>).target="so-ldp" format="default"/>). Unlike BGP, only Ethernet and Ethernet tagged mode are supported. The AGI, SAII, and TAII are encoded following the types defined inSection 3.4 of<xreftarget="RFC4446"></xref>.</t> <t><figure align="right" anchor="so-ldp" title="Signalingtarget="RFC4446" sectionFormat="of" section="3.4" format="default"/>.</t> <figure anchor="so-ldp"> <name>Signaling Option Subtree(LDP)"> <artwork align="center"><![CDATA[(LDP)</name> <sourcecode type="yangtree"><![CDATA[ ... | +--rw (signaling-option)? | ... | +--:(bgp) | | ... | +--:(ldp-or-l2tp) | +--rw ldp-or-l2tp | +--rw agi? | | rt-types:route-distinguisher | +--rw saii? uint32 | +--rw remote-targets* [taii] | | +--rw taii uint32 | | +--rw peer-addr inet:ip-address | +--rw (ldp-or-l2tp)? | +--:(ldp) | | +--rw t-ldp-pw-type? | | | identityref | | +--rw pw-type? identityref | | +--rw pw-description? string | | +--rw mac-addr-withdraw? boolean | | +--rw pw-peer-list* | | | [peer-addr vc-id] | | | +--rw peer-addr | | | | inet:ip-address | | | +--rw vc-id string | | | +--rw pw-priority? uint32 | | +--rw qinq | | +--rw s-tag dot1q-types:vlanid | | +--rw c-tag dot1q-types:vlanid | +--:(l2tp) | ... ...]]></artwork> </figure></t>]]></sourcecode> </figure> </section> <section anchor="l2tp"title="L2TP">numbered="true" toc="default"> <name>L2TP</name> <t>ThemodelL2NM supports the configuration of the parameters that are discussed inSection 4 of<xreftarget="RFC4667"></xref>.target="RFC4667" sectionFormat="of" section="4" format="default"/>. Such parameters include a Router ID that is used to uniquely identify a PE, a pseudowire type, an AGI, an SAII, and a list of peers that are associated with a TAII (<xreftarget="so-l2tp"></xref>).target="so-l2tp" format="default"/>). The pseudowire type ('pseudowire-type') value is taken from the IANA-maintained "iana-pseudowire-types" module (<xreftarget="iana-pw"></xref>).</t> <t><figure align="center" anchor="so-l2tp" title="Signalingtarget="iana-pw" format="default"/>).</t> <figure anchor="so-l2tp"> <name>Signaling Option Subtree(L2TP)"> <artwork align="center"><![CDATA[(L2TP)</name> <sourcecode type="yangtree"><![CDATA[ ... | +--rw (signaling-option)? | ... | +--:(bgp) | | ... | +--:(ldp-or-l2tp) | +--rw ldp-or-l2tp | +--rw agi? | | rt-types:route-distinguisher | +--rw saii? uint32 | +--rw remote-targets* [taii] | | +--rw taii uint32 | | +--rw peer-addr inet:ip-address | +--rw (ldp-or-l2tp)? | +--:(ldp) | | ... | +--:(l2tp) | +--rw router-id? | | rt-types:router-id | +--rw pseudowire-type? | identityref...]]></artwork> </figure></t>...]]></sourcecode> </figure> </section> </section> </section> <section anchor="sna"title="VPNnumbered="true" toc="default"> <name>VPN NetworkAccesses">Accesses</name> <t>A 'vpn-network-access' (<xreftarget="vpn_network_access_tree"></xref>)target="vpn_network_access_tree" format="default"/>) represents an entry point to a VPN service. In other words, this container encloses the parameters that describe the access information for the traffic that belongs to a particular L2VPN.</t> <t>A 'vpn-network-access' includes information such as the connection on which the access is defined, the specific Layer 2 service requirements, etc.</t><t><figure align="right" anchor="vpn_network_access_tree" title="VPN<figure anchor="vpn_network_access_tree"> <name>VPN Network AccessSubtree"> <artwork align="center"><![CDATA[Subtree</name> <sourcecode type="yangtree"><![CDATA[ ... +--rw vpn-nodes +--rw vpn-node* [vpn-node-id] ... +--rw vpn-network-accesses +--rw vpn-network-access* [id] +--rw id vpn-common:vpn-id +--rw description? string +--rw interface-id? string +--rw active-vpn-node-profile? leafref +--rw status | ... +--rw connection | ... +--rw (signaling-option)? | +--:(bgp) | +--rw (bgp-type)? | +--:(l2vpn-bgp) | | +--rw ce-id? uint16 | | +--rw remote-ce-id? uint16 | | +--rw vpls-instance | | +--rw vpls-edge-id? uint16 | +--:(evpn-bgp) | +--rw df-preference? uint16 | +--rw vpws-service-instance | ... +--rw group* [group-id] | +--rw group-id string | +--rw precedence? identityref | +--rw ethernet-segment-identifier? | l2vpn-es:es-ref +--rw ethernet-service-oam | ... +--rw service...]]></artwork> </figure></t>...]]></sourcecode> </figure> <t>The VPN network accesscomprises:</t> <t><list style="hanging"> <t hangText="'id':">Includesis comprised of the following:</t> <dl newline="false" spacing="normal"> <dt>'id':</dt> <dd>Includes an identifier of the VPN networkaccess.</t> <t hangText="'description':">Includesaccess.</dd> <dt>'description':</dt> <dd>Includes a textual description of the VPN networkaccess.</t> <t hangText="'interface-id':">Indicatesaccess.</dd> <dt>'interface-id':</dt> <dd>Indicates the interface on which the VPN network access isbound.</t> <t hangText="'active-vpn-node-profile':">Providesbound.</dd> <dt>'active-vpn-node-profile':</dt> <dd>Provides a pointer to an active 'global-parameters-profile' at the VPN node level. Referencing an active 'global-parameters-profile' implies that all associated data nodes will be inherited by the VPN network access. However, some of the inherited data nodes (e.g., ACL policies) can be overridden at the VPN network access level. In such case, adjusted values take precedence over inheritedvalues.</t> <t hangText="'status':">Indicatesvalues.</dd> <dt>'status':</dt> <dd>Indicates the administrative and operational status of the VPN networkaccess.</t> <t hangText="'connection':">Representsaccess.</dd> <dt>'connection':</dt> <dd>Represents and groups the set of Layer 2 connectivity from where the traffic of the L2VPN in a particular VPNNetworknetwork access is coming. See <xreftarget="connection"></xref>.</t> <t hangText="'signaling-option':">Indicatestarget="connection" format="default"/>.</dd> <dt>'signaling-option':</dt> <dd> <t>Indicates a set of signaling options that are specific to a given VPN network access, e.g., a CE ID ('ce-id' identifying the CE within the VPN) and a remote CE ID as discussed inSection 2.2.2 of<xreftarget="RFC6624"></xref>. <vspace blankLines="1" />Ittarget="RFC6624" sectionFormat="of" section="2.2.2" format="default"/>. </t> <t>It can also include a set of data nodes that are required for the configuration of a VPWS-EVPN <xreftarget="RFC8214"></xref>.target="RFC8214" format="default"/>. See <xreftarget="vsi"></xref>.</t> <t hangText="'group':">Istarget="vsi" format="default"/>.</t> </dd> <dt>'group':</dt> <dd>Is used for grouping VPN network accesses by assigning the same identifier to these accesses. The precedence attribute is used to differentiate the primary and secondary accesses for a service with multiple accesses. An example to illustrate the use of this container for redundancy purposes is provided in <xreftarget="prec-example"></xref>.target="prec-example" format="default"/>. This container is also used to identify the link of an ES by allocating the same ESI. An example to illustrate this functionality is provided in Appendices <xref format="counter"target="evpn-vpws-app"></xref>target="evpn-vpws-app"/> and <xref format="counter"target="auto-ex"></xref>.</t> <t hangText="'ethernet-service-oam':">Carriestarget="auto-ex"/>.</dd> <dt>'ethernet-service-oam':</dt> <dd>Carries information about the service OAM. See <xreftarget="oam"></xref>.</t> <t hangText="'service':">Specifiestarget="oam" format="default"/>.</dd> <dt>'service':</dt> <dd>Specifies the service parameters (e.g.,QoS,QoS and multicast) to apply for a given VPN network access. See <xreftarget="service"></xref>.</t> </list></t>target="service" format="default"/>.</dd> </dl> <section anchor="connection"title="Connection">numbered="true" toc="default"> <name>Connection</name> <t>The 'connection' container (<xreftarget="connection_tree"></xref>)target="connection_tree" format="default"/>) is used to configure the relevant properties of the interface to which the L2VPN instance is attached to (e.g., encapsulation type, Link Aggregation Group (LAG) interfaces, and split-horizon). The L2NM supports tag manipulation operations (e.g., tag rewrite).</t> <t>Note that the 'connection' container does not include the physical-specific configuration as this is assumed to be directly handled using device modules (e.g., an interfaces module). Moreover, this design is also meant to avoid manipulated global parameters at the service level and lower the risk of impacting other services sharing the same physical interface.</t> <t>A reference to the bearer is maintained to allow keeping the link between the L2SM and the L2NM when both data models are used in a given deployment.</t> <t>Some consistency checks should be ensured by implementations (typically, network controllers) for LAGinterfaceinterfaces, as the same information (e.g., LACP system-id) should be provided to the involved nodes.</t> <t>The L2NM inherits the 'member-link-list' structure from the L2SM (including indication of OAM 802.3ah support <xreftarget="IEEE-802-3ah"></xref>).</t>target="IEEE-802-3ah" format="default"/>).</t> <figurealign="right" anchor="connection_tree" title="Connection Subtree"> <artwork align="center"><![CDATA[anchor="connection_tree"> <name>Connection Subtree</name> <sourcecode type="yangtree"><![CDATA[ ... +--rw vpn-nodes +--rw vpn-node* [vpn-node-id] ... +--rw vpn-network-accesses +--rw vpn-network-access* [id] ... +--rw connection | +--rw l2-termination-point? | | string | +--rw local-bridge-reference? | | string | +--rw bearer-reference? string | | {vpn-common:bearer-reference}? | +--rw encapsulation | | +--rw encap-type? identityref | | +--rw dot1q | | | +--rw tag-type? identityref | | | +--rw cvlan-id? | | | | dot1q-types:vlanid | | | +--rw tag-operations | | | +--rw (op-choice)? | | | | +--:(pop) | | | | | +--rw pop? empty | | | | +--:(push) | | | | | +--rw push? empty | | | | +--:(translate) | | | | +--rw translate? empty | | | +--rw tag-1? | | | | dot1q-types:vlanid | | | +--rw tag-1-type? | | | | dot1q-types:dot1q-tag-type | | | +--rw tag-2? | | | | dot1q-types:vlanid | | | +--rw tag-2-type? | | | dot1q-types:dot1q-tag-type | | +--rw priority-tagged | | | +--rw tag-type? identityref | | +--rw qinq | | +--rw tag-type? identityref | | +--rw svlan-id | | | dot1q-types:vlanid | | +--rw cvlan-id | | | dot1q-types:vlanid | | +--rw tag-operations | | +--rw (op-choice)? | | | +--:(pop) | | | | +--rw pop? uint8 | | | +--:(push) | | | | +--rw push? empty | | | +--:(translate) | | | +--rw translate? empty | | +--rw tag-1? | | | dot1q-types:vlanid | | +--rw tag-1-type? | | | dot1q-types:dot1q-tag-type | | +--rw tag-2? | | | dot1q-types:vlanid | | +--rw tag-2-type? | | dot1q-types:dot1q-tag-type | +--rw lag-interface | | {vpn-common:lag-interface}? | +--rw lag-interface-id? string | +--rw lacp | | +--rw lacp-state? boolean | | +--rw mode? identityref | | +--rw speed? uint32 | | +--rw mini-link-num? uint32 | | +--rw system-id? | | | yang:mac-address | | +--rw admin-key? uint16 | | +--rw system-priority? uint16 | | +--rw member-link-list | | | +--rw member-link* [name] | | | +--rw name string | | | +--rw speed? uint32 | | | +--rw mode? identityref | | | +--rw link-mtu? uint32 | | | +--rw oam-802.3ah-link | | | | {oam-3ah}? | | | +--rw enable? boolean | | +--rw flow-control? boolean | | +--rw lldp? boolean | +--rw split-horizon | +--rw group-name? string ...]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vsi"title="EVPN-VPWSnumbered="true" toc="default"> <name>EVPN-VPWS ServiceInstance">Instance</name> <t>The 'vpws-service-instance' provides the local and remote VPWS Service Instance (VSI) <xreftarget="RFC8214"></xref>.target="RFC8214" format="default"/>. This container is only present when the 'vpn-type' is VPWS-EVPN. As shown in <xreftarget="vsi-tree"></xref>,target="vsi-tree" format="default"/>, the VSIs can be configured by a VPN service provider or auto-generated.</t> <t>An example to illustrate the use of the L2NM to configure VPWS-EVPN instances is provided in <xreftarget="evpn-vpws-app"></xref>.</t> <t><figure align="left" anchor="vsi-tree" title="EVPN-VPWStarget="evpn-vpws-app" format="default"/>.</t> <figure anchor="vsi-tree"> <name>EVPN-VPWS Service InstanceSubtree"> <artwork><![CDATA[...Subtree</name> <sourcecode type="yangtree"><![CDATA[... +--rw vpn-nodes +--rw vpn-node* [vpn-node-id] ... +--rw vpn-network-accesses +--rw vpn-network-access* [id] ... +--rw (signaling-option)? | +--:(bgp) | +--rw (bgp-type)? | +--:(l2vpn-bgp) | | ... | +--:(evpn-bgp) | +--rw df-preference? uint16 | +--rw vpws-service-instance | +--rw (local-vsi-choice)? | | +--:(directly-assigned) | | | +--rw local-vpws-service-instance? | | | uint32 | | +--:(auto-assigned) | | +--rw local-vsi-auto | | +--rw (auto-mode)? | | | +--:(from-pool) | | | | +--rw vsi-pool-name? | | | | string | | | +--:(full-auto) | | | +--rw auto? empty | | +--ro auto-local-vsi? uint32 | +--rw (remote-vsi-choice)? | +--:(directly-assigned) | | +--rw remote-vpws-service-instance? | | uint32 | +--:(auto-assigned) | +--rw remote-vsi-auto | +--rw (auto-mode)? | | +--:(from-pool) | | | +--rw vsi-pool-name? | | | string | | +--:(full-auto) | | +--rw auto? empty | +--ro auto-remote-vsi? uint32 ...]]></artwork> </figure></t>]]></sourcecode> </figure> </section> <section anchor="oam"title="Ethernet OAM">numbered="true" toc="default"> <name>Ethernet OAM</name> <t>Ethernet OAM refers to both <xreftarget="IEEE-802-1ag"></xref>target="IEEE-802-1ag" format="default"/> and <xreftarget="ITU-T-Y-1731"></xref>.</t>target="ITU-T-Y-1731" format="default"/>.</t> <t>As shown in <xreftarget="oamt"></xref>,target="oamt" format="default"/>, the L2NM inherits the same structure as inSection 5.3.2.2.6 of<xreftarget="RFC8466"></xref>target="RFC8466" sectionFormat="of" section="5.3.2.2.6" format="default"/> for OAM matters.</t><t><figure align="center" anchor="oamt" title="OAM Subtree"> <artwork align="center"><![CDATA[<figure anchor="oamt"> <name>OAM Subtree</name> <sourcecode type="yangtree"><![CDATA[ +--rw l2vpn-ntw +--rw vpn-profiles | ... +--rw vpn-services +--rw vpn-service* [vpn-id] ... +--rw vpn-nodes +--rw vpn-node* [vpn-node-id] ... +--rw vpn-network-accesses +--rw vpn-network-access* [id] ... +--rw ethernet-service-oam | +--rw md-name? string | +--rw md-level? uint8 | +--rw cfm-802.1-ag | | +--rw n2-uni-c* [maid] | | | +--rw maid string | | | +--rw mep-id? uint32 | | | +--rw mep-level? uint32 | | | +--rw mep-up-down? | | | | enumeration | | | +--rw remote-mep-id? uint32 | | | +--rw cos-for-cfm-pdus? uint32 | | | +--rw ccm-interval? uint32 | | | +--rw ccm-holdtime? uint32 | | | +--rw ccm-p-bits-pri? | | | ccm-priority-type | | +--rw n2-uni-n* [maid] | | +--rw maid string | | +--rw mep-id? uint32 | | +--rw mep-level? uint32 | | +--rw mep-up-down? | | | enumeration | | +--rw remote-mep-id? uint32 | | +--rw cos-for-cfm-pdus? uint32 | | +--rw ccm-interval? uint32 | | +--rw ccm-holdtime? uint32 | | +--rw ccm-p-bits-pri? | | ccm-priority-type | +--rw y-1731* [maid] | +--rw maid string | +--rw mep-id? uint32 | +--rw pm-type? identityref | +--rw remote-mep-id? uint32 | +--rw message-period? uint32 | +--rw measurement-interval? uint32 | +--rw cos? uint32 | +--rw loss-measurement? boolean | +--rwsynthethic-loss-measurement?synthetic-loss-measurement? | | boolean | +--rw delay-measurement | | +--rw enable-dm? boolean | | +--rw two-way? boolean | +--rw frame-size? uint32 | +--rw session-type? enumeration...]]></artwork> </figure></t>...]]></sourcecode> </figure> </section> <section anchor="service"title="Services">numbered="true" toc="default"> <name>Services</name> <t>The 'service' container (<xreftarget="service_tree"></xref>)target="service_tree" format="default"/>) provides a set of service-specificconfigurationconfigurations such asQuality of Service (QoS).</t> <t><figure align="center" anchor="service_tree" title="ServiceQoS.</t> <figure anchor="service_tree"> <name>Service OverallSubtree"> <artwork align="center"><![CDATA[Subtree</name> <sourcecode type="yangtree"><![CDATA[ +--rw l2vpn-ntw +--rw vpn-profiles | ... +--rw vpn-services +--rw vpn-service* [vpn-id] ... +--rw vpn-nodes +--rw vpn-node* [vpn-node-id] ... +--rw vpn-network-accesses +--rw vpn-network-access* [id] ... +--rw service +--rw mtu? uint32 +--rw svc-pe-to-ce-bandwidth | {vpn-common:inbound-bw}? | ... +--rw svc-ce-to-pe-bandwidth | {vpn-common:outbound-bw}? | ... +--rw qos {vpn-common:qos}? | ... +--rw mac-policies | ... +--rw broadcast-unknown-unicast-multicast ...]]></artwork> </figure>The]]></sourcecode> </figure> <t>The description of the service data nodes is as follows:</t><t><list style="hanging"> <t hangText="'mtu':">Specifies<dl newline="false" spacing="normal"> <dt>'mtu':</dt> <dd>Specifies the Layer 2 MTU, in bytes, for the VPN networkaccess.</t> <t hangText="'svc-pe-to-ce-bandwidth'access.</dd> <dt>'svc-pe-to-ce-bandwidth' and'svc-ce-to-pe-bandwidth':">Specify'svc-ce-to-pe-bandwidth':</dt> <dd> <t>Specify the service bandwidth for the L2VPN service.<vspace blankLines="1" />'svc-pe-to-ce-bandwidth'</t> <t>'svc-pe-to-ce-bandwidth' indicates the inbound bandwidth of the connection (i.e., download bandwidth from the service provider to the site).<vspace blankLines="1" />'svc-ce-to-pe-bandwidth'</t> <t>'svc-ce-to-pe-bandwidth' indicates the outbound bandwidth of the connection (i.e., upload bandwidth from the site to the service provider).<vspace blankLines="1" />'svc-pe-to-ce-bandwidth'</t> <t>'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth' can be represented using the Committed Information Rate (CIR), the Excess Information Rate (EIR), or the Peak Information Rate (PIR).<vspace blankLines="1" />As</t> <t>As shown in <xreftarget="bwtree"></xref>,target="bwtree" format="default"/>, the structure of service bandwidth data nodes is inherited from the L2SM <xreftarget="RFC8466"></xref>.target="RFC8466" format="default"/>. The following types, defined in <xreftarget="RFC9181"></xref>,target="RFC9181" format="default"/>, can be used to indicate the bandwidth type:<list style="hanging"> <t hangText="'bw-per-cos':">The</t> <dl newline="false" spacing="normal"> <dt>'bw-per-cos':</dt> <dd>The bandwidth is perClass of Service (CoS).</t> <t hangText="'bw-per-port':">TheCoS.</dd> <dt>'bw-per-port':</dt> <dd>The bandwidth is per VPN networkaccess.</t> <t hangText="'bw-per-site':">Theaccess.</dd> <dt>'bw-per-site':</dt> <dd>The bandwidth is to all VPN network accesses that belong to the samesite.</t> <t hangText="'bw-per-service':">Thesite.</dd> <dt>'bw-per-service':</dt> <dd>The bandwidth is per L2VPNservice.</t> </list><vspace blankLines="1" /><figure align="center" anchor="bwtree" title="Serviceservice.</dd> </dl> <figure anchor="bwtree"> <name>Service BandwidthSubtree"> <artwork align="center"><![CDATA[Subtree</name> <sourcecode type="yangtree"><![CDATA[ +--rw service ... +--rw svc-pe-to-ce-bandwidth | {vpn-common:inbound-bw}? | +--rw pe-to-ce-bandwidth* [bw-type] | +--rw bw-type identityref | +--rw (type)? | +--:(per-cos) | | +--rw cos* [cos-id] | | +--rw cos-id uint8 | | +--rw cir? uint64 | | +--rw cbs? uint64 | | +--rw eir? uint64 | | +--rw ebs? uint64 | | +--rw pir? uint64 | | +--rw pbs? uint64 | +--:(other) | +--rw cir? uint64 | +--rw cbs? uint64 | +--rw eir? uint64 | +--rw ebs? uint64 | +--rw pir? uint64 | +--rw pbs? uint64 +--rw svc-ce-to-pe-bandwidth | {vpn-common:outbound-bw}? | +--rw ce-to-pe-bandwidth* [bw-type] | +--rw bw-type identityref | +--rw (type)? | +--:(per-cos) | | +--rw cos* [cos-id] | | +--rw cos-id uint8 | | +--rw cir? uint64 | | +--rw cbs? uint64 | | +--rw eir? uint64 | | +--rw ebs? uint64 | | +--rw pir? uint64 | | +--rw pbs? uint64 | +--:(other) | +--rw cir? uint64 | +--rw cbs? uint64 | +--rw eir? uint64 | +--rw ebs? uint64 | +--rw pir? uint64 | +--rw pbs? uint64 ...]]></artwork> </figure></t> <t hangText="'qos':">Is]]></sourcecode> </figure> </dd> <dt>'qos':</dt> <dd> <t>Is used to define a set of QoS policies to apply on a given VPN network access (<xreftarget="qos-tree"></xref>).target="qos-tree" format="default"/>). The QoS classification can be based on many criteria such as source MAC address, destination MAC address, etc. See alsoSection 5.10.2.1 of<xreftarget="RFC8466"></xref>target="RFC8466" sectionFormat="of" section="5.10.2.1" format="default"/> for more discussion of QoS classification including the use of colortypes.<figure align="center" anchor="qos-tree" title="QoS Subtree"> <artwork align="center"><![CDATA[types.</t> <figure anchor="qos-tree"> <name>QoS Subtree</name> <sourcecode type="yangtree"><![CDATA[ +--rw service ... +--rw qos {vpn-common:qos}? | +--rw qos-classification-policy | | +--rw rule* [id] | | +--rw id string | | +--rw (match-type)? | | | +--:(match-flow) | | | | +--rw match-flow | | | | +--rw dscp? inet:dscp | | | | +--rw dot1q? uint16 | | | | +--rw pcp? uint8 | | | | +--rw src-mac-address? | | | | | yang:mac-address | | | | +--rw dst-mac-address? | | | | | yang:mac-address | | | | +--rw color-type? | | | | | identityref | | | | +--rw any? empty | | | +--:(match-application) | | | +--rw match-application? | | | identityref | | +--rw target-class-id? string | +--rw qos-profile | +--rw qos-profile* [profile] | +--rw profile leafref | +--rw direction? identityref ...]]></artwork> </figure></t> <t hangText="'mac-policies':">Lists]]></sourcecode> </figure> </dd> <dt>'mac-policies':</dt> <dd> <t>Lists a set of MAC-related policies such as MAC ACLs. Similar to <xreftarget="RFC8519"></xref>,target="RFC8519" format="default"/>, an ACL match can be based upon source MAC address, source MAC address mask, destination MAC address, destination MAC address mask, or a combinationthereof.<vspace blankLines="1" />Athereof.</t> <t>A data frame that matches an ACL can be dropped, be flooded, or trigger an alarm. A rate-limit policy can be defined for handling frames that match an ACL entry with 'flood' action.<vspace blankLines="1" />When</t> <t>When 'mac-loop-prevention' or 'mac-addr-limit' data nodes are provided, they take precedence over the onesinlcudedincluded in the 'global-parameters-profile' at the VPN service or VPN nodelevels.<figure align="center" anchor="mac-policies-tree" title="MAClevels.</t> <figure anchor="mac-policies-tree"> <name>MAC PoliciesSubtree"> <artwork align="center"><![CDATA[Subtree</name> <sourcecode type="yangtree"><![CDATA[ +--rw service ... +--rw mac-policies | +--rw access-control-list* [name] | | +--rw name string | | +--rw src-mac-address* | | | yang:mac-address | | +--rw src-mac-address-mask* | | | yang:mac-address | | +--rw dst-mac-address* | | | yang:mac-address | | +--rw dst-mac-address-mask* | | | yang:mac-address | | +--rw action? identityref | | +--rw rate-limit? decimal64 | +--rw mac-loop-prevention | | +--rw window? uint32 | | +--rw frequency? uint32 | | +--rw retry-timer? uint32 | | +--rw protection-type? identityref | +--rw mac-addr-limit | +--rw limit-number? uint16 | +--rw time-interval? uint32 | +--rw action? identityref ...]]></artwork> </figure></t> <t hangText="'broadcast-unknown-unicast-multicast':">Defines]]></sourcecode> </figure> </dd> <dt>'broadcast-unknown-unicast-multicast':</dt> <dd> <t>Defines the type of site in the customer multicast service topology: source, receiver, or both. It is also used to define multicast group-to-port mappings. </t> <figurealign="center" anchor="bum_tree" title="BUM Subtree"> <artwork align="center"><![CDATA[anchor="bum_tree"> <name>BUM Subtree</name> <sourcecode type="yangtree"><![CDATA[ +--rw service ... +--rw broadcast-unknown-unicast-multicast +--rw multicast-site-type? | enumeration +--rw multicast-gp-address-mapping* [id] | +--rw id uint16 | +--rw vlan-id uint32 | +--rw mac-gp-address | | yang:mac-address | +--rw port-lag-number? uint32 +--rw bum-overall-rate? uint64]]></artwork> </figure></t> </list></t>]]></sourcecode> </figure> </dd> </dl> </section> </section> </section> <sectiontitle="YANG Modules"> <t></t>numbered="true" toc="default"> <name>YANG Modules</name> <t/> <section anchor="iana-bgp"title="IANA-Maintainednumbered="true" toc="default"> <name>IANA-Maintained Module for BGP Layer 2 EncapsulationTypes">Types</name> <t>The "iana-bgp-l2-encaps" YANG moduleechoesmatches the "BGP Layer 2 Encapsulation Types" registryavailable at<xreftarget="IANA-BGP-L2"></xref>.</t>target="IANA-BGP-L2" format="default"/>.</t> <t>This module references <xreftarget="RFC3032"></xref>,target="RFC3032" format="default"/>, <xreftarget="RFC4446"></xref>,target="RFC4446" format="default"/>, <xreftarget="RFC4448"></xref>,target="RFC4448" format="default"/>, <xreftarget="RFC4553"></xref>,target="RFC4553" format="default"/>, <xreftarget="RFC4618"></xref>,target="RFC4618" format="default"/>, <xreftarget="RFC4619"></xref>,target="RFC4619" format="default"/>, <xreftarget="RFC4717"></xref>,target="RFC4717" format="default"/>, <xreftarget="RFC4761"></xref>,target="RFC4761" format="default"/>, <xreftarget="RFC4816"></xref>,target="RFC4816" format="default"/>, <xreftarget="RFC4842"></xref>,target="RFC4842" format="default"/>, and <xreftarget="RFC5086"></xref>.</t> <t><figure align="center"> <artwork><![CDATA[<CODE BEGINS>file "iana-bgp-l2-encaps@2021-07-05.yang"target="RFC5086" format="default"/>.</t> <sourcecode name="iana-bgp-l2-encaps@2022-09-20.yang" type="yang" markers="true"><![CDATA[ module iana-bgp-l2-encaps { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps"; prefix iana-bgp-l2-encaps; organization "IANA"; contact "Internet Assigned Numbers Authority Postal: ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America Tel: +1 310 301 5800 <mailto:iana@iana.org>"; description "This YANG module contains a collection of IANA-maintained YANG data types that are used for referring to BGP Layer 2 encapsulation types. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFCXXXX;9291; see the RFC itself for full legal notices."; revision2021-07-052022-09-20 { description "First revision."; reference "RFCXXXX:9291: A YANG Network Data Model for Layer 2 VPNs."; } identity bgp-l2-encaps-type { description "Base BGP Layer 2 encapsulation type."; reference "RFC 6624: Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling"; } identity frame-relay { base bgp-l2-encaps-type; description "Frame Relay."; reference "RFC 4446: IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)"; } identity atm-aal5 { base bgp-l2-encaps-type; description "ATM AAL5 SDU VCC transport."; reference "RFC 4446: IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)"; } identity atm-cell { base bgp-l2-encaps-type; description "ATM transparent cell transport."; reference "RFC 4816: Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service"; } identity ethernet-tagged-mode { base bgp-l2-encaps-type; description "Ethernet (VLAN) Tagged Mode."; reference "RFC 4448: Encapsulation Methods for Transport of Ethernet over MPLS Networks"; } identity ethernet-raw-mode { base bgp-l2-encaps-type; description "Ethernet Raw Mode."; reference "RFC 4448: Encapsulation Methods for Transport of Ethernet over MPLS Networks"; } identity hdlc { base bgp-l2-encaps-type; description "Cisco HDLC."; reference "RFC 4618: Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks"; } identity ppp { base bgp-l2-encaps-type; description "PPP."; reference "RFC 4618: Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks"; } identity circuit-emulation { base bgp-l2-encaps-type; description "SONET/SDH Circuit Emulation Service."; reference "RFC 4842: Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)"; } identity atm-to-vcc { base bgp-l2-encaps-type; description "ATM n-to-one VCC cell transport."; reference "RFC 4717: Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks"; } identity atm-to-vpc { base bgp-l2-encaps-type; description "ATM n-to-one VPC cell transport."; reference "RFC 4717: Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks"; } identity layer-2-transport { base bgp-l2-encaps-type; description "IP Layer 2 Transport."; reference "RFC 3032: MPLS Label Stack Encoding"; } identity fr-port-mode { base bgp-l2-encaps-type; description "Frame Relay Port mode."; reference "RFC 4619: Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks"; } identity e1 { base bgp-l2-encaps-type; description "Structure-agnostic E1 over packet."; reference "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)"; } identity t1 { base bgp-l2-encaps-type; description "Structure-agnostic T1 (DS1) over packet."; reference "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)"; } identity vpls { base bgp-l2-encaps-type; description "VPLS."; reference "RFC 4761: Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"; } identity t3 { base bgp-l2-encaps-type; description "Structure-agnostic T3 (DS3) over packet."; reference "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)"; } identity structure-aware { base bgp-l2-encaps-type; description "Nx64kbit/s Basic Service using Structure-aware."; reference "RFC 5086: Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)"; } identity dlci { base bgp-l2-encaps-type; description "Frame Relay DLCI."; reference "RFC 4619: Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks"; } identity e3 { base bgp-l2-encaps-type; description "Structure-agnostic E3 over packet."; reference "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)"; } identity ds1 { base bgp-l2-encaps-type; description "Octet-aligned payload for Structure-agnostic DS1 circuits."; reference "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)"; } identity cas { base bgp-l2-encaps-type; description "E1 Nx64kbit/s with CAS using Structure-aware."; reference "RFC 5086: Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)"; } identity esf { base bgp-l2-encaps-type; description "DS1 (ESF) Nx64kbit/s with CAS using Structure-aware."; reference "RFC 5086: Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)"; } identity sf { base bgp-l2-encaps-type; description "DS1 (SF) Nx64kbit/s with CAS using Structure-aware."; reference "RFC 5086: Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)"; } }<CODE ENDS>]]></artwork> </figure></t>]]></sourcecode> </section> <section anchor="iana-pw"title="IANA-Maintainednumbered="true" toc="default"> <name>IANA-Maintained Module for PseudowireTypes">Types</name> <t>The initial version of the "iana-pseudowire-types" YANG moduleechoesmatches theregistry available at"MPLS Pseudowire Types Registry" <xreftarget="IANA-PW-Types"></xref>.</t>target="IANA-PW-TYPES" format="default"/>.</t> <t>This module references <xreftarget="MFA"></xref>,target="MFA" format="default"/>, <xref target="RFC2507" format="default"/>, <xreftarget="RFC2507"></xref>,target="RFC2508" format="default"/>, <xreftarget="RFC2508"></xref>,target="RFC3032" format="default"/>, <xreftarget="RFC3032"></xref>,target="RFC3545" format="default"/>, <xreftarget="RFC3545"></xref>,target="RFC4448" format="default"/>, <xreftarget="RFC4448"></xref>,target="RFC4553" format="default"/>, <xreftarget="RFC4618"></xref>,target="RFC4618" format="default"/>, <xreftarget="RFC4619"></xref>,target="RFC4619" format="default"/>, <xreftarget="RFC4717"></xref>,target="RFC4717" format="default"/>, <xreftarget="RFC4842"></xref>,target="RFC4842" format="default"/>, <xreftarget="RFC4863"></xref>,target="RFC4863" format="default"/>, <xreftarget="RFC4901"></xref>,target="RFC4901" format="default"/>, <xreftarget="RFC5086"></xref>,target="RFC5086" format="default"/>, <xreftarget="RFC5087"></xref>,target="RFC5087" format="default"/>, <xreftarget="RFC5143"></xref>,target="RFC5143" format="default"/>, <xreftarget="RFC5795"></xref>,target="RFC5795" format="default"/>, and <xreftarget="RFC6307"></xref>.</t> <t><figure align="center"> <artwork><![CDATA[<CODE BEGINS>file "iana-pseudowire-types@2021-07-05.yang"target="RFC6307" format="default"/>.</t> <sourcecode name="iana-pseudowire-types@2022-09-20.yang" type="yang" markers="true"><![CDATA[ module iana-pseudowire-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:iana-pseudowire-types"; prefix iana-pw-types; organization "IANA"; contact "Internet Assigned Numbers Authority Postal: ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America Tel: +1 310 301 5800 <mailto:iana@iana.org>"; description "This module contains a collection of IANA-maintained YANG data types that are used for referring to Pseudowire Types. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFCXXXX;9291; see the RFC itself for full legal notices."; revision2021-07-052022-09-20 { description "First revision."; reference "RFCXXXX:RFC 9291: A YANG Network Data Model for Layer 2 VPNs."; } identity iana-pw-types { description "Base Pseudowire Layer 2 encapsulation type."; } identity frame-relay { base iana-pw-types; description "Frame Relay DLCI (Martini Mode)."; reference "RFC 4619: Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks"; } identity atm-aal5 { base iana-pw-types; description "ATM AAL5 SDU VCC transport."; reference "RFC 4717: Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks"; } identity atm-cell { base iana-pw-types; description "ATM transparent cell transport."; reference "RFC 4717: Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks"; } identity ethernet-tagged-mode { base iana-pw-types; description "Ethernet (VLAN) Tagged Mode."; reference "RFC 4448: Encapsulation Methods for Transport of Ethernet over MPLS Networks"; } identity ethernet { base iana-pw-types; description "Ethernet."; reference "RFC 4448: Encapsulation Methods for Transport of Ethernet over MPLS Networks"; } identity hdlc { base iana-pw-types; description "HDLC."; reference "RFC 4618: Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks"; } identity ppp { base iana-pw-types; description "PPP."; reference "RFC 4618: Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks"; } identity circuit-emulation-mpls { base iana-pw-types; description "SONET/SDH Circuit Emulation Service Over MPLS Encapsulation."; reference "RFC 5143: Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation"; } identity atm-to-vcc { base iana-pw-types; description "ATM n-to-one VCC cell transport."; reference "RFC 4717: Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks"; } identity atm-to-vpc { base iana-pw-types; description "ATM n-to-one VPC cell transport."; reference "RFC 4717: Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks"; } identity layer-2-transport { base iana-pw-types; description "IP Layer2 Transport."; reference "RFC 3032: MPLS Label Stack Encoding"; } identity atm-one-to-one-vcc { base iana-pw-types; description "ATM one-to-one VCC Cell Mode."; reference "RFC 4717: Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks"; } identity atm-one-to-one-vpc { base iana-pw-types; description "ATM one-to-one VPC Cell Mode."; reference "RFC 4717: Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks"; } identity atm-aal5-vcc { base iana-pw-types; description "ATM AAL5 PDU VCC transport."; reference "RFC 4717: Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks"; } identity fr-port-mode { base iana-pw-types; description "Frame-Relay Port mode."; reference "RFC 4619: Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks"; } identity circuit-emulation-packet { base iana-pw-types; description "SONET/SDH Circuit Emulation over Packet."; reference "RFC 4842: Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)"; } identity e1 { base iana-pw-types; description "Structure-agnostic E1 over Packet."; reference "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)"; } identity t1 { base iana-pw-types; description "Structure-agnostic T1 (DS1) over Packet."; reference "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)"; } identity e3 { base iana-pw-types; description "Structure-agnostic E3 over Packet."; reference "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)"; } identity t3 { base iana-pw-types; description "Structure-agnostic T3 (DS3) over Packet."; reference "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)"; } identity ces-over-psn { base iana-pw-types; description "CESoPSN basic mode."; reference "RFC 5086: Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)"; } identity tdm-over-ip-aal1 { base iana-pw-types; description "TDMoIP AAL1 Mode."; reference "RFC 5087: Time Division Multiplexing over IP (TDMoIP)"; } identity ces-over-psn-cas { base iana-pw-types; description "CESoPSN TDM with CAS."; reference "RFC 5086: Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)"; } identity tdm-over-ip-aal2 { base iana-pw-types; description "TDMoIP AAL2 Mode."; reference "RFC 5087: Time Division Multiplexing over IP (TDMoIP)"; } identity dlci { base iana-pw-types; description "Frame Relay DLCI."; reference "RFC 4619: Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks"; } identity rohc { base iana-pw-types; description "ROHC Transport Header-compressed Packets."; reference "RFC 5795: The RObust Header Compression (ROHC) Framework RFC 4901: Protocol Extensions for Header Compression over MPLS"; } identity ecrtp { base iana-pw-types; description "ECRTP Transport Header-compressed Packets."; reference "RFC 3545: Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering RFC 4901: Protocol Extensions for Header Compression over MPLS"; } identity iphc { base iana-pw-types; description "IPHC Transport Header-compressed Packets."; reference "RFC 2507: IP Header Compression RFC 4901: Protocol Extensions for Header Compression over MPLS"; } identity crtp { base iana-pw-types; description "cRTP Transport Header-compressed Packets."; reference "RFC 2508: Compressing IP/UDP/RTP Headers for Low-Speed Serial Links RFC 4901: Protocol Extensions for Header Compression over MPLS"; } identity atm-vp-virtual-trunk { base iana-pw-types; description "ATM VP Virtual Trunk."; reference "MFA Forum: The Use of Virtual Trunks for ATM/MPLS Control Plane Interworking Specification"; } identity fc-port-mode { base iana-pw-types; description "FC Port Mode."; reference "RFC 6307: Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks"; } identity wildcard { base iana-pw-types; description "Wildcard."; reference "RFC 4863: Wildcard Pseudowire Type"; } }<CODE ENDS>]]></artwork> </figure></t>]]></sourcecode> </section> <section anchor="es-yang"title="Ethernet Segments">numbered="true" toc="default"> <name>Ethernet Segments</name> <t>The "ietf-ethernet-segment" YANG module uses types defined in <xreftarget="RFC6991"></xref>.</t> <t><figure> <artwork><![CDATA[<CODE BEGINS>file "ietf-ethernet-segment@2022-05-25.yang"target="RFC6991" format="default"/>.</t> <sourcecode name="ietf-ethernet-segment@2022-09-20.yang" type="yang" markers="true"><![CDATA[ module ietf-ethernet-segment { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ethernet-segment"; prefix l2vpn-es; import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG DataTypes,Types (see Section3";3)"; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/opsawg/> WG List: <mailto:opsawg@ietf.org> Editor: Mohamed Boucadair <mailto:mohamed.boucadair@orange.com> Editor: Samier Barguil <mailto:samier.barguilgiraldo.ext@telefonica.com> Author: Oscar Gonzalez de Dios <mailto:oscar.gonzalezdedios@telefonica.com>"; description "This YANG module defines a model for Ethernet Segments. Copyright (c)20212022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFCXXXX;9291; see the RFC itself for full legal notices."; revision2022-05-252022-09-20 { description "Initial version."; reference "RFCXXXX:9291: A YANG Network Data Model for Layer 2 VPNs."; } /* Typedefs */ typedef es-ref { type leafref { path "/l2vpn-es:ethernet-segments/l2vpn-es:ethernet-segment" + "/l2vpn-es:name"; } description "Defines a type for referencing an Ethernet segment in other modules."; } /* Identities */ identity esi-type { description"T-(Ethernet"T (Ethernet Segment Identifier (ESI) Type) is a 1-octet field (most significant octet) that specifies the format of the remaining 9 octets (ESI Value)."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5"; } identity esi-type-0-operator { base esi-type; description "This type indicates an arbitrary 9-octet ESI value, which is managed and configured by the operator."; } identity esi-type-1-lacp { base esi-type; description "When the IEEE 802.1AX Link Aggregation Control Protocol (LACP) is used between the Provider Edge (PE) and Customer Edge (CE) devices, this ESI type indicates an auto-generated ESI value determined from LACP."; reference "IEEEStd.Std 802.1AX: Link Aggregation"; } identity esi-type-2-bridge { base esi-type; description "The ESI value is auto-generated and determined based on the Layer 2 bridge protocol."; } identity esi-type-3-mac { base esi-type; description "This type indicates a MAC-based ESI value that can be auto-generated or configured by the operator."; } identity esi-type-4-router-id { base esi-type; description "This type indicates a Router ID ESI value that can be auto-generated or configured by the operator."; } identity esi-type-5-asn { base esi-type; description "This type indicates an Autonomous System (AS)-based ESI value that can be auto-generated or configured by the operator."; } identity df-election-methods { description "Base Identity Designated Forwarder (DF) election method."; } identity default-7432 { base df-election-methods; description "The default DF election method. The default procedure for DF election at the granularity of <ES,VLAN> for VLAN-based service or <ES, VLAN bundle> for VLAN-(aware) bundle service is referred to as 'service carving'."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.5"; } identity highest-random-weight { base df-election-methods; description "The highest random weight (HRW) method."; reference "RFC 8584: Framework for Ethernet VPN Designated Forwarder Election Extensibility, Section 3"; } identity preference { base df-election-methods; description "Thepreference basedpreference-based method. PEs are assigned with preferences to become the DF in the Ethernet Segment (ES). The exact preference-based algorithm (e.g., lowest-preferencealgorithm,algorithm or highest-preference algorithm) to use is signaled at the control plane."; } identity es-redundancy-mode { description "Base identity for ES redundancy modes."; } identity single-active { base es-redundancy-mode; description "Indicates Single-Active redundancy mode for a given ES."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.1"; } identity all-active { base es-redundancy-mode; description "Indicates All-Active redundancy mode for a given ES."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.2"; } /* Main Ethernet Segment Container */ container ethernet-segments { description "Top container for the Ethernet Segment Identifier (ESI)."; list ethernet-segment { key "name"; description "Top list for ESIs."; leaf name { type string; description "Includes the name of the Ethernet Segment (ES) that is used to unambiguously identify an ES."; } leaf esi-type { type identityref { base esi-type; } default "esi-type-0-operator"; description "T-(ESI Type) is a 1-octet field (most significant octet) that specifies the format of the remaining 9 octets (ESI Value)."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5"; } choice esi-choice { description "Ethernet segment choice between several types. For ESI Type 0: The esi is directly configured by the operator. For ESI Type 1: The auto-mode must be used. For ESI Type 2: The auto-mode must be used. For ESI Type 3: The directly-assigned or auto-mode must be used. For ESI Type 4: The directly-assigned or auto-mode must be used. For ESI Type 5: The directly-assigned or auto-mode must be used."; case directly-assigned { description "Explicitly assign an ESI value."; leaf ethernet-segment-identifier { type yang:hex-string { length "29"; } description "10-octet ESI."; } } case auto-assigned { description "The ESI is auto-assigned."; container esi-auto { description "The ESI is auto-assigned."; choice auto-mode { description "Indicates the auto-assignment mode. ESI can be automatically assigned either with or without indicating a pool from which the ESI should be taken. For both cases, the server will auto-assign an ESI value 'auto-assigned-ESI' and use that value operationally."; case from-pool { leaf esi-pool-name { type string; description "The auto-assignment will be made from the pool identified by the ESI-pool-name."; } } case full-auto { leaf auto { type empty; description "Indicates an ESI is fully auto-assigned."; } } } leaf auto-ethernet-segment-identifier { type yang:hex-string { length "29"; } config false; description "The value of the auto-assigned ESI."; } } } } leaf esi-redundancy-mode { type identityref { base es-redundancy-mode; } description "Indicates the ES redundancy mode."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1"; } container df-election { description "Top container for the DF election method properties."; leaf df-election-method { type identityref { base df-election-methods; } default "default-7432"; description "Specifies the DF election method."; reference "RFC 8584: Framework for Ethernet VPN Designated Forwarder Election Extensibility"; } leaf revertive { when "derived-from-or-self(../df-election-method, " + "'preference')" { description "The revertive value is only applicable to the preference method."; } type boolean; default "true"; description "The default behavior is that the DF election procedure is triggered upon PE failures following configured preference values. Such a mode is called therevertive'revertive' mode. This mode may not be suitable in some scenarios where, e.g., an operator may want to maintain the new DF even if the former DF recovers. Such a mode is called the 'non-revertive' mode. The non-revertive mode can be configured by setting 'revertive' leaf to 'false'."; reference "RFC 8584: Framework for Ethernet VPN Designated Forwarder Election Extensibility, Section 1.3.2"; } leaf election-wait-time { type uint32; units "seconds"; default "3"; description"Election wait"Designated Forwarder Wait timer."; reference "RFC 8584: Framework for Ethernet VPN Designated Forwarder Election Extensibility"; } } leaf split-horizon-filtering { type boolean; description "Controls split-horizon filtering. It is enabled when set to 'true'. In order to achieve split-horizon filtering, every Broadcast,unknown unicast,Unknown Unicast, ormulticastMulticast (BUM) packet originating from a non-DF PE is encapsulated with an MPLS label that identifies the origin ES."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.3"; } container pbb { description "Provider Backbone Bridging (PBB) parameters ."; reference "IEEE 802.1ah: Provider BackboneBridge";Bridges"; leaf backbone-src-mac { type yang:mac-address; description "The PEs connected to the same CE must share the same Provider Backbone (B-MAC) address in All-Active mode."; reference "RFC 7623: Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN), Section 6.2.1.1"; } } list member { key "ne-id interface-id"; description "Includes a list of ES members."; leaf ne-id { type string; description "An identifier of the network element where the ES is configured within a service provider network."; } leaf interface-id { type string; description "Identifier of a node interface."; } } } } }<CODE ENDS> ]]></artwork> </figure></t>]]></sourcecode> </section> <section anchor="YANG_module"title="L2NM">numbered="true" toc="default"> <name>L2NM</name> <t>The "ietf-l2vpn-ntw" YANG module uses types defined in <xreftarget="RFC6991"></xref>,target="RFC6991" format="default"/>, <xreftarget="RFC9181"></xref>,target="RFC9181" format="default"/>, <xreftarget="RFC8294"></xref>,target="RFC8294" format="default"/>, and <xreftarget="IEEE802.1Qcp-2018"></xref>.</t> <figure align="center"> <artwork align="center"><![CDATA[<CODE BEGINS>file "ietf-l2vpn-ntw@2022-05-25.yang"target="IEEE802.1Qcp" format="default"/>.</t> <sourcecode name="ietf-l2vpn-ntw@2022-09-20.yang" type="yang" markers="true"><![CDATA[ module ietf-l2vpn-ntw { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw"; prefix l2vpn-ntw; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types, Section 4"; } import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types, Section 3"; } import ietf-vpn-common { prefix vpn-common; reference "RFC 9181: A Common YANG for Data Model for Layer 2 and Layer 3 VPNs"; } import iana-bgp-l2-encaps { prefix iana-bgp-l2-encaps; reference "RFCXXXX:9291: A YANG Network Data Model for Layer 2 VPNs."; } import iana-pseudowire-types { prefix iana-pw-types; reference "RFCXXXX:9291: A YANG Network Data Model for Layer 2 VPNs."; } import ietf-ethernet-segment { prefix l2vpn-es; reference "RFCXXXX:9291: A YANG Network Data Model for Layer 2 VPNs."; } import ietf-routing-types { prefix rt-types; reference "RFC 8294: Common YANG Data Types for the Routing Area"; } import ieee802-dot1q-types { prefix dot1q-types; reference "IEEE Std802.1Qcp-2018:802.1Qcp: Bridges and BridgedNetworks - Amendment:Networks-- Amendment 30: YANG Data Model"; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/opsawg/> WG List: <mailto:opsawg@ietf.org> Editor: Mohamed Boucadair <mailto:mohamed.boucadair@orange.com> Editor: Samier Barguil <mailto:samier.barguilgiraldo.ext@telefonica.com> Author: Oscar Gonzalez de Dios <mailto:oscar.gonzalezdedios@telefonica.com>"; description "This YANG module defines a network model for Layer 2 VPN services. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFCXXXX;9291; see the RFC itself for full legal notices."; revision2022-05-252022-09-20 { description "Initial version."; reference "RFCXXXX:9291: A YANG Network Data Model for Layer 2 VPNs."; } /* Features */ feature oam-3ah { description "Indicates the support of OAM 802.3ah."; reference "IEEE Std 802.3ah: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks"; } /* Identities */ identity evpn-service-interface-type { description "Base identity for EVPN service interface type."; } identity vlan-based-service-interface { base evpn-service-interface-type; description"VLAN-Based Service Interface.";"VLAN-based service interface."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.1"; } identity vlan-bundle-service-interface { base evpn-service-interface-type; description "VLANBundle Service Interface.";bundle service interface."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.2"; } identity vlan-aware-bundle-service-interface { base evpn-service-interface-type; description"VLAN-Aware Bundle Service Interface.";"VLAN-aware bundle service interface."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.3"; } identity mapping-type { base vpn-common:multicast-gp-address-mapping; description "Identity for multicast group mapping type."; } identity loop-prevention-type { description "Identity of loop prevention."; } identity shut { base loop-prevention-type; description "Shut protection type."; } identity trap { base loop-prevention-type; description "Trap protection type."; } identity color-type { description "Identity of color types. A type is assigned to a service frame to identify its QoS profile conformance."; } identity green { base color-type; description "'green' color type. A service frame is 'green' if it is conformant with the committed rate of the bandwidth profile."; } identity yellow { base color-type; description "'yellow' color type. A service frame is 'yellow' if it exceeds the committed rate but is conformant with the excess rate of the bandwidth profile."; } identity red { base color-type; description "'red' color type. A servicefamreframe is 'red' if it is not conformant with both the committed and excess rates of the bandwidth profile."; } identity t-ldp-pw-type { description "Identity fort-ldp-pw-type.";T-LDP pseudowire (PW) type."; } identity vpws-type { base t-ldp-pw-type; description "Virtual Private Wire Service (VPWS) t-ldp-pw-type."; reference "RFC 4664: Framework for Layer 2 Virtual Private Networks (L2VPNs), Section 3.3"; } identity vpls-type { base t-ldp-pw-type; description "Virtual Private LAN Service (VPLS) t-ldp-pw-type."; reference "RFC 4762: Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, Section 6.1"; } identity hvpls { base t-ldp-pw-type; description "Identity for Hierarchical Virtual Private LAN Service (H-VPLS) t-ldp-pw-type."; reference "RFC 4762: Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, Section 10"; } identity lacp-mode { description "Identity of the LACP mode."; } identity lacp-active { base lacp-mode; description "LACP active mode. This mode refers to the mode where auto-speed negotiation is initiated followed by an establishment of an Ethernet channel with the other end."; } identity lacp-passive { base lacp-mode; description "LACP passive mode. This mode refers to the LACP mode where an endpoint does not initiate thenegotiation,negotiation but only responds to LACP packets initiated by the other end (e.g., full duplex or half duplex)"; } identity pm-type { description "Identity for performance monitoring type."; } identity loss { base pm-type; description "Loss measurement is the performance monitoring type."; } identity delay { base pm-type; description "Delay measurement is the performance monitoring type."; } identity mac-learning-mode { description "Media Access Control (MAC) learning mode."; } identity data-plane { base mac-learning-mode; description "User MAC addresses are learned through ARP broadcast."; } identity control-plane { base mac-learning-mode; description "User MAC addresses are advertised through EVPN-BGP."; } identity mac-action { description "Base identity for a MAC action."; } identity drop { base mac-action; description "Dropping a packet as the MAC action."; } identity flood { base mac-action; description "Packet flooding as the MAC action."; } identity warning { base mac-action; description "Log a warning message as the MAC action."; } identity precedence-type { description "Redundancy type. The service can be created with primary and secondary signalization."; } identity primary { base precedence-type; description "Identifies the main VPN network access."; } identity secondary { base precedence-type; description "Identifies the secondary VPN network access."; } identity ldp-pw-type { description "Identity for allowed LDP-based pseudowire (PW) type."; reference "RFC 4762: Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, Section 6.1.1"; } identity ethernet { base ldp-pw-type; description "PW Ethernet type."; } identity ethernet-tagged { base ldp-pw-type; description "PW Ethernet tagged mode type."; } /* Typedefs */ typedef ccm-priority-type { type uint8 { range "0..7"; } description "A 3-bit priority value to be used in the VLANtag,tag if present in the transmitted frame. A larger value indicates a higher priority."; } /* Groupings */ grouping cfm-802 { description "Grouping for 802.1ag Connectivity Fault Management (CFM) attributes."; reference "IEEE Std802-1ag:802.1ag: Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management"; leaf maid { type string; description "Maintenance Association Identifier (MAID)."; } leaf mep-id { type uint32; description "Local Maintenance Entity Group End Point (MEP) ID."; } leaf mep-level { type uint32; description "MEP level."; } leaf mep-up-down { type enumeration { enum up { description "MEP is up."; } enum down { description "MEP is down."; } } default "up"; description "MEP up/down."; } leaf remote-mep-id { type uint32; description "Remote MEP ID."; } leaf cos-for-cfm-pdus { type uint32; description "Class ofserviceService for CFM PDUs."; } leaf ccm-interval { type uint32; units "milliseconds"; default "10000"; description "Continuity Check Message (CCM) interval."; } leaf ccm-holdtime { type uint32; units "milliseconds"; default "35000"; description "CCM hold time."; } leaf ccm-p-bits-pri { type ccm-priority-type; description "The priority parameter forContinuity Check Messages (CCMs)CCMs transmitted by the MEP."; } } grouping y-1731 { description "Grouping for Y-1731"; reference "ITU-TY-1731:G.8013/Y.1731: Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks"; list y-1731 { key "maid"; description "List of configured Y-1731 instances."; leaf maid { type string; description "MAID."; } leaf mep-id { type uint32; description "Local MEP ID."; } leaf pm-type { type identityref { base pm-type; } default "delay"; description "Performance monitor types."; } leaf remote-mep-id { type uint32; description "Remote MEP ID."; } leaf message-period { type uint32; units "milliseconds"; default "10000"; description "Defines the interval between OAM messages."; } leaf measurement-interval { type uint32; units "seconds"; description "Specifies the measurement interval for statistics."; } leaf cos { type uint32; description "Identifies the Class of Service."; } leaf loss-measurement { type boolean; default "false"; description "Controls whether loss measurement is ('true') or disabled ('false')."; } leafsynthethic-loss-measurementsynthetic-loss-measurement { type boolean; default "false"; description "Indicates whether synthetic loss measurement is enabled ('true') or disabled ('false')."; } container delay-measurement { description "Container for delaymeasurement";measurement."; leaf enable-dm { type boolean; default "false"; description "Controls whether delay measurement is enabled ('true') or disabled ('false')."; } leaf two-way { type boolean; default "false"; description "Whether delay measurement is two-way ('true') of one- way ('false')."; } } leaf frame-size { type uint32; units "bytes"; description "Indicates the frame size."; } leaf session-type { type enumeration { enum proactive { description "Proactive mode."; } enum on-demand { description "On-demand mode."; } } default "on-demand"; description "Specifies the session type."; } } } grouping parameters-profile { description "Container for per-service parameters."; leaf local-autonomous-system { type inet:as-number; description "Indicates a local AS Number (ASN)."; } leaf svc-mtu { type uint32; units "bytes"; description "Layer 2 service MTU. It is also known as the maximum transmission unit or maximum frame size."; } leaf ce-vlan-preservation { type boolean; description"Preserve"Preserves theCE-VLANCE VLAN ID from ingress to egress, i.e.,CE-VLANthe CE VLAN tag of the egress frame is identical to that of the ingress frame that yielded this egress service frame. If all-to-one bundling within a site is enabled, then preservation applies to all ingress service frames. If all-to-one bundling is disabled, then preservation applies to tagged ingress service frames havingCE-VLANCE VLAN ID 1 through 4094."; } leaf ce-vlan-cos-preservation { type boolean; description "CE VLAN CoS preservation. Priority Code Point (PCP) bits in theCE-VLANCE VLAN tag of the egress frame are identical to those of the ingress frame that yielded this egress service frame."; } leaf control-word-negotiation { type boolean; description "Controls whetherControl-wordcontrol-word negotiation is enabled (if set to true) or not (if set to false)."; reference "RFC 8077: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP), Section 7"; } container mac-policies { description "Container of MAC policies."; container mac-addr-limit { description "Container of MAC address limit configuration."; leaf limit-number { type uint16; description "Maximum number of MAC addresses learned from the customer for a single service instance. The default value is '2' when this grouping is used at the service level."; } leaf time-interval { type uint32; units "milliseconds"; description "The aging time of themacMAC address. The default value is '300' when this grouping is used at the service level."; } leaf action { type identityref { base mac-action; } description "Specifies the action when the upper limit is exceeded: drop the packet, flood the packet, or log a warning message (without dropping the packet). The default value is 'warning' when this grouping is used at the service level."; } } container mac-loop-prevention { description "Container for MAC loop prevention."; leaf window { type uint32; units "seconds"; description "The time interval over which a MAC mobility event is detected and checked. The default value is '180' when this grouping is used at the service level."; } leaf frequency { type uint32; description "The number of times to detect MAC duplication, where a 'duplicate MAC address' situation has occurred within the 'window' time interval and the duplicate MAC address has been added to a list of duplicate MAC addresses. The default value is '5' when this grouping is called at the service level."; } leaf retry-timer { type uint32; units "seconds"; description "The retry timer. When the retry timer expires, the duplicate MAC address will be flushed from the MAC-VRF."; } leaf protection-type { type identityref { base loop-prevention-type; } description "Protection type. The default value is 'trap' when this grouping is used at the service level."; } } } container multicast { if-feature "vpn-common:multicast"; description "Multicast container."; leaf enabled { type boolean; default "false"; description "Enables multicast."; } container customer-tree-flavors { description "Type of trees used by the customer."; leaf-list tree-flavor { type identityref { base vpn-common:multicast-tree-type; } description "Type of multicast tree to be used."; } } } } grouping bandwidth-parameters { description "A grouping for bandwidth parameters."; leaf cir { type uint64; units "bps"; description "Committed InformationRate.Rate (CIR). The maximum number of bits that a port can receive or send duringone-secondone second over an interface."; } leaf cbs { type uint64; units "bytes"; description "Committed BurstSize.Size (CBS). CBS controls the bursty nature of the traffic. Traffic that does not use the configured CIR accumulates credits until the credits reach the configured CBS."; } leaf eir { type uint64; units "bps"; description "Excess InformationRate,Rate (EIR), i.e., excess frame delivery allowed not subject toSLA.a Service Level Agreement (SLA). The traffic rate can be limited by EIR."; } leaf ebs { type uint64; units "bytes"; description "Excess BurstSize.Size (EBS). The bandwidth available for burst traffic from the EBS is subject to the amount of bandwidth that is accumulated during periods when traffic allocated by the EIR policy is not used."; } leaf pir { type uint64; units "bps"; description "Peak InformationRate,Rate (PIR), i.e., maximum frame delivery allowed. It is equal to or less than sum of CIR and EIR."; } leaf pbs { type uint64; units "bytes"; description "Peak BurstSize.";Size (PBS)."; } } /* Main L2NM Container */ container l2vpn-ntw { description "Container for the L2NM."; container vpn-profiles { description "Container for VPN profiles."; uses vpn-common:vpn-profile-cfg; } container vpn-services { description "Container for L2VPN services."; list vpn-service { key "vpn-id"; description "Container of a VPN service."; uses vpn-common:vpn-description; leaf parent-service-id { type vpn-common:vpn-id; description "Pointer to the parent service that triggered the L2NM."; } leaf vpn-type { type identityref { base vpn-common:service-type; } must "not(derived-from-or-self(current(), " + "'vpn-common:l3vpn'))" { error-message "L3VPN is only applicable in L3NM."; } description "Service type."; } leaf vpn-service-topology { type identityref { base vpn-common:vpn-topology; } description"Defining"Defines servicetopology,topology such as any-to-any, hub-spoke, etc."; } leaf bgp-ad-enabled { type boolean; description "Indicates whether BGP auto-discovery is enabled or disabled."; } leaf signaling-type { type identityref { base vpn-common:vpn-signaling-type; } description "VPN signaling type."; } container global-parameters-profiles { description "Container for a list of global parameters profiles."; list global-parameters-profile { key "profile-id"; description "List of global parameters profiles."; leaf profile-id { type string; description "The identifier of the global parameters profile."; } uses vpn-common:route-distinguisher; uses vpn-common:vpn-route-targets; uses parameters-profile; } } container underlay-transport { description "Container for the underlay transport."; uses vpn-common:underlay-transport; } uses vpn-common:service-status; container vpn-nodes { description "Set of VPN nodes that are involved in the L2NM."; list vpn-node { key "vpn-node-id"; description "Container of the VPN nodes."; leaf vpn-node-id { type vpn-common:vpn-id; description "Sets the identifier of the VPN node."; } leaf description { type string; description "Textual description of a VPN node."; } leaf ne-id { type string; description "An identifier of the network element where the VPN node is deployed. This identifier uniquely identifies the network element within an administrative domain."; } leaf role { type identityref { base vpn-common:role; } default "vpn-common:any-to-any-role"; description "Role of the VPN node in the VPN."; } leaf router-id { type rt-types:router-id; description "A 32-bit number in the dotted-quad format that is used to uniquely identify a node within anautonomous systemAutonomous System (AS)."; } container active-global-parameters-profiles { description "Container for a list of global parameters profiles."; list global-parameters-profile { key "profile-id"; description "List of active global parameters profiles."; leaf profile-id { type leafref { path "../../../../../global-parameters-profiles" + "/global-parameters-profile/profile-id"; } description "Points to a global profile defined at the service level."; } uses parameters-profile; } } uses vpn-common:service-status; container bgp-auto-discovery { when "../../../bgp-ad-enabled = 'true'" { description "Only applies when BGP auto-discovery is enabled."; } description "BGP is used for auto-discovery."; choice bgp-type { description "Choice for the BGP type."; case l2vpn-bgp { description "Container for BGP L2VPN."; leaf vpn-id { type vpn-common:vpn-id; description "VPN Identifier. This identifier serves to unify components of a given VPN for the sake of auto-discovery."; reference "RFC 6624: Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling"; } } case evpn-bgp { description "EVPN case."; leaf evpn-type { type leafref { path "../../../../vpn-type"; } description "EVPN type."; } leaf auto-rt-enable { type boolean; default "false"; description "Enables/disabled RT auto-derivation based on the ASN and Ethernet Tag ID."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 7.10.1"; } leaf auto-route-target { when "../auto-rt-enable = 'true'" { description "Can only be used when auto-RD is enabled."; } type rt-types:route-target; config false; description "The value of the auto-assigned RT."; } } } uses vpn-common:route-distinguisher; uses vpn-common:vpn-route-targets; } container signaling-option { description "Container for the L2VPN signaling."; leaf advertise-mtu { type boolean; description "Controls whether MTU is advertised."; reference "RFC 4667: Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP), Section 4.3"; } leaf mtu-allow-mismatch { type boolean; description "When set to true, it allows MTU mismatch."; reference "RFC 4667: Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP), Section 4.3"; } leaf signaling-type { type leafref { path "../../../../signaling-type"; } description "VPN signaling type."; } choice signaling-option { description "Choice for the signaling-option."; case bgp { description "BGP is used as the signaling protocol."; choice bgp-type { description "Choice for the BGP type."; case l2vpn-bgp { description "Container for BGP L2VPN."; leaf ce-range { type uint16; description "Determines the number of remote CEs with which a given CE can communicate in the context of a VPN."; reference "RFC 6624: Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling"; } leaf pw-encapsulation-type { type identityref { base iana-bgp-l2-encaps:bgp-l2-encaps-type; } description "PW encapsulation type."; } container vpls-instance { when "derived-from-or-self(../../../../" + "vpn-type, 'vpn-common:vpls')" { description "Only applies for VPLS."; } description "VPLS instance."; leaf vpls-edge-id { type uint16; description "VPLS Edge Identifier (VE ID). This is used when the same VE ID is configured for the PE."; reference "RFC 4761: Virtual Private LAN Service (VPLS) Using BGP for Auto- Discovery and Signaling, Section 3.5"; } leaf vpls-edge-id-range { type uint16; description "Specifies the size of the range of VE ID in a VPLS service. The range controls the size of the label block advertised in the context of a VPLS instance."; reference "RFC 4761: Virtual Private LAN Service (VPLS) Using BGP for Auto- Discovery and Signaling"; } } } case evpn-bgp { description "Used for EVPN."; leaf evpn-type { type leafref { path "../../bgp-auto-discovery/evpn-type"; } description "EVPN type."; } leaf service-interface-type { type identityref { base evpn-service-interface-type; } description "EVPN service interface type."; } container evpn-policies { description "Includes a set of EVPN policies such as those related to handling MAC addresses."; leaf mac-learning-mode { type identityref { base mac-learning-mode; } description "Indicates through which plane MAC addresses are advertised."; } leaf ingress-replication { type boolean; description "Controls whether ingress replication is enabled ('true') or disabled ('false')."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.3.1.1"; } leaf p2mp-replication { type boolean; description"Controles"Controls whetherP2MPPoint-to-Multipoint (P2MP) replication is enabled ('true') or disabled ('false')"; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.3.1.2"; } container arp-proxy { if-feature "vpn-common:ipv4"; description "Top container for the ARP proxy."; leaf enable { type boolean; default "false"; description "Enables (when set to 'true') or disables (when set to 'false') the ARP proxy."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 10"; } leaf arp-suppression { type boolean; default "false"; description "Enables (when set to 'true') or disables (when set to 'false') ARP suppression."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN"; } leaf ip-mobility-threshold { type uint16; description "It is possible for a given host (as defined by its IP address) to move from one ES to another. The IP mobility threshold specifies the number of IP mobility events that are detected for a given IP address within the detection-threshold before it is identified as a duplicate IP address. Once the detection threshold is reached, updates for the IP address are suppressed."; } leaf duplicate-ip-detection-interval { type uint16; units "seconds"; description "The time interval used in detecting a duplicate IP address. Duplicate IP address detection number of host moves are allowed within this interval period."; } } container nd-proxy { if-feature "vpn-common:ipv6"; description "Top container for the ND proxy."; leaf enable { type boolean; default "false"; description "Enables (when set to 'true') or disables (when set to 'false') the ND proxy."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 10"; } leaf nd-suppression { type boolean; default "false"; description "Enables (when set to 'true') or disables (when set to 'false') Neighbor Discovery (ND) message suppression. ND suppression is a technique that is used to reduce the amount of ND packets flooding within individualsegments, that issegments between hosts connected to the same logical switch."; } leaf ip-mobility-threshold { type uint16; description "It is possible for a given host (as defined by its IP address) to move from one ES to another. The IP mobility threshold specifies the number of IP mobility events that are detected for a given IP address within the detection-threshold before it is identified as a duplicate IP address. Once the detection threshold is reached, updates for the IP address are suppressed."; } leaf duplicate-ip-detection-interval { type uint16; units "seconds"; description "The time interval used in detecting a duplicate IP address. Duplicate IP address detection number of host moves are allowed within this interval period."; } } leaf underlay-multicast { type boolean; default "false"; description "Enables (when set to 'true') or disables (when set to 'false') underlay multicast."; } leafflood-unknown-unicast-supressionflood-unknown-unicast-suppression { type boolean; default "false"; description "Enables (when set to 'true') or disables (when set to 'false') unknown flood unicast suppression."; } leaf vpws-vlan-aware { type boolean; default "false"; description "Enables (when set to 'true') or disables (when set to 'false') VPWSVLAN-aware.";VLAN-aware service for the EVPN instance."; } container bum-management { description "Broadcast-unknown-unicast-multicast management."; leaf discard-broadcast { type boolean; default "false"; description "Discards broadcast, when enabled."; } leaf discard-unknown-multicast { type boolean; default "false"; description "Discards unknown multicast, when enabled."; } leaf discard-unknown-unicast { type boolean; default "false"; description "Discards unknown unicast, when enabled."; } } container pbb { when "derived-from-or-self(" + "../../evpn-type, 'pbb-evpn')" { description "Only applies for PBB EVPN."; } description "PBB parameters container."; reference "IEEE 802.1ah: Provider BackboneBridge";Bridges"; leaf backbone-src-mac { type yang:mac-address; description "Includesprovider backboneProvider Backbone MAC (B-MAC) address."; reference "RFC 7623: Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN), Section 8.1"; } } } } } } container ldp-or-l2tp { description "Container for LDP or L2TP-signaled PWs choice."; leaf agi { type rt-types:route-distinguisher; description "Attachment Group Identifier. Also, called VPLS-Id."; reference "RFC 4667: Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP), Section 4.3 RFC 4762: Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, Section 6.1.1"; } leaf saii { type uint32; description "Source Attachment Individual Identifier (SAII)."; reference "RFC 4667: Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP), Section 3"; } list remote-targets { key "taii"; description "List of allowed target Attachment IndividualIdentifier (AII)Identifiers (AIIs) and peers."; reference "RFC 4667: Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP), Section 5"; leaf taii { type uint32; description "Target Attachment Individual Identifier."; reference "RFC 4667: Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP), Section 3"; } leaf peer-addr { type inet:ip-address; description "Indicates the peer forwarder's IP address."; } } choice ldp-or-l2tp { description "Choice of LDP or L2TP-signaled PWs."; case ldp { description "Container for T-LDP PW configurations."; leaf t-ldp-pw-type { type identityref { base t-ldp-pw-type; } description "T-LDP PW type."; } leaf pw-type { type identityref { base ldp-pw-type; } description "PW encapsulation type."; reference "RFC 4762: Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, Section 6.1.1"; } leaf pw-description { type string; description "Includes a human-readable description of the interface. This may be used when communicating with a remote peer."; reference "RFC 4762: Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, Section 6.1.1"; } leaf mac-addr-withdraw { type boolean; description "If set to 'true', then MAC address withdrawal is enabled. If 'false', then MAC address withdrawal is disabled."; reference "RFC 4762: Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, Section 6.2"; } list pw-peer-list { key "peer-addr vc-id"; description "List ofACattachment circuit (AC) and PW bindings."; leaf peer-addr { type inet:ip-address; description "Indicates the peer's IP address."; } leaf vc-id { type string; description "VC label used to identify a PW."; } leaf pw-priority { type uint32; description "Defines the priority for the PW. The higher the pw-priority value, the higher the preference of the PW will be."; } } container qinq { when "derived-from-or-self(" + "../t-ldp-pw-type, 'hvpls')" { description "Only applies whent-ldp pwT-LDP PW type ish-vpls.";H-VPLS."; } description "Container for QinQ."; leaf s-tag { type dot1q-types:vlanid; mandatory true; description "S-TAG."; } leaf c-tag { type dot1q-types:vlanid; mandatory true; description "C-TAG."; } } } case l2tp { description "Container for L2TP PWs."; leaf router-id { type rt-types:router-id; description "A 32-bit number in the dotted-quad format that is used to uniquely identify a node within a service provider network."; reference "RFC 4667: Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP), Section 4.2"; } leaf pseudowire-type { type identityref { base iana-pw-types:iana-pw-types; } description "Encapsulation type."; reference "RFC 4667: Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP), Section 4.2"; } } } } } } container vpn-network-accesses { description "Main container for VPN network accesses."; list vpn-network-access { key "id"; description "List of VPN network accesses."; leaf id { type vpn-common:vpn-id; description "Identifier of the networkaccess";access."; } leaf description { type string; description "A textual description of the VPN network access."; } leaf interface-id { type string; description "Refers to a physical or logical interface."; } leaf active-vpn-node-profile { type leafref { path "../../.." + "/active-global-parameters-profiles" + "/global-parameters-profile/profile-id"; } description "An identifier of an active VPN instance profile."; } uses vpn-common:service-status; container connection { description "Container for the bearer and AC."; leaf l2-termination-point { type string; description "Specifies a reference to a local Layer 2 termination point such as a Layer 2 sub-interface."; } leaf local-bridge-reference { type string; description "Specifies a local bridge reference to accommodate, for example, implementations that require internal bridging. A reference may be a local bridge domain."; } leaf bearer-reference { if-feature "vpn-common:bearer-reference"; type string; description "This is an internal reference for the service provider to identify the bearer associated with this VPN."; } container encapsulation { description "Container for Layer 2 encapsulation."; leaf encap-type { type identityref { base vpn-common:encapsulation-type; } default "vpn-common:priority-tagged"; description "Tagged interface type. By default, the type of the tagged interface is 'priority-tagged'."; } container dot1q { when "derived-from-or-self(../encap-type, " + "'vpn-common:dot1q')" { description "Only applies when the type of the tagged interface is 'dot1q'."; } description "Tagged interface."; leaf tag-type { type identityref { base vpn-common:tag-type; } default "vpn-common:c-vlan"; description "Tag type. By default, the tag type is 'c-vlan'."; } leaf cvlan-id { type dot1q-types:vlanid; description "VLAN identifier."; } container tag-operations { description "Sets the tag manipulation policy for this VPN network access. It defines a set of tag manipulations that allow for the insertion, removal, or rewriting of 802.1Q VLAN tags. These operations are indicated for the CE-PE direction. By default, tag operations are symmetric. As such, the reverse tag operation is assumed on the PE-CE direction."; choice op-choice { description "Selects the tag rewriting policy for a VPN network access."; leaf pop { type empty; description "Pop the outer tag."; } leaf push { type empty; description"Push"Pushes one or two tags defined by the tag-1 and tag-2 leaves. It is assumed that, absent any policy, the default value of 0 will be used for the PCP setting."; } leaf translate { type empty; description"Translate"Translates the outer tag to one or two tags. PCP bits are preserved."; } } leaf tag-1 { when 'not(../pop)'; type dot1q-types:vlanid; description "A first tag to be used for push or translate operations. This tag will be used as the outermost tag as a result of the tag operation."; } leaf tag-1-type { type dot1q-types:dot1q-tag-type; default "dot1q-types:s-vlan"; description "Specifies a specific 802.1Q tag type of tag-1."; } leaf tag-2 { when '(../translate)'; type dot1q-types:vlanid; description "A second tag to be used for translation."; } leaf tag-2-type { type dot1q-types:dot1q-tag-type; default "dot1q-types:c-vlan"; description "Specifies a specific 802.1Q tag type of tag-2."; } } } container priority-tagged { when "derived-from-or-self(../encap-type, " + "'vpn-common:priority-tagged')" { description "Only applies when the type of the tagged interface is 'priority-tagged'."; } description "Priority tagged container."; leaf tag-type { type identityref { base vpn-common:tag-type; } default "vpn-common:c-vlan"; description "Tag type. By default, the tag type is 'c-vlan'."; } } container qinq { when "derived-from-or-self(../encap-type, " + "'vpn-common:qinq')" { description "Only applies when the type of the tagged interface isQinQ.";'QinQ'."; } description "Includes QinQ parameters."; leaf tag-type { type identityref { base vpn-common:tag-type; } default "vpn-common:s-c-vlan"; description "Tag type. By default, the tag type is 's-c-vlan'."; } leaf svlan-id { type dot1q-types:vlanid; mandatory true; description "S-VLAN identifier."; } leaf cvlan-id { type dot1q-types:vlanid; mandatory true; description "C-VLAN identifier."; } container tag-operations { description "Sets the tag manipulation policy for this VPN network access. It defines a set of tag manipulations that allow for the insertion, removal, or rewriting of 802.1Q VLAN tags. These operations are indicated for the CE-PE direction. By default, tag operations are symmetric. As such, the reverse tag operation is assumed on the PE-CE direction."; choice op-choice { description "Selects the tag rewriting policy for a VPN network access."; leaf pop { type uint8 { range "1|2"; } description"Pop"Pops one or two tags as a function of the indicated pop value."; } leaf push { type empty; description"Push"Pushes one or two tags defined by the tag-1 and tag-2 leaves. It is assumed that, absent any policy, the default value of 0 will be used for PCP setting."; } leaf translate { type uint8 { range "1|2"; } description"Translate"Translates one or two outer tags. PCP bits are preserved. The following operations are supported: - translate 1 with tag-1 leaf is provided: only the outermost tag is translated to the value in tag-1. - translate 2 with both tag-1 and tag-2 leaves are provided: both outer and inner tags are translated to the values in tag-1 and tag-2, respectively. - translate 2 with tag-1 leaf is provided: the outer tag is popped while the inner tag is translated to the value in tag-1."; } } leaf tag-1 { when 'not(../pop)'; type dot1q-types:vlanid; description "A first tag to be used for push or translate operations. This tag will be used as the outermost tag as a result of the tag operation."; } leaf tag-1-type { type dot1q-types:dot1q-tag-type; default "dot1q-types:s-vlan"; description "Specifies a specific 802.1Q tag type of tag-1."; } leaf tag-2 { when 'not(../pop)'; type dot1q-types:vlanid; description "A second tag to be used for push or translate operations."; } leaf tag-2-type { type dot1q-types:dot1q-tag-type; default "dot1q-types:c-vlan"; description "Specifies a specific 802.1Q tag type of tag-2."; } } } } container lag-interface { if-feature "vpn-common:lag-interface"; description "Container of LAG interface attributes configuration."; leaf lag-interface-id { type string; description "LAG interface identifier."; } container lacp { description "Container for LACP."; leaf lacp-state { type boolean; default "false"; description "Controls whether LACP is enabled."; } leaf mode { type identityref { base lacp-mode; } description "Indicates the LACP mode."; } leaf speed { type uint32; units "mbps"; default "10"; description "LACP speed. This low default value is inherited from the L2SM."; } leaf mini-link-num { type uint32; description "Defines the minimum number of links that must be active before the aggregating link is put into service."; } leaf system-id { type yang:mac-address; description "Indicates the System ID used by LACP."; } leaf admin-key { type uint16; description "Indicates the value of the key used for the aggregate interface."; } leaf system-priority { type uint16 { range "0..65535"; } default "32768"; description "Indicates the LACP priority for the system."; } container member-link-list { description "Container of Member link list."; list member-link { key "name"; description "Member link."; leaf name { type string; description "Member link name."; } leaf speed { type uint32; units "mbps"; default "10"; description "Port speed."; } leaf mode { type identityref { base vpn-common:neg-mode; } description "Negotiation mode."; } leaf link-mtu { type uint32; units "bytes"; description "Link MTU size."; } container oam-802.3ah-link { if-feature "oam-3ah"; description "Container foroamthe OAM 802.3ah link."; leaf enable { type boolean; default "false"; description "Indicates support of the OAM 802.3ah link."; } } } } leaf flow-control { type boolean; default "false"; description "Indicates whether flow control is supported."; } leaf lldp { type boolean; default "false"; description "Indicates whether the Link Layer Discovery Protocol (LLDP) is supported."; } } container split-horizon { description "Configuration withsplit horizonSplit Horizon enabled."; leaf group-name { type string; description "Group name of the Split Horizon."; } } } } choice signaling-option { description "Choice for the signaling-option."; case bgp { description "BGP is used as the signaling protocol."; choice bgp-type { description "Choice for the BGP type."; case l2vpn-bgp { description "Container for BGP L2VPN."; leaf ce-id { type uint16; description "Identifies the CE within the VPN."; reference "RFC 6624: Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling"; } leaf remote-ce-id { type uint16; description "Indicates the identifier of the remote CE."; } container vpls-instance { when "derived-from-or-self(../../../../../" + "vpn-type, 'vpn-common:vpls')" { description "Only applies for VPLS."; } description "VPLS instance."; leaf vpls-edge-id { type uint16; description "VPLS Edge Identifier (VE ID)."; reference "RFC 4761: Virtual Private LAN Service (VPLS) Using BGP for Auto- Discovery and Signaling, Section 3.2.1"; } } } case evpn-bgp { description "Used for EVPN."; leaf df-preference { type uint16; default "32767"; description "Defines a 2-octet value that indicates the PE preference to become the DF in the ES. The preference value is only applicable to thepreference basedpreference-based method."; reference "RFC 8584: Framework for Ethernet VPN Designated Forwarder Election Extensibility"; } container vpws-service-instance { when "derived-from-or-self(../../../../../" + "vpn-type, 'vpn-common:vpws-evpn')" { description "Only applies for EVPN-VPWS."; } description "Local and remote VPWS Service Instance (VSI)"; reference "RFC 8214: Virtual Private Wire Service Support in Ethernet VPN"; choice local-vsi-choice { description "Choices for assigning local VSI."; case directly-assigned { description "Explicitly assign a local VSI."; leaf local-vpws-service-instance { type uint32 { range "1..16777215"; } description "Indicates the assigned local VSI."; } } case auto-assigned { description "The local VSI is auto-assigned."; container local-vsi-auto { description "The local VSI is auto-assigned."; choice auto-mode { description "Indicates the auto-assignment mode of local VSI. VSI can be automatically assigned either with or without indicating a pool from which the VSI should be taken. For both cases, the server will auto-assign a local VSI value and use that value."; case from-pool { leaf vsi-pool-name { type string; description "The auto-assignment will be made from this pool."; } } case full-auto { leaf auto { type empty; description "Indicates that a local VSI is fully auto-assigned."; } } } leaf auto-local-vsi { type uint32 { range "1..16777215"; } config false; description "The value of the auto-assigned local VSI."; } } } } choice remote-vsi-choice { description "Choice for assigning the remote VSI."; case directly-assigned { description "Explicitly assign a remote VSI."; leaf remote-vpws-service-instance { type uint32 { range "1..16777215"; } description "Indicates the value of the remote VSI."; } } case auto-assigned { description "The remote VSI is auto-assigned."; container remote-vsi-auto { description "The remote VSI is auto-assigned."; choice auto-mode { description "Indicates the auto-assignment mode of remote VSI. VSI can be automatically assigned either with or without indicating a pool from which the VSI should be taken. For both cases, the server will auto-assign a remote VSI value and use that value."; case from-pool { leaf vsi-pool-name { type string; description "The auto-assignment will be made from this pool."; } } case full-auto { leaf auto { type empty; description "Indicates that a remote VSI is fully auto-assigned."; } } } leaf auto-remote-vsi { type uint32 { range "1..16777215"; } config false; description "The value of the auto-assigned remote VSI."; } } } } } } } } } list group { key "group-id"; description "List of group-ids."; leaf group-id { type string; description "Indicates the group-id to which the network access belongs to."; } leaf precedence { type identityref { base precedence-type; } description"Defining"Defines service redundancy in transport network."; } leaf ethernet-segment-identifier { type l2vpn-es:es-ref; description "Reference to the ESI associated with the VPN network access."; } } container ethernet-service-oam { description "Container for Ethernet service OAM."; leaf md-name { type string; description "Maintenance domain name."; } leaf md-level { type uint8; description "Maintenance domain level."; } container cfm-802.1-ag { description "Container of 802.1ag CFM configurations."; list n2-uni-c { key "maid"; description "List of UNI-N to UNI-C."; uses cfm-802; } list n2-uni-n { key "maid"; description "List of UNI-N to UNI-N."; uses cfm-802; } } uses y-1731; } container service { description "Container for service"; leaf mtu { type uint32; units "bytes"; description "Layer 2MTU,MTU; it is also known as the maximum transmission unit or maximum frame size."; } container svc-pe-to-ce-bandwidth { if-feature "vpn-common:inbound-bw"; description "From the customer site's perspective, the service inbound bandwidth of the connection or download bandwidth from the service provider to the site. Note that the L2SM uses 'input-bandwidth' to refer to the same concept."; list pe-to-ce-bandwidth { key "bw-type"; description "List for PE-to-CE bandwidth data nodes."; leaf bw-type { type identityref { base vpn-common:bw-type; } description "Indicates the bandwidth type."; } choice type { description "Choice based upon bandwidth type."; case per-cos { description "Bandwidth per CoS."; list cos { key "cos-id"; description "List ofclassClass ofservices.";Services."; leaf cos-id { type uint8; description "Identifier of the CoS, indicated byDSCPa Differentiated Services Code Point (DSCP) or a CE-CLAN CoS (802.1p) value in the service frame."; reference "IEEE Std 802.1Q: Bridges and Bridged Networks"; } uses bandwidth-parameters; } } case other { description "Other bandwidth types."; uses bandwidth-parameters; } } } } container svc-ce-to-pe-bandwidth { if-feature "vpn-common:outbound-bw"; description "From the customer site's perspective, the service outbound bandwidth of the connection or upload bandwidth from the CE to the PE. Note that the L2SM uses 'output-bandwidth' to refer to the same concept."; list ce-to-pe-bandwidth { key "bw-type"; description "List for CE-to-PE bandwidth."; leaf bw-type { type identityref { base vpn-common:bw-type; } description "Indicates the bandwidth type."; } choice type { description "Choice based upon bandwidth type."; case per-cos { description "Bandwidth per CoS."; list cos { key "cos-id"; description "List ofclassClass ofservices.";Services."; leaf cos-id { type uint8; description "Identifier of the CoS, indicated by DSCP or a CE-CLAN CoS (802.1p) value in the service frame."; reference "IEEE Std 802.1Q: Bridges and Bridged Networks"; } uses bandwidth-parameters; } } case other { description "Other non CoS-aware bandwidth types."; uses bandwidth-parameters; } } } } container qos { if-feature "vpn-common:qos"; description "QoS configuration."; container qos-classification-policy { description "Configuration of the traffic classification policy."; list rule { key "id"; ordered-by user; description "List of classification rules."; leaf id { type string; description "A description identifying the QoS classification policy rule."; } choice match-type { default "match-flow"; description "Choice for classification."; case match-flow { container match-flow { description "Describes flow-matching criteria."; leaf dscp { type inet:dscp; description "DSCP value."; } leaf dot1q { type uint16; description "802.1Q matching. It is a VLAN tag added into a frame."; reference "IEEE Std 802.1Q: Bridges and Bridged Networks"; } leaf pcp { type uint8 { range "0..7"; } description "Priority Code Point (PCP) value."; } leaf src-mac-address { type yang:mac-address; description "Source MAC address."; } leaf dst-mac-address { type yang:mac-address; description "Destination MAC address."; } leaf color-type { type identityref { base color-type; } description "Color type."; } leaf any { type empty; description "Allows all."; } } } case match-application { leaf match-application { type identityref { base vpn-common:customer-application; } description "Defines the application to match."; } } } leaf target-class-id { type string; description "Identification of the CoS. This identifier is internal to the administration."; } } } container qos-profile { description "QoS profile configuration."; list qos-profile { key "profile"; description "QoS profile. Can be a standardprofileor customized profile."; leaf profile { type leafref { path "/l2vpn-ntw/vpn-profiles" + "/valid-provider-identifiers" + "/qos-profile-identifier/id"; } description "QoS profile to be used."; } leaf direction { type identityref { base vpn-common:qos-profile-direction; } default "vpn-common:both"; description "The direction to which the QoS profile is applied."; } } } } container mac-policies { description "Container for MAC-related policies."; list access-control-list { key "name"; description "Container foraccess control List.";the Access Control List (ACL)."; leaf name { type string; description "Specifies the name of the ACL."; } leaf-list src-mac-address { type yang:mac-address; description "Specifies the source MAC address."; } leaf-list src-mac-address-mask { type yang:mac-address; description "Specifies the source MAC address mask."; } leaf-list dst-mac-address { type yang:mac-address; description "Specifies the destination MAC address."; } leaf-list dst-mac-address-mask { type yang:mac-address; description "Specifies the destination MAC address mask."; } leaf action { type identityref { base mac-action; } default "drop"; description "Specifies the filtering action."; } leaf rate-limit { when "derived-from-or-self(../action, " + "'flood')" { description "Rate-limit is valid only when the action is to accept the matching frame."; } type decimal64 { fraction-digits 2; } units "bytes per second"; description "Specifies how to rate-limit the traffic."; } } container mac-loop-prevention { description "Container of MAC loop prevention."; leaf window { type uint32; units "seconds"; default "180"; description "The timer when a MAC mobility event is detected."; } leaf frequency { type uint32; default "5"; description "The number of times to detect MAC duplication, where a 'duplicate MAC address' situation has occurred and the duplicate MAC address has been added to a list of duplicate MAC addresses."; } leaf retry-timer { type uint32; units "seconds"; description "The retry timer. When the retry timer expires, the duplicate MAC address will be flushed from the MAC-VRF."; } leaf protection-type { type identityref { base loop-prevention-type; } default "trap"; description "Protection type"; } } container mac-addr-limit { description "Container of MAC-Addr limitconfigurations";configurations."; leaf limit-number { type uint16; default "2"; description "Maximum number of MAC addresses learned from the subscriber for a single service instance."; } leaf time-interval { type uint32; units "milliseconds"; default "300"; description "The aging time of themacMAC address."; } leaf action { type identityref { base mac-action; } default "warning"; description "Specifies the action when the upper limit is exceeded: drop the packet, flood the packet, or log a warning message (without dropping the packet)."; } } } container broadcast-unknown-unicast-multicast { description "Container of broadcast, unknown unicast,andor multicastconfigurations";configurations."; leaf multicast-site-type { type enumeration { enum receiver-only { description "The site only has receivers."; } enum source-only { description "The site only has sources."; } enum source-receiver { description "The site has both sources and receivers."; } } default "source-receiver"; description "Type of the multicast site."; } list multicast-gp-address-mapping { key "id"; description "List ofPort to groupport-to-group mappings."; leaf id { type uint16; description "Unique identifier for the mapping."; } leaf vlan-id { type uint32; mandatory true; description "The VLAN ID of the multicast group."; } leaf mac-gp-address { type yang:mac-address; mandatory true; description "The MAC address of the multicast group."; } leaf port-lag-number { type uint32; description "The port/LAG belonging to the multicast group."; } } leaf bum-overall-rate { type uint64; units "bps"; description "Overall rate for BUM."; } } } } } } } } } } }<CODE ENDS> ]]></artwork> </figure>]]></sourcecode> </section> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>The YANG modules specified in this documentdefinesdefine schemas for data that are designed to be accessed via network management protocols such as NETCONF <xreftarget="RFC6241"></xref>target="RFC6241" format="default"/> or RESTCONF <xreftarget="RFC8040"></xref>.target="RFC8040" format="default"/>. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) <xreftarget="RFC6242"></xref>.target="RFC6242" format="default"/>. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS <xreftarget="RFC8446"></xref>.</t>target="RFC8446" format="default"/>.</t> <t>The Network Configuration Access Control Model (NACM) <xreftarget="RFC8341"></xref>target="RFC8341" format="default"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.</t> <t>There are a number of data nodes defined in the "ietf-l2vpn-ntw" and "ietf-ethernet-segment" YANG modules that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability in the "ietf-l2vpn-ntw" and "ietf-ethernet-segment" modules:<list style="symbols"> <t>'vpn-profiles':</t> <dl> <dt>'vpn-profiles': </dt> <dd> This container includes a set of sensitive data thatinfluenceinfluences how the L3VPN service is delivered. For example, an attacker who has access to these data nodes may be able to manipulate routing policies, QoS policies, or encryption properties. These data nodes are defined with "nacm:default-deny-write" tagging <xreftarget="RFC9181"></xref>.</t> <t>'ethernet-segments'target="RFC9181" format="default"/>. </dd> <dt>'ethernet-segments' and 'vpn-services':An</dt> <dd>An attacker who is able to access network nodes can undertake various attacks, such as deleting a running L2VPN service, interrupting all the traffic of a client. In addition, an attacker may modify the attributes of a running service (e.g., QoS, bandwidth) or an ES, leading to malfunctioning of the service and therefore to SLA violations. In addition, an attacker could attempt to create an L2VPN service, add a new network access, or intercept/redirect the traffic to a non-authorized node. In addition to using NACM to prevent authorized access, such activity can be detected by adequately monitoring and tracking network configurationchanges.</t> </list></t>changes. </dd> </dl> <t>Some of the readable data nodes in the "ietf-l2vpn-ntw" YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:</t><t><list style="symbols"> <t>'customer-name'<dl> <dt>'customer-name' and 'ip-connection':An</dt> <dd>An attacker can retrieve privacy-related informationwhichthat can be used to track a customer. Disclosing such information may be consideredasa violation of the customer-provider trustrelationship.</t> </list></t>relationship. </dd> </dl> <t>Both "iana-bgp-l2-encaps" and "iana-pseudowire-types" modules define YANG identities for encapsulation/pseudowires types. These identities are intended to be referenced by other YANGmodules,modules and by themselves do not expose any nodeswhichthat arewritable,writable or contain read-onlystate,state or RPCs.</t> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <sectiontitle="Registeringnumbered="true" toc="default"> <name>Registering YANGModules"> <t>This document requests IANA to registerModules</name> <t>IANA has registered the following URIs in the "ns" subregistry within the "IETF XML Registry" <xreftarget="RFC3688"></xref>:</t> <figure> <artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps Registranttarget="RFC3688" format="default"/>:</t> <dl spacing="compact"> <dt>URI: </dt> <dd>urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps </dd> <dt>Registrant Contact:The</dt> <dd>The IESG.XML: N/A;</dd> <dt>XML: </dt> <dd>N/A; the requested URI is an XML namespace.URI: urn:ietf:params:xml:ns:yang:iana-pseudowire-types Registrant</dd> </dl> <dl spacing="compact"> <dt>URI: </dt> <dd>urn:ietf:params:xml:ns:yang:iana-pseudowire-types </dd> <dt>Registrant Contact:The</dt> <dd>The IESG.XML: N/A;</dd> <dt>XML: </dt> <dd>N/A; the requested URI is an XML namespace.URI: urn:ietf:params:xml:ns:yang:ietf-ethernet-segment Registrant</dd> </dl> <dl spacing="compact"> <dt>URI: </dt> <dd>urn:ietf:params:xml:ns:yang:ietf-ethernet-segment </dd> <dt>Registrant Contact:The</dt> <dd>The IESG.XML: N/A;</dd> <dt>XML: </dt> <dd>N/A; the requested URI is an XML namespace.URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw Registrant</dd> </dl> <dl spacing="compact"> <dt>URI: </dt> <dd>urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw </dd> <dt>Registrant Contact:The</dt> <dd>The IESG.XML: N/A;</dd> <dt>XML: </dt> <dd>N/A; the requested URI is an XMLnamespace.]]></artwork> </figure> <t>This document requests IANA to registernamespace. </dd> </dl> <t>IANA has registered the following YANG modules in the "YANG Module Names" subregistry <xreftarget="RFC6020"></xref>target="RFC6020" format="default"/> within the "YANG Parameters" registry:</t><figure> <artwork><![CDATA[ name: iana-bgp-l2-encaps namespace: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps maintained<dl spacing="compact"> <dt>name:</dt> <dd>iana-bgp-l2-encaps </dd> <dt>namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps </dd> <dt>maintained byIANA: Y prefix: iana-bgp-l2-encaps reference: RFC XXXX name: iana-pseudowire-types namespace: urn:ietf:params:xml:ns:yang:iana-pseudowire-types maintainedIANA:</dt> <dd>Y </dd> <dt>prefix:</dt> <dd>iana-bgp-l2-encaps </dd> <dt>reference:</dt> <dd>RFC 9291 </dd> </dl> <dl spacing="compact"> <dt>name:</dt> <dd>iana-pseudowire-types </dd> <dt>namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:iana-pseudowire-types </dd> <dt>maintained byIANA: Y prefix: iana-pw-types reference: RFC XXXX name: ietf-ethernet-segment namespace: urn:ietf:params:xml:ns:yang:ietf-ethernet-segment maintainedIANA:</dt> <dd>Y </dd> <dt>prefix:</dt> <dd>iana-pw-types </dd> <dt>reference:</dt> <dd>RFC 9291 </dd> </dl> <dl spacing="compact"> <dt>name:</dt> <dd>ietf-ethernet-segment </dd> <dt>namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-ethernet-segment </dd> <dt>maintained byIANA: N prefix: l2vpn-es reference: RFC XXXX name: ietf-l2vpn-ntw namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw maintainedIANA:</dt> <dd>N </dd> <dt>prefix:</dt> <dd>l2vpn-es </dd> <dt>reference:</dt> <dd>RFC 9291 </dd> </dl> <dl spacing="compact"> <dt>name:</dt> <dd>ietf-l2vpn-ntw </dd> <dt>namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw </dd> <dt>maintained byIANA: N prefix: l2vpn-ntw reference: RFC XXXX]]></artwork> </figure> <t></t>IANA:</dt> <dd>N </dd> <dt>prefix:</dt> <dd>l2vpn-ntw </dd> <dt>reference:</dt> <dd>RFC 9291 </dd> </dl> <t/> </section> <sectiontitle="BGPnumbered="true" toc="default"> <name>BGP Layer 2 EncapsulationTypes">Types</name> <t>This document defines the initial version of the IANA-maintained "iana-bgp-l2-encaps" YANG module (<xreftarget="iana-bgp"></xref>).target="iana-bgp" format="default"/>). IANAis requested to addhas added this note to theregistry:<list style="empty"> <t>BGP"YANG Module Names" registry:</t> <ul empty="true" spacing="normal"> <li>BGP Layer 2 encapsulation types must not be directly added to the "iana-bgp-l2-encaps" YANG module. They must instead be added to the "BGP Layer 2 Encapsulation Types" registry at <xreftarget="IANA-BGP-L2"></xref>.</t> </list></t>target="IANA-BGP-L2" format="default"/>.</li> </ul> <t>When a Layer 2 encapsulation type is added to the "BGP Layer 2 Encapsulation Types" registry, a new "identity" statement must be added to the "iana-bgp-l2-encaps" YANG module. The name of the "identity" is a lower-case version of the encapsulation name provided in the description. The "identity" statement should have the following sub-statements defined:</t><t><list hangIndent="15" style="hanging"> <t hangText=""base":">Contains 'bgp-l2-encaps-type'.</t> <t hangText=""description":">Replicates<dl newline="false" spacing="normal" indent="15"> <dt>"base":</dt> <dd>Contains 'bgp-l2-encaps-type'.</dd> <dt>"description":</dt> <dd>Replicates the description from theregistry.</t> <t hangText=""reference":">Replicatesregistry.</dd> <dt>"reference":</dt> <dd>Replicates the reference from the registry with the title of the documentadded.</t> </list></t>added.</dd> </dl> <t>Unassigned or reserved values are not present in the module.</t> <t>When the "iana-bgp-l2-encaps" YANG module is updated, a new "revision" statement with a unique revision date must be added in front of the existing revision statements.</t> <t>IANAis requested to addhas added this note to <xreftarget="IANA-BGP-L2"></xref>:</t> <t><list style="empty"> <t>Whentarget="IANA-BGP-L2" format="default"/>:</t> <ul empty="true" spacing="normal"> <li>When this registry is modified, the YANG module "iana-bgp-l2-encaps" must be updated as defined inRFCXXXX.</t> </list></t>RFC 9291.</li> </ul> </section> <sectiontitle="Pseudowire Types">numbered="true" toc="default"> <name>Pseudowire Types</name> <t>This document defines the initial version of the IANA-maintained "iana-pseudowire-types" YANG module (<xreftarget="iana-pw"></xref>).target="iana-pw" format="default"/>). IANAis requested to addhas added this note to theregistry:<list style="empty"> <t>MPLS"YANG Module Names" registry:</t> <ul empty="true" spacing="normal"> <li>MPLS pseudowire types must not be directly added to the"iana-bgp-l2-encaps""iana-pseudowire-types" YANG module. They must instead be added to the "MPLS Pseudowire Types" registry at <xreftarget="IANA-PW-Types"></xref>.</t> </list></t>target="IANA-PW-TYPES" format="default"/>.</li> </ul> <t>When a pseudowire type is added to the "iana-pseudowire-types" registry, a new "identity" statement must be added to the "iana-pseudowire-types" YANG module. The name of the "identity" is a lower-case version of the encapsulation name provided in the description. The "identity" statement should have the following sub-statements defined:</t><t><list hangIndent="15" style="hanging"> <t hangText=""base":">Contains 'iana-pw-types'.</t> <t hangText=""description":">Replicates<dl newline="false" spacing="normal" indent="15"> <dt>"base":</dt> <dd>Contains 'iana-pw-types'.</dd> <dt>"description":</dt> <dd>Replicates the description from theregistry.</t> <t hangText=""reference":">Replicatesregistry.</dd> <dt>"reference":</dt> <dd>Replicates the reference from the registry with the title of the documentadded</t> </list></t>added.</dd> </dl> <t>Unassigned or reserved values are not present in the module.</t> <t>When the "iana-pseudowire-types" YANG module is updated, a new "revision" statement with a unique revision date must be added in front of the existing revision statements.</t> <t>IANAis requested to addhas added this note to <xreftarget="IANA-PW-Types"></xref>:</t> <t><list style="empty"> <t>Whentarget="IANA-PW-TYPES" format="default"/>:</t> <ul empty="true" spacing="normal"> <li>When this registry is modified, the YANG module "iana-pseudowire-types" must be updated as defined inRFCXXXX.</t> </list></t>RFC 9291.</li> </ul> </section> </section> </middle><!-- *****BACK MATTER ***** --><back><!-- References split into informative and normative --> <!-- There are 2 ways to insert reference entries from the citation libraries: 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.xml"?> 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 files in the same directory as the including file. You can also define the XML_LIBRARY environment variable with a value containing a set of directories to search. These can be either in the local filing system or remote ones accessed by http (http://domain/dir/... ).--> <references title="Normative References"> <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?--> &RFC3688; &RFC6242; &RFC8341; &RFC6020; &RFC6241; &RFC7950; &RFC8040; &RFC8466; &RFC8214; &RFC7432; <?rfc include='reference.RFC.9181'?> <?rfc include='reference.RFC.8342'?> <?rfc include='reference.RFC.6074'?> <?rfc include='reference.RFC.4761'?> <?rfc include='reference.RFC.4762'?> <?rfc include='reference.RFC.7623'?> <?rfc include='reference.RFC.8365'?> <?rfc include='reference.RFC.8077'?> <?rfc include='reference.RFC.6991'?> <?rfc include='reference.RFC.8294'?> <?rfc include='reference.RFC.4667'?> <?rfc include='reference.RFC.6624'?> <?rfc include='reference.RFC.4026'?> <?rfc include='reference.RFC.4446'?> <?rfc include='reference.RFC.8446'?> <?rfc include='reference.RFC.8584'?><displayreference target="I-D.ietf-bess-evpn-pref-df" to="EVPN-PERF-DF"/> <displayreference target="I-D.ietf-bess-evpn-yang" to="EVPN-YANG"/> <displayreference target="I-D.ietf-idr-bgp-model" to="BGP-YANG-MODEL"/> <displayreference target="I-D.ietf-opsawg-sap" to="YANG-SAPS"/> <displayreference target="I-D.ietf-teas-enhanced-vpn" to="VPN+-FRAMEWORK"/> <displayreference target="I-D.ietf-teas-ietf-network-slices" to="IETF-NET-SLICES"/> <displayreference target="I-D.ietf-teas-te-service-mapping-yang" to="TE-SERVICE-MAPPING"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8466.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8214.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9181.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6074.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4761.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4762.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7623.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8365.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8077.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8294.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4667.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6624.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4026.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4446.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8584.xml"/> <reference anchor="IANA-BGP-L2"target="https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-l2-encapsulation-types-registry">target="https://www.iana.org/assignments/bgp-parameters"> <front> <title>BGP Layer 2 Encapsulation Types</title> <author><organization abbrev="IANA">Internet Assigned Numbers Authority</organization><organization>IANA</organization> </author><date /><date/> </front> </reference> <referenceanchor="IANA-PW-Types" target="http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe3-parameters-2">anchor="IANA-PW-TYPES" target="http://www.iana.org/assignments/pwe3-parameters/"> <front> <title>MPLS Pseudowire Types Registry</title><author fullname="IANA"> <organization abbrev="IANA">Internet Assigned Numbers Authority</organization><author> <organization>IANA</organization> </author><date /><date/> </front> </reference> <referenceanchor="IEEE-802-1ag" target="DOI 10.1109/IEEESTD.2007.4431836">anchor="IEEE-802-1ag"> <front><title>802.1ag - 2007 - IEEE<title>IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management</title><author fullname="IEEE"> <organization></organization><author> <organization>IEEE</organization> </author> <dateyear="2007" />month="December" year="2007"/> </front> <seriesInfo name="DOI" value="10.1109/IEEESTD.2007.4431836"/> <seriesInfo name="IEEE Std" value="802.1ag-2007"/> </reference> <reference anchor="ITU-T-Y-1731" target="https://www.itu.int/rec/T-REC-Y.1731/en"> <front><title>Operations,<title>Operation, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks</title><author fullname="International Telecommunication Union"> <organization></organization><author> <organization>ITU-T</organization> </author> <date month="August"year="2015" />year="2015"/> </front> <seriesInfo name="ITU-T Recommendation" value="G.8013/Y.1731"/> </reference> <referenceanchor="IEEE802.1Qcp-2018" target="https://ieeexplore.ieee.org/document/8467507">anchor="IEEE802.1Qcp"> <front> <title>IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks--Amendment 30: YANG Data Model</title><author fullname="IEEE"> <organization></organization><author> <organization>IEEE</organization> </author> <date month="September"year="2018" />year="2018"/> </front> <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8467507"/> <seriesInfo name="IEEE Std" value="802.1Qcp-2018"/> </reference> </references><references title="Informative References"> <!-- Here we use entities that we defined at the beginning. --> &RFC8309; &RFC8340; &RFC8453; <?rfc include='reference.RFC.3644'?> <?rfc include='reference.RFC.7209'?> <?rfc include='reference.RFC.5880'?> <?rfc include='reference.RFC.8969'?> <?rfc include='reference.RFC.7297'?> <?rfc include='reference.I-D.ietf-teas-enhanced-vpn'?> <?rfc include='reference.I-D.ietf-teas-ietf-network-slices'?> <?rfc include='reference.I-D.ietf-idr-bgp-model'?> <?rfc include='reference.I-D.ietf-bess-evpn-pref-df'?> <?rfc include='reference.RFC.8345'?> <?rfc include='reference.RFC.4664'?> <?rfc include='reference.RFC.2507'?> <?rfc include='reference.RFC.2508'?> <?rfc include='reference.RFC.3032'?> <?rfc include='reference.RFC.3545'?> <?rfc include='reference.RFC.4553'?> <?rfc include='reference.RFC.4448'?> <?rfc include='reference.RFC.4618'?> <?rfc include='reference.RFC.4619'?> <?rfc include='reference.RFC.4717'?> <?rfc include='reference.RFC.4816'?> <?rfc include='reference.RFC.4842'?> <?rfc include='reference.RFC.4863'?> <?rfc include='reference.RFC.4901'?> <?rfc include='reference.RFC.5086'?> <?rfc include='reference.RFC.5087'?> <?rfc include='reference.RFC.5143'?> <?rfc include='reference.RFC.5795'?> <?rfc include='reference.RFC.6307'?> <?rfc include='reference.RFC.8343'?> <?rfc include='reference.RFC.8519'?> <?rfc include='reference.RFC.7951'?> <?rfc include='reference.RFC.8792'?> <?rfc include='reference.RFC.8960'?> <?rfc include='reference.RFC.7267'?> <?rfc include='reference.I-D.ietf-bess-evpn-yang'?> <?rfc include='reference.I-D.ietf-teas-te-service-mapping-yang'?> <?rfc include='reference.I-D.ietf-opsawg-sap'?><references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8309.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3644.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7209.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8969.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7297.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-teas-enhanced-vpn.xml"/> <reference anchor="I-D.ietf-teas-ietf-network-slices"> <front> <title>Framework for IETF Network Slices</title> <author initials="A" surname="Farrel" fullname="A. Farrel" role="editor"/> <author initials="J" surname="Drake" fullname="J. Drake" role="editor"/> <author initials="R" surname="Rokui" fullname="R. Rokui"/> <author initials="S" surname="Homma" fullname="S. Homma"/> <author initials="K" surname="Makhijani" fullname="K. Makhijani"/> <author initials="L. M." surname="Contreras" fullname="L.M. Contreras"/> <author initials="J" surname="Tantsura" fullname="J. Tantsura"/> <date month="August" day="3" year="2022"/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network-slices-14"/> </reference> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-idr-bgp-model.xml"/> <reference anchor="I-D.ietf-bess-evpn-pref-df"> <front> <title> Preference-based EVPN DF Election </title> <author initials="J" surname="Rabadan" fullname="J. Rabadan" role="editor"/> <author initials="S" surname="Sathappan" fullname="S. Sathappan"/> <author initials="W" surname="Lin" fullname="W. Lin"/> <author initials="J" surname="Drake" fullname="J. Drake"/> <author initials="A" surname="Sajassi" fullname="A. Sajassi"/> <date month="September" day="2" year="2022"/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-pref-df-10"/> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8345.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4664.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2507.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2508.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3545.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4553.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4448.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4618.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4619.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4717.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4816.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4842.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4863.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4901.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5086.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5087.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5143.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5795.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6307.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8519.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7951.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8960.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7267.xml"/> <reference anchor="I-D.ietf-bess-evpn-yang"> <front> <title> Yang Data Model for EVPN </title> <author initials="P" surname="Brissette" fullname="P. Brissette" role="editor"/> <author initials="H" surname="Shah" fullname="H. Shah" role="editor"/> <author initials="I" surname="Chen" fullname="I. Chen" role="editor"/> <author initials="I" surname="Hussain " fullname="I. Hussain " role="editor"/> <author initials="K" surname="Tiruveedhula" fullname="K. Tiruveedhula" role="editor"/> <author initials="J" surname="Rabadan" fullname="J. Rabadan" role="editor"/> <date month="March" day="11" year="2019"/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-yang-07"/> </reference> <reference anchor="I-D.ietf-teas-te-service-mapping-yang"> <front> <title> Traffic Engineering (TE) and Service Mapping YANG Data Model </title> <author initials="Y" surname="Lee" fullname="Y. Lee" role="editor"/> <author initials="D" surname="Dhody" fullname="D. Dhody" role="editor"/> <author initials="G" surname="Fioccola" fullname="G. Fioccola"/> <author initials="Q" surname="Wu" fullname="Q. Wu" role="editor"/> <author initials="D" surname="Ceccarelli" fullname="D. Ceccarelli" /> <author initials="J" surname="Tantsura" fullname="J. Tantsura"/> <date month="July" day="11" year="2022"/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-teas-te-service-mapping-yang-11"/> </reference> <reference anchor="I-D.ietf-opsawg-sap"> <front> <title> A YANG Network Model for Service Attachment Points (SAPs) </title> <author initials="M" surname="Boucadair" fullname="M. Boucadair" role="editor"/> <author initials="O" surname="Gonzalez de Dios" fullname="O. Gonzalez de Dios"/> <author initials="S" surname="Barguil" fullname="S. Barguil"/> <author initials="Q" surname="Wu" fullname="Q. Wu"/> <author initials="V" surname="Lopez" fullname="V. Lopez" /> <date month="July" day="28" year="2022"/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-sap-09"/> </reference> <reference anchor="PYANG" target="https://github.com/mbj4668/pyang"> <front> <title>pyang</title> <author><organization></organization><organization/> </author> <date month="November"year="2020" />year="2020"/> </front> </reference> <reference anchor="IEEE802.1AX"> <front><title>Link<title>IEEE Standard for Local and Metropolitan Area Networks--Link Aggregation</title> <author><organization></organization><organization>IEEE </organization> </author> <datemonth="" year="2020" />month="May" year="2020"/> </front> <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9105034" /> <seriesInfo name="IEEE" value="Std802.1AX-2020" />802.1AX-2020"/> </reference> <referenceanchor="IEEE-802-3ah" target="DOI 10.1109/IEEESTD.2004.94617">anchor="IEEE-802-3ah"> <front><title>802.3ah - 2004 - IEEE<title>IEEE Standard for Information technology-- Local and metropolitan area networks-- Part 3: CSMA/CD Access Method and Physical Layer Specifications Amendment: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks</title><author fullname="IEEE"> <organization></organization><author> <organization>IEEE</organization> </author> <datemonth="" year="2004" />month="September" year="2004"/> </front> <seriesInfoname="IEEE" value="Std 802.3AH-2004" />name="DOI" value="10.1109/IEEESTD.2004.94617"/> <seriesInfo name="IEEE Std" value="802.3AH-2004"/> </reference> <reference anchor="IEEE-802-1ah" target="https://standards.ieee.org/standard/802_1ah-2008.html"> <front> <title>IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges</title><author fullname="IEEE"> <organization></organization><author> <organization>IEEE</organization> </author> <datemonth="" year="2008" />month="August" year="2008"/> </front> <seriesInfo name="IEEE" value="Std801.3AH-2008" />801.3AH-2008"/> </reference> <referenceanchor="IEEE802.1Q" target="https://ieeexplore.ieee.org/document/8403927">anchor="IEEE802.1Q"> <front><title>Bridges<title>IEEE Standard for Local and Metropolitan Area Network--Bridges and Bridged Networks</title> <author><organization></organization><organization>IEEE</organization> </author> <dateday="06"month="July"year="2018" />year="2018"/> </front> <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8403927"/> <seriesInfo name="IEEE" value="Std802.1Q-2018" />802.1Q-2018"/> </reference> <reference anchor="MFA"> <front> <title>The Use of Virtual Trunks for ATM/MPLS Control Plane Interworking Specification</title><author fullname=""> <organization></organization><author> <organization>MFA Forum Technical Committee</organization> </author> <dateday=""month="February"year="2006" />year="2006"/> </front><seriesInfo name="MFA<refcontent>MFA Forum9.0.0" value="" />9.0.0</refcontent> </reference> </references> </references> <section anchor="examples"title="Examples">numbered="true" toc="default"> <name>Examples</name> <t>This section includes a non-exhaustive list of examples to illustrate the use of the L2NM.</t> <t>In the following subsections, only the content of the message bodies is shown using JSON notations <xreftarget="RFC7951"></xref>.</t>target="RFC7951" format="default"/>.</t> <t>The examples usethefolding as defined in <xreftarget="RFC8792"></xref>target="RFC8792" format="default"/> for long lines.</t> <section anchor="ex1"title="BGP-based VPLS">numbered="true" toc="default"> <name>BGP-Based VPLS</name> <t>This section provides an example to illustrate how the L2NM can be used to manage BGP-based VPLS. We consider the sample VPLS service delivered using the architecture depicted in <xreftarget="vpls-ex"></xref>.target="vpls-ex" format="default"/>. In accordance with <xreftarget="RFC4761"></xref>,target="RFC4761" format="default"/>, we assume that a full mesh is established between all PEs. The details about such full mesh are not detailed here.</t><t><figure align="center" anchor="vpls-ex" title="An<figure anchor="vpls-ex"> <name>An Example ofVPLS"> <artwork><![CDATA[VPLS</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +-----+ +--------------+ +-----+ +----+ | PE1 |===| |===| PE3 | +----+ | CE1+-------+ | | | | +-------+ CE3| +----+ +-----+ | | +-----+ +----+ | Core | +----+ +-----+ | | +-----+ +----+ |CE2 +-------+ | | | | +-------+ CE4| +----+ | PE2 |===| |===| PE4 | +----+ +-----+ +--------------+ +-----+ ]]></artwork></figure><xref target="l2nm-vpls"></xref> show</figure> <t><xref target="l2nm-vpls" format="default"/> shows an example of a message body used to configure a VPLS instance using the L2NM. In this example, BGP is used for both auto-discovery and signaling. The 'signaling-type' data node is set to 'vpn-common:bgp-signaling'.</t><t><figure align="center" anchor="l2nm-vpls" title="Example<figure anchor="l2nm-vpls"> <name>An Example of an L2NM Message Body to Configure aBGP-based VPLS"> <artwork><![CDATA[===============BGP-Based VPLS</name> <sourcecode type="json"><![CDATA[=============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-l2vpn-ntw:l2vpn-ntw": { "vpn-services": { "vpn-service": [ { "vpn-id": "vpls7714825356", "vpn-description": "Sample BGP-based VPLS", "customer-name": "customer-7714825356", "vpn-type": "ietf-vpn-common:vpls", "bgp-ad-enabled": true, "signaling-type": "ietf-vpn-common:bgp-signaling", "global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile", "local-autonomous-system": 65535, "svc-mtu": 1518, "rd-suffix": 1, "vpn-target": [ { "id": 1, "route-targets": [ { "route-target": "0:65535:1" } ], "route-target-type": "both" } ] } ] }, "vpn-nodes": { "vpn-node": [ { "vpn-node-id": "pe1", "ne-id": "198.51.100.1", "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "bgp-auto-discovery": { "vpn-id": "1" }, "signaling-option": { "pw-encapsulation-type":"iana-bgp-l2-encaps:ethernet\ -tagged-mode","iana-bgp-l2-encaps:\ ethernet-tagged-mode", "vpls-instance": { "vpls-edge-id": 1, "vpls-edge-id-range": 100 } }, "vpn-network-accesses": { "vpn-network-access": [ { "id": "1/1/1.1", "interface-id": "1/1/1", "description": "Interface to CE1", "active-vpn-node-profile": "simple-profile", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "connection": { "encapsulation": { "encap-type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 1 } } } } ] } }, { "vpn-node-id": "pe2", "ne-id": "198.51.100.2", "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "bgp-auto-discovery": { "vpn-id": "1" }, "signaling-option": { "pw-encapsulation-type":"iana-bgp-l2-encaps:ethernet\ -tagged-mode","iana-bgp-l2-encaps:\ ethernet-tagged-mode", "vpls-instance": { "vpls-edge-id": 2, "vpls-edge-id-range": 100 } }, "vpn-network-accesses": { "vpn-network-access": [ { "id": "1/1/1.1", "interface-id": "1/1/1", "description": "Interface to CE2", "active-vpn-node-profile": "simple-profile", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "connection": { "encapsulation": { "encap-type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 1 } } } } ] } }, { "vpn-node-id": "pe3", "ne-id": "198.51.100.3", "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "bgp-auto-discovery": { "vpn-id": "1" }, "signaling-option": { "pw-encapsulation-type":"iana-bgp-l2-encaps:ethernet\ -tagged-mode","iana-bgp-l2-encaps:\ ethernet-tagged-mode", "vpls-instance": { "vpls-edge-id": 3, "vpls-edge-id-range": 100 } }, "vpn-network-accesses": { "vpn-network-access": [ { "id": "1/1/1.1", "interface-id": "1/1/1", "description": "Interface to CE3", "active-vpn-node-profile": "simple-profile", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "connection": { "encapsulation": { "encap-type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 1 } } } } ] } }, { "vpn-node-id": "pe4", "ne-id": "198.51.100.4", "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "bgp-auto-discovery": { "vpn-id": "1" }, "signaling-option": { "pw-encapsulation-type":"iana-bgp-l2-encaps:ethernet\ -tagged-mode","iana-bgp-l2-encaps:\ ethernet-tagged-mode", "vpls-instance": { "vpls-edge-id": 4, "vpls-edge-id-range": 100 } }, "vpn-network-accesses": { "vpn-network-access": [ { "id": "1/1/1.1", "interface-id": "1/1/1", "description": "Interface to CE4", "active-vpn-node-profile": "simple-profile", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "connection": { "encapsulation": { "encap-type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 1 } } } } ] } } ] } } ] } } }]]></artwork> </figure></t> <t></t>]]></sourcecode> </figure> <t/> </section> <section anchor="ex2"title="BGP-basednumbered="true" toc="default"> <name>BGP-Based VPWS with LDPSignaling">Signaling</name> <t>Let's consider the simple architecture depicted in <xreftarget="vpws-ex"></xref>target="vpws-ex" format="default"/> to offer a VPWS between CE1 and CE2. The service uses BGP for auto-discovery and LDP for signaling.</t><t><figure align="center" anchor="vpws-ex" title="An<figure anchor="vpws-ex"> <name>An Example ofVPLS"> <artwork><![CDATA[VPLS</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +-----+ +--------------+ +-----+ +----+ | PE1 |===| |===| PE2 | +----+ | CE1+-------+ | | Core | | +-------+ CE2| +----+ +-----+ +--------------+ +-----+ +----+ site1 site2 ]]></artwork></figure></t> <t><figure align="center" anchor="l2nm-vpws-ex" title="Example</figure> <figure anchor="l2nm-vpws-ex"> <name>An Example of an L2NM Message Body to Configure aBGP-basedBGP-Based VPWS with LDPSignaling"> <artwork><![CDATA[{Signaling</name> <sourcecode type="json"><![CDATA[{ "ietf-l2vpn-ntw:l2vpn-ntw": { "vpn-services": { "vpn-service": [ { "vpn-id": "vpws12345", "vpn-description": "Sample VPWS", "customer-name": "customer-12345", "vpn-type": "ietf-vpn-common:vpws", "bgp-ad-enabled": true, "signaling-type": "ietf-vpn-common:ldp-signaling", "global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile", "local-autonomous-system": 65550, "rd-auto": { "auto": [ null ] }, "vpn-target": [ { "id": 1, "route-targets": [ { "route-target": "0:65535:1" } ], "route-target-type": "both" } ] } ] }, "vpn-nodes": { "vpn-node": [ { "vpn-node-id": "pe1", "ne-id": "2001:db8:100::1", "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "bgp-auto-discovery": { "vpn-id": "587" }, "signaling-option": { "advertise-mtu": true, "ldp-or-l2tp": { "saii": 1, "remote-targets": [ { "taii": 2 } ], "t-ldp-pw-type": "ethernet" } }, "vpn-network-accesses": { "vpn-network-access": [ { "id": "1/1/1.1", "interface-id": "1/1/1", "description": "Interface to CE1", "active-vpn-node-profile": "simple-profile", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } } } ] } }, { "vpn-node-id": "pe2", "ne-id": "2001:db8:200::1", "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "bgp-auto-discovery": { "vpn-id": "587" }, "signaling-option": { "advertise-mtu": true, "ldp-or-l2tp": { "saii": 2, "remote-targets": [ { "taii": 1 } ], "t-ldp-pw-type": "ethernet" } }, "vpn-network-accesses": { "vpn-network-access": [ { "id": "5/1/1.1", "interface-id": "5/1/1", "description": "Interface to CE2", "active-vpn-node-profile": "simple-profile", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } } } ] } } ] } } ] } } }]]></artwork> </figure></t> <t></t>]]></sourcecode> </figure> <t/> </section> <section anchor="ex3"title="LDP-based VPLS">numbered="true" toc="default"> <name>LDP-Based VPLS</name> <t>This section provides an exampleto illustratethat illustrates how the L2NM can be used to manage a VPLS with LDP signaling. The connectivity between the CE and the PE is direct using Dot1q encapsulation <xreftarget="IEEE802.1Q"></xref>.target="IEEE802.1Q" format="default"/>. We consider the sample service delivered using the architecture depicted in <xreftarget="vpls-ldp-ex"></xref>.</t> <t><figure align="center" anchor="vpls-ldp-ex" title="Antarget="vpls-ldp-ex" format="default"/>.</t> <figure anchor="vpls-ldp-ex"> <name>An Example of VPLStopology "> <artwork><![CDATA[Topology</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +---------- VPLS "1543" ----------+ +-----+ +--------------+ +-----+ +----+ | PE1 |===| |===| PE2 | +----+ | CE1 +-----+"450"| | MPLS | |"451"+-------+ CE2| +----+ +-----+ | | +-----+ +----+ | Core | +--------------+ ]]></artwork></figure></t></figure> <t><xreftarget="vpls-ldp-call"></xref>target="vpls-ldp-call" format="default"/> shows how the L2NM is used to instruct both PE1 and PE2 to use the targeted LDP session between them to establish the VPLS "1543" between the ends. A single VPN service is created for this purpose. Additionally, two VPN Nodesandthat eachwith ahave corresponding VPN network accessisare also created.</t><t><figure align="center" anchor="vpls-ldp-call" title="Example<figure anchor="vpls-ldp-call"> <name>An Example of an L2NM Message Body forLDP-based VPLS"> <artwork align="center"><![CDATA[===============LDP-Based VPLS</name> <sourcecode type="json"><![CDATA[=============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-l2vpn-ntw:l2vpn-ntw": { "vpn-services": { "vpn-service": [ { "vpn-id": "450", "vpn-name": "CORPO-EXAMPLE", "vpn-description": "SEDE_CENTRO_450", "customer-name": "EXAMPLE", "vpn-type": "ietf-vpn-common:vpls", "vpn-service-topology": "ietf-vpn-common:hub-spoke", "bgp-ad-enabled": false, "signaling-type": "ietf-vpn-common:ldp-signaling", "global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile", "ce-vlan-preservation": true, "ce-vlan-cos-preservation": true } ] }, "vpn-nodes": { "vpn-node": [ { "vpn-node-id": "450", "description": "SEDE_CENTRO_450", "ne-id": "2001:db8:5::1", "role": "ietf-vpn-common:hub-role", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "signaling-option": { "ldp-or-l2tp": { "t-ldp-pw-type": "vpls-type", "pw-peer-list": [ { "peer-addr": "2001:db8:50::1", "vc-id": "1543" } ] } }, "vpn-network-accesses": { "vpn-network-access": [ { "id": "4508671287", "description": "VPN_450_SNA", "interface-id": "gigabithethernet0/0/1", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "connection": { "l2-termination-point": "550", "encapsulation": { "encap-type": "ietf-vpn-common:dot1q", "dot1q": { "tag-type": "ietf-vpn-common:c-vlan", "cvlan-id": 550 } } }, "service": { "mtu": 1550, "svc-pe-to-ce-bandwidth": { "pe-to-ce-bandwidth": [ { "bw-type":"ietf-vpn-common:bw-per-port","ietf-vpn-common:\ bw-per-port", "cir": "20480000" } ] }, "svc-ce-to-pe-bandwidth": { "ce-to-pe-bandwidth": [ { "bw-type":"ietf-vpn-common:bw-per-port","ietf-vpn-common:\ bw-per-port", "cir": "20480000" } ] }, "qos": { "qos-profile": { "qos-profile": [ { "profile": "QoS_Profile_A", "direction": "ietf-vpn-common:both" } ] } } } } ] } }, { "vpn-node-id": "451", "description": "SEDE_CHAPINERO_451", "ne-id": "2001:db8:50::1", "role": "ietf-vpn-common:spoke-role", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "signaling-option": { "ldp-or-l2tp": { "t-ldp-pw-type": "vpls-type", "pw-peer-list": [ { "peer-addr": "2001:db8:5::1", "vc-id": "1543" } ] } }, "vpn-network-accesses": { "vpn-network-access": [ { "id": "4508671288", "description": "VPN_450_SNA", "interface-id": "gigabithethernet0/0/1", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "connection": { "l2-termination-point": "550", "encapsulation": { "encap-type": "ietf-vpn-common:dot1q", "dot1q": { "tag-type": "ietf-vpn-common:c-vlan", "cvlan-id": 550 } } }, "service": { "mtu": 1550, "svc-pe-to-ce-bandwidth": { "pe-to-ce-bandwidth": [ { "bw-type":"ietf-vpn-common:bw-per-port","ietf-vpn-common:\ bw-per-port", "cir": "20480000" } ] }, "svc-ce-to-pe-bandwidth": { "ce-to-pe-bandwidth": [ { "bw-type":"ietf-vpn-common:bw-per-port","ietf-vpn-common:\ bw-per-port", "cir": "20480000" } ] }, "qos": { "qos-profile": { "qos-profile": [ { "profile": "QoS_Profile_A", "direction": "ietf-vpn-common:both" } ] } } } } ] } } ] } } ] } } }]]></artwork> </figure></t>]]></sourcecode> </figure> </section> <section anchor="evpn-vpws-app"title="VPWS-EVPNnumbered="true" toc="default"> <name>VPWS-EVPN ServiceInstance">Instance</name> <t><xreftarget="vpws-evpn-ex"></xref>target="vpws-evpn-ex" format="default"/> depicts a sample architecture to offer VPWS-EVPN service between CE1 and CE2. Both CEs aremulti-homed.multihomed. BGP sessions are maintained between these PEs as per <xreftarget="RFC8214"></xref>.target="RFC8214" format="default"/>. In this EVPN instance, an All-Active redundancy mode is used.</t><t><figure align="center" anchor="vpws-evpn-ex" title="An<figure anchor="vpws-evpn-ex"> <name>An Example ofVPWS-EVPN"> <artwork><![CDATA[VPWS-EVPN</name> <artwork name="" type="" align="left" alt=""><![CDATA[ |<-------- EVPN Instance --------->| | | ESI1 V V ESI2 | +-----+ +--------------+ +-----+ | +----+ | | PE1 |===| |===| PE3 | | +----+ | +-------+ | | | | +-------+ | | | | +-----+ | | +-----+ | | | | CE1| | | Core | | |CE2 | | | | +-----+ | | +-----+ | | | | +-------+ | | | | +-------+ | +----+ | | PE2 |===| |===| PE4 | | +----+ ^ | +-----+ +--------------+ +-----+ | ^ | ESI1 ESI2 | |<-------------- Emulated Service ---------------->|]]></artwork></figure></t></figure> <t>Let's first suppose that the following ES was created (<xreftarget="es1"></xref>).</t> <t><figure align="center" anchor="es1" title="Exampletarget="es1" format="default"/>).</t> <figure anchor="es1"> <name>An Example of an L2NM Message Body to Configure an EthernetSegment"> <artwork><![CDATA[===============Segment</name> <sourcecode type="json"><![CDATA[=============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-ethernet-segment:ethernet-segments": { "ethernet-segment": [ { "name": "esi1", "ethernet-segment-identifier": "00:11:11:11:11:11:11:\ 11:11:11", "esi-redundancy-mode": "all-active" }, { "name": "esi2", "ethernet-segment-identifier": "00:22:22:22:22:22:22:\ 22:22:22", "esi-redundancy-mode": "all-active" } ] }}]]></artwork> </figure><xref target="vpws-evpn-ex"></xref>}]]></sourcecode> </figure> <t><xref target="l2nm-vpws-evpn" format="default"/> shows a simplified configuration to illustrate the use of the L2NM toconfiguredconfigure a VPWS-EVPN instance.</t><t><figure align="center" anchor="l2nm-vpws-evpn" title="Example<figure anchor="l2nm-vpws-evpn"> <name>An Example of an L2NM Message Body to Configure a VPWS-EVPNInstance"> <artwork><![CDATA[{Instance</name> <sourcecode type="json"><![CDATA[{ "ietf-l2vpn-ntw:l2vpn-ntw": { "vpn-services": { "vpn-service": [ { "vpn-id": "vpws15432855", "vpn-description": "Sample VPWS-EVPN", "customer-name": "customer_15432855", "vpn-type": "ietf-vpn-common:vpws-evpn", "bgp-ad-enabled": true, "signaling-type": "ietf-vpn-common:bgp-signaling", "global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile", "local-autonomous-system": 65535, "rd-suffix": 1, "vpn-target": [ { "id": 1, "route-targets": [ { "route-target": "0:65535:1" } ], "route-target-type": "both" } ] } ] }, "vpn-nodes": { "vpn-node": [ { "vpn-node-id": "pe1", "ne-id": "198.51.100.1", "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "vpn-network-accesses": { "vpn-network-access": [ { "id": "1/1/1.1", "interface-id": "1/1/1", "description": "Interface to CE1", "active-vpn-node-profile": "simple-profile", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "connection": { "encapsulation": { "encap-type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 1 } } }, "vpws-service-instance": { "local-vpws-service-instance": 1111, "remote-vpws-service-instance": 1112 }, "group": [ { "group-id": "gr1", "ethernet-segment-identifier": "esi1" } ] } ] } }, { "vpn-node-id": "pe2", "ne-id": "198.51.100.2", "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "vpn-network-accesses": { "vpn-network-access": [ { "id": "1/1/1.1", "interface-id": "1/1/1", "description": "Interface to CE1", "active-vpn-node-profile": "simple-profile", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "connection": { "encapsulation": { "encap-type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 1 } } }, "vpws-service-instance": { "local-vpws-service-instance": 1111, "remote-vpws-service-instance": 1112 }, "group": [ { "group-id": "gr1", "ethernet-segment-identifier": "esi1" } ] } ] } }, { "vpn-node-id": "pe3", "ne-id": "198.51.100.3", "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "vpn-network-accesses": { "vpn-network-access": [ { "id": "1/1/1.1", "interface-id": "1/1/1", "description": "Interface to CE2", "active-vpn-node-profile": "simple-profile", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "connection": { "encapsulation": { "encap-type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 1 } } }, "vpws-service-instance": { "local-vpws-service-instance": 1112, "remote-vpws-service-instance": 1111 }, "group": [ { "group-id": "gr1", "ethernet-segment-identifier": "esi2" } ] } ] } }, { "vpn-node-id": "pe4", "ne-id": "198.51.100.4", "active-global-parameters-profiles": { "global-parameters-profile": [ { "profile-id": "simple-profile" } ] }, "vpn-network-accesses": { "vpn-network-access": [ { "id": "1/1/1.1", "interface-id": "1/1/1", "description": "Interface to CE2", "active-vpn-node-profile": "simple-profile", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "connection": { "encapsulation": { "encap-type": "ietf-vpn-common:dot1q", "dot1q": { "cvlan-id": 1 } } }, "vpws-service-instance": { "local-vpws-service-instance": 1112, "remote-vpws-service-instance": 1111 }, "group": [ { "group-id": "gr1", "ethernet-segment-identifier": "esi2" } ] } ] } } ] } } ] } } }]]></artwork> </figure></t> <t></t>]]></sourcecode> </figure> <t/> </section> <section anchor="auto-ex"title="Automaticnumbered="true" toc="default"> <name>Automatic ESIAssignment">Assignment</name> <t>This section provides an example to illustrate how the L2NM can be used to manage ESI auto-assignment. We consider the sample EVPN service delivered using the architecture depicted in <xreftarget="auto-esi-ex"></xref>.</t> <t><figure align="center" anchor="auto-esi-ex" title="Antarget="auto-esi-ex" format="default"/>.</t> <figure anchor="auto-esi-ex"> <name>An Example of Automatic ESIAssignment "> <artwork><![CDATA[Assignment</name> <artwork name="" type="" align="left" alt=""><![CDATA[ ES | +-----+ +--------------+ +-----+ +----+ | | PE1 |======| |===| PE3 | +----+ | +-------+ | | | | +-------+ CE3| | | | +-----+ | | +-----+ +----+ | CE1| | | Core | | | | +-----+ | | +-----+ +----+ | +-------+ | | | | +-------+ CE2| +----+ | | PE2 |======| |===| PE4 | +----+ | +-----+ +--------------+ +-----+ LACP ]]></artwork></figure></t> <t><xref target="es2"></xref></figure> <t>Figures <xref target="es2" format="counter"/> and <xreftarget="auto-lacp"></xref>target="auto-lacp" format="counter"/> show how the L2NM is used to instruct both PE1 and PE2 to auto-assign the ESI to identify the ES used with CE1. In this example, we suppose that LACP is enabled and that a Type 1 (T=0x01) is used as perSection 5 of<xreftarget="RFC7432"></xref>.target="RFC7432" sectionFormat="of" section="5" format="default"/>. Note that this example does not include all the details to configure the EVPNservice,service but focuses only on the ESI management part.</t><t><figure align="center" anchor="es2" title="Example<figure anchor="es2"> <name>An Example of an L2NM Message Body to Auto-Assign Ethernet SegmentIdentifiers"> <artwork><![CDATA[{Identifiers</name> <sourcecode type="json"><![CDATA[{ "ietf-ethernet-segment:ethernet-segments": { "ethernet-segment": [ { "name": "esi1", "esi-type": "esi-type-1-lacp", "esi-redundancy-mode": "all-active" } ] }}]]></artwork> </figure></t> <t><figure align="center" anchor="auto-lacp" title="An}]]></sourcecode> </figure> <figure anchor="auto-lacp"> <name>An Example of an L2NM Message Body for ESIAuto-Assignment"> <artwork><![CDATA[{Auto-Assignment</name> <sourcecode type="json"><![CDATA[{ "ietf-l2vpn-ntw:l2vpn-ntw": { "ietf-l2vpn-ntw:vpn-services": { "vpn-service": [ { "vpn-id": "auto-esi-lacp", "vpn-description": "Sample to illustrate auto-ESI", "vpn-type": "ietf-vpn-common:vpws-evpn", "vpn-nodes": { "vpn-node": [ { "vpn-node-id": "pe1", "ne-id": "198.51.100.1", "vpn-network-accesses": { "vpn-network-access": [ { "id": "1/1/1.1", "interface-id": "1/1/1", "description": "Interface to CE1", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "connection": { "lag-interface": { "lag-interface-id": "1", "lacp": { "lacp-state": true, "system-id": "11:00:11:00:11:11", "admin-key": 154 } } }, "group": [ { "group-id": "gr1", "ethernet-segment-identifier": "esi1" } ] } ] } }, { "vpn-node-id": "pe2", "ne-id": "198.51.100.2", "vpn-network-accesses": { "vpn-network-access": [ { "id": "2/2/2.5", "interface-id": "2/2/2", "description": "Interface to CE1", "status": { "admin-status": { "status": "ietf-vpn-common:admin-up" } }, "connection": { "lag-interface": { "lag-interface-id": "1", "lacp": { "lacp-state": true, "system-id": "11:00:11:00:11:11", "admin-key": 154 } } }, "group": [ { "group-id": "gr1", "ethernet-segment-identifier": "esi1" } ] } ] } } ] } } ] } } }]]></artwork> </figure></t>]]></sourcecode> </figure> <t>The auto-assigned ESI can be retrieved using, e.g., a GET RESTCONF method. The assigned value willbethen be returned as shown in the 'esi-auto' data node in <xreftarget="auto-lacp-response"></xref>.</t> <t><figure align="center" anchor="auto-lacp-response" title="Antarget="auto-lacp-response" format="default"/>.</t> <figure anchor="auto-lacp-response"> <name>An Example of an L2NM Message Body to Retrieve the AssignedESI"> <artwork><![CDATA[===============ESI</name> <sourcecode type="json"><![CDATA[=============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-ethernet-segment:ethernet-segments": { "ethernet-segment": [ { "name": "esi1", "ethernet-segment-identifier": "esi-type-1-lacp", "esi-auto": { "auto-ethernet-segment-identifier": "01:11:00:11:00:11:\ 11:9a:00:00" }, "esi-redundancy-mode": "all-active" } ] } }]]></artwork> </figure></t>]]></sourcecode> </figure> </section> <section anchor="prec-example"title="VPNnumbered="true" toc="default"> <name>VPN Network AccessPrecedence">Precedence</name> <t>In reference to the example depicted in <xreftarget="p1"></xref>,target="p1" format="default"/>, an L2VPN service involves two VPN network accesses to sites that belong to the same customer.</t><t><figure align="center" anchor="p1" title="Example<figure anchor="p1"> <name>An Example of Multiple VPN NetworkAccesses">Accesses</name> <artworkalign="center"><![CDATA[+--------------+align="center" name="" type="" alt=""><![CDATA[+--------------+ |VPN-NODE | | +--+-------+ | | NET-ACC-1| Primary | | +------------------ | +--+-------+ | | | +--+-------+ | | NET-ACC-2| Secondary | | +------------------ | +--+-------+ | | +--------------+ ]]></artwork></figure>In</figure> <t>In order to tag one of these VPN network accesses as "primary" and the other one as "secondary", <xreftarget="p2"></xref>target="p2" format="default"/> shows an excerpt of the corresponding L2NM configuration. In such a configuration, both accesses are bound to the same"group-id""group-id", and the "precedence" data node is set as a function of the intended role of each access (primary or secondary).</t><t><figure align="center" anchor="p2" title="Example<figure anchor="p2"> <name>An Example of a Message Body to Associate Priority Levels with VPN NetworkAccesses"> <artwork><![CDATA[{Accesses</name> <sourcecode type="json"><![CDATA[{ "ietf-l2vpn-ntw:l2vpn-ntw": { "vpn-services": { "vpn-service": [ { "vpn-id": "Sample-Service", "vpn-nodes": { "vpn-node": [ { "vpn-node-id": "VPN-NODE", "vpn-network-accesses": { "vpn-network-access": [ { "id": "NET-ACC-1", "connection": { "bearer-reference": "br1" }, "group": [ { "group-id": "1", "precedence": "primary" } ] }, { "id": "NET-ACC-2", "connection": { "bearer-reference": "br2" }, "group": [ { "group-id": "1", "precedence": "secondary" } ] } ] } } ] } } ] } }}]]></artwork> </figure></t> <t></t>}]]></sourcecode> </figure> <t/> </section> </section> <section numbered="false"title="Acknowledgements"toc="default"> <name>Acknowledgements</name> <t>During the discussions of this work, helpful comments, suggestions, and reviews were received from:Sergio Belotti, Italo Busi, Miguel<contact fullname="Sergio Belotti"/>, <contact fullname="Italo Busi"/>, <contact fullname="Miguel CrosCecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Moti Morgenstern, Erez Segev, and Tom Petch.Cecilia"/>, <contact fullname="Joe Clarke"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Adrian Farrel"/>, <contact fullname="Roque Gagliano"/>, <contact fullname="Christian Jacquenet"/>, <contact fullname="Kireeti Kompella"/>, <contact fullname="Julian Lucek"/>, <contact fullname="Moti Morgenstern"/>, <contact fullname="Tom Petch"/>, and <contact fullname="Erez Segev"/>. Many thanks to them.</t><t>Luay Jalil, Jichun Ma, Daniel King, and Zhang Guiyu<t><contact fullname="Zhang Guiyu"/>, <contact fullname="Luay Jalil"/>, <contact fullname="Daniel King"/>, and <contact fullname="Jichun Ma"/> contributed to an early draft version of this document.</t> <t>Thanks toYingzhen Qu and Himanshu Shah<contact fullname="Yingzhen Qu"/> and <contact fullname="Himanshu Shah"/> for the rtgdir reviews,Ladislav Lhotka<contact fullname="Ladislav Lhotka"/> for the yangdoctors review,Chris Lonvick<contact fullname="Chris Lonvick"/> for the secdir review, andDale Worley<contact fullname="Dale Worley"/> for the gen-art review. Special thanks toAdrian Farrel<contact fullname="Adrian Farrel"/> for the careful Shepherd review.</t> <t>Thanks toRobert Wilton<contact fullname="Robert Wilton"/> for the careful AD review and various suggestions to enhance the model.</t> <t>Thanks toLars Eggert, Erik Kline, Roman Danyliw, Francesca Palombini, Zaheduzzaman Sarker, and Eric Vyncke<contact fullname="Roman Danyliw"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Erik Kline"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Zaheduzzaman Sarker"/>, and <contact fullname="Éric Vyncke"/> for the IESG review.</t> <t>A YANG module for Ethernet segments was first defined in the context of the EVPN device module <xref target="I-D.ietf-bess-evpn-yang"/>.</t>format="default"/>.</t> <t>This work is partially supported by the European Commission under Horizon 2020grant agreement number 101015857Secured autonomic traffic management for a Tera of SDN flows(Teraflow).</t>(Teraflow) project (grant agreement number 101015857).</t> </section> <section numbered="false"title="Contributors"toc="default"><figure> <artwork><![CDATA[Victor Lopez Nokia Email: victor.lopez@nokia.com Qin Wu Huawei Email: bill.wu@huawei.com Raul Arco Nokia Email: raul.arco@nokia.com]]></artwork> </figure> <t /> <t /><name>Contributors</name> <author fullname="Victor Lopez" initials="V" surname="Lopez"> <organization>Nokia</organization> <address> <email>victor.lopez@nokia.com</email> </address> </author> <author fullname="Qin Wu" initials="Q" surname="Wu"> <organization>Huawei</organization> <address> <email>bill.wu@huawei.com</email> </address> </author> <author fullname="Raul Arco" initials="R" surname="Arco"> <organization>Nokia</organization> <address> <email>raul.arco@nokia.com</email> </address> </author> </section> </back> </rfc>