RFC 9291: A YANG Network Data Model for Layer 2 VPNs
- M. Boucadair, Ed.,
- O. Gonzalez de Dios, Ed.,
- S. Barguil,
- L. Munoz
Abstract
This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices.¶
Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types.¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
[RFC8466] defines an L2VPN Service Model (L2SM) YANG data model that can be used between customers and service providers for ordering Layer 2 Virtual Private Network (L2VPN) services. This document complements the L2SM by creating a network-centric view of the service: the L2VPN Network Model (L2NM).¶
Also, this document defines the initial versions of two IANA-maintained modules that define a set of identities of BGP Layer 2 encapsulation types (Section 8.1) and pseudowire types (Section 8.2). These types are used in the L2NM to identify a Layer 2 encapsulation type as a function of the signaling option used to deliver an L2VPN service. Relying upon these IANA-maintained modules is meant to provide more flexibility in handling new types rather than being limited by a set of identities defined in the L2NM itself. Section 8.3 defines another YANG module to manage Ethernet Segments (ESes) that are required for instantiating Ethernet VPNs (EVPNs). References to Ethernet segments that are created using the module in Section 8.3 can be included in the L2NM for EVPNs.¶
The L2NM (Section 8.4) can be exposed, for
example, by a network controller to a service controller within the
service provider's network. In particular, the model can be used in the
communication interface between the entity that interacts directly with
the customer (i.e., the service orchestrator) and the entity in charge
of network orchestration and control (a.k.a., network
controller
The L2NM supports capabilities such as exposing operational parameters, transport protocols selection, and precedence. It can also serve as a multi-domain orchestration interface.¶
The L2NM is scoped for a variety of Layer 2 Virtual Private Networks such as:¶
The L2NM is designed to easily support future Layer 2 VPN flavors and procedures (e.g., advanced configuration such as pseudowires resilience or multi-segment pseudowires [RFC7267]). A set of examples to illustrate the use of the L2NM are provided in Appendix A.¶
This document uses the common Virtual Private Network (VPN) YANG module defined in [RFC9181].¶
The YANG data models in this document conform to the Network Management Datastore Architecture (NMDA) defined in [RFC8342].¶
2. Terminology
This document assumes that the reader is familiar with [RFC6241], [RFC7950], [RFC8466], [RFC4026], and [RFC8309]. This document uses terminology from those documents.¶
This document uses the term "network model" as defined in Section 2.1 of [RFC8969].¶
The meanings of the symbols in the YANG tree diagrams are defined in [RFC8340].¶
This document makes use of the following terms:¶
- Ethernet Segment (ES):
- Refers to the set of Ethernet links that are used by a customer site (device or network) to connect to one or more Provider Edges (PEs).¶
- L2VPN Service Model (L2SM):
- Describes the
service characterizatio
n of an L2VPN that interconnects a set of sites from the customer's perspective. The customer service model does not provide details on the service provider network. An L2VPN customer service model is defined in [RFC8466].¶ - L2VPN Network Model (L2NM):
- Refers to the YANG data model that describes an L2VPN service with a network-centric view. It contains information on the service provider network and might include allocated resources. Network controllers can use it to manage the Layer 2 VPN service configuration in the service provider's network. The corresponding YANG module can be used by a service orchestrator to request a VPN service to a network controller or to expose the list of active L2VPN services. The L2NM can also be used to retrieve a set of L2VPN-related state information (including Operations, Administration, and Maintenance (OAM)).¶
- MAC-VRF:
- Refers to a Virtual Routing and Forwarding (VRF) table for Media Access Control (MAC) addresses on a PE.¶
- Network controller:
- Denotes a functional entity responsible for the management of the service provider network.¶
- Service orchestrator:
- Refers to a functional entity that interacts with the customer of an L2VPN relying upon, e.g., the L2SM. The service orchestrator is responsible for the Customer Edge to Provider Edge (CE-PE) attachment circuits, the PE selection, and requesting the activation of the L2VPN service to a network controller.¶
- Service provider network:
- A network that is able to provide L2VPN-related services.¶
- VPN node:
- An abstraction that represents a set of policies applied on a PE and belongs to a single VPN service. A VPN service involves one or more VPN nodes. The VPN node will identify the service providers' node on which the VPN is deployed.¶
- VPN network access:
- An abstraction that represents the network interfaces that are associated with a given VPN node. Traffic coming from the VPN network access belongs to the VPN. The attachment circuits (bearers) between CEs and PEs are terminated in the VPN network access.¶
- VPN service provider:
- A service provider that offers L2VPN-related services.¶
3. Acronyms and Abbreviations
The following acronyms and abbreviations are used in this document:¶
- ACL
- Access Control List¶
- BGP
- Border Gateway Protocol¶
- BUM
- Broadcast, Unknown Unicast, or Multicast¶
- CE
- Customer Edge¶
- ES
- Ethernet Segment¶
- ESI
- Ethernet Segment Identifier¶
- EVPN
- Ethernet VPN¶
- L2VPN
- Layer 2 Virtual Private Network¶
- L2SM
- L2VPN Service Model¶
- L2NM
- L2VPN Network Model¶
- MAC
- Media Access Control¶
- PBB
- Provider Backbone Bridging¶
- PCP
- Priority Code Point¶
- PE
- Provider Edge¶
- QoS
- Quality of Service¶
- RD
- Route Distinguisher¶
- RT
- Route Target¶
- VPLS
- Virtual Private LAN Service¶
- VPN
- Virtual Private Network¶
- VPWS
- Virtual Private Wire Service¶
- VRF
- Virtual Routing and Forwarding¶
4. Reference Architecture
Figure 1 illustrates how the L2NM is used. As a reminder, this figure is an expansion of the architecture presented in Section 3 of [RFC8466] and decomposes the box marked "orchestration" in that figure into three separate functional components called "Service Orchestration", "Network Orchestration", and "Domain Orchestration".¶
Similar to Section 3 of [RFC8466], CE to PE
attachment is achieved through a bearer with a Layer 2 connection on
top. The bearer refers to properties of the attachment that are below
Layer 2, while the connection refers to Layer 2 protocol
The reader may refer to [RFC8309] for the distinction between the "Customer Service Model", "Service Delivery Model", "Network Configuration Model", and "Device Configuration Model". The "Domain Orchestration" and "Config Manager" roles may be performed by "SDN Controllers".¶
The customer may use various means to request a service that may trigger the instantiation of an L2NM. The customer may use the L2SM or may rely upon more abstract models to request a service that relies upon an L2VPN service. For example, the customer may supply an IP Connectivity Provisioning Profile (CPP) that characterizes the requested service [RFC7297], an enhanced VPN (VPN+) service [VPN+-FRAMEWORK], or an IETF network slice service [IETF-NET-SLICES].¶
Note also that both the L2SM and L2NM may be used in the context of the Abstraction and Control of TE Networks (ACTN) framework [RFC8453]. Figure 2 shows the Customer Network Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and the Provisioning Network Controller (PNC).¶
5. Relationship to Other YANG Data Models
The "ietf
Also, the L2NM uses the IANA-maintained modules "iana
For the particular case of EVPN, the L2NM includes a name that refers
to an Ethernet segment that is created using the "ietf
As discussed in Section 4, the L2NM is used to manage L2VPN services within a service provider network. The module provides a network view of the L2VPN service. Such a view is only visible to the service provider and is not exposed outside (to customers, for example). The following discusses how the L2NM interfaces with other YANG modules:¶
- L2SM:
-
The L2NM is not a customer service model.¶
The internal view of the service (i.e., the L2NM) may be mapped to an external view that is visible to customers: L2VPN Service Model (L2SM) [RFC8466].¶
The L2NM can be fed with inputs that are requested by customers and that typically rely on an L2SM template. Concretely, some parts of the L2SM module can be directly mapped into the L2NM while other parts are generated as a function of the requested service and local guidelines. Finally, there are parts local to the service provider, and they do not map directly to the L2SM.¶
Note that using the L2NM within a service provider does not assume, nor does it preclude, exposing the VPN service via the L2SM. This is deployment specific. Nevertheless, the design of L2NM tries to align as much as possible with the features supported by the L2SM to ease the grafting of both the L2NM and the L2SM for the sake of highly automated VPN service provisioning and delivery.¶
- Network Topology Modules:
- An L2VPN involves nodes that are part of a topology managed by the service provider network. Such a topology can be represented using the network topology module in [RFC8345] or its extension, such as a network YANG module for Service Attachment Points (SAPs) [YANG-SAPS].¶
- Device Modules:
-
The L2NM is not a device model.¶
Once a global VPN service is captured by means of the L2NM, the actual activation and provisioning of the VPN service will involve a variety of device modules to tweak the required functions for the delivery of the service. These functions are supported by the VPN nodes and can be managed using device YANG modules. A non
-comprehensive list of such device YANG modules is provided below:¶ How the L2NM is used to derive device-specific actions is implementation specific.¶
6. Description of the Ethernet Segment YANG Module
The 'ietf
The descriptions of the data nodes depicted in Figure 3 are as follows:¶
- 'name':
-
Sets a name to uniquely identify an ES within a service provider network. In order to ease referencing ESes by their name in other modules, "es-ref" typedef is defined.¶
This typedef is used in the VPN network access level of the L2NM to reference an ES (Section 7.6). An example to illustrate such a use in the L2NM is provided in Appendix A.4.¶
- 'esi-type':
-
Indicates the Ethernet Segment Identifier (ESI) type as discussed in Section 5 of [RFC7432]. ESIs can be automatically assigned either with or without indicating a pool from which an ESI should be taken
('esi -pool -name' ). The following types are supported:¶ - 'esi
-type -0 -operator' : - The ESI is directly
configured by the VPN service provider. The configured value is
provided in 'ethernet
-segment -identifier' .¶ - 'esi
-type -1 -lacp' : - The ESI is auto-generated from the IEEE 802.1AX Link Aggregation Control Protocol (LACP) [IEEE802.1AX].¶
- 'esi
-type -2 -bridge' : - The ESI is auto-generated and determined based on the Layer 2 bridge protocol.¶
- 'esi
-type -3 -mac' : - The ESI is a MAC-based ESI value that can be auto-generated or configured by the VPN service provider.¶
- 'esi
-type -4 -router -id' : - The ESI is auto-generated or configured by the VPN service provider based on the Router ID. The 'router-id' supplied in Section 7.5 can be used to auto-derive an ESI when this type is used.¶
- 'esi
-type -5 -asn' : - The ESI is auto-generated or
configured by the VPN service provider based on the Autonomous
System (AS) number. The 'local
-autonomous -system' supplied in Section 7.4 can be used to auto-derive an ESI when this type is used.¶
Auto-generated values can be retrieved using 'auto
-ethernet -segment -identifier' .¶ - 'esi
- 'esi
-redundancy -mode' : - Specifies the EVPN redundancy mode for a given ES. The following modes are supported: Single-Active (Section 14.1.1 of [RFC7432]) or All-Active (Section 14.1.2 of [RFC7432]).¶
- 'df-election':
-
Specifies a set of parameters related to the Designated Forwarder (DF) election (Section 8.5 of [RFC7432]). For example, this data node can be used to indicate an election method (e.g., [RFC8584] or [EVPN-PERF-DF]). If no election method is indicated, the default method defined in Section 8.5 of [RFC7432] is used.¶
As discussed in Section 1.3.2 of [RFC8584], the default behavior is to trigger the DF election procedure when a DF fails (e.g., link failure). The former DF will take over when it is available again. Such a mode is called 'revertive'. The behavior can be overridden by setting the 'revertive' leaf to 'false'.¶
Also, this data node can be used to configure a DF Wait timer
('election -wait -time' ) (Section 2.1 of [RFC8584]).¶ - 'split
-horizon -filtering' : - Controls the activation of the split-horizon filtering for an ES (Section 8.3 of [RFC7432]).¶
- 'pbb':
-
Indicates data nodes that are specific to PBB [IEEE-802-1ah]:¶
- 'backbone
-src -mac' : - Associates a Provider Backbone MAC (B-MAC) address with an ES. This is particularly useful for All-Active multihomed ESes (Section 9.1 of [RFC7623]).¶
- 'backbone
- 'member':
- Lists the members of an ES in a service provider network.¶
7. Description of the L2NM YANG Module
The L2NM
The full tree diagram of the module can be generated using the "pyang" tool [PYANG]. That tree is not included here because it is too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided for the reader's convenience.¶
Note that the following subsections introduce some data nodes that
enclose textual descriptions (e.g., VPN service (Section 7.3), VPN node (Section 7.5), or VPN network access (Section 7.6)). Such descriptions are not intended for random
end users but for network
7.1. Overall Structure of the Module
The 'ietf
The 'vpn-profiles' container is used by the provider to define and maintain a set of common VPN profiles that apply to VPN services (Section 7.2).¶
The 'vpn-services' container maintains the set of L2VPN services managed in the service provider network. The module allows creating a new L2VPN service by adding a new instance of 'vpn-service'. The 'vpn-service' is the data structure that abstracts the VPN service (Section 7.3).¶
7.2. VPN Profiles
The 'vpn-profiles' container (Figure 5) is used by a VPN service provider to define and maintain a set of VPN profiles [RFC9181] that apply to one or several VPN services.¶
The exact definition of these profiles is local to each VPN service provider. The model only includes an identifier for these profiles in order to ease identifying and binding local policies when building a VPN service. As shown in Figure 5, the following identifiers can be included:¶
- 'external
-connectivity -identifier' : - This identifier refers to a profile that defines the external connectivity provided to a VPN service (or a subset of VPN sites). External connectivity may be access to the Internet or restricted connectivity such as access to a public/private cloud.¶
- 'encryption
-profile -identifier' : - An encryption profile refers to a set of policies related to the encryption schemes and setup that can be applied when building and offering a VPN service.¶
- 'qos
-profile -identifier' : - A Quality of Service (QoS) profile refers to a set of policies such as classification, marking, and actions (e.g., [RFC3644]).¶
- 'bfd
-profile -identifier' : - A Bidirectional Forwarding Detection (BFD) profile refers to a set of BFD policies [RFC5880] that can be invoked when building a VPN service.¶
- 'forwarding
-profile -identifier' : - A forwarding profile refers to the policies that apply to the forwarding of packets conveyed within a VPN. Such policies may consist of, for example, applying ACLs.¶
- 'routing
-profile -identifier' : - A routing profile refers to a set of routing policies that will be invoked (e.g., BGP policies) when delivering the VPN service.¶
7.3. VPN Services
The 'vpn-service' is the data structure that abstracts an L2VPN service in the service provider network. Each 'vpn-service' is uniquely identified by an identifier: 'vpn-id'. Such a 'vpn-id' is only meaningful locally within the network controller. The subtree of the 'vpn-services' is shown in Figure 6.¶
The descriptions of the VPN service data nodes that are depicted in Figure 6 are as follows:¶
- 'vpn-id':
- An identifier that is used to uniquely identify the L2VPN service within the L2NM scope.¶
- 'vpn-name':
- Associates a name with the service in order to facilitate the identification of the service.¶
- 'vpn
-description' : -
Includes a textual description of the service.¶
The internal structure of a VPN description is local to each VPN service provider.¶
- 'customer-name':
- Indicates the name of the customer who ordered the service.¶
- 'parent
-service -id' : - Refers to an identifier of the parent service (e.g., the L2SM, IETF network slice, and VPN+) that triggered the creation of the L2VPN service. This identifier is used to easily correlate the (network) service as built in the network with a service order. A controller can use that correlation to enrich or populate some fields (e.g., description fields) as a function of local deployments.¶
- 'vpn-type':
-
Indicates the L2VPN type. The following types, defined in [RFC9181], can be used for the L2NM:¶
- 'vpls':
- Virtual Private LAN Service (VPLS) as defined in [RFC4761] or [RFC4762]. This type is also used for hierarchical VPLS (H-VPLS) (Section 10 of [RFC4762]).¶
- 'vpws':
- Virtual Private Wire Service (VPWS) as defined in Section 3.1.1 of [RFC4664].¶
- 'vpws-evpn':
- VPWS EVPNs as defined in [RFC8214].¶
- 'pbb-evpn':
- Provider Backbone Bridging (PBB) EVPNs as defined in [RFC7623].¶
- 'mpls-evpn':
- MPLS-based EVPNs [RFC7432].¶
- 'vxlan-evpn':
- VXLAN-based EVPNs [RFC8365].¶
The type is used as a condition for the presence of some data nodes in the L2NM.¶
- 'vpn
-service -topology' : - Indicates the network topology for the service: hub-spoke, any-to-any, or custom. These types are defined in [RFC9181].¶
- 'bgp
-ad -enabled' : - Controls whether BGP auto-discovery is enabled. If so, additional data nodes are included (Section 7.5.1).¶
- 'signaling
-type' : -
Indicates the signaling that is used for setting up pseudowires. Signaling type values are taken from [RFC9181]. The following signaling options are supported:¶
- 'bgp-signaling':
-
The L2NM supports two flavors of BGP-signaled L2VPNs:¶
- 'l2vpn-bgp':
- The service is a Multipoint VPLS that uses a BGP control plane as described in [RFC4761] and [RFC6624].¶
- 'evpn-bgp':
- The service is a Multipoint VPLS that uses a BGP control plane but also includes the additional EVPN features and related parameters as described in [RFC7432] and [RFC7209].¶
- 'ldp-signaling':
- A Multipoint VPLS that uses a mesh of LDP-signaled pseudowires [RFC6074].¶
- 'l2tp
-signaling' : - The L2NM uses L2TP-signaled pseudowires as described in [RFC6074].¶
Table 1 summarizes the allowed signaling types for each VPN service type ('vpn-type'). See Section 7.5.2 for more details.¶
- 'global
-parameters -profiles' : -
Defines reusable parameters for the same L2VPN service.¶
More details are provided in Section 7.4.¶
- 'underlay
-transport' : -
Describes the preference for the transport technology to carry the traffic of the VPN service. This preference is especially useful in networks with multiple domains and Network
-to -Network Interface (NNI) types. The underlay transport can be expressed as an abstract transport instance (e.g., an identifier of a VPN+ instance, a virtual network identifier, or a network slice name) or as an ordered list of the actual protocols to be enabled in the network.¶ A rich set of protocol identifiers that can be used to refer to an underlay transport (or how such an underlay is set up) are defined in [RFC9181].¶
The model defined in Section 6.3.2 of [TE
-SERVICE ] may be used if specific protection and availability requirements are needed between PEs.¶-MAPPING - 'status':
-
Used to track the overall status of a given VPN service. Both operational and administrative status are maintained together with a timestamp. For example, a service can be created but not put into effect.¶
Administrative and operational status can be used as a trigger to detect service anomalies. For example, a service that is declared at the service layer as being created but still inactive at the network layer is an indication that network provisioning actions are needed to align the observed service status with the expected service status.¶
- 'vpn-node':
-
An abstraction that represents a set of policies applied to a network node and belonging to a single 'vpn-service'. An L2VPN service is typically built by adding instances of 'vpn-node' to the 'vpn-nodes' container.¶
A 'vpn-node' contains 'vpn
-network -accesses', which are the interfaces attached to the VPN by which the customer traffic is received. Therefore, the customer sites are connected to the 'vpn -network -accesses' .¶ Note that, as this is a network data model, the information about customers sites is not required in the model. Such information is rather relevant in the L2SM. Whether that information is included in the L2NM, e.g., to populate the various 'description' data nodes, is implementation specific.¶
More details are provided in Section 7.5.¶
7.4. Global Parameters Profiles
The 'global
The description of the global parameters profile is as follows:¶
- 'profile-id':
- Uniquely identifies a global parameter profile in the context of an L2VPN service.¶
- 'rd':
-
As defined in [RFC9181], these RD assignment modes are supported: direct assignment, automatic assignment from a given pool, full automatic assignment, and no assignment.¶
Also, the module accommodates deployments where only the Assigned Number subfield of RDs is assigned from a pool while the Administrator subfield is set to, e.g., the Router ID that is assigned to a VPN node. The module supports these modes to manage the Assigned Number subfield: explicit assignment, auto-assignment from a pool, and full auto
-assignment .¶ - 'vpn-targets':
- Specifies RT import/export rules for the VPN service.¶
- 'local
-autonomous -system' : - Indicates the Autonomous System Number (ASN) that is configured for the VPN node. The ASN can be used to auto-derive some other attributes such as RDs or Ethernet Segment Identifiers (ESIs).¶
- 'svc-mtu':
- Is the service MTU for an L2VPN service
(i.e., a Layer 2 MTU including an L2 frame header
/trailer ). It is also known as the maximum transmission unit or maximum frame size. It is expressed in bytes.¶ - 'ce
-vlan -preservation' : - Is set to preserve the Customer Edge VLAN (CE VLAN) IDs from ingress to egress, i.e., CE VLAN tags of the egress frame are identical to those of the ingress frame that yielded this egress service frame. If all-to-one bundling within a site is enabled, then preservation applies to all ingress service frames. If all-to-one bundling is disabled, then preservation applies to tagged Ingress service frames having CE VLAN ID 1 through 4094.¶
- 'ce
-vlan -cos -preservation' : - Controls the CE VLAN Class of Service (CoS) preservation. When set, Priority Code Point (PCP) bits in the CE VLAN tag of the egress frame are identical to those of the ingress frame that yielded this egress service frame.¶
- 'control
-word -negotiation' : - Controls whether control-word negotiation is enabled (if set to true) or not (if set to false). Refer to Section 7 of [RFC8077] for more details.¶
- 'mac-policies':
-
Includes a set of MAC policies that apply to the service:¶
- 'mac
-addr -limit' : -
Is a container of MAC address limit configuration. It includes the following data nodes:¶
- 'mac
-loop -prevention' : -
Container for MAC loop prevention.¶
- 'window':
- The time interval over which a MAC mobility event is detected and checked.¶
- 'frequency':
- The number of times to detect MAC duplication, where a 'duplicate MAC address' situation has occurred within the 'window' time interval, and the duplicate MAC address has been added to a list of duplicate MAC addresses.¶
- 'retry-timer':
- The retry timer. When the retry timer expires, the duplicate MAC address will be flushed from the MAC-VRF.¶
- 'protection
-type' : - It defines the loop prevention type (e.g., shut).¶
- 'mac
- 'multicast':
- Controls whether multicast is allowed in the service.¶
7.5. VPN Nodes
The 'vpn-node' (Figure 8) is an
abstraction that represents a set of policies applied
to a network node that belongs to a single 'vpn-service'. A
'vpn-node' contains 'vpn
The descriptions of VPN node data nodes are as follows:¶
- 'vpn-node-id':
- Used to uniquely identify a node that enables a VPN network access.¶
- 'description':
- Provides a textual description of the VPN node.¶
- 'ne-id':
- Includes an identifier of the network element where the VPN node is deployed.¶
- 'role':
- Indicates the role of the VPN instance
profile in the VPN. Role values are defined in [RFC9181] (e.g., 'any
-to -any -role', 'spoke-role', and 'hub-role').¶ - 'router-id':
- Indicates a 32-bit number that is used to uniquely identify a router within an AS.¶
- 'active
-global -parameters -profiles' : -
Lists the set of active global VPN parameter profiles for this VPN node. Concretely, one or more global profiles that are defined at the VPN service level (i.e., under 'l2vpn
-ntw /vpn -services /vpn -service' level) can be activated at the VPN node level; each of these profiles is uniquely identified by means of 'profile-id'. The structure of 'active -global -parameters -profiles' uses the same data nodes as Section 7.4 with the exception of the data nodes related to RD and RT.¶ Values defined in 'active
-global -parameters -profiles' override the values defined in the VPN service level.¶ - 'status':
- Tracks the status of a node involved in a VPN service. Both operational and administrative status are maintained. A mismatch between the administrative status vs. the operational status can be used as a trigger to detect anomalies.¶
- 'bgp
-auto -discovery' : - See Section 7.5.1.¶
- 'signaling
-option' : - See Section 7.5.2.¶
- 'vpn
-network -accesses' : -
Represents the point to which sites are connected.¶
Note that, unlike the L2SM, the L2NM does not need to model the customer site; only the points that receive traffic from the site are covered (i.e., the PE side of Provider Edge to Customer Edge (PE-CE) connections). Hence, the VPN network access contains the connectivity information between the provider's network and the customer premises. The VPN profiles
('vpn -profiles' ) have a set of routing policies that can be applied during the service creation.¶ See Section 7.6 for more details.¶
7.5.1. BGP Auto-Discovery
The 'bgp
As discussed in Section 1 of [RFC6624], all BGP-based methods include the notion of a VPN identifier that serves to unify components of a given VPN and the concept of auto-discovery, hence the support of the data node 'vpn-id'.¶
For the particular case of EVPN, the L2NM supports RT
auto-derivation based on the Ethernet Tag ID specified in Section 7.10.1 of [RFC7432]. A VPN service provider can
enable/disable this functionality by means of 'auto
For all BGP-based L2VPN flavors, other data nodes such as RD and RT are used. These data nodes have the same structure as the one discussed in Section 7.4.¶
7.5.2. Signaling Options
The 'signaling
The following signaling data nodes are supported:¶
- 'advertise-mtu':
- Controls whether MTU is advertised when setting a pseudowire (e.g., Section 4.3 of [RFC4667], Section 5.1 of [RFC6624], or Section 6.1 of [RFC4762]).¶
- 'mtu
-allow -mismatch' : - When set to true, it allows an MTU mismatch for a pseudowire (see, e.g., Section 4.3 of [RFC4667]).¶
- 'signaling
-type' : - Indicates the signaling type.
This type inherits the value of 'signaling
-type' defined at the service level (Section 7.3).¶ - 'bgp':
- Is provided when BGP is used for L2VPN signaling. Refer to Section 7.5.2.1 for more details.¶
- 'ldp':
- The model supports the configuration of the parameters that are discussed in Section 6 of [RFC4762]. Refer to Section 7.5.2.2 for more details.¶
- 'l2tp':
- The model supports the configuration of the parameters that are discussed in Section 4 of [RFC4667]. Refer to Section 7.5.2.3 for more details.¶
Note that LDP and L2TP choices are bundled ("ldp-or-l2tp") because they share a set of common parameters that are further detailed in Sections 7.5.2.2 and 7.5.2.3.¶
7.5.2.1. BGP
The structure of the BGP-related data nodes is provided in Figure 11.¶
Remote CEs that are entitled to connect to the same VPN should
fit with the CE range ('ce-range') as discussed in Section 2.2.3 of [RFC6624]. 'pw
For the specific case of VPLS, the VPLS Edge Identifier (VE ID)
For EVPN-related L2VPNs, 'service
7.5.2.2. LDP
The L2NM supports the configuration of the parameters that are discussed in Section 6 of [RFC4762]. Such parameters include an Attachment Group Identifier (AGI) (a.k.a., VPLS-id), a Source Attachment Individual Identifier (SAII), a list of peers that are associated with a Target Attachment Individual Identifier (TAII), a pseudowire type, and a pseudowire description (Figure 12). Unlike BGP, only Ethernet and Ethernet tagged mode are supported. The AGI, SAII, and TAII are encoded following the types defined in Section 3.4 of [RFC4446].¶
7.5.2.3. L2TP
The L2NM supports the configuration of the parameters that are
discussed in Section 4 of [RFC4667]. Such
parameters include a Router ID that is used to uniquely identify a
PE, a pseudowire type, an AGI, an SAII, and a list of peers that
are associated with a TAII (Figure 13). The
pseudowire type
7.6. VPN Network Accesses
A 'vpn
A 'vpn
The VPN network access is comprised of the following:¶
- 'id':
- Includes an identifier of the VPN network access.¶
- 'description':
- Includes a textual description of the VPN network access.¶
- 'interface-id':
- Indicates the interface on which the VPN network access is bound.¶
- 'active
-vpn -node -profile' : - Provides a pointer to an
active 'global
-parameters -profile' at the VPN node level. Referencing an active 'global -parameters -profile' implies that all associated data nodes will be inherited by the VPN network access. However, some of the inherited data nodes (e.g., ACL policies) can be overridden at the VPN network access level. In such case, adjusted values take precedence over inherited values.¶ - 'status':
- Indicates the administrative and operational status of the VPN network access.¶
- 'connection':
- Represents and groups the set of Layer 2 connectivity from where the traffic of the L2VPN in a particular VPN network access is coming. See Section 7.6.1.¶
- 'signaling
-option' : -
Indicates a set of signaling options that are specific to a given VPN network access, e.g., a CE ID ('ce-id' identifying the CE within the VPN) and a remote CE ID as discussed in Section 2.2.2 of [RFC6624].¶
It can also include a set of data nodes that are required for the configuration of a VPWS-EVPN [RFC8214]. See Section 7.6.2.¶
- 'group':
- Is used for grouping VPN network accesses by assigning the same identifier to these accesses. The precedence attribute is used to differentiate the primary and secondary accesses for a service with multiple accesses. An example to illustrate the use of this container for redundancy purposes is provided in Appendix A.6. This container is also used to identify the link of an ES by allocating the same ESI. An example to illustrate this functionality is provided in Appendices A.4 and A.5.¶
- 'ethernet
-service -oam' : - Carries information about the service OAM. See Section 7.6.3.¶
- 'service':
- Specifies the service parameters (e.g., QoS and multicast) to apply for a given VPN network access. See Section 7.6.4.¶
7.6.1. Connection
The 'connection' container (Figure 15) is used to configure the relevant properties of the interface to which the L2VPN instance is attached to (e.g., encapsulation type, Link Aggregation Group (LAG) interfaces, and split-horizon). The L2NM supports tag manipulation operations (e.g., tag rewrite).¶
Note that the 'connection' container does not include the
physical
A reference to the bearer is maintained to allow keeping the link between the L2SM and the L2NM when both data models are used in a given deployment.¶
Some consistency checks should be ensured by implementations (typically, network controllers) for LAG interfaces, as the same information (e.g., LACP system-id) should be provided to the involved nodes.¶
The L2NM inherits the 'member
7.6.2. EVPN-VPWS Service Instance
The 'vpws
An example to illustrate the use of the L2NM to configure VPWS-EVPN instances is provided in Appendix A.4.¶
7.6.3. Ethernet OAM
Ethernet OAM refers to both [IEEE-802-1ag] and [ITU-T-Y-1731].¶
As shown in Figure 17, the L2NM inherits the same structure as in Section 5.3.2.2.6 of [RFC8466] for OAM matters.¶
7.6.4. Services
The 'service' container (Figure 18)
provides a set of service
The description of the service data nodes is as follows:¶
- 'mtu':
- Specifies the Layer 2 MTU, in bytes, for the VPN network access.¶
- 'svc
-pe -to -ce -bandwidth' and 'svc -ce -to -pe -bandwidth' : -
Specify the service bandwidth for the L2VPN service.¶
'svc
-pe -to -ce -bandwidth' indicates the inbound bandwidth of the connection (i.e., download bandwidth from the service provider to the site).¶ 'svc
-ce -to -pe -bandwidth' indicates the outbound bandwidth of the connection (i.e., upload bandwidth from the site to the service provider).¶ 'svc
-pe -to -ce -bandwidth' and 'svc -ce -to -pe -bandwidth' can be represented using the Committed Information Rate (CIR), the Excess Information Rate (EIR), or the Peak Information Rate (PIR).¶ As shown in Figure 19, the structure of service bandwidth data nodes is inherited from the L2SM [RFC8466]. The following types, defined in [RFC9181], can be used to indicate the bandwidth type:¶
- 'qos':
-
Is used to define a set of QoS policies to apply on a given VPN network access (Figure 20). The QoS classification can be based on many criteria such as source MAC address, destination MAC address, etc. See also Section 5.10.2.1 of [RFC8466] for more discussion of QoS classification including the use of color types.¶
- 'mac-policies':
-
Lists a set of MAC-related policies such as MAC ACLs. Similar to [RFC8519], an ACL match can be based upon source MAC address, source MAC address mask, destination MAC address, destination MAC address mask, or a combination thereof.¶
A data frame that matches an ACL can be dropped, be flooded, or trigger an alarm. A rate-limit policy can be defined for handling frames that match an ACL entry with 'flood' action.¶
When 'mac
-loop -prevention' or 'mac -addr -limit' data nodes are provided, they take precedence over the ones included in the 'global -parameters -profile' at the VPN service or VPN node levels.¶ - 'broadcast
-unknown -unicast -multicast' : -
Defines the type of site in the customer multicast service topology: source, receiver, or both. It is also used to define multicast group-to-port mappings.¶
8. YANG Modules
8.1. IANA-Maintained Module for BGP Layer 2 Encapsulation Types
The "iana
This module references [RFC3032], [RFC4446], [RFC4448], [RFC4553], [RFC4618], [RFC4619], [RFC4717], [RFC4761], [RFC4816], [RFC4842], and [RFC5086].¶
8.2. IANA-Maintained Module for Pseudowire Types
The initial version of the "iana
This module references [MFA], [RFC2507], [RFC2508], [RFC3032], [RFC3545], [RFC4448], [RFC4553], [RFC4618], [RFC4619], [RFC4717], [RFC4842], [RFC4863], [RFC4901], [RFC5086], [RFC5087], [RFC5143], [RFC5795], and [RFC6307].¶
8.3. Ethernet Segments
The "ietf
9. Security Considerations
The YANG modules specified in this document define schemas for data
that are designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure
transport layer, and the mandatory
The Network Configuration Access Control Model (NACM) [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.¶
There are a number of data nodes defined in the "ietf
- 'vpn-profiles':
- This container includes a set of sensitive data that influences
how the L3VPN service is delivered. For example, an attacker who has
access to these data nodes may be able to manipulate routing policies,
QoS policies, or encryption properties. These data nodes are defined
with "nacm
:default -deny -write" tagging [RFC9181].¶ - 'ethernet
-segments' and 'vpn-services': - An attacker who is able to access network nodes can undertake
various attacks, such as deleting a running L2VPN service,
interrupting all the traffic of a client. In addition, an attacker may
modify the attributes of a running service (e.g., QoS, bandwidth) or
an ES, leading to malfunctioning of the service and therefore to SLA
violations. In addition, an attacker could attempt to create an L2VPN
service, add a new network access, or intercept
/redirect the traffic to a non-authorized node. In addition to using NACM to prevent authorized access, such activity can be detected by adequately monitoring and tracking network configuration changes.¶
Some of the readable data nodes in the "ietf
- 'customer-name' and 'ip
-connection' : - An attacker can retrieve privacy-related information that can be used to
track a customer. Disclosing such information may be considered a
violation of the customer
-provider trust relationship.¶
Both "iana
10. IANA Considerations
10.1. Registering YANG Modules
IANA has registered the following URIs in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:¶
- URI:
- urn
:ietf :params :xml :ns :yang :iana -bgp -l2 -encaps¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
- URI:
- urn
:ietf :params :xml :ns :yang :iana -pseudowire -types¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -ethernet -segment¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -l2vpn -ntw¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
IANA has registered the following YANG modules in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry:¶
- name:
- iana
-bgp -l2 -encaps¶ - namespace:
- urn
:ietf :params :xml :ns :yang :iana -bgp -l2 -encaps¶ - maintained by IANA:
- Y¶
- prefix:
- iana
-bgp -l2 -encaps¶ - reference:
- RFC 9291¶
- name:
- iana
-pseudowire -types¶ - namespace:
- urn
:ietf :params :xml :ns :yang :iana -pseudowire -types¶ - maintained by IANA:
- Y¶
- prefix:
- iana-pw-types¶
- reference:
- RFC 9291¶
10.2. BGP Layer 2 Encapsulation Types
This document defines the initial version of the IANA-maintained
"iana
When a Layer 2 encapsulation type is added to the "BGP Layer 2
Encapsulation Types" registry, a new "identity" statement must be
added to the "iana
- "base":
- Contains 'bgp
-l2 -encaps -type' .¶ - "description":
- Replicates the description from the registry.¶
- "reference":
- Replicates the reference from the registry with the title of the document added.¶
Unassigned or reserved values are not present in the module.¶
When the "iana
IANA has added this note to [IANA-BGP-L2]:¶
10.3. Pseudowire Types
This document defines the initial version of the IANA-maintained
"iana
When a pseudowire type is added to the "iana
- "base":
- Contains 'iana
-pw -types' .¶ - "description":
- Replicates the description from the registry.¶
- "reference":
- Replicates the reference from the registry with the title of the document added.¶
Unassigned or reserved values are not present in the module.¶
When the "iana
IANA has added this note to [IANA-PW-TYPES]:¶
11. References
11.1. Normative References
- [IANA-BGP-L2]
-
IANA, "BGP Layer 2 Encapsulation Types", <https://
www >..iana .org /assignments /bgp -parameters - [IANA-PW-TYPES]
-
IANA, "MPLS Pseudowire Types Registry", <http://
www >..iana .org /assignments /pwe3 -parameters / - [IEEE-802-1ag]
-
IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management", DOI 10
.1109 , IEEE Std 802.1ag-2007, , <https:///IEEESTD .2007 .4431836 doi >..org /10 .1109 /IEEESTD .2007 .4431836 - [IEEE802.1Qcp]
-
IEEE, "IEEE Standard for Local and metropolitan area networks
--Bridges and Bridged Networks , DOI 10--Amendment 30: YANG Data Model" .1109 , IEEE Std 802.1Qcp-2018, , <https:///IEEESTD .2018 .8467507 doi >..org /10 .1109 /IEEESTD .2018 .8467507 - [ITU-T-Y-1731]
-
ITU-T, "Operation, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks", ITU-T Recommendation G.8013/Y.1731, , <https://
www >..itu .int /rec /T -REC -Y .1731 /en - [RFC3688]
-
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10
.17487 , , <https:///RFC3688 www >..rfc -editor .org /info /rfc3688 - [RFC4026]
-
Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10
.17487 , , <https:///RFC4026 www >..rfc -editor .org /info /rfc4026 - [RFC4446]
-
Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, DOI 10
.17487 , , <https:///RFC4446 www >..rfc -editor .org /info /rfc4446 - [RFC4667]
-
Luo, W., "Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)", RFC 4667, DOI 10
.17487 , , <https:///RFC4667 www >..rfc -editor .org /info /rfc4667 - [RFC4761]
-
Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10
.17487 , , <https:///RFC4761 www >..rfc -editor .org /info /rfc4761 - [RFC4762]
-
Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10
.17487 , , <https:///RFC4762 www >..rfc -editor .org /info /rfc4762 - [RFC6020]
-
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10
.17487 , , <https:///RFC6020 www >..rfc -editor .org /info /rfc6020 - [RFC6074]
-
Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10
.17487 , , <https:///RFC6074 www >..rfc -editor .org /info /rfc6074 - [RFC6241]
-
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10
.17487 , , <https:///RFC6241 www >..rfc -editor .org /info /rfc6241 - [RFC6242]
-
Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10
.17487 , , <https:///RFC6242 www >..rfc -editor .org /info /rfc6242 - [RFC6624]
-
Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, DOI 10
.17487 , , <https:///RFC6624 www >..rfc -editor .org /info /rfc6624 - [RFC6991]
-
Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10
.17487 , , <https:///RFC6991 www >..rfc -editor .org /info /rfc6991 - [RFC7432]
-
Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10
.17487 , , <https:///RFC7432 www >..rfc -editor .org /info /rfc7432 - [RFC7623]
-
Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10
.17487 , , <https:///RFC7623 www >..rfc -editor .org /info /rfc7623 - [RFC7950]
-
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10
.17487 , , <https:///RFC7950 www >..rfc -editor .org /info /rfc7950 - [RFC8040]
-
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10
.17487 , , <https:///RFC8040 www >..rfc -editor .org /info /rfc8040 - [RFC8077]
-
Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10
.17487 , , <https:///RFC8077 www >..rfc -editor .org /info /rfc8077 - [RFC8214]
-
Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, DOI 10
.17487 , , <https:///RFC8214 www >..rfc -editor .org /info /rfc8214 - [RFC8294]
-
Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10
.17487 , , <https:///RFC8294 www >..rfc -editor .org /info /rfc8294 - [RFC8341]
-
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10
.17487 , , <https:///RFC8341 www >..rfc -editor .org /info /rfc8341 - [RFC8342]
-
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10
.17487 , , <https:///RFC8342 www >..rfc -editor .org /info /rfc8342 - [RFC8365]
-
Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10
.17487 , , <https:///RFC8365 www >..rfc -editor .org /info /rfc8365 - [RFC8446]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10
.17487 , , <https:///RFC8446 www >..rfc -editor .org /info /rfc8446 - [RFC8466]
-
Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10
.17487 , , <https:///RFC8466 www >..rfc -editor .org /info /rfc8466 - [RFC8584]
-
Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet VPN Designated Forwarder Election Extensibility", RFC 8584, DOI 10
.17487 , , <https:///RFC8584 www >..rfc -editor .org /info /rfc8584 - [RFC9181]
-
Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and Layer 3 VPNs", RFC 9181, DOI 10
.17487 , , <https:///RFC9181 www >..rfc -editor .org /info /rfc9181
11.2. Informative References
- [BGP-YANG-MODEL]
-
Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP YANG Model for Service Provider Networks", Work in Progress, Internet-Draft, draft
-ietf , , <https://-idr -bgp -model -14 datatracker >..ietf .org /doc /html /draft -ietf -idr -bgp -model -14 - [EVPN-PERF-DF]
-
Rabadan, J., Ed., Sathappan, S., Lin, W., Drake, J., and A. Sajassi, "Preference
-based EVPN DF Election" , Work in Progress, Internet-Draft, draft-ietf , , <https://-bess -evpn -pref -df -10 datatracker >..ietf .org /doc /html /draft -ietf -bess -evpn -pref -df -10 - [EVPN-YANG]
-
Brissette, P., Ed., Shah, H., Ed., Chen, I., Ed., Hussain, I., Ed., Tiruveedhula, K., Ed., and J. Rabadan, Ed., "Yang Data Model for EVPN", Work in Progress, Internet-Draft, draft
-ietf , , <https://-bess -evpn -yang -07 datatracker >..ietf .org /doc /html /draft -ietf -bess -evpn -yang -07 - [IEEE-802-1ah]
-
IEEE, "IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges", IEEE Std 801.3AH-2008, , <https://
standards >..ieee .org /standard /802 _1ah -2008 .html - [IEEE-802-3ah]
-
IEEE, "IEEE Standard for Information technology-- Local and metropolitan area networks-- Part 3: CSMA/CD Access Method and Physical Layer Specifications Amendment: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks", DOI 10
.1109 , IEEE Std 802.3AH-2004, , <https:///IEEESTD .2004 .94617 doi >..org /10 .1109 /IEEESTD .2004 .94617 - [IEEE802.1AX]
-
IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Link Aggregation", DOI 10
.1109 , IEEE Std 802.1AX-2020, , <https:///IEEESTD .2020 .9105034 doi >..org /10 .1109 /IEEESTD .2020 .9105034 - [IEEE802.1Q]
-
IEEE, "IEEE Standard for Local and Metropolitan Area Network
--Bridges and Bridged Networks" , DOI 10.1109 , IEEE Std 802.1Q-2018, , <https:///IEEESTD .2018 .8403927 doi >..org /10 .1109 /IEEESTD .2018 .8403927 - [IETF
-NET -SLICES] -
Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "Framework for IETF Network Slices", Work in Progress, Internet-Draft, draft
-ietf , , <https://-teas -ietf -network -slices -14 datatracker >..ietf .org /doc /html /draft -ietf -teas -ietf -network -slices -14 - [MFA]
- MFA Forum Technical Committee, "The Use of Virtual Trunks for ATM/MPLS Control Plane Interworking Specification", MFA Forum 9.0.0, .
- [PYANG]
-
"pyang", , <https://
github >..com /mbj4668 /pyang - [RFC2507]
-
Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, DOI 10
.17487 , , <https:///RFC2507 www >..rfc -editor .org /info /rfc2507 - [RFC2508]
-
Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, DOI 10
.17487 , , <https:///RFC2508 www >..rfc -editor .org /info /rfc2508 - [RFC3032]
-
Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10
.17487 , , <https:///RFC3032 www >..rfc -editor .org /info /rfc3032 - [RFC3545]
-
Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, DOI 10
.17487 , , <https:///RFC3545 www >..rfc -editor .org /info /rfc3545 - [RFC3644]
-
Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, DOI 10
.17487 , , <https:///RFC3644 www >..rfc -editor .org /info /rfc3644 - [RFC4448]
-
Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10
.17487 , , <https:///RFC4448 www >..rfc -editor .org /info /rfc4448 - [RFC4553]
-
Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure
-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)" , RFC 4553, DOI 10.17487 , , <https:///RFC4553 www >..rfc -editor .org /info /rfc4553 - [RFC4618]
-
Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, DOI 10
.17487 , , <https:///RFC4618 www >..rfc -editor .org /info /rfc4618 - [RFC4619]
-
Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, DOI 10
.17487 , , <https:///RFC4619 www >..rfc -editor .org /info /rfc4619 - [RFC4664]
-
Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10
.17487 , , <https:///RFC4664 www >..rfc -editor .org /info /rfc4664 - [RFC4717]
-
Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, DOI 10
.17487 , , <https:///RFC4717 www >..rfc -editor .org /info /rfc4717 - [RFC4816]
-
Malis, A., Martini, L., Brayley, J., and T. Walsh, "Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service", RFC 4816, DOI 10
.17487 , , <https:///RFC4816 www >..rfc -editor .org /info /rfc4816 - [RFC4842]
-
Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, "Synchronous Optical Network
/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)" , RFC 4842, DOI 10.17487 , , <https:///RFC4842 www >..rfc -editor .org /info /rfc4842 - [RFC4863]
-
Martini, L. and G. Swallow, "Wildcard Pseudowire Type", RFC 4863, DOI 10
.17487 , , <https:///RFC4863 www >..rfc -editor .org /info /rfc4863 - [RFC4901]
-
Ash, J., Ed., Hand, J., Ed., and A. Malis, Ed., "Protocol Extensions for Header Compression over MPLS", RFC 4901, DOI 10
.17487 , , <https:///RFC4901 www >..rfc -editor .org /info /rfc4901 - [RFC5086]
-
Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, DOI 10
.17487 , , <https:///RFC5086 www >..rfc -editor .org /info /rfc5086 - [RFC5087]
-
Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, DOI 10
.17487 , , <https:///RFC5087 www >..rfc -editor .org /info /rfc5087 - [RFC5143]
-
Malis, A., Brayley, J., Shirron, J., Martini, L., and S. Vogelsang, "Synchronous Optical Network
/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation" , RFC 5143, DOI 10.17487 , , <https:///RFC5143 www >..rfc -editor .org /info /rfc5143 - [RFC5795]
-
Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, DOI 10
.17487 , , <https:///RFC5795 www >..rfc -editor .org /info /rfc5795 - [RFC5880]
-
Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10
.17487 , , <https:///RFC5880 www >..rfc -editor .org /info /rfc5880 - [RFC6307]
-
Black, D., Ed., Dunbar, L., Ed., Roth, M., and R. Solomon, "Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks", RFC 6307, DOI 10
.17487 , , <https:///RFC6307 www >..rfc -editor .org /info /rfc6307 - [RFC7209]
-
Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN (EVPN)", RFC 7209, DOI 10
.17487 , , <https:///RFC7209 www >..rfc -editor .org /info /rfc7209 - [RFC7267]
-
Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed., "Dynamic Placement of Multi-Segment Pseudowires", RFC 7267, DOI 10
.17487 , , <https:///RFC7267 www >..rfc -editor .org /info /rfc7267 - [RFC7297]
-
Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10
.17487 , , <https:///RFC7297 www >..rfc -editor .org /info /rfc7297 - [RFC7951]
-
Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10
.17487 , , <https:///RFC7951 www >..rfc -editor .org /info /rfc7951 - [RFC8309]
-
Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10
.17487 , , <https:///RFC8309 www >..rfc -editor .org /info /rfc8309 - [RFC8340]
-
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10
.17487 , , <https:///RFC8340 www >..rfc -editor .org /info /rfc8340 - [RFC8343]
-
Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10
.17487 , , <https:///RFC8343 www >..rfc -editor .org /info /rfc8343 - [RFC8345]
-
Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10
.17487 , , <https:///RFC8345 www >..rfc -editor .org /info /rfc8345 - [RFC8453]
-
Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10
.17487 , , <https:///RFC8453 www >..rfc -editor .org /info /rfc8453 - [RFC8519]
-
Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10
.17487 , , <https:///RFC8519 www >..rfc -editor .org /info /rfc8519 - [RFC8792]
-
Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10
.17487 , , <https:///RFC8792 www >..rfc -editor .org /info /rfc8792 - [RFC8960]
-
Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A YANG Data Model for MPLS Base", RFC 8960, DOI 10
.17487 , , <https:///RFC8960 www >..rfc -editor .org /info /rfc8960 - [RFC8969]
-
Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10
.17487 , , <https:///RFC8969 www >..rfc -editor .org /info /rfc8969 - [TE
-SERVICE -MAPPING] -
Lee, Y., Ed., Dhody, D., Ed., Fioccola, G., Wu, Q., Ed., Ceccarelli, D., and J. Tantsura, "Traffic Engineering (TE) and Service Mapping YANG Data Model", Work in Progress, Internet-Draft, draft
-ietf , , <https://-teas -te -service -mapping -yang -11 datatracker >..ietf .org /doc /html /draft -ietf -teas -te -service -mapping -yang -11 - [VPN+-FRAMEWORK]
-
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Network (VPN+)", Work in Progress, Internet-Draft, draft
-ietf , , <https://-teas -enhanced -vpn -11 datatracker >..ietf .org /doc /html /draft -ietf -teas -enhanced -vpn -11 - [YANG-SAPS]
-
Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu, Q., and V. Lopez, "A YANG Network Model for Service Attachment Points (SAPs)", Work in Progress, Internet-Draft, draft
-ietf , , <https://-opsawg -sap -09 datatracker >..ietf .org /doc /html /draft -ietf -opsawg -sap -09
Appendix A. Examples
This section includes a non-exhaustive list of examples to illustrate the use of the L2NM.¶
In the following subsections, only the content of the message bodies is shown using JSON notations [RFC7951].¶
The examples use folding as defined in [RFC8792] for long lines.¶
A.1. BGP-Based VPLS
This section provides an example to illustrate how the L2NM can be used to manage BGP-based VPLS. We consider the sample VPLS service delivered using the architecture depicted in Figure 23. In accordance with [RFC4761], we assume that a full mesh is established between all PEs. The details about such full mesh are not detailed here.¶
Figure 24 shows an example of a
message body used to configure a VPLS instance using the L2NM. In this
example, BGP is used for both auto-discovery and signaling. The
'signaling
A.2. BGP-Based VPWS with LDP Signaling
Let's consider the simple architecture depicted in Figure 25 to offer a VPWS between CE1 and CE2. The service uses BGP for auto-discovery and LDP for signaling.¶
A.3. LDP-Based VPLS
This section provides an example that illustrates how the L2NM can be used to manage a VPLS with LDP signaling. The connectivity between the CE and the PE is direct using Dot1q encapsulation [IEEE802.1Q]. We consider the sample service delivered using the architecture depicted in Figure 27.¶
Figure 28 shows how the L2NM is used to instruct both PE1 and PE2 to use the targeted LDP session between them to establish the VPLS "1543" between the ends. A single VPN service is created for this purpose. Additionally, two VPN Nodes that each have corresponding VPN network access are also created.¶
A.4. VPWS-EVPN Service Instance
Figure 29 depicts a sample architecture to offer VPWS-EVPN service between CE1 and CE2. Both CEs are multihomed. BGP sessions are maintained between these PEs as per [RFC8214]. In this EVPN instance, an All-Active redundancy mode is used.¶
Let's first suppose that the following ES was created (Figure 30).¶
Figure 31 shows a simplified configuration to illustrate the use of the L2NM to configure a VPWS-EVPN instance.¶
A.5. Automatic ESI Assignment
This section provides an example to illustrate how the L2NM can be
used to manage ESI auto
Figures 33 and 34 show how the L2NM is used to instruct both PE1 and PE2 to auto-assign the ESI to identify the ES used with CE1. In this example, we suppose that LACP is enabled and that a Type 1 (T=0x01) is used as per Section 5 of [RFC7432]. Note that this example does not include all the details to configure the EVPN service but focuses only on the ESI management part.¶
The auto-assigned ESI can be retrieved using, e.g., a GET RESTCONF method. The assigned value will then be returned as shown in the 'esi-auto' data node in Figure 35.¶
A.6. VPN Network Access Precedence
In reference to the example depicted in Figure 36, an L2VPN service involves two VPN network accesses to sites that belong to the same customer.¶
In order to tag one of these VPN network accesses as "primary" and the other one as "secondary", Figure 37 shows an excerpt of the corresponding L2NM configuration. In such a configuration, both accesses are bound to the same "group-id", and the "precedence" data node is set as a function of the intended role of each access (primary or secondary).¶
Acknowledgements
During the discussions of this work, helpful comments, suggestions, and reviews were received from: Sergio Belotti, Italo Busi, Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Moti Morgenstern, Tom Petch, and Erez Segev. Many thanks to them.¶
Zhang Guiyu, Luay Jalil, Daniel King, and Jichun Ma contributed to an early draft version of this document.¶
Thanks to Yingzhen Qu and Himanshu Shah for the rtgdir reviews, Ladislav Lhotka for the yangdoctors review, Chris Lonvick for the secdir review, and Dale Worley for the gen-art review. Special thanks to Adrian Farrel for the careful Shepherd review.¶
Thanks to Robert Wilton for the careful AD review and various suggestions to enhance the model.¶
Thanks to Roman Danyliw, Lars Eggert, Erik Kline, Francesca Palombini, Zaheduzzaman Sarker, and Éric Vyncke for the IESG review.¶
A YANG module for Ethernet segments was first defined in the context of the EVPN device module [EVPN-YANG].¶
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).¶