<?xml version="1.0"encoding="US-ASCII"?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->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 nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY 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. --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-opsawg-vpn-common-12" number="9181" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <!--Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults inxml2rfcv1.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="4"?> <!-- 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)v2v3 conversion 3.10.0 --><?rfc compact="yes" ?> <!-- do not start each main section on a new page --> <?rfc subcompact="no" ?> <!-- keep one blank line between list items --> <!-- end of list of popular I-D processing instructions --> <rfc category="std" docName="draft-ietf-opsawg-vpn-common-12" ipr="trust200902"><front> <title abbrev="VPN Common YANG Data Model">ALayer 2/3 VPNCommon YANGModel</title>Data Model for Layer 2 and Layer 3 VPNs</title> <seriesInfo name="RFC" value="9181"/> <author fullname="Samier Barguil" initials="S." surname="Barguil"> <organization>Telefonica</organization> <address> <postal><street></street><city>Madrid</city><region></region> <code></code><country>Spain</country> </postal><phone></phone> <facsimile></facsimile><email>samier.barguilgiraldo.ext@telefonica.com</email><uri></uri><uri/> </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 --><city>Madrid</city><region></region> <code></code><country>Spain</country> </postal><phone></phone><email>oscar.gonzalezdedios@telefonica.com</email><!-- uri and facsimile elements may also be added --></address> </author> <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 --> <city></city> <region></region> <code></code><country>France</country> </postal><phone></phone><email>mohamed.boucadair@orange.com</email><!-- uri and facsimile elements may also be added --></address> </author> <author fullname="Qin Wu" initials="Q." surname="Wu"> <organization>Huawei</organization> <address> <postal> <street>101 SoftwareAvenue, YuhuaAvenue</street> <street>Yuhua District</street> <city>Nanjing</city> <region>Jiangsu</region> <code>210012</code> <country>China</country> </postal> <email>bill.wu@huawei.com</email> </address> </author> <date/>year="2022" month="February"/> <workgroup>opsawg</workgroup> <keyword>service automation</keyword> <keyword>network automation</keyword> <keyword>service delivery</keyword> <keyword>service provisioning</keyword> <keyword>Slice</keyword> <keyword>network slicing</keyword> <keyword>vitalisation</keyword> <keyword>Automation</keyword> <keyword>Network Models</keyword> <abstract> <t>This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN network models.</t> </abstract><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 Layer 2/3 VPN Common YANG Model";</t> <t>reference: RFC XXXX</t> </list></t> <t>Also, please update the "revision" date of the YANG module.</t> </note></front> <middle> <section anchor="intro"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>The IETF has specified YANGdatamodules for VPN services, e.g., the Layer 3 VPN Service Model (L3SM) <xreftarget="RFC8299"></xref>target="RFC8299" format="default"/> or the Layer 2 VPN Service Model (L2SM) <xreftarget="RFC8466"></xref>.target="RFC8466" format="default"/>. Other relevant YANG data models are the Layer 3 VPN Network Model (L3NM) <xreftarget="I-D.ietf-opsawg-l3sm-l3nm"></xref>target="RFC9182" format="default"/> and the Layer 2 VPN Network Model (L2NM) <xreftarget="I-D.ietf-opsawg-l2nm"></xref>.target="L2NM-YANG" format="default"/>. There are common data nodes and structures that are present in all of these models or at least a subset of them.</t> <t>This document defines a common YANG module that is meant to be reused by various VPN-related modules such as the L3NM <xreftarget="I-D.ietf-opsawg-l3sm-l3nm"></xref>target="RFC9182" format="default"/> and the L2NM <xreftarget="I-D.ietf-opsawg-l2nm"></xref>:target="L2NM-YANG" format="default"/>: "ietf-vpn-common" (<xreftarget="module"></xref>).</t>target="module" format="default"/>).</t> <t>The "ietf-vpn-common" module includes a set of identities, types, and groupings that are meant to be reused by other VPN-related YANG modules independently of their layer (e.g., Layer 2, Layer 3) and the type of the module (e.g., network model, servicemodel)model), including possible future revisions of existing models (e.g., the L3SM <xreftarget="RFC8299"></xref>target="RFC8299" format="default"/> or the L2SM <xreftarget="RFC8466"></xref>).</t>target="RFC8466" format="default"/>).</t> </section> <section anchor="terminology"title="Terminology">numbered="true" toc="default"> <name>Terminology</name> <t>The terminology for describing YANG modules is defined in <xreftarget="RFC7950"></xref>.</t>target="RFC7950" format="default"/>.</t> <t>Themeaningmeanings of the symbols in tree diagramsisare defined in <xreftarget="RFC8340"></xref>.</t>target="RFC8340" format="default"/>.</t> <t>The reader may refer to <xreftarget="RFC4026"></xref>target="RFC4026" format="default"/> and <xreftarget="RFC4176"></xref>target="RFC4176" format="default"/> for VPN-related terms.</t><t>The<t>This document inherits many terms from <xreftarget="RFC8299"></xref>target="RFC8299" format="default"/> and <xreftarget="RFC8466"></xref>target="RFC8466" format="default"/> (e.g., Enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), Massive Machine Type Communications (mMTC)).</t> </section> <sectiontitle="Descriptionnumbered="true" toc="default"> <name>Description of the VPN Common YANGModule">Module</name> <t>The "ietf-vpn-common" module defines a set of common VPN-related features,including: <list style="hanging"> <t hangText="Encapsulation featuresincluding the following:</t> <dl newline="false" spacing="normal"> <dt>Encapsulation features, suchas:"><list style="symbols"> <t>Dot1q <xref target="IEEE802.1Q"></xref>,</t> <t>QinQ <xref target="IEEE802.1ad"></xref>,</t> <t>linkas the following:</dt> <dd> <ul spacing="normal"> <li>dot1Q <xref target="IEEE802.1Q" format="default"/>,</li> <li>QinQ <xref target="IEEE802.1ad" format="default"/>,</li> <li>link aggregation <xreftarget="IEEE802.1AX"></xref>, and</t> <t><xref target="RFC7348">Virtualtarget="IEEE802.1AX" format="default"/>, and</li> <li> <xref target="RFC7348" format="default">Virtual eXtensible Local AreaNetwork (VXLAN)</xref>.</t> </list></t> <t hangText="Multicast [RFC6513]."></t> <t hangText="Routing featuresNetworks (VXLANs)</xref>.</li> </ul> </dd> <dt>Multicast <xref target="RFC6513" format="default"/>.</dt> <dd/> <dt>Routing features, suchas:"><list style="symbols"> <t>BGP <xref target="RFC4271"></xref>,</t> <t>OSPF <xref target="RFC4577"></xref><xref target="RFC6565"></xref>,</t> <t>IS-IS <xref target="ISO10589"></xref>,</t> <t>RIP <xref target="RFC2080"></xref><xref target="RFC2453"></xref>,</t> <t>Bidirectionalas the following:</dt> <dd> <ul spacing="normal"> <li>BGP <xref target="RFC4271" format="default"/>,</li> <li>OSPF <xref target="RFC4577" format="default"/> <xref target="RFC6565" format="default"/>,</li> <li>IS-IS <xref target="ISO10589" format="default"/>,</li> <li>RIP <xref target="RFC2080" format="default"/> <xref target="RFC2453" format="default"/>,</li> <li>Bidirectional Forwarding Detection (BFD) <xreftarget="RFC5880"></xref><xref target="RFC7880"></xref>, and</t> <t>Virtualtarget="RFC5880" format="default"/> <xref target="RFC7880" format="default"/>, and</li> <li>Virtual Router Redundancy Protocol (VRRP) <xreftarget="RFC5798"></xref>.</t> </list></t> </list>target="RFC5798" format="default"/>.</li> </ul> </dd> </dl> <t> Also, the module defines a set of identities,including:<list style="hanging"> <t hangText="'service-type':">Usedincluding the following:</t> <dl newline="false" spacing="normal"> <dt>'service-type':</dt> <dd> <t>Used to identify the VPN service type. Examples of supported service typesare: <list style="symbols"> <t>L3VPN,</t> <t>Virtualare as follows: </t> <ul spacing="normal"> <li>L3VPN,</li> <li>Virtual Private LAN Service (VPLS) using BGP <xreftarget="RFC4761"></xref>,</t> <t><xref target="RFC4762">VPLStarget="RFC4761" format="default"/>,</li> <li> <xref target="RFC4762" format="default">VPLS using the Label Distribution Protocol(LDP)</xref>,</t> <t><xref target="RFC8214">Virtual(LDP)</xref>,</li> <li> <xref target="RFC8214" format="default">Virtual Private Wire Service(VPWS)</xref>,</t> <t><xref target="RFC7432">BGP(VPWS)</xref>,</li> <li> <xref target="RFC7432" format="default">BGP MPLS-Based EthernetVPN</xref>,</t> <t><xref target="RFC8365">EthernetVPN</xref>,</li> <li> <xref target="RFC8365" format="default">Ethernet VPN (EVPN)</xref>,and</t> <t><xref target="RFC7623">Providerand</li> <li> <xref target="RFC7623" format="default">Provider Backbone Bridging Combined with Ethernet VPN(PBB-EVPN)</xref>.</t> </list></t> <t hangText="'vpn-signaling-type':">Used(PBB-EVPN)</xref>.</li> </ul> </dd> <dt>'vpn-signaling-type':</dt> <dd> <t>Used to identify the signaling mode used for a given service type. Examples of supported VPN signaling typesare: <list style="symbols"> <t>L2VPNsare as follows: </t> <ul spacing="normal"> <li>L2VPNs using BGP <xreftarget="RFC6624"></xref>.</t> <t>LDP <xref target="RFC5036"></xref>, and</t> <t>Layertarget="RFC6624" format="default"/>,</li> <li>LDP <xref target="RFC5036" format="default"/>, and</li> <li>Layer Two Tunneling Protocol (L2TP) <xreftarget="RFC3931"></xref>.</t> </list></t> </list></t>target="RFC3931" format="default"/>.</li> </ul> </dd> </dl> <t>The module covers both IPv4 <xreftarget="RFC0791"></xref>target="RFC0791" format="default"/> and IPv6 <xreftarget="RFC8200"></xref>target="RFC8200" format="default"/> identities. It also includesmulticast relatedmulticast-related identities such as Internet Group Management Protocol version 1 (IGMPv1) <xreftarget="RFC1112"></xref>,target="RFC1112" format="default"/>, IGMPv2 <xreftarget="RFC2236"></xref>,target="RFC2236" format="default"/>, IGMPv3 <xreftarget="RFC3376"></xref>,target="RFC3376" format="default"/>, Multicast Listener Discovery version 1 (MLDv1) <xreftarget="RFC2710"></xref>,target="RFC2710" format="default"/>, MLDv2 <xreftarget="RFC3810"></xref>,target="RFC3810" format="default"/>, and Protocol Independent Multicast (PIM) <xreftarget="RFC7761"></xref>.</t>target="RFC7761" format="default"/>.</t> <t>The reader should refer to <xreftarget="module"></xref>target="module" format="default"/> for the full list of supported identities (identities related to address families, VPN topologies, network access types, operational and administrative status, site or noderoles,role, VPN service constraints, routing protocols,routes imports and exports, bandwidthroute import and export policies, bandwidth, Quality of Service (QoS), etc.).</t> <t>The "ietf-vpn-common" module also contains a set of reusable VPN-related groupings.The<xref target="ctree" format="default"/> provides the tree diagramof the "ietf-vpn-common" modulethat depicts the common groupingsis provided in <xref target="ctree"></xref>.</t> <t><figure align="center" anchor="ctree" title="VPNfor the "ietf-vpn-common" module.</t> <figure anchor="ctree"> <name>VPN CommonTree"> <artwork align="center"><![CDATA[module:Tree</name> <sourcecode name="" type="yangtree"><![CDATA[module: ietf-vpn-common groupingvpn-descriptionvpn-description: +-- vpn-id? vpn-id +-- vpn-name? string +-- vpn-description? string +-- customer-name? string groupingvpn-profile-cfgvpn-profile-cfg: +-- valid-provider-identifiers +-- external-connectivity-identifier* [id] | {external-connectivity}? | +-- id string +-- encryption-profile-identifier* [id] | +-- id string +-- qos-profile-identifier* [id] | +-- id string +-- bfd-profile-identifier* [id] | +-- id string +-- forwarding-profile-identifier* [id] | +-- id string +-- routing-profile-identifier* [id] +-- id string groupingoper-status-timestampoper-status-timestamp: +--ro status? identityref +--ro last-change? yang:date-and-time groupingservice-statusservice-status: +-- status +-- admin-status | +-- status? identityref | +-- last-change? yang:date-and-time+--+--ro oper-status +--ro status? identityref +--ro last-change? yang:date-and-time groupingunderlay-transportunderlay-transport: +-- (type)? +--:(abstract) | +-- transport-instance-id? string | +-- instance-type? identityref +--:(protocol) +-- protocol* identityref groupingvpn-route-targetsvpn-route-targets: +-- vpn-target* [id] | +-- id uint8 | +-- route-targets* [route-target] | | +-- route-target rt-types:route-target | +-- route-target-type rt-types:route-target-type +-- vpn-policies +-- import-policy? string +-- export-policy? string groupingroute-distinguisherroute-distinguisher: ... groupingvpn-components-groupvpn-components-group: +-- groups +-- group* [group-id] +-- group-id string groupingplacement-constraintsplacement-constraints: +-- constraint* [constraint-type] +-- constraint-type? identityref +-- target +-- (target-flavor)? +--:(id) | +-- group* [group-id] | +-- group-id string +--:(all-accesses) | +-- all-other-accesses? empty +--:(all-groups) +-- all-other-groups? empty groupingportsports: ... groupingqos-classification-policyqos-classification-policy: ...]]></artwork> </figure></t>]]></sourcecode> </figure> <t>Thedescriptiondescriptions of the common groupingsisare provided below:</t><t><list style="hanging"> <t hangText="'vpn-description':"><list style="empty"> <t>A<dl newline="true" spacing="normal"> <dt>'vpn-description':</dt> <dd>A YANG grouping that provides common administrative VPN information such as an identifier, a name, a textual description, and a customername.</t> </list></t> <t hangText="'vpn-profile-cfg':"><list style="empty">name.</dd> <dt>'vpn-profile-cfg':</dt> <dd> <t>A YANG grouping that defines a set of valid profiles (encryption, routing, forwarding, etc.) that can be bound to a Layer 2/3 VPN. This document does not make anyassumptionassumptions about the structure of suchprofiles,profiles but allows "gluing" a VPN service with other parameters that can be required locally to provideadded valuevalue-added features to requesting customers.<vspace blankLines="1" />For</t> <t>For example, a service provider may provideanexternal connectivity to a VPN customer (e.g., to a private or public cloud, Internet). Such a service may involve tweaking both filtering and NAT rules (e.g.,bindbinding a Virtual Routing and Forwarding (VRF) interface with a NAT instance as discussed inSection 2.10 of<xreftarget="RFC8512"></xref>).target="RFC8512" sectionFormat="of" section="2.10"/>). Theseadded valuevalue-added features may be bound toallall, or a subsetofof, network accesses. Some of theseadded valuevalue-added features may be implemented in nodes other thanPEsProvider Edges (PEs) (e.g., a P node or even a dedicated node that hosts the NAT function).<vspace blankLines="1" />It is out</t> <t>Elaborating on the structure of these profiles is beyond the scope of thisdocument to elaborate the structure of these profiles.</t> </list></t> <t hangText="'oper-status-timestamp':"><list style="empty"> <t>Adocument.</t> </dd> <dt>'oper-status-timestamp':</dt> <dd>A YANG grouping that defines the operational status updates of a VPN service orcomponent.</t> </list></t> <t hangText="'service-status':"><list style="empty"> <t>Acomponent.</dd> <dt>'service-status':</dt> <dd>A YANG grouping that defines the administrative and operational status of a component. The grouping can be applied to the whole service or anendpoint.</t> </list></t> <t hangText="'underlay-transport':"><list style="empty">endpoint.</dd> <dt>'underlay-transport':</dt> <dd> <t>A YANG grouping that defines the type of the underlay transport for a VPN service or how that underlay is set.<vspace blankLines="1" />The</t> <t>The underlay transport can be expressed as an abstract transport instance (e.g., an identifier of a VPN+ instance <xreftarget="I-D.ietf-teas-enhanced-vpn"></xref>,target="I-D.ietf-teas-enhanced-vpn" format="default"/>, a virtual network identifier <xreftarget="I-D.ietf-teas-actn-vn-yang"></xref><xref target="RFC8453"></xref>,target="ACTN-VN-YANG" format="default"/> <xref target="RFC8453" format="default"/>, or a network slice name <xreftarget="I-D.ietf-teas-ietf-network-slices"></xref>)target="Network-Slices-Framework" format="default"/>) or as an ordered list of the actual protocols to be enabled in the network.<vspace blankLines="1" />The</t> <t>The module supports a rich set of protocol identifiers that can be used,e.g.,for example, to refer to an underlay transport. Examples of supported protocolsare:<list style="symbols"> <t>IP-in-IP <xref target="RFC2003"></xref><xref target="RFC2473"></xref>,</t> <t>GRE <xref target="RFC1701"></xref><xref target="RFC1702"></xref><xref target="RFC7676"></xref>,</t> <t>MPLS-in-UDPare as follows:</t> <ul spacing="normal"> <li>IP in IP <xref target="RFC2003" format="default"/> <xref target="RFC2473" format="default"/>,</li> <li>Generic Routing Encapsulation (GRE) <xref target="RFC1701" format="default"/> <xreftarget="RFC7510"></xref>,</t> <t>Generictarget="RFC1702" format="default"/> <xref target="RFC7676" format="default"/>,</li> <li>MPLS in UDP <xref target="RFC7510" format="default"/>,</li> <li>Generic Network Virtualization Encapsulation(GENEVE)(Geneve) <xreftarget="RFC8926"></xref>,</t> <t>Segmenttarget="RFC8926" format="default"/>,</li> <li>Segment Routing (SR) <xreftarget="RFC8660"></xref><xref target="RFC8663"></xref><xref target="RFC8754"></xref>,</t> <t>Resourcetarget="RFC8660" format="default"/> <xref target="RFC8663" format="default"/> <xref target="RFC8754" format="default"/>,</li> <li>Resource ReSerVation Protocol (RSVP) with traffic engineering extensions <xreftarget="RFC3209"></xref>, and</t> <t>BGPtarget="RFC3209" format="default"/>, and</li> <li>BGP with labeled prefixes <xreftarget="RFC8277"></xref>.</t> </list></t> </list></t> <t hangText="'vpn-route-targets':"><list style="empty"> <t>Atarget="RFC8277" format="default"/>.</li> </ul> </dd> <dt>'vpn-route-targets':</dt> <dd>A YANG grouping that defines Route Target (RT) import/export rules used in a BGP-enabled VPN. This grouping can be used for both L3VPNs <xreftarget="RFC4364"></xref>target="RFC4364" format="default"/> andL2VPNs<xref target="RFC4664"></xref>.L2VPNs <xref target="RFC4664" format="default"/>. Note that this ismodelledmodeled as a list to ease the reuse of this grouping in modules where an RT identifier is needed (e.g.,associateassociating an operator withRTs).</t> </list></t> <t hangText="'route-distinguisher': "><list style="empty">RTs).</dd> <dt>'route-distinguisher': </dt> <dd> <t>A YANG grouping that defines Route Distinguishers(RDs). <vspace blankLines="1" />As(RDs).</t> <t>As depicted in <xreftarget="rtrd"></xref>,target="rtrd" format="default"/>, the module supportsthesethe following RD assignment modes: direct assignment, full automatic assignment, automatic assignment from a given pool,automatic assignment,and noassignment. <vspace blankLines="1" />Also,assignment.</t> <t>Also, the module accommodates deployments where only the Assigned Number subfield of RDs(Section 4.2 of <xref target="RFC4364"></xref>)(<xref target="RFC4364" sectionFormat="of" section="4.2"/>) is assigned from a pool while the Administrator subfield is set to,e.g.,for example, therouter-idRouter ID that is assigned to a VPN node. The module supportsthesethree modes for managing the Assigned Number subfield: explicit assignment,auto-assignmentautomatic assignment from a given pool, and fullauto-assignment.<figure align="center" anchor="rtrd" title="Routeautomatic assignment.</t> <figure anchor="rtrd"> <name>Route Distinguisher GroupingSubtree"> <artwork align="center"><![CDATA[Subtree</name> <sourcecode name="" type="yangtree"><![CDATA[ groupingroute-distinguisherroute-distinguisher: +-- (rd-choice)? +--:(directly-assigned) | +-- rd? rt-types:route-distinguisher +--:(directly-assigned-suffix) | +-- rd-suffix? uint16 +--:(auto-assigned) | +-- rd-auto | +-- (auto-mode)? | | +--:(from-pool) | | | +-- rd-pool-name? string | | +--:(full-auto) | | +-- auto? empty | +--ro auto-assigned-rd? | | rt-types:route-distinguisher +--:(auto-assigned-suffix) | +-- rd-auto-suffix | +-- (auto-mode)? | | +--:(from-pool) | | | +-- rd-pool-name? string | | +--:(full-auto) | | +-- auto? empty | +--ro auto-assigned-rd-suffix? uint16 +--:(no-rd) +-- no-rd? empty]]></artwork> </figure></t> </list></t> <t hangText="'vpn-components-group':"><list style="empty"> <t>A]]></sourcecode> </figure> </dd> <dt>'vpn-components-group':</dt> <dd>A YANG grouping that is used to group VPN nodes, VPN network accesses, or sites. For example, diversity or redundancy constraints can be applied on a per-groupbasis.</t> </list></t> <t hangText="'placement-constraints':"><list style="empty"> <t>Abasis.</dd> <dt>'placement-constraints':</dt> <dd>A YANG grouping that is used to define the placement constraints of a VPN node, VPN network access, orsite.</t> </list></t> <t hangText="'ports': "><list style="empty">site.</dd> <dt>'ports': </dt> <dd> <t>A YANG grouping that defines ranges of source and destination port numbers and operators. The subtree of this grouping is depicted in <xreftarget="ports"></xref>.<figure align="center" anchor="ports" title="Porttarget="ports" format="default"/>.</t> <figure anchor="ports"> <name>Port Numbers GroupingSubtree"> <artwork align="center"><![CDATA[Subtree</name> <sourcecode name="" type="yangtree"><![CDATA[ groupingportsports: +-- (source-port)? | +--:(source-port-range-or-operator) | +-- source-port-range-or-operator | +-- (port-range-or-operator)? | +--:(range) | | +-- lower-port inet:port-number | | +-- upper-port inet:port-number | +--:(operator) | +-- operator? operator | +-- port inet:port-number +-- (destination-port)? +--:(destination-port-range-or-operator) +-- destination-port-range-or-operator +-- (port-range-or-operator)? +--:(range) | +-- lower-port inet:port-number | +-- upper-port inet:port-number +--:(operator) +-- operator? operator +-- port inet:port-number]]></artwork> </figure></t> </list></t> <t hangText="'qos-classification-policy':"><list style="empty">]]></sourcecode> </figure> </dd> <dt>'qos-classification-policy':</dt> <dd> <t>A YANG grouping that defines a set of QoS classification policies based on variousmatchLayer 3/4 and application match criteria. The subtree of this grouping is depicted in <xreftarget="qos"></xref>. <vspace blankLines="1" />Thetarget="qos" format="default"/>. </t> <t>The QoS match criteria reuse groupings that are defined in the packet fields module "ietf-packet-fields"(Section 4.2 of <xref target="RFC8519"></xref>). <vspace blankLines="1" />Any layer(<xref target="RFC8519" sectionFormat="of" section="4.2"/>). </t> <t>Any Layer 4 protocol can be indicated in the 'protocol' data node under 'l3', but onlyTCPTCP- andUDP specificUDP-specific match criteria are elaborated on in thisversionversion, as these protocols are widely used in the context of VPN services. Future revisions can be considered to add otherLayer 4 specificLayer-4-specific parameters (e.g., the Stream Control Transmission Protocol <xreftarget="RFC4960"></xref>),target="RFC4960" format="default"/>), if needed.<vspace blankLines="1" />Some</t> <t>Some transport protocols use existing protocols (e.g., TCP or UDP) as the substrate. The match criteria for such protocols may rely upon the 'protocol' under 'l3', TCP/UDP match criteria as shown in <xreftarget="qos"></xref>,target="qos" format="default"/>, part of the TCP/UDP payload, or a combination thereof. This version of the module does not support such advanced match criteria. Future revisions of the module may consider adding match criteria based on the transport protocol payload (e.g., by means of a bitmask match). </t> <figurealign="center" anchor="qos" title="QoSanchor="qos"> <name>QoS ClassificationSubtree"> <artwork align="center"><![CDATA[Subtree</name> <sourcecode name="" type="yangtree"><![CDATA[ groupingqos-classification-policyqos-classification-policy: +-- rule* [id] +-- id string +-- (match-type)? | +--:(match-flow) | | +-- (l3)? | | | +--:(ipv4) | | | | +-- ipv4 | | | | +-- dscp? inet:dscp | | | | +-- ecn? uint8 | | | | +-- length? uint16 | | | | +-- ttl? uint8 | | | | +-- protocol? uint8 | | | | +-- ihl? uint8 | | | | +-- flags? bits | | | | +-- offset? uint16 | | | | +-- identification? uint16 | | | | +-- (destination-network)? | | | | | +--:(destination-ipv4-network) | | | | | +-- destination-ipv4-network? | | | | | inet:ipv4-prefix | | | | +-- (source-network)? | | | | +--:(source-ipv4-network) | | | | +-- source-ipv4-network? | | | | inet:ipv4-prefix | | | +--:(ipv6) | | | +-- ipv6 | | | +-- dscp? inet:dscp | | | +-- ecn? uint8 | | | +-- length? uint16 | | | +-- ttl? uint8 | | | +-- protocol? uint8 | | | +-- (destination-network)? | | | | +--:(destination-ipv6-network) | | | | +-- destination-ipv6-network? | | | | inet:ipv6-prefix | | | +-- (source-network)? | | | | +--:(source-ipv6-network) | | | | +-- source-ipv6-network? | | | | inet:ipv6-prefix | | | +-- flow-label? | | | inet:ipv6-flow-label | | +-- (l4)? | | +--:(tcp) | | | +-- tcp | | | +-- sequence-number? uint32 | | | +-- acknowledgement-number? uint32 | | | +-- data-offset? uint8 | | | +-- reserved? uint8 | | | +-- flags? bits | | | +-- window-size? uint16 | | | +-- urgent-pointer? uint16 | | | +-- options? binary | | | +-- (source-port)? | | | | +--:(source-port-range-or-operator) | | | | +-- source-port-range-or-operator | | | | +-- (port-range-or-operator)? | | | | +--:(range) | | | | | +-- lower-port | | | | | | inet:port-number | | | | | +-- upper-port | | | | | inet:port-number | | | | +--:(operator) | | | | +-- operator? operator | | | | +-- port | | | | inet:port-number | | | +-- (destination-port)? | | | +--:(destination-port-range-or-operator) | | | +-- destination-port-range-or-operator | | | +-- (port-range-or-operator)? | | | +--:(range) | | | | +-- lower-port | | | | | inet:port-number | | | | +-- upper-port | | | | inet:port-number | | | +--:(operator) | | | +-- operator? operator | | | +-- port | | | inet:port-number | | +--:(udp) | | +-- udp | | +-- length? uint16 | | +-- (source-port)? | | | +--:(source-port-range-or-operator) | | | +-- source-port-range-or-operator | | | +-- (port-range-or-operator)? | | | +--:(range) | | | | +-- lower-port | | | | | inet:port-number | | | | +-- upper-port | | | | inet:port-number | | | +--:(operator) | | | +-- operator? operator | | | +-- port | | | inet:port-number | | +-- (destination-port)? | | +--:(destination-port-range-or-operator) | | +-- destination-port-range-or-operator | | +-- (port-range-or-operator)? | | +--:(range) | | | +-- lower-port | | | | inet:port-number | | | +-- upper-port | | | inet:port-number | | +--:(operator) | | +-- operator? operator | | +-- port | | inet:port-number | +--:(match-application) | +-- match-application? identityref +-- target-class-id? string{qos}? ]]></artwork> </figure></t> </list></t> </list></t> <t></t>]]></sourcecode> </figure> </dd> </dl> </section> <section anchor="module"title="Layernumbered="true" toc="default"> <name>Layer 2/3 VPN CommonModule">Module</name> <t>This module uses types defined in <xreftarget="RFC6991"></xref>,target="RFC6991" format="default"/>, <xreftarget="RFC8294"></xref>,target="RFC8294" format="default"/>, and <xreftarget="RFC8519"></xref>.target="RFC8519" format="default"/>. It also uses the extension defined in <xreftarget="RFC8341"></xref>.</t> <t><figure> <artwork><![CDATA[<CODE BEGINS> file "ietf-vpn-common@2021-09-10.yang"target="RFC8341" format="default"/>.</t> <sourcecode name="ietf-vpn-common@2022-02-11.yang" type="yang" markers="true"><![CDATA[ module ietf-vpn-common { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-vpn-common"; prefix vpn-common; import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control Model"; } import ietf-routing-types { prefix rt-types; reference "RFC 8294: Common YANG Data Types for the Routing Area"; } import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types, Section 3"; } import ietf-packet-fields { prefix packet-fields; reference "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; } organization "IETF OPSAWG (Operations and Management Area Working Group)"; contact "WG Web: <https://datatracker.ietf.org/wg/opsawg/> WG List: <mailto:opsawg@ietf.org> Editor: Mohamed Boucadair <mailto:mohamed.boucadair@orange.com> Author: Samier Barguil <mailto:samier.barguilgiraldo.ext@telefonica.com>Author:Editor: Oscar Gonzalez de Dios <mailto:oscar.gonzalezdedios@telefonica.com> Author: Qin Wu <mailto:bill.wu@huawei.com>"; description "This YANG module defines a common module that is meant to be reused by various VPN-related modules (e.g., the Layer 3 VPN Service Model (L3SM), the Layer 2 VPN Service Model (L2SM), the Layer 3 VPN Network Model (L3NM), and the Layer 2 VPN Network Model (L2NM)). 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, theSimplifiedRevised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents(http://trustee.ietf.org/license-info).(https://trustee.ietf.org/license-info). This version of this YANG module is part of RFCXXXX;9181; see the RFC itself for full legal notices."; revision2021-09-102022-02-11 { description "Initial revision."; reference "RFCXXXX:9181: ALayer 2/3 VPNCommon YANGModel";Data Model for Layer 2 and Layer 3 VPNs"; } /******** Collection of VPN-relatedFeaturesfeatures ********/ /* * Features related to encapsulation schemes */ feature dot1q { description "Indicatesthesupport forthe Dot1qdot1Q encapsulation."; reference "IEEE Std 802.1Q:BridgesIEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks"; } feature qinq { description "Indicatesthesupport fortheQinQ encapsulation."; reference "IEEE Std 802.1ad: IEEE Standard for Local and Metropolitan Area Networks---Virtual Bridged Local Area Networks---Amendment 4: Provider Bridges"; } feature vxlan { description "Indicatesthesupport fortheVirtual eXtensible Local Area Network (VXLAN) encapsulation."; reference "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks"; } feature qinany { description "Indicatesthesupport fortheQinAny encapsulation. The outer VLAN tag is set to a specificvaluevalue, but the inner VLAN tag is set to any."; } feature lag-interface { description "Indicatesthesupport for Link AggregationGroup (LAG)Groups (LAGs) between VPN network accesses."; reference "IEEEStd.Std 802.1AX:LinkIEEE Standard for Local and Metropolitan Area Networks--Link Aggregation"; } /* * Features related to multicast */ feature multicast { description "Indicates support for multicast capabilitiessupportin a VPN."; reference "RFC 6513: Multicast in MPLS/BGP IP VPNs"; } feature igmp { description "Indicates support for the Internet Group Management Protocol (IGMP)."; reference "RFC 1112: Host Extensions for IP Multicasting RFC 2236: Internet Group Management Protocol, Version 2 RFC 3376: Internet Group Management Protocol, Version 3"; } feature mld { description "Indicates support for Multicast Listener Discovery (MLD)."; reference "RFC 2710: Multicast Listener Discovery (MLD) for IPv6 RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6"; } feature pim { description "Indicates support for Protocol Independent Multicast (PIM)."; reference "RFC 7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"; } /* * Features related to address family types */ feature ipv4 { description "Indicates IPv4 support in a VPN. That is, IPv4 traffic can be carried in the VPN, IPv4 addresses/prefixes can be assigned to a VPN network access, IPv4 routes can be installed for theCE/PECustomer Edge to Provider Edge (CE-PE) link, etc."; reference "RFC 791: Internet Protocol"; } feature ipv6 { description "Indicates IPv6 support in a VPN. That is, IPv6 traffic can be carried in the VPN, IPv6 addresses/prefixes can be assigned to a VPN network access, IPv6 routes can be installed for theCE/PECE-PE link, etc."; reference "RFC 8200: Internet Protocol, Version 6(IPv6)";(IPv6) Specification"; } /* * Features related to routing protocols */ feature rtg-ospf { description "Indicates support fortheOSPF as the Provider Edge(PE)/to Customer Edge(CE)(PE-CE) routing protocol."; reference "RFC 4577: OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) RFC 6565: OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol"; } feature rtg-ospf-sham-link { description "Indicates support for OSPF sham links."; reference "RFC 4577: OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs), Section 4.2.7 RFC 6565: OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol, Section 5"; } feature rtg-bgp { description "Indicates support for BGP as thePE/CEPE-CE routing protocol."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; } feature rtg-rip { description "Indicates support for RIP as thePE/CEPE-CE routing protocol."; reference "RFC 2453: RIP Version 2 RFC 2080: RIPng for IPv6"; } feature rtg-isis { description "Indicates support for IS-IS as thePE/CEPE-CE routing protocol."; reference "ISO10589: Information technology - Telecommunications and information exchange between systems - Intermediate System to Intermediate Systemintra- domainintra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"; } feature rtg-vrrp { description "Indicates support for the Virtual Router Redundancy Protocol (VRRP) inCE/PEthe CE-PE link."; reference "RFC 5798: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6"; } feature bfd { description "Indicates support for Bidirectional Forwarding Detection (BFD) between the CE and the PE."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD)"; } /* * Features related to VPN service constraints */ feature bearer-reference { description "A bearer refers to properties of the CE-PE attachment that are below Layer 3. This feature indicates support for the bearer reference accessconstraint. That is,constraint, i.e., the reuse of a network connection that was already ordered to the service provider apart from the IP VPN site."; } feature placement-diversity { description "Indicates support for placement diversity constraints in the customer premises. An example of these constraints may be to avoid connecting a site network access to the sameProvider EdgePE as a target site network access."; } /* * Features related to bandwidth and Quality of Service (QoS) */ feature qos { description "Indicates support for Classes of Service (CoSes) in the VPN."; } feature inbound-bw { description "Indicates support for the inbound bandwidth in aVPN. That is,VPN, i.e., support for specifying the download bandwidth from the service provider network to the VPN site. Note that the L3SM uses 'input' to identify the same feature. That terminology should be deprecated in favor of theoneterminology defined in this module."; } feature outbound-bw { description "Indicates support for the outbound bandwidth in aVPN. That is,VPN, i.e., support for specifying the upload bandwidth from the VPN site to the service provider network. Note that the L3SM uses 'output' to identify the same feature. That terminology should be deprecated in favor of theoneterminology defined in this module."; } /* * Features related to security and resilience */ feature encryption { description "Indicates support for encryption in the VPN."; } feature fast-reroute { description "Indicates support for Fast Reroute (FRR) capabilities for a VPN site."; } /* * Features related to advanced VPN options */ feature external-connectivity { description "Indicates support for the VPN to provide external connectivity (e.g., Internet, private or public cloud)."; reference "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs), Section 11"; } feature extranet-vpn { description "Indicates support for extranetVPNs. That is,VPNs, i.e., the capability of a VPN to access a list of other VPNs."; reference "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs), Section 1.1"; } feature carriers-carrier { description "Indicates support forCarrier-of-CarrierCarriers' Carriers in VPNs."; reference "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs), Section 9"; } /* *Address familyIdentities relatedidentitiesto address families */ identity address-family { description "Defines a type for the address family."; } identity ipv4 { base address-family; description "Identity for an IPv4 address family."; } identity ipv6 { base address-family; description "Identity for an IPv6 address family."; } identity dual-stack { base address-family; description "Identity for IPv4 and IPv6 addressfamily.";families."; } /* * Identities related to VPN topology */ identity vpn-topology { description "Base identity of the VPN topology."; } identity any-to-any { base vpn-topology; description "Identity for any-to-any VPN topology. All VPN sites can communicate with each other without any restrictions."; } identity hub-spoke { base vpn-topology; description "Identity for Hub-and-Spoke VPN topology. All Spokes can communicateonlywith Hubsbutonly and not with each other. Hubs can communicate with each other."; } identity hub-spoke-disjoint { base vpn-topology; description "Identity for Hub-and-Spoke VPN topology where Hubs cannot communicate with each other."; } identity custom { base vpn-topology; description "Identity for custom VPN topologies where the role of the nodes is not strictly Hub or Spoke. The VPN topology is controlled by the import/export policies. The custom topology reflects more complex VPNnodesnodes, such as a VPN node that acts as a Hub for certain nodes and a Spoketofor others."; } /* * Identities related to network access types */ identity site-network-access-type { description "Base identity for site network accesstype.";types."; } identity point-to-point { base site-network-access-type; description "Point-to-point access type."; } identity multipoint { base site-network-access-type; description "Multipoint access type."; } identity irb { base site-network-access-type; description "Integrated RoutingBridgeand Bridging (IRB). Identity for pseudowire connections."; } identity loopback { base site-network-access-type; description "Loopback access type."; } /* * Identities related to operational and administrative status */ identity operational-status { description "Base identity fortheoperational status."; } identity op-up { base operational-status; description "Operational status is Up/Enabled."; } identity op-down { base operational-status; description "Operational status is Down/Disabled."; } identity op-unknown { base operational-status; description "Operational status is Unknown."; } identity administrative-status { description "Base identity for administrative status."; } identity admin-up { base administrative-status; description "Administrative status is Up/Enabled."; } identity admin-down { base administrative-status; description "Administrative status is Down/Disabled."; } identity admin-testing { base administrative-status; description "Administrative status isupUp for testing purposes."; } identity admin-pre-deployment { base administrative-status; description "Administrative statusisreflects a pre-deploymentphase. That is,phase, i.e., prior to the actual deployment of a service."; } /* * Identities related to site or noderoleroles */ identity role { description "Base identity of a site oranode role."; } identity any-to-any-role { base role; description "Any-to-any role."; } identity spoke-role { base role; description "A node or a site is acting as a Spoke."; } identity hub-role { base role; description "A node or a site is acting as a Hub."; } identity custom-role { base role; description "VPN node with a custom or complex role in the VPN. For somesources/destinationssources/destinations, it can behave as a Hub, but forothersothers, it can act as aSpokeSpoke, depending on the configured policy."; } /* * Identities related to VPN service constraints */ identity placement-diversity { description "Base identity for access placement constraints."; } identity bearer-diverse { base placement-diversity; description "Bearer diversity. The bearers should not use common elements."; } identity pe-diverse { base placement-diversity; description "PE diversity."; } identity pop-diverse { base placement-diversity; description "PointOfof Presence (POP) diversity."; } identity linecard-diverse { base placement-diversity; description "Linecard diversity."; } identity same-pe { base placement-diversity; description "Having sites connected on the same PE."; } identity same-bearer { base placement-diversity; description "Having sites connected using the same bearer."; } /* * Identities related to service types */ identity service-type { description "Base identity for servicetype.";types."; } identity l3vpn { base service-type; description "L3VPN service."; reference "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)"; } identity vpls { base service-type; description"VPLS service.";"Virtual Private LAN Service (VPLS)."; reference "RFC 4761: Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling RFC 4762: Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"; } identity vpws { base service-type; description "Virtual Private Wire Service(VPWS) service.";(VPWS)."; reference "RFC 4664: Framework for Layer 2 Virtual Private Networks (L2VPNs), Section 3.1.1"; } identity vpws-evpn { base service-type; description"EVPN"Ethernet VPN (EVPN) used to supportVPWS service.";VPWS."; reference "RFC 8214: Virtual Private Wire Service Support in Ethernet VPN"; } identity pbb-evpn { base service-type; description "Provider Backbone Bridging (PBB)EVPNsEVPN service."; reference "RFC 7623: Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)"; } identity mpls-evpn { base service-type; description "MPLS-based EVPN service."; reference "RFC 7432: BGP MPLS-Based Ethernet VPN"; } identity vxlan-evpn { base service-type; description "VXLAN-based EVPN service."; reference "RFC 8365: A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)"; } /* * Identities related to VPN signalingtypetypes */ identity vpn-signaling-type { description "Base identity for VPN signalingtypes";types."; } identity bgp-signaling { base vpn-signaling-type; description "Layer 2 VPNs using BGP signaling."; reference "RFC 6624: Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling RFC 7432: BGP MPLS-Based Ethernet VPN"; } identity ldp-signaling { base vpn-signaling-type; description "Targeted Label Distribution Protocol (LDP) signaling."; reference "RFC 5036: LDP Specification"; } identity l2tp-signaling { base vpn-signaling-type; description "Layer Two Tunneling Protocol (L2TP) signaling."; reference "RFC 3931: Layer Two Tunneling Protocol - Version 3 (L2TPv3)"; } /* * Identities related to routing protocols */ identity routing-protocol-type { description "Base identity for routing protocoltype.";types."; } identity static-routing { base routing-protocol-type; description "Static routing protocol."; } identity bgp-routing { if-feature "rtg-bgp"; base routing-protocol-type; description "BGP routing protocol."; reference "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; } identity ospf-routing { if-feature "rtg-ospf"; base routing-protocol-type; description "OSPF routing protocol."; reference "RFC 4577: OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual PrivateNetworks(VPNs)Networks (VPNs) RFC 6565: OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol"; } identity rip-routing { if-feature "rtg-rip"; base routing-protocol-type; description "RIP routing protocol."; reference "RFC 2453: RIP Version 2 RFC 2080: RIPng for IPv6"; } identity isis-routing { if-feature "rtg-isis"; base routing-protocol-type; description "IS-IS routing protocol."; reference "ISO10589: Information technology - Telecommunications and information exchange between systems - Intermediate System to Intermediate Systemintra- domainintra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"; } identity vrrp-routing { if-feature "rtg-vrrp"; base routing-protocol-type; description "VRRP protocol. This is to be used when LANs are directly connected to PEs."; reference "RFC 5798: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6"; } identity direct-routing { base routing-protocol-type; description "Direct routing. This is to be used when LANs are directly connected to PEs and must be advertised in the VPN."; } identity any-routing { base routing-protocol-type; description "Any routing protocol.ThisFor example, this canbe, e.g.,be used to set policies that apply to any routing protocol in place."; } identity isis-level { if-feature "rtg-isis"; description "Base identity for the IS-IS level."; reference "ISO10589: Information technology - Telecommunications and information exchange between systems - Intermediate System to Intermediate Systemintra- domainintra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"; } identity level-1 { base isis-level; description "IS-ISlevelLevel 1."; } identity level-2 { base isis-level; description "IS-ISlevelLevel 2."; } identity level-1-2 { base isis-level; description "IS-ISlevelsLevels 1 and 2."; } identity bfd-session-type { if-feature "bfd"; description "Base identity for the BFD session type."; } identity classic-bfd { base bfd-session-type; description "Classic BFD."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD)"; } identity s-bfd { base bfd-session-type; description "Seamless BFD."; reference "RFC 7880: Seamless Bidirectional Forwarding Detection (S-BFD)"; } /* * Identities related toRoutes Importroute import andExportexport policies */ identity ie-type { description "Base identity for'import/export'import/export routing profiles. These profiles can be reused between VPN nodes."; } identity import { base ie-type; description"'Import'"Import routing profile."; reference "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs), Section 4.3.1"; } identity export { base ie-type; description"'Export'"Export routing profile."; reference "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs), Section 4.3.1"; } identity import-export { base ie-type; description"'Import/export'"Import/export routing profile."; } /* * Identities related to bandwidth and QoS */ identity bw-direction { description "Base identity for the bandwidth direction."; } identity inbound-bw { if-feature "inbound-bw"; base bw-direction; description "Inbound bandwidth."; } identity outbound-bw { if-feature "outbound-bw"; base bw-direction; description "Outbound bandwidth."; } identity bw-type { description "Base identity for the bandwidth type."; } identity bw-per-cos { if-feature "qos"; base bw-type; description "The bandwidth isper-CoS.";per CoS."; } identity bw-per-port { base bw-type; description "The bandwidth isper-siteper a given site network access."; } identity bw-per-site { base bw-type; description "The bandwidth isper-site.per site. It is applicable to all the site network accesses within a site."; } identity bw-per-service { base bw-type; description "The bandwidth isper-VPNper VPN service."; } identity qos-profile-direction { if-feature "qos"; description "Base identity for the QoS profile direction."; } identity site-to-wan { base qos-profile-direction; description"Customer"From the customer site to the provider'snetwork direction.network. This is typically the CE-to-PE direction."; } identity wan-to-site { base qos-profile-direction; description"Provider's"From the provider's network to the customersite direction.site. This is typically the PE-to-CE direction."; } identity both { base qos-profile-direction; description "BothWAN-to-Sitethe WAN-to-site direction andSite-to-WAN directions.";the site-to-WAN direction."; } /* * Identities related to underlay transport instances */ identity transport-instance-type { description "Base identity for underlay transport instancetype.";types."; } identity virtual-network { base transport-instance-type; description "Virtual network."; reference "RFC 8453: Framework for Abstraction and Control of TE Networks (ACTN)"; } identity enhanced-vpn { base transport-instance-type; description "Enhanced VPN (VPN+). VPN+ is an approach that is based on existing VPN and Traffic Engineering (TE) technologies but adds characteristics that specific services require over and above classical VPNs."; reference"I-D.ietf-teas-enhanced-vpn:"draft-ietf-teas-enhanced-vpn-09: A Framework for Enhanced Virtual Private Network (VPN+) Services"; } identity ietf-network-slice { base transport-instance-type; description "IETF network slice. An IETF network slice is a logical network topology connecting a number of endpoints using a set of shared or dedicated network resources that are used to satisfy specific service objectives."; reference"I-D.ietf-teas-ietf-network-slices:"draft-ietf-teas-ietf-network-slices-05: Framework for IETF Network Slices"; } /* * Identities related to protocol types. These types aretypically* typically used to identify the underlay transport. */ identity protocol-type { description "Base identity forProtocol Type.";protocol types."; } identity ip-in-ip { base protocol-type; description "Transport is based onIP-in-IP.";IP in IP."; reference "RFC 2003: IP Encapsulation within IP RFC 2473: Generic Packet Tunneling in IPv6 Specification"; } identity ip-in-ipv4 { base ip-in-ip; description "Transport is based on IP over IPv4."; reference "RFC 2003: IP Encapsulation within IP"; } identity ip-in-ipv6 { base ip-in-ip; description "Transport is based on IP over IPv6."; reference "RFC 2473: Generic Packet Tunneling in IPv6 Specification"; } identity gre { base protocol-type; description "Transport is based on Generic Routing Encapsulation (GRE)."; reference "RFC 1701: Generic Routing Encapsulation (GRE) RFC 1702: Generic Routing Encapsulation over IPv4 networks RFC 7676: IPv6 Support for Generic Routing Encapsulation (GRE)"; } identity gre-v4 { base gre; description "Transport is based on GRE over IPv4."; reference "RFC 1702: Generic Routing Encapsulation over IPv4 networks"; } identity gre-v6 { base gre; description "Transport is based on GRE over IPv6."; reference "RFC 7676: IPv6 Support for Generic Routing Encapsulation (GRE)"; } identity vxlan-trans { base protocol-type; description "Transport is based onVXLAN.";VXLANs."; reference "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks"; } identity geneve { base protocol-type; description "Transport is based on Generic Network Virtualization Encapsulation(GENEVE).";(Geneve)."; reference "RFC 8926: Geneve: Generic Network Virtualization Encapsulation"; } identity ldp { base protocol-type; description "Transport is based on LDP."; reference "RFC 5036: LDP Specification"; } identity mpls-in-udp { base protocol-type; description "Transport is based on MPLS in UDP."; reference "RFC 7510: Encapsulating MPLS in UDP"; } identity sr { base protocol-type; description "Transport is based on Segment Routing (SR)."; reference "RFC 8660: Segment Routing with the MPLS Data Plane RFC 8663: MPLS Segment Routing over IP RFC 8754: IPv6 Segment Routing Header (SRH)"; } identity sr-mpls { base sr; description "Transport is based on SR withMPLS.";the MPLS data plane."; reference "RFC 8660: Segment Routing with the MPLS Data Plane"; } identity srv6 { base sr; description "Transport is based on SR over IPv6."; reference "RFC 8754: IPv6 Segment Routing Header (SRH)"; } identity sr-mpls-over-ip { base sr; description "Transport is based on SR over MPLS over IP."; reference "RFC 8663: MPLS Segment Routing over IP"; } identity rsvp-te { base protocol-type; description "Transport setup relies upon RSVP-TE."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity bgp-lu { base protocol-type; description "Transport setup relies uponBGP-LU.";BGP-based labeled prefixes."; reference "RFC 8277: Using BGP to Bind MPLS Labels to Address Prefixes"; } identity unknown { base protocol-type; description"Not known"Unknown protocol type."; } /* * Identities related toencapsulationsencapsulation types */ identity encapsulation-type { description "Base identity fortheencapsulationtype.";types."; } identity priority-tagged { base encapsulation-type; description "Priority-tagged interface."; } identity dot1q { if-feature "dot1q"; base encapsulation-type; description"Dot1q"dot1Q encapsulation."; } identity qinq { if-feature "qinq"; base encapsulation-type; description "QinQ encapsulation."; } identity qinany { if-feature "qinany"; base encapsulation-type; description "QinAny encapsulation."; } identity vxlan { if-feature "vxlan"; base encapsulation-type; description"VxLAN"VXLAN encapsulation."; } identity ethernet-type { base encapsulation-type; description "Ethernet encapsulation type."; } identity vlan-type { base encapsulation-type; description "VLAN encapsulation type."; } identity untagged-int { base encapsulation-type; description "Untagged interface type."; } identity tagged-int { base encapsulation-type; description "Tagged interface type."; } identity lag-int { if-feature "lag-interface"; base encapsulation-type; description "LAG interface type."; } /* * Identities related to VLANTagtags */ identity tag-type { description "Base identity fortheVLAN tag types."; } identity c-vlan { base tag-type; description "Indicates a Customer VLAN (C-VLAN) tag, normally using the 0x8100 Ethertype."; } identity s-vlan { base tag-type; description "Indicates a Service VLAN (S-VLAN) tag."; } identity s-c-vlan { base tag-type; description "Uses both an S-VLAN tag and a C-VLAN tag."; } /* * Identities related toVXLANVXLANs */ identity vxlan-peer-mode { if-feature "vxlan"; description "Base identity fortheVXLAN peermode.";modes."; } identity static-mode { base vxlan-peer-mode; description "VXLAN access in the static mode."; } identity bgp-mode { base vxlan-peer-mode; description "VXLAN access by BGP EVPN learning."; } /* * Identities related to multicast */ identity multicast-gp-address-mapping { if-feature "multicast"; description "Base identity for multicast group mappingtype.";types."; } identity static-mapping { base multicast-gp-address-mapping; description "Static mapping, i.e.,attach thean interface is attached to the multicast group as a static member."; } identity dynamic-mapping { base multicast-gp-address-mapping; description "Dynamic mapping, i.e., an interface is added to the multicast group as a result of snooping."; } identity multicast-tree-type { if-feature "multicast"; description "Base identity for multicast treetype.";types."; } identity ssm-tree-type { base multicast-tree-type; description "Source-Specific Multicast (SSM) tree type."; } identity asm-tree-type { base multicast-tree-type; description "Any-Source Multicast (ASM) tree type."; } identity bidir-tree-type { base multicast-tree-type; description "Bidirectional tree type."; } identity multicast-rp-discovery-type { if-feature "multicast"; description "Base identity for Rendezvous Point (RP) discoverytype.";types."; } identity auto-rp { base multicast-rp-discovery-type; description "Auto-RP discovery type."; } identity static-rp { base multicast-rp-discovery-type; description "Static type."; } identity bsr-rp { base multicast-rp-discovery-type; description "Bootstrap Router (BSR) discovery type."; } identity group-management-protocol { if-feature "multicast"; description "Base identity for multicast group managementprotocol.";protocols."; } identity igmp-proto { base group-management-protocol; description "IGMP."; reference "RFC 1112: Host Extensions for IP Multicasting RFC 2236: Internet Group Management Protocol, Version 2 RFC 3376: Internet Group Management Protocol, Version 3"; } identity mld-proto { base group-management-protocol; description "MLD."; reference "RFC 2710: Multicast Listener Discovery (MLD) for IPv6 RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6"; } identity pim-proto { if-feature "pim"; base routing-protocol-type; description "PIM."; reference "RFC 7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"; } identity igmp-version { if-feature "igmp"; description "Base identity for indicating the IGMP version."; } identity igmpv1 { base igmp-version; description "IGMPv1."; reference "RFC 1112: Host Extensions for IP Multicasting"; } identity igmpv2 { base igmp-version; description "IGMPv2."; reference "RFC 2236: Internet Group Management Protocol, Version 2"; } identity igmpv3 { base igmp-version; description "IGMPv3."; reference "RFC 3376: Internet Group Management Protocol, Version 3"; } identity mld-version { if-feature "mld"; description "Base identity for indicating the MLD version."; } identity mldv1 { base mld-version; description "MLDv1."; reference "RFC 2710: Multicast Listener Discovery (MLD) for IPv6"; } identity mldv2 { base mld-version; description "MLDv2."; reference "RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6"; } /* * Identities related to traffic types */ identity tf-type { description "Base identity forthetraffictype.";types."; } identity multicast-traffic { base tf-type; description "Multicast traffic."; } identity broadcast-traffic { base tf-type; description "Broadcast traffic."; } identity unknown-unicast-traffic { base tf-type; description "Unknown unicast traffic."; } /* * Identities related to customer applications */ identity customer-application { description "Base identity for customer applications."; } identity web { base customer-application; description "Web applications (e.g., HTTP, HTTPS)."; } identity mail { base customer-application; description "Mail application."; } identity file-transfer { base customer-application; description "File transfer application (e.g., FTP,SFTP).";Secure FTP (SFTP))."; } identity database { base customer-application; description "Database application."; } identity social { base customer-application; description "Social-network application."; } identity games { base customer-application; description "Gaming application."; } identity p2p { base customer-application; description "Peer-to-peer application."; } identity network-management { base customer-application; description "Management application (e.g., Telnet, syslog, SNMP)."; } identity voice { base customer-application; description "Voice application."; } identity video { base customer-application; description"Video conference"Video-conference application."; } identity embb { base customer-application; description "Enhanced Mobile Broadband (eMBB) application. Note thataneMBBapplication demandsapplications demand network performance with a wide variety ofcharacteristics,such characteristics as data rate, latency, loss rate, reliability, and many other parameters."; } identity urllc { base customer-application; description "Ultra-Reliable and Low Latency Communications (URLLC) application. Note thatanURLLCapplication demandsapplications demand network performance with a wide variety ofcharacteristics,such characteristics as latency, reliability, and many other parameters."; } identity mmtc { base customer-application; description "Massive Machine Type Communications (mMTC) application. Note thatanmMTCapplication demandsapplications demand network performance with a wide variety ofcharacteristics,such characteristics as data rate, latency, loss rate, reliability, and many other parameters."; } /* * Identities related to service bundling */ identity bundling-type { description "The base identity for the bundling type. It supports a subset or allCE-VLANsCustomer Edge VLAN IDs (CE-VLAN IDs) associated with an L2VPN service."; } identity multi-svc-bundling { base bundling-type; description "Multi-service bundling, i.e., multipleC-VLANCE-VLAN IDs can be associated with an L2VPN service at a site."; } identity one2one-bundling { base bundling-type; description "One-to-one service bundling, i.e., each L2VPN can be associated with only oneC-VLANCE-VLAN ID at a site."; } identity all2one-bundling { base bundling-type; description "All-to-one bundling, i.e., allC-VLANCE-VLAN IDs are mapped to one L2VPN service."; } /* * Identities related to EthernetServicesservices */ identity control-mode { description "BaseIdentityidentity for the type of control modeonused with the Layer 2 Control Protocol (L2CP)."; } identity peer { base control-mode; description "'peer' mode, i.e., participate in the protocol towards the CE. Peering is common for the Link Aggregation Control Protocol (LACP) and the Ethernet Local Management Interface (E-LMI) and, occasionally, for the Link Layer Discovery Protocol (LLDP). For VPLSs and VPWSs, the subscriber can also request that the peer service providerenablesenable spanning tree."; } identity tunnel { base control-mode; description "'tunnel' mode, i.e., pass to the egress or destination site. For Ethernet Private Lines (EPLs), the expectation is that L2CP frames aretunnelled.";tunneled."; } identity discard { base control-mode; description "'Discard' mode, i.e., discard the frame."; } identity neg-mode { description "Base identity for the type of negotiation mode."; } identity full-duplex { base neg-mode; description "Full-duplex negotiation mode."; } identity auto-neg { base neg-mode; description "Auto-negotiation mode."; } /********Collection ofVPN-relatedTypestype ********/ typedef vpn-id { type string; description "Defines an identifier that is used with a VPN module.This can be, forFor example, this can be a service identifier, a node identifier, etc."; } /******* VPN-related reusable groupings *******/ grouping vpn-description { description "Provides common VPN information."; leaf vpn-id { type vpn-common:vpn-id; description "A VPN identifier that uniquely identifies a VPN. This identifier has a local meaning, e.g., within a service provider network."; } leaf vpn-name { type string; description "Used to associate a name with the service in order to facilitate the identification of the service."; } leaf vpn-description { type string; description "Textual description of a VPN."; } leaf customer-name { type string; description "Name of the customer that actually uses the VPN."; } } grouping vpn-profile-cfg { description "Grouping for VPNProfileprofile configuration."; container valid-provider-identifiers { description "Container for valid provider profile identifiers."; list external-connectivity-identifier { if-feature "external-connectivity"; key "id"; description "Listforof profile identifiers that uniquely identify profiles governing how external connectivity is provided to a VPN. A profile indicates the type of external connectivity (Internet, cloud, etc.), the sites/nodes that are associated with a connectivity profile, etc. A profile can also indicate filtering rules and/or address translation rules. Such features may involve PE, P, or dedicated nodes as a function of the deployment."; leaf id { type string; description "Identification of an external connectivity profile. The profile only has significance within the service provider's administrative domain."; } } list encryption-profile-identifier { key "id"; description "Listforof encryption profile identifiers."; leaf id { type string; description "Identification of the encryption profile to be used. The profile only has significance within the service provider's administrative domain."; } } list qos-profile-identifier { key "id"; description "Listforof QoSProfile Identifiers.";profile identifiers."; leaf id { type string; description "Identification of the QoS profile to be used. The profile only has significance within the service provider's administrative domain."; } } list bfd-profile-identifier { key "id"; description "Listforof BFD profile identifiers."; leaf id { type string; description "Identification of the BFD profile to be used. The profile only has significance within the service provider's administrative domain."; } } list forwarding-profile-identifier { key "id"; description "Listforof forwarding profile identifiers."; leaf id { type string; description "Identification of the forwarding profile to be used. The profile only has significance within the service provider's administrative domain."; } } list routing-profile-identifier { key "id"; description "Listfor Routing Profile Identifiers.";of routing profile identifiers."; leaf id { type string; description "Identification of the routing profile to be used by the routing protocols within sites,vpn-network-accesses,VPN network accesses, orvpn-nodesVPN nodes forreferingreferring to VRF's import/export policies. The profile only has significance within the service provider's administrative domain."; } } nacm:default-deny-write; } } grouping oper-status-timestamp { description "This grouping defines some operational parameters for the service."; leaf status { type identityref { base operational-status; } config false; description"Operations"Operational status."; } leaf last-change { type yang:date-and-time; config false; description "Indicates the actual date and time of the service status change."; } } grouping service-status { description "Service status grouping."; container status { description "Service status."; container admin-status { description "Administrative service status."; leaf status { type identityref { base administrative-status; } description "Administrative service status."; } leaf last-change { type yang:date-and-time; description "Indicates the actual date and time of the service status change."; } } container oper-status { config false; description "Operational service status."; uses oper-status-timestamp; } } } grouping underlay-transport { description "This grouping defines the type of underlay transport for the VPN service or how that underlay is set. It can include an identifiertofor an abstract transport instance to which the VPN is grafted or indicate a technical implementation that is expressed as an ordered list of protocols."; choice type { description "A choice based on the type of underlay transport constraints."; case abstract { description "Indicates that the transport constraint is an abstract concept."; leaf transport-instance-id { type string; description "An optional identifier of the abstract transport instance."; } leaf instance-type { type identityref { base transport-instance-type; } description "Indicates a transport instance type. For example, it can be a VPN+, an IETF network slice, a virtual network, etc."; } } case protocol { description "Indicates a list of protocols."; leaf-list protocol { type identityref { base protocol-type; } ordered-by user; description "Aclient orderedclient-ordered list of transport protocols."; } } } } grouping vpn-route-targets { description "A grouping that specifies Route Target (RT)import-exportimport/export rules used in a BGP-enabled VPN."; reference "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs) RFC 4664: Framework for Layer 2 Virtual Private Networks (L2VPNs)"; list vpn-target { key "id"; description"Route targets."RTs. AND/OR operations may be defined based on theRTs assigment.";assigned RTs."; leaf id { type uint8; description "Identifies each VPNTarget.";target."; } list route-targets { key "route-target"; description "List of RTs."; leaf route-target { type rt-types:route-target; description "Conveys an RT value."; } } leaf route-target-type { type rt-types:route-target-type; mandatory true; description "Import/export type of the RT."; } } container vpn-policies { description "VPN service policies.It'vpn-policies' contains references to the import and export policies to be associated with the VPN service."; leaf import-policy { type string; description "Identifies the'import'import policy."; } leaf export-policy { type string; description "Identifies the'export'export policy."; } } } grouping route-distinguisher { description "Grouping forroute distinguisher (RD).";Route Distinguishers (RDs)."; choice rd-choice { description"Route distinguisher"RD choice between several optionsonfor providing theroute distinguisherRD value."; case directly-assigned { description "Explicitlyassignassigns an RD value."; leaf rd { type rt-types:route-distinguisher; description "Indicates an RD value that is explicitly assigned."; } } case directly-assigned-suffix { description "The value of the Assigned Number subfield of the RD. The Administrator subfield of the RD will be based on other configuration information such asrouter-idthe Router ID orASN.";Autonomous System Number (ASN)."; leaf rd-suffix { type uint16; description "Indicates the value of the Assigned Number subfield that is explicitly assigned."; } } case auto-assigned { description "The RD is auto-assigned."; container rd-auto { description "The RD is auto-assigned."; choice auto-mode { description "Indicates the auto-assignment mode. The RD can be automatically assigned with or without indicating a pool from which the RD should be taken. For both cases, the server will auto-assign an RD value 'auto-assigned-rd' and use that value operationally."; case from-pool { leaf rd-pool-name { type string; description "The auto-assignment will be made from the pool identified bythe rd-pool-name.";'rd-pool-name'."; } } case full-auto { leaf auto { type empty; description "Indicates that an RD is fully auto-assigned."; } } } leaf auto-assigned-rd { type rt-types:route-distinguisher; config false; description "The value of the auto-assigned RD."; } } } case auto-assigned-suffix { description "The value of the Assigned Number subfield will be auto-assigned. The Administrator subfield will be based on other configuration information such asrouter-idthe Router ID or ASN."; container rd-auto-suffix { description "The Assigned Number subfield is auto-assigned."; choice auto-mode { description "Indicates the auto-assignment mode of the Assigned Number subfield. This number can be automatically assigned with or without indicating a pool from which the value should be taken. For both cases, the server will auto-assign 'auto-assigned-rd-suffix' and use that value to build the RD that will be used operationally."; case from-pool { leaf rd-pool-name { type string; description "The assignment will be made from the pool identified bythe rd-pool-name.";'rd-pool-name'."; } } case full-auto { leaf auto { type empty; description "Indicates that the Assigned Number subfield is fullyauto assigned.";auto-assigned."; } } } leaf auto-assigned-rd-suffix { type uint16; config false; description "Includes the value of the Assigned Number subfield that isauto-assigned .";auto-assigned."; } } } case no-rd { description"Use"Uses theempty'empty' type to indicate that the RD has no value and is not to be auto-assigned."; leaf no-rd { type empty; description "No RD is assigned."; } } } } grouping vpn-components-group { description "Grouping definition to assigngroup-idsgroup IDs to associate VPN nodes, sites, or network accesses."; container groups { description "Lists the groups to which a VPN node, a site, or a network accessbelongs to.";belongs."; list group { key "group-id"; description "List ofgroup-ids.";group IDs."; leaf group-id { type string; description"Is the group-id"The group ID to which a VPN node, a site, or a network accessbelongs to.";belongs."; } } } } grouping placement-constraints { description "Constraintsfor placingrelated to placement of a network access."; list constraint { key "constraint-type"; description "List of constraints."; leaf constraint-type { type identityref { base placement-diversity; } description "Diversity constraint type."; } container target { description "The constraint will apply against this list of groups."; choice target-flavor { description "Choice for the group definition."; case id { list group { key "group-id"; description "List of groups."; leaf group-id { type string; description "The constraint will apply against this particulargroup-id.";group ID."; } } } case all-accesses { leaf all-other-accesses { type empty; description "The constraint will apply against all other network accesses of a site."; } } case all-groups { leaf all-other-groups { type empty; description "The constraint will apply against all other groupsthatmanaged by thecustomer is managing.";customer."; } } } } } } grouping ports { description "Choice of specifyingasource or destination port numbers."; choice source-port { description "Choice of specifying the source port or referring to a group of source port numbers."; container source-port-range-or-operator { description "Source port definition."; uses packet-fields:port-range-or-operator; } } choice destination-port { description "Choice of specifying a destination port or referring to a group of destination port numbers."; container destination-port-range-or-operator { description "Destination port definition."; uses packet-fields:port-range-or-operator; } } } grouping qos-classification-policy { description "Configuration of the traffic classification policy."; list rule { key "id"; ordered-by user; description "List of marking rules."; leaf id { type string; description "An identifier of the QoS classification policy rule."; } choice match-type { default "match-flow"; description "Choice for classification."; case match-flow { choice l3 { description "Either IPv4 or IPv6."; container ipv4 { description "Rule set that matches the IPv4 header."; uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv4-header-fields; } container ipv6 { description "Rule set that matches the IPv6 header."; uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv6-header-fields; } } choice l4 { description "IncludesLayer 4 specificLayer-4-specific information. This version focuses on TCP and UDP."; container tcp { description "Rule set that matches the TCP header."; uses packet-fields:acl-tcp-header-fields; uses ports; } container udp { description "Rule set that matches the UDP header."; uses packet-fields:acl-udp-header-fields; uses ports; } } } case match-application { leaf match-application { type identityref { base customer-application; } description "Defines the application to match."; } } } leaf target-class-id {if-feature "qos";type string; description "Identification of the class of service. This identifier is internal to the administration."; } } } }<CODE ENDS>]]></artwork> </figure></t>]]></sourcecode> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>The YANGmodulesmodule specified in this documentdefine schemasdefines a schema for data that is designed to be accessed via network management protocols such as NETCONF <xreftarget="RFC6241"></xref>target="RFC6241"/> or RESTCONF <xreftarget="RFC8040"></xref>.target="RFC8040"/>. 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"/>. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS <xreftarget="RFC8446"></xref>.</t>target="RFC8446"/>.</t> <t>The Network Configuration Access Control Model (NACM) <xreftarget="RFC8341"></xref>target="RFC8341"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.</t> <t>The "ietf-vpn-common" module defines a set of identities, types, and groupings. These nodes are intended to be reused by other YANG modules. The module by itself does not exposeby itselfany data nodeswhichthat are writable, data nodes that contain read-only state, or RPCs. As such, there are no additional security issuesto be considered relatingrelated to the "ietf-vpn-common"module.</t>module that need to be considered.</t> <t>Modules that use the groupings that are defined in this document should identify the corresponding security considerations. For example, reusing some of these groupings will expose privacy-related information (e.g.,customer-name).'customer-name'). Disclosing such information may be consideredasa violation of the customer-provider trust relationship.</t> </section> <section anchor="IANA"title="IANA Considerations"> <t>This document requests IANA to registernumbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" <xreftarget="RFC3688"></xref>:</t> <t><figure> <artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-vpn-common Registrant Contact: The IESG. XML: N/A;target="RFC3688" format="default"/>:</t> <dl newline="false" spacing="compact"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-vpn-common</dd> <dt>Registrant Contact:</dt><dd>The IESG.</dd> <dt>XML:</dt><dd>N/A; the requested URI is an XMLnamespace.]]></artwork> </figure></t> <t>This document requests IANA to registernamespace.</dd> </dl> <t>IANA has registered the following YANG module in the "YANG Module Names" subregistry <xreftarget="RFC6020"></xref>target="RFC6020" format="default"/> within the "YANG Parameters" registry.</t><t><figure> <artwork><![CDATA[ name: ietf-vpn-common namespace: urn:ietf:params:xml:ns:yang:ietf-vpn-common maintained<dl newline="false" spacing="compact"> <dt>Name:</dt><dd>ietf-vpn-common</dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-vpn-common</dd> <dt>Maintained byIANA: N prefix: vpn-common reference: RFC XXXX]]></artwork> </figure></t>IANA?</dt><dd>N</dd> <dt>Prefix:</dt><dd>vpn-common</dd> <dt>Reference:</dt><dd>RFC 9181</dd> </dl> </section><section anchor="ack" title="Acknowledgements"> <t>During the discussions of this work, helpful comments and reviews were received from (listed alphabetically): Alejandro Aguado, Raul Arco, Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Tom Petch, Erez Segev, and Paul Sherratt. Many thanks to them.</t> <t>This work is partially supported by the European Commission under Horizon 2020 grant agreement number 101015857 Secured autonomic traffic management for a Tera of SDN flows (Teraflow).</t> <t>Many thanks to Radek Krejci for the yangdoctors review, Wesley Eddy for the tsvart review, Ron Bonica and Victoria Pritchard for the Rtgdir review, Joel Halpern for the genart review, Tim Wicinski for the opsdir review, and Suresh Krishnan for the intdir review.</t> <t>Special thanks to Robert Wilton</middle> <back> <displayreference target="I-D.ietf-teas-enhanced-vpn" to="Enhanced-VPN-Framework"/> <references> <name>References</name> <references> <name>Normative References</name> <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.3688.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.7950.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.8040.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.8446.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.8294.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.4364.xml"/> </references> <references> <name>Informative References</name> <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.0791.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8512.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2236.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2710.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5798.xml"/> <!-- draft-ietf-opsawg-l3sm-l3nm (RFC 9182) --> <reference anchor='RFC9182' target="https://www.rfc-editor.org/info/rfc9182"> <front> <title>A YANG Network Data Model forthe AD review.</t> <t>Thanks to Roman Danyliw, Lars Eagert, Warren Kumari, Erik Kline, Zaheduzzaman Sarker, Benjamin Kaduk, and Éric VynckeLayer 3 VPNs</title> <author initials='S' surname='Barguil' fullname='Samier Barguil'> <organization /> </author> <author initials='O' surname='Gonzalez de Dios' fullname='Oscar Gonzalez de Dios' role="editor"> <organization /> </author> <author initials='M' surname='Boucadair' fullname='Mohamed Boucadair' role="editor"> <organization /> </author> <author initials='L' surname='Munoz' fullname='Luis Munoz'> <organization /> </author> <author initials='A' surname='Aguado' fullname='Alejandro Aguado'> <organization /> </author> <date year='2022' month='February'/> </front> <seriesInfo name="RFC" value="9182"/> <seriesInfo name="DOI" value="10.17487/RFC9182"/> </reference> <!-- draft-ietf-teas-enhanced-vpn (I-D Exists) --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-teas-enhanced-vpn.xml"/> <!-- draft-ietf-teas-actn-vn-yang (I-D Exists) Long way; two editors --> <reference anchor='ACTN-VN-YANG'> <front> <title>A YANG Data Model forthe IESG review.</t> </section> <section title="Contributors"> <t><figure> <artwork><![CDATA[ Italo Busi Huawei Technologies Email: Italo.Busi@huawei.com Luis Angel Munoz Vodafone Email: luis-angel.munoz@vodafone.com Victor Lopez Alvarez Telefonica Email: victor.lopezalvarez@telefonica.com]]></artwork> </figure></t> </section> </middle>VN Operation</title> <author initials='Y' surname='Lee' fullname='Young Lee' role="editor"> <organization /> </author> <author initials='D' surname='Dhody' fullname='Dhruv Dhody' role="editor"> <organization /> </author> <author initials='D' surname='Ceccarelli' fullname='Daniele Ceccarelli'> <organization /> </author> <author initials='I' surname='Bryskin' fullname='Igor Bryskin'> <organization /> </author> <author initials='B' surname='Yoon' fullname='Bin-Yeong Yoon'> <organization /> </author> <date year='2021' month='October' day='23' /> </front> <seriesInfo name='Internet-Draft' value='draft-ietf-teas-actn-vn-yang-13'/> </reference> <!--*****BACK MATTER *****draft-ietf-opsawg-l2nm (I-D Exists) Long way; two editors, plus a couple names messed up in original repo. file --> <reference anchor='L2NM-YANG'> <front> <title>A Layer 2 VPN Network YANG Model</title> <author initials='S' surname='Barguil' fullname='Samier Barguil'> <organization /> </author> <author initials='O' surname='Gonzalez de Dios' fullname='Oscar Gonzalez de Dios' role="editor"> <organization /> </author> <author initials='M' surname='Boucadair' fullname='Mohamed Boucadair' role="editor"> <organization /> </author> <author initials='L' surname='Munoz' fullname='Luis Munoz'> <organization /> </author> <date year='2021' month='November' day='22' /> </front> <seriesInfo name='Internet-Draft' value='draft-ietf-opsawg-l2nm-12'/> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8299.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.7348.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4577.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6565.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.1701.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1702.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7676.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8663.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8277.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.7432.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5036.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.4761.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.7623.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.8365.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3931.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2003.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2473.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7510.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4176.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.8453.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2453.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2080.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7880.xml"/> <!-- draft-ietf-teas-ietf-network-slices I-D Exists Long way; one author is editor --><back> <references title="Normative References"> <?rfc include='reference.RFC.6991'?> <?rfc include='reference.RFC.3688'?> <?rfc include='reference.RFC.6020'?> <?rfc include='reference.RFC.7950'?> <?rfc include='reference.RFC.6241'?> <?rfc include='reference.RFC.8040'?> <?rfc include='reference.RFC.6242'?> <?rfc include='reference.RFC.8446'?> <?rfc include='reference.RFC.8341'?> <?rfc include='reference.RFC.8294'?> <?rfc include='reference.RFC.8519'?> <?rfc include='reference.RFC.4364'?> </references> <references title="Informative References"> <?rfc include='reference.RFC.8340'?> <?rfc include='reference.RFC.0791'?> <?rfc include='reference.RFC.8200'?> <?rfc include='reference.RFC.8512'?> <?rfc include='reference.RFC.1112'?> <?rfc include='reference.RFC.2236'?> <?rfc include='reference.RFC.3376'?> <?rfc include='reference.RFC.2710'?> <?rfc include='reference.RFC.3810'?> <?rfc include='reference.RFC.7761'?> <?rfc include='reference.RFC.5798'?> <?rfc include='reference.I-D.ietf-opsawg-l3sm-l3nm'?> <?rfc include='reference.I-D.ietf-teas-enhanced-vpn'?> <?rfc include='reference.I-D.ietf-teas-actn-vn-yang'?> <?rfc include='reference.I-D.ietf-opsawg-l2nm'?> <?rfc include='reference.RFC.8299'?> <?rfc include='reference.RFC.8466'?> <?rfc include='reference.RFC.7348'?> <?rfc include='reference.RFC.6513'?> <?rfc include='reference.RFC.4577'?> <?rfc include='reference.RFC.6565'?> <?rfc include='reference.RFC.5880'?> <?rfc include='reference.RFC.1701'?> <?rfc include='reference.RFC.1702'?> <?rfc include='reference.RFC.7676'?> <?rfc include='reference.RFC.8660'?> <?rfc include='reference.RFC.8663'?> <?rfc include='reference.RFC.8754'?> <?rfc include='reference.RFC.8277'?> <?rfc include='reference.RFC.6624'?> <?rfc include='reference.RFC.7432'?> <?rfc include='reference.RFC.5036'?> <?rfc include='reference.RFC.4762'?> <?rfc include='reference.RFC.4761'?> <?rfc include='reference.RFC.8214'?> <?rfc include='reference.RFC.7623'?> <?rfc include='reference.RFC.4664'?> <?rfc include='reference.RFC.8365'?> <?rfc include='reference.RFC.3931'?> <?rfc include='reference.RFC.2003'?> <?rfc include='reference.RFC.2473'?> <?rfc include='reference.RFC.8926'?> <?rfc include='reference.RFC.7510'?> <?rfc include='reference.RFC.3209'?> <?rfc include='reference.RFC.4176'?> <?rfc include='reference.RFC.4026'?> <?rfc include='reference.RFC.8453'?> <?rfc include='reference.RFC.4960'?> <?rfc include='reference.RFC.4271'?> <?rfc include='reference.RFC.2453'?> <?rfc include='reference.RFC.2080'?> <?rfc include='reference.RFC.7880'?> <?rfc include='reference.I-D.ietf-teas-ietf-network-slices'?><referenceanchor="IEEE802.1Q">anchor="Network-Slices-Framework"> <front><title>Bridges<title>Framework for IETF Network Slices</title> <author initials="A" surname="Farrel" fullname="Adrian Farrel" role="editor"> <organization/></author> <author initials="E" surname="Gray" fullname="Eric Gray"> <organization/></author> <author initials="J" surname="Drake" fullname="John Drake"> <organization/></author> <author initials="R" surname="Rokui" fullname="Reza Rokui"> <organization/></author> <author initials="S" surname="Homma" fullname="Shunsuke Homma"> <organization/></author> <author initials="K" surname="Makhijani" fullname="Kiran Makhijani"> <organization/></author> <author initials="LM" surname="Contreras" fullname="Luis M. Contreras"> <organization/></author> <author initials="J" surname="Tantsura" fullname="Jeff Tantsura"> <organization/></author> <date month='October' day='25' year='2021'/> </front> <seriesInfo name='Internet-Draft' value='draft-ietf-teas-ietf-network-slices-05'/> </reference> <reference anchor="IEEE802.1Q" target="https://standards.ieee.org/standard/802_1Q-2018.html"> <front> <title>IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks</title><author> <organization></organization> </author><author><organization>IEEE</organization></author> <!-- <date day="06" month="July"year="2018" />year="2018"/> --> </front><seriesInfo name="IEEE" value="Std 802.1Q-2018" /></reference> <referenceanchor="IEEE802.1ad">anchor="IEEE802.1ad" target="https://standards.ieee.org/standard/802_1ad-2005.html"> <front><title>Virtual<title>IEEE Standard for Local and Metropolitan Area Networks---Virtual Bridged Local AreaNetworks AmendmentNetworks---Amendment 4: Provider Bridges</title><author> <organization></organization> </author><author><organization>IEEE</organization></author> <!-- <date month=""year="2006" />year="2006"/> --> </front><seriesInfo name="IEEE" value="Std 802.1ad-2005" /></reference> <referenceanchor="IEEE802.1AX">anchor="IEEE802.1AX" target="https://standards.ieee.org/standard/802_1AX-2020.html"> <front><title>Link<title>IEEE Standard for Local and Metropolitan Area Networks--Link Aggregation</title><author> <organization></organization> </author><author><organization>IEEE</organization></author> <!-- <date month=""year="2020" />year="2020"/> --> </front><seriesInfo name="IEEE" value="Std 802.1AX-2020" /></reference> <reference anchor="ISO10589"target="International Standard 10589:2002, Second Edition">target="https://www.iso.org/standard/30932.html"> <front><title>Intermediate<title>Information technology - Telecommunications and information exchange between systems - Intermediate System to Intermediate Systemintra- domainintra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)</title><author fullname="ISO"> <organization></organization> </author><author><organization>ISO</organization></author> <dateyear="2002" />month="November" year="2002"/> </front> <refcontent>International Standard 10589:2002, Second Edition</refcontent> </reference> </references> </references> <section anchor="app-ex"title="Examplenumbered="true" toc="default"> <name>Example of Common Data Nodes in Early L2NM/L3NMDesigns">Designs</name> <t>In order to avoid duplication of data nodesduplicationand to ease passing data among layers (i.e., from the service layer to the network layer and vice versa), early versions of the L3NM reused many of the data nodes that are defined in the L3SM. Nevertheless, that approach was abandoned because that design was interpreted as if the deployment of the L3NM depends on the L3SM, while this is not required. For example, a service provider may decide to use the L3NM to build its L3VPN services without exposing the L3SM to customers.</t> <t>Likewise, early versions of the L2NM reused many of the data nodes that are defined in both the L2SM and the L3NM. An example of L3NM groupings reused in the L2NM is shown in <xreftarget="ex2"></xref>.target="ex2" format="default"/>. Such reuse of data nodesreusewas interpreted as if the deployment of the L2NM requiresthesupportoffor theL3NM;L3NM, which is not required.</t><t><figure align="left" anchor="ex2" title="Excerpt<figure anchor="ex2"> <name>Excerpt from the L2NM YANGModule"> <artwork><![CDATA[moduleModule</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[module ietf-l2vpn-ntw { ... import ietf-l3vpn-ntw { prefix l3vpn-ntw; reference "RFCNNNN:9182: A YANG Network Data Model for Layer 3VPN Network YANG Model";VPNs"; } ... container l2vpn-ntw { ... container vpn-services { list vpn-service { ... uses l3vpn-ntw:service-status; uses l3vpn-ntw:svc-transport-encapsulation; ... } } ... } } ]]></artwork></figure></t> <t></t></figure> </section> <section anchor="ack" numbered="false" toc="default"> <name>Acknowledgements</name> <t>During the discussions of this work, helpful comments and reviews were received from (listed alphabetically) <contact fullname="Alejandro Aguado"/>, <contact fullname="Raul Arco"/>, <contact fullname="Miguel Cros 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="Tom Petch"/>, <contact fullname="Erez Segev"/>, and <contact fullname="Paul Sherratt"/>. Many thanks to them.</t> <t>This work is partially supported by the European Commission under Horizon 2020 Secured autonomic traffic management for a Tera of SDN flows (Teraflow) project (grant agreement number 101015857).</t> <t>Many thanks to <contact fullname="Radek Krejci"/> for the YANG Doctors review, <contact fullname="Wesley Eddy"/> for the tsvart review, <contact fullname="Ron Bonica"/> and <contact fullname="Victoria Pritchard"/> for the RtgDir review, <contact fullname="Joel Halpern"/> for the genart review, <contact fullname="Tim Wicinski"/> for the opsdir review, and <contact fullname="Suresh Krishnan"/> for the intdir review.</t> <t>Special thanks to <contact fullname="Robert Wilton"/> for the AD review.</t> <t>Thanks to <contact fullname="Roman Danyliw"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Erik Kline"/>, <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Benjamin Kaduk"/>, and <contact fullname="Éric Vyncke"/> for the IESG review.</t> </section> <section numbered="false" toc="default"> <name>Contributors</name> <contact fullname="Italo Busi"> <organization>Huawei Technologies</organization> <address> <postal> <street></street> <city></city> <region></region> <code></code> <country></country> </postal> <email>Italo.Busi@huawei.com</email> </address> </contact> <contact fullname="Luis Angel Munoz"> <organization>Vodafone</organization> <address> <postal> <street></street> <city></city> <region></region> <code></code> <country></country> </postal> <email>luis-angel.munoz@vodafone.com</email> </address> </contact> <contact fullname="Victor Lopez"> <organization>Nokia</organization> <address> <postal> <street></street> <city>Madrid</city> <region></region> <code></code> <country>Spain</country> </postal> <email>victor.lopez@nokia.com</email> </address> </contact> </section> </back> </rfc>