| Internet-Draft | L2NM | October 2021 |
| Barguil, et al. | Expires 4 April 2022 | [Page] |
This document defines an L2VPN Network YANG Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (VPN) services within a network (e.g., service provider network). The L2NM complements the Layer 2 Service Model (L2SM) by providing a network-centric view of the service that is internal to a service providers. As such, the L2NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices.¶
Also, the document defines the initial versions of two IANA-maintained modules that defines a set of identities of BGP Layer 2 encapsulation types and pseudowire types.¶
Please update these statements within the document with the RFC number to be assigned to this document:¶
Please update "RFC CCCC" to the RFC number to be assigned to I-D.ietf-opsawg-vpn-common.¶
Also, please update the "revision" date of the YANG modules.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 April 2022.¶
Copyright (c) 2021 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://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
[RFC8466] defines an L2VPN Service Model (L2SM) YANG data model that can be used for Layer 2 Virtual Private Network (L2VPN) service ordering matters between customers and service providers. This document complements the L2SM by creating a network-centric view of the service: the L2VPN Network Model (L2NM).¶
The L2NM (Section 7.3) can be exposed, for example, by a network controller to a service controller within the service providers network. In particular, the model can be used in the communication interface between the entity that interacts directly with the customer, the service orchestrator (either fully automated or a human operator), and the entity in charge of network orchestration and control (a.k.a., network controller/orchestrator) by allowing for more network-centric information to be included.¶
The L2NM supports capabilities, such as exposing operational parameters, transport protocols selection, and precedence. It can also serve as a multi-domain orchestration interface.¶
This document uses the common Virtual Private Network (VPN) YANG module defined in [I-D.ietf-opsawg-vpn-common]. Also, the document defines the initial versions of two IANA-maintained modules that define a set of identities of BGP Layer 2 encapsulation types (Section 7.1) and pseudowire types (Section 7.2). Relying upon these IANA-maintained modules is meant to provide more flexibility in handling new types rather than be limited by a set of identities defined in the L2NM itself.¶
The YANG data models in this document conforms to the Network Management Datastore Architecture (NMDA) defined in [RFC8342].¶
The L2NM (Section 7.3) is scoped for a variety of Layer 2 Virtual Private Networks such as Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]), Virtual Private Wire Service (VPWS) (Section 3.1.1 of [RFC4664]) and various flavors of Ethernet VPN (VPWS EVPN [RFC8214], PBB EVPN [RFC7623], EVPN over MPLS[RFC7432], and EVPN over VxLAN [RFC8365]). The module is designed to easily support future Layer 2 VPN flavors and procedures.¶
A set of examples to illustrate the use of the L2MN is provided in Appendix A.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document assumes that the reader is familiar with the contents of [RFC6241], [RFC7950], [RFC8466], [RFC8309], and uses terminology from those documents.¶
This document uses the term "network model" defined in Section 2.1 of [RFC8969].¶
The meaning of the symbols in YANG tree diagrams is [RFC8340].¶
This document makes use of the following terms:¶
The following acronyms are used in the document:¶
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".¶
The reader may refer to [RFC8309] for the distinction between the "Customer Service Model", the "Service Delivery Model", the "Network Configuration Model", and the "Device Configuration Model". The "Domain Orchestration" and "Config Manager" roles may be performed by "SDN Controllers".¶
+---------------+
| Customer |
+-------+-------+
Customer Service Model |
e.g., l2vpn-svc |
+-------+-------+
| Service |
| Orchestration |
+-------+-------+
Network Model |
l2vpn-ntw |
+-------+-------+
| Network |
| Orchestration |
+-------+-------+
Network Configuration Model |
___________|___________
| |
+--------+------+ +--------+------+
| Domain | | Domain |
| Orchestration | | Orchestration |
+---+-----------+ +--------+------+
Device | | |
Configuration | | |
Model | | |
+----+----+ | |
| Config | | |
| Manager | | |
+----+----+ | |
| | |
| NETCONF/CLI..................
| | |
+------------------------------------------------+
Network
+++++++
+ AAA +
+++++++
++++++++ Bearer ++++++++ ++++++++ ++++++++
+ CE A + ----------- + PE A + + PE B + ---- + CE B +
++++++++ Connection ++++++++ ++++++++ ++++++++
Site A Site B
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) [RFC7297], an enhanced VPN (VPN+) service [I-D.ietf-teas-enhanced-vpn], or an IETF network slice [I-D.ietf-teas-ietf-network-slices].¶
Note also that both the L2SM and the L2NM may be used in the context of the Abstraction and Control of TE Networks (ACTN) architecture [RFC8453]. Figure 2 shows the Customer Network Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and the Provisioning Network Controller (PNC).¶
+----------------------------------+
| Customer |
| +-----------------------------+ |
| | CNC | |
| +-----------------------------+ |
+----+-----------------------+-----+
| |
| L2SM | L2SM
| |
+---------+---------+ +---------+---------+
| MDSC | | MDSC |
| +---------------+ | | (parent) |
| | Service | | +---------+---------+
| | Orchestration | | |
| +-------+-------+ | | L2NM
| | | |
| | L2NM | +---------+---------+
| | | | MDSC |
| +-------+-------+ | | (child) |
| | Network | | +---------+---------+
| | Orchestration | | |
| +---------------+ | |
+---------+---------+ |
| |
| Network Configuration |
| |
+------------+-------+ +---------+------------+
| Domain | | Domain |
| Controller | | Controller |
| +---------+ | | +---------+ |
| | PNC | | | | PNC | |
| +---------+ | | +---------+ |
+------------+-------+ +---------+------------+
| |
| Device Configuration |
| |
+----+---+ +----+---+
| Device | | Device |
+--------+ +--------+
The "ietf-vpn-common" module [I-D.ietf-opsawg-vpn-common] includes a set of identities, types, and groupings that are meant to be reused by VPN-related YANG modules independently of the layer (e.g., Layer 2, Layer 3) and the type of the module (e.g., network model, service model) including future revisions of existing models (e.g., [RFC8466]). The L2NM reuses these common types and groupings.¶
Also, the L2NM uses the IANA-maintained modules "iana-bgp-l2-encaps" (Section 7.1) and "iana-pseudowire-types" (Section 7.2) to identify a layer 2 encapsulation type.¶
As discussed in Section 4, the L2NM is meant to manage L2VPN services within a service provider network. The module provides a network view of the service. Such a view is only visible within the service provider and is not exposed outside (to customers, for example). The following discusses how L2NM interfaces with other YANG modules:¶
L2NM is not a customer service model.¶
The internal view of the service (i.e., L2NM) may be mapped to an external view which is visible to customers: L2VPN Service YANG data Model (L2SM) [RFC8466].¶
The L2NM can be fed with inputs that are requested by customers, typically, relying upon an L2SM template. Concretely, some parts of the L2SM module can be directly mapped into 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 do not map directly to L2SM.¶
Note that the use of the L2NM within a service provider does not assume nor 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 grafting both L2NM and L2SM for the sake of highly automated VPN service provisioning and delivery.¶
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.¶
The L2NM ('ietf-l2vpn-ntw', Section 7.3) is meant to manage L2VPNs within a service provider network. In particular, the 'ietf-l2vpn-ntw' module can be used to create, modify, delete and retrieve L2VPN services in a network controller. The module is designed to minimize the amount of customer-related information.¶
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.¶
The 'ietf-l2vpn-ntw' module uses two main containers: 'vpn-profiles', 'ethernet-segments', and 'vpn-services' (see Figure 3).¶
The 'vpn-profiles' container is used by the provider to maintain a set of common VPN profiles that apply to one or several VPN services (Section 6.2).¶
The 'ethernet-segments' container provides a set of data related to Ethernet Segments (ESs). This container is present only for EVPN-related L2VPN types. More details are provided in Section 6.3.¶
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 6.4).¶
module: ietf-l2vpn-ntw
+--rw l2vpn-ntw
+--rw vpn-profiles
| ...
+--rw ethernet-segments
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
The 'vpn-profiles' container (Figure 4) allows the VPN service provider to define and maintain a set of VPN profiles [I-D.ietf-opsawg-vpn-common] that apply to one or several VPN services.¶
+--rw l2vpn-ntw
+--rw vpn-profiles
| +--rw valid-provider-identifiers
| +--rw external-connectivity-identifier* [id]
| | {external-connectivity}?
| | +--rw id string
| +--rw encryption-profile-identifier* [id]
| | +--rw id string
| +--rw qos-profile-identifier* [id]
| | +--rw id string
| +--rw bfd-profile-identifier* [id]
| | +--rw id string
| +--rw forwarding-profile-identifier* [id]
| | +--rw id string
| +--rw routing-profile-identifier* [id]
| +--rw id string
+--rw ethernet-segments
| ...
+--rw vpn-services
...
This document does not make any assumption about the exact definition of these profiles. The exact definition of the profiles is local to each VPN service provider. The model only includes an identifier to these profiles in order to ease identifying and binding local policies when building a VPN service. As shown in Figure 4, the following identifiers can be included:¶
The 'ethernet-segments' container is used to list a set of ESes that are defined in an EVPN service.¶
+--rw l2vpn-ntw
+--rw vpn-profiles
| ...
+--rw ethernet-segments
| +--rw ethernet-segment* [name]
| +--rw name string
| +--rw esi-type? identityref
| +--rw (esi-choice)?
| | +--:(directly-assigned)
| | | +--rw ethernet-segment-identifier? yang:hex-string
| | +--:(auto-assigned)
| | +--rw esi-auto
| | +--rw (auto-mode)?
| | | +--:(from-pool)
| | | | +--rw esi-pool-name? string
| | | +--:(full-auto)
| | | +--rw auto? empty
| | +--ro auto-ethernet-segment-identifier?
| | yang:hex-string
| +--rw esi-redundancy-mode? identityref
| +--rw df-election
| | +--rw df-election-method? identityref
| | +--rw preference? uint16
| | +--rw revertive? boolean
| | +--rw election-wait-time? uint32
| +--rw split-horizon-filtering? boolean
| +--rw pbb
| | +--rw backbone-src-mac? yang:mac-address
| +--rw member* [ne-id, interface-id]
| +--rw ne-id string
| +--rw interface-id string
+--rw vpn-services
...
In reference to the structure shown in Figure 5, the following data nodes can be included:¶
Indicates the ESI type as discussed in Section 5 of [RFC7432]. ESI can be automatically assigned either with or without indicating a pool from which the ESI should be taken. The following types are supported:¶
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 'vpn-id' is only meaningful locally within the network controller. The subtree of the 'vpn-services' is shown in Figure 6.¶
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id vpn-common:vpn-id
+--rw vpn-name? string
+--rw vpn-description? string
+--rw customer-name? string
+--rw parent-service-id? vpn-common:vpn-id
+--rw vpn-type? identityref
+--rw vpn-service-topology? identityref
+--rw bgp-ad-enabled? boolean
+--rw signaling-type? identityref
+--rw global-parameters-profiles
| ...
+--rw underlay-transport
| +--rw (type)?
| +--:(abstract)
| | +--rw transport-instance-id? string
| | +--rw instance-type? identityref
| +--:(protocol)
| +--rw protocol* identityref
+--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-change? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-change? yang:date-and-time
+--rw vpn-nodes
...
The description of the VPN service data nodes that are depicted in Figure 6 are as follows:¶
Includes a textual description of the service.¶
The internal structure of a VPN description is local to each VPN service provider.¶
Indicates the L2VPN type. The following types, defined in [I-D.ietf-opsawg-vpn-common], can be used for the L2NM:¶
The type is used as a condition for the presence of some data nodes in the L2NM.¶
Indicates the signaling that is used for setting pseudowires. Signaling type values are taken from [I-D.ietf-opsawg-vpn-common]. The following signaling options are supported:¶
The L2NM supports two flavors of BGP-signaled L2VPNs:¶
Table 1 summarizes the allowed signaling types for each VPN service type ('vpn-type'). See Section 6.6.2 for more details.¶
Defines reusable parameters for the same L2VPN service.¶
More details are provided in Section 6.5.¶
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 are defined in [I-D.ietf-opsawg-vpn-common].¶
Is used to track the service 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 active but still inactive at the network layer is an indication that network provision actions are needed to align the observed service status with the expected service status.¶
Is an abstraction that represents a set of policies applied to a network node and that belong 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 node is implementation-specific.¶
More details are provided in Section 6.6.¶
| VPN Type | Signaling Options |
|---|---|
| vpls | l2tp-signaling, ldp-signaling, bgp-signaling (l2vpn-bgp) |
| vpws | l2tp-signaling, ldp-signaling, bgp-signaling (l2vpn-bgp) |
| vpws-evpn | bgp-signaling (evpn-bgp) |
| pbb-evpn | bgp-signaling (evpn-bgp) |
| mpls-evpn | bgp-signaling (evpn-bgp) |
| vxlan-evpn | bgp-signaling (evpn-bgp) |
The 'global-parameters-profile' defines reusable parameters for the same L2VPN service instance ('vpn-service'). Global parameters profile are defined at the VPN service level and then called at the VPN node and VPN network access levels. Each VPN instance profile is identified by 'profile-id'. Some of the data nodes can be adjusted at the VPN node or VPN network access levels. These adjusted values take precedence over the global ones. The subtree of 'global-parameters-profile' is depicted in Figure 7.¶
...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw global-parameters-profiles
| +--rw global-parameters-profile* [profile-id]
| +--rw profile-id string
| +--rw (rd-choice)?
| | +--:(directly-assigned)
| | | +--rw rd?
| | | rt-types:route-distinguisher
| | +--:(directly-assigned-suffix)
| | | +--rw rd-suffix? uint16
| | +--:(auto-assigned)
| | | +--rw rd-auto
| | | +--rw (auto-mode)?
| | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto)
| | | | +--rw auto? empty
| | | +--ro auto-assigned-rd?
| | | rt-types:route-distinguisher
| | +--:(auto-assigned-suffix)
| | | +--rw rd-auto-suffix
| | | +--rw (auto-mode)?
| | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto)
| | | | +--rw auto? empty
| | | +--ro auto-assigned-rd-suffix? uint16
| | +--:(no-rd)
| | +--rw no-rd? empty
| +--rw vpn-target* [id]
| | +--rw id uint8
| | +--rw route-targets* [route-target]
| | | +--rw route-target rt-types:route-target
| | +--rw route-target-type
| | rt-types:route-target-type
| +--rw vpn-policies
| | +--rw import-policy? string
| | +--rw export-policy? string
| +--rw local-autonomous-system? inet:as-number
| +--rw svc-mtu? uint32
| +--rw ce-vlan-preservation? boolean
| +--rw ce-vlan-cos-preservation? boolean
| +--rw control-word-negotiation? boolean
| +--rw mac-policies
| | +--rw mac-addr-limit
| | | +--rw mac-num-limit? uint16
| | | +--rw time-interval? uint32
| | | +--rw action? identityref
| | +--rw mac-loop-prevention
| | +--rw window? uint32
| | +--rw frequency? uint32
| | +--rw retry-timer? uint32
| | +--rw protection-type? identityref
| +--rw multicast-like {vpn-common:multicast}?
| +--rw enabled? boolean
| +--rw customer-tree-flavors
| +--rw tree-flavor* identityref
...
The description of the global parameters profile is as follows:¶
As defined in [I-D.ietf-opsawg-vpn-common], these RD assignment modes are supported: direct assignment, automatic assignment from a given pool, automatic assignment, and no assignment. For illustration purposes, the following modes can be used in the deployment cases:¶
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 for managing the Assigned Number subfield: explicit assignment, auto-assignment from a pool, and full auto-assignment.¶
Includes a set of MAC policies that apply to the service:¶
Is a container of MAC address limit configuration. It includes the following data nodes:¶
Container for MAC loop prevention.¶
The 'vpn-node' is an abstraction that represents a set of policies/configurations applied to a network node and that belong to a single 'vpn-service'. A 'vpn-node' contains 'vpn-network-accesses', which are the interfaces involved in the creation of the VPN. The customer sites are connected to the 'vpn-network-accesses'.¶
+--rw l2vpn-ntw
+--rw vpn-profiles
| ...
+--rw ethernet-segments
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
+--rw vpn-node-id vpn-common:vpn-id
+--rw description? string
+--rw ne-id? string
+--rw role? identityref
+--rw router-id? rt-types:router-id
+--rw active-global-parameters-profiles
| +--rw global-parameters-profile* [profile-id]
| +--rw profile-id leafref
| +--rw local-autonomous-system?
| | inet:as-number
| +--rw svc-mtu? uint32
| +--rw ce-vlan-preservation? boolean
| +--rw ce-vlan-cos-preservation? boolean
| +--rw control-word-negotiation? boolean
| +--rw mac-policies
| | +--rw mac-addr-limit
| | | +--rw mac-num-limit? uint16
| | | +--rw time-interval? uint32
| | | +--rw action? identityref
| | +--rw mac-loop-prevention
| | +--rw window? uint32
| | +--rw frequency? uint32
| | +--rw retry-timer? uint32
| | +--rw protection-type? identityref
| +--rw multicast-like {vpn-common:multicast}?
| +--rw enabled? boolean
| +--rw customer-tree-flavors
| +--rw tree-flavor* identityref
+--rw status
| ...
+--rw bgp-auto-discovery
| ...
+--rw signaling-option
| ...
+--rw vpn-network-accesses
...
In reference to the subtree shown in Figure 8, the description of VPN node data nodes is as follows:¶
Lists the set of active global VPN parameters profiles for this VPN node. Concretely, one or more global profiles that are defined at the 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 6.5 except RD and RT related data nodes.¶
Values defined in 'active-global-parameters-profiles' overrides the ones defined in the VPN service level.¶
Represents the point to which sites are connected.¶
Note that, unlike in L2SM, the L2NM does not need to model the customer site, only the points where the traffic from the site are received (i.e., the PE side of 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 6.7 for more details.¶
'bgp-auto-discovery' container (Figure 9) includes the required information for the activation of BGP auto-discovery [RFC4761][RFC6624].¶
+--rw l2vpn-ntw
+--rw vpn-profiles
| ...
+--rw ethernet-segments
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw bgp-auto-discovery
| +--rw (bgp-type)?
| | +--:(l2vpn-bgp)
| | | +--rw vpn-id?
| | | vpn-common:vpn-id
| | +--:(evpn-bgp)
| | +--rw evpn-type? leafref
| | +--rw auto-rt-enable? boolean
| | +--ro auto-route-target?
| | rt-types:route-target
| +--rw (rd-choice)?
| | +--:(directly-assigned)
| | | +--rw rd?
| | | rt-types:route-distinguisher
| | +--:(directly-assigned-suffix)
| | | +--rw rd-suffix? uint16
| | +--:(auto-assigned)
| | | +--rw rd-auto
| | | +--rw (auto-mode)?
| | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto)
| | | | +--rw auto? empty
| | | +--ro auto-assigned-rd?
| | | rt-types:route-distinguisher
| | +--:(auto-assigned-suffix)
| | | +--rw rd-auto-suffix
| | | +--rw (auto-mode)?
| | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto)
| | | | +--rw auto? empty
| | | +--ro auto-assigned-rd-suffix? uint16
| | +--:(no-rd)
| | +--rw no-rd? empty
| +--rw vpn-target* [id]
| | +--rw id uint8
| | +--rw route-targets* [route-target]
| | | +--rw route-target rt-types:route-target
| | +--rw route-target-type
| | rt-types:route-target-type
| +--rw vpn-policies
| +--rw import-policy? string
| +--rw export-policy? string
+--rw signaling-option
| ...
+--rw vpn-network-accesses
...
As discussed in Section 1 of [RFC6624], all of 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-rt-enable'. The assigned RT can be retrieved using 'auto-route-target'.¶
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 6.5.¶
The 'signaling-option' container (Figure 10) defines a set of data nodes for a given signaling protocol that is used for an L2VPN service. As discussed in Section 6.4, several signaling options to exchange membership information between PEs of an L2VPN are supported. The signaling type to be used for an L2VPN service is the controlled at the VPN service level by means of 'signaling-type'.¶
... +--rw vpn-nodes +--rw vpn-node* [vpn-node-id] ... +--rw signaling-option | +--rw advertise-mtu? boolean | +--rw mtu-allow-mismatch? boolean | +--rw signaling-type? leafref | +--rw (signaling-option)? | +--:(bgp) | | ... | +--:(ldp-or-l2tp) | +--rw (ldp-or-l2tp)? | +--:(ldp) | | ... | +--:(l2tp) | ...
The following signaling data nodes are supported:¶
The structure of the BGP-related data nodes is provided in Figure 11.¶
...
| +--rw (signaling-option)?
| ...
| +--:(bgp)
| | +--rw (bgp-type)?
| | +--:(l2vpn-bgp)
| | | +--rw ce-id? uint16
| | | +--rw ce-range? uint16
| | | +--rw pw-encapsulation-type?
| | | | identityref
| | | +--rw vpls-instance
| | | +--rw vpls-edge-id? uint16
| | | +--rw vpls-edge-id-range? uint16
| | +--:(evpn-bgp)
| | +--rw evpn-type? leafref
| | +--rw service-interface-type?
| | | identityref
| | +--rw evpn-policies
| | +--rw mac-learning-mode?
| | | identityref
| | +--rw ingress-replication?
| | | boolean
| | +--rw p2mp-replication?
| | | boolean
| | +--rw arp-proxy {vpn-common:ipv4}?
| | | +--rw enable? boolean
| | | +--rw arp-suppression?
| | | | boolean
| | | +--rw ip-mobility-threshold?
| | | | uint16
| | | +--rw duplicate-ip-detection-interval?
| | | uint16
| | +--rw nd-proxy {vpn-common:ipv6}?
| | | +--rw enable? | boolean
| | | +--rw nd-suppression?
| | | | boolean
| | | +--rw ip-mobility-threshold?
| | | | uint16
| | | +--rw duplicate-ip-detection-interval?
| | | uint16
| | +--rw underlay-multicast?
| | | boolean
| | +--rw flood-unknown-unicast-supression?
| | | boolean
| | +--rw vpws-vlan-aware? boolean
| | +--rw bum-management
| | | +--rw discard-broadcast?
| | | | boolean
| | | +--rw discard-unknown-multicast?
| | | | boolean
| | | +--rw discard-unknown-unicast?
| | | boolean
| | +--rw pbb
| | +--rw backbone-src-mac?
| | yang:mac-address
| +--:(ldp-or-l2tp)
| ...
As discussed in Section 2.2.2 of [RFC6624], a CE ID ('ce-id') identifying the CE within the VPN must be provided. 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-encapsulation-type' is used to control the PW encapsulation type (Section 3 of [RFC6624]). The value of the 'pw-encapsulation-type' are taken from the IANA-maintained "iana-bgp-l2-encaps" module.¶
For the specific case of VPLS, the VPLS Edge ID (VE ID, 'vpls-edge-id') and a VE ID range ('vpls-edge-id-range') are provided as per Section 3.2 of [RFC4761].¶
For EVPN-related L2VPNs, 'service-interface-type' indicates whether this is VLAN-based, VLAN bundle, or VLAN-aware bundle service interface (Section 6 of [RFC7432]). Moreover, a set of policies can be provided such as MAC address learning mode (Section 9 of [RFC7432]), ingress replication (Section 12.1 of [RFC7432]), Address Resolution Protocol (ARP) and Nighbour Discovery (ND) proxy (Section 10 of [RFC7432]), processing of Broadcast, unknown unicast, or multicast (BUM) (Section 12 of [RFC7432]), etc.¶
The model supports the configuration of the parameters that are discussed in Section 6 of [RFC4762]. Such parameters include a 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 PW type, and a PW 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].¶
... | +--rw (signaling-option)? | ... | +--:(bgp) | | ... | +--:(ldp-or-l2tp) | +--rw ldp-or-l2tp | +--rw agi? | | rt-types:route-distinguisher | +--rw saii? uint32 | +--rw remote-targets* [taii] | | +--rw taii uint32 | | +--rw peer-addr inet:ip-address | +--rw (ldp-or-l2tp)? | +--:(ldp) | | +--rw t-ldp-pw-type? | | | identityref | | +--rw pw-type? identityref | | +--rw pw-description? string | | +--rw mac-addr-withdraw? boolean | | +--rw pw-peer-list* | | | [peer-addr vc-id] | | | +--rw peer-addr | | | | inet:ip-address | | | +--rw vc-id string | | | +--rw pw-priority? uint32 | | +--rw qinq | | +--rw s-tag uint32 | | +--rw c-tag uint32 | +--:(l2tp) | +--rw router-id? | | rt-types:router-id | +--rw pseudowire-type? | identityref ...
The model 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 PW type, an AGI, an SAII, and a list of peers that are associated with a TAII (Figure 13). The PW type ('pseudowire-type') value is taken from the IANA-maintained "iana-pseudowire-types" module.¶
... | +--rw (signaling-option)? | ... | +--:(bgp) | | ... | +--:(ldp-or-l2tp) | +--rw ldp-or-l2tp | +--rw agi? | | rt-types:route-distinguisher | +--rw saii? uint32 | +--rw remote-target* [peer-addr taii] | | +--rw peer-addr inet:ip-address | | +--rw taii uint32 | +--rw (ldp-or-l2tp)? | +--:(ldp) | | ... | +--:(l2tp) | +--rw router-id? | | rt-types:router-id | +--rw pseudowire-type? | identityref ...
A 'vpn-network-access' (Figure 14) represents an entry point to a VPN service . In other words, this container encloses the parameters that describe the access information for the traffic that belongs to a particular L2VPN. As such, every 'vpn-network-access' MUST belong to one and only one 'vpn-node'.¶
A 'vpn-network-access' includes information such as the connection on which the access is defined , the specific layer 2 service requirements, etc.¶
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
+--rw id vpn-common:vpn-id
+--rw description? string
+--rw interface-id? string
+--rw global-parameters-profile? leafref
+--rw status
| ...
+--rw connection
| ...
+--rw vpws-service-instance
| ...
+--rw group* [group-id]
| +--rw group-id string
| +--rw precedence?
| | identityref
| +--rw ethernet-segment-identifier? leafref
+--rw ethernet-service-oam
| ...
+--rw service
...
The VPN network access is comprised of:¶
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, LAG interfaces, split-horizon). The L2NM supports tag manipulation operations (e.g., tag rewrite).¶
Note that the 'connection' container does not include the physical-specific configuration as this is assumed to be directly handled using device modules (e.g., interfaces module). Moreover, this design is also meant to avoid manipulated global parameters at the service level and lower the risk of impacting other services sharing the same physical interface.¶
Some consistency checks should be ensured by implementations (typically, network controllers) for LAG interface as the same information (e.g., LACP system-id) should be provided to the involved nodes.¶
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw connection
| +--rw l2-termination-point?
| | string
| +--rw local-bridge-reference?
| | string
| +--rw bearer-reference? string
| | {vpn-common:bearer-reference}?
| +--rw encapsulation
| | +--rw encap-type? identityref
| | +--rw dot1q
| | | +--rw tag-type? identityref
| | | +--rw cvlan-id? uint16
| | | +--rw rewrite
| | | +--rw (tag-choice)?
| | | | +--:(pop)
| | | | | +--rw pop?
| | | | | enumeration
| | | | +--:(push)
| | | | | +--rw push? empty
| | | | +--:(translate)
| | | | +--rw translate?
| | | | enumeration
| | | +--rw cvlan-id? uint16
| | | +--rw mode? enumeration
| | +--rw priority-tagged
| | | +--rw tag-type? identityref
| | +--rw qinq
| | +--rw tag-type? identityref
| | +--rw svlan-id uint16
| | +--rw cvlan-id uint16
| +--rw lag-interface
| | {vpn-common:lag-interface}?
| +--rw lag-interface-id? string
| +--rw lacp
| | +--rw lacp-state? boolean
| | +--rw mode? identityref
| | +--rw speed? uint32
| | +--rw mini-link-num? uint32
| | +--rw system-id?
| | | yang:mac-address
| | +--rw admin-key? uint16
| | +--rw system-priority? uint16
| | +--rw member-link-list
| | | +--rw member-link* [name]
| | | +--rw name string
| | | +--rw port-speed? uint32
| | | +--rw mode? identityref
| | | +--rw link-mtu? uint32
| | | +--rw oam-802.3ah-link
| | | | {oam-3ah}?
| | | +--rw enable? boolean
| | +--rw flow-control? string
| | +--rw lldp? boolean
| +--rw split-horizon
| +--rw group-name? string
...
The 'vpws-service-instance' provides the local and remote VPWS Service Instance (VSI) [RFC8214]. This container is only present when the 'vpn-type' is VPWS-EVPN. As shown in Figure 16, the VSIs can be configured by a VPN service provider or auto-generated.¶
An example to illustrate the use of the L2NM to configure VPWS-EVPN instances is provided in Appendix A.4.¶
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw vpws-service-instance
| +--rw (local-vsi-choice)?
| | +--:(directly-assigned)
| | | +--rw local-vpws-service-instance?
| | | uint32
| | +--:(auto-assigned)
| | +--rw local-vsi-auto
| | +--rw (auto-mode)?
| | | +--:(from-pool)
| | | | +--rw vsi-pool-name?
| | | | string
| | | +--:(full-auto)
| | | +--rw auto? empty
| | +--ro auto-local-vsi?
| | uint32
| +--rw (remote-vsi-choice)?
| +--:(directly-assigned)
| | +--rw remote-vpws-service-instance?
| | uint32
| +--:(auto-assigned)
| +--rw remote-vsi-auto
| +--rw (auto-mode)?
| | +--:(from-pool)
| | | +--rw vsi-pool-name?
| | | string
| | +--:(full-auto)
| | +--rw auto? empty
| +--ro auto-remote-vsi?
| uint32
...
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.¶
+--rw l2vpn-ntw
+--rw vpn-profiles
| ...
+--rw ethernet-segments
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw ethernet-service-oam
| +--rw md-name? string
| +--rw md-level? uint8
| +--rw cfm-802.1-ag
| | +--rw n2-uni-c* [maid]
| | | +--rw maid string
| | | +--rw mep-id? uint32
| | | +--rw mep-level? uint32
| | | +--rw mep-up-down?
| | | | enumeration
| | | +--rw remote-mep-id? uint32
| | | +--rw cos-for-cfm-pdus? uint32
| | | +--rw ccm-interval? uint32
| | | +--rw ccm-holdtime? uint32
| | | +--rw ccm-p-bits-pri?
| | | ccm-priority-type
| | +--rw n2-uni-n* [maid]
| | +--rw maid string
| | +--rw mep-id? uint32
| | +--rw mep-level? uint32
| | +--rw mep-up-down?
| | | enumeration
| | +--rw remote-mep-id? uint32
| | +--rw cos-for-cfm-pdus? uint32
| | +--rw ccm-interval? uint32
| | +--rw ccm-holdtime? uint32
| | +--rw ccm-p-bits-pri?
| | ccm-priority-type
| +--rw y-1731* [maid]
| +--rw maid string
| +--rw mep-id? uint32
| +--rw pm-type? identityref
| +--rw remote-mep-id? uint32
| +--rw message-period? uint32
| +--rw measurement-interval? uint32
| +--rw cos? uint32
| +--rw loss-measurement? boolean
| +--rw synthethic-loss-measurement?
| | boolean
| +--rw delay-measurement
| | +--rw enable-dm? boolean
| | +--rw two-way? boolean
| +--rw frame-size? uint32
| +--rw session-type? enumeration
...
The 'service' container (Figure 18) provides a set of service-specific configuration such as Quality of Service (QoS).¶
+--rw l2vpn-ntw
+--rw vpn-profiles
| ...
+--rw ethernet-segments
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw service
+--rw mtu? uint32
+--rw svc-inbound-bandwidth
| {vpn-common:inbound-bw}?
| ...
+--rw svc-outbound-bandwidth
| {vpn-common:outbound-bw}?
| ...
+--rw qos {vpn-common:qos}?
| ...
+--rw mac-policies
| ...
+--rw broadcast-unknown-unicast-multicast
...
The description of the service data nodes is as follows:¶
Specify the service bandwidth for the L2VPN service. It 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 [I-D.ietf-opsawg-vpn-common], can be used to indicate the bandwidth type:¶
'svc-inbound-bandwidth' indicates the inbound bandwidth of the connection (i.e., download bandwidth from the service provider to the site).¶
'svc-outbound-bandwidth' indicates the outbound bandwidth of the connection (i.e., upload bandwidth from the site to the service provider).¶
+--rw service
...
+--rw svc-inbound-bandwidth
| {vpn-common:inbound-bw}?
| +--rw inbound-bandwidth* [bw-type]
| +--rw bw-type identityref
| +--rw cos-id? uint8
| | {vpn-common:qos}?
| +--rw cir? uint64
| +--rw cbs? uint64
| +--rw eir? uint64
| +--rw ebs? uint64
| +--rw pir? uint64
| +--rw pbs? uint64
+--rw svc-outbound-bandwidth
| {vpn-common:outbound-bw}?
| +--rw outbound-bandwidth* [bw-type]
| +--rw bw-type identityref
| +--rw cos-id? uint8
| | {vpn-common:qos}?
| +--rw cir? uint64
| +--rw cbs? uint64
| +--rw eir? uint64
| +--rw ebs? uint64
| +--rw pir? uint64
| +--rw pbs? uint64
...
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].¶
+--rw service
...
+--rw qos {vpn-common:qos}?
| +--rw qos-classification-policy
| | +--rw rule* [id]
| | +--rw id string
| | +--rw (match-type)?
| | | +--:(match-flow)
| | | | +--rw match-flow
| | | | +--rw dscp? inet:dscp
| | | | +--rw dot1q? uint16
| | | | +--rw pcp? uint8
| | | | +--rw src-mac-address?
| | | | | yang:mac-address
| | | | +--rw dst-mac-address?
| | | | | yang:mac-address
| | | | +--rw color-type?
| | | | | identityref
| | | | +--rw any? empty
| | | +--:(match-application)
| | | +--rw match-application?
| | | identityref
| | +--rw target-class-id? string
| +--rw qos-profile
| +--rw qos-profile* [profile]
| +--rw profile leafref
| +--rw direction? identityref
...
Lists a set of MAC-related policies such as MAC ACLs. An ACL can be based on source MAC address, source MAC address mask, destination MAC address , and destination MAC address mask. A data frame that matches an ACL can be dropped, 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 precendence over the one inlcudes at the 'global-parameters-profile' at the VPN service or VPN node levels.¶
+--rw service
...
+--rw mac-policies
| +--rw access-control-list* [name]
| | +--rw name string
| | +--rw src-mac-address*
| | | yang:mac-address
| | +--rw src-mac-address-mask*
| | | yang:mac-address
| | +--rw dst-mac-address*
| | | yang:mac-address
| | +--rw dst-mac-address-mask*
| | | yang:mac-address
| | +--rw action? identityref
| | +--rw rate-limit? decimal64
| +--rw mac-loop-prevention
| | +--rw window? uint32
| | +--rw frequency? uint32
| | +--rw retry-timer? uint32
| | +--rw protection-type? identityref
| +--rw mac-addr-limit
| +--rw mac-num-limit? uint16
| +--rw time-interval? uint32
| +--rw action? identityref
...
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.¶
+--rw service
...
+--rw broadcast-unknown-unicast-multicast
+--rw multicast-site-type?
| enumeration
+--rw multicast-gp-address-mapping* [id]
| +--rw id uint16
| +--rw vlan-id? uint32
| +--rw mac-gp-address?
| | yang:mac-address
| +--rw port-lag-number? uint32
+--rw bum-overall-rate? uint32
The "iana-bgp-l2-encaps" YANG module (Section 7.1) is designed to echo the registry available at [IANA-BGP-L2]. Appendix B lists the initial values included in the "iana-bgp-l2-encaps" YANG module.¶
<CODE BEGINS>file "iana-bgp-l2-encaps@2021-07-05.yang"
module iana-bgp-l2-encaps {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps";
prefix iana-bgp-l2-encaps;
organization
"IANA";
contact
"Internet Assigned Numbers Authority
Postal: ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States of America
Tel: +1 310 301 5800
<mailto:iana@iana.org>";
description
"This module contains a collection of YANG data types defined
by IANA and used for referring to BGP layer 2 encapsulation
types.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified 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).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2021-07-05 {
description
"First revision.";
reference
"RFC XXXX: A Layer 2 VPN Network YANG Model.";
}
identity bgp-l2-encaps-type {
description
"Base BGP Layer 2 encapsulation type.";
reference
"RFC 6624: Layer 2 Virtual Private Networks Using BGP for
Auto-Discovery and Signaling";
}
identity frame-relay {
base bgp-l2-encaps-type;
description
"Frame Relay.";
reference
"RFC 4446: IANA Allocations for Pseudowire Edge
to Edge Emulation (PWE3)";
}
identity atm-aal5 {
base bgp-l2-encaps-type;
description
"ATM AAL5 SDU VCC transport.";
reference
"RFC 4446: IANA Allocations for Pseudowire Edge
to Edge Emulation (PWE3)";
}
identity atm-cell {
base bgp-l2-encaps-type;
description
"ATM transparent cell transport";
reference
"RFC 4816: Pseudowire Emulation Edge-to-Edge (PWE3)
Asynchronous Transfer Mode (ATM) Transparent
Cell Transport Service";
}
identity ethernet-tagged-mode {
base bgp-l2-encaps-type;
description
"Ethernet (VLAN) Tagged Mode.";
reference
"RFC 4448: Encapsulation Methods for Transport of Ethernet
over MPLS Networks";
}
identity ethernet-raw-mode {
base bgp-l2-encaps-type;
description
"Ethernet Raw Mode.";
reference
"RFC 4448: Encapsulation Methods for Transport of Ethernet
over MPLS Networks";
}
identity hdlc {
base bgp-l2-encaps-type;
description
"Cisco HDLC.";
reference
"RFC 4618: Encapsulation Methods for Transport of
PPP/High-Level Data Link Control (HDLC)
over MPLS Networks";
}
identity ppp {
base bgp-l2-encaps-type;
description
"PPP.";
reference
"RFC 4618: Encapsulation Methods for Transport of
PPP/High-Level Data Link Control (HDLC)
over MPLS Networks";
}
identity circuit-emulation {
base bgp-l2-encaps-type;
description
"SONET/SDH Circuit Emulation Service.";
reference
"RFC 4842: Synchronous Optical Network/Synchronous Digital
Hierarchy (SONET/SDH) Circuit Emulation over Packet
(CEP)";
}
identity atm-to-vcc {
base bgp-l2-encaps-type;
description
"ATM n-to-one VCC cell transport.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS Networks";
}
identity atm-to-vpc {
base bgp-l2-encaps-type;
description
"ATM n-to-one VPC cell transport.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS Networks";
}
identity layer-2-transport {
base bgp-l2-encaps-type;
description
"IP Layer 2 Transport.";
reference
"RFC 3032: MPLS Label Stack Encoding";
}
identity fr-port-mode {
base bgp-l2-encaps-type;
description
"Frame Relay Port mode.";
reference
"RFC 4619: Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks";
}
identity e1 {
base bgp-l2-encaps-type;
description
"Structure-agnostic E1 over packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity t1 {
base bgp-l2-encaps-type;
description
"Structure-agnostic T1 (DS1) over packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity vpls {
base bgp-l2-encaps-type;
description
"VPLS.";
reference
"RFC 4761: Virtual Private LAN Service (VPLS)
Using BGP for Auto-Discovery and Signaling";
}
identity t3 {
base bgp-l2-encaps-type;
description
"Structure-agnostic T3 (DS3) over packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity structure-aware {
base bgp-l2-encaps-type;
description
"Nx64kbit/s Basic Service using Structure-aware.";
reference
"RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched
Network (CESoPSN)";
}
identity dlci {
base bgp-l2-encaps-type;
description
"Frame Relay DLCI.";
reference
"RFC 4619: Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks";
}
identity e3 {
base bgp-l2-encaps-type;
description
"Structure-agnostic E3 over packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity ds1 {
base bgp-l2-encaps-type;
description
"Octet-aligned payload for Structure-agnostic DS1 circuits.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity cas {
base bgp-l2-encaps-type;
description
"DS1 (ESF) Nx64kbit/s with CAS using Structure-aware.";
reference
"RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched
Network (CESoPSN)";
}
identity esf {
base bgp-l2-encaps-type;
description
"DS1 (ESF) Nx64kbit/s with CAS using Structure-aware.";
reference
"RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched
Network (CESoPSN)";
}
identity sf {
base bgp-l2-encaps-type;
description
"DS1 (SF) Nx64kbit/s with CAS using Structure-aware.";
reference
"RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched
Network (CESoPSN)";
}
}
<CODE ENDS>¶
The initial version of the "iana-pseudowire-types" YANG module (Section 7.2) is designed to echo the registry available at [IANA-PW-Types]. . Appendix C lists the initial values included in the "iana-bgp-l2-encaps" YANG module.¶
<CODE BEGINS>file "iana-pseudowire-types@2021-07-05.yang"
module iana-pseudowire-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-pseudowire-types";
prefix iana-pw-types;
organization
"IANA";
contact
"Internet Assigned Numbers Authority
Postal: ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States of America
Tel: +1 310 301 5800
<mailto:iana@iana.org>";
description
"This module contains a collection of YANG data types defined
by IANA and used for referring to Pseudowire Types.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified 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).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2021-07-05 {
description
"First revision.";
reference
"RFC XXXX: A Layer 2 VPN Network YANG Model.";
}
identity iana-pw-types {
description
"Base BGP Layer 2 encapsulation type.";
}
identity frame-relay {
base iana-pw-types;
description
"Frame Relay.";
reference
"RFC 4619: Encapsulation Methods for Transport of Frame Relay
over Multiprotocol Label Switching (MPLS) Networks";
}
identity atm-aal5 {
base iana-pw-types;
description
"ATM AAL5 SDU VCC transport.";
}
identity atm-cell {
base iana-pw-types;
description
"ATM transparent cell transport";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS
Networks";
}
identity ethernet-tagged-mode {
base iana-pw-types;
description
"Ethernet (VLAN) Tagged Mode.";
reference
"RFC 4448: Encapsulation Methods for Transport of Ethernet
over MPLS Networks";
}
identity ethernet {
base iana-pw-types;
description
"Ethernet.";
reference
"RFC 4448: Encapsulation Methods for Transport of Ethernet
over MPLS Networks";
}
identity hdlc {
base iana-pw-types;
description
"Cisco HDLC.";
reference
"RFC 4618: Encapsulation Methods for Transport of
PPP/High-Level Data Link Control (HDLC)
over MPLS Networks";
}
identity ppp {
base iana-pw-types;
description
"PPP.";
reference
"RFC 4618: Encapsulation Methods for Transport of
PPP/High-Level Data Link Control (HDLC)
over MPLS Networks";
}
identity circuit-emulation-mpls {
base iana-pw-types;
description
"SONET/SDH Circuit Emulation Service Over MPLS Encapsulation.";
reference
"RFC 5143: Synchronous Optical Network/Synchronous Digital
Hierarchy (SONET/SDH) Circuit Emulation Service over
MPLS (CEM) Encapsulation";
}
identity atm-to-vcc {
base iana-pw-types;
description
"ATM n-to-one VCC cell transport.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS Networks";
}
identity atm-to-vpc {
base iana-pw-types;
description
"ATM n-to-one VPC cell transport.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS Networks";
}
identity layer-2-transport {
base iana-pw-types;
description
"IP Layer2 Transport.";
reference
"RFC 3032: MPLS Label Stack Encoding";
}
identity atm-one-to-one-vcc {
base iana-pw-types;
description
"ATM one-to-one VCC Cell Mode.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS Networks";
}
identity atm-one-to-one-vpc {
base iana-pw-types;
description
"ATM one-to-one VPC Cell Mode.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS Networks";
}
identity atm-aal5-vcc {
base iana-pw-types;
description
"ATM AAL5 PDU VCC transport.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS Networks";
}
identity fr-port-mode {
base iana-pw-types;
description
"Frame-Relay Port mode.";
reference
"RFC 4619: Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks";
}
identity circuit-emulation-packet {
base iana-pw-types;
description
"SONET/SDH Circuit Emulation over Packet.";
reference
"RFC 4842: Synchronous Optical Network/Synchronous Digital
Hierarchy (SONET/SDH) Circuit Emulation over Packet
(CEP)";
}
identity e1 {
base iana-pw-types;
description
"Structure-agnostic E1 over Packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity t1 {
base iana-pw-types;
description
"Structure-agnostic T1 (DS1) over Packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity e3 {
base iana-pw-types;
description
"Structure-agnostic E3 over Packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity t3 {
base iana-pw-types;
description
"Structure-agnostic T3 (DS3) over Packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity ces-over-psn {
base iana-pw-types;
description
"CESoPSN basic mode.";
reference
"RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched Network
(CESoPSN)";
}
identity tdm-over-ip-aal1 {
base iana-pw-types;
description
"TDMoIP AAL1 Mode.";
reference
"RFC 5087: Time Division Multiplexing over IP (TDMoIP)";
}
identity ces-over-psn-cas {
base iana-pw-types;
description
"CESoPSN TDM with CAS.";
reference
"RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched Network
(CESoPSN)";
}
identity tdm-over-ip-aal2 {
base iana-pw-types;
description
"TDMoIP AAL2 Mode.";
reference
"RFC 5087: Time Division Multiplexing over IP (TDMoIP)";
}
identity dlci {
base iana-pw-types;
description
"Frame Relay DLCI.";
reference
"RFC 4619: Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks";
}
identity rohc {
base iana-pw-types;
description
"ROHC Transport Header-compressed Packets.";
reference
"RFC 5795: The RObust Header Compression (ROHC) Framework
RFC 4901: Protocol Extensions for Header Compression over MPLS";
}
identity ecrtp {
base iana-pw-types;
description
"ECRTP Transport Header-compressed Packets.";
reference
"RFC 3545: Enhanced Compressed RTP (CRTP) for Links with High
Delay, Packet Loss and Reordering
RFC 4901: Protocol Extensions for Header Compression over MPLS";
}
identity iphc {
base iana-pw-types;
description
"IPHC Transport Header-compressed Packets.";
reference
"RFC 2507: IP Header Compression
RFC 4901: Protocol Extensions for Header Compression over MPLS";
}
identity crtp {
base iana-pw-types;
description
"cRTP Transport Header-compressed Packets.";
reference
"RFC 2508: Compressing IP/UDP/RTP Headers for Low-Speed Serial
Links
RFC 4901: Protocol Extensions for Header Compression over MPLS";
}
identity atm-vp-virtual-trunk {
base iana-pw-types;
description
"ATM VP Virtual Trunk.";
}
identity fc-port-mode {
base iana-pw-types;
description
"FC Port Mode.";
reference
"RFC 6307: Encapsulation Methods for Transport of
Fibre Channel Traffic over MPLS Networks";
}
identity wildcard {
base iana-pw-types;
description
"Wildcard.";
reference
"RFC 4863: Wildcard Pseudowire Type";
}
}
<CODE ENDS>¶
The "ietf-l2vpn-ntw" YANG module uses types defined in [RFC6991], [I-D.ietf-opsawg-vpn-common], and [RFC8294].¶
<CODE BEGINS>file "ietf-l2vpn-ntw@2021-10-01.yang"
module ietf-l2vpn-ntw {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw";
prefix l2vpn-ntw;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types, Section 4";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types, Section 3";
}
import ietf-vpn-common {
prefix vpn-common;
reference
"RFC CCCC: A Layer 2/3 VPN Common YANG Model";
}
import iana-bgp-l2-encaps {
prefix iana-bgp-l2-encaps;
}
import iana-pseudowire-types {
prefix iana-pw-types;
}
import ietf-routing-types {
prefix rt-types;
reference
"RFC 8294: Common YANG Data Types for the Routing Area";
}
organization
"IETF OPSA (Operations and Management Area) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Editor: Samier Barguil
<mailto:samier.barguilgiraldo.ext@telefonica.com>
Author: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com>";
description
"This YANG module defines a network model for layer 2 VPN
services.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified 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).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2021-10-01 {
description
"Initial version.";
reference
"RFC XXXX: A Layer 2 VPN Network YANG Model.";
}
/* Features */
feature oam-3ah {
description
"Indicates the support of OAM 802.3ah.";
reference
"IEEE Std 802.3ah: Media Access Control Parameters, Physical
Layers, and Management Parameters for
Subscriber Access Networks";
}
/* Identities */
identity esi-type {
description
"T-(Ethernet Segment Identifier (ESI) Type) is a 1-octet field
(most significant octet) that specifies the format of the
remaining 9 octets (ESI Value).";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5";
}
identity esi-type-0 {
base esi-type;
description
"This type indicates an arbitrary 9-octet ESI value,
which is managed and configured by the operator.";
}
identity esi-type-1 {
base esi-type;
description
"When IEEE 802.1AX Link Aggregation Control Protocol (LACP)
is used between the Provider Edge (PE) and Customer Edge (CE)
devices, this ESI type indicates an auto-generated ESI value
determined from LACP.";
reference
"IEEE Std. 802.1AX: Link Aggregation";
}
identity esi-type-2 {
base esi-type;
description
"The ESI value is auto-generated and determined based
on the Layer 2 bridge protocol.";
}
identity esi-type-3 {
base esi-type;
description
"This type indicates a MAC-based ESI value that can be
auto-generated or configured by the operator.";
}
identity esi-type-4 {
base esi-type;
description
"This type indicates a Router-ID ESI value that can be
auto-generated or configured by the operator.";
}
identity esi-type-5 {
base esi-type;
description
"This type indicates an Autonomous System (AS)-based ESI value
that can be auto-generated or configured by the operator.";
}
identity df-election-methods {
description
"Base Identity Designated Forwarder (DF) election method.";
}
identity default-7432 {
base df-election-methods;
description
"The default DF election method.
The default procedure for DF election at the granularity of <ES,
VLAN> for VLAN-based service or <ES, VLAN bundle> for VLAN-
(aware) bundle service is referred to as 'service carving'.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.5";
}
identity highest-random-weight {
base df-election-methods;
description
"The highest random weight (HRW) method.";
reference
"RFC 8584: Framework for Ethernet VPN Designated
Forwarder Election Extensibility, Section 3";
}
identity preference {
base df-election-methods;
description
"The preference based method. PEs are assigned with
preferences to become the DF in the Ethernet Segment (ES).
The exact preference-based algorithm (e.g., lowest-preference
algorithm, highest-preference algorithm) to use is
signaled at the control plane.";
}
identity evpn-redundancy-mode {
description
"Base identity for Ethernet VPN (EVPN) redundancy modes.";
}
identity single-active {
base evpn-redundancy-mode;
description
"Indicates Single-Active redundancy mode for a given ES.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.1";
}
identity all-active {
base evpn-redundancy-mode;
description
"Indicates All-Active redundancy mode for a given ES.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.2";
}
identity evpn-service-type {
description
"Base identity for EVPN service type.";
}
identity vlan-based-service-interface {
base evpn-service-type;
description
"VLAN-Based Service Interface.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.1";
}
identity vlan-bundle-service-interface {
base evpn-service-type;
description
"VLAN Bundle Service Interface.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.2";
}
identity vlan-aware-bundle-service-interface {
base evpn-service-type;
description
"VLAN-Aware Bundle Service Interface.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.3";
}
identity mapping-type {
base vpn-common:multicast-gp-address-mapping;
description
"Identity for multicast group mapping type.";
}
identity loop-prevention-type {
description
"Identity of loop prevention.";
}
identity shut {
base loop-prevention-type;
description
"Shut protection type.";
}
identity trap {
base loop-prevention-type;
description
"Trap protection type.";
}
identity color-type {
description
"Identity of color types.";
}
identity green {
base color-type;
description
"'green' color type.";
}
identity yellow {
base color-type;
description
"'yellow' color type.";
}
identity red {
base color-type;
description
"'red' color type.";
}
identity t-ldp-pw-type {
description
"Identity for t-ldp-pw-type.";
}
identity vpws-type {
base t-ldp-pw-type;
description
"Virtual Private Wire Service (VPWS) t-ldp-pw-type.";
reference
"RFC 4664: Framework for Layer 2 Virtual Private Networks
(L2VPNs), Section 3.3";
}
identity vpls-type {
base t-ldp-pw-type;
description
"Virtual Private LAN Service (VPLS) t-ldp-pw-type.";
reference
"RFC 4762: Virtual Private LAN Service (VPLS) Using
Label Distribution Protocol (LDP)
Signaling, Section 6.1";
}
identity hvpls {
base t-ldp-pw-type;
description
"Identity for Hierarchical Virtual Private LAN Service (H-VPLS)
t-ldp-pw-type.";
reference
"RFC 4762: Virtual Private LAN Service (VPLS) Using
Label Distribution Protocol (LDP)
Signaling, Section 10";
}
identity lacp-mode {
description
"Identity of the LACP mode.";
}
identity lacp-active {
base lacp-mode;
description
"LACP active mode.
This mode refers to the mode where auto-speed negotiation
is initiated followed by an establishement of an
Ethernet channel with the other end.";
}
identity lacp-passive {
base lacp-mode;
description
"LACP passive mode.
This mode refers to the LACP mode where an endopoint does
not initiate the negotiation, but only responds to LACP
packets initiated by the other end (e.g., full duplex
or half duplex)";
}
identity pm-type {
description
"Identity for performance monitoring type.";
}
identity loss {
base pm-type;
description
"Loss measurement is the performance monitoring type.";
}
identity delay {
base pm-type;
description
"Delay measurement is the performance monitoring type.";
}
identity mac-learning-mode {
description
"Media Access Control (MAC) learning mode.";
}
identity data-plane {
base mac-learning-mode;
description
"User MAC addresses are learned through ARP broadcast.";
}
identity control-plane {
base mac-learning-mode;
description
"User MAC addresses are advertised through EVPN-BGP.";
}
identity mac-action {
description
"Base identity for a MAC action.";
}
identity drop {
base mac-action;
description
"Dropping a packet as the MAC action.";
}
identity flood {
base mac-action;
description
"Packet flooding as the MAC action.";
}
identity warning {
base mac-action;
description
"Sending a warning log message as the MAC action.";
}
identity precedence-type {
description
"Redundancy type. The service can be created
with primary and secondary signalization.";
}
identity primary {
base precedence-type;
description
"Identifies the main VPN network access.";
}
identity secondary {
base precedence-type;
description
"Identifies the secondary VPN network access.";
}
identity pw-type {
description
"Identity for allowed LDP-based pseudowire (PW) type.";
reference
"RFC 4762: Virtual Private LAN Service (VPLS) Using
Label Distribution Protocol (LDP)
Signaling, Section 6.1.1";
}
identity ethernet {
base pw-type;
description
"PW Ethernet type.";
}
identity ethernet-tagged {
base pw-type;
description
"PW Ethernet tagged mode type.";
}
/* Typedefs */
typedef ccm-priority-type {
type uint8 {
range "0..7";
}
description
"A 3-bit priority value to be used in the VLAN tag,
if present in the transmitted frame.";
}
/* Groupings */
grouping cfm-802-grouping {
description
"Grouping for 802.1ag Connectivity Fault Management (CFM)
attributes.";
reference
"IEEE Std 802-1ag: Virtual Bridged Local Area Networks
Amendment 5: Connectivity Fault Management";
leaf maid {
type string;
description
"Maintenance Association Identifier (MAID).";
}
leaf mep-id {
type uint32;
description
"Local Maintenance End Point (MEP) ID.";
}
leaf mep-level {
type uint32;
description
"MEP level.";
}
leaf mep-up-down {
type enumeration {
enum up {
description
"MEP is up.";
}
enum down {
description
"MEP is down.";
}
}
description
"MEP up/down.";
}
leaf remote-mep-id {
type uint32;
description
"Remote MEP ID.";
}
leaf cos-for-cfm-pdus {
type uint32;
description
"Class of service for CFM PDUs.";
}
leaf ccm-interval {
type uint32;
description
"Continuity Check Message (CCM) interval.";
}
leaf ccm-holdtime {
type uint32;
description
"CCM hold time.";
}
leaf ccm-p-bits-pri {
type ccm-priority-type;
description
"The priority parameter for Continuity Check Messages (CCMs)
transmitted by the MEP.";
}
}
grouping y-1731 {
description
"Grouping for y.1731";
reference
"ITU-T Y-1731: Operations, administration and maintenance
(OAM) functions and mechanisms for
Ethernet-based networks";
list y-1731 {
key "maid";
description
"List for y-1731.";
leaf maid {
type string;
description
"MAID.";
}
leaf mep-id {
type uint32;
description
"Local MEP ID.";
}
leaf pm-type {
type identityref {
base pm-type;
}
description
"Performance monitor types.";
}
leaf remote-mep-id {
type uint32;
description
"Remote MEP ID.";
}
leaf message-period {
type uint32;
units "milliseconds";
description
"Defines the interval between OAM messages.";
}
leaf measurement-interval {
type uint32;
units "seconds";
description
"Specifies the measurement interval for statistics.";
}
leaf cos {
type uint32;
description
"Identifies the Class of Service.";
}
leaf loss-measurement {
type boolean;
description
"Controls whether loss measurement is enabled/disabled.";
}
leaf synthethic-loss-measurement {
type boolean;
description
"Indicates whether synthetic loss measurement is enabled.";
}
container delay-measurement {
description
"Container for delay measurement";
leaf enable-dm {
type boolean;
description
"Controls whether delay measurement is enabled/disabled.";
}
leaf two-way {
type boolean;
description
"Whether delay measurement is two-way ('true') of one-
way ('false').";
}
}
leaf frame-size {
type uint32;
description
"Indicates the frame size.";
}
leaf session-type {
type enumeration {
enum proactive {
description
"Proactive mode.";
}
enum on-demand {
description
"On-demand mode.";
}
}
description
"Specifies the session type.";
}
}
}
grouping global-parameters-profile {
description
"Container for per-service parameters.";
leaf local-autonomous-system {
type inet:as-number;
description
"Indicates a local AS Number (ASN).";
}
leaf svc-mtu {
type uint32;
description
"Service MTU, it is also known as the maximum transmission unit
or maximum frame size. When a frame is larger than the MTU,
it is fragmented to accommodate the MTU of the network.";
}
leaf ce-vlan-preservation {
type boolean;
description
"Preserve the CE-VLAN ID from ingress to egress,i.e.,
CE-VLAN tag 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.";
}
leaf ce-vlan-cos-preservation {
type boolean;
description
"CE vlan CoS preservation. 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.";
}
leaf control-word-negotiation {
type boolean;
description
"Controls whether Control-word negotiation is enabled
(if set to true) or not (if set to false).";
reference
"Section 7 of RFC 8077";
}
container mac-policies {
description
"Container of MAC policies.";
container mac-addr-limit {
description
"Container of MAC-Addr limit configuration.";
leaf mac-num-limit {
type uint16;
description
"Maximum number of MAC addresses learned from
the customer for a single service instance.";
}
leaf time-interval {
type uint32;
units "milliseconds";
description
"The aging time of the mac address.";
}
leaf action {
type identityref {
base mac-action;
}
description
"Specifies the action when the upper limit is
exceeded: drop the packet, flood the
packet, or simply send a warning log message.";
}
}
container mac-loop-prevention {
description
"Container for MAC loop prevention.";
leaf window {
type uint32;
units "seconds";
default "180";
description
"The timer when a MAC mobility event is detected.";
}
leaf frequency {
type uint32;
default "5";
description
"The number of times to detect MAC duplication, where
a 'duplicate MAC address' situation has occurred and
the duplicate MAC address has been added to a list of
duplicate MAC addresses.";
}
leaf retry-timer {
type uint32;
units "seconds";
description
"The retry timer. When the retry timer expires,
the duplicate MAC address will be flushed from
the MAC-VRF.";
}
leaf protection-type {
type identityref {
base loop-prevention-type;
}
description
"Protection type.";
}
}
}
container multicast-like {
if-feature "vpn-common:multicast";
description
"Multicast-like container.";
leaf enabled {
type boolean;
default "false";
description
"Enables multicast.";
}
container customer-tree-flavors {
description
"Type of trees used by customer.";
leaf-list tree-flavor {
type identityref {
base vpn-common:multicast-tree-type;
}
description
"Type of multicast tree to be used.";
}
}
}
}
/* Main L2NM Container */
container l2vpn-ntw {
description
"Container for the L2NM.";
container vpn-profiles {
description
"Container for VPN profiles.";
uses vpn-common:vpn-profile-cfg;
}
container ethernet-segments {
description
"Top container for the Ethernet Segment Identifier (ESI).";
list ethernet-segment {
key "name";
description
"Top list for ESIs.";
leaf name {
type string;
description
"Includes the name of the Ethernet Segment (ES).";
}
leaf esi-type {
type identityref {
base esi-type;
}
default "esi-type-0";
description
"T-(ESI Type) is a 1-octet field (most significant
octet) that specifies the format of the remaining
9 octets (ESI Value).";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5";
}
choice esi-choice {
description
"Ethernet segment choice between several types.
For ESI Type 0: The esi is directly configured by the
operator.
For ESI Type 1: The auto-mode must be used.
For ESI Type 2: The auto-mode must be used.
For ESI Type 3: The directly-assigned or auto-mode must
be used.
For ESI Type 4: The directly-assigned or auto-mode must
be used.
For ESI Type 5: The directly-assigned or auto-mode must
be used.";
case directly-assigned {
description
"Explicitly assign an ESI value.";
leaf ethernet-segment-identifier {
type yang:hex-string {
length "29";
}
description
"10-octet ESI.";
}
}
case auto-assigned {
description
"The ESI is auto-assigned.";
container esi-auto {
description
"The ESI is auto-assigned.";
choice auto-mode {
description
"Indicates the auto-assignment mode. ESI can be
automatically assigned either with or without
indicating a pool from which the ESI should be
taken.
For both cases, the server will auto-assign an
ESI value 'auto-assigned-ESI' and use that value
operationally.";
case from-pool {
leaf esi-pool-name {
type string;
description
"The auto-assignment will be made from the
pool identified by the ESI-pool-name.";
}
}
case full-auto {
leaf auto {
type empty;
description
"Indicates an ESI is fully auto-assigned.";
}
}
}
leaf auto-ethernet-segment-identifier {
type yang:hex-string {
length "29";
}
config false;
description
"The value of the auto-assigned ESI.";
}
}
}
}
leaf esi-redundancy-mode {
type identityref {
base evpn-redundancy-mode;
}
description
"Indicates the EVPN redundancy mode for a multihomed
CE.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1";
}
container df-election {
description
"Top container for the DF election method properties.";
leaf df-election-method {
type identityref {
base df-election-methods;
}
default "default-7432";
description
"Specifies the DF election method.";
reference
"RFC 8584: Framework for Ethernet VPN Designated
Forwarder Election Extensibility";
}
leaf preference {
when "derived-from-or-self(../df-election-method, "
+ "'preference')" {
description
"The preference value is only applicable
to the preference based method.";
}
type uint16;
description
"Defines a 2-octet value that indicates the PE
preference to become the DF in the ES.";
reference
"RFC 8584: Framework for Ethernet VPN Designated
Forwarder Election Extensibility";
}
leaf revertive {
when "derived-from-or-self(../df-election-method, "
+ "'preference')" {
description
"The revertive value is only applicable
to the preference method.";
}
type boolean;
default "true";
description
"The 'preempt' or 'revertive' behavior. This
option allows a non-revertive behavior in the
DF election.";
reference
"RFC 8584: Framework for Ethernet VPN Designated
Forwarder Election Extensibility";
}
leaf election-wait-time {
type uint32;
description
"Election wait timer.";
reference
"RFC 8584: Framework for Ethernet VPN Designated
Forwarder Election Extensibility";
}
}
leaf split-horizon-filtering {
type boolean;
description
"Controls split-horizon filtering.
In order to achieve split-horizon filtering, every
Broadcast, unknown unicast, or multicast (BUM)
packet originating from a non-DF PE is encapsulated
with an MPLS label that identifies the origin ES.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5";
}
container pbb {
description
"Provider Backbone Bridging (PBB) parameters .";
reference
"IEEE 802.1ah: Provider Backbone Bridge";
leaf backbone-src-mac {
type yang:mac-address;
description
"The PEs connected to the same CE must share the
same Provider Backbone (B-MAC) address in
All-Active mode.";
reference
"RFC 7623: Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN), Section 6.2.1.1";
}
}
list member {
key "ne-id interface-id";
description
"Includes a list of ES members.";
leaf ne-id {
type string;
description
"Unique identifier of the network element where the ES
is configured.";
}
leaf interface-id {
type string;
description
"Identifier of a node interface.";
}
}
}
}
container vpn-services {
description
"Container for L2VPN services.";
list vpn-service {
key "vpn-id";
description
"Container of a VPN service.";
uses vpn-common:vpn-description;
leaf parent-service-id {
type vpn-common:vpn-id;
description
"Pointer to the parent service that
triggered the L2NM.";
}
leaf vpn-type {
type identityref {
base vpn-common:service-type;
}
must "not(derived-from-or-self(current(), "
+ "'vpn-common:l3vpn'))" {
error-message "L3VPN is only applicable in L3NM.";
}
description
"Service type.";
}
leaf vpn-service-topology {
type identityref {
base vpn-common:vpn-topology;
}
description
"Defining service topology, such as
any-to-any, hub-spoke, etc.";
}
leaf bgp-ad-enabled {
type boolean;
description
"Indicates whether BGP auto-discovery is enabled
or disabled.";
}
leaf signaling-type {
type identityref {
base vpn-common:vpn-signaling-type;
}
description
"VPN signaling type.";
}
container global-parameters-profiles {
description
"Container for a list of global parameters profiles.";
list global-parameters-profile {
key "profile-id";
description
"List of global parameters profiles.";
leaf profile-id {
type string;
description
"The identifier of the global parameters profile.";
}
uses vpn-common:route-distinguisher;
uses vpn-common:vpn-route-targets;
uses global-parameters-profile;
}
}
container underlay-transport {
description
"Container for the underlay transport.";
uses vpn-common:underlay-transport;
}
uses vpn-common:service-status;
container vpn-nodes {
description
"Set of VPN nodes that are involved in the L2NM.";
list vpn-node {
key "vpn-node-id";
description
"Container of the VPN nodes.";
leaf vpn-node-id {
type vpn-common:vpn-id;
description
"Sets the identifier of the VPN node.";
}
leaf description {
type string;
description
"Textual description of a VPN node.";
}
leaf ne-id {
type string;
description
"Indicates the node's IP address.";
}
leaf role {
type identityref {
base vpn-common:role;
}
default "vpn-common:any-to-any-role";
description
"Role of the VPN node in the VPN.";
}
leaf router-id {
type rt-types:router-id;
description
"A 32-bit number in the dotted-quad format that is
used to uniquely identify a node within an
autonomous system (AS). ";
}
container active-global-parameters-profiles {
description
"Container for a list of global parameters profiles.";
list global-parameters-profile {
key "profile-id";
description
"List of active global parameters profiles.";
leaf profile-id {
type leafref {
path "/l2vpn-ntw/vpn-services/vpn-service"
+ "/global-parameters-profiles"
+ "/global-parameters-profile/profile-id";
}
description
"Points to a global profile defined at the
service level.";
}
uses global-parameters-profile;
}
}
uses vpn-common:service-status;
container bgp-auto-discovery {
when "/l2vpn-ntw/vpn-services/vpn-service"
+ "/bgp-ad-enabled = 'true'" {
description
"Only applies when BGP auto-discovery is enabled.";
}
description
"BGP is used for auto-discovery.";
choice bgp-type {
description
"Choice for the BGP type.";
case l2vpn-bgp {
description
"Container for BGP L2VPN.";
leaf vpn-id {
type vpn-common:vpn-id;
description
"VPN Identifier. This identifier serves to unify
components of a given VPN for the sake of
auto-discovery.";
reference
"RFC 6624: Layer 2 Virtual Private Networks Using
BGP for Auto-Discovery and Signaling";
}
}
case evpn-bgp {
when "derived-from-or-self(/l2vpn-ntw/vpn-services"
+ "/vpn-service/vpn-type, 'vpn-common:vpws-evpn') "
+ "or derived-from-or-self(/l2vpn-ntw/vpn-services"
+ "/vpn-service/vpn-type, 'vpn-common:pbb-evpn') "
+ "or derived-from-or-self(/l2vpn-ntw/vpn-services"
+ "/vpn-service/vpn-type, 'vpn-common:mpls-evpn') "
+ "or derived-from-or-self(/l2vpn-ntw/vpn-services"
+ "/vpn-service/vpn-type, "
+ "'vpn-common:vxlan-evpn')" {
description
"Can only be used when EVPN is used.";
}
description
"EVPN case.";
leaf evpn-type {
type leafref {
path "/l2vpn-ntw/vpn-services/vpn-service"
+ "/vpn-type";
}
description
"EVPN type.";
}
leaf auto-rt-enable {
type boolean;
default "false";
description
"Enables/disabled RT auto-derivation based on
the ASN and Ethernet Tag ID.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 7.10.1";
}
leaf auto-route-target {
when "../auto-rt-enable = 'true'" {
description
"Can only be used when auto-RD is enabled.";
}
type rt-types:route-target;
config false;
description
"The value of the auto-assigned RT.";
}
}
}
uses vpn-common:route-distinguisher;
uses vpn-common:vpn-route-targets;
}
container signaling-option {
description
"Container for the L2VPN signaling.";
leaf advertise-mtu {
type boolean;
description
"Controls whether MTU is advertised.";
reference
"RFC 4667: Layer 2 Virtual Private Network (L2VPN)
Extensions for Layer 2 Tunneling
Protocol (L2TP), Section 4.3";
}
leaf mtu-allow-mismatch {
type boolean;
description
"When set to true, it allows MTU mismatch.";
reference
"RFC 4667: Layer 2 Virtual Private Network (L2VPN)
Extensions for Layer 2 Tunneling
Protocol (L2TP), Section 4.3";
}
leaf signaling-type {
type leafref {
path "/l2vpn-ntw/vpn-services/vpn-service"
+ "/signaling-type";
}
description
"VPN signaling type.";
}
choice signaling-option {
description
"Choice for the signaling-option.";
case bgp {
when "derived-from-or-self(./signaling-type, "
+ "'vpn-common:bgp-signaling')" {
description
"Only applies when VPN signaling type is BGP.";
}
description
"BGP is used as the signaling protocol.";
choice bgp-type {
description
"Choice for the BGP type.";
case l2vpn-bgp {
description
"Container for BGP L2VPN.";
leaf ce-id {
type uint16;
description
"The PE must know the set of virtual circuits
connecting it to the CE and a CE ID
identifying the CE within the VPN.";
reference
"RFC 6624: Layer 2 Virtual Private Networks
Using BGP for Auto-Discovery and
Signaling";
}
leaf ce-range {
type uint16;
description
"Determines the number of remote CEs with
which a given CE can communicate in the
context of a VPN.";
reference
"RFC 6624: Layer 2 Virtual Private Networks
Using BGP for Auto-Discovery and
Signaling";
}
leaf pw-encapsulation-type {
type identityref {
base iana-bgp-l2-encaps:bgp-l2-encaps-type;
}
description
"PW encapsulation type.";
}
container vpls-instance {
when "derived-from-or-self(/l2vpn-ntw"
+ "/vpn-services/vpn-service/vpn-type, "
+ "'vpn-common:vpls')" {
description
"Only applies for VPLS.";
}
description
"VPLS instance.";
leaf vpls-edge-id {
type uint16;
description
"VPLS Edge Identifier (VE ID).";
reference
"RFC 4761: Virtual Private LAN Service
(VPLS) Using BGP for Auto-
Discovery and Signaling";
}
leaf vpls-edge-id-range {
type uint16;
description
"Specifies the size of the range of VE ID in
a VPLS service. The range controls the size
of the label block advertised in the
context of a VPLS instance.";
reference
"RFC 4761: Virtual Private LAN Service
(VPLS) Using BGP for Auto-
Discovery and Signaling";
}
}
}
case evpn-bgp {
description
"Used for EVPN.";
leaf evpn-type {
type leafref {
path "/l2vpn-ntw/vpn-services/vpn-service"
+ "/vpn-nodes/vpn-node/bgp-auto-discovery"
+ "/evpn-type";
}
description
"EVPN type.";
}
leaf service-interface-type {
type identityref {
base evpn-service-type;
}
description
"EVPN service interface type.";
}
container evpn-policies {
description
"Includes a set of EVPN policies such as those
related to handling MAC addresses.";
leaf mac-learning-mode {
type identityref {
base mac-learning-mode;
}
description
"Indicates through which plane MAC addresses
are advertised.";
}
leaf ingress-replication {
type boolean;
description
"Controls whether ingress replication is
enabled/disabled.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 8.3.1.1";
}
leaf p2mp-replication {
type boolean;
description
"Controles whether P2MP replication is
enabled/disabled.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 8.3.1.2";
}
container arp-proxy {
if-feature "vpn-common:ipv4";
description
"Top container for the ARP proxy.";
leaf enable {
type boolean;
default "false";
description
"Enables (when set to 'true') or disables
(when set to 'false') ARP proxy.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 10";
}
leaf arp-suppression {
type boolean;
default "false";
description
"Enables (when set to 'true') or disables
(when set to 'false') ARP suppression.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN";
}
leaf ip-mobility-threshold {
type uint16;
description
"It is possible for a given host (as
defined by its IP address) to move from
one ES to another.
IP mobility threshold specifies the
number of IP mobility events
that are detected for a given IP address
within the detection-threshold before it
is identified as a duplicate IP address.
Once the detection threshold is reached,
updates for the IP address are
suppressed.";
}
leaf duplicate-ip-detection-interval {
type uint16;
description
"The time interval used in detecting a
duplicate IP address. Duplicate IP
address detection number of host moves
are allowed within this interval
period.";
}
}
container nd-proxy {
if-feature "vpn-common:ipv6";
description
"Top container for the ND proxy.";
leaf enable {
type boolean;
default "false";
description
"Enables (when set to 'true') or disables
(when set to 'false') ND proxy.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 10";
}
leaf nd-suppression {
type boolean;
default "false";
description
"Enables (when set to 'true') or disables
(when set to 'false') Neighbor Discovery
(ND) message suppression.
ND suppression is a technique that is
used to reduce the amount of ND packets
flooding within individual segments,
that is between hosts connected to the
same logical switch.";
}
leaf ip-mobility-threshold {
type uint16;
description
"It is possible for a given host (as
defined by its IP address) to move from
one ES to another.
IP mobility threshold specifies the
number of IP mobility events
that are detected for a given IP address
within the detection-threshold before it
is identified as a duplicate IP address.
Once the detection threshold is reached,
updates for the IP address are
suppressed.";
}
leaf duplicate-ip-detection-interval {
type uint16;
description
"The time interval used in detecting a
duplicate IP address. Duplicate IP
address detection number of host moves
are allowed within this interval
period.";
}
}
leaf underlay-multicast {
type boolean;
default "false";
description
"Enables (when set to 'true') or disables
(when set to 'false') underlay multicast.";
}
leaf flood-unknown-unicast-supression {
type boolean;
default "false";
description
"Enables (when set to 'true') or disables
(when set to 'false') unknown flood unicast
suppression.";
}
leaf vpws-vlan-aware {
type boolean;
default "false";
description
"Enables (when set to 'true') or disables
(when set to 'false') VPWS VLAN-aware.";
}
container bum-management {
description
"Broadcast-unknown-unicast-multicast
management.";
leaf discard-broadcast {
type boolean;
description
"Discards broadcast, when enabled.";
}
leaf discard-unknown-multicast {
type boolean;
description
"Discards unknown multicast, when
enabled.";
}
leaf discard-unknown-unicast {
type boolean;
description
"Discards unknown unicast, when enabled.";
}
}
container pbb {
when "derived-from-or-self(../../evpn-type,"
+ " 'pbb-evpn')" {
description
"Only applies for PBB EVPN.";
}
description
"PBB parameters container.";
reference
"IEEE 802.1ah: Provider Backbone Bridge";
leaf backbone-src-mac {
type yang:mac-address;
description
"Includes provider backbone MAC (B-MAC)
address.";
reference
"RFC 7623: Provider Backbone Bridging
Combined with Ethernet VPN
(PBB-EVPN), Section 8.1";
}
}
}
}
}
}
container ldp-or-l2tp {
description
"Container for LDP or L2TP-signaled PWs.";
leaf agi {
type rt-types:route-distinguisher;
description
"Attachment Group Identifier. Also, called
VPLS-Id.";
reference
"RFC 4667: Layer 2 Virtual Private Network (L2VPN)
Extensions for Layer 2 Tunneling
Protocol (L2TP), Section 4.3
RFC 4762: Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol (LDP)
Signaling, Section 6.1.1";
}
leaf saii {
type uint32;
description
"Source Attachment Individual Identifier (SAII).";
reference
"RFC 4667: Layer 2 Virtual Private Network (L2VPN)
Extensions for Layer 2 Tunneling
Protocol (L2TP), Section 3";
}
list remote-targets {
key "taii";
description
"List of allowed target Attachment Individual
Identifier (AII) and peers.";
reference
"RFC 4667: Layer 2 Virtual Private Network (L2VPN)
Extensions for Layer 2 Tunneling
Protocol (L2TP), Section 5";
leaf taii {
type uint32;
description
"Target Attachment Individual Identifier.";
reference
"RFC 4667: Layer 2 Virtual Private Network
(L2VPN) Extensions for Layer 2
Tunneling Protocol (L2TP),
Section 3";
}
leaf peer-addr {
type inet:ip-address;
description
"Indicates the peer forwarder's IP address.";
}
}
choice ldp-or-l2tp {
description
"Choice of LDP or L2TP-signaled PWs.";
case ldp {
when "derived-from-or-self(../signaling-type, "
+ "'vpn-common:ldp-signaling')" {
description
"Only applies when VPN signaling type is
Target LDP.";
}
description
"Container for T-LDP PW configurations.";
leaf t-ldp-pw-type {
type identityref {
base t-ldp-pw-type;
}
description
"T-LDP PW type.";
}
leaf pw-type {
type identityref {
base pw-type;
}
description
"PW encapsulation type.";
reference
"RFC 4762: Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol
(LDP) Signaling, Section 6.1.1";
}
leaf pw-description {
type string;
description
"Includes an interface description used to
send a human-readable administrative
string describing the interface to the
remote.";
reference
"RFC 4762: Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol
(LDP) Signaling, Section 6.1.1";
}
leaf mac-addr-withdraw {
type boolean;
description
"If set to 'true', then MAC address withdrawal
is enabled. If 'false', then MAC address
withdrawal is disabled.";
reference
"RFC 4762: Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol
(LDP) Signaling, Section 6.2";
}
list ac-pw-list {
key "peer-addr vc-id";
description
"List of AC and PW bindings.";
leaf peer-addr {
type inet:ip-address;
description
"Indicates the peer's IP address.";
}
leaf vc-id {
type string;
description
"VC label used to identify a PW.";
}
leaf pw-priority {
type uint32;
description
"Defines the priority for the PW.
The higher the pw-priority value, the
higher the preference of the PW will be.";
}
}
container qinq {
when "derived-from-or-self(../t-ldp-pw-type, "
+ "'hvpls')" {
description
"Only applies when t-ldp pw type is
h-vpls.";
}
description
"Container for QinQ.";
leaf s-tag {
type uint32;
mandatory true;
description
"S-TAG.";
}
leaf c-tag {
type uint32;
mandatory true;
description
"C-TAG.";
}
}
}
case l2tp {
when "derived-from-or-self(../signaling-type, "
+ "'vpn-common:l2tp-signaling')" {
description
"Applies when VPN signaling type is L2TP.";
}
description
"Container for L2TP PWs.";
leaf router-id {
type rt-types:router-id;
description
"A 32-bit number in the dotted-quad format
that is used to uniquely identify a node
within an autonomous system.";
reference
"RFC 4667: Layer 2 Virtual Private Network
(L2VPN) Extensions for Layer 2
Tunneling Protocol (L2TP),
Section 4.2";
}
leaf pseudowire-type {
type identityref {
base iana-pw-types:iana-pw-types;
}
description
"Encapsulation type.";
reference
"RFC 4667: Layer 2 Virtual Private Network
(L2VPN) Extensions for Layer 2
Tunneling Protocol (L2TP),
Section 4.2";
}
}
}
}
}
}
container vpn-network-accesses {
description
"Main container for VPN network accesses.";
list vpn-network-access {
key "id";
description
"List of VPN network accesses.";
leaf id {
type vpn-common:vpn-id;
description
"Identifier of the network access";
}
leaf description {
type string;
description
"A textual description of the VPN network access.";
}
leaf interface-id {
type string;
description
"Refers to a physical or logical interface.";
}
leaf global-parameters-profile {
type leafref {
path "/l2vpn-ntw/vpn-services/vpn-service/vpn-nodes"
+ "/vpn-node/active-global-parameters-profiles"
+ "/global-parameters-profile/profile-id";
}
description
"An identifier of an active VPN instance profile.";
}
uses vpn-common:service-status;
container connection {
description
"Container for the bearer and AC.";
leaf l2-termination-point {
type string;
description
"Specifies a reference to a local layer 2
termination point such as a layer 2
sub-interface.";
}
leaf local-bridge-reference {
type string;
description
"Specifies a local bridge reference to
accommodate, for example, implementations
that require internal bridging.
A reference may be a local bridge domain.";
}
leaf bearer-reference {
if-feature "vpn-common:bearer-reference";
type string;
description
"This is an internal reference for the service
provider to identify the bearer associated
with this VPN.";
}
container encapsulation {
description
"Container for layer 2 encapsulation.";
leaf encap-type {
type identityref {
base vpn-common:encapsulation-type;
}
default "vpn-common:priority-tagged";
description
"Tagged interface type. By default, the type of
the tagged interface is 'priority-tagged'.";
}
container dot1q {
when "derived-from-or-self(../encap-type, "
+ "'vpn-common:dot1q')" {
description
"Only applies when the type of the
tagged interface is 'dot1q'.";
}
description
"Tagged interface.";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:c-vlan";
description
"Tag type. By default, the tag type is
'c-vlan'.";
}
leaf cvlan-id {
type uint16;
description
"VLAN identifier.";
}
container rewrite {
description
"Sets the tag rewriting policy for this
'vpn-network-accesses'. Enables the
manipulation of the layer-2 frame header for
data frames as they are processed on the
'vpn-network-access'.";
choice tag-choice {
description
"Selects the tag rewriting policy for a VPN
network access. It defines a set of
standard tag manipulations that allow for
the insertion, removal, or rewriting of one
or two 802.1Q VLAN tags.";
leaf pop {
type enumeration {
enum 1 {
description
"Allows one (1) tag removal.";
}
enum 2 {
description
"Allows two (2) tags removal.";
}
}
description
"Standard tag removal.
The number of 802.1Q VLAN tags to pop.";
}
leaf push {
type empty;
description
"Standard tag Push.
The number of 802.1Q tags to push on the
front of the frame.";
}
leaf translate {
type enumeration {
enum 1-to-1 {
description
"Allows one (1) to one (1) tag
translation.";
}
enum 1-to-2 {
description
"Allows one (1) to two (2) tags
translation.";
}
enum 2-to-1 {
description
"Allows two (2) to one (1) tag
translation.";
}
enum 2-to-2 {
description
"Allows two (2) to two (2) tags
translation.";
}
}
description
"Replaces tags with other tags.
Translate operations are expressed as
as a combination of tag push and pop
operations. For example, translating the
outer tag is expressed as popping a
single tag.";
}
}
leaf cvlan-id {
when 'not(../pop)';
type uint16;
description
"Push/Translate vlan tags";
}
leaf direction {
type enumeration {
enum symmetric {
description
"TAGs operation is performed in a
symmetric way.
The operation is performed on the
outbound traffic on an interface, then
the reverse operation is performed on
the inbound traffic out of the
same interface.";
}
}
description
"Indicates the direction.";
}
}
}
container priority-tagged {
when "derived-from-or-self(../encap-type, "
+ "'vpn-common:priority-tagged')" {
description
"Only applies when the type of the
tagged interface is 'priority-tagged'.";
}
description
"Priority tagged container.";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:c-vlan";
description
"Tag type. By default, the tag type is
'c-vlan'.";
}
}
container qinq {
when "derived-from-or-self(../encap-type, "
+ "'vpn-common:qinq')" {
description
"Only applies when the type of the tagged
interface is QinQ.";
}
description
"Includes QinQ parameters.";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:s-c-vlan";
description
"Tag type. By default, the tag type is
's-c-vlan'.";
}
leaf svlan-id {
type uint16;
mandatory true;
description
"S-VLAN identifier.";
}
leaf cvlan-id {
type uint16;
mandatory true;
description
"C-VLAN identifier.";
}
}
}
container lag-interface {
if-feature "vpn-common:lag-interface";
description
"Container of LAG interface attributes
configuration.";
leaf lag-interface-id {
type string;
description
"LAG interface identifier.";
}
container lacp {
description
"Container for LACP.";
leaf lacp-state {
type boolean;
default "false";
description
"Controls whether LACP is enabled.";
}
leaf mode {
type identityref {
base lacp-mode;
}
description
"Indicates the LACP mode.";
}
leaf speed {
type uint32;
units "mbps";
default "10";
description
"LACP speed. By default, the LACP speed is 10
Mbps.";
}
leaf mini-link-num {
type uint32;
description
"Defines the minimum number of links that must
be active before the aggregating link is put
into service.";
}
leaf system-id {
type yang:mac-address;
description
"Indicates the System ID used by LACP.";
}
leaf admin-key {
type uint16;
description
"Indicates the value of the key used for the
aggregate interface.";
}
leaf system-priority {
type uint16 {
range "0..65535";
}
default "32768";
description
"Indicates the LACP priority for the
system.";
}
container member-link-list {
description
"Container of Member link list.";
list member-link {
key "name";
description
"Member link.";
leaf name {
type string;
description
"Member link name.";
}
leaf port-speed {
type uint32;
description
"Port speed.";
}
leaf mode {
type identityref {
base vpn-common:neg-mode;
}
description
"Negotiation mode.";
}
leaf link-mtu {
type uint32;
description
"Link MTU size.";
}
container oam-802.3ah-link {
if-feature "oam-3ah";
description
"Container for oam 802.3 ah link.";
leaf enable {
type boolean;
description
"Indicates support of OAM 802.3 ah
link.";
}
}
}
}
leaf flow-control {
type string;
description
"Indicates whtehr flow control is
supported.";
}
leaf lldp {
type boolean;
description
"Indicates whether Link Layer Discovery
Protocol (LLDP) is supported.";
}
}
container split-horizon {
description
"Configuration with split horizon enabled.";
leaf group-name {
type string;
description
"Group name of the Split Horizon.";
}
}
}
}
container vpws-service-instance {
when "derived-from-or-self(/l2vpn-ntw/vpn-services"
+ "/vpn-service/vpn-nodes/vpn-node"
+ "/bgp-auto-discovery/evpn-type, "
+ "'vpws-evpn')" {
description
"Only applies for EVPN-VPWS.";
}
description
"Local and remote VPWS Service Instance (VSI)";
reference
"RFC 8214: Virtual Private Wire Service Support
in Ethernet VPN";
choice local-vsi-choice {
description
"Choices for assigning local VSI.";
case directly-assigned {
description
"Explicitly assign a local VSI.";
leaf local-vpws-service-instance {
type uint32 {
range "1..16777215";
}
description
"Indicates the assigned local VSI.";
}
}
case auto-assigned {
description
"The local VSI is auto-assigned.";
container local-vsi-auto {
description
"The local VSI is auto-assigned.";
choice auto-mode {
description
"Indicates the auto-assignment mode of
local VSI. VSI can be automatically
assigned either with or without
indicating a pool from which the VSI
should be taken.
For both cases, the server will
auto-assign a local VSI value and use
that value.";
case from-pool {
leaf vsi-pool-name {
type string;
description
"The auto-assignment will be made
from this pool.";
}
}
case full-auto {
leaf auto {
type empty;
description
"Indicates that a local VSI is
fully auto-assigned.";
}
}
}
leaf auto-local-vsi {
type uint32 {
range "1..16777215";
}
config false;
description
"The value of the auto-assigned local
VSI.";
}
}
}
}
choice remote-vsi-choice {
description
"Choice for assigning the remote VSI.";
case directly-assigned {
description
"Explicitly assign a remote VSI.";
leaf remote-vpws-service-instance {
type uint32 {
range "1..16777215";
}
description
"Indicates the value of the remote
VSI.";
}
}
case auto-assigned {
description
"The remote VSI is auto-assigned.";
container remote-vsi-auto {
description
"The remote VSI is auto-assigned.";
choice auto-mode {
description
"Indicates the auto-assignment mode
of remote VSI. VSI can be
automatically assigned either with or
without indicating a pool from which
the VSI should be taken.
For both cases, the server will
auto-assign a remote VSI value and use
that value.";
case from-pool {
leaf vsi-pool-name {
type string;
description
"The auto-assignment will be made
from this pool.";
}
}
case full-auto {
leaf auto {
type empty;
description
"Indicates that a remote VSI is fully
auto-assigned.";
}
}
}
leaf auto-remote-vsi {
type uint32 {
range "1..16777215";
}
config false;
description
"The value of the auto-assigned remote
VSI.";
}
}
}
}
}
list group {
key "group-id";
description
"List of group-ids.";
leaf group-id {
type string;
description
"Indicates the group-id to which the network
access belongs to.";
}
leaf precedence {
type identityref {
base precedence-type;
}
description
"Defining service redundancy in transport
network.";
}
leaf ethernet-segment-identifier {
type leafref {
path "/l2vpn-ntw/ethernet-segments"
+ "/ethernet-segment/name";
}
description
"Reference to the ESI associated to the VPN
network access.";
}
}
container ethernet-service-oam {
description
"Container for Ethernet service OAM.";
leaf md-name {
type string;
description
"Maintenance domain name.";
}
leaf md-level {
type uint8;
description
"Maintenance domain level.";
}
container cfm-802.1-ag {
description
"Container of 802.1ag CFM configurations.";
list n2-uni-c {
key "maid";
description
"List of UNI-N to UNI-C.";
uses cfm-802-grouping;
}
list n2-uni-n {
key "maid";
description
"List of UNI-N to UNI-N.";
uses cfm-802-grouping;
}
}
uses y-1731;
}
container service {
description
"Container for service";
leaf mtu {
type uint32;
description
"MTU, it is also known as the maximum
transmission unit or maximum frame size. When a
frame is larger than the MTU, it is broken down,
or fragmented, into smaller pieces by the
network protocol to accommodate the MTU of the
network";
}
container svc-inbound-bandwidth {
if-feature "vpn-common:inbound-bw";
description
"From the PE perspective, the service inbound
bandwidth of the connection.";
list inbound-bandwidth {
key "bw-type";
description
"List for input bandwidth data nodes.";
leaf bw-type {
type identityref {
base vpn-common:bw-type;
}
description
"Indicates the bandwidth type.";
}
leaf cos-id {
if-feature "vpn-common:qos";
type uint8;
description
"Identifier of the Class of Service (CoS),
indicated by DSCP or a CE-CLAN
CoS (802.1p) value in the service frame.";
}
leaf cir {
type uint64;
description
"Committed Information Rate. The maximum
number of bits that a port can receive or
send during one-second over an interface.";
}
leaf cbs {
type uint64;
description
"Committed Burst Size. CBS controls the bursty
nature of the traffic. Traffic that does not
use the configured CIR accumulates credits
until the credits reach the configured CBS.";
}
leaf eir {
type uint64;
description
"Excess Information Rate, i.e., excess frame
delivery allowed not subject to SLA. The
traffic rate can be limited by EIR.";
}
leaf ebs {
type uint64;
description
"Excess Burst Size. The bandwidth available
for burst traffic from the EBS is subject to
the amount of bandwidth that is accumulated
during periods when traffic allocated by the
EIR policy is not used.";
}
leaf pir {
type uint64;
description
"Peak Information Rate, i.e., maximum frame
delivery allowed. It is equal to or less
than sum of CIR and EIR.";
}
leaf pbs {
type uint64;
units "bytes per second";
description
"Peak Burst Size.";
}
}
}
container svc-outbound-bandwidth {
if-feature "vpn-common:outbound-bw";
description
"From the PE perspective, the service outbound
bandwidth of the connection.";
list outbound-bandwidth {
key "bw-type";
description
"List for outbound bandwidth";
leaf bw-type {
type identityref {
base vpn-common:bw-type;
}
description
"Bandwidth Type.";
}
leaf cos-id {
if-feature "vpn-common:qos";
type uint8;
description
"Identifier of the CoS, indicated by
DSCP or a CE-CLAN CoS (802.1p) value in
the service frame.";
}
leaf cir {
type uint64;
description
"Committed Information Rate. The maximum
number of bits that a port can receive or
send during one-second over an interface.";
}
leaf cbs {
type uint64;
description
"Committed Burst Size. CBS controls the bursty
nature of the traffic. Traffic that does not
use the configured CIR accumulates credits
until the credits reach the configured CBS.";
}
leaf eir {
type uint64;
description
"Excess Information Rate, i.e., excess frame
delivery allowed not subject to SLA. The
traffic rate can be limited by EIR.";
}
leaf ebs {
type uint64;
description
"Excess Burst Size. The bandwidth available
for burst traffic from the EBS is subject to
the amount of bandwidth that is accumulated
during periods when traffic allocated by the
EIR policy is not used.";
}
leaf pir {
type uint64;
description
"Peak Information Rate, i.e., maximum frame
delivery allowed. It is equal to or less than
sum of CIR and EIR.";
}
leaf pbs {
type uint64;
units "bytes per second";
description
"Peak Burst Size.";
}
}
}
container qos {
if-feature "vpn-common:qos";
description
"QoS configuration.";
container qos-classification-policy {
description
"Configuration of the traffic classification
policy.";
list rule {
key "id";
ordered-by user;
description
"List of classification rules.";
leaf id {
type string;
description
"A description identifying the QoS
classification policy rule.";
}
choice match-type {
default "match-flow";
description
"Choice for classification.";
case match-flow {
container match-flow {
description
"Describes flow-matching criteria.";
leaf dscp {
type inet:dscp;
description
"DSCP value.";
}
leaf dot1q {
type uint16;
description
"802.1Q matching. It is a VLAN tag
added into a frame.";
}
leaf pcp {
type uint8 {
range "0..7";
}
description
"PCP value.";
}
leaf src-mac-address {
type yang:mac-address;
description
"Source MAC address.";
}
leaf dst-mac-address {
type yang:mac-address;
description
"Destination MAC address.";
}
leaf color-type {
type identityref {
base color-type;
}
description
"Color type.";
}
leaf any {
type empty;
description
"Allows all.";
}
}
}
case match-application {
leaf match-application {
type identityref {
base vpn-common:customer-application;
}
description
"Defines the application to match.";
}
}
}
leaf target-class-id {
type string;
description
"Identification of the CoS.
This identifier is internal to the
administration.";
}
}
}
container qos-profile {
description
"QoS profile configuration.";
list qos-profile {
key "profile";
description
"QoS profile.
Can be standard profile or customized
profile.";
leaf profile {
type leafref {
path "/l2vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers"
+ "/qos-profile-identifier/id";
}
description
"QoS profile to be used.";
}
leaf direction {
type identityref {
base vpn-common:qos-profile-direction;
}
default "vpn-common:both";
description
"The direction to which the QoS profile
is applied.";
}
}
}
}
container mac-policies {
description
"Container for MAC-related policies.";
list access-control-list {
key "name";
description
"Container for access control List.";
leaf name {
type string;
description
"Specifies the name of the ACL.";
}
leaf-list src-mac-address {
type yang:mac-address;
description
"Specifies the source MAC address.";
}
leaf-list src-mac-address-mask {
type yang:mac-address;
description
"Specifies the source MAC address mask.";
}
leaf-list dst-mac-address {
type yang:mac-address;
description
"Specifies the destination MAC address.";
}
leaf-list dst-mac-address-mask {
type yang:mac-address;
description
"Specifies the destination MAC address mask.";
}
leaf action {
type identityref {
base mac-action;
}
default "drop";
description
"Specifies the filtering action.";
}
leaf rate-limit {
when "derived-from-or-self(../action, "
+ "'flood')" {
description
"Rate-limit is valid only when the action is
to accept the matching frame.";
}
type decimal64 {
fraction-digits 2;
}
units "bytes per second";
description
"Specifies how to rate-limit the traffic.";
}
}
container mac-loop-prevention {
description
"Container of MAC loop prevention.";
leaf window {
type uint32;
units "seconds";
default "180";
description
"The timer when a MAC mobility event is
detected.";
}
leaf frequency {
type uint32;
default "5";
description
"The number of times to detect MAC
duplication, where a 'duplicate MAC address'
situation has occurred and the duplicate MAC
address has been added to a list of duplicate
MAC addresses.";
}
leaf retry-timer {
type uint32;
units "seconds";
description
"The retry timer. When the retry timer
expires, the duplicate MAC address will be
flushed from the MAC-VRF.";
}
leaf protection-type {
type identityref {
base loop-prevention-type;
}
description
"Protection type";
}
}
container mac-addr-limit {
description
"Container of MAC-Addr limit configurations";
leaf mac-num-limit {
type uint16;
description
"maximum number of MAC addresses learned from
the subscriber for a single service
instance.";
}
leaf time-interval {
type uint32;
units "milliseconds";
description
"The aging time of the mac address.";
}
leaf action {
type identityref {
base mac-action;
}
description
"specify the action when the upper limit is
exceeded: drop the packet, flood the
packet, or simply send a warning log
message.";
}
}
}
container broadcast-unknown-unicast-multicast {
description
"Container of broadcast, unknown unicast, and
multicast configurations";
leaf multicast-site-type {
type enumeration {
enum receiver-only {
description
"The site only has receivers.";
}
enum source-only {
description
"The site only has sources.";
}
enum source-receiver {
description
"The site has both sources and receivers.";
}
}
default "source-receiver";
description
"Type of the multicast site.";
}
list multicast-gp-address-mapping {
key "id";
description
"List of Port to group mappings.";
leaf id {
type uint16;
description
"Unique identifier for the mapping.";
}
leaf vlan-id {
type uint32;
description
"The VLAN ID of the Multicast group.";
}
leaf mac-gp-address {
type yang:mac-address;
description
"The MAC address of the Multicast group.";
}
leaf port-lag-number {
type uint32;
description
"The ports/LAGs belonging to the Multicast
group.";
}
}
leaf bum-overall-rate {
type uint32;
description
"Overall rate for BUM.";
}
}
}
}
}
}
}
}
}
}
}
<CODE ENDS>¶
The YANG modules specified in this document defines schema for data that is 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-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].¶
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 "ietf-l2vpn-ntw" YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability in the "ietf-l2vpn-ntw" module:¶
Some of the readable data nodes in the "ietf-l2vpn-ntw" YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:¶
Both "iana-bgp-l2-encaps" and "iana-pseudowire-types" modules define YANG identities for encapsulation/pseudowires types. These identities are intended to be referenced by other YANG modules, and by themselves do not expose any nodes which are writable, contain read-only state, or RPCs.¶
This document requests IANA to register 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-l2vpn-ntw
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.¶
This document requests IANA to register 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 XXXX
name: iana-pseudowire-types
namespace: urn:ietf:params:xml:ns:yang:iana-pseudowire-types
maintained by IANA: Y
prefix: iana-pw-types
reference: RFC XXXX
name: ietf-l2vpn-ntw
namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw
maintained by IANA: N
prefix: l2vpn-ntw
reference: RFC XXXX¶
This document defines the initial version of the IANA-maintained "iana-bgp-l2-encaps" YANG module. IANA is requested to add this note for both modules:¶
When a Layer 2 encapsulation type is added to the "BGP Layer 2 Encapsulation Types" registry, a new "identity" statement must be added to the "iana-bgp-l2-encaps" YANG module. The name of the "identity" is the lower-case of encapsulation name provided in the description. The "identity" statement should have the following sub-statements defined:¶
Unassigned or reserved values are not present in the module.¶
When the "iana-bgp-l2-encaps" YANG module is updated, a new "revision" statement must be added in front of the existing revision statements.¶
IANA is requested to add this note to [IANA-BGP-L2]:¶
This document defines the initial version of the IANA-maintained "iana-pseudowire-types" YANG module. IANA is requested to add this note for both modules:¶
When a pseudowire type is added to the "iana-pseudowire-types" registry, a new "identity" statement must be added to the "iana-pseudowire-types" YANG module. The name of the "identity" is the lower-case of encapsulation name provided in the description. The "identity" statement should have the following sub-statements defined:¶
Unassigned or reserved values are not present in the module.¶
When the "iana-pseudowire-types" YANG module is updated, a new "revision" statement must be added in front of the existing revision statements.¶
IANA is requested to add this note to [IANA-PW-Types]:¶
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 the folding defined in [RFC8792] for long lines.¶
This section provides an example to illustrate how the L2NM can be used to mange 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.¶
+-----+ +--------------+ +-----+
+----+ | PE1 |======| |===| PE3 | +----+
| CE1+-------+ | | | | +-------+ CE3|
+----+ +-----+ | | +-----+ +----+
| Core |
+----+ +-----+ | | +-----+ +----+
|CE2 +-------+ | | | | +-------+ CE4|
+----+ | PE2 |======| |===| PE4 | +----+
+-----+ +--------------+ +-----+
Figure 24 show an example of a message body used to configured a VPLS instance using the L2NM. In this example, BGP is used for both auto-discovery and signaling. The 'signaling-type' data node is set to 'vpn-common:bgp-signaling'.¶
{
"ietf-l2vpn-ntw:vpn-services": {
"vpn-service": [
{
"vpn-id": "vpls7714825356",
"description": "Sample BGP-based VPLS",
"customer-name": "customer-7714825356",
"vpn-type": "vpn-common:vpls",
"bgp-ad-enabled": true,
"signaling-type": "vpn-common:bgp-signaling",
"global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile",
"local-autonomous-system": 65550,
"mtu": 1518,
"rd-suffix": "1",
"vpn-targets": {
"vpn-target": [
{
"id": 1,
"route-targets": [
"0:65550:1"
],
"route-target-type": "both"
}
]
}
}
]
},
"vpn-node": [
{
"vpn-node-id": "pe1",
"ne-id": "198.51.100.1",
"active-global-parameters-profile": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet-\
tagged-mode",
"vpls-instance": {
"vpls-edge-id": 1,
"vpls-edge-id-range": 100
}
},
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE1",
"global-parameters-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
},
{
"vpn-node-id": "pe2",
"ne-id": "198.51.100.2",
"active-global-parameters-profile": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet-\
tagged-mode",
"vpls-instance": {
"vpls-edge-id": 2,
"vpls-edge-id-range": 100
}
},
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE2",
"global-parameters-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
},
{
"vpn-node-id": "pe3",
"ne-id": "198.51.100.3",
"active-global-parameters-profile": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet-\
tagged-mode",
"vpls-instance": {
"vpls-edge-id": 3,
"vpls-edge-id-range": 100
}
},
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE3",
"global-parameters-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
},
{
"vpn-node-id": "pe4",
"ne-id": "198.51.100.4",
"active-global-parameters-profile": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet-\
tagged-mode",
"vpls-instance": {
"vpls-edge-id": 4,
"vpls-edge-id-range": 100
}
},
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE4",
"global-parameters-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
}
]
}
]
}
}
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.¶
+-----+ +--------------+ +-----+
+----+ | PE1 |======| |===| PE2 | +----+
| CE1+-------+ | | Core | | +-------+ CE2|
+----+ +-----+ +--------------+ +-----+ +----+
site1 site2
{
"ietf-l2vpn-ntw:vpn-services": {
"vpn-service": [
{
"vpn-id": "vpws12345",
"description": "Sample VPWS",
"customer-name": "customer-12345",
"vpn-type": "vpn-common:vpws",
"bgp-ad-enabled": true,
"signaling-type": "vpn-common:ldp-signaling",
"global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile",
"local-autonomous-system": 65550,
"rd-auto": {
"auto": [
null
]
},
"vpn-targets": {
"vpn-target": [
{
"id": 1,
"route-targets": [
"0:65550:1"
]
}
]
}
}
]
},
"vpn-node": [
{
"vpn-node-id": "pe1",
"ne-id": "2001:db8:100::1",
"active-global-parameters-profile": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE1",
"global-parameters-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"bgp-auto-discovery": {
"vpn-id": "587"
},
"signaling-option": {
"mtu-pw": 1500,
"ldp-or-l2tp": {
"saii": 1,
"remote-targets": [
{
"taii": 2
}
]
},
"pw-type": "ethernet"
}
}
]
},
{
"vpn-node-id": "pe2",
"ne-id": "2001:db8:200::1",
"active-global-parameters-profile": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"vpn-network-access": [
{
"id": "5/1/1.1",
"interface-id": "5/1/1",
"description": "Interface to CE2",
"global-parameters-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"bgp-auto-discovery": {
"vpn-id": "587"
},
"signaling-option": {
"mtu-pw": 1500,
"ldp-or-l2tp": {
"saii": 2,
"remote-targets": [
{
"taii": 1
}
]
},
"pw-type": "ethernet"
}
}
]
}
]
}
]
}
}
This section provides an example to illustrate 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. We consider the sample service delivered using the architecture depicted in Figure 27.¶
+----------- VPLS "1543" ------------+
+-----+ +--------------+ +-----+
+----+ | PE1 |======| |===| PE2 | +----+
| CE1 +-----+"450"| | MPLS | |"451"+-------+ CE2|
+----+ +-----+ | | +-----+ +----+
| Core |
+--------------+
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 and each with a corresponding VPN network access is also created.¶
{
"l2vpn-ntw": {
"vpn-services": {
"vpn-service": {
"vpn-id": "450",
"vpn-name": "CORPO-EXAMPLE",
"vpn-description": "SEDE_CENTRO_450",
"customer-name": "EXAMPLE",
"vpn-type": "vpn-common:vpls",
"vpn-service-topology": "vpn-common:hub-spoke",
"bgp-ad-enabled": false,
"signaling-type": "vpn-common:ldp-signaling",
"global-parameters-profiles": {
"global-parameters-profile": {
"ce-vlan-preservation": "true",
"ce-vlan-cos-preservation": "true"
}
},
"vpn-nodes": [
{
"vpn-node": {
"vpn-node-id": "450",
"description": "SEDE_CENTRO_450",
"ne-id": "2001:db8:5::1",
"role": "vpn-common:hub-role",
"status": {
"admin-status": {
"status": "vpn-common:admin-up"
}
},
"ldp-or-l2tp": {
"signaling-option": [
{
"t-ldp-pw-type": "vpls-type"
}
]
},
"ac-pw-list": [
{
"peer-addr": "2001:db8:50::1",
"vc-id": "1543"
}
]
},
"vpn-network-accesses": {
"vpn-network-access": {
"id": "4508671287",
"description": "VPN_450_SNA",
"interface-id": "gigabithethernet0/0/1",
"status": {
"admin-status": {
"status": "vpn-common:admin-up"
}
},
"connection": {
"l2-termination-point": "550",
"encapsulation": {
"encap-type": "vpn-common:dot1q",
"dot1q": {
"tag-type": "vpn-common:c-vlan",
"cvlan-id": 550
}
}
},
"service": {
"mtu": 1550,
"svc-inbound-bandwidth": {
"inbound-bandwidth": {
"bw-type": "vpn-common:bw-per-service",
"cir": "20480000"
}
},
"svc-outbound-bandwidth": {
"outbound-bandwidth": {
"bw-type": "vpn-common:bw-per-port",
"cir": "20480000"
}
},
"qos": {
"qos-profile": {
"qos-profile": {
"profile": "QoS_Profile_A",
"direction": "vpn-common:both"
}
}
}
}
}
}
},
{
"vpn-node": {
"vpn-node-id": "451",
"description": "SEDE_CHAPINERO_451",
"ne-id": "2001:db8:50::1",
"role": "vpn-common:spoke-role",
"status": {
"admin-status": {
"status": "vpn-common:admin-up"
}
},
"ldp-or-l2tp": {
"signaling-option": [
{
"t-ldp-pw-type": "vpls-type"
}
]
},
"ac-pw-list": [
{
"peer-addr": "2001:db8:5::1",
"vc-id": "1543"
}
]
},
"vpn-network-accesses": {
"vpn-network-access": {
"id": "4508671288",
"description": "VPN_450_SNA",
"interface-id": "gigabithethernet0/0/1",
"status": {
"admin-status": {
"status": "vpn-common:admin-up"
}
},
"connection": {
"l2-termination-point": "550",
"encapsulation": {
"encap-type": "vpn-common:dot1q",
"dot1q": {
"tag-type": "vpn-common:c-vlan",
"cvlan-id": 550
}
}
},
"service": {
"mtu": 1550,
"svc-inbound-bandwidth": {
"inbound-bandwidth": {
"bw-type": "vpn-common:bw-per-service",
"cir": "20480000"
}
},
"svc-outbound-bandwidth": {
"outbound-bandwidth": {
"bw-type": "vpn-common:bw-per-port",
"cir": "20480000"
}
},
"qos": {
"qos-profile": {
"qos-profile": {
"profile": "QoS_Profile_A",
"direction": "vpn-common:both"
}
}
}
}
}
}
}
]
}
}
}
}
Figure 29 depictes a sample architecture to offer VPWS-EVPN service between CE1 and CE2. Both CEs are multi-homed. BGP sessions are maintained between these PEs as per [RFC8214]. In this EVPN instance, an All-Active redundancy mode is used.¶
|<--------- EVPN Instance ----------->|
| |
| V V |
| +-----+ +--------------+ +-----+ |
+----+ | | PE1 |======| |===| PE3 | | +----+
| +-------+ | | | | +-------+ |
| | | +-----+ | | +-----+ | | |
| CE1| | | Core | | |CE2 |
| | | +-----+ | | +-----+ | | |
| +-------+ | | | | +-------+ |
+----+ | | PE2 |======| |===| PE4 | | +----+
^ ESI1 +-----+ +--------------+ +-----+ ESI2 ^
| |
|<---------------- Emulated Service -------------------->|
Let's first suppose that the following ES was created (Figure 30).¶
{
"ietf-l2vpn-ntw:ethernet-segments": {
"ethernet-segment": [
{
"name": "esi1",
"ethernet-segment-identifier": "00:11:11:11:11:11:11:\
11:11:11",
"esi-redundancy-mode": "all-active"
},
{
"name": "esi2",
"ethernet-segment-identifier": "00:22:22:22:22:22:22:\
22:22:22",
"esi-redundancy-mode": "all-active"
}
]
}
}
Figure 29 shows a simplified configuration to illustrate the use of the L2NM to configured VPWS-EVPN instance.¶
{
"ietf-l2vpn-ntw:vpn-services": {
"vpn-service": [
{
"vpn-id": "vpws15432855",
"description": "Sample VPWS-EVPN",
"customer-name": "customer_15432855",
"vpn-type": "vpn-common:vpws-evpn",
"bgp-ad-enabled": true,
"signaling-type": "vpn-common:bgp-signaling",
"global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile",
"local-autonomous-system": 65550,
"rd-suffix": "1",
"vpn-targets": {
"vpn-target": [
{
"id": 1,
"route-targets": [
"0:65550:1"
],
"route-target-type": "both"
}
]
}
}
]
},
"vpn-node": [
{
"vpn-node-id": "pe1",
"ne-id": "198.51.100.1",
"active-global-parameters-profile": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE1",
"global-parameters-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "dot1q",
"dot1q": {
"cvlan-id": 1
}
}
},
"vpws-service-instance": {
"local-vpws-service-instance": 1111,
"remote-vpws-service-instance": 1112
},
"group": [
{
"group-id": "gr1",
"ethernet-segment-identifier": "esi1"
}
]
}
]
},
{
"vpn-node-id": "pe2",
"ne-id": "198.51.100.2",
"active-global-parameters-profile": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE1",
"global-parameters-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "dot1q",
"dot1q": {
"cvlan-id": 1
}
}
},
"vpws-service-instance": {
"local-vpws-service-instance": 1111,
"remote-vpws-service-instance": 1112
},
"group": [
{
"group-id": "gr1",
"ethernet-segment-identifier": "esi1"
}
]
}
]
},
{
"vpn-node-id": "pe3",
"ne-id": "198.51.100.3",
"active-global-parameters-profile": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE2",
"global-parameters-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "dot1q",
"dot1q": {
"cvlan-id": 1
}
}
},
"vpws-service-instance": {
"local-vpws-service-instance": 1112,
"remote-vpws-service-instance": 1111
},
"group": [
{
"group-id": "gr1",
"ethernet-segment-identifier": "esi2"
}
]
}
]
},
{
"vpn-node-id": "pe4",
"ne-id": "198.51.100.4",
"active-global-parameters-profile": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE2",
"global-parameters-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "dot1q",
"dot1q": {
"cvlan-id": 1
}
}
},
"vpws-service-instance": {
"local-vpws-service-instance": 1112,
"remote-vpws-service-instance": 1111
},
"group": [
{
"group-id": "gr1",
"ethernet-segment-identifier": "esi2"
}
]
}
]
}
]
}
]
}
}
This section provides an example to illustrate how the L2NM can be used to manage ESI auto-assignment. We consider the sample EVPN service delivered using the architecture depicted in Figure 32.¶
ES
| +-----+ +--------------+ +-----+
+----+ | | PE1 |======| |===| PE3 | +----+
| +-------+ | | | | +-------+ CE3|
| | | +-----+ | | +-----+ +----+
| CE1| | | Core |
| | | +-----+ | | +-----+ +----+
| +-------+ | | | | +-------+ CE2|
+----+ | | PE2 |======| |===| PE4 | +----+
LACP +-----+ +--------------+ +-----+
Figure 33 and Figure 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.¶
{
"ietf-l2vpn-ntw:ethernet-segments": {
"ethernet-segment": [
{
"name": "esi1",
"ethernet-segment-identifier": "esi-type-1",
"esi-redundancy-mode": "all-active"
}
]
}
}
{
"ietf-l2vpn-ntw:vpn-services": {
"vpn-service": [
{
"vpn-id": "auto-esi-lacp",
"description": "Sample to illustrate auto-ESI",
"vpn-type": "vpn-common:vpls-evpn",
"vpn-node": [
{
"vpn-node-id": "pe1",
"ne-id": "198.51.100.1",
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE1",
"global-parameters-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"connection": {
"lag-interface": {
"lag-interface": [
{
"lag-interface-id": "1",
"lacp": {
"lacp-state": true,
"system-id": "11:00:11:00:11:11",
"admin-key": 154
}
}
]
}
},
"group": [
{
"group-id": "gr1",
"ethernet-segment-identifier": "esi1"
}
]
}
]
},
{
"vpn-node-id": "pe2",
"ne-id": "198.51.100.2",
"vpn-network-access": [
{
"id": "2/2/2.5",
"interface-id": "2/2/2",
"description": "Interface to CE1",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"connection": {
"lag-interface": {
"lag-interface": [
{
"lag-interface-id": "1",
"lacp": {
"lacp-state": true,
"system-id": "11:00:11:00:11:11",
"admin-key": 154
}
}
]
}
},
"group": [
{
"group-id": "gr1",
"ethernet-segment-identifier": "esi1"
}
]
}
]
}
]
}
]
}
}
The auto-assigned ESI can be retrieved using, e.g., a GET RESTCONF method. The assigned value will be then returned as shown in the 'esi-auto' data node in Figure 35.¶
{
"ietf-l2vpn-ntw:ethernet-segments": {
"ethernet-segment": [
{
"name": "esi1",
"ethernet-segment-identifier": "esi-type-1",
"esi-auto": {
"auto-ethernet-segment-identifier": "01:11:00:11:00:11:\
11:9A:00:00"
},
"esi-redundancy-mode": "all-active"
}
]
}
}
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.¶
+--------------+ |VPN-NODE | | +--+-------+ | | NET-ACC-1| Primary | | +------------------ | +--+-------+ | | | +--+-------+ | | NET-ACC-2| Secondary | | +------------------ | +--+-------+ | | +--------------+
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 as configuration, both accesses are bound to the same "group-id" and the "precedence" data node set as function of the intended role of each access (primary or secondary).¶
{
"vpn-services": {
"vpn-service": {
"vpn-id": "Sample-Service",
"vpn-nodes": {
"vpn-node": {
"vpn-node-id": "VPN-NODE",
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "NET-ACC-1",
"group": {
"group-id": "1",
"precedence": "primary"
}
},
{
"id": "NET-ACC-2",
"group": {
"group-id": "1",
"precedence": "secondary"
}
}
]
}
}
}
}
}
}
Value Description Reference
===== ================================ =========
1 Frame Relay [RFC4446]
2 ATM AAL5 SDU VCC transport [RFC4446]
3 ATM transparent cell transport [RFC4816]
4 Ethernet (VLAN) Tagged Mode [RFC4448]
5 Ethernet Raw Mode [RFC4448]
6 Cisco HDLC [RFC4618]
7 PPP [RFC4618]
8 SONET/SDH Circuit Emulation [RFC4842]
Service
9 ATM n-to-one VCC cell transport [RFC4717]
10 ATM n-to-one VPC cell transport [RFC4717]
11 IP Layer 2 Transport [RFC3032]
15 Frame Relay Port mode [RFC4619]
17 Structure-agnostic E1 over packet [RFC4553]
18 Structure-agnostic T1 (DS1) over [RFC4553]
packet
19 VPLS [RFC4761]
20 Structure-agnostic T3 (DS3) over [RFC4553]
packet
21 Nx64kbit/s Basic Service using [RFC5086]
Structure-aware
25 Frame Relay DLCI [RFC4619]
40 Structure-agnostic E3 over packet [RFC4553]
41 Octet-aligned payload for [RFC4553]
Structure-agnostic DS1 circuits
42 E1 Nx64kbit/s with CAS using [RFC5086]
Structure-aware
43 DS1 (ESF) Nx64kbit/s with CAS [RFC5086]
using Structure-aware
44 DS1 (SF) Nx64kbit/s with CAS [RFC5086]
using Structure-aware¶
PW Type Description Reference
======= ================================ =========
0x0001 Frame Relay DLCI [RFC4619]
0x0002 ATM AAL5 SDU VCC transport
0x0003 ATM transparent cell transport [RFC4717]
0x0004 Ethernet Tagged Mode [RFC4448]
0x0005 Ethernet [RFC4448]
0x0006 HDLC [RFC4618]
0x0007 PPP [RFC4618]
0x0008 SONET/SDH Circuit Emulation
Service Over MPLS Encapsulation [RFC5143]
0x0009 ATM n-to-one VCC cell transport [RFC4717]
0x000A ATM n-to-one VPC cell transport [RFC4717]
0x000B IP Layer2 Transport [RFC3032]
0x000C ATM one-to-one VCC Cell Mode [RFC4717]
0x000D ATM one-to-one VPC Cell Mode [RFC4717]
0x000E ATM AAL5 PDU VCC transport [RFC4717]
0x000F Frame-Relay Port mode [RFC4619]
0x0010 SONET/SDH Circuit Emulation [RFC4842]
Reference Packet
0x0011 Structure-agnostic E1 over [RFC4553]
Packet
0x0012 Structure-agnostic T1 (DS1) [RFC4553]
over Packet
0x0013 Structure-agnostic E3 over [RFC4553]
Packet
0x0014 Structure-agnostic T3 (DS3) [RFC4553]
over Packet
0x0015 CESoPSN basic mode [RFC5086]
0x0016 TDMoIP AAL1 Mode [RFC5087]
0x0017 CESoPSN TDM with CAS [RFC5086]
0x0018 TDMoIP AAL2 Mode [RFC5087]
0x0019 Frame Relay DLCI [RFC4619]
0x001A ROHC Transport Header-compressed [RFC5795][RFC4901]
Packets
0x001B ECRTP Transport Header-compressed [RFC3545][RFC4901]
Packets
0x001C IPHC Transport Header-compressed [RFC2507][RFC4901]
Packets
0x001D cRTP Transport Header-compressed [RFC2508][RFC4901]
Packets
0x001E ATM VP Virtual Trunk
0x001F FC Port Mode [RFC6307]
0x7FFF Wildcard [RFC4863]¶
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, Erez Segev, and Tom Petch. Many thanks to them.¶
Luay Jalil, Jichun Ma, Daniel King, and Zhang Guiyu contributed to an early version of this document.¶
Thanks to Yingzhen Qu for the rtgdir review.¶
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).¶
Victor Lopez Nokia Email: victor.lopez@nokia.com Qin Wu Huawei Email: bill.wu@huawei.com Raul Arco Nokia Email: raul.arco@nokia.com¶